[SOLVED] Utility to check for out of date AUR packages

jdarnold · 2018-03-19 13:32:34

I'm trying to avoid using any AUR helpers to install and maintain the AUR packages I use. I keep getting into trouble with them.

So what I'm looking for is a simple utility that will just check all my installed AUR packages (as reported by 'pacman -Qm') against the version found in the AUR using the AUR RPC interface and just tell me I need to update it (or even that it's been removed). I've looked at a couple things mentioned in the AUR wiki page, but they all either try to do too much or don't seem to work.

If it doesn't exist, I'll just write it, I guess.

Last edited by jdarnold (2018-03-19 13:49:19)

Trilby · 2018-03-19 13:42:44

https://bbs.archlinux.org/viewtopic.php … 7#p1773307

jdarnold · 2018-03-19 13:49:03

Perfect!

cjobrien · 2018-05-29 21:58:34

Trilby wrote:

https://bbs.archlinux.org/viewtopic.php … 7#p1773307

Thanks, very handy

Looks like there are some version string changes that LooseVersion does not handle well

:: p4 2015.2.1326881-16 -> 2017.2.1579154-1
:: plantuml 1.2017.15-1 -> 1.2018.6-1     
Traceback (most recent call last):      
  File "/tmp/foo.py", line 23, in <module>                     
    if installed < available:                        
  File "/usr/lib/python3.6/distutils/version.py", line 52, in __lt__
    c = self._cmp(other)                      
  File "/usr/lib/python3.6/distutils/version.py", line 337, in _cmp
    if self.version < other.version:       
TypeError: '<' not supported between instances of 'int' and 'str'

0.12.2.r479.ga43a439c-1 changing to 0.12.r46.g7a5e8ef3-2 was the culprit here.

I'm sure there's a more elegant solution, but I hacked around it easily enough:

--- /tmp/original.py	2018-05-29 14:54:52.000000000 
+++ /tmp/hacked.py	2018-05-29 14:44:01.000000000 
@@ -17,10 +17,15 @@
     info  = loads(url.read().decode())['results']
 
 for pkg in info:
     params = {'Name': pkg['Name'], 'Old': vers[pkg['Name']], 'New': pkg['Version']}
     available = LooseVersion(pkg['Version'])
     installed = LooseVersion(vers[pkg['Name']])
-    if installed < available:
-        print(newer_fmt.format(**params))
-    elif installed != available:
+
+    try:
+        if installed < available:
+            print(newer_fmt.format(**params))
+        elif installed != available:
+            print(older_fmt.format(**params))
+            
+    except TypeError:
         print(older_fmt.format(**params))

Trilby · 2018-05-29 22:18:24

I think that is the most elegant solution in my view. You can make LooseVersion work around this, but it's not immediately obvious what *should* be done when upstream changes their versioning scheme. In this case I'm pretty sure 0.2.12.r<stuff> should be interpreted as newer than 0.2.r<stuff>, and if it's safe to always assume that'd be the case (i.e. always assume that a numeric element is "higher" than a string element) then the following would be more complete, though its a handful of lines of code to deal with odd corner cases:

except TypeError:
   installed = [ v if type(v) is int else 0 for v in installed.version ]
   available = [ v if type(v) is int else 0 for v in available.version ]
   if installed < available:
      print(newer_fmt.format(**params))
   elif installed != available:
      print(older_fmt.format(**params))

If you wanted you could have fewer lines of code by doing the check premeptively and sanitizing strings to zeros (though this is a bit of a waste for such a rare corner case, and rather un-pyhonic):

if [ type(x) for x in installed.version ] != [ type(y) for y in available.version ]:
   installed = [ v if type(v) is int else 0 for v in installed.version ]
   available = [ v if type(v) is int else 0 for v in available.version ]
if installed < available:
   # ...

So overall I think your solution is best. It deals with unexpected input and highlights the two versions as not being equal without attempting to make potentially hasty inferences about which one should be considered "higher" (which highlights the fact that "older_fmt" is a bit of a misnomer for the variable, but it works well enough). I've added your version to my aur tool.

Last edited by Trilby (2018-05-29 22:21:12)

eschwartz · 2018-05-29 22:46:47

Pyalpm comes with libalpm vercmp bindings, or you could use ctypes. It would let you reliably use the same version comparison logic used by pacman, without regard to how python's version comparison behaves.

But pkg_resources has a parse_version which is supposedly much better than distutils anyway. While it's not in the stdlib, setuptools is one of the most common modules to have...

But, it considers things like 2 < 2.r

Or more importantly, it considers 0.12.2.r479.ga43a439c-1 < 0.12.2-1

I'm unsure what the best way to get version comparison on python might be, except that when it comes to pacman the answer is definitely "use vercmp properly".

Trilby · 2018-05-29 23:04:04

Eschwartz wrote:

Or more importantly, it considers 0.12.2.r479.ga43a439c-1 < 0.12.2-1

LooseVersion will get that right too*. That wasn't the issue at hand (unless that was a typo in your post). The problem was due to one of the version numbers having numeric major-minor-revision and the other having only major-minor as numeric. Although I see parse_version would work on the above-noted problem. Although I also just realized that the upstream source actually intended the opposite of both what I assumed would be true and what parse_version concludes: 0.12.r46 is newer than 0.12.2.r479. As there really isn't any logic that can account for this, just falling back to reporting unequal version numbers still seems best.

*EDIT: scratch that. ~~That must have been a typo in your post, right?~~ LooseVersion has no problem comparing those to version numbers, but it concludes, as I would, that the first is greater than the second. EDIT 2: and I confirmed parse_version agrees with what you posted. So this is a different issue all together: parse_version and LooseVersion both successfully compare those values, but they get different answers. LooseVersion's answer looks better to me.

Last edited by Trilby (2018-05-29 23:09:25)

progandy · 2018-05-29 23:24:33

Eschwartz wrote:

I'm unsure what the best way to get version comparison on python might be, except that when it comes to pacman the answer is definitely "use vercmp properly".

I modified Trilbys script especially for you Now it uses pyalpm.

#!/usr/bin/env python

import pyalpm
from pycman import config
from json import loads
from subprocess import check_output
from urllib.request import urlopen

aur='https://aur.archlinux.org/rpc/?v=5&'
newer_fmt = '\033[34m:: \033[0;1m{Name} \033[0;31m{Old}\033[0m -> \033[32m{New}\033[0m'
older_fmt = '\033[34m:: \033[0;1m{Name} \033[0m{Old} != {New}'

handle = config.init_with_config("/etc/pacman.conf")

syncpkgs = set(p.name for db in handle.get_syncdbs() for p in db.pkgcache)

foreign_vers = { p.name: p.version for p in handle.get_localdb().pkgcache if not p.name in syncpkgs }

params = '&arg[]=' + '&arg[]='.join(foreign_vers.keys())

with urlopen(aur + 'type=info' + params) as url:
   info  = loads(url.read().decode())['results']

for pkg in info:
    params = {'Name': pkg['Name'], 'Old': foreign_vers[pkg['Name']], 'New': pkg['Version']}
    newer = pyalpm.vercmp(pkg['Version'], foreign_vers[pkg['Name']])
    if newer > 0:
        print(newer_fmt.format(**params))
    elif newer < 0:
        print(older_fmt.format(**params))

Last edited by progandy (2018-05-29 23:35:54)

eschwartz · 2018-05-30 00:48:16

Trilby wrote:

Eschwartz wrote:
Or more importantly, it considers 0.12.2.r479.ga43a439c-1 < 0.12.2-1
LooseVersion will get that right too*. That wasn't the issue at hand (unless that was a typo in your post). The problem was due to one of the version numbers having numeric major-minor-revision and the other having only major-minor as numeric. Although I see parse_version would work on the above-noted problem. Although I also just realized that the upstream source actually intended the opposite of both what I assumed would be true and what parse_version concludes: 0.12.r46 is newer than 0.12.2.r479. As there really isn't any logic that can account for this, just falling back to reporting unequal version numbers still seems best.
*EDIT: scratch that. ~~That must have been a typo in your post, right?~~ LooseVersion has no problem comparing those to version numbers, but it concludes, as I would, that the first is greater than the second. EDIT 2: and I confirmed parse_version agrees with what you posted. So this is a different issue all together: parse_version and LooseVersion both successfully compare those values, but they get different answers. LooseVersion's answer looks better to me.

As you eventually concluded? I was pointing out that they each have their strengths and weaknesses, and that parse_version at least fulfills its own goal -- which differs from pacman.

Are we going for better or best? Is it a goal to stick to the stdlib, or is a pyalpm dependency okay?

progandy wrote:

I modified Trilbys script especially for you Now it uses pyalpm.

My hero

Trilby · 2018-05-30 01:15:18

Eschwartz wrote:

Are we going for better or best?

Given two options, better is best. But now we have three options with pyalpm, but that one does no better (actually arguably worse) than LooseVersion on the corner case that triggered this discussion. While LooseVersion fails to compare the two version numbers, a simple try block will allow it to report a version mismatch so the user can make an informed decision. In contrast pyalpm's vercmp would get the wrong answer.

Last edited by Trilby (2018-05-30 01:16:16)

progandy · 2018-05-30 01:44:56

I'm not sure where there could be a problem with vercmp. 0.12.2.r* is a more recent version than 0.12.r* and vercmp provides this answer. If the project uses illogical version numbers, then vercmp can't do anything about that. You can only report a version mismatch, and that works with vercmp as well.

By the way, 0.12.r46.g7a5e8ef3-2 is the version of python-flask-git as it is in the AUR from March 2017, and commit a43a439c is from December 2017, so the vercmp works very well.

These are all correct results for alpm versions, even with pkgrel:

vercmp 0.12.2.r479.ga43a439c-1 0.12.r46.g7a5e8ef3-2
1 # first version is newer
vercmp 0.12.2-1 0.12-3
1
vercmp 0.12.2-1 0.12.2-3
-1 # second version is newer
vercmp 0.12.2 0.12.b4
1
vercmp 0.13 0.12.0
1
vercmp 0.12 0.13.0
-1
vercmp 0.12 0.12.0
-1
vercmp 0.12 0.12
0

Trilby · 2018-05-30 01:50:56

progandy wrote:

I'm not sure where there could be a problem with vercmp

There isn't one. But for the problem raised in this thread, it doesn't seem to be an improvement over LooseVersion.

eschwartz · 2018-05-30 03:05:26

Um, what?

Literally the whole point of vercmp is that it's what pacman considers to be an updated version. By definition, if some upstream versioning breaks this, then AUR maintainers are supposed to add an epoch... it's the logic pacman will use when telling you it's either upgrading or downgrading or reinstalling a package.

It *is* the canonical source for what's an updated version. That's even stronger than "it implements the same version comparison logic".
So how can it ever be wrong? If it was ever wrong, then what it said would become right and it wouldn't be wrong anymore.

Trilby · 2018-05-30 10:12:22

Are we in the same discussion? LooseVersion worked fine until the exception presented in post #4 where it didn't recognize upstreams 'new' version number as newer. Vercmp was presented as an alternative that could do better ... but in the one case that triggered the discussion, it judged upstreams 'new' version as older!

Tool B was presented as better than tool A based on the evidence that tool A failed in a specific case. But then tool B also fails in that case ... but the tool B proponents define that failure as a success and therefore conclude it's the better tool.

I could define LooseVersion's handling of this case as a success. Really it's not a stretch. Something odd happened with upstreams version numbers, and LooseVersion is more verbose about that - it can really flag it as odd.

Tools should be evaluated in the real world, not fictional examples only derived from how we think the real world should be.

Last edited by Trilby (2018-05-30 10:14:01)

eschwartz · 2018-05-30 12:20:13

Trilby wrote:

Are we in the same discussion? LooseVersion worked fine until the exception presented in post #4 where it didn't recognize upstreams 'new' version number as newer. Vercmp was presented as an alternative that could do better ... but in the one case that triggered the discussion, it judged upstreams 'new' version as older!

I don't know, are we? I'm discussing the example from post #4:

$ vercmp 0.12.2.r479.ga43a439c-1 0.12.r46.g7a5e8ef3-2
1 # 0.12.2.r479.ga43a439c-1 > 0.12.r46.g7a5e8ef3-2

This is correct for pacman, which is good because those aren't upstream versions, they're PKGBUILD versions.

>>> from pkg_resources import parse_version as V
>>> V('0.12.2.r479.ga43a439c-1') > V('0.12.r46.g7a5e8ef3-2')
True

This too is correct for pacman.

>>> from pkg_resources import parse_version as V
>>> V('0.12.2.r479.ga43a439c-1') > V('0.12.2-1')
False

This is wrong, trying to use these *PKGBUILD* versions in makepkg will get you a pacman *upgrade*, but python says it isn't!

$ vercmp 0.12.2.r479.ga43a439c-1 0.12.2-1
1 # 0.12.2.r479.ga43a439c-1 > 0.12.2-1

Good thing pacman's internal version comparison logic gets it right whether you load alpm_pkg_vercmp from libalpm.so or the version statically linked into /usr/bin/vercmp

Good thing distutils LooseVersion gets it right too:

>>> from distutils.version import LooseVersion as LV
>>> LV('0.12.2.r479.ga43a439c-1') > LV('0.12.2-1')
True

Hmm, let's see how it handles other *valid pacman versions*

>>> LV('0.12.2.r479.ga43a439c-1') > LV('0.12.r46.g7a5e8ef3-2')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3.6/distutils/version.py", line 64, in __gt__
    c = self._cmp(other)
  File "/usr/lib/python3.6/distutils/version.py", line 337, in _cmp
    if self.version < other.version:
TypeError: '<' not supported between instances of 'int' and 'str'

Oops, looks like you cannot rely on it even functioning!

Tool B was presented as better than tool A based on the evidence that tool A failed in a specific case. But then tool B also fails in that case ... but the tool B proponents define that failure as a success and therefore conclude it's the better tool.
I could define LooseVersion's handling of this case as a success. Really it's not a stretch. Something odd happened with upstreams version numbers, and LooseVersion is more verbose about that - it can really flag it as odd.
Tools should be evaluated in the real world, not fictional examples only derived from how we think the real world should be.

How on earth do you define success and failure? Give me real-world examples of where Python's version comparison logic parses *pacman versions* better than *pacman itself*!

*checks which subforum we're in*

Forget about upstream versions for a second. There are no upstream versions anywhere in this thread.

Trilby · 2018-05-30 12:30:18

Eschwartz wrote:

How on earth do you define success and failure? Give me real-world examples of where Python's version comparison logic parses *pacman versions* better than *pacman itself*!

Post #4.

Although I'm not arguing it's objectively better. You seem to be arguing that alpm's version comparison handles the situation in post #4 better than LooseVersion. This is plainly false. They both get that one wrong.

I will argue I prefer LooseVersion, as the way it get's it wrong is more useful to me than the way pyalpm gets it wrong.

As for the no true scotsman argument here, the version numbers in post #4 are actual real-world version numbers whether or not you think they should be.

Last edited by Trilby (2018-05-30 12:31:40)

eschwartz · 2018-05-30 12:47:11

Trilby wrote:

Eschwartz wrote:
How on earth do you define success and failure? Give me real-world examples of where Python's version comparison logic parses *pacman versions* better than *pacman itself*!
Post #4.
Although I'm not arguing it's objectively better. You seem to be arguing that alpm's version comparison handles the situation in post #4 better than LooseVersion. This is plainly false. They both get that one wrong.
I will argue I prefer LooseVersion, as the way it get's it wrong is more useful to me than the way pyalpm gets it wrong.
As for the no true scotsman argument here, the version numbers in post #4 are actual real-world version numbers whether or not you think they should be.

Yes, that's the real-world proof that I am right and so is pyalpm.

Let's try this one more time.

Why do you think 0.12.r46.g7a5e8ef3-2 is greater than 0.12.2.r479.ga43a439c-1?

To start with, this is a pacman version string. We can tell because one of them came from `pacman -Qm`, and the other came from the AurJson (which retrieved it from a .SRCINFO file generated by makepkg). So let's consider what it actually means. Namely, it is generated from git describe, which means it is:

tagged release = 0.12
git revisions since tag = .r46
the sha1 short hash of commit = .g7a5e8ef3
pkgrel = 2

vs.

tagged release = 0.12.2
git revisions since tag = .r479
the sha1 short hash of commit = .ga43a439c
pkgrel = 1

Why do you think the first one is more up-to-date than the second one?

Please explain your reasoning, then open a pacman bug requesting that `pacman -{S,U}` see the second one as a downgrade rather than an upgrade (and therefore refuses to automatically sync this when using `pacman -Syu`).

Currently, pacman itself sees this as an upgrade...

According to you, pacman is currently broken and downgrades my packages while thinking it is upgrading them. This is obviously a serious bug and the pacman developers should be aware of it and fix it.

Last edited by eschwartz (2018-05-30 12:51:03)

Trilby · 2018-05-30 13:46:42

Eschwartz wrote:

Yes, that's the real-world proof that I am right

Or delusional.

Eschwartz wrote:

Why do you think 0.12.r46.g7a5e8ef3-2 is greater than 0.12.2.r479.ga43a439c-1?

I don't. Period. I have never said this.

Eschwartz wrote:

Why do you think the first one is more up-to-date than the second one?

See above.

Eschwarz wrote:

Please explain your reasoning, then open a pacman bug

What on earth would motivate me to honor either of those requests?

Eschwartz wrote:

Currently, pacman itself sees this as an upgrade...

First, I'm not talking about pacman. But a correction: pacman would see the change under discussion as a downgrade. There was a version in the AUR. Then a new version was added to the AUR that had a version number that pacman and pyalpm would see as a lower version number, a downgrade.

Eschwartz wrote:

According to you, pacman is currently broken and downgrades my packages while thinking it is upgrading them.

I have never said this, and there is nothing left to discuss as you keep puting completely nonsense words into my mouth and demanding proof of them.

I like LooseVersion. I'll continue to use LooseVersion. Pyalpm can give three answers in comparing version numbers: Greater, Lesser, or Equal. LooseVersion can give four answers: Greater, Lesser, Equal, or 'Something funny is happening'. I find that last response useful. If you don't find it useful, don't use it! Frankly I'm getting less and less willing to share code I use. I've not even ever shared my little aur script in full, but I have given little portions that I thought might help other users. Most of them have been appreciative - but then I get demands to prove how my code is best and also prove how other code is flawed. I have no need to prove such things.

Last edited by Trilby (2018-05-30 15:13:24)

eschwartz · 2018-05-30 22:58:43

Trilby wrote:

Eschwartz wrote:
Why do you think 0.12.r46.g7a5e8ef3-2 is greater than 0.12.2.r479.ga43a439c-1?
I don't. Period. I have never said this.

vercmp says this. You've stated that vercmp is wrong. You didn't say you don't want to use it because you prefer other things -- you've stated it is wrong.

Eschwarz wrote:
Please explain your reasoning, then open a pacman bug
What on earth would motivate me to honor either of those requests?

You've stated that vercmp is wrong, therefore I assumed that was a bug which should presumably be fixed.

Eschwartz wrote:
Currently, pacman itself sees this as an upgrade...
First, I'm not talking about pacman. But a correction: pacman would see the change under discussion as a downgrade. There was a version in the AUR. Then a new version was added to the AUR that had a version number that pacman and pyalpm would see as a lower version number, a downgrade.

Well, then, that sounds like it's a lesser version, so what's the package and why do you suggest that it's a newer version?

If some AUR maintainer pushed a change from 3.0 to 2.0, that's definitely a newer version of the PKGBUILD, but I'd say it's a downgraded package. If *upstream* tagged a release like that, then I'd even say upstream has a broken versioning schema, and the PKGBUILD maintainer was irresponsible for not using an epoch (something many package managers including Arch Linux pacman, Debian apt, Fedora rpm, and Python pip have).

Incidentally, use of epoch is one of the things th1at triggers the LooseVersion

Is it python-flask-git? But that's entirely correct to say that the version in the AUR is older. It's a VCS package, and the version you get when you run makepkg on the PKGBUILD is definitively newer than the version in the .SRCINFO which was pushed to the AUR. The AUR itself never saw a downgrade, as definitively proven by https://aur.archlinux.org/cgit/aur.git/ … -flask-git

...

But you're so busy picking a fight about pyalpm being "wrong" in order to defend your solution, that you never even considered this possibility, did you?

Eschwartz wrote:
According to you, pacman is currently broken and downgrades my packages while thinking it is upgrading them.
I have never said this, and there is nothing left to discuss as you keep puting completely nonsense words into my mouth and demanding proof of them.

Well, you certainly seem to be implying that pacman/vercmp sees "new" versions as older and "old" versions as newer.

