Bruno Haible via "Patches for the config.guess and config.sub scripts" <[email protected]> writes:
> Simon Josefsson asked: >> That reminds me of a long-lived pet issue: is there any strong reason >> for having those files in that special project? > > Yes. I would say, the reason is that, this way, it is not subject to > (possibly biased) influences from any other GNU package. > > For instance, if these scripts were maintained inside GCC, I would > expect to see more unlucky disagreements between the config arch > and the mainstream term (such as 'aarch64' vs. 'arm64'). > > The parts of the GNU build system (config, autoconf, automake, libtool, > gnulib) have distinct skills requirements for their maintainers. For example, > autoconf and automake maintainers need to know Perl, whereas libtool > and gnulib maintainers need to know Shell and C. The skills requirements > for config are just Shell. I think that's a good thing. Yeah, I don't disagree here. >> It is not widely packaged by distributions (I think) directly, so access >> to the latest non-vendored version of those files is fairly obscure. >> >> Would it make sense to move the files to gnulib? > > Gnulib is already redistributing the latest versions of these files. > I don't see the problem that you see. There is a growing trend to avoid vendoring files, because of bit-rot and supply-chain concerns among other reasons, and while it is not really enforced well in many places yet, I do believe vendoring files is something we should try to reduce. There are much larger problems than the 'config' files, but I think this sets a bad example for important files that are executed by almost anyone running ./configure. That's the only problem I see, and it is subjective. I just wanted to float this in case others also share this concern and see some improvement to make here. /Simon
signature.asc
Description: PGP signature
