Fedora Account System
Red Hat Associate
Red Hat Customer
On AlmaLinux 10.1 (x86_64_v2) with EPEL 10 enabled, system updates fail because plasma5support from EPEL requires libgps.so.30()(64bit), but DNF cannot complete the transaction when the distro repository offers gpsd with an Obsoletes relationship against gpsd-libs.My system has: plasma5support-6.4.5-2.el10_1.alma_altarch.x86_64_v2 installed from EPEL gpsd-libs-1:3.25-17.el10_0.alma_altarch.x86_64_v2 installed from EPEL gpsd-1:3.26.1-1.el10.x86_64_v2 available from AppStream dnf repoquery --whatprovides 'libgps.so.30()(64bit)' shows that only gpsd-libs-1:3.25-17... provides libgps.so.30 in this repository set. During dnf update, DNF tries to move forward due to gpsd (AppStream) obsoleting gpsd-libs < 1:3.26.1-1.el10, but then plasma5support still requires libgps.so.30, and the solver cannot find an installable provider, causing the update to fail.This blocks not only CLI updates (dnf update) but also GUI updates (Discover/PackageKit), since the transaction never resolves.Steps to Reproduce Install AlmaLinux 10.1 (x86_64_v2). Enable EPEL 10 repository. Install KDE/Plasma stack including plasma5support from EPEL. Run: dnf update Actual Resultsdnf update fails with a dependency resolution error similar to: plasma5support requires libgps.so.30()(64bit) gpsd from AppStream obsoletes gpsd-libs < 1:3.26.1-1.el10 DNF cannot install a consistent set of packages satisfying both constraints (Full command outputs included below.)Expected Resultsdnf update should complete successfully with EPEL enabled, without requiring transaction flags like --allowerasing, --skip-broken, or --nobest.Installed PackagesOutput of dnf list --installed plasma5support 'gpsd*': gpsd-libs.x86_64_v2 1:3.25-17.el10_0.alma_altarch @epel plasma5support.x86_64_v2 6.4.5-2.el10_1.alma_altarch @epel Enabled RepositoriesOutput of dnf repolist --enabled: appstream (AlmaLinux 10 - AppStream) baseos (AlmaLinux 10 - BaseOS) crb (AlmaLinux 10 - CRB) extras (AlmaLinux 10 - Extras) epel (Extra Packages for Enterprise Linux 10 from AlmaLinux - x86_64_v2) Provider Check for the Required SONAMEOutput of dnf repoquery --whatprovides 'libgps.so.30()(64bit)': gpsd-libs-1:3.25-17.el10_0.alma_altarch.x86_64_v2 Package Info (available versions)Output of dnf repoquery --info gpsd gpsd-libs (relevant fields): gpsd Epoch: 1 Version: 3.26.1 Release: 1.el10 Repo: appstream gpsd-libs Epoch: 1 Version: 3.25 Release: 17.el10_0.alma_altarch Repo: epel gpsd-libs Epoch: 1 Version: 3.26.1 Release: 1.el10_1.alma_altarch Repo: epel Notes / ImpactThis appears to be a cross-repo dependency/obsoletes interaction where: EPEL plasma5support depends on libgps.so.30 AppStream gpsd introduces an obsoletes rule against older gpsd-libs The transaction becomes unsatisfiable, blocking updates Please advise whether plasma5support should be rebuilt/adjusted to depend on the newer SONAME (if applicable), or whether a compatibility provider for libgps.so.30 is expected in EPEL for EL10 environments.
Hello, This seems to be happening again on EL 10.2: [root@mypc ~] # dnf upgrade Last metadata expiration check: 0:01:44 ago on jue 13 ago 2026 13:31:42. Error: Problem: package plasma5support-6.6.4-1.el10_2.x86_64 from @System requires libgps.so.31()(64bit), but none of the providers can be installed - package gpsd-1:3.26.1-3.el10_2.1.x86_64 from local-appstream obsoletes gpsd-libs < 1:3.26.1-3.el10_2.1 provided by gpsd-libs-1:3.26.1-3.el10_2.x86_64 from @System - package gpsd-1:3.26.1-3.el10_2.1.x86_64 from local-appstream obsoletes gpsd-libs < 1:3.26.1-3.el10_2.1 provided by gpsd-libs-1:3.26.1-3.el10_2.x86_64 from local-epel - package gpsd-1:3.26.1-3.el10_2.1.x86_64 from local-appstream obsoletes gpsd-libs < 1:3.26.1-3.el10_2.1 provided by gpsd-libs-1:3.26.1-3.el10_2.x86_64 from epel - cannot install the best update candidate for package plasma5support-6.6.4-1.el10_2.x86_64 - cannot install the best update candidate for package gpsd-libs-1:3.26.1-3.el10_2.x86_64 (try to add '--skip-broken' to skip uninstallable packages or '--nobest' to use not only best candidate packages) [root@mypc ~] # dnf list --showduplicates gpsd\* Last metadata expiration check: 0:00:33 ago on jue 13 ago 2026 13:31:42. Installed Packages gpsd-libs.x86_64 1:3.26.1-3.el10_2 @System Available Packages gpsd.x86_64 1:3.26.1-3.el10 appstream gpsd.x86_64 1:3.26.1-3.el10_2.1 appstream gpsd-clients.x86_64 1:3.26.1-3.el10 appstream gpsd-clients.x86_64 1:3.26.1-3.el10_2.1 appstream gpsd-devel.x86_64 1:3.26.1-3.el10_2 epel gpsd-libs.x86_64 1:3.26.1-3.el10_2 epel
I just noticed, it's not that plasma5support needs a rebuild, it's that gpsd is obsoleting gpsd-libs ... yuck. So, the reality is that this is a duplicate of #2498939. Working on it.
FEDORA-EPEL-2026-70d981126c (gpsd-epel-3.26.1-3.el10_2.1) has been submitted as an update to Fedora EPEL 10.2. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2026-70d981126c
FEDORA-EPEL-2026-70d981126c has been pushed to the Fedora EPEL 10.2 testing repository. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2026-70d981126c See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-EPEL-2026-70d981126c (gpsd-epel-3.26.1-3.el10_2.1) has been pushed to the Fedora EPEL 10.2 stable repository. If problem still persists, please make note of it in this bug report.