Including build metadata in packages

Paul Wise pabs at debian.org
Mon Feb 14 11:29:42 GMT 2022


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...

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=950585#30

This approach is already in use in the archive, but not
yet for the kind of artefacts that you are talking about:

https://codesearch.debian.net/search?perpkg=1&q=dpkg-distaddfile
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)
https://salsa.debian.org/ftp-team/dak/tree/master/scripts/debian/

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.

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.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <http://alioth-lists.debian.net/pipermail/reproducible-builds/attachments/20220214/a254bd78/attachment.sig>


More information about the Reproducible-builds mailing list