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

[Guillem Jover]

On Thu, 2018-03-01 at 15:22:30 +0000, Holger Levsen wrote:
> On Wed, Jan 24, 2018 at 04:05:39PM +0100, Salvatore Bonaccorso wrote:
> > Any news regarding this proposal from Ansgar? We were biten now
> > several times already by this (e.g. php update, curl via
> > security.d.o).
> 
> Guilem, what's your stance on this bug?

I think it should be fixed. I've just not come up with something that
would seem a generic/clean way to do that. :(

> We (reproducible builds) really dont want "our" tools (=.buildinfo files)
> to cause grief to other teams in Debian, and especially not on a regular
> basis... so as a first step to fix this, I'd like to collect opinions
> how to best fix this issue here.

The problem got introduced when I proposed changing the filename
format, and dropping the annoying timestamp. I also though there was
talk at some point initially about DAK renaming those files to cope
with possible multiple uploads if the conflicting names?

Renaming the arch buildinfo to _source.buildinfo seems wrong, and even
then I'm not sure how to cleanly transfer that knowledge from
dpkg-buildpackage to dpkg-genbuildinfo.

I guess, the ideal solution would be to qualify the buildinfo file
with the builder user and hostname, because that in a way denotes the
build environment. But that seems like too much leakage. As in:

  pkgfoo_1.0.0-1_mips64el_username at hostname.buildinfo

Perhaps just using the maintainer email address might be enough though,
the one from the -m option or from the changelog, which AFAIR buildds
do set? But this seems like it can produce quite ugly filenames:

  pkgfoo_1.0.0-1_mips64el_buildd_mipsel-mipsel-sil-01 at buildd.debian.org.buildinfo

not to mention that both of these "break" the conventional pattern, which
is still used by things like the debian/files parser and injector.

Perhaps the simplest and more correct might be to name it using
something like source+amd64 as the arch name, which seems like a
dubious arch, but at least is accurate and might be trivial to
implement, taking care of not ending up with such fake arch in
unexpected places…

Thanks,
Guillem