On Wed, May 16, 2007 at 08:10:44AM +0200, Martin Zobel-Helas wrote: > as a QA effort the whole archive was rebuilt yesterday to catch > build-failures, whether a package can be build twice in a row (unpack, > build, clean, build). We found about 400 packages not having a sane > clean target. > > To cite > http://www.debian.org/doc/debian-policy/ch-source.html#s-debianrules > > clean > > This must undo any effects that the build and binary targets may > have had, except that it should leave alone any output files created > in the parent directory by a run of a binary target.
What about packages that automatically pull in updated autoconf files as part of the build, or regenerate .po files which were already there, but due to a new version of the tools generates a different .po file from what was already there? The result is that doing the build caused the sources to change and be different from the source when extracted. Some packages also leave around .orig files due to patches applying but with offsets or fuzz, which also don't get cleaned up and leave the sources changed. Neither of these cases cause build failures, but they are quite annoying when trying to diff for any changes one may be trying to make to a package. I know of at least a few packages that had these issues under Sarge and I believe also under Etch: quagga, dhcp3, openswan: Generate changed .po files ntp: changes autoconf files grub: changes autoconf files and reruns automake generating new .in files. It would certainly make life a little easier for me if these kinds of changes were simply not permitted. If a package can't be built and cleaned and end up exactly like it was when extracted, then there is something wrong with how it builds or how it cleans. -- Len Sorensen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
