[tex-k] [Reproducible-builds] SORCE_DATE_EPOCH_TEX_PRIMITIVES

[Ximin Luo]

(I ask that everyone spend some undisturbed and unpressured time to read and digest what I'm about to write. Hopefully this way we can avoid unnecessary redundant replies that don't contribute new information and only risk adding fuel to any potential flamewars.)

Alexis Bienvenüe:
> Therefore, I would like to support a solution where the default value of
> SOURCE_DATE_EPOCH_TEX_PRIMITIVES is set to to 1.

If I understand correctly, tex-k are pointing out that there is a semantic difference between:

1. implicit timestamps in .tar/.pdf that nobody explicitly told tar/pdf to write
2. explicit calls to time()-equivalents in Turing-complete languages, such as \today in TeX

Yes, we did not explore this issue in enough depth when we originally wrote the SOURCE_DATE_EPOCH spec. Indeed, #2 is exactly why we don't simply patch time(2) ourselves in glibc and be done with it - it does indeed break some use-cases of Turing-complete languages. For example it breaks make(1) which is a very important part of our build ecosystem. I can understand being cautious, when you are parsing a Turing-complete language where #2 *might* have unsafe corner-cases; you don't want to potentially break things that are time-sensitive.

However, in the scenarios that are relevant to PDF generators, we at R-B believe that #2 is *always safe* . Even if your input-language is Turing-complete, whenever you are generating some output data from some input data in a build process, *this should not be time-sensitive or require a "real" clock*. In other words, even if TeX-as-a-general-programming-language may need to be cautious about how it interprets \today, in the context of parsing-a-TeX-file-to-generate-PDFs, this cautiousness is unnecessary and leads to overcomplexity.

Based on this reasoning, our current preferences for pdftex behaviour are:

# Proposal 0 ("ideal" solution for the R-B team)

Use SOURCE_DATE_EPOCH unconditionally for case #2 [*], for the reason in the previous paragraph - i.e. that pdftex will never need to interpret \today in a time-sensitive context, even if TeX in general might need to do that.

[*] i.e. as well as case #1 which is uncontroversial

# Proposal 1

Default SOURCE_DATE_EPOCH_TEX_PRIMITIVES to 1 as Alexis suggested, so that case #2 defaults to honouring SOURCE_DATE_EPOCH, and people doing reproducible builds don't need to learn a new flag/envvar for every new tool.

To allow time-sensitive TeX programs to safely handle corner cases arising out of case #2, you can do it like this:

a. the tex interpreter libraries could have an internal "use-SDE-as-\today" option that defaults to being "no"
b. the pdftex *program* knows that it is using TeX purely in a document-building context which is *not* time-sensitive, and can set this internal option as "yes" by default, even if SOURCE_DATE_EPOCH_TEX_PRIMITIVES is not present. If the user set SOURCE_DATE_EPOCH_TEX_PRIMITIVES=0 explicitly, then it can set the internal option back to "no".

# Proposal 2

If you are unwilling to have case #2 above use SOURCE_DATE_EPOCH by default, then my suggestion is to rename SOURCE_DATE_EPOCH_TEX_PRIMITIVES to a more generic name like USE_CLOCK_SOURCE_DATE.

This is just my personal preference and we the R-B team haven't reached consensus on this yet. My motivation for this name is that it mirrors the POSIX clock id constants CLOCK_REALTIME, CLOCK_MONOTONIC etc. You can read it colloquially as "use CLOCK_SOURCE_DATE [instead of CLOCK_REALTIME]", where CLOCK_SOURCE_DATE can be thought of as a fake constant clock that always returns SOURCE_DATE_EPOCH. (Of course this is not actually in the POSIX standard, but the other clocks are.)

For more context see `man 2 clock_gettime` or http://pubs.opengroup.org/onlinepubs/009695399/functions/clock_getres.html.

X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
git://github.com/infinity0/pubkeys.git

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <http://tug.org/pipermail/tex-k/attachments/20160515/184af481/attachment.bin>