I’m currently experimenting with Rocky Linux 9 + KDE from EPEL as a desktop.
Besides the official repos, I’m mainly using EPEL and RPMFusion for the third-party stuff. And this is where it gets messy:
# dnf install mplayer
Last metadata expiration check: 0:13:19 ago on Fri 03 May 2024 09:21:03 AM CEST.
Error:
Problem: problem with installed package libswscale-free-5.1.4-2.el9.x86_64
- package ffmpeg-libs-5.1.4-1.el9.x86_64 from rpmfusion-free conflicts with libswscale-free provided by libswscale-free-5.1.4-2.el9.x86_64 from @System
- package ffmpeg-libs-5.1.4-1.el9.x86_64 from rpmfusion-free conflicts with libswscale-free provided by libswscale-free-5.1.4-2.el9.x86_64 from epel
- package mplayer-1.5.1-0.3.20220726svn.el9.x86_64 from rpmfusion-free requires ffmpeg-libs(x86-64), but none of the providers can be installed
Here’s a list of some multimedia-related packages I want to install:
audacious
audacious-plugins-freeworld
audacity
audacity-manual
gstreamer1-libav
gstreamer1-plugins-bad-freeworld
gstreamer1-plugins-ugly
gstreamer1-svt-av1
gstreamer1-svt-vp9
gstreamer1-vaapi
kdenlive
libdvdcss
mencoder
mplayer
vlc
vlc-plugins-freeworld
As far as I can tell, some of the stuff (like kdenlive) depends on ffmpeg-free from EPEL, while some other stuff (like mplayer) depends on ffmpeg from RPMFusion. And some basic KDE stuff (like ffmpegthumbs) also depends on ffmpeg-free.
I’ll answer that myself, since I just found a solution (I think).
Once X11 is installed, I just install ffmpeg from RPMFusion first, and then only I install the KDE package group from EPEL and all the multimedia apps. Looks like the ffmpeg package from RPMFusion has all the corresponding provides information, so ffmpeg-free won’t be installed.
Yes. Dependency resolution is not trivial when multiple packages do provide the same feature.
I’ve had it the other way: had to install something else first in order to remove urge to pull something from RPMFusion.
Put in other words: one cannot simply have one (long) list of “all” packages to install at once. One has to progress in steps (and potentially disable/enable repos for some steps).
Note: RHEL 9.4 became GA last Tuesday. EPEL (and other third-party repos) probably updates their content for it already. Rocky 9.4 is not out quite yet. We are in a twilight zone where packages may be incompatible.
First thing to note is that none of those repos are supported, and nor is KDE. The main issue in the original post is that there are two versions of “ffmpeg”, one in epel, and one in rpmfusion. The error might change depending on which unofficial repos are enabled when running dnf install.
It’s happened to me on Fedora when using epel and rpmfusion, I got in a depedency loop with vlc and associated plugins. I did manage to sort it eventually, but it would make sense if there wasn’t overlap between the repos. Eg, if epel does make vlc, then perhaps the other one shouldn’t. Otherwise, it would be a case of having say epel enabled, and rpmfusion disabled, but only enabled when you actually need a package from it by providing the enablerepo parameter during package installation. That’s about the only sane way right now.
The overlap avoidance is something that the maintainers of the repos would have to agree and coordinate. However, nobody can force smaller repos to adopt a “not if already in EL or EPEL” policy (like EPEL has “not if already in EL” policy).
The VLC is no longer a good example, because it is now only in EPEL. IIRC, the vlc-plugins-freeworld is the only VLC subpackage that EPEL can’t have, so it is in RPM Fusion. (Where I had to juggle was a NVidia’s CUDA repo + RPM Fusion + ELRepo combo.)
That is what I do; keep (most) third-party repos disabled and enable only on need. It is relatively simple with Ansible plays too.
I was surprised about the overlap. I don’t even remember ffmpeg being in epel. Both epel and rpmfusion say that they are associated with Fedora. A few years back, I remember looking at the package lists for both repos and thinking they must talk to each other to avoid clashes.
Both repositories contain only add-on packages and not replacements in relation to the base package set. Whereby the base package set is defined as: RHEL/CentOS + EPEL or Fedora (Fedora 7+)
," I got in a depedency loop with vlc and associated plugins. I did manage to sort it eventually, but it would make sense if there wasn’t overlap between the repos. Eg, if epel does make vlc, then perhaps the other one shouldn’t. "
GREAT!! NOT!!!
I did get RL 9.4 installed and it is GREAT!! The problem that I had was installing either AMAROK or CLEMINTINE – I’m not fussy. I WAS able to to get CLEMENTINE installed via SNAPD / SNAP but that came with a price: /var/log started to fill up lines that said 100% filled that slowed my machine down a tad (I have 128 GiB of RAM) , but it did start to fill up /var/log. So I first killed SNAPD/SNAP and then went in and hand deleted /var/log so I no longer run away processes… I also no longer have CLEMENTINE I then installed VLC. Have not tried it yet
Flatpak can be used to install clementine instead. I personally hate snap/snapd, it’s one of the first things I always remove from an Ubuntu system. Much prefer native packages from rpm/deb repositories than flatpak or snapd. If I have to choose between the two, flatpak is the better option imo.
I have serious concerns about snapd and flatpak, and even people blindly downloading containers, binaries and random rpms, but most people seem happy with it all. The only site I could find, was the hilarious: http://flatkill.org/
That, and packages installed from flatpak etc take up so much more space than if they were installed natively. It’s best to search and hope that an rpm/deb exists first. I use flatpak as a last resort.
I then installed VLC. Have not tried it yet 
