Moving towards a deb-buildinfo(5) Format 1.0

[Guillem Jover]

Hi!

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
  cleanup branch).

* 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
  former.

* 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. :)

Thanks,
Guillem