guix-devel
[Top][All Lists]
Advanced

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

Re: On raw strings in <origin> commit field


From: Liliana Marie Prikler
Subject: Re: On raw strings in <origin> commit field
Date: Fri, 31 Dec 2021 04:27:14 +0100
User-agent: Evolution 3.42.1

Hi,

Am Freitag, dem 31.12.2021 um 02:23 +0100 schrieb 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. ;-)
To shorten it, we currently have the following problem: We can specify
the commit field by tag, which is not robust, by raw commit which is
confusing and can be misleading, or by let-bound commit with a special
version field, which is still confusing if we're at an epsilon revision
(epsilon meaning nothing changed since release and we're not expecting
change), but beats the first option in robustness and the second in
readability at the cost of having a funky version field.  I am arguing
that we should go with either option one or three, but never two.

> 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.
To be fair, you raise a good point with SWH not being infallible, so we
might want to have fallbacks that work regardless of it.  That being
said, we don't support git-mirrors yet either, do we?

> > 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
... 

Fine, I'mma quote flathub for a change.
> When building from a git tag, both the tag name and the commit id
> should be specified, like so:
> 
>    "tag": "1.0.4",
>    "commit": "cdfb19b90587bc0c44404fae30c139f9ec1cca5c"
It's almost as though they know a commit without a tag has no intrinsic
meaning.  Also, I'm pretty sure flatpak could care less about hashes if
asked to (unlike Guix, which requires you provide one to be granted
network access), so the optional by means other than policy SHA-1 hash
here is not comparable to the required SHA-256 hash we always have.

Also, even if we do decide to sacrifice readability for the greater
reproducibility, I think this approach is especially hostile to the
future reader in the very case it is concerned about.  For all they
know, this particular Guix package of version "1.0.4" could have had
cosmetic changes applied, which were not at all cosmetic, but rather a
downgrade to 0.1.4.

Cheers



reply via email to

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