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.
