[tex-k] Reproducible builds using pdftex

[Alexis Bienvenüe]

> Beyond that, I can imagine, at least in theory, that a document might
> look at (not typeset) the value of \year etc. for some reason, and want
> to get its current value, even while using SOURCE_DATE_EPOCH to get a
> reproducible build.  After all, many manuals do not typeset \today.

The SOURCE_DATE_EPOCH envvar is designed to be used only in the context
of reproducible builds. In this context, if a document uses \year in
some way (not only typesetting it) that does change the result, we must
either modify the document itself to fix its behavior, either use
SOURCE_DATE_EPOCH_TEX_PRIMITIVES to fix \year's behavior. So I think
there can't be any case where we will want to set SOURCE_DATE_EPOCH but
not SOURCE_DATE_EPOCH_TEX_PRIMITIVES.

That said, I think that SOURCE_DATE_EPOCH_TEX_PRIMITIVES _is_ a solution
that covers our needs.

> tinkering with \year etc. is
> subverting the stated intention of the document authors

Producing the document in a version that corresponds to the author's
wish for the date the sources were last modified at don't seem disloyal
to me. Especially if we "date" this document with embedded PDF info
corresponding to SOURCE_DATE_EPOCH.

> In fact, I can see another argument that if you need to pretend it's
> three weeks ago, you should change the date on the system instead of
> expecting every application to cater to your desires.

Yes, but :
- we won't be able to get the same date/time at the time pdftex is
called, even if we set the time at the beginning of the building
process, because of eg. CPU differences.
- the goal is also to allow everyone to check easily that the binary
package is the exact result of the building process from the sources,
thus with as little change in the environment as possible.

Regards,
Alexis Bienvenüe.