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... > > 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. 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... live well, vagrant
Attachment:
signature.asc
Description: PGP signature