[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/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
