DKMS is not installing the right kernel-devel package

[Miloslav Trmač]

> On Fri, Jun 12, 2015 at 7:24 AM, Neal Gompa <ngompa13 at gmail.com> 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.


> It's worth pointing out that the Fedora DKMS package could implement
> the logic you suggest in DKMS itself.  Then it would either fail if
> the relevant kernel-devel isn't installed (or kernel-PAE-devel, etc).
> However, that still doesn't really make it an automated working
> solution and still requires manual intervention to actually get it
> installed.

It is actually already fairly easy to usefully (but not reliably) automate this, copying an ugly hack from Chrome packaging, something like
> %post dkms
> the_details=…
> echo 'dnf install kernel-devel-$the_details' | at now+1minute
 
> As I said, there are no great solutions here.

Yeah, the above is another example of that ☺
   Mirek