unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Mark H Weaver <mhw@netris.org>
To: Liliana Marie Prikler <liliana.prikler@gmail.com>, guix-devel@gnu.org
Subject: Re: On raw strings in <origin> commit field
Date: Wed, 29 Dec 2021 20:13:24 -0500	[thread overview]
Message-ID: <87k0fm7v3k.fsf@netris.org> (raw)
In-Reply-To: <6e451a878b749d4afb6eede9b476e5faabb0d609.camel@gmail.com>

Hi Liliana,

Liliana Marie Prikler <liliana.prikler@gmail.com> writes:
> It should be noted, that in the case of moving or deleted tags, the
> assertion Guix "1.2.3" = upstream "v1.2.3" no longer holds.

Agreed, but I don't think that assertion should be our top priority.

For purposes of Guix's core goal of enabling software to be reliably
reproduced in the future, the most important property to preserve is
that 'Guix "1.2.3"' should remain forever immutable.

An obvious corollary is that if upstream mutates the meaning of
'upstream "v1.2.3"' over time, then the equation above will become
false.  That would be an unfortunate result of upstream's actions, but
it's exactly what _needs_ to happen to enable Guix to be reliably
reproducible.

If I perform an experiment with Guix "1.2.3" and publish the results,
and someone later wishes to reproduce those results, they will want
precisely the same 'Guix "1.2.3"' that was used to perform the original
experiment, and not whatever version of the software upstream is now
calling "v1.2.3".

The simple fact is that the way Ricardo wrote the 'guile-aiscm' package
is the right way to ensure that it can be reliably reproduced in the
future.

Guix packages that refer to git _tags_ may cease to be reproducible in
the future if upstream mutates or removes those tags, and it's simply
not feasible to transform our SHA256 hashes (of the NAR-encoded source
checkout) into something that we can use to fetch the archived source
from SWH.  There's simply no hope to make that work, unless we can
convince SWH to maintain a secondary index of their content based on
NAR-encoded source trees, which seems unlikely.

On the other hand, if we refer to git _commit hashes_, then it *is*
feasible for us to fetch the archived source from SWH, regardless of
what upstream has done to its tags in the meantime.

For that reason alone, I think that the way Ricardo wrote the
guile-aiscm package definition is clearly the right approach, given
Guix's longstanding goals.

> On the note
> of fallbacks, we do also have the issue that Guix fails on the first
> download that does not match the hash instead of e.g. continuing to SWH
> to fetch an archive of the old tag (as well as other fallback-related
> issues, also including the "Tricking Peer Review" thread).

That's a bug that can, and should, be fixed.  The existence of that bug
might temporarily prevent us from enjoying the benefits of Ricardo's
approach, but that's not an argument for adopting practices that push us
farther from our core goals.

What do you think?

      Regards,
        Mark

-- 
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about <https://stallmansupport.org>.


  parent reply	other threads:[~2021-12-30  1:14 UTC|newest]

Thread overview: 63+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-28 20:55 On raw strings in <origin> commit field Liliana Marie Prikler
2021-12-29  8:39 ` zimoun
2021-12-29 20:25   ` Liliana Marie Prikler
2021-12-30 12:43     ` zimoun
2021-12-31  0:02       ` Liliana Marie Prikler
2021-12-31  1:23         ` zimoun
2021-12-31  3:27           ` Liliana Marie Prikler
2021-12-31  9:31             ` Ricardo Wurmus
2021-12-31 11:07               ` Liliana Marie Prikler
2021-12-31 12:31                 ` Ricardo Wurmus
2021-12-31 13:18                   ` Liliana Marie Prikler
2021-12-31 13:15               ` zimoun
2021-12-31 15:19                 ` Liliana Marie Prikler
2021-12-31 17:21                   ` zimoun
2021-12-31 20:52                     ` Liliana Marie Prikler
2021-12-31 23:36         ` Mark H Weaver
2022-01-01  1:33           ` Liliana Marie Prikler
2022-01-01  5:00             ` Mark H Weaver
2022-01-01 10:33               ` Liliana Marie Prikler
2022-01-01 20:37                 ` Mark H Weaver
2022-01-01 22:55                   ` Liliana Marie Prikler
2022-01-02 22:57                     ` Mark H Weaver
2022-01-03 21:25                       ` Liliana Marie Prikler
2022-01-03 23:14                         ` Mark H Weaver
2022-01-04 19:55                           ` Liliana Marie Prikler
2022-01-04 23:42                             ` Mark H Weaver
2022-01-05  9:28                               ` Mark H Weaver
2022-01-05 20:43                                 ` Liliana Marie Prikler
2022-01-06 10:38                                   ` Mark H Weaver
2022-01-06 11:25                                     ` Liliana Marie Prikler
2022-01-02 19:30                   ` zimoun
2022-01-02 21:35                     ` Liliana Marie Prikler
2022-01-03  9:22                       ` zimoun
2022-01-03 18:13                         ` Liliana Marie Prikler
2022-01-03 19:07                           ` zimoun
2022-01-03 20:19                             ` Liliana Marie Prikler
2022-01-03 23:00                               ` zimoun
2022-01-04  5:23                                 ` Liliana Marie Prikler
2022-01-04  8:51                                   ` zimoun
2022-01-04 13:15                                     ` zimoun
2022-01-04 19:45                                       ` Liliana Marie Prikler
2022-01-04 19:53                                         ` zimoun
2021-12-31 23:56         ` Mark H Weaver
2022-01-01  0:15           ` Liliana Marie Prikler
2021-12-30  1:13 ` Mark H Weaver [this message]
2021-12-30 12:56   ` zimoun
2021-12-31  3:15   ` Liliana Marie Prikler
2021-12-31  7:57     ` Taylan Kammer
2021-12-31 10:55       ` Liliana Marie Prikler
2022-01-01  1:41     ` Mark H Weaver
2022-01-01 11:12       ` Liliana Marie Prikler
2022-01-01 17:45         ` Timothy Sample
2022-01-01 19:52           ` Liliana Marie Prikler
2022-01-02 23:00             ` Timothy Sample
2022-01-03 15:46           ` Ludovic Courtès
2022-01-01 20:19         ` Mark H Weaver
2022-01-01 23:20           ` Liliana Marie Prikler
2022-01-02 12:25             ` Mark H Weaver
2022-01-02 14:09               ` Liliana Marie Prikler
2022-01-02  2:07         ` Bengt Richter
2021-12-31 17:56 ` Vagrant Cascadian
2022-01-03 15:51   ` Ludovic Courtès
2022-01-03 16:29     ` Vagrant Cascadian

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87k0fm7v3k.fsf@netris.org \
    --to=mhw@netris.org \
    --cc=guix-devel@gnu.org \
    --cc=liliana.prikler@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).