Re: Bad interaction between pbuilder/debhelper/dpkg-buildinfo/dpkg-genchanges and dak on security-master

[Ian Jackson <ijackson@chiark.greenend.org.uk>]

Yves-Alexis Perez writes ("Bad interaction between pbuilder/debhelper/dpkg-buildinfo/dpkg-genchanges and dak on security-master"):
> However, I recently did that for an upload targeted at stretch-security, and
> unfortunately this caused a problem on security-master, where dak couldn't
> process the build by the amd64 autobuilder because an _amd64.buildinfo file
> was already present. It was part of my upload because it was included in the
> _source.changes file generated during the pbuilder run.

We had a related conversation on debian-dpkg recently.

There were some reasons discussed why publishing the uploader's
_ARCH.buildinfo, even of a source-only upload, may be useful to some
people.

However, given that the autobuilder's _ARCH.buildinfo actually
corresponds to the published binaries, that clearly must take
precedence.

So I think publishing the uploader's .buildinfo for
built-but-unpublished binaries requires being able to store and
reproduce multiple .buildinfo files for a single ARCH.

> So few questions:
> 
> - would it make sense to have a _source.buildinfo when building a package?

Separately, we discussed the nature of _source.buildinfo.  Currently
dpkg-genchanges will generate a _source.buildinfo if asked to make a
source-only .changes file.  I think this is usually wrong.

(And the fact that build-dependencies might affect the generated
_source package_ is a bug in our source code management systems.)

Perhaps we need to invent the concept of _source+ARCH.buildinfo or
something.

Ian.