[Josselin Mouette] > Given that especially autoconf introduces serious incompatibilities > between minor releases, this is simply not feasible because it would > trigger hundreds of FTBFS errors each time a new autoconf version is > uploaded. So it sounds like you're saying that, although we ship source code to our users, we _assume_ that the source doesn't actually build with our tools, so we have to also ship precompiled code to work around this. To me, that's a poor attitude for a distribution that focuses on providing users with access to source. What use is source code if it can't be hacked on and rebuilt? I think we should have a little bit of faith in our autoconf maintainer not to introduce incompatible versions without changing the name. This was already done for autoconf2.13 -> autoconf2.50 (the latter since renamed to autoconf). If he uploads a version of autoconf that breaks other builds, the appropriate response is to file a bug. That is what we do for gcc. (Sometimes the response is "too bad, gcc is changing to be more strict, you'll have to fix your package", and yet, the world somehow fails to end.) Honestly though, I haven't seen autoconf break my packages for a very long time - I can't even remember last time it happened. (It might have been autoconf2.13 -> autoconf2.50.) Were you thinking of automake, perhaps? automake changes much more frequently, which is why we have so many versions in the archive, so you can use a version that won't break your builds. -- Peter Samuelson | org-tld!p12n!peter | http://p12n.org/
Attachment:
signature.asc
Description: Digital signature