Re: Proposed release goal: fix debian/rules build-arch
Charles Plessy <plessy@debian.org> writes:
> Le Tue, Feb 17, 2009 at 07:51:14PM +0100, Cyril Brulebois a écrit :
>>
>> Does â??build reproducibilityâ?? mean something to you?
>
> Hi Cyril,
>
> Build reproduciblitity means to me that two instances package built in the same
> environment should be reasonably identical (things like timestamps or random
> numbers will never be reproducible).
>
> Interestingly, the Debian packages are built in an environment where
> reproducibility is only transient as Sid is constantly updated. This is even a
> feature in the case of binNMUs.
The packageversions used are listed in the buildd log file and thanks
to snapshots you can recreate and identical build environment and
reproduce the build perfectly (timestamps and random numbers excepted).
> I do not think that anybody proposes a Build-Recommend field that can result in
> binary differences in the context of the Debian buildd network. However, since
> I agree with the persons who question the usefulness of distinguishing
> Build-Indep dependancies, because dropping this distinction would make my work
> easier and therefore more robust, I try to figure out a possible alternative.
If any buildd ever installs any build-recommends then the builds
become random. Builds on different architectures or times will use
different sets of packages and result in different features being
availabale. You can never have anything optional in the build process
without introducing random variations.
> For the purpose of skipping documentation building and test making, be it
> locally or remotely, Build-Recommends can be a useful alternative to
> Build-Depends-Indep. In particular, the use of Build-Depends-Indep to emulate a
> "nodoc" option is only possible if the documentation is separated from the main
> package in an Arch:all package. For some packages, for instance altree, it
> would mean to make a -doc package with a single PDF file in, for the sake of
> removing TeX and LaTeX from the build-dependancies.
We already have the perfectly names Build-Depends-Indep (things needed
to build indep stuff) field for that. You are proposing to create not
only a method to properly utilize that information but on top of that
rename the field to a totaly unsuitable name? How is that ever going
to help?
The Build-Depends-Indep are not recommended, they are REQUIRED when
building the indep stuff.
> I hope that this also anwers to Steve.
>
> Have a nice day,
MfG
Goswin
Reply to: