Ошибка invalid version flag or

Перейти к контенту

--> Processing Dependency: python3-libs(x86-64) = 3.6.8-18.el7 for package: python3-3.6.8-18.el7.x86_64 -
--> Package python3-pycparser.noarch 0:2.14-14.el8 will be installed -
--> Package readline.x86_64 0:6.2-11.el7 will be updated 
--> Processing Dependency: libreadline.so.6()(64bit) for package: alt-sqlite-3.26.0-1.1.el7.x86_64 
--> Processing Dependency: libreadline.so.6()(64bit) for package: cpanel-sqlite-3.32.3-1.cp1198.x86_64 
--> Processing Dependency: libreadline.so.6()(64bit) for package: python-libs-2.7.5-91.el7.cloudlinux.x86_64 
--> Processing Dependency: libreadline.so.6()(64bit) for package: alt-php-internal-cli-7.4.22-2.el7.x86_64 
--> Processing Dependency: libreadline.so.6()(64bit) for package: jetlftp-4.9.1.1-1.x86_64 -
--> Package redhat-rpm-config.noarch 0:129-1.el8.alma will be installed Error: Invalid version flag: if

# yum update
ID-CD_epel_redhat-7                | 2.6 kB  00:00:00
ID-CD_epel_redhat-8                | 2.4 kB  00:00:00
rhel-7-server-rpms                 | 2.0 kB  00:00:00
(1/9): ID-CD_epel_redhat-7/group   | 392 kB  00:00:00
(2/9): ID-CD_epel_redhat-7/updateinfo                             | 892 kB  00:00:00
(3/9): ID-CD_epel_redhat-7/primary | 4.9 MB  00:00:00
(4/9): ID-CD_epel_redhat-8/group   | 121 kB  00:00:00
(5/9): ID-CD_epel_redhat-8/updateinfo                             | 455 kB  00:00:00
(6/9): ID-CD_epel_redhat-8/primary | 2.6 MB  00:00:00
(7/9): rhel-7-server-rpms/7Server/x86_64/group                    | 637 kB  00:00:00
(8/9): rhel-7-server-rpms/7Server/x86_64/updateinfo               | 4.1 MB  00:00:00
(9/9): rhel-7-server-rpms/7Server/x86_64/primary                  |  51 MB  00:00:00
ID-CD_epel_redhat-7                                 13592/13592
ID-CD_epel_redhat-8                                 7349/7349
rhel-7-server-rpms                                  31780/31780
.

Error: Invalid version flag: if

Hello,

I attempt to upgrade from 4.1.16-1 to 5.x. So, I followed the steps mentioned here:
https://docs.strangebee.com/thehive/setup/installation/upgrade-from-4.x/#install-thehive_1

However, when I run sudo yum install thehive

I get the the following output:

Resolving Dependencies
--> Running transaction check
---> Package thehive.noarch 0:5.0.9-1 will be installed
Error: Invalid version flag: or

I am on Oracle Linux 7.9

I would like to know how I can fix it.

Thank you in advance for your help and your support.

It’s a simple thing to keep your system updated. A quick yum update every few days — just like brushing your teeth. Completely painless, quick, efficient.

Not today it wasnt.

—> Package screen.x86_64 0:4.1.0-0.26.20120314git3c2946.el7 will be updated
—> Package screen.x86_64 0:4.1.0-0.27.20120314git3c2946.el7_9 will be an update
—> Package skypeforlinux.x86_64 0:8.67.0.96-1 will be updated
—> Package skypeforlinux.x86_64 0:8.71.0.36-1 will be an update
Error: Invalid version flag: or

This was the error I received. Okay, so when yum update fails, there’s always the tried and true command sequence that fixes it:

sudo yum clean all
sudo yum update —skip-broken

This time it didn»t work. I still received the same error. Time to google for more info… 

I found a kool command sequence on John S. De Stefano’s blog that looked promising:

sudo yum check all                # tells you of any problems
sudo package-cleanup —problems   # lists all known package problems
sudo package-cleanup —dupes      # lists duplicate packages
sudo package-cleanup —cleandupes # actually cleans up duplicates
sudo yum check all                # run again to check for remaining problems
sudo yum-complete-transaction —cleanup-only

However, this command sequence failed to fix the issue too. Looks like I’m going to have to work out what’s broken and why. No easy way out with this problem.

Rich Dependencies

Scrolling through bugzilla, I found the following entry:

There was a mistake made in the rpmlib() dep for rich deps. You need
at least rpm 4.13 for the base rich deps, and rpm 4.13.1 for the rest.

yum and related packages are no longer actively developed.
They are being replaced with dnf, dnf-utils, etc.

I’m closing this bug because it’s most likely never going to be fixed.
If you still consider your bug report important, reopen it, please.

https://bugzilla.redhat.com/show_bug.cgi?id=1578942

This was actually a bug report for F28+. Since Fedora uses DNF primarily and YUM is deprecated, no one seemed particularly interested in fixing it in Fedora. RHEL/CentOS 8 both use DNF as well. Could this bug have percolated down into CentOS 7? Time to check rpm versions and make sure I have at least 4.13:

$ yum —showduplicate list rpm

Installed Packages
rpm.x86_64                          4.11.3-45.el7                          @base
Available Packages
rpm.x86_64                          4.11.3-45.el7                          base 

Well, that’s just peachy!

I’m running an old version of rpm that doesn’t support rich dependencies. It also appears that yum may not handle them well either — although the indications are the problem really lies with rpmlib().

I’ve never really spent a lot of time looking at the inner workings of package managers and their respective update managers. Now that ignorance is coming back to haunt me and it’s time for some old fashioned studying the matter.

From rpm.org there’s an excellent description of how the boolean operators work and how they help avoid dependency hell. This is what is being referenced in the error I received. The ‘or’ operator is unknown because my version of rpm is too old. Boolean operators enable what is termed «rich dependencies». Basically providing a logical sequence for resolving dependency issues across multiple versions. A good example is community-mysql and mariadb. Both packages do the same thing — provide a mysql style database. Without rich dependencies, if another package requires mysql, you have to choose which package is required. With rich dependencies you can state:

Package A: Requires: mysql
Package mariadb: Provides: mysql
Package community-mysql: Provides: mysql
Suggests: mariadb to Package A.

Which means that if community-mysql is already installed, that is used as the dependency, otherwise mariadb is installed.

This is really cool, but yum simply ignores it.

Put simply, the root cause of the problem is:

1. RPM supports «rich dependencies»
2. DNF supports resolving packages with «rich dependencies»
3. YUM does not support resolving packages with «rich dependencies»

The solution then is obvious: Since CentOS 7 supports DNF, it’s time to switch. Fiddling with yum and manually resolving the dependencies will only delay the inevitable.

YUM vs DNF 

source

«Dandified YUM» or DNF, is the replacement package update manager for RHEL/CentOS. It’s been part of Fedora for a long time now. I acknowledge it is clearly superior to YUM in most aspects, plus it doesn’t suffer from some of the issues that Debian apt does. The major goal is to eliminate (where possible) dependency hell. But it also has other advantages.

It was also designed to be as drop-in replaceable to yum as possible. It comes very close, but some commands have no equivalent (some of these are deliberate actions). So, for me, if your used to using yum, dnf just represents yet another sequence of commands that must be memorised just to continue doing your job.

I’m not going to bore you with lists here of features, commands, comparisons etc. The links I’ve provided do that well enough. Plus, if you want a deep dive into dnf, you can go here. Suffice it to say that I decided that installing and using dnf was the simplest and most effect potential solution to the immediate and potentially long term problems.

Install DNF on CentOS7

Pretty simple really, however there are a number of dependencies since it leverages by Py2 and Py3. A total of 11 dependent packages were installed, however YMMV.

$sudo yum install dnf
…
Resolving Dependencies
—> Running transaction check
—> Package dnf.noarch 0:4.0.9.2-2.el7_9 will be installed
—> Processing Dependency: python2-dnf = 4.0.9.2-2.el7_9 for package: dnf-4.0.9.2-2.el7_9.noarch
—> Running transaction check
—> Package python2-dnf.noarch 0:4.0.9.2-2.el7_9 will be installed
—> Processing Dependency: dnf-data = 4.0.9.2-2.el7_9 for package: python2-dnf-4.0.9.2-2.el7_9.noarch
—> Processing Dependency: python2-libdnf >= 0.22.5 for package: python2-dnf-4.0.9.2-2.el7_9.noarch
—> Processing Dependency: python2-libcomps >= 0.1.8 for package: python2-dnf-4.0.9.2-2.el7_9.noarch
—> Processing Dependency: python2-hawkey >= 0.22.5 for package: python2-dnf-4.0.9.2-2.el7_9.noarch
—> Processing Dependency: libmodulemd >= 1.4.0 for package: python2-dnf-4.0.9.2-2.el7_9.noarch
—> Processing Dependency: python2-libdnf for package: python2-dnf-4.0.9.2-2.el7_9.noarch
—> Processing Dependency: python-enum34 for package: python2-dnf-4.0.9.2-2.el7_9.noarch
—> Running transaction check
—> Package dnf-data.noarch 0:4.0.9.2-2.el7_9 will be installed
—> Package libmodulemd.x86_64 0:1.6.3-1.el7 will be installed
—> Package python-enum34.noarch 0:1.0.4-1.el7 will be installed
—> Package python2-hawkey.x86_64 0:0.22.5-2.el7_9 will be installed
—> Processing Dependency: libdnf(x86-64) = 0.22.5-2.el7_9 for package: python2-hawkey-0.22.5-2.el7_9.x86_64
—> Processing Dependency: libsolvext.so.0(SOLV_1.0)(64bit) for package: python2-hawkey-0.22.5-2.el7_9.x86_64
—> Processing Dependency: libsolv.so.0(SOLV_1.0)(64bit) for package: python2-hawkey-0.22.5-2.el7_9.x86_64
—> Processing Dependency: libsolvext.so.0()(64bit) for package: python2-hawkey-0.22.5-2.el7_9.x86_64
—> Processing Dependency: libsolv.so.0()(64bit) for package: python2-hawkey-0.22.5-2.el7_9.x86_64
—> Processing Dependency: librepo.so.0()(64bit) for package: python2-hawkey-0.22.5-2.el7_9.x86_64
—> Processing Dependency: libdnf.so.2()(64bit) for package: python2-hawkey-0.22.5-2.el7_9.x86_64
—> Package python2-libcomps.x86_64 0:0.1.8-14.el7 will be installed
—> Processing Dependency: libcomps(x86-64) = 0.1.8-14.el7 for package: python2-libcomps-0.1.8-14.el7.x86_64
—> Processing Dependency: libcomps.so.0.1.6()(64bit) for package: python2-libcomps-0.1.8-14.el7.x86_64
—> Package python2-libdnf.x86_64 0:0.22.5-2.el7_9 will be installed
—> Running transaction check
—> Package libcomps.x86_64 0:0.1.8-14.el7 will be installed
—> Package libdnf.x86_64 0:0.22.5-2.el7_9 will be installed
—> Package librepo.x86_64 0:1.8.1-8.el7_9 will be installed
—> Package libsolv.x86_64 0:0.6.34-4.el7 will be installed
—> Finished Dependency Resolution

Dependencies Resolved

Next I tried dnf update:

$ sudo dnf update
<snip>
Running transaction check
Error: transaction check vs depsolve:
(libatomic or libatomic1) is needed by skypeforlinux-8.71.0.36-1.x86_64
rpmlib(RichDependencies) <= 4.12.0-1 is needed by skypeforlinux-8.71.0.36-1.x86_64
To diagnose the problem, try running: ‘rpm -Va —nofiles —nodigest’.
You probably have corrupted RPMDB, running ‘rpm —rebuilddb’ might fix the issue.
The downloaded packages were saved in cache until the next successful transaction.
You can remove cached packages by executing ‘dnf clean packages’.

DNF is smart enough to know why the update failed. The package ‘skypeforlinux’ uses rich dependencies. These dependencies require a version of rpmlib that is greater than the CentOS 7 repositories can provide. Therefore, the dependencies cannot be resolved. There’s a tip there to use rpm directly to reconcile the issues, but since I know that the version of rpm is also too low, that won’t work.

I decide that I can live without skypeforlinux, so I remove it and both dnf and yum are happy.

At this point in time, since both work, I can use either to keep my system updated. However, having installed dnf and now that I’m comfortable working with it (having learned the syntax and equivalent commands) I think I’ll use it from now on.