On Sat, 2012-02-18 at 12:03 -0200, Henrique de Moraes Holschuh wrote: > The problem is that we want more than just config.guess/sub to > be updated...
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. > 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. Tested by upstream, since they are probably the only ones with a collection of emulators and VM images vast enough to do so. > 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. 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. > 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. 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. > 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 :-) 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> -- bye, pabs http://wiki.debian.org/PaulWise
signature.asc
Description: This is a digitally signed message part
