On Sat, 02 May 2009, Bernhard R. Link wrote: > First of all, you do not discuss the most common type of packages: do > not change the build-system, but just use it. This means autotools are > never called, neighter when preparing the package, nor when building the > package.
Yeah, it is really common, and it is also close to being the 'worst practice' (except for the few packages whose upstream takes very good care of their build system and keep it up-to-date themselves). > The more important goals are: > - derivation from upstream: > + every change means using something not previously tested. Well, as a rule, we do much better at testing build systems than any upstream, anywhere. We build for MUCH more platforms, for one. And likely we're already using a newer toolchain than upstream anyway... and that's far more likely to root out bogosity (or to cause bogosity for that matter) than autoreconf. > Change source files, run autoreconf at build time > - derivation: package is build with a system run with another autotools > version, but the way this is done is canonical > - identification: as only the build system's source file changes, easy > to grasp (unless the new autotools version bring the real changes). > - maintainability: perfect > - robustness: danger of new autotools version breaking the build This is the current best practice, but it needs to be done right. There is a reason why autotools-dev recommends that you should use the proper environment vars (and build-deps and conflicts when needed) to lock the auto* versions you have tested with. There is one _very_ important reason why it is the best practice, too: since the build process is complete, and tested at every upload on every arch, it is far less likely to break on the hands of the security team, or on the hands of a porter of a new arch, or in the hands of someone else in a time of need. -- "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 debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
