Re: Source-Depends? Autoreconf?
* Henrique de Moraes Holschuh <hmh@debian.org> [090502 18:25]:
> 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).
I disagree here strongly. While many Debian developers are better at
judging and improving build systems than the average upstream,
understanding a build in all its details and important pitfalls just
needs to much experience with that specific package to be error-proof.
Thus the best way is the DD to help upstream to improve the build system
and then is using the upstream build system unmodified as long it can be
used to produce sane results. (Of course often build systems are just
too broken for that. But often the perceived need to change a build
system is just a result of understanding the tools involved. (Like often
giving make an argument makes patching a Makefile uncessary).
> > 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.
We build for much more platforms, but all our platforms are quite
uniform w.r.t. things a build system usually has to deal with.
It also depends on the kind of package. Most things are just too seldom
tested in Debian package. Breaking core funcitonality or failing builds
will usually be caught well, but that is not true for anything.
For example in one package I mispatched a Makfile to support DESTDIR.
Upstream did only install a file, if it was not already there. The
install command got the DESTDIR, but the check did not. This introduces
a bug causing the file to be missing if the package is build with it
being installed. I doubt any DD would have caught it until some poor
user wanting to recompile/patch it would have been bitten by it, had
I not by cheer luck and comparing file lists all the time would have
found it.
> 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.
Well, newer for some upstreams. Older for other ones. And often both
older and newer at the same time. This only means this point is one of
many, not that it is unimportant.
> 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.
This is what I called robustness. And I fail to see how having a new
build-system every time can be more robust than using the same tested
again and again. (Unless people want to change something in the build
system, which is also an important thing to look at. Having to
change the build system in a security upload or a new arch is quite
rare (especially with autotools, which abstract architectures into
specific files), but it is also an important point, though I'd put it
into maintainability).
Hochachtungsvoll,
Bernhard R. Link
Reply to: