binutils-dev: included log files introduce reproducibility issues

[Chris Lamb]

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
     `. `'`      lamby at debian.org 🍥 chris-lamb.co.uk
       `-