Re: On raw strings in <origin> commit field

[zimoun]

Hi Liliana,

I have read all your emails a couple of times and I am sorry I am still
missing what you are raising.  Because I feel we are failing to explain
each other, that’s fine, it happens sometimes :-) I hope others will
find the intersection of this discussion.

Honestly I am lost in the middle of somewhere between affine space and
Cantor’s diagonal argument. ;-)


I agree with this statement:

    >> SWH records the “history of the history”.  It can tell you what the
    >> tag pointed to at the time of a specific snapshot.
    This just reiterates my point of Guix not trying hard enough with
    fallbacks.

and in my views, the path to robustify the fallback is via more
immutable content-address and intrinsic values and less mutable broken
string as URL+tag.  Obviously, 1) all is not white or black and many
things are grey as always and 2) we have to deal with this broken world
of URL+tag, thus I hope we will improve the fallback SWH through various
snapshots instead of considering only the last one.

However consider that SWH is an archive, not a forge or a mirror.  It
means that SWH ingests this or that only every X months.  Therefore, you
have no guarantee that the snapshots represents the complete history of
history.

For sure, upstream can remove some commits between two ingestions.  But,
most of the time, commits (history) are kept and the bad practise is to
just move the pointer (tag) from one commit to another.


> I'mma quote Ludo for a change.

And for completeness, let quote Ludo again from the same thread. :-)

        No, I think we should consider always referring to commits
        instead of tags.  It’s annoying from a readability viewpoint,
        but it would ensure reproducibility.  Even flatpak has this
        policy.  :-)

          https://github.com/flathub/flathub/wiki/App-Requirements

<https://yhetil.org/guix/87mtmr2a3t.fsf_-_@gnu.org/>


Cheers,
simon