At Tue, 12 Apr 2022 21:54:00 +0200, Tobias Nygren <tnn%NetBSD.org@localhost> wrote:
Subject: Re: lang/guile30 violates basic pkgsrc mechanisms to work around an ancient bug
>
> On Tue, 12 Apr 2022 12:20:34 -0700
> "Greg A. Woods" <woods%planix.ca@localhost> wrote:
>
> > -LOWER_VENDOR?= # empty ("arch--opsys")
> > +LOWER_VENDOR?= unknown
>
> Expect a lot of pushback on this change.
Yeah, I know what you mean, but....
1. NetBSD pkgsrc has _always_ been arguably wrong (well, before 1998 it
was more correct, though still imperfect.)
2. Other Autoconf-using packages have exhibited related problems in the
past (emacs for one)
> Why change the default
> triplet just because guile upstream insists on being difficult?
Why battle against doing the right thing? It's just a poor excuse to
claim "well because the current way mostly works most of the time".
Obviously it hasn't actually always worked. The current way clearly
fails sometimes and in at least this one case has caused someone to make
a poor hack (not even a proper patch) to try to avoid the issue.
The vendor string only matters when it matters, but why fight against
those cases -- one cannot predict when or where they will occur and
without a change like the one I suggest pkgsrc will _always_ have to
play catch-up, hacking and patching around those cases whenever and
wherever they occur.
Meanwhile there is a clearly and obviously correct fix which will 100%
guaranteed prevent all future hacks and patching.
Pkgsrc is trying to drive a "foreign" build tool, and that tool has
clearly documented an ideal way to specify its options, but pgksrc isn't
(always) following those guidelines completely and carefully. (Pkgsrc
does appear to provide a non-empty vendor string for all(?) other
platforms it supports.)
It's never too late to fix pkgsrc to do the right thing when invoking
GNU Autoconf generated configure scripts.
> Stating that the vendor component cannot be empty string seems
> like historical revisionism to me since the vendor component was
> historically optional.
Well, the vendor component is "optional" only in the sense that it
doesn't HAVE to be some registered or even widely known string, with the
clear exception that "unknown" has been the literally canonical default
value for any unknown vendor, though of course this is only clearly
documented in code, or by example:
$ cd guile
$ build-aux/config.guess
x86_64-unknown-netbsd9.99
See a recent version of Autoconf's "config.guess", especially for the
comments in the code related to NetBSD where NetBSD is pointed out to
being particularly uncaring about the "vendor" portion:
https://git.savannah.gnu.org/cgit/config.git/plain/config.guess
The ancient way of using "$(uname -p)-netbsd" way worked OK for most
uses because "config.sub" could, and still can, canonicalize that form
to the proper triplet:
$ build-aux/config.sub x86_64-netbsd
x86_64-pc-netbsd
$ build-aux/config.sub i386-netbsd
i386-pc-netbsd
$ build-aux/config.sub sparc-netbsd
sparc-unknown-netbsd
(Note there's an interesting and relevant comment in the code about the
choice of "pc" vs. "unknown" too.)
However "config.sub" has always been a bit dumb about handling a missing
vendor string (since it's not always important), and I guess that's why
pkgsrc fell into the trap of not supplying it and been mostly getting
away with it ever since 1998.
BTW, it looks like pkglint will complain if LOWER_VENDOR is defined as
an empty string:
reg.sysloadbl3("LOWER_VENDOR", BtIdentifierDirect, NonemptyIfDefined)
Obviously pkglint is not meant to audit the pkgsrc/mk/* files, but.... :-)
--
Greg A. Woods <gwoods%acm.org@localhost>
Kelowna, BC +1 250 762-7675 RoboHack <woods%robohack.ca@localhost>
Planix, Inc. <woods%planix.com@localhost> Avoncote Farms <woods%avoncote.ca@localhost>
Attachment:
pgp4TvfW0GaGB.pgp
Description: OpenPGP Digital Signature