guix-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug#49517] [PATCH] gnu: txr: Build documentation and update to 265.


From: Kaz Kylheku
Subject: [bug#49517] [PATCH] gnu: txr: Build documentation and update to 265.
Date: Mon, 19 Jul 2021 14:31:15 -0700
User-agent: Roundcube Webmail/0.9.2

On 2021-07-19 05:08, Guillaume Le Vaillant wrote:
So Debian indeed has a patch adding the possibility to set the timestamp based on SOURCE_DATE_EPOCH (see '2010_add_build_timestamp_setting.patch'
in [1] for example).

Looks like they rolled out this patch into production in 2015.

Is there a reason why Guix can't just steal the Debian patches
related to reproducibility? (Like underlying differences it the overall
approach which lead to incompatibilities?)

It would probably be best if distros did this the same way, so
there are no surprises.

GNU/Linux could set a precedent for other platforms, even.
If I'm building something on, say, Cygwin, OpenBSD or MacOS, if the
reproducbility stuff works the same way like on GNU/Linuxes, that's
great.

Here is a powerful argument why Just One Way of doing it is better:

Distros should not be carrying patches for this in the first place;
the programs themselves should be upstreaming the changes for
reproducibility.

If there is an agreed-upon /de facto/ (or /de jure/) standard way
of doing it, it is easier to persuade the individual program developers to
accept the changes. They have a single target to hit which covers
all platforms.

In contrast, if reproducibility is an /ad hoc/ OS-and-distro-specific
matter, they are going to be understandably less motivated to upstream
the changes.

Nobody wants a situation in their source tree like:

  patches/for-debian
         /for-guix
         /for-solaris
         ...

Just one implementation, committed into trunk, with with no #ifdefs.





reply via email to

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