Bug#844431: policy: packages should be reproducible
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.
>
> And given that this is a new field I think it's ok, while somewhat unsatisfying,
> that maybe some unreproducibility will only be detected by a more advanced
> tool, like reproducible.debian.net (which aint a,b,c nor d, but e.)
> after an upload has taken place.
I think it's probably not a good idea to (when we've moved to mandate
"packages must be reproducible") allow packages to become insta-buggy by
things that are out of their control and not clearly specified in
policy. That's not how we do things in Debian.
As such, I would favour the following approach:
- You guys (= the reproducible builds guys) come up with a list of
things that commonly make a package nonreproducible today, and policy
adds those as "should not"s. If I'm not mistaken, such a list already
exists, you may simply need to generalize it a bit?
- Actually, I'm sure there may be things that packages failed to
comply with in the past, but that are not a problem anymore today;
we can make those "must not" rules already today.
- If you find new and interesting ways to make packages nonreproducible
at some point in the future, those can be added (as "should" first,
and as "must" later).
This would result in a section in policy of this form:
---
# Reproducible builds
Packages should generally be reproducible. That is, a package build
should result in a bit-by-bit identical package from one build to the
next.
Specifically, packages must not do any of the following things:
- non-reproducible thing A
- non-reproducible thing B
- ...
Moreover, while the following are not must rules yet, packages should
also not do any of the following things:
- still-in-the-wild non-reproducible thing A
- still-in-the-wild non-reproducible thing B
- ...
---
(wording may need some tweaking)
The above wording makes "bit-by-bit identical" a should (so packagers
are encouraged to reach that goal), but already allows you to file RC
bugs on some subset of "is not reproducible" package issues, and a
subset that will improve over time.
With that wording, I don't think we should ever make "bit-by-bit
identical" a must; I also don't think we would need to. As you say,
building packages nonreproducibly is difficult to define, and it
certainly is difficult to test for in a definite manner.
> > What parameters
> > are allowed to change need to be defined.
>
> I sadly think this is impossible.
I agree that it will probably be a neverending effort, but I also think
it's the only way that it can reasonably be done.
--
< ron> I mean, the main *practical* problem with C++, is there's like a dozen
people in the world who think they really understand all of its rules,
and pretty much all of them are just lying to themselves too.
-- #debian-devel, OFTC, 2016-02-12
Reply to: