The attached patch (that unfortunately was reject upstream) checks a
number of paths for newer versions and runs the newest one. The reason
for the rejection is not documented publicly, but was basically "It adds
more complexity than I would like." with existing workarounds suggested
as a replacement.

This patch is useful for distributions like Debian that add new
architectures and then have to update config.sub and config.guess in
every single package that uses automake or have to workaround the
problem by adding code to each package to copy in the latest versions of
these scripts from another package containing the latest version of the
scripts (autotools-dev in Debian).

We really want the packages to retool during build, so that the build can
pick up fixes to the tooling AND to force the package to be honest (i.e. no
hidden changes to configure/makefile).  Otherwise, it comes back from the
grave to bite people who are doing security updates or NMUs, or taking over
the package because the original maintainer disappeared.

Also, any changes to config.guess and config.sub have to be vettoed against
really nasty, really buggy, really crappy oldware.  Have you managed to do
that, or otherwise constraint yourself to stuff that had already to be
working for config.sub/guess to work?  It does look like you did, but I need
to be certain about this one... upstream maintainers do develop using Debian
and Ubuntu, and whatever we provide ends up also being distributed [outside
of the packaging system] as part of upstream sources, to build on platforms
that are far less sane than Debian or Ubuntu userspace.

So, as you see, I am not sure it is a good idea to accept this patch.  It is
useless for all packages that do what we want them all to do in the first
place (retool during build), and it is a deviation from upstream which might
cause surprises to upstream developers of software that uses GNU config
(config.sub/guess).

I will wait for more comments before I make my mind.

The idea behind the patch is that after an initial (admittedly long)
bootstrap period, updating config.guess/sub can happen outside packages,
since they will automatically pick up new versions of the scripts in
autotools-dev, /usr/local or $HOME. This eliminates the config.guess/sub
problem for new Debian ports and new ports for other Linux, kFreeBSD,
Hurd etc distributions. The new ARMv8 thing you mentioned in the
autotools-dev changelog is an example of this.

I haven't checked the script updates against oldware. The changes only
make it swap itself for newer versions of itself. Presumably newer
versions of the scripts will be tested by yourself/upstream. I received
quite a bit of advice from Debian folk when I was creating this patch
about different shells. The only constructs it adds that weren't already
present are $@ and $HOME but I presume that these are portable enough. I
admit that the paths chosen may not work on all platforms but they can
be easily complemented.

Personally I feel that not wanting to deviate from upstream is plenty
enough of a reason to reject this particular patch, but in that case I
would ask you to consider attempting to re-discuss this upstream.

An alternative (and possibly better; no bootstrap period) way to achieve
the same result might be for dpkg-dev to check the timestamp of the
config.guess/sub in the package and replace it at the right point in the
build process. Getting this right might be quite hard though.

I got that.  The problem is that we want more than just config.guess/sub to
be updated...

Not really.  ARM wanted aarch64 on GNU config also for upstream reasons, as
I said, people DO develop on Ubuntu and Debian.

I'm worried that the new shell code won't run in whatever crap oddball
*nixes used.  Not that I care much about them, but since this will leak to
many upstream tarballs, I am duty-bound to require any changes to be at
least as safe as whatever upstream is doing.

By whom?  That's probably what worries upstream as well, that's probably why
upstream didn't like the added complexity.

Truth to be told, I am pretty sure lots of the code in config.guess is
currently subject to various levels of bitrot.  The testsuite can only go so
far, especially when you cannot really trust the target platform to provide
sane "sed", or even a sane /bin/sh.

I would, if it would give us enough of an advantage to push it instead of
actually clamping down on packages that do not retool on build.  But
packages that use GNU config without autoconf are rare, and packages where
we can ignore the need for eventual retooling are difficult to track down.

So, if anyone can provide compelling reasons that show it would give us
enough of an practical advantage, I'd be willing to also talk to upstream
about it.

Well, that I'd have no objections to, on the grounds that it won't leak
upstream, won't deviate from upstream, and that if you want it enough to
actually manage to get it done, you deserve to have it :-)

We do? Sounds like there is a gap in my understanding then.

Maybe you want Makefile.in, configure updated using recent autoreconf,
replacing the pre-built upstream versions? I would also advocate that,
but I think that is a much harder problem.
...

Tested by upstream, since they are probably the only ones with a
collection of emulators and VM images vast enough to do so.

The sed usage is approximately the same as earlier in the scripts,
switching to sed -e would make it more like that though. The usage of
$HOME will not cause any issues if it is unset. I'm slightly worried
about test -x working everywhere, the rest of the script uses [ -x
instead. test -gt is used earlier in the script. I'm not sure how to
find out if $@ works, but the configure scripts generated by autoconf
seem to use it a fair bit.

Some years ago the number of config.guess/sub related build failures on
a new Debian architecture made me write the patch. Never having those
problems again was the practical advantage I saw.

Retooling every package one by one is doable, but involves a lot of
manual work by a lot of individual maintainers (verifying their upstream
is sane etc). Getting --with autoreconf as the default for debhelper's
dh sequencer would reduce that manual work but might introduce a fair
number of bugs.

I feel thats a workaround for not being able to do things upstream so
they benefit the wider free software community, which I promised to do
when I joined Debian:

http://www.debian.org/social_contract

<insert grumbling about the compiler hardening stuff not being upstream>

Hello,

Good morning,

We have gone through your samples from a partner and Here is our  Order
List. Please do bear in mind that we are very much in  need of this
order, quote your competitive prices.

Kindly send the Order confirmation.

Your early reply will be much appreciated.

Best Regards,

Maryanah Erwin.

PT FINDORA INTERNUSA

Jln Pahlawan 66 Kec. Arjawinangun

45162 CIREBON West-Java INDONESIA

tel : +62 231 357334

fax: +62 231 357260

email: marketing@findora.com