(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

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 

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 


GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE

Attachment: signature.asc
Description: OpenPGP digital signature

Reproducible-builds mailing list

Reply via email to