unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Liliana Marie Prikler <liliana.prikler@gmail.com>
To: Mark H Weaver <mhw@netris.org>, guix-devel@gnu.org
Subject: Re: On raw strings in <origin> commit field
Date: Sun, 02 Jan 2022 00:20:39 +0100	[thread overview]
Message-ID: <b3bfa7b57b527d78aeb21dee6123c617a90fc13d.camel@gmail.com> (raw)
In-Reply-To: <87tuenky2x.fsf@netris.org>

Hi,

Am Samstag, dem 01.01.2022 um 15:19 -0500 schrieb Mark H Weaver:
> Hi Liliana,
> 
> Liliana Marie Prikler <liliana.prikler@gmail.com> writes:
> 
> > Am Freitag, dem 31.12.2021 um 20:41 -0500 schrieb Mark H Weaver:
> > > I disagree with the last line above.  What makes you think that
> > > I'm presupposing that the tag does change?
> > > 
> > > There's a difference between "presupposing that the tag does
> > > change" and "not assuming that the tag will not change".  Do you
> > > see the difference?
> > I'm pretty sure ¬assume(¬X) = assume(¬¬X) in this concept.
To correct my own typo here, I meant context, not concept.

> No, that's certainly false.  On the left-hand side of that equation
> there is an absence of any assumptions, and on the right-hand side
> there is the assumption that ¬¬X is true.
> 
> Perhaps something is getting lost in translation between our
> languages.
You are not a tabula rasa.  By the time you push a commit or even by
the time you submit it to the mailing lists, you have already made a
bunch of assumptions, some of them just more implicit than others. 
Assuming you care enough to make an informed use of the raw commit
pattern rather than just copying it from elsewhere, this holds even
more so.

> > > 
> > > > 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 
> > > 
> > > I see what you're getting at here, but still I disagree.  Our
> > > basis for associating version "1.2.3" with commit XYZ is simply
> > > that upstream had indicated that version "1.2.3" was commit XYZ. 
> > > That historical fact is immutable.
> > History is a social construct, it's not immutable.
> 
> I agree that /our knowledge of history/ is a social construct, and
> thus mutable, but that's not what I was referring to here.  I was
> referring to the facts of what /actually happened/ in the past, which
> is admittedly unknowable to us (especially in recent times).
We'd have to go into metaphysics in order to debate that and I'm sure
you could chase that rabbit hole to find an answer that works for
software version control, but at the same time we are dealing with an
even larger field of unanswered questions at that point and not making
any advancements to the problem we're actually trying to solve
whatsoever.

> > 
> > > If upstream later indicates that version "1.2.3" is now commit
> > > YYZ, I don't think that invalidates our basis for continuing to
> > > associate version "1.2.3" with commit XYZ.  The aforementioned
> > > immutable historical fact still remains our basis and
> > > justification for making that association.
> > I'm pretty sure it does, particularly to a future observer who may
> > not have the luxury of a history to distinguish that record from
> > one in which a malicious committer linked those versions and tag
> > together and then no one bothered to check.
> 
> It's a valid point.  However, your denial of the existence of any
> immutable historical facts (which is somewhat defensible) is starkly
> at odds with the fundamental principles of GNU Guix and its core
> goals.
> 
> I can understand your desire to have "FOO@1.2.3" in Guix correspond
> to the most recent announcement from the upstream FOO project on what
> they consider version "1.2.3" of their package to be.  This is
> obviously a desirable property for a package manager to have.
> 
> The problem is that it's incompatible with properties of Guix that I
> consider to be far more important.  I don't want the meaning of
> "FOO@1.2.3" in Guix to depend on what time it is when I ask the
> question.  I want it to mean the same thing tomorrow that it means
> today.  Reproducibility requires this.  It requires some notion of
> immutability.
> 
> I don't see how to reconcile Guix's core goals with your apparent
> goal of having "FOO@1.2.3" match upstream's latest idea of what
> "1.2.3" means to them, without abandoning the use of package version
> numbers in Guix altogether.
> 
> We might simply want different things from a package manager.
> De gustibus non disputandum est.
I think you are (intentionally or not) ignoring multiple key
assumptions here, that we can work with.  Some because we're dealing
with software, some because we're working with Guix.  For instance, the
assumption (you might call it "fact"), that Guix can identify an origin
by a combination of filename and hash.  Or the assumption that version
numbers are monotonically increasing and typically not reissued.

When you claim for a specific git-reference that you need to prepare
for the occasion of a tag being overwritten, you are making an
assumption that such an event will indeed take place in the future and
justifying your action based on said assumption.  When I claim "yeah,
GNOME has been around for more than twenty years and they're pretty
adamant about versioning", I am doing exactly the same.  However,
notice how from my assumption it logically follows – as long as said
assumption remains valid – that there exists a single release 41.0
which I can refer to (by tag), but from yours – again, as long as it is
valid – it follows that there is no single version N that you can refer
to by whatever commit you have.

Now what if I'm wrong?  If I am indeed wrong and GNOME 43 is tagged
twice or even thrice, I'd be willing to use git-version for all GNOME
stuff that we take from git.  I'd also be willing to move to git
origins for GNOME stuff if mirror://gnome becomes unreliable.  But what
if you're correct?  Are you willing to use git-version for every single
git-reference out there?


  reply	other threads:[~2022-01-01 23:21 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
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 [this message]
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=b3bfa7b57b527d78aeb21dee6123c617a90fc13d.camel@gmail.com \
    --to=liliana.prikler@gmail.com \
    --cc=guix-devel@gnu.org \
    --cc=mhw@netris.org \
    /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).