Proposed new release goal: Dependency/file list predictability
[Please keep discussion on -devel; -release is not a discussion list and
I'm not subscribed to -qa :-)]
Hi,
As discussed during DebConf, I'd like to propose a new release goal: Packages
should not only build in clean chroots, but also in non-clean environments.
Specifically, adding extra packages from the archive into the build
environment (that are not in Build-Conflicts) should not affect the resulting
package in any noticeable way.
To this end, I've set up the "build daemon from Hell" (BDFH) on my machine,
currently doing script testing. (Joey Hess has kindly promised to donate CPU
time on a four-CPU machine so we can push through the entire archive at
reasonable speeds at regular intervals; the setup will be moved there as soon
as it's stable.) The idea is to build a package both in a pbuilder and in
a really filled chroot -- it currently contains 18GB of packages, which is
most of the "devel" and "libdevel" sections. What is compared is:
- The list of Depends.
- The list of Recommends.
- The list of filenames.
(Actually, it is first built in the "dirty" chroot, and if it matches what's
in the archive already, the script won't bother doing the pbuilder test,
under the assumption that it's going to be the same anyway. I don't expect
this to miss many bugs, but it will save many lengthy rebuilds, especially
for packages that have been built recently and thus depend on the newest
libc6 etc.)
Differences between the two versions will be counted as a bug, which I hope
can get status as a release goal under the usertag
"unpredictable-build-result". Also, packages that just plain FTBFS under the
messy chroot (assuming it is not something _wrong_ in the build environment
or something, of course), should be tracked, hopefully under the same release
goal, but with the usertag "unpredictable-build-failure". I intend to start
mass filing for such bugs in a few weeks, whether it's approved as a release
goal or not (but in that case, with normal severity and a different usertag),
but I'll send appropriate warning to -devel first.
The correct fix for almost all such packages would be adding --disable flags
to the autoconf script (it is believed that most such bugs would stem from
autoconf finding and using some library); Build-Conflicts are possible, but
less than ideal for several reasons.
Comments would be appreciated.
/* Steinar */
--
Homepage: http://www.sesse.net/
Reply to: