> On Mon, 24 Sep 2007 00:54:58 +0200 > Martin Uecker <[EMAIL PROTECTED]> wrote: > > > Neil Williams <[EMAIL PROTECTED]>: > > > 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
