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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
