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
