Has anyone encountered the following situation? I’m not sure where to report a bug, as the bug might not be ELRepo’s after all.
- I have [elrepo-kernel] enabled, because I need
kernel-lt
(6.1). - I only have
kernel-lt
,kernel-lt-core
,kernel-lt-modules
installed, but notkernel-lt-tools
,kernel-lt-tools-lib
. - I also do not have anything
kernel-mt
installed. - Starting with ELRepo’s
kernel-ml-6.6.2
build of 20-Nov-2023, nowdnf
,DiscoverNotifier
,plasma-discover
,gnome-software
, they all want me to “update/upgrade” this:
Installingkernel-ml-tools
replacingkernel-tools
Installing dependencykernel-ml-tools-libs
replacingkernel-tools-libs
- The funny thing is that it never tried to install either of
kernel-lt-tools
orkernel-ml-tools
as a “replacement” forkernel-tools
; it’s only with this build ofkernel-ml-tools
that it does so! - How can I tell whether this bug is ELRepo’s, or dnf’s?
Of course bothkernel-lt-tools
andkernel-ml-tools
“provide”kernel-tools
, but that’s not a reason to force the installation ofkernel-ml-tools
! Becausekernel-lt
andkernel-mt
also “provide”kernel
, and neither are proposed as upgrades tokernel
!
I inspected ELRepo’s spec files forkernel-lt
andkernel-ml
, and they’re practically identical, bar the differences in names and versions.
I also inspected the changes between 6.6.1 and 6.6.2 forkernel-ml
. Nope.
So I can’t tell what was it that suddenly madekernel-ml-tools
a mandatory replacement forkernel-tools
.
I had to fix this by setting priorities/costs: 1 for [baseos] and 1000 [elrepo-kernel]. Is that a normal thing to do that I wasn’t aware of?
Still, even without these priorities,kernel-mt
didn’t want to replace Alma’skernel
, so where’s the bug?