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
try.
> > > 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!
Martin
Reply to: