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
