Ignore epoch when comparing package versions for upgrade

itektur · 2018-07-15 10:22:51

There are packages versioned with an epoch number that I would like to see being upgraded. However, they do not show up for upgrade because their epoch is greater than the epoch of the new package. Example:

    $ cower -s ttf-tahoma
    aur/ttf-tahoma 2.13-2 (76, 2.44) [installed: 1:1.7.27-1]
        Tahoma and Tahoma Bold fonts from the Wine project

I cannot quite remember what caused this package to be installed, but after an upgrade some weeks ago, I ran into an issue with fonts (especially bold fonts!) not working as expected, so I would like to give the approach in that thread a try to fix it now: https://bbs.archlinux.org/viewtopic.php?id=206746

In other words, my AUR helpers do not show this package as upgradable due to the epoch number. I found this package as possibly being out of date only because said thread pointed that very package out to me.

Now, I wonder which else packages I "forgot" to upgrade the whole time because of the epoch number. Is there a way to ignore the epoch when attempting to upgrade all packages so I can see which packages might cause trouble?

(I know that the AUR is a nice place to break things, but it does not help much if an epoch number creeps in (erroneously, maybe) and blocks updates like forever without pointing that out to the user.)

Allan · 2018-07-15 10:41:57

There is no way to do that.

arojas · 2018-07-15 11:10:37

Report this to the package maintainer, epoch should *never* be removed

amish · 2018-07-15 12:17:26

You can force upgrade by using -U manually.

Or first remove the package and install new one.

# find a colon
pacman -Q  | grep :

should give you all packages installed with epoch in their version

Then you can upgrade (downgrade by version logic) whichever package you want.

Last edited by amish (2018-07-15 12:18:46)

Lone_Wolf · 2018-07-15 12:53:14

https://aur.archlinux.org/cgit/aur.git/ … ttf-tahoma

It appears the original submitter used epoch without understanding what it means and the current maintainer removed it when they adopted the package in september 2017.
I would probably have done the same, although i would have posted a comment to alert existing users of the change.

amish · 2018-07-15 14:34:00

Since Arch is a rolling release, I think we can devise a way for epoch removal by maintainers.

We can reserve epoch versions between 90 to 99 as reserved epochs.

By Arch principle everyone is supposed to be up-to-date.

So if old version 3.0 was overridden by epoch version 1:2.0

We can safely assume that noone would be (and should be) on version 3.0 after say 6 months.

We can then prepare an epoch "reset" version say 90:2.0

Now after another 6 months we can again safely assume that everyone is on epoch 90

Now any EPOCH less version will override epoch >= 90.

So then we can have a new epochless release say 2.1

So logic that we can apply is
3.0 < 1:2.0
1:2.0 < 90:2.0 (buffer period begins)
90:2.0 < 2.1 (or even 2.0) (because old epoch is between 90-99)

We reserve epoch between 90-99 so that we still maintain a way to increase epoch incase any such need arises and still be able to "reset" epoch in future.

Last edited by amish (2018-07-15 14:35:30)

Trilby · 2018-07-15 14:48:35

That's a ridiculously complex way of dealing with a non-issue.

We already have a consistent and reliable system. The only way it can go wrong is if a packager fucks up. Making the system ridiculously more complex is most certainly not going to make it less likely for someone to fuck it up.

amish · 2018-07-15 14:57:34

Why unnecessary swearing?!

I am just answering the "subject" question.

If there can be a way to "ignore epoch when comparing package versions for upgrade"

I am not saying "do it"

If you have a reliable way .. where epoch can be "reset" by maintainer without manual intervention by users. Please do share. I would love to know.

Trilby · 2018-07-15 15:04:47

amish wrote:

If you have a reliable way .. where epoch can be "reset" by maintainer without manual intervention by users. Please do share. I would love to know.

No, that's the point. It should not be done. Period.

The problem is not the inability to "reset" the epoch. The problem is an AUR maintainer fucked up, it's as simple as that. That may be adult language, but we are adults, and it is accurate. I could have said the AUR maintainer made a boo-boo, if you'd be more comfortable with that.

The solution is to tell them to clean up the products of their boo-boo and not leave nukka poos in the AUR.

amish · 2018-07-15 15:11:48

Trilby wrote:

That may be adult language, but we are adults,

OT: didnt know Arch linux and forums were meant to be used / read by adults only. But anyway - I do not want to drag this any further. So cheers.

eschwartz · 2018-07-15 15:16:27

Lone_Wolf wrote:

It appears the original submitter used epoch without understanding what it means and the current maintainer removed it when they adopted the package in september 2017.
I would probably have done the same, although i would have posted a comment to alert existing users of the change.

What part of "epoch should *never* be removed" was difficult to comprehend?

There is *no* acceptable reason for removing the epoch, ever.

It doesn't matter if someone misused it, it has still become part of the canonical version string and you're screwing over users in order to perform revisionist history, just to please your sense of aesthetics.

