Brim install failure on CentOS 7.8

[philrz]

A community user pointed out on public Slack that an attempt to install Brim fails on CentOS 7.8.

I've reproduced this on a scratch VM. Here's the not-too-helpful error message one gets when simply double-clicking the RPM package from the file utility:

I'm not sure precisely what's behind the install process it's trying to invoke, but being a RedHat-flavored distro, I assume it's yum, especially since I found dnf was not installed by default.

Here's an example of the failure during an attempt to install via yum:

$ sudo yum install brim_x86_64_v0.15.1.rpm 
[sudo] password for phil: 
Loaded plugins: fastestmirror, langpacks
Examining brim_x86_64_v0.15.1.rpm: brim-0.15.1-1.x86_64
Marking brim_x86_64_v0.15.1.rpm to be installed
Resolving Dependencies
--> Running transaction check
---> Package brim.x86_64 0:0.15.1-1 will be installed
Error: Invalid version flag: or

When I search for that error message online, I find mention of others struggling with this error message when their RPMs contain "rich dependencies", and these same threads imply yum is not able to deal with them. That in turn led me to this article that talks about boolean logic to express dependencies in newer versions of RPM, which I assume is the origin of the or.

What I don't know is if we put that boolean logic in there ourselves and could express it in a yum-compatible way instead.

Also, for kicks I tried installing dnf and seeing if that would be a viable workaround. Alas, that doesn't seem to work out-of-the-box either:

$ sudo dnf install brim_x86_64_v0.15.1.rpm 
CentOS-7 - Base                                 974 kB/s |  10 MB     00:10    
CentOS-7 - Updates                              2.5 MB/s | 4.2 MB     00:01    
CentOS-7 - Extras                               574 kB/s | 275 kB     00:00    
Dependencies resolved.
================================================================================
 Package             Arch         Version              Repository          Size
================================================================================
Installing:
 brim                x86_64       0.15.1-1             @commandline       165 M
Installing dependencies:
 libXScrnSaver       x86_64       1.2.2-6.1.el7        base                24 k

Transaction Summary
================================================================================
Install  2 Packages

Total size: 165 M
Total download size: 24 k
Installed size: 528 M
Is this ok [y/N]: y
Downloading Packages:
libXScrnSaver-1.2.2-6.1.el7.x86_64.rpm          122 kB/s |  24 kB     00:00    
--------------------------------------------------------------------------------
Total                                            75 kB/s |  24 kB     00:00     
Running transaction check
Error: transaction check vs depsolve:
(kde-cli-tools or kde-cli-tools5 or kde-runtime or trash-cli or glib2 or gvfs-client) is needed by brim-0.15.1-1.x86_64
(libXtst or libXtst6) is needed by brim-0.15.1-1.x86_64
(libnotify or libnotify4) is needed by brim-0.15.1-1.x86_64
(libuuid or libuuid1) is needed by brim-0.15.1-1.x86_64
(nss or mozilla-nss) is needed by brim-0.15.1-1.x86_64
rpmlib(RichDependencies) <= 4.12.0-1 is needed by brim-0.15.1-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'.

[philrz]

Perhaps we could revive the topic of Flatpak (#685) as a catch-all for this & any other Linux distros that have these kinds of problems. At one time that issue was blocked because Zeek had a problem that prevented us from easily creating a Flatpak release, but the fix in zeek/zeek#928 has theoretically unblocked us from that. Granted, this still might not be a perfect approach since I expect users of RedHat/Debian-derived distros would often still likely try .DEB/.RPM packages first and report it as a problem when it doesn't work rather than jumping on their own to trying Flatpak (personally, I'd never even heard of Flatpak until a community user suggested it). However, it would arguably be a better Support response than just keeping a list of known distros Brim doesn't install on at all and having no workaround to offer.

[philrz]

Incidentally, I just happened to try installing GA Brim v0.19.0 on Fedora 21 and saw the same symptom.

$ sudo yum install brim_x86_64_v0.19.0.rpm 
[sudo] password for phil: 
Loaded plugins: langpacks
Examining brim_x86_64_v0.19.0.rpm: brim-0.19.0-1.x86_64
Marking brim_x86_64_v0.19.0.rpm to be installed
Resolving Dependencies
--> Running transaction check
---> Package brim.x86_64 0:0.19.0-1 will be installed
Error: Invalid version flag: or

[philrz]

I'm circling back with an update on this. We recently embarked on a fairly exhaustive testing effort that led to publishing more thorough Supported Platforms guidance that cautions users away from even trying to run on these older distros due to this/other failures. It's now confirmed that while this issue is consistently present on older RedHat-flavored distros cited above like CentOS v7.8 and Fedora 21, it's consistently not a problem on newer distros like CentOS 8+ or Fedora 28+. While those older distros are not EOL for a while yet, the less-sophisticated packaging format that causes this issue is rapidly falling out of favor and hopefully more & more users will continue over time to run newer distros for security/functionality/other reasons. Therefore we're going to close this issue as a "Won't Fix".

[thewhitegrizzli]

Why wont fix i have this issue too!

[philrz]

@thewhitegrizzli: Would it be possible for you to upgrade to one of the newer Linux distros that doesn't have this problem? As Brim relies on modern Dev tooling, we've found problems getting it to work on older distros such as this. Since we have limited resources in the core Dev team, we're focused largely on delivering new functionality and bug fixes that will benefit lots of users, whereas adapting to the constraints of the older distros would be a significant investment with limited returns as more & more users upgrade to newer distros over time. Since our code is open source, community users are certainly welcomed to look into what it might take to make Brim work on older distros and we're open to reviewing Pull Requests. But given the hundreds of other priorities on the to-do list for the core Dev team, we just like to set expectations that it's unlikely we'll be able to get to it. I'm hopeful you can still find a way to use Brim.