support the special '~' character in our version parser

  • Open
  • quality assurance status badge
Details
2 participants
  • Jelle Licht
  • Maxim Cournoyer
Owner
unassigned
Submitted by
Maxim Cournoyer
Severity
normal
M
M
Maxim Cournoyer wrote on 11 Jan 2023 04:23
guix lint thinks 2019111-0.7e76d75 is older than 20191111
(name . bug-guix)(address . bug-guix@gnu.org)
878ri9kb3v.fsf@gmail.com
Hi Guix,

If you run 'guix lint emacs-enh-ruby-mode', it'll print this:

Toggle snippet (3 lines)
emacs-enh-ruby-mode@2019111-0.7e76d75: can be upgraded to 20191111

That's wrong; it should know that something that starts with the tag and
has trailing characters is considered newer. Actually, it should
probably implement the RPM scheme used in Debian also, so that an RC can
be understood as older than the final release. The scheme uses the
tilde character (~) as a way to specify that the version is lower than
the number that precedes the tilde.

See the test case here for a "specification" (there may be a better
place):

--
Thanks,
Maxim
J
J
Jelle Licht wrote on 11 Jan 2023 14:24
87ilhdkxv3.fsf@fsfe.org
Maxim Cournoyer <maxim.cournoyer@gmail.com> writes:

Toggle quote (7 lines)
> Hi Guix,
>
> If you run 'guix lint emacs-enh-ruby-mode', it'll print this:
>
> --8<---------------cut here---------------start------------->8---
> emacs-enh-ruby-mode@2019111-0.7e76d75: can be upgraded to 20191111
> --8<---------------cut here---------------end--------------->8---
In this particular case, 2019111 seems to have been a typo in the first
place. (It misses out on a '1' in our package record).

AFAIK, any sane versioning scheme would assert that 20191111 > 2019111-anything.
M
M
Maxim Cournoyer wrote on 11 Jan 2023 14:43
(name . Jelle Licht)(address . jlicht@fsfe.org)
87358hjifv.fsf@gmail.com
retitle 60725 support the special '~' character in our version parser
thanks

Jelle Licht <jlicht@fsfe.org> writes:

Toggle quote (12 lines)
> Maxim Cournoyer <maxim.cournoyer@gmail.com> writes:
>
>> Hi Guix,
>>
>> If you run 'guix lint emacs-enh-ruby-mode', it'll print this:
>>
>> --8<---------------cut here---------------start------------->8---
>> emacs-enh-ruby-mode@2019111-0.7e76d75: can be upgraded to 20191111
>> --8<---------------cut here---------------end--------------->8---
> In this particular case, 2019111 seems to have been a typo in the first
> place. (It misses out on a '1' in our package record).

Thanks! With this typo fixed, 'guix lint' doesn't suggest a downgrade
anymore.

Toggle quote (2 lines)
> AFAIK, any sane versioning scheme would assert that 20191111 > 2019111-anything.

That's not currently the case with Guix. Guix package version strings
are documented has having the requirement to be 'monotonically
increasing', so '43.rc3' as used by GNOME is seen by Guix as newer than
'43', the final release.

I'll keep this bug open (and retitle it), because implementing ~ would
be useful (GNOME makes use of that scheme, and it's understood by rpm,
dpkg, pkg-config, etc.).

--
Thanks,
Maxim
J
J
Jelle Licht wrote on 11 Jan 2023 15:34
(name . Maxim Cournoyer)(address . maxim.cournoyer@gmail.com)
87cz7lkum8.fsf@fsfe.org
Maxim Cournoyer <maxim.cournoyer@gmail.com> writes:

Toggle quote (27 lines)
> retitle 60725 support the special '~' character in our version parser
> thanks
>
> Jelle Licht <jlicht@fsfe.org> writes:
>
>> Maxim Cournoyer <maxim.cournoyer@gmail.com> writes:
>>
>>> Hi Guix,
>>>
>>> If you run 'guix lint emacs-enh-ruby-mode', it'll print this:
>>>
>>> --8<---------------cut here---------------start------------->8---
>>> emacs-enh-ruby-mode@2019111-0.7e76d75: can be upgraded to 20191111
>>> --8<---------------cut here---------------end--------------->8---
>> In this particular case, 2019111 seems to have been a typo in the first
>> place. (It misses out on a '1' in our package record).
>
> Thanks! With this typo fixed, 'guix lint' doesn't suggest a downgrade
> anymore.
>
>> AFAIK, any sane versioning scheme would assert that 20191111 > 2019111-anything.
>
> That's not currently the case with Guix. Guix package version strings
> are documented has having the requirement to be 'monotonically
> increasing', so '43.rc3' as used by GNOME is seen by Guix as newer than
> '43', the final release.

I agree with your assesment, but note that my example (again) had one
"1" less, in which case Guix does the right thing :-).

Toggle quote (5 lines)
>
> I'll keep this bug open (and retitle it), because implementing ~ would
> be useful (GNOME makes use of that scheme, and it's understood by rpm,
> dpkg, pkg-config, etc.).

Fixing our versioning code so "123" > "123-alpha2" will also bring us
(more) in line with Semantic Versioning.

- Jelle
M
M
Maxim Cournoyer wrote on 11 Jan 2023 19:59
(name . Jelle Licht)(address . jlicht@fsfe.org)
87mt6oj3rm.fsf@gmail.com
Hi,

Jelle Licht <jlicht@fsfe.org> writes:

Toggle quote (7 lines)
> Maxim Cournoyer <maxim.cournoyer@gmail.com> writes:
>
>> retitle 60725 support the special '~' character in our version parser
>> thanks
>>
>> Jelle Licht <jlicht@fsfe.org> writes:

[...]

Toggle quote (8 lines)
>> That's not currently the case with Guix. Guix package version strings
>> are documented has having the requirement to be 'monotonically
>> increasing', so '43.rc3' as used by GNOME is seen by Guix as newer than
>> '43', the final release.
>
> I agree with your assesment, but note that my example (again) had one
> "1" less, in which case Guix does the right thing :-).

Ah! I failed to correctly read that version number again, eh!

--
Thanks,
Maxim
?
Your comment

Commenting via the web interface is currently disabled.

To comment on this conversation send an email to 60725@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 60725
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch