Sometimes build tools embed into the output. This causes the build to be unreproducible when .
There are different reasons why this is done, most commonly . However, we have never seen nor do we foresee a reasonable use-case where the actual is needed; all the use-cases we have seen, would equally be satisfied by using the . This has the additional benefit of giving reproducible build output.
In fact, it is already possible for upstream projects to do this. They could - as opposed to .
However in many cases, upstream projects are not the ones directly responsible for embedding this information into the build output - it is some intermediate build tool that does it, e.g. . So they (the upstream project) shouldn't have to implement this detection and then supply this information to that build tool, just to get reproducible build output. Therefore, we have chosen to define this standard.
This is a standard that defines an environment variable <<GetVal(ReproducibleBuilds/BuildPathProposal/Dict, envvar_name)>>, that distributions can implement centrally, and have build tools obey this in order to produce reproducible output even if the upstream project is not specifically aware of reproducible builds.
This minimises the work required across the whole software community, to achieve reproducible builds by default. However, it does add a tiny bit of complexity to specific build tools. So, before implementing this, you should go through the following checklist, to see if you can avoid implementing it:
Checklist: Do I really need to use this?
1. See if strip-nondeterminism will get rid of the difference for you, or if it's easy to add this functionality to it. If yes, then you don't need this variable. For example, .
2. See if you can patch the tool that generates this information, to simply not generate this information in the first place. If this is a good idea, then you don't need this variable. For example, .
3. See if you can patch the tool that generates this information, to use this specification to generate a reproducible value for this information, based on a standardised environment variable set centrally by your distribution. This is what this document is about.
4. See if you can patch the package that uses the tool, to give it some tool-specific options like CLI arguments or its own environment variables, to avoid generating this information in the first place. For example, . However, this should be avoided in favour of the above options, since you will have to do this for every package that uses the tool.