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/
Attachment:
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Autoconf mailing list Autoconf@xxxxxxx https://lists.gnu.org/mailman/listinfo/autoconf
