Uploads with conflicting buildinfo filenames

[Helmut Grohne]

Hello reproducible builds folks,

in the context of Debusine, we ran into an issue around the naming of
buildinfo files. Fundamentally, I hope we agree that buildinfo files are
not meant to be reproducible themselves as they include e.g. the precise
build date, build path and optionally a signature. Yet, their filenames
are quite reproducible.  In effect, if you perform several related
uploads (e.g. source and binary) you may end up with multiple .changes
files referencing the same .buildinfo filename with differing .buildinfo
content. That seems allright. A key aspect of reproducible builds is to
allow several buildinfo files to document how the same .deb came to be,
but the current naming scheme suggests conflicting filenames for such
rebuilds.

Let's have a bit of context. The wiki[1] has a section on naming them
and specifies a predictable scheme. This is followed by the tools in
widespread use (sbuild and dpkg). Later in the same page, an example is
given.

| The following file could be named e.g. fweb_1.62-12+b2_brahms-20120530114812.buildinfo:

At the very least, the wiki page is inconsistent with itself.

The naming was discussed[2] on the rb-general list in 2018 and there a
portion of randomness was suggested.

There also is a bug[3] about the inclusion of a binary buildinfo in a
source upload. It remains inconclusive as of now. Generally, I think
that including a .buildinfo in a source upload does pose an advantage.
As a developer, I can provide additional certification of the
reproducible .debs beyond what the buildds supply. Holger evidently
disagrees[4]. Am I the only one seeing an advantage in keeping
buildinfos with source-only uploads and calling that bug a feature?

A problem arises when you attempt to upload such a _source.changes
concurrently with an _amd64.changes to the same incoming directory.
Likewise, reprepro tends to include those files in its pool hierarchy
and there a similar naming conflict arises.

Having several buildinfo files for the same architecture is something
that we plausibly want to have eventually. Imagine running two sets of
buildds and assembling a single upload containing buildinfo files from
both buildds in the same upload. In a similar vein, as a developer I may
want to supply several buildinfo files with my source upload (e.g. for
multiple architectures). Doing any of this is incompatible with current
incoming processing and with reprepro.

Do you see this problem as something worth working on?

How about changing the buildinfo specification suggesting a different
naming pattern (yes, this was suggested earlier) that allows uniqueness
to be encoded into the filename?

Helmut


[1] https://wiki.debian.org/ReproducibleBuilds/BuildinfoFiles#File_name_and_encoding
[2] https://lists.reproducible-builds.org/pipermail/rb-general/2018-August/001103.html
[3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1105019
[4] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1105019#34