Is it a bug in dnf, in ELRepo, or why does kernel-ml-tools want to replace kernel-tools?

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 not kernel-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, now dnf, DiscoverNotifier, plasma-discover, gnome-software, they all want me to “update/upgrade” this:
    Installing kernel-ml-tools replacing kernel-tools
    Installing dependency kernel-ml-tools-libs replacing kernel-tools-libs
  • The funny thing is that it never tried to install either of kernel-lt-tools or kernel-ml-tools as a “replacement” for kernel-tools; it’s only with this build of kernel-ml-tools that it does so!
  • How can I tell whether this bug is ELRepo’s, or dnf’s?
    Of course both kernel-lt-tools and kernel-ml-tools “provide” kernel-tools, but that’s not a reason to force the installation of kernel-ml-tools! Because kernel-lt and kernel-mt also “provide” kernel, and neither are proposed as upgrades to kernel!
    I inspected ELRepo’s spec files for kernel-lt and kernel-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 for kernel-ml. Nope.
    So I can’t tell what was it that suddenly made kernel-ml-tools a mandatory replacement for kernel-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’s kernel, so where’s the bug?

If you look with dnf rq --installonly or dnf rq --installonly --available, you will see that kernel-*tools* are not on those lists. The kernel{,-lt,-ml}{,-core,-modules} etc are a separate topic.

I’d ask from EPEL first, if I were you. It is after all the metadata in their packages that probably guides dnf.

Thank you, but you mean that, because of that, kernel-ml-tools is a legitimate update to (and replacement for)kernel-tools, unless I prevent it e.g. by using priorities?

I know that @toracat has mentioned that there is no reason to replace kernel-headers with kernel-ml-headers, but I don’t know whether that advice applies to tools as well.