Bug#844431: Revised patch: Oppose
rra at debian.org
Wed Aug 16 16:30:23 UTC 2017
Adrian Bunk <bunk at stusta.de> writes:
> I hereby oppose the addition of this to policy.
> It is not true that this would be "Debian's precisification" of
> reproducible builds.
> The definition does not match any past, present or future practice in
> Including the people who want this change to policy, there seems to be
> noone intending to use this definition of reproducibility.
> Adding this to policy would do more harm than good.
Let me get the formal part of this out of the way first:
As Policy Editor (a delegated position), based on my read of project
consensus including in-person verification of that consensus at DebConf
17, I am formally declaring that I believe this change has consensus
despite your opposition. We will therefore include this change in the
next release of Policy.
If you disagree, your choices of action are appealing to the Technical
Committee under section 6.1 of the Constitution (I'm fine with using that
section and letting the TC take a majority vote), or propose a GR under
Okay, now, why I'm taking that stance:
This text is a formalization and simplification of existing practice that
we worked out in conjuction with the reproducible builds team and that
strikes a balance between attempting to enumerate all the causes of
nonreproducibility (which would be quite difficult to do) and providing
some clear guidance to maintainers about what types of output variance
they *don't* have to worry about (since obviously packages can't be
reproducible under all circumstances and in all environments). The
intention is to set a minimum bar that packages should be trying to meet,
and to lay the groundwork for future work.
This is directly in the center of Policy's normal role of standardizing
and documenting best practice that has been developed elsewhere in the
project. The project is already comfortable with filing bugs against
packages for being non-reproducible under this criteria of
non-reproducibility, and we already have put significant work into
establishing a baseline and have a firm understanding of how close we're
currently coming to meeting that baseline. This meets the bar for
maturity of work that we look for in major Policy changes. As with many
other things in Debian, we hope to improve further later on, and to raise
the Policy bar over time as we develop better tools and better
understanding, but this bar is one that we can start recognizing with
normal-priority bugs right now.
The bug severity was specifically chosen to not kick any packages out of
Debian and to not make reproducible builds mandatory, simply to recognize
them as bugs that we as a project want to see fixed. This feels like the
right balance to strike at this point. More work would be required to
make them RC.
The definition is not decoupled from current practice. It is roughly
equivalent to the information currently captured in *.buildinfo files
while being easily comprehensible to people who haven't studied
*.buildinfo files. More precision will be possible in the future, but we
don't have to wait for that to set the simpler bar.
On the consensus side, there was a rare opportunity here to get a measure
of consensus from a large section of the project. Holger specifically
asked for a show of hands and a show of objections (there were none) for
including this standard in Policy, and we had various discussions with
other people over the course of DebConf. We have a much better read on
project consensus for this than we have for many other things in Debian.
Finally, Policy in no way constrains people from filing bugs or reporting
issues (via whatever means, such as tracker.debian.org) in packages about
things that are not spelled out in Policy. This is a core principle of
Policy maintenance that we have held to for the more than a decade I've
been involed in Policy maintenance. Policy is not an exhaustive list of
the possible bugs in packages, and never will be, and Policy will never
prevent people from filing bugs against packages at the severity that they
think is appropriate. The definition of reproducibility is no exception
to this general rule.
Rather, the general project stance has been that Policy spells out the
things that are less open to debate, and bugs filed on the basis of things
that aren't in Policy are more at the maintainer's discretion (assuming
obvious common sense is applied). And that's what I would expect for any
bugs filed about reproducible builds failing criteria more strict than
those stated in Policy (such as differing build paths) until such time as
project consensus builds that we want to hold all packages to that
stricter standard regardless of maintainer preference.
To be clear, the above discussion is intended as an explanation for this
decision, not a continuation of debate. If you disagree with the above,
you should probably address those objections to the Technical Committee; I
feel like I have a pretty complete understanding of the issues here, and
it's highly unlikely that further elaborations or rephrasings of your
current arguments are going to change my mind.
Russ Allbery (rra at debian.org) <http://www.eyrie.org/~eagle/>
More information about the Reproducible-builds