Re: RFS: knmap -- Kde interface to nmap [uploaded]
Bas Wijnen <shevek@fmf.nl> writes:
> I completelely agree. When I read Steve's e-mail about libtool
> (referenced earlier in this thread), I was again confirmed in my
> position (although I think Steve doesn't agree with it) that running the
> autotools (and that includes libtoolize) from debian/rules is a very
> good idea: It makes sure that the latest (and presumably best) version
> of everything is used. And that "everything" includes libtool and
> autoconf, but also Makefile.am and configure.ac.
> Of course I know the classical argument against this: To build a
> program, you should only need to do "./configure;make;make install".
> configure is the platform independant script, autoconf should only be
> used by upstream.
> I strongly disagree with this line of argument. Autoconf was indeed
> created to allow building on platforms which don't have any special
> portability tools installed. In particular, they don't need to have
> autoconf installed. However, this is completely irrelevant if we _do_
> have them (and on Debian we do, of course).
The problem is, in a nutshell, this doesn't actually work reliably. If
the Autoconf tools had a clean language specification that they continued
to implement or at least only changed at major revisions, you could be
sure that re-running the autotools on a package would only fix bugs.
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
upstream release will just break horribly (or worse, break subtlely) on a
given package.
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.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: