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): 2.2.0.3-30.git.7c3e7c5.fc22 How reproducible: Always 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) Actual results: kernel-debug-devel is pulled in as a dependency and installed Expected results: kernel-devel should be installed as a dependency on a system that's not running a debug kernel Additional info: 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. kernel-debug-devel-0:4.0.4-301.fc22.x86_64 kernel-devel-0:4.0.4-301.fc22.x86_64 kernel-debug-devel-0:4.0.7-300.fc22.x86_64 kernel-devel-0:4.0.7-300.fc22.x86_64 kernel-devel-0:4.0.6-300.fc22.x86_64 kernel-debug-devel-0:4.0.6-300.fc22.x86_64 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: https://lists.fedoraproject.org/pipermail/devel/2015-June/211248.html Last post here: https://lists.fedoraproject.org/pipermail/devel/2015-June/211445.html
Can this be solved somehow using recently-approved weak dependencies? https://fedoraproject.org/wiki/Packaging:WeakDependencies
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: https://lists.fedoraproject.org/pipermail/devel/2015-July/212672.html http://rpm.org/wiki/PackagerDocs/BooleanDependencies
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: > https://lists.fedoraproject.org/pipermail/devel/2015-July/212672.html > http://rpm.org/wiki/PackagerDocs/BooleanDependencies 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? > https://fedoraproject.org/wiki/Packaging:WeakDependencies 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 > kernel 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 > kernel? 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 See rhbz#1228897
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.
This message is a reminder that Fedora 24 is nearing its end of life. Approximately 2 (two) weeks from now Fedora will stop maintaining and issuing updates for Fedora 24. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '24'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 24 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Still valid issue.
with use of rpm boolean dependencies , it looks like we can solve this problem (#1474423)
(In reply to Thorsten Leemhuis from comment #15) > (In reply to Sergio Monteiro Basto from comment #13) > > One thing which, seems to me, is not right, is kernel-devel not require > > kernel > > 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? your argument kill me , but install kernel-devel without his kernel counter-part is the bug IMHO .
This issue is fixed from the kernel side. See also rhbz#1228897
(In reply to Nicolas Chauvet (kwizart) from comment #32) > This issue is fixed from the kernel side. > See also rhbz#1228897 kwizart, this is the bug rhbz#1228897, what bug do you want mention ?
This still seems to be an issue in Fedora 29 [luca@localhost ~]$ sudo dnf install dkms Last metadata expiration check: 0:01:48 ago on Fri 17 May 2019 02:50:46 PM CEST. Dependencies resolved. ================================================================================ Package Arch Version Repository Size ================================================================================ Installing: dkms noarch 2.6.1-2.fc29 fedora 78 k Installing dependencies: elfutils-libelf-devel x86_64 0.176-1.fc29 updates 23 k kernel-debug-devel x86_64 5.0.16-200.fc29 updates 13 M zlib-devel x86_64 1.2.11-14.fc29 fedora 46 k Transaction Summary ================================================================================ Install 4 Packages Total download size: 13 M Installed size: 53 M Is this ok [y/N]:
*** Bug 1630815 has been marked as a duplicate of this bug. ***
As far as I can see there has never been any change, kernel package still provides kernel-debug-devel: https://src.fedoraproject.org/rpms/kernel/blob/master/f/kernel.spec#_673 For RHEL 7 it's fixed in an errata: https://access.redhat.com/solutions/1278123
At this point, I think the right fix would be to have each of the kernel-$flavor-* subpackages have "Enhances: kernel-$flavor", with the natural special exception being kernel-* subpackages having "Enhances: kernel". That would allow libsolv to make the correct selection for variants.
seems to me that kernel-devel-matched on centos 9 fix this issue for me also available on Fedora 35 mock -r fedora-35-x86_64-rpmfusion_free install kernel mock -r fedora-35-x86_64-rpmfusion_free install VirtualBox installs the correct kernel-devel
(In reply to Sergio Basto from comment #38) but when we have one kernel upgrade with dnf upgrade, kernel-devel-matched should be not replaced/removed and should have the same behaviour of kernel-devel , IMO