On Wed, May 16, 2007 at 10:00:57AM +0000, [EMAIL PROTECTED] wrote:
> On Wed, May 16, 2007 at 11:21:51AM +0200, Guus Sliepen wrote:
> > On Wed, May 16, 2007 at 11:12:56AM +0200, Richard Atterer wrote:
> > > > Wouldn't it be better to unpack a package twice in two different
> > > > directories, build and clean in one dir and then compare the obtained
> > > > tree with the tree available in the other dir?
> > > IMHO, a good test would be to build the package twice and then to compare
> > > whether the created .debs are identical between the first and second run.
> > > (Of course, file timestamps would have to be ignored when comparing.)
> > There are lots of reasons why the resulting package can differ each time
> > you build it, some of them perfectly valid. For example, this is not
> > uncommon in C programs:
> > printf("foo version %s (built %s %s)\n", VERSION, __DATE__, __TIME__);
> > Also, running update-po will always change the header of a .po file to
> > reflect the last time update-po was run. I don't think we can require
> > that building a package twice in a row produces exactly the same .deb
> > and/or .diff.gz.
> granted there are things like this, but reproducible builds would be
> fantastic and well worth the effort.
If you're talking about "byte-for-byte identical builds", then no, that
would be a tremendous amount of effort for no practical gain. There's no
reason to consider it a bug for packages to not be byte-for-byte identical
between two builds, so why should anyone waste time trying to "fix" it?
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
[EMAIL PROTECTED] http://www.debian.org/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