I like LooseVersion. I'll continue to use LooseVersion. Pyalpm can give three answers in comparing version numbers: Greater, Lesser, or Equal. LooseVersion can give four answers: Greater, Lesser, Equal, or 'Something funny is happening'. I find that last response useful. If you don't find it useful, don't use it! Frankly I'm getting less and less willing to share code I use. I've not even ever shared my little aur script in full, but I have given little portions that I thought might help other users. Most of them have been appreciative - but then I get demands to prove how my code is best and also prove how other code is flawed. I have no need to prove such things.

Your code is perfectly fine. I never demanded you prove your code is best. I know it's not the best, *and I even respect your reason for not considering that important*.

I just don't understand why you moved on from saying that LooseVersion is more useful to you, to saying vercmp is broken and returns false information.

I will also feel perfectly vindicated in saying that once you move on to saying that other peoples' code is broken, you should defend your claim with hard evidence. You're the person who volunteered the information that vercmp is "wrong".

Tool B was presented as better than tool A based on the evidence that tool A failed in a specific case. But then tool B also fails in that case ... but the tool B proponents define that failure as a success and therefore conclude it's the better tool.

I'm also personally unable to understand what specific information you're deriving from "something funny is happening". The only thing I see happening here, is that the PKGBUILD in the AUR is a VCS package, that got locally updated. This is the "Lesser" state, and most AUR helpers tend to do heuristics e.g. detecting "-git" in the pkgname and ignoring it, or checking to see if there's a pkgver() function defined in the PKGBUILD... then for other cases, they will warn you that the version in the AUR is older.

...

You know, this whole thing started when I mentioned that python contains another common version comparison tool, which gets does not use the same logic as pacman, then pointed out that pacman has python bindings... which seems to do the same thing as LooseVersion except that *by spec* it is correct when processing Arch Linux package versions.

But I didn't say LooseVersion was wrong. It's good enough to get the right answer most of the time, it has the benefit of absolutely zero external dependencies, and in the unusual case where it freaks out and returns backtraces because it cannot parse the version in order to compare it, it's easy to leave that to the user. Hence I just mentioned the options, then said the most technically correct solution is pyalpm.

You then reacted badly, with:

Given two options, better is best. But now we have three options with pyalpm, but that one does no better (actually arguably worse) than LooseVersion on the corner case that triggered this discussion. While LooseVersion fails to compare the two version numbers, a simple try block will allow it to report a version mismatch so the user can make an informed decision. In contrast pyalpm's vercmp would get the wrong answer.

Which is a lie. pyalpm does not get the wrong answer. But you're getting hung up on defending your use of LooseVersion, even though it was never attacked, that you're inventing reasons out of whole cloth why its buggy, backtracey behavior (to be entirely precise, it compares each period-separated component, then freaks out if and only if the first component it tries to compare that contains a non-int does not have have a non-int in both LooseVersions) is an "actively more useful good" thing.

There's plenty of such PKGBUILDs around. If some git package does the "officially recommended correct" thing and uses "r244" for its pkgver, then gets a stable release 1.0 and starts using VCS versions like "1.0.r2", LooseVersion will fail on that too. Is it wonky? Maybe. Reporting a version mismatch is no less correct here than in the python-flask-git case, so pyalpm is again not strictly necessary given LooseVersion is once again in the stdlib.

It is completely, 100% unrelated to whether the version in the AUR is new or older. The backtrace appears when trying to compare certain classes of versions, regardless of whether you use > or < to compare them. But a mismatch certainly indicates some interesting update to look at on the AUR PKGBUILD! (Or else a VCS package, but those need special heuristics either way).

...

So either continue to say "pyalpm's vercmp would get the wrong answer", but be entirely unwilling to defend your judgmental judgmentyness, or not. I think I've determined the answer for myself either way.

And do continue to use your code which I never had a problem with regardless of the outcome of this discussion.

Trilby · 2018-05-30 23:39:19

Eschwartz wrote:

Well, then, that sounds like it's a lesser version, so what's the package and why do you suggest that it's a newer version?

FFS! It's post #4, read it already.

And I said vercmp gave the wrong conclusion about that version comparison, yes. But then you had to redefine "right" and "wrong", and using your definition of "right" being whatever pacman would say, yes, vercmp gave the "right" answer, but that answer is of no use in the context of this thread.

