FYI: EPEL9: "KDE Plasma Workspaces" only installable in 9.4, not in 9.3

General Discussion & Chat
1

EPEL Bug 2279322 - kf5-libkdcraw-23.08.5 is not installable, making “KDE Plasma Workspaces” not installable

Following EPEL’s upgrade from KDE 5.27.6 / KF 5.108.0 to KDE 5.27.11 / KF 5.115.0, there are unmet dependencies that lead to KDE being uninstallable.

kf5-libkdcraw-23.08.5 seems to be the main culprit. Systems that already had KDE 5.27.6 / KF 5.108.0 can upgrade to KDE 5.27.11 / KF 5.115.0 as long as they have kf5-libkdcraw-23.04.3 installed; but non-KDE systems cannot groupinstall "KDE Plasma Workspaces" not even with --nobest --skip-broken, because some version of kf5-libkdcraw is required, and the only one in the repo is not installable.

Here’s the current error message:

  Problem 1: package kdegraphics-thumbnailers-23.08.5-1.el9.x86_64 from 
epel requires libKF5KDcraw.so.5()(64bit), but none of the providers can 
be installed
   - conflicting requests
   - nothing provides libraw.so.23()(64bit) needed by 
kf5-libkdcraw-23.08.5-1.el9.x86_64 from epel
  Problem 2: package gwenview-1:23.08.5-2.el9.x86_64 from epel requires 
libgwenviewlib.so.5()(64bit), but none of the providers can be installed
   - package gwenview-1:23.08.5-2.el9.x86_64 from epel requires 
gwenview-libs(x86-64) = 1:23.08.5-2.el9, but none of the providers can 
be installed
   - package gwenview-libs-1:23.08.5-2.el9.x86_64 from epel requires 
libKF5KDcraw.so.5()(64bit), but none of the providers can be installed
   - conflicting requests
   - nothing provides libraw.so.23()(64bit) needed by 
kf5-libkdcraw-23.08.5-1.el9.x86_64 from epel

As a temporary workaround, the affected users could temporarily enable epel-testing, then install KDE using sudo dnf groupinstall "KDE Plasma Workspaces" --nobest --skip-broken, as there is a non-installable ImageMagick in epel-testing that should be skipped. This is not to be recommended on production systems, but I tested it in a VM on AlmaLinux 9.3 MATE, and it led to a fully functional KDE 5.27.11 / KF 5.115.0 with both X11 and Wayland.

2

Thanks for the heads up.

There are almost always minor pain points like this for some EPEL packages after a minor version update. It usually takes EPEL about a week to get the new builds that fix this into production.

Testing and upvoting the updates in https://bodhi.fedoraproject.org/ can help this happen faster.

3

Still, I failed to see how they tested this upgrade. It was a mass upgrade of KDE LTS to the next patch level. The most elementary test were to have a VM with a plain EL9 with e.g. GNOME, and try a groupinstall. They obviously never tried that.

I only noticed the issue on the users mailing list, as my upgrade worked due to having kf5-libkdcraw-23.04.3 installed, which provides libKF5KDcraw.so.5. But I wanted to try to build a custom 9.4 Live ISO with KDE, and I couldn’t even start, as EPEL is broken.

Sometimes, I wonder why don’t I use Kubuntu.

OTOH, I know why I don’t use Fedora anymore. (Even more obvious now, when they force KDE6 on their users. Maybe when 6.2 is released, but not now. KDE5 wasn’t really stable before 5.4.)

4

They were able to build and test against CentOS Stream while it was tracking 9.4.

This is only caused by the mandatory 1w waiting period (assuming no karma) on updates within Fedora/EPEL. EPEL is a Fedora project, not part of RHEL, so there is a tad bit of time where things don’t line up 1:1.

EPEL10 will help address this. See EPEL 10 proposal - Fedora Discussion

