Re: Building packages twice in a row
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
Reply to: