Inaccurate results in some scenarios

[adoom42]

Hi, I've been using python-rpm-vercmp in some scripts for some time now and it's worked very well.

Recently a discrepancy was discovered. First, some background...

With this module, when the second argument to vercmp is newer, it returns -1. When the second argument is older, it returns 1.

There's a nice tool called rpmdev-vercmp available in the rpmdevtools package.

All of my hosts are RHEL/CentOS 7 with Python 3.6.

Here's a case where both Python and rpmdev-vercmp give the same results. This is expected. 1.1 is newer than 1.0.

$ python3
Python 3.6.5 (default, Apr 10 2018, 17:08:37)
[GCC 4.8.5 20150623 (Red Hat 4.8.5-16)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import rpm_vercmp
>>> assert rpm_vercmp.vercmp("1.0", "1.1") == -1
>>> assert rpm_vercmp.vercmp("1.1", "1.0") == 1

$ rpmdev-vercmp 1.0 1.1
1.0 < 1.1

However, the results vary when comparing a three-part version to a four-part version. rpmdev-vercmp and yum consider 11.13.2.0-1 to be newer than 11.13.2-1 while this module does not.

$ python3
Python 3.6.5 (default, Apr 10 2018, 17:08:37)
[GCC 4.8.5 20150623 (Red Hat 4.8.5-16)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import rpm_vercmp
>>> assert rpm_vercmp.vercmp("11.13.2-1", "11.13.2.0-1") == -1
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AssertionError
>>> assert rpm_vercmp.vercmp("11.13.2.0-1", "11.13.2-1") == 1
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AssertionError

$ rpmdev-vercmp 11.13.2-1 11.13.2.0-1
11.13.2-1 < 11.13.2.0-1

$ rpm -q mypackage
mypackage-11.13.2-1.noarch

$ sudo yum downgrade mypackage-11.13.2.0-1
Loaded plugins: product-id, search-disabled-repos, subscription-manager
Only Upgrade available on package: mypackage-11.13.2.0-1.noarch
Nothing to do

$ yum update mypackage-11.13.2.0-1
Loaded plugins: product-id, search-disabled-repos, subscription-manager
Resolving Dependencies
--> Running transaction check
---> Package mypackage.noarch 0:11.13.2-1 will be updated
---> Package mypackage.noarch 0:11.13.2.0-1 will be an update
--> Finished Dependency Resolution

Dependencies Resolved

======================================================================================================================================
 Package                        Arch                       Version                          Repository                           Size
======================================================================================================================================
Updating:
 mypackage                      noarch                     11.13.2.0-1                      myrepo                                 1 M

Transaction Summary
======================================================================================================================================
Upgrade  1 Package

Total download size: 79 M
Is this ok [y/d/N]:

One might say that versions should only contain three parts, or that all versions of the same package should have at least the same number of parts. However, that is not always the case. As a real-world example, take git. In CentOS 7, the version contains four parts (1.8.3.1): https://centos.pkgs.org/7/centos-x86_64/git-1.8.3.1-23.el7_8.x86_64.rpm.html whereas in CentOS 8, the version contains three parts (2.27.0): https://centos.pkgs.org/8/centos-appstream-x86_64/git-2.27.0-1.el8.x86_64.rpm.html.

Either way, this appears to be a bug with python-rpm-vercmp as the results don't align with rpm/yum.