On Wed, May 16, 2007 at 04:22:17PM -0700, Steve Langasek wrote:
> 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?
As a check on whether a binary is in fact the binary that builds from
the source that purports to be from ?
Regards,
Paddy
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
