Re: On raw strings in <origin> commit field

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

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 have to
> start with some assumptions and while ideally we'd like to encode "I
> don't care", we do not have a system that allows us to do 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).

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

      Regards,
        Mark

-- 
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about <https://stallmansupport.org>.