On Sat, 18 Feb 2012, Paul Wise wrote: > The idea behind the patch is that after an initial (admittedly long) > bootstrap period, updating config.guess/sub can happen outside packages,
I got that. The problem is that we want more than just config.guess/sub to be updated... > Hurd etc distributions. The new ARMv8 thing you mentioned in the > autotools-dev changelog is an example of this. Not really. ARM wanted aarch64 on GNU config also for upstream reasons, as I said, people DO develop on Ubuntu and Debian. > > 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. > > I haven't checked the script updates against oldware. The changes only > make it swap itself for newer versions of itself. Presumably newer 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. > 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. 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. > > 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). > > 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. 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. > 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. 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 :-) -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
