Red Hat Bugzilla – Bug 1228897
dnf installs the wrong kernel variant subpackages
Last modified: 2017-05-05 03:33:22 EDT
Description of problem:
When dkms is installed on a system that doesn't have kernel-devel, it gets kernel-debug-devel instead. It grabs the right kernel-headers, but not the right devel package for the kernel.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Set up a Fedora system without kernel-devel installed already running on a non-debug kernel
2. Install dkms through dnf (or yum on Fedora 21)
kernel-debug-devel is pulled in as a dependency and installed
kernel-devel should be installed as a dependency on a system that's not running a debug kernel
This issue also appears to have cropped up recently in Fedora 21, too. It didn't always happen, which makes me think it is something related to the 4.0.x kernel release to Fedora 21, but I am not sure of that. Obviously, this breaks DKMS managed kernel modules because now they cannot build properly...
In RPMFusion we got the same problem with akmods ...
As I understand this, this is not only 'dkms' issue, or packaging issue, it is hard/impossible to fix currently I guess without low_level changes which will solve this in some way.
also other packages which require 'kernel-devel', pull in 'kernel-debug-devel', which is most likely wrong for them (like in https://bugzilla.redhat.com/show_bug.cgi?id=1047041#c6 ), as I'm told in #yum @ irc.freenode.net, this is because both 'kernel-devel' and 'kernel-debug-devel' provide 'kernel-devel', and yum/dnf resolves that and satisfies the dependency.
[root@fedora ~]# dnf --enablerepo updates-testing repoquery --whatprovides kernel-devel
Last metadata expiration check performed 1:26:11 ago on Sun Jul 5 12:23:43 2015.
So this should be moved to some other component, but I don't know which one (yum/dnf,rpm)?
This problem is two parts, really:
1) AFAIK, there is no virtual provides or other kind of thing that ensures that kernel-devel matching running kernel is installed
2) If said thing does exist (in rpm or yum/dnf), DKMS isn't using it (it just Requires kernel-devel).
(In reply to Neal Gompa from comment #3)
> This problem is two parts, really:
> 1) AFAIK, there is no virtual provides or other kind of thing that ensures
> that kernel-devel matching running kernel is installed
> 2) If said thing does exist (in rpm or yum/dnf), DKMS isn't using it (it
> just Requires kernel-devel).
There is also "kernel-devel-uname-r" that you can use to match your current kernel, but that again breaks installation while there are updates pending etc.
So only the first point is relevant, unfortunately. Otherwise I would have added it. I have the same problems on DKMS and aKMODs packages that I maintain.
There has been a discussion on devel a few weeks ago exactly about this:
Last post here:
Can this be solved somehow using recently-approved weak dependencies?
Not really, because the problem is that the kernel package people are using could be quite arbitrary.
Did anyone check if "Boolean Dependencies" in RPM 4.13 can solve this bug? For Background see:
Sorry for the late reply.
(In reply to Thorsten Leemhuis from comment #7)
> Did anyone check if "Boolean Dependencies" in RPM 4.13 can solve this bug?
> For Background see:
Will try, thanks. The problem is that I would really like to fix this for RHEL 7+ and Fedora 21+ alike. This is only for rawhide.
akmods in RPMFusion has simply an added "Conflicts: kernel-debug-devel" in the SPEC file but I don't think it's correct.
Maybe kernel-debug-devel should not provide kernel-devel at all?
The virtual provides screw up everything, because from DNF and RPM's perspective, they're _all_ kernel-devel. Likewise with kernel-debug indicating it's also "kernel".
AFAICT, rich dependencies could solve it if we renamed kernel-* packages to kernel-release, removed the virtual provides for kernel and kernel-devel, and created virtual packages for kernel and kernel-devel that contained rich dependencies to Require kernel-release* or kernel-debug* things properly.
But the issue with that is that we would need to change how our release composition process would work in order to properly select the right kernel, unless we can bake in the proper logic in the virtual packages' Requires to handle that aspect too.
This issue is present in Fedora 23, and is more accurately a depsolver issue. Reassigning to "DNF".
(In reply to Kamil Páral from comment #5)
> Can this be solved somehow using recently-approved weak dependencies?
Yes, we will talk with kernel team how it should be packaged.
*** Bug 1323445 has been marked as a duplicate of this bug. ***
One thing which, seems to me, is not right, is kernel-devel not require kernel, and we could install kernel-debug-devel without install kernel-debug .
*** Bug 1047041 has been marked as a duplicate of this bug. ***
(In reply to Sergio Monteiro Basto from comment #13)
> One thing which, seems to me, is not right, is kernel-devel not require
Please explain. You don't need kernel-12.34 if you want to build a module for it, you only need kernel-devel-12.34; so why should kernel-devel require kernel?
(In reply to Jan Silhan from comment #11)
> (In reply to Kamil Páral from comment #5)
> > Can this be solved somehow using recently-approved weak dependencies?
> > https://fedoraproject.org/wiki/Packaging:WeakDependencies
> Yes, we will talk with kernel team how it should be packaged.
Did this ever happen? It would be nice if this issue was solved so that installing kernel subpackages works correctly. Because of this, netinstalls of Fedora 23 and 24 wind up installing kernel-debug-modules-* instead of the proper one, which breaks all kinds of functionality.
If it's breaking functionality then netinstalls should require the right one.
Adding `Suggests: kernel-modules*` to `kernel` and `Suggests: kernel-debug-modules*` to `kernel-debug` would probably solve it.
Can you even put wildcards in Suggests and expect them to be processed properly? I didn't think that even worked...
(In reply to Thorsten Leemhuis from comment #15)
> Please explain. You don't need kernel-12.34 if you want to build a module
> for it, you only need kernel-devel-12.34; so why should kernel-devel require
why we want build a module for a kernel that I don't run or even install ? this is even more strange , akmods or dkms want build modules automatically , but if kernel-devel doesn't match with kernel , it want build and it is a big mess error, end user have many difficulties to understand what happen look for example for http://forums.fedoraforum.org/showthread.php?t=308358
Conclusion even if it is possible create an module with kernel-devel and without kernel , it is not a good idea , kernel-devel shour require kernel , as first step to solve this problem .
(In reply to Neal Gompa from comment #16)
> (In reply to Jan Silhan from comment #11)
> > (In reply to Kamil Páral from comment #5)
> > > Can this be solved somehow using recently-approved weak dependencies?
> > > https://fedoraproject.org/wiki/Packaging:WeakDependencies
> > Yes, we will talk with kernel team how it should be packaged.
> Did this ever happen? It would be nice if this issue was solved so that
> installing kernel subpackages works correctly. Because of this, netinstalls
> of Fedora 23 and 24 wind up installing kernel-debug-modules-* instead of the
> proper one, which breaks all kinds of functionality.
Fist I prefer summary: dkms pulls in kernel-debug-devel instead of kernel-devel of the running kernel
I don't find a way with WeakDependencies to solve this problem
We could set a distro wide preference for the non-debug flavor if DNF had libsolv's preference list stuff hooked up. Alternatively, it might be possible using Suggests in the fedora-repos package to prefer the non-debug variants of all the kernel packages. That depends on whether libsolv uses all existing recorded Suggests as part of its decision logic for new transactions.
Another solution might be to use rich dependencies. If kernel, kernel-modules, kernel-modules-extra, kernel-devel, etc. were all empty packages that resolved the correct variant with rich dependencies, then it might work better.
Essentially, it'd be the same trick that allows us to handle languages/locales now in Fedora 24.
But, that would involve quite a bit of refactoring of how the kernel package is set up, and may have unexpected side-effects. For example, we currently rely on packages calling themselves "kernel" to be able to be multiversion installable, and that may not work anymore...
I'm not sure how this can be solved...
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
Is there any workaround which is possible for Fedora 25? If you just install a package requiring "kernel-devel", dnf will automatically pull in kernel-debug-devel which then breaks the dkms compilation.
(In reply to Luca Weiss from comment #23)
> Is there any workaround which is possible for Fedora 25? If you just install
> a package requiring "kernel-devel", dnf will automatically pull in
> kernel-debug-devel which then breaks the dkms compilation.
First install package kernel-devel, then (in an later dnf run) install the packages that require "kernel-devel".
I tried and it's also possible to install them simultaneously (in one command) but it's still not a good solution for people to do. I actually meant something which I can implement in the package spec because people installing this package will surely forget to follow the instructions and install the wrong kernel-devel package... Thanks anyways.
I'm suggesting to drop the kernel-devel virtual provides in the kernel package
According to above discussion we can suggest that solution cannot be provided by DNF, but most probably by changes in the packaging for kernel* packages. Probably it would be good to reassigned it to kernel component.