On Sat, 14 Jan 2006, Russ Allbery wrote: > The problem is, in a nutshell, this doesn't actually work reliably. If
It does inside Debian (you can explicitly choose a given version, and upgrade to the next only after some testing). It *mostly* does among minor versions of the autotools, if whomever wrote the scripts didn't abuse internals or fork-and-modify macros. > the Autoconf tools had a clean language specification that they continued > to implement or at least only changed at major revisions, you could be Now, that's a valid complain. But it is a reason to use something ELSE than autotools, and not to keep around old broken stuff inside Debian packages. > Unfortunately, in practice, interfaces go away or change radically in > minor releases, people have to use locally hacked versions of the tools to > work around bugs (heck, Debian's are even modified to fix major bugs that > upstream hasn't fixed), and it's a random lottery whether the next And *THAT* is the reason why you should autoreconf (as in regenerate everything autotools, and that includes libtool) often, using the Debian packages. Now, why the GNU people taking care of auto* can't get version numbering right, I have no idea. autoconf should have been versioned 3.00 instead of 2.50, and automake 1.5 should have been automake 2.0. But I haven't seen great changes since automake 1.6, nor since autoconf 2.52. They now warn you of breakage the previous versions didn't complain about, but that's something gcc 4 does as well, for example. Maybe I am just lukcy? > You're probably safe doing this with small packages, but I cringe at the > idea of re-running the autotools automatically on a substantial package. Well, it depends. I *rewrote* the autotools scripts for substantial packages to clean up the usual load of crap people put in there, because I know well that it won't stand up for abuse (crap and dumb hacks are something that lacks good resilience, as we all know :P). This speaks against the quality of the autotools documentation and its learning curve. I always rebuild the entire auto chain before every upload of every one of my auto-* packages. As long as I fix anything hackish or plain broken done by upstream as soon as it shows up in my diffs, it is quite rare for me to have to revisit any given section of an .am or .ac file. Of course, I am not maintaining anything that *forked* the autotools macros and expected to get away with it by never merging back changes from upstream as autotools evolved. People stuck with that legacy will, of course, go through a lot of pain, regardless of which reasons caused the fork in the first place. -- "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 [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
