Description of problem: When installing koji kernel-headers and kernel-devel, dnf upgrades (thus removing) the prior kernel-headers and kernel-devel. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. Booted kernel-3.13.6-200.fc20.x86_64. Also already installed kernel-headers-3.13.6-200.fc20.x86_64 kernel-devel-3.13.6-200.fc20.x86_64. 2. Download from koji kernel-3.13.7-200.fc20.x86_64, dnf install causes it alone to be installed; it does not replace kernel-3.13.6-200.fc20.x86_64. As expected. 3. Download from koji kernel-devel-3.13.7-200.fc20.x86_64 and kernel-headers-3.13.7-200.fc20.x86_64. 4. dnf install those two RPMs. Actual results: dnf changes the install command to an upgrade command, and removes the devel and headers for the prior kernel. Expected results: install means install, not upgrade, not replace existing; these files can co-exist. Additional info: # dnf install kernel-devel-3.13.7-200.fc20.x86_64.rpm kernel-headers-3.13.7-200.fc20.x86_64.rpm Resolving dependencies --> Starting dependency resolution ---> Package kernel-devel.x86_64 3.13.6-200.fc20 will be upgraded ---> Package kernel-devel.x86_64 3.13.7-200.fc20 will be an upgrade ---> Package kernel-headers.x86_64 3.13.6-200.fc20 will be upgraded ---> Package kernel-headers.x86_64 3.13.7-200.fc20 will be an upgrade --> Finished dependency resolution Dependencies resolved.
dnf-0.4.18-1.fc20.noarch hawkey-0.4.12-1.fc20.x86_64
Hi Chris, thanks for the report we'll take a look. :sic
This is because libsolv chooses the best version for the user job before resolving the dependencies of installed packages. This is normally a good thing, for unrelated packages people expect dnf to select the best version and update the packages to meet the dependencies. For packages like "kernel-headers" this unfortunately means that you automatically get an update. I already thought about adding an option to the solver to first resolve the installed packages which would mean less updates, but I don't think this should be the default.
It's an open question if developers flip between kernel versions (probably) but also have an on-going need for each version's -headers -devel package. The one case I need -headers -devel is to build vbox guest additions which is a one time thing so this bug doesn't adversely affect me, but I could see how it would be untenable for others. I just don't know how common a problem it will be.
Chris can you please provide depsolver debug data for the case from comment 0? [1] Thanks! [1] http://dnf.baseurl.org/2013/11/25/reporting-depsolving-bugs/
Created attachment 885793 [details] debutdata.tar This is not exactly what was requested, but rather an install request turned into a downgrade action. 1. Existing kernel-3.13.7-200.fc20.x86_64 kernel-3.14.0-1.fc21.x86_64 kernel-headers-3.14.0-1.fc21.x86_64 kernel-devel-3.14.0-1.fc21.x86_64 2. Download kernel-3.13.9, kernel-headers-3.13.9, and kernel-devel-3.13.9. 3. dnf install *rpm This is turned into: Installing: kernel x86_64 3.13.9-200.fc20 @commandline 31 M Downgrading: kernel-devel x86_64 3.13.9-200.fc20 @commandline 8.6 M kernel-headers x86_64 3.13.9-200.fc20 @commandline 928 k I'd say it's just as common people want to keep kernel-devel and kernel-headers as they want to keep kernel. So I'm really not expecting anything kernel related to get upgraded/downgraded (meaning the existing version is replaced) when explicitly asking for install. If I ask for upgrade or downgrade, then OK delete existing.
What is described by both comment 6 and comment 0 is happening because neither kernel-headers nor kernel-devel are installonly and the command line specifically asks for a different version to be installed. The resulting transaction is the expected and correct one. Also see bug 1062997.