Moving towards a deb-buildinfo(5) Format 1.0
As I've mentioned elsewhere, I've noticed several things with the
current .buildinfo format, even after the cleanup pre-merge, that
I'd like to fix or change so that we can hopefully reach Format 1.0.
Some of the issues, that bother me:
* .buildinfo files are not currently signed
I just need to do that, but given that this is not final I didn't
see it as a big problem when I noticed just after the first release
introducing this. Ximin also filed #843925 about this later on.
* .buildinfo filename
Having the buildinfo filename be derived from its contents and the
current date is annoying and makes finding it more difficult, as you
have to scan the .changes file if it's around, but cannot link it
directly otherwise. It also leaves dangling files around when building
the same package multiple times, just because the date increases. If
we have already established that the .buildinfo contents will vary
across different builders anyway, which means the .changes files
contents will too, I don't see why we need to distinguish the
.buildinfo filename generation from the .changes filename.
So I'd probably prefer to use the same algo as used for .changes
filename generation. And move the build date inside the .buildinfo
file in a Build-Date field or similar (as I had for some time on my
* dpkg-genbuildinfo injects itself into debian/files
I still tend to think this is the right way to do it (instead of
letting dpkg-buildpackage add the entry). But this can cause issues
when running it multiple times, but it does not cause them (or
should not), with a stable filename, so fixing the above would cover
this one too.
* .buildinfo files are not generated when creating source-only uploads
I should probably check the exact conditions, but it might be worth
including a .buildinfo file if it exists and is in debian/files, even
when doing something like:
$ dpkg-buildpackage -us -uc --change-option=-S
because then we could "be sure" the maintainer built something. :)
* .buildinfo has some issues when including .dsc information
Only the .dsc file is referenced not all of its contents, it might
be better to match .changes logic here. Also the “source”
pseudo-architecture does not get added to the Architecture field.
I'll just do at least the latter, I'm open for discussion on the
* Some of the environment variables seem superfluous or leaks
Several of the envvars are either always set by dpkg-buildpackage
anyway (like SOURCE_DATE_EPOCH, although the user might have set it
explicitly and that will be honored), or should be irrelevant for
the reproducible build, as we should be fixing packages to make them
impervious to change in their values (LANG, LC_* etc). Some of which
kind of leak information about the build system.
I'm not extremely fussed about this point though, because this might
still be interesting information to record, but only as long as it
does not leak possibly sensitive build system information. Locales
used might be too revealing perhaps. But then reportbug and similar
leak this and much more so, dunno.
I'll probably do some of the fixes already and bump Format to 0.2
and after the discussion settles we can perhaps do a 0.3, and see how
it goes, and iterate until it looks good, at which point we'd declare
it 1.0, ideally before the freeze. :)