On Mon, 24 Sep 2007 00:54:58 +0200 Martin Uecker <muecker@gmx.de> wrote: > Neil Williams <codehelp@debian.org>: > > Martin Uecker <muecker@gmx.de> wrote: > > 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. > > This could be fixed. Fixed?? What the? You're asserting that this is a PROBLEM to be fixed? It's good, it's useful, it's helpful. I'm confused, what is wrong with that? :-( IMNSHO, this is not a bug, there is no good reason to prevent upstream from using such macros and besides, there are other upstream processes that modify the built binaries every time the build proceeds. Think Latex and various other generation tools. 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. > > 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. -- Neil Williams ============= http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/
Attachment:
pgpFrVoHZYuGY.pgp
Description: PGP signature