Description of problem: A great way to break a great many things... remove sqlite and libidn (which breaks rpm and dnf, among others): $ rpm -q kernel-core kernel-core-4.2.7-300.fc23.x86_64 kernel-core-4.2.8-300.fc23.x86_64 $ sudo dnf remove kernel-core-4.2.7-300.fc23.x86_64 Dependencies resolved. ================================================================================ Package Arch Version Repository Size ================================================================================ Removing: kernel x86_64 4.2.7-300.fc23 @updates 0 kernel-core x86_64 4.2.7-300.fc23 @updates 51 M kernel-modules x86_64 4.2.7-300.fc23 @updates 17 M kmod-nvidia-4.2.7-300.fc23.x86_64 x86_64 1:358.16-1.fc23 @@commandline 13 M libidn x86_64 1.32-1.fc23 @fedora 671 k sqlite x86_64 3.9.0-1.fc23 @updates 942 k Transaction Summary ================================================================================ Remove 6 Packages Installed size: 82 M Is this ok [y/N]: n Operation aborted. This isn't logical.... doing a "dnf remove" on sqlite along shows 102 packages would also need to be removed to ensure that nothing remains that depends on it; doing the same for libidn shows 82 packages. So... why does dnf want to remove libdn and sqlite in the first place, and perhaps more importantly why does it have no issues with removing these required packages when the package operation/transaction is part of removing the kernel? Seems like a bug. Version-Release number of selected component (if applicable): $ rpm -qa | grep dnf dnf-1.1.5-1.fc23.noarch dnf-yum-1.1.5-1.fc23.noarch python3-dnf-plugins-core-0.1.15-1.fc23.noarch dnf-langpacks-0.15.1-1.fc23.noarch python3-dnf-1.1.5-1.fc23.noarch yumex-dnf-4.1.5-1.fc23.noarch python3-dnf-langpacks-0.15.1-1.fc23.noarch dnf-plugins-core-0.1.15-1.fc23.noarch dnfdaemon-0.3.11-1.fc23.noarch python3-dnfdaemon-0.3.11-1.fc23.noarch dnf-conf-1.1.5-1.fc23.noarch dnf-langpacks-conf-0.15.1-1.fc23.noarch
*** This bug has been marked as a duplicate of bug 1222812 ***