guix-devel
[Top][All Lists]
Advanced

[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/



reply via email to

[Prev in Thread] Current Thread [Next in Thread]