Differences between revisions 4 and 5
Revision 4 as of 2020-08-31 12:30:06
Size: 3395
Editor: GuillemJover
Comment: Update metadata and minor wording changes
Revision 5 as of 2020-08-31 20:30:13
Size: 3691
Editor: ?VagrantCascadian
Comment: some additional comments
Deletions are marked like this. Additions are marked like this.
Line 21: Line 21:
  * 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.
  * 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). (if the checksum and size and build date were removed, it might be possible to make the embedded .buildinfo reproducible)
  * the .changes and the .buildinfo file would end up with inconsistent .deb archive references (one before the bundling the other after). (unless produced artifacts are removed from embedded .builinfo)
  * all .deb archives from source packages would end up with the same .buildinfo (per architecture) 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. (could still ship an external .buildinfo as done now in addition to embedded .buildinfo)
Line 32: Line 32:
  

  • 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 that:

  • 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). (if the checksum and size and build date were removed, it might be possible to make the embedded .buildinfo reproducible)
  • the .changes and the .buildinfo file would end up with inconsistent .deb archive references (one before the bundling the other after). (unless produced artifacts are removed from embedded .builinfo)
  • all .deb archives from source packages would end up with the same .buildinfo (per architecture) 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. (could still ship an external .buildinfo as done now in addition to embedded .buildinfo)
  • .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.
  • the current deployment problem gets partially fixed, and we also get mirroring for free.
  • 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?


CategorySpec