On 2022-06-22, Maxim Cournoyer wrote:
> Vagrant Cascadian <vagrant@reproducible-builds.org> writes:
>> On 2022-06-21, Maxim Cournoyer wrote:
>>> Vagrant Cascadian <vagrant@reproducible-builds.org> writes:
>>>> That said, some projects (such as texlive) might be worried about
>>>> messing with time too much (I get it, lots of cautionary sci-fi
>>>> stories!), and so you *also* need FORCE_SOURCE_DATE=1 to be set in order
>>>> to respect SOURCE_DATE_EPOCH.
>>>
>>> That seems ridiculous.  Has anyone tried getting in touch with them to
>>> get their arguments about why inventing another variable that means the
>>> same thing was necessary?
>>
>> Yes, there were some fairly long threads about it and I have little hope
>> that revisiting it would change much; it was originally implemented as a
>> texlive specific variable, which was changed to the FORCE_SOURCE_DATE
>> variable to at least avoid the danger of every project inventing their
>> own name-brand variables...

I have tracked it down to these threads:

  https://www.tug.org/pipermail/tex-k/2016-May/thread.html#2691
  https://www.tug.org/pipermail/tex-k/2016-May/thread.html#2712
  https://www.tug.org/pipermail/tex-k/2016-June/thread.html#2721


>>> I'd much prefer challenging that stance than "endorsing" it in Guix :-).
>>> I think it'd be OK to reluctantly add it in as a stop-gap fix in Guix,
>>> but *only* after opening an issue to discuss it upstream and linking to
>>> that issue in Guix.
...
>> I think the pragmatism of making more packages reproducible by conceding
>> to set FORCE_SOURCE_DATE is the appropriate way forward; I agree it
>> feels silly or even maybe would go so far as to say a bit "wrong".
>
> Perhaps to show our stand here we could patch our copy of pdftex with
> 's/FORCE_SOURCE_DATE/SOURCE_DATE_EPOCH/', lest we end up with a grocery
> list of *SOURCE_DATE* variable variants.

Sure, with some technical details fixed up, as I think they are
functionally different, in that FORCE_SOURCE_DATE is a boolean, and
SOURCE_DATE_EPOCH is an integer, though ... Guix sets
SOURCE_DATE_EPOCH=1 ... so it might just work by dumb luck! Though There
may be some rare packages that need SOURCE_DATE_EPOCH to be some larger
value...  "It can't possibly be 1970, this program was first written in
2002, there must be some error, failing build..."

At any rate, if diverging from upstream Tex Live is how Guix wants to
handle this, I'm all for it!

live well,
  vagrant