Bug#869184: dpkg: source uploads including _amd64.buildinfo cause problems

[Francesco Poli]

On Mon, 08 Jul 2019 16:39:30 -0700 Vagrant Cascadian wrote:

> On 2019-07-09, Francesco Poli wrote:
[...]
> > Maybe it's a naive question: what's the use of including a .buildinfo
> > file into a source-only upload? Is it superfluous?
> 
> It's an attestation from the uploader that they built the package, what
> the hashes of their build are, and the build environment used to produce
> those binary packages. If there are differences between the buildd build
> of the package and the uploader's build of the package, it may be
> possible to compare the results.
[...]
> 
> This is certainly desireable from a reproducible builds perspective.

I see: this makes perfect sense, sure.
Thanks a lot for the clear explanation!

[...]
> > Would it be better, if dpkg-genchanges completely refrained from
> > including .buildinfo files into source-only .changes files?
> 
> Or calling the .buildinfo by a different name, e.g. source.buildinfo or
> source-arch.buildinfo, etc.

Maybe an alternative strategy could work as follows:

 • dpkg-genchanges should continue to do exactly what it currently does

 • the autobuilders should rename their own .buildinfo files on the fly,
   to something like package_version_arch-buildd.buildinfo

This way, we could avoid name clashes, without the need to fix the
tools used by all the people who upload packages...

Could this strategy be the way to go?
Does it have any important drawback?


-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
..................................................... Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/reproducible-builds/attachments/20190709/28e646af/attachment.sig>