Re: On raw strings in <origin> commit field

[Liliana Marie Prikler]

Hi,

Am Freitag, dem 31.12.2021 um 08:57 +0100 schrieb Taylan Kammer:
> On 31.12.2021 04:15, Liliana Marie Prikler wrote:
> >                                                   [...] 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". [...]
> 
> I think here lies the crux of the disagreement.  As far as I
> understand, Guix doesn't intend to support the notion that one
> version string could represent two different actual versions of a
> program throughout time.
It does not [intend ...], but the failure mode is important here,
particularly also for outside observers.  An outside observer seeing
that Guix uses commit deadbeef for "1.2.3" whereas upstream has
bedeadaf for the same might not know that upstream moved their commit
and given that committers can do much without oversight, they could
also sneak in a malicious deadbeef when upstream "1.2.3" was actually
d000000d all along.  If Ricardo had pushed to staging or core-updates,
that commit could have gone unnoticed for far longer (and just to be
sure, I do trust Ricardo to pick the right commit and would likely not
even bother checking if I was used to that scheme).

Seeing `guix build' fail because upstream hopped tags is frustrating
from a reproducibility angle, but it makes it somewhat easier to assign
blame and move forward.  Similarly, if we use git-version where we are
unsure if upstreams play nice, we never claim to package a canonical
"1.2.3", but a particular commit that advertises being "1.2.3" through
other means, such as configure files.  It would be obvious, that Guix
always packaged that commit.

> Rather, I think, the reason Guix keeps both the tag and commit ref is
> simply that the tag could disappear from the repo.  (In my
> experience, that's easy to do by accident when you clone a repo and
> push it to a new location.  You have to fetch and push the tags
> explicitly.)
Changing locations are not an issue here as we don't have git mirrors.

> If a tag ever *was* changed to point to a different commit, meaning
> that the same version string now represents a different actual
> version, then I think Guix would give that version a new name, such
> as "1.2.3-new" or whatever.  I don't know if this ever actually
> happened, but I think this is how Guix would probably want to deal
> with it if it does.  Having one string represent two different actual
> versions is just really terrible and I don't see Guix ever supporting
> such a practice.
Currently, Guix "supports" this practice by going from tags to (git-
version base revision commit), i.e. doing what you'd expect it to do. 
I think we did find a few badly behaving upstreams by virtue of using
tag and (hopefully) moved to git-version for all of those.

The alternative proposal would support this practice by not caring
about tags and let upstreams do as they please because they can't break
our tooling anyway, YOLO.  In a sense, we are trying to find technical
solutions to social issues here.

> [tangent follows]
> 
> (A software developer might argue that two different commits actually
> are the same version of the software, say for instance because only a
> minor change in the build system or README file or such was made,
> i.e. files that are considered "not part of the end-product," but in
> Guix land I think we wouldn't let that fare.  Maybe an exception
> would be made if it was proven that the actual package produced by
> Guix from both commits will always be bit-identical.  Even then,
> better not.)
If the documentation is included in the end product (which it hopefully
is), then yes, that hash would also change.  If you change your gitlab
CI yaml, because you typo'd hard and then the CI failed to build a
release tarball, I think we as Guix can see that this is a one time
thing while you're still young and move to the new commit.  If you do
it more often then yeah, no love from us.

> P.S. I hope I'm actually helping to add clarity to the thread instead
> of more confusion by adding my voice.  I was just skimming the ML,
> found this thread interesting, and thought I might be able to add
> clarity, because it seemed a little confusing. :-)
At least imo your opinion helps, as it also helps me formulating my own
ideas clearly.  If there's a particular thing you're confused about, do
not hesitate to ask :)

Cheers