[rb-general] Core Debian reproducibility: how close?

[David A. Wheeler]

On Thu, 25 Oct 2018 18:47:58 +0000, Holger Levsen <holger at layer-acht.org> wrote:
> Hi David,
> your simple question is not that simple... :)

That's true for many questions :-).

But I think it'd be wise to try to identify
"what's most important first" that is *user-visible*, and focus on the
steps necessary to get *there*.  If you can't boil things down to
their essence, it's hard to get backing (for example).

> besides what Chris said, I think it's useful to divide your question
> into several:
> 
> when will we have:
> - reproducible debootstrap?

That's a useful *intermediate* step, but I think most Debian users don't
use a debootstrap result directly (tell me if I'm wrong).
So I don't think that's important, except as an internal progress measure.

> - reproducible installer build?
> - reproducible installation images?
> - reproducible default desktop installation?
> - reproducible cloud images?
> - all packages in Debian reproducible?

How about "reproducible minimum required set of packages?"
(which wasn't on your list.)  And soon before or after that,
"reproducible installation images".

"All packages" is a lofty goal - but I think that's a distraction.
The graph is cool, and focusing on general tool improvements instead of
fixes-per-each package has its advantages.  HOWEVER,
it's *way* more important to focus on the small set of packages that
*must* be installed, and the set of packages that *most*
people install would probably be next.

It might not even be *possible* get all packages, and I think there's
a point of diminishing returns.  If you don't install foobar and don't depend
on its results, it really doesn't matter if foobar is reproducible.

> And then it will need up to two years to go from sid to stable :)

Sigh.  Another good reason to try to get the good "lab work"
into actual delivered components.  To be fair, lots of people use testing or
unstable, so getting it into those releases would be a big improvement.

> For "reproducible installation images", TAILS has shown this can be done
> today. Someone "just" needs to check the debian images and adopt the
> changes done in TAILS.

Sounds like no one has taken on that work, which is surprising.
Is that a bug on the Debian bug list that Chris noted earlier?

> For "reproducible default desktop installation" we really should have
> an exact matching package set on https://tests.reproducible-builds.org/debian/buster/amd64/index_pkg_sets.html
> but until the the 30 failing packages on
> https://tests.reproducible-builds.org/debian/buster/amd64/pkg_set_gnome.html
> are giving a good idea.

I think it'd be more important to start with the packages *everyone* has to
install, and then add the default desktop install packages once people can
get the required ones working.

> I believe it's useful to file 6 bugs to track those 6 topics and I will
> do so in a bit.

Excellent.

> what's missing, especially lately has been any focus on those 59
> packages failing there (or focus on anything...) (could partly be
> related to lack of funding...)

Sigh, I'm well aware of that problem.

> it's just a very big challenge: the stuff I described in this email is
> mostly what I call the theorectical side of reproducible builds (making
> sure the software can be build reproducible) while I havent really
> touched the practical parts (how to make sure distros have reproducible
> builds which can be verified by users) I havent mentioned at all,
> basically. 

If there's *no* part of a distro as received by *users* that is reproducible,
it's hard to argue that reproducible builds are real.  Once you can say,
"the installation and this minimum subset have reproducible builds",
it's far more "real" and it may be easier to argue for fixing those other parts.

For example, once some parts are really reproducible, you can organize
"build parties" or "build-offs" where different organizations in different
places can build things & verify that they got the same result.
That might give a lot more visibility to the reproducible builds work.

It might even be easier to get funding for the remaining pieces:
"Parts X and Y as delivered to users are reproducible; we need funding to
get parts K through W to be reproducible as well".  The current progress
chart is cool, but it falls apart once someone asks "how many of those
are *delivered* as being reproducible?"

--- David A. Wheeler