Fedora is solid. One of the key principles in Fedora is “First” meaning pushing the boundaries of the software. FWIW I’ve been running KDE6 on Fedora 40 since it was BETA and it’s been nothing but exceptional. KDE has come a looong way in the past few years and they’re publishing really good, generally stable software these days much faster than they used to.

5

Sorry, but I have to contradict you.

  1. Only epel9-next is built and tested against CentOS Stream 9; epel9 is built and tested against RHEL 9.x, as it should be. See the 4th table in the aforementioned EPEL10 proposal. But I failed to understand what the proposal was for EPEL10. And the comments gave me a headache: everything lacks clarity. I’m afraid EPEL is going down the drain. After all, it’s a Fedora project.

  2. CentOS Stream is too much demonized. The upgrades between, say, EL 9.3 and 9.4 aren’t that important, but upgrading a system from 9.3 to 9.4 can be extremely painful because all the updates come at once. If packages were upgraded continually, as it’s the case with CentOS Stream, I’m pretty sure things would take place smoother.

To give an extreme example: updating Arch, Endeavour, Manjaro, etc. only leads to occasional breakages, if the system is continuously updated. But leave a system shut down for a year and try upgrading it. It will break with 99.9% certainty!

Sure thing, EL8.x and EL9.x upgrades from x to x+1 are more important than e.g. Debian’s 12.x to 12.x+1 updates. I’d prefer packages to receive some upgrades, like in EL, but continuously, like in Debian. Or like in CentOS Stream, so we really have some updates, not just security patches.

Most people don’t understand what CentOS Stream is. It’s frigging NOT the path to EL10! It’s the path to 9.4, 9.5, and so on. It’s the way EL should be.

The problem with CentOS Stream is the shorter support. Otherwise, I’d be using it. This, and the fact that rpmfusion and ELRepo don’t support epel9-next (although the extra kernels from ELRepo would almost certainly always work).

  1. No, Fedora is not a solid distro. It’s the only distro that froze several PCs in my household after a kernel upgrade. Twice.

Because Fedora is a complete lie. Oh, it’s not a rolling-release distro, but it continuously upgrades the kernel during a point release, despite the fact that any kernel is supported for more than 6 to 9 months, so at least the frigging kernel could be stable during a point release of Fedora!

Instead of keeping the kernel stable, Fedora keeps most packages stable (although it can update e.g. KDE during a point release), while upgrading the kernel to whatever the newest one is. This is utterly idiotic!

Arch and Manjaro, despite being rolling-release, allow you to keep a stable kernel, to have at least the heart of the OS stable! You can choose between several kernels, including at least one LTS kernel! That, in a rolling-release distro!

Fedora is unusable specifically because it can’t frigging guarantee you a kernel version, not even for 6 months. Then they wonder why they lose people to Arch & the gang.

  1. I tried Fedora 40 KDE. No, KDE 6.0.x isn’t there yet. No given software is stable enough at any .0 version. And there are things not working yet. After all, it’s been a porting from Qt5 to Qt6, right? Not a minor task.
6

Well yes. Sorry if I wasn’t clear about that. My only point is that through CentOS Stream the builds can be prepared and tested for upcoming RHEL releases.

tl;dr of the proposal is that EPEL will track minor RHEL versions, meaning as long as you’re on say 10.2, you’re getting EPEL 10.2 builds. Part of the problem right now is that RHEL comes first, followed by rebuilds. Fedora/EPEL maintainers may try and wait on some rebuilds to catch up/release the update to prevent breakage, which results in breakage for others…it’s not a perfect solution.

The proposal will let CentOS stream builds against the upcoming minor release be immediately available. Breakages like we’re seeing right now should be virtually eliminated.

This isn’t due to lack of “continual updates”. The comment above about the EPEL10 proposal pretty much addresses it.

Been there done that with Arch. It’s no fun for sure.

