Re: On raw strings in <origin> commit field

[Liliana Marie Prikler]

Hi Mark,

Am Mittwoch, dem 29.12.2021 um 20:13 -0500 schrieb Mark H Weaver:
> 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".
I agree with you so far, though with some nuance.  Obviously, when
travelling back in time, we want Guix' "1.2.3" to be whatever it was by
that point, but on the other hand, we also want a recently pulled Guix
to have a reasonably recent "v1.2.3" if it claims to have "1.2.3".  So
we have two proposals at odds with each other, with only the origin-
hash to determine which interpretation to prioritize.

> 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.
And here I disagree.  This reasoning presupposes that we have to ensure
that the package still points to the same commit if the tag changes,
which itself presupposes that the tag does change.  However, if we are
always talking about more than one possible "1.2.3" (with the included
future tag that we have yet to witness), we lose the basis by which we
currently assign "1.2.3" as the version (instead of using git-version,
as we expect it won't be "1.2.3" at some future point).  This scheme
only makes sense when it doesn't make sense and when it doesn't make
sense it makes sense.

> 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.
As pointed out elsewhere, SWH keeps a history of the tags that we could
look up until one matches, and there'd also be the option to keep a
secondary index ourselves (or have a third party do it).

> 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.
To me, it rather sounds like a workaround for longstanding bugs [1, 2].
And then again it rests on the assumption that upstream does awful
things to their tags which makes no sense when it makes sense.

> > 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?
Which bug are you talking about?  "Tricking Peer Review" or the
fallback thing?  If it's the fallback thing, then that's an enabler for
Ricardo's approach, since as you pointed out the commit will still be
fetched correctly from SWH (if not from the main repo itself). 
Insufficient fallbacks are what make it painful to refer to moving
commit tags by tag, since our SWH lookup currently breaks when it
doesn't need to.  Having sufficient fallbacks would mean that we could
use git tags as we did before even in those cases, since the SWH (or
other) fallback would kick in and give us the historical version
matching our origin-hash.

Now, "Tricking Peer Review" is a harder thing to circumvent.  We would
need to issue a warning, preferably a big one if fallbacks do kick in
unintended, i.e. particularly outside of time-machine.

Cheers

[1] https://issues.guix.gnu.org/28659
[2] https://issues.guix.gnu.org/39575