[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Set FORCE_SOURCE_DATE=1 by default
From: |
Maxim Cournoyer |
Subject: |
Re: Set FORCE_SOURCE_DATE=1 by default |
Date: |
Wed, 22 Jun 2022 09:59:18 -0400 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/28.1 (gnu/linux) |
Hi,
Vagrant Cascadian <vagrant@reproducible-builds.org> writes:
> On 2022-06-21, Maxim Cournoyer wrote:
>> Vagrant Cascadian <vagrant@reproducible-builds.org> writes:
>>> So, guix sets SOURCE_DATE_EPOCH=1 by default in
>>> guix/build/gnu-build-system.scm, which is great!
>>>
>>> This allows guix packages in many cases to build packages reproducibly,
>>> with a curious side-effect that takes us all back to the early 70s in
>>> some corner-cases (or even late 60s, dependent on timezone).
>>>
>>> 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'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 get it. I really do. It kind of grates at me every time I think about
> this.
>
> I know it really is not great and seems quite suboptimal to me, but I
> don't personally think rehashing the arguments will be a productive use
> of time for anyone...
>
> 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. Even reproducible-builds.org
discourage its use (directed at upstream rather than downstream, but
still) [0]:
If for some reason you’re still conflicted on suddenly changing the
meaning of your “now()” function and desire another switch other than
SOURCE_DATE_EPOCH being set or not, the texlive project came up with the
variable FORCE_SOURCE_DATE; when that environment variable is set to 1
cases that wouldn’t normally obey SOURCE_DATE_EPOCH will do. We strongly
discourage the usage of such variable; SOURCE_DATE_EPOCH is meant to be
already a flag forcing a particular timestamp to be used.
It'd still be nice to have the link to the upstream discussion that led
using a FORCE_SOURCE_DATE variable mentioned in a comment above where
we'd do this trivial substitution; do you have a link to it? I couldn't
find it.
Thanks,
Maxim
[0] https://reproducible-builds.org/docs/source-date-epoch/
Time namespace for build sandbox (was Re: Set FORCE_SOURCE_DATE=1 by default), Zhu Zihao, 2022/06/22