The support of SOURCE_DATE_EPOCH added in pdftex/dvipdfm-x is great, and
does a very good job at building reproducible binary software packages.
SOURCE_DATE_EPOCH allows to fix the metadata timestamps in the compiled
document, and when SOURCE_DATE_EPOCH_TEX_PRIMITIVES is set to 1, the tex
primitives \year, \month etc. are also fixed, so that for example \today
refers to the date given by SOURCE_DATE_EPOCH.

The SOURCE_DATE_EPOCH environment variable is always used to get
reproducible builds, and in this context,
SOURCE_DATE_EPOCH_TEX_PRIMITIVES is always set to 1. This is fine when
working with tex documents only. However in a more general context, for
example debian reproducible build effort [1] (which has equivalents for
other distributions [2]), the need to set another tool-specific
environment variable has been criticized: adding such tool-specifc
envvar handling in general package-building tools is considered to be
endless and so discarded.

Therefore, I would like to support a solution where the default value of
SOURCE_DATE_EPOCH_TEX_PRIMITIVES is set to to 1. It has already been
mentioned by Norman Gray [3]. The only drawback is that we brake
backward-compatibility in a situation where someone already uses
SOURCE_DATE_EPOCH for another task, and don't set
SOURCE_DATE_EPOCH_TEX_PRIMITIVES. In this situation, the default value 0
of SOURCE_DATE_EPOCH_TEX_PRIMITIVES allows this user to get the same
content in the compiled document. I do think this situation is very

Another solution is to drop SOURCE_DATE_EPOCH_TEX_PRIMITIVES as if it is
always set to 1, but I understand that it has to be kept if someone
thinks it can be useful.

Whatever will be your answer, I thank you again for your welcome
regarding reproducibility questions.

Alexis Bienvenüe.

[1] https://wiki.debian.org/ReproducibleBuilds/
[2] https://reproducible-builds.org/
[3] https://www.tug.org/pipermail/tex-k/2016-May/002703.html

Reproducible-builds mailing list

Reply via email to