Bug#844431: policy: packages should be reproducible

[Bill Allombert <ballombe@debian.org>]

On Sun, May 14, 2017 at 11:15:26PM +0000, Holger Levsen wrote:
> On Mon, May 15, 2017 at 12:05:17AM +0200, Bill Allombert wrote:
> > On Sun, May 14, 2017 at 03:20:54PM +0000, Holger Levsen wrote:
> > > On Sun, May 14, 2017 at 05:05:36PM +0200, Bill Allombert wrote:
> > > a.) go to http://reproducible.debian.net/$srcpkg and see if its reproducible today.
> > As I said, I would like to check that my package build is reproducible before
> > I upload it, not after, so I can be sure that any bug is fixed in the
> > upload.
>  
> b.), b.0), c.) and d.) were given as possible "tools" *to build twice with 
> (some) variation(s) and compare the results*.
> 
> "Reproducible Builds" (in the sense of bit by bit identicall builds) is
> really a rather new field in the era of software (well, not really, but 
> thats history and bit rotted until it was rediscovered in the early 2010s…)
> 
> What is trivial, if given, is to show that a package is *un*reproducible.
> 
> It's much harder to show that a package is reproducible.

We should avoid a terminological confusion...

Unreproducible means that "it will never be reproduced", which is quite
different from "it will always be reproduced".
Reproducible means that "it is possible to reproduce".

So in fact it is much easier to show that something is reproducible
than unreproducible.

There are situations where policy mandates that the build will be
different (for example setting DEB_BUILD_OPTIONS).

And actually, we do not need packages to build always identically.
Instead we need a reliable way to rebuild them identically, which is a
lower bar.

If (as it is planned) all packages are built by the autobuilders, then
we could provide a tool that rebuild a package (maybe by taking a
.buildinfo as input and downloading the same versions of the build
dependencies from snapshot.d.o) using the same setting as the autobuilders.

Then policy would cover the issues that could still lead to a different
build (for example using timestamp, hardcoding hardware characteristic
of the build machine , etc.).

Cheers,
-- 
Bill. <ballombe@debian.org>

Imagine a large red swirl here.