(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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
