DKMS is not installing the right kernel-devel package

Josh Boyer jwboyer at
Mon Jun 15 12:25:38 UTC 2015

On Mon, Jun 15, 2015 at 8:16 AM, Neal Gompa <ngompa13 at> wrote:
> On Mon, Jun 15, 2015 at 8:01 AM, Josh Boyer <jwboyer at> wrote:
>> On Mon, Jun 15, 2015 at 4:28 AM, Miloslav Trmač <mitr at> wrote:
>>>> On Fri, Jun 12, 2015 at 7:24 AM, Neal Gompa <ngompa13 at> wrote:
>>>> > What about some kind of virtual provides defined in repos/rpm/somewhere that
>>>> > would automatically grab the kernel-devel package associated with the exact
>>>> > kernel that is running at the time yum/dnf is installing a program that
>>>> > depends on it? That would allow for things like DKMS to function properly,
>>>> > since they'll have what they need to build kernel modules. Going forward,
>>>> > kernel upgrades will also drag in the appropriate kernel-devel packages to
>>>> > match, keeping things sane.
>>>> That would help DKMS at the cost of breaking rpmfusion, koji, or any
>>>> other scenario where you want to build a kernel module for a kernel
>>>> that isn't running.  The kernel-devel package is meant to be flexible
>>>> enough so that you can install it without having anything close to the
>>>> same kernel version actually running.
>>> I don’t think this would break the model: there would be no changes to packaging kernel-devel, you would still be able to install kernel-devel-$whateverversion, but a magic (dnf install ^kernel-devel-current) or “Requires: ^kernel-devel-current” would refer to a specific one.
>> I'm not understanding what you're suggesting here.

> Essentially, a virtual provides called "kernel-devel-current" would
> always resolve to grab the kernel-devel package that corresponds with
> the running kernel, be it kernel-PAE, kernel-debug, or kernel (or for
> things like the Raspberry Pi 2, kernel-rpi2 or whatever it would be
> named). Other things that are safe with "kernel-devel" alone can still
> use that, preserving existing behavior when doing so.

Yes, I understand the concept.  What I don't understand is how one
would actually implement it.  As far as I can tell, it would have to
be done outside of the kernel package itself.  Perhaps as a DNF plugin
or something.  If so, then great but thus far the DNF developers have
been trying very hard to not treat the kernel and its subpackages as
special by any means.


More information about the devel mailing list