Possible fix (fixed the typo in my original post, comment #0):

%package devel
Requires: kernel = %{version}-%{release}

(In reply to Raphael Groner from comment #0)
> Description of problem:
> Updates of kernel package break dkms. DNF introduces a new behaviour with
> thenew --best --allowerasing options. that was not seen with yum. If a new
> kernel update gets applied, kernel-devel stays in the system with the old
> version. We can not build modules for the new kernel, e.g. automatically via
> dkms. Package kernel-devel needs to be manually updated afterwards. Is that
> intentionally? I am aware that there can be more than one kernel be
> installed for grub options, but one source only via kernel-devel. An
> unexperienced user gets confused and is forced to stop dkms related third
> party software.

This is a dnf problem.  The kernel-devel package intentionally doesn't require the main kernel package because you do not need the main kernel package to build against.  The kernel-devel package has historically been used to build modules for multiple kernel versions on the same machine.

There are probably other bugs open for this somewhere, but I can't remember their numbers or find them in the 62M of bugmail I have.

(In reply to Raphael Groner from comment #1)
> Possible fix (fixed the typo in my original post, comment #0):
> 
> %package devel
> Requires: kernel = %{version}-%{release}
Shouldn't this be 'Requires: kernel%{?_isa} = %{version}-%{release}'?

(In reply to Josh Boyer from comment #2)
> This is a dnf problem.  The kernel-devel package intentionally doesn't
> require the main kernel package because you do not need the main kernel
> package to build against.
Maybe Recommends not Requires? dnf would install it by default, and it would still be possible to avoid installation if wanted.

Yes, there should be weak dependency as it's not a requirement of the package. We will get touch with kernel packaging and let them know how it should be packaged correctly so even depsolver could know how to deal with them.

This bug appears to have been reported against 'rawhide' during the Fedora 24 development cycle.
Changing version to '24'.

More information and reason for this action is here:
https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora24#Rawhide_Rebase

Proposed as a Freeze Exception for 24-alpha by Fedora user raphgro using the blocker tracking app because:

  Jan Silhan 2016-01-19 15:26:21 CET

Yes, there should be weak dependency as it's not a requirement of the package. We will get touch with kernel packaging and let them know how it should be packaged correctly so even depsolver could know how to deal with them.

Discussed at today's blocker review meeting [1]. Rejected as a freeze exception - there doesn't seem to be anything here which would actually be helped by a freeze exception. This does not involve release media and can't be easily fixed by pushing to updates-testing, which is still enabled by default. It can be re-proposed with a clearer justification.

[1] https://meetbot-raw.fedoraproject.org/fedora-blocker-review/2016-03-07/

(In reply to Jan Silhan from comment #4)
> Yes, there should be weak dependency as it's not a requirement of the
> package. We will get touch with kernel packaging and let them know how it
> should be packaged correctly so even depsolver could know how to deal with
> them.

This never happened as far as I know.  I'd love to see suggestions.

I am not sure if this describes the same problem, but I think so:

We have servers running for a long time without reboot. For example:

# uname -r
4.4.6-301.fc23.x86_64

In the meantime there was installed more than three new kernel versions by dnf-automatic:

# rpm -q kernel kernel-devel
kernel-4.4.6-301.fc23.x86_64
kernel-4.5.5-201.fc23.x86_64
kernel-4.5.6-200.fc23.x86_64
kernel-devel-4.4.9-300.fc23.x86_64
kernel-devel-4.5.5-201.fc23.x86_64
kernel-devel-4.5.6-200.fc23.x86_64

The problem is, that there are three kernel packages and three kernel-devel packages, but the version numbers doesn't agree. The oldest kernel package version and the oldest kernel-devel package version differ.

When an update of a akmod package occurs, it tries to build a kmod package for the new version against the current running kernel. But this fails because the kernel source required for the kmod build is missing, because kernel-devel for the running kernel version was automatically removed sometimes in the past. (We had installed it.)

For example, we have servers that act as GPU servers for CUDA software. Today I got the error message (same server used as for examples above):

# nvidia-smi 
Failed to initialize NVML: Driver/library version mismatch

I checked the versions and what to do for building the new driver module.

# rpm -q --scripts akmod-nvidia
posttrans scriptlet (using /bin/sh):
nohup /usr/sbin/akmods --from-akmod-posttrans --akmod nvidia &> /dev/null &

# /usr/sbin/akmods --from-akmod-posttrans --akmod nvidia
Checking kmods exist for 4.4.6-301.fc23.x86_64             [  OK  ]
Files needed for building modules against kernel
4.4.6-301.fc23.x86_64 could not be found as the following
directories are missing:
/usr/src/kernels/4.4.6-301.fc23.x86_64/
/usr/lib/modules/4.4.6-301.fc23.x86_64/build/Is the correct[FEHLGESCHLAGEN]ckage installed?


I have tried to install the kernel-devel package for the current running kernel, but it was not found. It seems it was removed too early from the repositories. I think all released kernel packages for a Fedora release should stay on the repositories.

[root@kornweihe ~]# LANG=C dnf list all kernel-devel
Last metadata expiration check: 3:44:17 ago on Thu Jun 16 11:06:09 2016.
Installed Packages
kernel-devel.x86_64                                      4.4.9-300.fc23                                       @updates
kernel-devel.x86_64                                      4.5.5-201.fc23                                       @updates
kernel-devel.x86_64                                      4.5.6-200.fc23                                       @updates

# LANG=C dnf install kernel-devel-4.4.6-301.fc23.x86_64
Last metadata expiration check: 3:44:56 ago on Thu Jun 16 11:06:09 2016.
No package kernel-devel-4.4.6-301.fc23.x86_64 available.
Dependencies resolved.
Nothing to do.
Complete!
# LANG=C dnf downgrade kernel-devel-4.4.6-301.fc23.x86_64
Last metadata expiration check: 3:45:10 ago on Thu Jun 16 11:06:09 2016.
No package kernel-devel-4.4.6-301.fc23.x86_64 available.
Error: Nothing to do.

I could try to find the old package on koji.fedoraproject.org and download and install it manually. At least it is available there.


But this behavior breaks the automatic build of new driver modules for new versions of extern driver packages with akmod, like nvidia-driver, wl, VirtualBox - to list some of them.

I use akmod because kmod packages of external software has some delay of creation some times and I don't want to delay the installation of new kernel versions because of breaking dependencies for some kmod packages.


The behaviour we need for working with akmod:

If a kernel package stays installed because it is the version of the current running kernel, and kernel-devel for this kernel version is installed, it should stay installed too and must not removed by updates.

kernel-devel should removed by updates only when the kernel package of the same version is removed.

This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

*** Bug 1062997 has been marked as a duplicate of this bug. ***

I am really sorry but we cannot solve the problem. There are several reasons and I will try to highlight some of them.

1. The first question if every user requires same version of package and devel package on system? I think that no, but if yes the problem will be easily solved by hard dependency (for that solution it is necessary to make request on each package to add requires to devel packages, because dnf delivery solution requested by user based on packaging rules).

2. Often different versions of devel kernel packages and kernel providing packages is due to protection of running kernel package but not protection of devel package. If oldest kernel is running kernel, dnf removes oldest kernel devel package but not oldest package that provides kernel (kernel-core). This is not nice behavior, but if devel package do not requires kernel package we cannot do much because by binding kernel devel to kernel we prohibit differences in version between those packages (dnf will act like requires in devel package is present, therefore we have behavior like in #1)

3. Proposed weak dependency solution will not solve the problem.

I am really sorry but DNF should support only general solution but in this case there is no such a option, therefore I have to close the request.

Jaroslav, thanks for your explanation. But still I think this bug should stay as open. Maybe someone finds a good solution.

Could a meta package solve it somehow or a workaround by comps?

Well ok, but in this case I think that it will be better to change a component to kernel, because they can provide a solution on packaging level.

(In reply to Raphael Groner from comment #0)
> Description of problem:
> Updates of kernel package break dkms. DNF introduces a new behaviour with
> thenew --best --allowerasing options. that was not seen with yum. If a new
> kernel update gets applied, kernel-devel stays in the system with the old
Here I stop.
(Rewind to the original message)
While I disagree with this ticket original title (the kernel-devel has strictly not point to require a kernel, as explained by Josh in c#2)
In your original post, you describe the really opposite problem: you have a kernel updated and the kernel-devel that "stays behind".

Boolean dependencies could allow to accurately describe what is the requirement.
Basically from a given kernel package: "if a kernel-devel is installed, then I need this kernel-devel >= %{version}"

I'm going to suggest looking forward 1450577

*** This bug has been marked as a duplicate of bug 1450577 ***