Re: [RFC] getting rid of the config.guess/sub problem when bootstrapping new ports/systems

[Paul Wise]

On Mon, 2012-10-08 at 10:22 -0600, Eric Blake wrote:

> Not to discourage you, but I still see a fundamental problem, where
> things will just not scale for several more years (if ever).  Your
> proposed patch will have no effect on packages that were shipped with a
> configure script generated by autoconf 2.69 or earlier (that is, they
> would only affect new packages built with the as-yet-unreleased autoconf
> 2.70).  Therefore, you STILL have to touch every single package that was
> built with older toolchains to get them to take advantage of any new
> self-upgrading code path built into a newer autoconf.

I acknowledge this problem and there is no way to get around it.
The patch is not meant to be useful for arm64, I'm taking a much longer
term view here, the benefit is perhaps 5-10 years away. Once the patch
is in a released version of autoconf it will percolate through the
distributions archives as projects autoreconf with the latest autoconf
and make new releases. Eventually we will have good coverage in most
distributions. In the meantime, within Debian we will be pursuing both
per-package updating of config.guess/sub and I'm also thinking about
getting our binary package build toolchain to take that role, but I'm
not sure how well that would be received within Debian or how well it
would work.

> Is it safe enough to look at common system locations alone, or should we
> also be attempting a network lookup for the latest canonical upstream
> sources (of course, realizing that networking might not be available, so
> we must not trigger fatal failure just because a machine is off the grid
> at the time configure is run).

For Debian, network access is usually disabled on our build daemons.
I would discourage this without some checking of GPG signatures,
otherwise it would be easy for network attackers to get arbitrary code
execution on people's laptops and distribution build servers.

> I haven't yet looked at the patch; it's non-trivial enough that it will
> need copyright assignment to the FSF before it can even be considered.

Personally I don't consider the patch to contain any creativity or to be
copyrightable. I therefore consider that it is in the public domain and
to the extent possible under law, I have waived[CC0] all copyright and
related or neighboring rights to this work. If that isn't good enough
for the FSF, then I'm willing to assign copyright as needed.

CC0: http://creativecommons.org/publicdomain/zero/1.0/

> But I'm first worried about the bigger implications of what you intend
> to do about the fact that packages that were not built with autoconf
> 2.70 or later (assuming this patch makes it in) will still not benefit
> from this patch.

I hope I've addressed them to your satisfaction above.

-- 
bye,
pabs

http://bonedaddy.net/pabs3/

signature.asc
Description: This is a digitally signed message part