If it was okay to remove the epoch because it was misused, it would also be okay to remove the epoch when it was in fact used correctly -- or just not use it at all and "post a comment to alert existing users of the change" when the version string changes in such a way that would require an epoch.

But, since Arch Linux is not a distro where you need to read the documentation for every single package on your system before you can successfully do stupidly simple things like pacman -Syu (or in this case, trust whatever mechanism you use to scrape the AUR for *version* updates not comment updates), maintaining the version string inside the package comments instead of the PKGBUILD is not a thing which the Arch Linux community does.

...

EDIT: reconsidered last paragraph

Last edited by eschwartz (2018-07-15 23:30:07)

WorMzy · 2018-07-15 18:07:45

That last comment was unnecessary. Tone it down, please.

https://wiki.archlinux.org/index.php/Co … ther_users

itektur · 2018-07-16 18:38:19

Thank you very much for all your help. I derived the following Bash line to search for packages that have a non-zero epoch number in their version string using yaourt (I do not know how to do this with cower):

function join { local IFS="|"; echo "$*"; } ; pkglist=$(pacman -Q | grep -E " [^:0]+:" | grep -o -E "^[^ ]+") ; regex='^('"$(join $pkglist)"')$' ; yaourt -Ss --nameonly "$regex"

(There is probably a simpler way to accomplish that, but it works, apparently.)

I don't know much about packaging and the AUR, but if Lone_Wolf is right, I wonder whether there are some countermeasures like warning signs and explicit hints etc. that clearly point out, for example, that a non-zero epoch for the very first version of a package does not make sense, or even confirmation prompts if someone attempts to upload a version with a bogus epoch number.

Actually, now that I think about it, a way to interactively choose a reasonable epoch number might look like this in pseudo code:

repair_epoch(new_version_string, current_version_string){

  IF strip_epoch(new_version_string) > strip_epoch(current_version_string) THEN
    PRINT "You know you do not need to bump the epoch in this case, do you?"
    RETURN set_epoch(new_version_string, epoch(current_version_string))
  ENDIF

  IF strip_epoch(new_version_string) == strip_epoch(current_version_string) THEN
    PRINT "Please bump the package release number for me, I am lazy today."
    ABORT
  ENDIF

  IF strip_epoch(new_version_string) <= strip_epoch(current_version_string) THEN
    PRINT "Are you sure your new version is actually newer and replaces the current (old) version of this package?"
    INPUT x
    IF x == "yes" THEN
      RETURN set_epoch(new_version_string, epoch(current_version_string) + 1)
    ENDIF
  ENDIF

  RETURN new_version_string
}

In other words, the epoch never needs to be bumped manually but some piece of software can do so semi-automatically if the new version looks older than the current one.

Just my two cents.

(Okay, now I have probably revealed to the world how much I do not know about the AUR. This is certainly a candidate for the most embarrassing post of the year, I guess. Well, at least I tried …)

Trilby · 2018-07-16 18:50:38

I had a lot to critique as I read your last post - that is until I get to the very end where I found the last two sentences quite agreeable.

A non-zero inital epoch number would not actually be a problem. It isn't needed and frankly doesn't make much sense to have one at that point, but it will cause no problems at all. But once one is added, it must stay, or as needed be incremented. It's as simple as that. To do otherwise is incorrect.

WorMzy · 2018-07-16 18:59:12

I'm going to close this now, as the topic is just going in circles.

A non-zero epoch is not a problem. It does not need fixing.

Arch Linux

#1 2018-07-15 10:22:51

Ignore epoch when comparing package versions for upgrade

#2 2018-07-15 10:41:57

Re: Ignore epoch when comparing package versions for upgrade

#3 2018-07-15 11:10:37

Re: Ignore epoch when comparing package versions for upgrade

#4 2018-07-15 12:17:26

Re: Ignore epoch when comparing package versions for upgrade

#5 2018-07-15 12:53:14

Re: Ignore epoch when comparing package versions for upgrade

#6 2018-07-15 14:34:00

Re: Ignore epoch when comparing package versions for upgrade

#7 2018-07-15 14:48:35

Re: Ignore epoch when comparing package versions for upgrade

#8 2018-07-15 14:57:34

Re: Ignore epoch when comparing package versions for upgrade

#9 2018-07-15 15:04:47

Re: Ignore epoch when comparing package versions for upgrade

#10 2018-07-15 15:11:48

Re: Ignore epoch when comparing package versions for upgrade

#11 2018-07-15 15:16:27

Re: Ignore epoch when comparing package versions for upgrade

#12 2018-07-15 18:07:45

Re: Ignore epoch when comparing package versions for upgrade

#13 2018-07-16 18:38:19

Re: Ignore epoch when comparing package versions for upgrade

#14 2018-07-16 18:50:38

Re: Ignore epoch when comparing package versions for upgrade

#15 2018-07-16 18:59:12

Re: Ignore epoch when comparing package versions for upgrade

Board footer