Re: automake/autoconf in build-dependencies
On Sat, 19 Mar 2005, Henning Makholm wrote:
> Better have them restricted to developers and users who modify code
> than to have them happen randomly to people who just want to build the
> unmodified package.
Like, say, our security and QA teams. I would very much like their opinion
on this, they're the ones that get to hold the short end of the stick when a
maintainer fails to keep his package in top-notch condition.
As far as I can see, any package that is not suffering bit-rot is much
better off using a full autotools update per build, be it at every build
(if you are a fan of dpatching the build structure), or at every source
upload (if you'd rather do it under controlled conditions).
That means the person who knows best (the package maintainer) AND who is
supposed to be taking care of the package in the first place, keeps it
working for everyone else. 99% of the time if something does not work with
the latest autoconf (and latest *revision* of the automake branch used to
create said package), it is buggy and bugs need to be fixed ASAP. Anything
that does not work with the most up-to-date libtool and gettext needs to be
fixed no later than a few weeks after sarge is out.
I do not agree at all with your position that the best course of action is
to allow a maintainer to be lazy and leave a stale build system around just
so it is less trouble for him, at the detriment of everyone else. There are
very, very few packages using auto* that are complex enough to warrant an "I
am not touching this" policy re. the build system. We should consider them
the exceptions for the rule, and keep everything else up-to-date.
And really, I am one of those who call automake & friends "autohell", and
libtool "libtrash" (which really is not deserved by libtool 1.5.6+, but the
older versions... ugh).
That said, I manage to not only take care of autotools-dev, but I have also
converted *every* package of mine to the absolutest newest auto*, and
managed to push it upstream 98% of the time (and for the package that did
not make it upstream yet, it is actually much easier to maintain my fixed
build structure than go with the outaded PoS upstream has).
These are lessons well learned from the time fetchmail used to do hideous
things because of whatever weird gettext ESR was using did not like a Debian
system, a few years ago.
--
"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: