[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Building packages with exact binary matches

> On Mon, 24 Sep 2007 00:54:58 +0200
> Martin Uecker <muecker@gmx.de> wrote:
> > Neil Williams <codehelp@debian.org>:
> > > This has been covered before - certain upstream macros are among 
> > > many factors that ensure that this is unlikely. I, for one, use
> > > such macros upstream to indicate the build time of the actual
> > > executable installed so this will change the binary every 
> > > time it is built.
> > ac
> > This could be fixed.
> Fixed?? What the? You're asserting that this is a PROBLEM to be
> fixed?

If policy would require the exact reproducability of binaries, then
it would be a policy violation.

> It's good, it's useful, it's helpful. I'm confused, what is wrong
> with that?
> :-(

I do not see how a date stamp in a binary is really usefull. Often
it is just used as a cheap replacement of fine grained versioning
information. But I do not think that's a good reason. The date on
which a binary is built is actually completely irrelevant from
a technical point of view. What's really usefull is the exact
version of the source code and the build tools. Everything else
should not matter at all!

> IMNSHO, this is not a bug, there is no good reason to prevent
> upstream from using such macros 

Ofcourse there is: reproducability

> and besides, there are other upstream processes that modify 
> the built binaries every time the build proceeds.
> Think Latex and various other generation tools.

These could be fixed too ;-)

> Also, any build process generates files that contain different
> references and linked objects - if a package hasn't been built for a
> while (no new uploads), what on earth is wrong with that not being a
> binary-match for a package that was built yesterday against updated
> libraries?
> See also this thread:
> http://lists.debian.org/debian-devel/2007/07/msg00588.html
> and
> http://lists.debian.org/debian-devel/2007/06/msg01076.html
> If the dependencies change between builds, so will the binary.

That's an different issue. I am not complaing about the fact 
that binaries can change without source code changes, but that
it is impossible to create an identical package even when you

> > > You have md5sums and GnuPG signatures on the Release files - I
> > > see no benefit from bit-matching.
> > 
> > The build host could be compromised. Not that unlikely.
> That's why the autobuild process is not entirely automated. A real
> DD needs to sign off the ported packages.

I do not see how this helps. Imagine a build host is compromised
and this is noticed only after a few weeks. Theoretically every
machine which downloaded and installed a package in this time
could be compromised. And even worse: it is practically impossible
to find out wether a package is actually affected! 


Reply to: