Hi,
There’s a slightly newer Qt in 8.7, which breaks EPEL’s KeePassXC. I’m planning to file a bug report on that, but in the meantime, feel free to use my own rebuild of KeePassXC:
https://www.microlinux.fr/pub/rockylinux/8/x86_64/packages/keepassxc-2.7.1-8.el8.x86_64.rpm
Cheers,
Niki
Thanks for that. I noticed the problem as well.
On a side-note: I’m a bit puzzled as to why someone defines a dependency with an equal sign “=” to a version number of a library instead of greater-or-equal “>=” which should probably have solved (rather: avoided) the whole issue.
Fair enough, there may have been reasons to do so in order to make sure we get a stable installation, yes, …but it still feels like kinda too picky to me.
Well, that and the unsigned tzdata lately did cause me more headache than all updates since 8.4. 
Still, rocky is my favourite distro.
Cheers, Thomas
Maybe, but ‘epel’ is not an official supported repo, so it’s impossible for them to know every future direction of RHEL (a moving target).
Using >= means they can anticipate in the future there will be newer versions of packages. It’s actually pretty much guaranteed things will move forward and not remain on the same old version.
To add on to this, it really depends on the software. If you are using >= you are taking a gamble that the new versions of those libraries will not have API changes that will affect what you’ve built. Some software and libraries are API stable like that. If you are using = you are saying that it is exact and must be recompiled at some point, because there’s a chance the new version must be recompiled (note that this isn’t the only case). Not only that, this is what can cause a “compat” package to appear for some scenarios, for stuff that can’t be compiled on the newer version because of all the heavy changes (and thus requires a rewrite), so there’s a compatibility layer somewhere instead.
Packages also have cases where they specifically say “yes we require this specific library and version” as a result of AutoReqProv, which long story short helps determine some of the dependencies it needs. qt is a perfect example of this. The moment you build a new qt5 base package, all the other qt5 packages must be rebuilt. That is the nature of the qt ecosystem.
That’s exactly the case for KeePassXC. Here’s the corresponding comment from the specfile:
# enforces on the user system, Qt version to be the same one used to build KeepassXC
# This avoids "not a bug" bugreports like this one
# https://bugzilla.redhat.com/show_bug.cgi?id=2068981
%{?_qt5:Requires: %{_qt5}%{?_isa} = %{_qt5_version}}
Cheers,
Niki
Looks like keepassxc-2.7.1-8.el8 has just been released to the epel main repository.
I’ve had version 2.7.1-8 installed since July. Checked Index of /pub/epel/8/Everything/x86_64/Packages/k and it looks like it’s the same version still?
keepassxc-2.7.4-4
I just updated my main desktop computer (this one) and haven’t encountered any issues.
As noted above keepassxc was a showstopper up to today, so this appears to be a solved problem.