Collaborative Working Sessions - Packaging

Reproducible Builds Summit 2022

Day 1:

Points to work on:

The package managers that would be taken into account: Pip, Stack, Kabal, Debian, FreeBSD, OpenBSD, rpm, Guix, Cargo, Go modules, Gradle, Npm, Docker, OCI, Maven, opam (missing in the group: Ruby Gems, Composer, Nuget)

What reproducible would mean in comparison between binaries or just “text” like source code (JavaScript, Python or any other type of intrepretable): what is distributed? => there is probably a classification between package managers to be found

Once you have a reproducible candidate (release manager thinks his package should be rebproducible), you need to have another actor that should try to verify the reproducibility by rebuilding and checking against the published reference: only when someone can get the same output is the release marked as “reproducible verified/confirmed”.

Language specific packagers:

Day 2:

Starting actions:

Artefact:

In case of Debian, the build.info file provides all the information and can be used as input for debrepro.

From the perspective of the reproducibility we can have the following when it comes to languages:

Reproducibility classes:

Practical tests:

In Debian’s case everything that is released is built from scratch, including Java packages for instance. The minimal subset of inputs required to be able to generate reproducibile builds is the set of dependencies and some environment variables. The assumption is that the dependecies are safe.