On Sun, May 03 2009, Bernhard R. Link wrote:
>> 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).
Having a package that only builds in a hothouse (that is, with a
single "tested" toolchain) is actually detrimental to the quality of
implementation. If we are trying to be a good citizen in the free
software world, just building a binary package that happens to work on
our buildds is just one goal. We should also seek to
+ cater to users building our software on their regular machine (not
just in artificially clean build environments)
+ Try to find out bugs in the toolchain -- and that means the
autotools too. Locking down gcc or autotools versions hinders this.
Can using whatever gcc or autotools is around sometimes uncover
bugs and prevent building? Sure. But once found, these bugs can be
fixed, and not just for Debian package builders.
manoj
--
An engineer is someone who does list processing in FORTRAN.
Manoj Srivastava <sriva...@debian.org> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