This all started when LooseVersion failed to categorize a change in version numbers as an upgrade. Vercmp was presented as an allegedly better alternative that could categorize the version number change in post #4 as an upgrade: but it doesn't do that! It calls it a downgrade. Whether it is "right" or "wrong" is irrelevant, it can't be an improvement over LooseVersion for failing to call something an upgrade that LooseVersion also failed to call an upgrade. Either they are both wrong or they are both right depending on how you wish to redefine those words, but vercmp can't be a better option based on this criteria.

Recap:
1) LooseVersion worked pretty well.
2) A package changed from 0.12.2.r479.ga43a439c-1 to 0.12.r46.g7a5e8ef3-2 and LooseVersion couldn't deal with that. A simple patch made it deal with it, but it still was lacking as it didn't detect this as an upgrade.
3) pyalpm was presented as a better alternative because it allegedly would detect this as an upgrade.

But statement 3 is false. Pyalpm does not categorize that change in versions as an upgrade. This is easy to verify. You can say it shouldn't consider that an upgrade: that's wonderful, but then claiming that it would see it as an upgrade is still an invalid premise in point 3 above.

- Hey, your tool got that answer wrong, mine will get it right
-- But your tool gave basically the same answer ...
- Yes, but when my tool gets that answer it's right, when your tool get's that answer it's wrong ... because we define right as whatever my tool gets for the answer
-- So why did my tool need improvement in the first place?
...

Last edited by Trilby (2018-05-30 23:56:05)

ewaller · 2018-05-31 01:22:48

I get some kind of weird enjoyment watching the two of you arguing -- two of the smartest, and certainly more stubborn, members of the community. Please both remember that you also represent the community.

Alad · 2018-05-31 02:06:29

ewaller wrote:

Please both remember that you also represent the community.

You mean they represent of how strongly opiniated our user base is purely for the sake of it.

Last edited by Alad (2018-05-31 02:07:24)

Arch Linux

#1 2018-03-19 13:32:34

[SOLVED] Utility to check for out of date AUR packages

#2 2018-03-19 13:42:44

Re: [SOLVED] Utility to check for out of date AUR packages

#3 2018-03-19 13:49:03

Re: [SOLVED] Utility to check for out of date AUR packages

#4 2018-05-29 21:58:34

Re: [SOLVED] Utility to check for out of date AUR packages

#5 2018-05-29 22:18:24

Re: [SOLVED] Utility to check for out of date AUR packages

#6 2018-05-29 22:46:47

Re: [SOLVED] Utility to check for out of date AUR packages

#7 2018-05-29 23:04:04

Re: [SOLVED] Utility to check for out of date AUR packages

#8 2018-05-29 23:24:33

Re: [SOLVED] Utility to check for out of date AUR packages

#9 2018-05-30 00:48:16

Re: [SOLVED] Utility to check for out of date AUR packages

#10 2018-05-30 01:15:18

Re: [SOLVED] Utility to check for out of date AUR packages

#11 2018-05-30 01:44:56

Re: [SOLVED] Utility to check for out of date AUR packages

#12 2018-05-30 01:50:56

Re: [SOLVED] Utility to check for out of date AUR packages

#13 2018-05-30 03:05:26

Re: [SOLVED] Utility to check for out of date AUR packages

#14 2018-05-30 10:12:22

Re: [SOLVED] Utility to check for out of date AUR packages

#15 2018-05-30 12:20:13

Re: [SOLVED] Utility to check for out of date AUR packages

#16 2018-05-30 12:30:18

Re: [SOLVED] Utility to check for out of date AUR packages

#17 2018-05-30 12:47:11

Re: [SOLVED] Utility to check for out of date AUR packages

#18 2018-05-30 13:46:42

Re: [SOLVED] Utility to check for out of date AUR packages

#19 2018-05-30 22:58:43

Re: [SOLVED] Utility to check for out of date AUR packages

#20 2018-05-30 23:39:19

Re: [SOLVED] Utility to check for out of date AUR packages

#21 2018-05-31 01:22:48

Re: [SOLVED] Utility to check for out of date AUR packages

#22 2018-05-31 02:06:29

Re: [SOLVED] Utility to check for out of date AUR packages

Board footer