unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Liliana Marie Prikler <liliana.prikler@gmail.com>
To: zimoun <zimon.toutoune@gmail.com>, guix-devel@gnu.org
Subject: Re: On raw strings in <origin> commit field
Date: Fri, 31 Dec 2021 04:27:14 +0100	[thread overview]
Message-ID: <9a5e3e7f44155146d731dd5a97450a9ff9dff5ab.camel@gmail.com> (raw)
In-Reply-To: <86k0flpnx5.fsf@gmail.com>

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	other threads:[~2021-12-31  3:32 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 [this message]
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
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=9a5e3e7f44155146d731dd5a97450a9ff9dff5ab.camel@gmail.com \
    --to=liliana.prikler@gmail.com \
    --cc=guix-devel@gnu.org \
    --cc=zimon.toutoune@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).