Including build metadata in packages
vagrant at reproducible-builds.org
Sat May 7 23:39:55 BST 2022
On 2022-02-14, Paul Wise wrote:
> On Sun, 2022-02-13 at 14:13 -0800, Vagrant Cascadian wrote:
>> * Split build metadata into a separate file or archive
>> Some of the debian-installer packages generate tarballs that are not
>> .deb files and are included in the .changes files when uploading to
>> the archive; making a similar generalized option for other packages to
>> put build metadata into a separate artifact might be workable approach,
>> although this would presumably require toolchain changes in dpkg and
>> dak at the very least, and might take a couple release cycles, which
>> is... well, debian.
> I already sent a mail like this in the past, but...
> This approach is already in use in the archive, but not
> yet for the kind of artefacts that you are talking about:
> https://salsa.debian.org/ftp-team/dak/raw/master/config/debian/dak.conf (search for AutomaticByHandPackages)
> https://salsa.debian.org/ftp-team/dak/raw/master/daklib/upload.py (search for byhand_files)
> I think this would not require anything except a new dak config stanza
> for AutomaticByHandPackage and potentially a patch to dak code or a
> script. Seems unlikely it would require changes to anything other than
> dak plus the packages that want to opt in to using it, so should be
> completely doable within the bookworm release cycle.
I took a peek at this approach finally, and it looks like binutils would
be relatively trivial to support, but things like gcc-11, gcc-N would
need regular intervention from ftpmasters (unless some sort of pattern
matching rules were added). At least, one more step for the NEW
processing to consider...
> If you want to have some way to automatically download the data, then
> something like apt-file and Contents files could be done, I expect that
> would also be able to be done for the bookworm release and also be
> possible to put in bullseye-backports.
> You could even include all the build logs and build info in the same
> data set, and potentially modify the package build process so that
> build logs for maintainer built binaries end up there too.
> Something like this would be my suggested archive structure:
> Release -> Builds-amd64 -> foo_amd64.build
> \ \-> foo_amd64.buildinfo
> \--> foo_amd64.buildmeta.tar.xz
> Or since the buildinfo files are similar to Packages/Sources stanzas:
> Release -> BuildLogs-amd64 -> foo_amd64.build.xz
> \ \-> BuildInfo-amd64
> \--> BuildMeta-amd64 -> foo_amd64.buildmeta.tar.xz
> This could be in the main archive, or a separate debian-builds archive.
For reproducible builds, this doesn't actually end up being very
different from just shipping a FOO-unreproducible.deb, as reproducible
builds tests would still have to exclude FOO_ARCH.buildmeta.tar.xz from
the comparisons anyways, if they end up being listed in the .changes
(and .buildinfo?) files.
Though, it does open the door to other possibilities. Putting all the
.buildinfo files in this buildmeta.tar.xz would finally get in-archive
distribution of .buildinfo files, which would be very nice...
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 227 bytes
Desc: not available
More information about the Reproducible-builds