Version numbers with letters

Support AUR
1

Greetings all, I am posting this in this catagory, but moderators, feel free to put it somewhere else if it makes more sense.

So as part of the the DeLinuxCo spin, I maintain AppImages in the DeLinuxCo repo, they are bundled in a package and delivered to the user like any other package. Everything works fine, no issues at all, except for Zen-Browser!

zen-browser-appimage was at version 1.21.9b, (this is the version method zen-browsers uses), a newer version is available, 1.21.11b. So I built the package with version 1.21.11b-1, but Arch apparently does not see 1.21.11b as newer than 1.21.9b, so it will never update. Apparently, according to Ai, the letter at the end causes this issue.

I am stuck, I want to move to a version number with no letters, but it will always see 1.21.9b as newer until version 1.22.0. Any suggestions on a way out of this circle?

2

You shouldn’t change upstream version numbers - this will break your users expectations.

Your versioning schema is alphanumeric and as such it cannot use numerical sorting.

1.21.11b comes before 1.21.9b because the .11b comes before .9b because they are read as a string - not numbers.

From man pacman

[...]
        You can also use pacman -Su to upgrade all packages that are
        out-of-date. See Sync Options below. When upgrading, pacman
        performs version comparison to determine which packages need
        upgrading. This behavior operates as follows:

        Alphanumeric:
            1.0a < 1.0b < 1.0beta < 1.0p < 1.0pre < 1.0rc < 1.0 < 1.0.a < 1.0.1
        Numeric:
            1 < 1.0 < 1.1 < 1.1.1 < 1.2 < 2.0 < 3.0.0
        
        Additionally, version strings can have an epoch value defined that
        will overrule any version comparison, unless the epoch values are
        equal. This is specified in an epoch:version-rel format. For
        example, 2:1.0-1 is always greater than 1:3.6-1.

[...]

Also see

man PKGBUILD

Note the epoch epoch

[...]
       epoch
           Used to force the package to be seen as newer than any previous
           versions with a lower epoch, even if the version number would
           normally not trigger such an upgrade. This value is required to be
           a positive integer; the default value if left unspecified is 0.
           This is useful when the version numbering scheme of a package
           changes (or is alphanumeric), breaking normal version comparison
           logic. See pacman(8) for more information on version comparisons.
[...]

In your case you would increment the epoch each time the appended letter increments. There is no rule that states how big the epoch can be.

In my opinion - when upstream uses an alphanumerical versioning which will not fit into the package manager’s version comparison - epoch is the way forward.

Just remember: If you go down the epoch road - judging from man pacman - there is no turning back.

3

Zen-browser Download page shows it is in beta stage currently

Release notes show the first beta version 1.0.2-b.0 replaced alpha version 1.0.1-a.19.
Change to current version number format ocurred when 1.6b replaced 1.2.0-b.5

4

Have you tried renaming 1.21.9b to 1.21.09b ? Then 09 will be lower than 11. (0<1). As said, read as string (9 like 90). I hate it. We actually received a special instruction at work for this because some colleges named files with dates like 7.8. instead of 07.08.26 and the sorting of the Microsoft server apparently fails the same way.

5

How do you figure? :thinking:

❯ vercmp 1.21.9b-1 1.21.11b-1
-1

vercmp (pacman) v7.1.0

Compare package version numbers using pacman's version comparison logic.

Usage: vercmp <ver1> <ver2>

Output values:
  < 0 : if ver1 < ver2
    0 : if ver1 == ver2
  > 0 : if ver1 > ver2

See man vercmp.

By the way, 1.21.12b is out now.

6

Are you using pacman or some other package manager? I think pacman behaves correctly but maybe some other package manager not.

9

Sorry all, have not had time to respond to all, but yes, I am just using pacman, yay does the same thing.

From all i had researched is that, in order for pacman to see 1.21.11b as newer than 1.21.9b, it should have been tagged 1.21.09b.

So my main question, how to move away from using a string in a version number but at the same time forcing the update to the existing package installs?

I see no reason why I can’t just use 1.21.11, that way it just works as normal? I am thinking I would have to use “conflicts with”, but I can’t wrap my head around how I would go about it? I really don want to move away from the existing name.

I never had this issue because I started with version 1.21.4b
I even tried a version of 1.21.9z, thinking maybe it will roll over, but sadly it still does not see the newer package. Although it did upgrade to 1.21.9z perfectly.

image
image847×284 88.2 KB

João

@Teo was on the right track. I rebuilt the package to 1.21.09b, deleted the 1.21.9b and left the 1.21.11 there.

Renaming was not enough, had to actually rebuild the package that worked!

Systems are updating to 1.21.11 perfectly.

Thank you all, love this community!

João

Perfect timing, I will add this version to verify that it updates :slight_smile:

Mod edit: I’ve merged your posts to keep things tidy. Hope you don’t mind :wink: Your conttributions here are really appreciated.