Status: draft proposal evaluation
Last-Updated: 2020-08
Summary
Getting the .buildinfo files into the Debian archive has not yet happened, and it is one of the last infrastructure blockers for having full reproducible support in Debian.
Holger Levsen proposed in https://debconf20.debconf.org/talks/49-reproducing-bullseye-in-practice/ the possibility of bundling the .buildinfo files into the binary .deb archives, as a way to sidestep the deployment into the archive.
From the dpkg PoV while this seems like it could probably get implemented somehow, it also looks like the result might end up being impractical/cumbersome, more complex than needed, and backtracks on some of the design principles originally agreed on as good properties for the .buildinfo support (https://wiki.debian.org/ReproducibleBuilds/BuildinfoFiles). But it's still probably interesting to go through the pros and cons anyway, even if just for historical purposes.
Evaluation
While the proposal has definitely not really been fleshed out, we can still evaluate some possibilities.
Bundling the .buildinfo files inside the .deb archives would probably imply:
- the .deb archive are generated by a call to dpkg-deb from within debian/rules, bundling .buildinfo inside would require appending those from something called by dpkg-buildpackage.
- the .buildinfo file contains references to .deb archives (size and checksums), which would become wrong once the .buildinfo files have been bundled into the .deb archives. This would make a simple file comparison (or checksum comparison) not feasible anymore, and would require some kind of tool to unbundle the .buildinfo from the .deb archive (which goes against one of the stated original design principles).
- the .changes and the .buildinfo file would end up with inconsistent .deb archive references (one before the bundling the other after).
- all .deb archives from source packages would end up with the same .buildinfo which seems wasteful, although the .buildinfo files are not too big, and could end up compressed within an ar member.
- a .changes for a source-only upload would be unable to provide a .buildinfo file, which would be a regression.
- .udebs would not contain these given that they are size constrained. This would make udeb-only source packages not trackable as reproducible. Source packages generating .deb and .udeb would still make it possible to fetch the .buildinfo by downloading a .deb (if any was built for that arch) matching the arch_version of the .udeb.
- that the current deployment problem gets partially fixed, and we also get mirroring for free.
- that the .buildinfo information is always readily available for a .deb archive.
Some alternatives:
- there has been some talk about packing some build artifacts so that they are easier to disseminate after a build, such as build logs, or similar. Perhaps an alternative solution would be to automatically generate a new .deb that contains build artifacts such as (at least) .buildinfo and build logs). This though might still require infra changes for the archive, say to have something like the debug symbol packages archive. This would still seem somehow problematic for the source-only upload, as including a binary .deb with build artifacts might seem odd?