Hi Paul, > There is already the BYHAND (and automatic BYHAND) mechanisms for files > that get installed outside of pool/ in the Debian apt repository. Each > one needs support from dak too though. [..] > It strikes me that these files are most similar to .buildinfo or the > build logs in that they are data *about* the builds. I've wanted > maintainers to be able to also upload build logs with their binary > builds and started a WIP patch for that.
My gut feeling is that this is the avenue we want to explore. Having a separate mechanism to capture this build-specific metadata would be an elegant solution and, as you imply, having the logs would have QA advantages as well as permit reproducible builds. The system could be generic enough for future use-cases that we cannot envisage too. > The other option would be to put the files in a test results .deb file, > but that would still mean repro-builds folks would compare them, unless > there were a naming convention that could be used to ignore them. This sort of thinking always makes me a little uneasy. We have taken great pains over the years that no special knowledge, tools or tricks are required to compare the artifacts of a Debian build with respect to reproducibility. All you need right now is sha1sum(1) or any cmp(1)-like command-line tool. This is partly due to aesthetics but I have further observed that distributions and platforms that have not adopted this fail-safe approach are always at a marked disadvantage. This would appear to be a superficial niggle, but it makes a huge difference in mindset with many 1st and 2nd effects. Best wishes, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org 🍥 chris-lamb.co.uk `-