Description of problem: Upon initating an update, dnf proposes updating kernel-headers, and kernel-devel but not kernel. Version-Release number of selected component (if applicable): dnf-0.4.17-1.fc20.noarch hawkey-0.4.11-1.fc20.x86_64 How reproducible: Always Steps to Reproduce: 1. Running kernel 3.14.0-0.rc5.git0.1.fc21.1.x86_64 2. kernel-3.13.5-200.fc20.x86_64 is installed as are mismatching versions: kernel-headers-3.13.5-202.fc20.x86_64 kernel-devel-3.13.5-202.fc20.x86_64 So -200 for kernel, and -202 for headers+devel. 3. dnf update Actual results: ---> Package kernel-devel.x86_64 3.13.5-202.fc20 will be upgraded ---> Package kernel-devel.x86_64 3.13.6-200.fc20 will be an upgrade ---> Package kernel-headers.x86_64 3.13.5-202.fc20 will be upgraded ---> Package kernel-headers.x86_64 3.13.6-200.fc20 will be an upgrade Expected results: That kernel, kernel-devel, kernel-headers, version 3.13.5-202.fc20, will be an upgrade for all exiting 3.13.5-XXX versions of those packages. Additional info: # rpm -qa kernel\* kernel-3.13.5-200.fc20.x86_64 kernel-3.14.0-0.rc5.git0.1.fc21.1.x86_64 kernel-headers-3.13.5-202.fc20.x86_64 kernel-devel-3.13.5-202.fc20.x86_64
Created attachment 872576 [details] debugdata.tar.gz
After proceeding with the prescribed update and rebooting, dnf still isn't recognizing that installed kernel-3.13.5-200.fc20.x86_64 should be updated to 3.13.6-200 which is listed in bodhi as stable, FEDORA-2014-3655. It reports Dependencies resolved. Nothing to do. Will attach another debugsolver archive.
Created attachment 872577 [details] debugsolver.tar.gz per comment 2
# dnf clean all # dnf update Resolving dependencies --> Starting dependency resolution --> Finished dependency resolution Dependencies resolved. Nothing to do.
Hello, What you got is the expected behavior: libsolv sees no benefit in it for the system if there is already 3.14.0 installed to add a newer 3.13.* version. Before I close this: Michael, can you please confirm this is by design? You can install the old kernel package with dnf install kernel-<EVRA>
Yes, libsolv has no special magic that splits the version into (version-release) tuples and tries to update to the latest release for every version. I also don't think that such a behavior would make sense for packages other than the kernel. (IMHO all the multiversion handling only makes sense for the kernel, so it's kind of an historic thing.)
Thank you Michal. Closing this, this is the expected behavior.