Re: RFS: knmap -- Kde interface to nmap [uploaded]
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
Reply to: