Bug#876055: Environment variable handling for reproducible builds

[Russ Allbery]

Package: debian-policy
Version: 4.1.0.0
Severity: normal

Currently, Debian Policy requires all environment variables be held the
same across builds for the build to be expected to be reproducible.
However, the current approach of some reproducible build tools is to
instead enumerate a set of fixed environment variables and allow other
variables to vary.

We should ideally converge on a single approach to environment variables
and build reproducibility and make it easy for tools to implement that
approach.

I think the alternatives are:

1. Enumerate environment variables to hold fixed.  This is better in
   the sense that it allows packages to be reproducible under more
   situations, but it's unstable in the sense that we'll never be able to
   enumerate all environment variables that might possibly affect the
   build.  It's also not testable in the sense that we can't set every
   possible environment variable.

2. Set the entire environment to the environment specified in buildinfo
   when doing a reproducible build.  I think this is conceptually the
   simplest, but it means that we should make every tool that builds
   official Debian packages use the same environment variable logic so
   that the buildinfo file completely captures the environment (without
   leaking random, inappropriate things into buildinfo).  It also means
   effectively giving up on debian/rules build being a path for making a
   reproducible build, since we don't have control over that environment,
   but I think it will be hard to make that work anyway.

3. List a set of environment variables that are permitted to vary in the
   reproducible build policy, and then have reproducible builds clean the
   environment except for that set and then apply the buildinfo environment
   variable set.  This is very similar to 2.  I think the primary advantage
   is that it lets us require packages build reproducibly in the presence
   of some settings that logically should not affect the build (USER, HOME,
   etc.), at the cost of making reproducible builds harder to achieve.
   It's mostly testable, in that one can try reproducible builds with
   various settings for those variables, although it would be hard to catch
   corner cases where only a specific setting causes issues.

I personally lean towards 2, which is consistent with what's in Policy
right now, but I can see definite merits in 3.  I believe the reproducible
builds project is currently sort of doing 1, but I have a hard time seeing
how to make that viable on the testing side.

-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (990, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.12.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages debian-policy depends on:
ii  libjs-sphinxdoc  1.6.3-2

debian-policy recommends no packages.

Versions of packages debian-policy suggests:
pn  doc-base  <none>

-- no debconf information