$ uname -r 4.14.18-300.fc27.x86_64 # dnf update ======================================================================= Package Arch Version Repository Size ======================================================================= Installing: kernel x86_64 4.18.5-200.fc28 updates-testing 98 k kernel-devel x86_64 4.18.5-200.fc28 updates-testing 13 M Removing: kernel x86_64 4.17.18-200.fc28 @System 0 kernel-devel x86_64 4.14.18-300.fc27 @System 44 M As you can see, dnf update tries to remove kernel-devel-4.14.18-300.fc27.x86_64, which corresponds to the running kernel. yum did not do that, it removed the next oldest kernel-devel (kernel-devel-4.17.18-200.fc28.x86_64). Is it possible for dnf to behave like yum? If not, is it possible to exclude kernel-devel-4.14.18-300.fc27.x86_64 from erasing? I tried to add excludepkgs=kernel-devel-4.14.18-300.fc27.x86_64 to dnf.conf, did not help. versionlock dnf plugin did not help neither.
This a problem because there is no hint in metadata that those packages has something similar. I really don't think that this is a good idea to add some additional rules by dnf, because there are users that need different version of devel packages. I can reassign the bug to kernel team, but they will close it. Lets skip one step. I am really sorry but we cannot help you.
I think it would be nice to have functionality which excluded some package from erasing. It should not have anything to do with kernel, but with any package which can have multiple versions installed.
There is the functionality: 1. excludepkgs in dnf.conf 2. plugin versionlock 3. "-x" from commandline
(In reply to Jaroslav Mracek from comment #3) > There is the functionality: > 1. excludepkgs in dnf.conf > 2. plugin versionlock > 3. "-x" from commandline But this functionality is for excluding packages from upgrading. If I have excludepkgs=kernel-devel, it would not update kernel-devel, which is not exactly what I want. I would like to have excluderemovepkgs=kernel-devel-4.14.18-300.fc27.x86_64, which would not remove this particular package version only. BTW, excludepkgs=kernel-devel-4.18.9-200.fc28.x86_64 (i.e. with specific version) works, I've just tested. So excluderemovepkgs= should work with specific package version too.
Well I have an alternative solution. I create a patch that change sorting for installonly packages removal, therefore the problem with removing of kernel-devel packages with same version like running kernel during upgrade should be avoided. But this is weak rule that do not limit end user for any action. See https://github.com/rpm-software-management/libdnf/pull/600. Please can you test it?
Seems to work. Before patch: # uname -r 4.14.18-300.fc27.x86_64 # dnf update Installing: kernel-devel x86_64 4.18.11-301.fc29 updates-testing 13 M Installing dependencies: kernel x86_64 4.18.11-301.fc29 updates-testing 23 k Removing: kernel-devel x86_64 4.14.18-300.fc27 @System 44 M After patch: Installing: kernel-devel x86_64 4.18.11-301.fc29 updates-testing 13 M Installing dependencies: kernel x86_64 4.18.11-301.fc29 updates-testing 23 k Removing: kernel-devel x86_64 4.18.9-200.fc28 @System 49 M Thank you! It will help with wireguard (and other dkms) too, as now on a long running system kernel-devel is removed after a few new kernel updates.
dnf-plugins-core-4.0.0-1.fc29 dnf-4.0.4-1.fc29 libdnf-0.22.0-1.fc29 has been submitted as an update to Fedora 29. https://bodhi.fedoraproject.org/updates/FEDORA-2018-2789f6b6e7
dnf-4.0.4-1.fc29, dnf-plugins-core-4.0.0-1.fc29, libdnf-0.22.0-1.fc29 has been pushed to the Fedora 29 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-2789f6b6e7
dnf-4.0.4-1.fc29 dnf-plugins-core-4.0.0-2.fc29 libdnf-0.22.0-2.fc29 has been submitted as an update to Fedora 29. https://bodhi.fedoraproject.org/updates/FEDORA-2018-2789f6b6e7
dnf-4.0.4-1.fc29, dnf-plugins-core-4.0.0-2.fc29, libdnf-0.22.0-2.fc29 has been pushed to the Fedora 29 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-2789f6b6e7
anaconda-29.24.6-1.fc29 dnf-4.0.4-1.fc29 dnf-plugins-core-4.0.0-2.fc29 libblockdev-2.20-2.fc29 libdnf-0.22.0-2.fc29 has been submitted as an update to Fedora 29. https://bodhi.fedoraproject.org/updates/FEDORA-2018-2789f6b6e7
anaconda-29.24.7-1.fc29, dnf-4.0.4-1.fc29, dnf-plugins-core-4.0.0-2.fc29, libblockdev-2.20-2.fc29, libdnf-0.22.0-5.fc29 has been pushed to the Fedora 29 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-2789f6b6e7
anaconda-29.24.7-1.fc29, dnf-4.0.4-1.fc29, dnf-plugins-core-4.0.0-2.fc29, libblockdev-2.20-2.fc29, libdnf-0.22.0-5.fc29 has been pushed to the Fedora 29 stable repository. If problems still persist, please make note of it in this bug report.