[quote=“ludditus, post:5, topic:3961, full:true”]
Most people don’t understand what CentOS Stream is. It’s frigging NOT the path to EL10! It’s the path to 9.4, 9.5, and so on. It’s the way EL should be.

The problem with CentOS Stream is the shorter support. Otherwise, I’d be using it. This, and the fact that rpmfusion and ELRepo don’t support epel9-next (although the extra kernels from ELRepo would almost certainly always work).[/quote]
It’s both. There are multiple versions of CentOS Stream which track both paths (Stream 10 is coming together pretty quickly)

I’d suggest stable-1 - don’t use the latest stable but 1 version older stable. It’s still supported for ~7 months after latest stable.

Only a few packages have update exceptions that let them update during a cycle, kernel being one of them.

So stick with 39 for a while. KDE 6.1 is coming to F40 soon :slight_smile:

7

That’s a good idea, actually.

I wasn’t talking about upgrades EPEL-wise, but only EL-wise. But knowing that most breakages come from EPEL… it makes sense. Although some people can have issues even when not using 3rd-party repos. This is why I said that the entire EL should be… Stream-like.

I’d never use Fedora-1. And I thought it’s only supported for 3-4-5 months after the next point release. Whatever, not a fix.

KDE too. And not only it. I’ve lived it more than once, so I don’t care what they say in that document that I won’t read. They’re lying. Facts are facts.

I cannot stick to something I don’t use. I’d rather install Kubuntu 24.04 than install Fedora again.

8

Not every distro fits every person or use-case. The beauty of open source is that you have choices.

9

Nah. We would need a couple of solid distros. Instead, we have ~200 pathetic ones. That’s divide and impera, and the reason why most people use Winbloat.

There is absolutely no distro to have, simultaneously:

  • a stable kernel, or more stable LTS kernels
  • the option to use one of several versions of the apps, not necessarily the latest one (but to have the last one available)
  • the guarantee of having the minor updates if one chooses to stay with a major version (Debian stable does NOT update version 1.2.3 to 1.2.4, but only patches 1.2.3-1 to 1.2.3-2 if it’s a security issue)
  • and I mean by using the package management system, not Flatpaks, snaps, AppImages and whatnot; also, no immutable crap
  • finally, because of the stupid Linux kernel architecture, one cannot have a new driver for a new device, unless they install a new kernel; a driver cannot be installed over an existing kernel, like it’s always been the case with Windows

This is why Windows is what it is. And this makes me sad. If I were to use Win10/11, which I don’t, I could:

  • use whatever version of a software I want: the latest one, or a previous branch
  • install a driver, just a new driver, not a whole new frigging kernel

I’m using Linux because it’s the smaller evil, not because it’s good. It ain’t. It’s broken by design. Still, it gives me more freedom.

Open source, you said? Then why are NetBSD and FreeBSD still almost as useless as they were in 1994-1995? For a laptop usage, that is. No installable Live ISOs with full desktop environments, no proper HW support, nothing.

10

The kernel is one of the pain points, definitely… Fedora does not have the manpower to keep backporting kernel fixes, so the same kernel is rolled out across all supported releases. This makes the kernel test weeks super important - especially for people who rely on say Nvidia proprietary drivers.

Every Fedora release is actually supported until 2N+1 - so Fedora 38 is supported until 1 month after Fedora 40 comes out, etc. You might be thinking of Ubuntu where the non-LTS versions are sunset not long after the next release is out.

11

An LTS kernel is supported for 2+ years. So what’s to be backported? Nothing!

Either way, it’s funny how Arch, which can’t maintain a proper installer for lacking the manpower (therefore they have none), can support several kernels, including LTS ones. OK, only EndeavourOS and Manjaro have GUI tools to manage several kernels, but even Arch has the rolling linux, plus linux-lts.

