CRUX

Welcome to CRUX bug tracking.
Tasklist

FS#1805 - prt-get recognizes version not correctly

Attached to Project: CRUX
Opened by Feodor Petrov (teodor) - Sunday, 03 May 2020, 15:09 GMT
Last edited by Fredrik Rinnestam (frinnst) - Sunday, 03 May 2020, 18:29 GMT
Task Type Bug Report
Category tools → prt-get
Status Closed
Assigned To No-one
Operating System CRUX
Severity Low
Priority Normal
Reported Version 3.5
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

I have tmux 3.1-1 installed.

prt-get offers to upgrade to 3.1a-1. ok.

But with --prefer-higher it doesn't offer to upgrade.

> printf '%s\n%s\n' '3.1' '3.1a' | sort -V
3.1
3.1a

> printf '%s\n%s\n' '3.1-1' '3.1a-1' | sort -V
3.1a-1
3.1-1

prt-get does not sort correctly. Should sort without $release first.
This task depends upon

Closed by  Fredrik Rinnestam (frinnst)
Sunday, 03 May 2020, 18:29 GMT
Reason for closing:  Invalid
Comment by Johannes Winkelmann (jw) - Sunday, 03 May 2020, 17:20 GMT
Just a little bit of historic context: The CRUX mantra has always been that the latest version in the tree is better, so that's why the version comparison is not the default. I trusted port maintainers to do the right thing, and users to lock their ports if they don't want to get an update.

Note that it's also common to use 'a' to denote alpha releases (see https://en.wikipedia.org/wiki/Software_versioning#Pre-release_versions), and of course, 3.1a(lpha) should be lesser than 3.1... so you can make an equally well case that sort(1) in not correctly, and tmux' release scheme flawed... all of that is mostly a question convention, or lack thereof. I know other packages use letters for patch releases, too, but there is no single globally accepted standard here.

Since this case can be interpreted in multiple ways depending on the versioning scheme used, prt-get determines that it is "undecided" on this: the two versions do not have the same amount of elements, and the additional element ('a') is not a number (e.g. for 1.1 and 1.1.1 it can compare it, because missing tokens are replaced with -1 which allow a simple number comparision). If it's undecided, it will not perform the update, and leave it up to the user, to make sure that nothing unexpected happens automatically. In other words, that is intended behavior.

Again, this is just the historic context. Whether the convention I followed while implementing this ~15(!) years ago still makes sense today is for others to decide, but the code itself is doing what it is supposed to do.
Comment by Feodor Petrov (teodor) - Sunday, 03 May 2020, 17:36 GMT
@jw, seems that you're right

Loading...