EPEL broken... now what?


Here’s what I get when I try to update a box running Rocky Linux 9 with KDE from EPEL:

# dnf update
 Problem: cannot install the best update candidate for package kf5-libkdcraw-23.04.3-2.el9.x86_64
  - nothing provides libraw.so.23()(64bit) needed by kf5-libkdcraw-23.08.5-1.el9.x86_64 from epel
(try to add '--skip-broken' to skip uninstallable packages or '--nobest' to use not only best candidate packages)

Now I know this is due to Red Hat having published RHEL 9.4 and EPEL following closely.

Any advice on how to handle this? Is there some timeline to address to resolve this kind of issue?



Suggest waiting until Rocky 9.4 is released. This is unfortunately what happens when there is a new RHEL release that EPEL follows. Nothing you can do until Rocky 9.4 is released.


Just curious : is this a matter of days ? Or more like weeks ? I know the maintainers are already doing some great work. Just wanted to know what to expect.

Testing is in progress, of ISO’s, etc, so I expect days max.

1 Like

you can peek on the stg repo it has the pre release


they just released the rc1 of 9.4

and have a nice day everyone :slight_smile:


Looks like the new LibRaw requires rebuilding some epel packages for 9.4.


out of curiosity, how does the REHL update cause epel to start refusing to provide packages even though epel itself hasn’t updated?

Just trying to workout if there’s something we can do in our build pipeline to avoid this sort of issue in the future as it is currently blocking us from building docker containers .

Edit: my interim workaround is to just install the centos version

 yum -y install \
    # renovate: datasource=yum repo=rocky-9-extras-x86_64
    epel-release-9-7.el9 \
    # TODO: Remove this once 9.4 is out
    https://mirror.stream.centos.org/9-stream/AppStream/${ARCH}/os/Packages/LibRaw-0.21.1-1.el9.${ARCH}.rpm \

EPEL packages certain software and libraries that hook into dependencies that are in EL. These dependencies may have a specific ABI. Once that ABI changes, everything that relies on it must be rebuilt. For example, EPEL provides KDE Plasma packages. If qt5 packages update in EL, just about everything related to KDE in EPEL must be rebuilt. There’s no getting around this.

What sometimes happens is some packages may get rebuilt in EPEL when RHEL is released. Rebuilds/derivatives (like Rocky Linux) don’t release on the same day as RHEL, so folks who may be using KDE for example will fail to update their systems until we release a new package.

Until Rocky Linux 9.4 comes out, there’s nothing more that can be done.


I’d add to that that EPEL is not “one”, unlike RHEL and Rocky.
There was a moment, when all packages of RHEL 9.4 became available.
There will be a moment, when all packages of Rocky 9.4 become available.

EPEL is not “all at once”, but a community of maintainers. All (new) packages
are not released simultaneously. They come when/if they get (re)built (and tested).

You seem to be focusing on the present and not the historical context because that is not how it was historically. This means very recently maintainers and EPEL sig leaders have actually decided to think about the derivatives rather than just RHEL. It is only a recent occurrence that somethings (not all) are held back until the other derivatives are ready. Yes, it remains at maintainer’s discretion.

Note that 10 will be much cleaner/easier in this regard as they will maintain 10.X directories, with 10.X+1 in development and made “stable” once a minor release is available.

1 Like

The present affects today, doesn’t it?


The full discussion for the EPEL 10 proposal is listed here.



I submitted a bug to the Red Hat/Fedora Bugzilla, and they told me that it’s because Rocky tracks RHEL 9.3 at the moment… so being an adventurous systems engineer, I went and found the Alma 9.4 srpm, downloaded it, built it, and installed it. No complaints along the way when I did.

Not a good idea, since Alma doesn’t track RHEL anymore. You’ve just compiled and installed something that now means your system has diverged from Rocky. You should have just waited until Rocky releases 9.4 shortly.

1 Like

CentOS 9 Stream has the same one… LibRaw-0.21.1-1.el9.src.rpm

Even worse, since stream also isn’t Rocky Linux, so doing what you have done is a bad idea. Rocky 9.4 will be released shortly, so it’s just silly doing such things like that.

1 Like

You can just replace $releasever with 9.3 in

sed -i 's/\$releasever/9.3/g' /etc/yum.repos.d/rocky.repo
sed -i 's/\$releasever/9.3/g' /etc/yum.repos.d/rocky-extras.repo

then revert it later on

sed -i 's/9.3/\$releasever/g' /etc/yum.repos.d/rocky.repo
sed -i 's/9.3/\$releasever/g' /etc/yum.repos.d/rocky-extras.repo
1 Like

Thank you! I need quick fix right now and this worked smoothly.


I am uncertain what to think…I just downloaded and created a workstation with 9.4 DVD yet the problem is still there. Have I done something wrong? I cannot install anything, even after a yum update to ensure that everything was up to date.