Fedora can’t be bothered to have a kernel-lt (I’m using the name from ELRepo). Even when they manage to use an LTS version, they swiftly move to the next version when it’s released, because their users are guinea pigs, that’s why. Although, frankly, I don’t see the utility of the short-lived kernel versions. They’re just a bad idea. The Torvalds genius cannot be bothered with common sense.

You’re perfectly right.

12

Yeah, I do agree having an LTS kernel as an option would be nice. Debian ships it by default so they do get some testing.

It is not impossible to have multiple kernels - the Asahi project has to maintain a custom kernel because it has a lot of kernel patches that are still out-of-tree - so that might be an interesting project if someone wants to take it on[1]

  1. not me, I’m swamped for the next few months ↩︎

13

Not going to happen. It has been discussed countless times. No resources, etc. So they do have the resources to test a new kernel every single time one is released, yet they cannot stick to a LTS kernel as long as the upstream is supporting it!

By any normal logic, this doesn’t make any sense. Instead of upgrading to, say, 6 major kernel versions, they could just stick to a LTS.

They test my royal butt. Fedora’s kernels are, in my experience, the worst of all. This might be upstream’s fault, I grant you that, but this happens because upstream and Fedora change the kernel versions too fast, too often.

14

It’s… tricky right. Without Fedora dogfooding the kernel the upstream kernel is likely going to be even buggier. Chicken and egg situation.

But yeah that’s why having an LTS would actually be nice as you said, at least as an option.

One way forward could be to ask the vanilla kernel folks to add LTS to the kernels they build in COPR.

1 Like
15

Indeed, this would be nice. But it would require one to believe in Tooth Fairy. Not at my age.

16

Another issue I should have realized. There is no EPEL for 9.3 and EPEL for 9.4. So something might/could/would/will be broken: either 9.3, or 9.4.

One more reason to follow the CentOS Stream model.

I could not test on an AlmaLinux 9.4 fresh non-KDE install, but after having upgraded my AlmaLinux 9.3 KDE to 9.4, I noticed that the 3 non-upgradeable packages now were installable, including the infamous kf5-libkdcraw-23.08.5!

But one cannot install KDE in 9.3.

Which means that the EPEL model is broken. I should have realized this long ago. Dumb me. Without EPEL, there is no way I could use EL, because I cannot use GNOME.

17

I closed myself the bug that I reported. NOTABUG.

“KDE Plasma Workspaces” installs just fine on 9.4 (tested on AlmaLinux 9.4 Minimal Install). It only fails to install on 9.3.

The situation is likely due to the fact that there is a unique EPEL9, not EPEL9.3 and EPEL9.4, and the KDE upgrade released after the release of EL9.4 wasn’t supposed to work with EL9.3.

I suppose we tend to forget that we should upgrade to the next point release ASAP.

Which brings me again to the furious rant: why on Earth is EL structured on x.y releases, as long as, without an EUS, the previous x.y release isn’t supported? What I mean is that, to the extent of my very little knowledge, 9.3 is not supported with updates once 9.4 is out, not for a single day, unless one pays for EUS. This is beyond stupid. A continuous upgrade à la Stream makes much more sense.

Furthermore, as long as EPEL is not split into dot releases, i.e. there is EPEL9, but no EPEL9.3, EPEL9.4, etc., it’s bound to break the previous dot-release. So at one moment EPEL is broken because it doesn’t yet have the packages for EL9.4, and the next day it breaks EL9.3 because it has packages built for EL9.4! How are people even using EPEL? In all these years, I never thought of this, but now that I do, I realize how stupid EPEL’s design is.

Even with the changes to be adopted with EL10, EPEL9 and EPEL8 will keep being broken by design.

I seriously consider switching to CentOS Stream 9 and epel9-next, but only with Synergy from AlmaLinux still works with such a setup. Unfortunately, I’m too pissed off to experiment and to replace the OS in my computers, so I’ll probably go on with AlmaLinux 9.4, while cursing the completely retarded idiots who designed the point releases in EL, and the non-point releases in EPEL.