pado at passoire.fr
Sun May 15 15:14:41 CEST 2016
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  (which has equivalents for
other distributions ), 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 . 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.
More information about the tex-k