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
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Reproducible-builds mailing list Reproducible-builds@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
