Re: RFS: knmap -- Kde interface to nmap [uploaded]
Henrique de Moraes Holschuh <hmh@debian.org> writes:
> 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.
Unfortunately, it's rather tricky to do this properly. I've done the
autotools cleanup of a lot of different projects, and I think I can safely
say that almost no one knows how to write safe autotools scripts.
I agree with your point about Automake and libtool; it's a lot easier to
handle it in Debian because you can depend on the specific version. I
worry more about Autoconf, which does sometimes break things from version
to version. Of course, at this point, Autoconf upstream is somewhat on
life support, so maybe it doesn't matter as much any more.
> 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.
Believe me, I'd be happy to use something that's a little saner to work
with for the packages I'm also upstream for. I already refuse to use
Automake for various reasons. I've just never found anything else that's
really a reasonable replacement for Autoconf or libtool (and Autoconf does
do a good job if one really knows how to write macros, although it's
harder than it should be to express a lot of things in its language).
> 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?
I don't remember the last thing I got bitten by, but I think it was more
recent than 2.52. Something related to LIBOBJ, maybe?
> 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.
Yup.
The other problem is that this sort of fix is often very hard to get
accepted upstream, since it tends to be a substantial change that partly
looks cosmetic and the build tools all work for them on their platforms.
It's also often quite a bit of work to turn the broken macros people use
into something clean.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: