Description of problem: The automatic removal of installed dependencies when removing a package via 'dnf remove' can go so far as to destroy the system. As a specific example, the following command sequence renders my system unusable: bash$ twm Install 'xorg-x11-twm'? y then bash$ sudo dnf remove twm This causes dnf to remove zlib and libuuid. Since dnf, rpm, gnome-terminal, and various other critical binaries need zlib, proceeding with this command makes the system unusable. Version-Release number of selected component (if applicable): Fedora 23 How reproducible: Every time. Steps to Reproduce: 1. Attempt to run 'twm' from bash prompt 2. Accept automatic installation of xorg-x11-twm 3. sudo dnf remove xorg-x11-twm Actual results: The xorg-x11-twm package is removed, along with zlib. Expected results: Only the xorg-x11-twm and the packages installed as its dependencies (libXaw and xterm) should have been removed. Additional info:
Please rerun the task with --debugsolver and attach the debugdata. http://dnf.baseurl.org/2013/11/25/reporting-depsolving-bugs/
Created attachment 1097739 [details] dnf debugdata
The issue did not appear on this run. I have a theory as to why: When the problem presented itself and dnf removed zlib and libuuid, I was able to save the system by copying over libz.so.1 from another system and then running "dnf install zlib" and "dnf install libuuid". This marked those packages as manually installed and therefore changed the dependency calculation. Also, something to note: when I did the reinstall, I specifically had to install the x86_64 versions of the packages (dnf install zlib.x86_64), because the i686 packages were still there (installed originally as Skype dependencies). When the original dnf run removed zlib, it removed the x86_64 version, but not the i686 version. Thanks for your help.
Since https://bugzilla.redhat.com/show_bug.cgi?id=1222812 is closed, I am posting my comment here as well. I think this is really serious and should be investigated further (no plexmediaserver installed on my box): $ sudo dnf remove gnome-mines-3.18.2-1.fc23.x86_64 [sudo] password for kristi: Dependencies resolved. ============================================================================================================================================================================================================================================== Package Arch Version Repository Size ============================================================================================================================================================================================================================================== Removing: gnome-mines x86_64 3.18.2-1.fc23 @updates 6.5 M libpng x86_64 2:1.6.19-1.fc23 @updates 211 k sqlite x86_64 3.9.0-1.fc23 @updates 942 k zlib x86_64 1.2.8-9.fc23 @koji-override-0 183 k Transaction Summary ============================================================================================================================================================================================================================================== Remove 4 Packages Installed size: 7.8 M Is this ok [y/N]: n Operation aborted. Could it be because zlib is provided both by the 64bit and the 32bit package, and the requirements of the packages needing zlib.x86_64 do not specify the architecture? [kristi@papoi ~]$ rpm -q --whatprovides zlib zlib-1.2.8-9.fc23.x86_64 zlib-1.2.8-9.fc23.i686
Another thing, looking at Skype's dependencies, which brought most of the i686 libraries: $ sudo rpm -q --requires skype /bin/sh /bin/sh alsa-plugins-pulseaudio(x86-32) config(skype) = 4.3.0.37-fc16 libQtCore.so.4 libQtDBus.so.4 libQtGui.so.4 libQtNetwork.so.4 libQtWebKit.so.4 libQtXml.so.4 libX11.so.6 libXScrnSaver libXext.so.6 libXss.so.1 libXv libXv.so.1 libc.so.6 libc.so.6(GLIBC_2.0) libc.so.6(GLIBC_2.1) libc.so.6(GLIBC_2.1.3) libc.so.6(GLIBC_2.2) libc.so.6(GLIBC_2.3) libc.so.6(GLIBC_2.3.2) libc.so.6(GLIBC_2.3.4) libc.so.6(GLIBC_2.4) libc.so.6(GLIBC_2.7) libdl.so.2 libdl.so.2(GLIBC_2.0) libdl.so.2(GLIBC_2.1) libgcc_s.so.1 libgcc_s.so.1(GCC_3.0) libgcc_s.so.1(GLIBC_2.0) libm.so.6 libm.so.6(GLIBC_2.0) libm.so.6(GLIBC_2.1) libpng libpthread.so.0 libpthread.so.0(GLIBC_2.0) libpthread.so.0(GLIBC_2.1) libpthread.so.0(GLIBC_2.2) libpthread.so.0(GLIBC_2.3.2) librt.so.1 librt.so.1(GLIBC_2.2) libstdc++.so.6 libstdc++.so.6(CXXABI_1.3) libstdc++.so.6(GLIBCXX_3.4) libstdc++.so.6(GLIBCXX_3.4.9) pulseaudio-libs qt >= 4.6 qtwebkit rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1 rtld(GNU_HASH) It requires a "generic" libpng. So, when I try to remove skype (random pick) it actually tries to remove the 64bit version of libpng, but not the 32bit one (this is not right, and I guess is a mix of badly defined requires/provides): $ sudo dnf remove skype Dependencies resolved. ============================================================================================================================================================================================================================================== Package Arch Version Repository Size ============================================================================================================================================================================================================================================== Removing: alsa-plugins-pulseaudio i686 1.0.29-2.fc23 @fedora 100 k cairo i686 1.14.2-2.fc23 @fedora 1.8 M cdparanoia-libs i686 10.2-20.fc23 @fedora 125 k flac-libs i686 1.3.1-5.fc23 @fedora 576 k graphite2 i686 1.2.4-5.fc23 @fedora 178 k gsm i686 1.0.13-13.fc23 @fedora 54 k gstreamer1 i686 1.6.2-1.fc23 @updates 3.8 M gstreamer1-plugins-base i686 1.6.2-1.fc23 @updates 4.3 M harfbuzz i686 1.0.6-1.fc23 @updates 443 k json-c i686 0.12-6.fc23 @fedora 45 k libXScrnSaver i686 1.2.2-9.fc23 @fedora 35 k libXft i686 2.3.2-3.fc23 @fedora 124 k libXtst i686 1.2.2-5.fc23 @fedora 28 k libXv i686 1.0.10-3.fc23 @fedora 20 k libasyncns i686 0.8-9.fc23 @fedora 54 k libdatrie i686 0.2.8-6.fc23 @fedora 57 k libogg i686 2:1.3.2-4.fc23 @fedora 33 k libogg x86_64 2:1.3.2-4.fc23 @koji-override-0 34 k libpng x86_64 2:1.6.19-1.fc23 @updates 211 k libsndfile i686 1.0.25-17.fc23 @updates 447 k libthai i686 0.1.21-2.fc23 @fedora 713 k libtheora i686 1:1.1.1-13.fc23 @fedora 699 k libvisual i686 1:0.4.0-18.fc23 @fedora 429 k libvorbis i686 1:1.3.4-5.fc23 @fedora 765 k libwayland-client i686 1.9.0-1.fc23 @fedora 51 k libwayland-server i686 1.9.0-1.fc23 @fedora 60 k libwebp i686 0.4.4-1.fc23 @updates 702 k mesa-libEGL i686 11.0.6-1.20151122.fc23 @updates 192 k mesa-libgbm i686 11.0.6-1.20151122.fc23 @updates 76 k orc i686 0.4.24-1.fc23 @fedora 623 k pango i686 1.38.1-1.fc23 @fedora 730 k pixman i686 0.33.4-1.fc23 @updates 627 k proj i686 4.9.1-3.fc23 @fedora 499 k pulseaudio-libs i686 7.1-1.fc23 @updates 2.9 M qt-mobility-common i686 1.2.2-0.21.20140317git169da60c.fc23 @fedora 115 k qt-mobility-location i686 1.2.2-0.21.20140317git169da60c.fc23 @fedora 2.0 M qt-mobility-sensors i686 1.2.2-0.21.20140317git169da60c.fc23 @fedora 435 k qtwebkit i686 2.3.4-8.fc23 @fedora 69 M skype i586 4.3.0.37-fc16 @@commandline 42 M tcp_wrappers-libs i686 7.6-81.fc23 @fedora 126 k Transaction Summary ============================================================================================================================================================================================================================================== Remove 40 Packages
I just hit the same issue, had skype installed, which pulled in 32 bit version of libuuid and sqlite, later while removing some packages (akmods) sqlite and libuuid got removed as well, leaving me with borked system. Had to curl both packages from the repo ,unpack manually, copy libs to /usr/lib64 and then install both missing packages with .x86_64 suffix (otherwise dnf complained they are already there, since it had 32 bit versions).
This problem arises with disturbing frequency. When 32-bit versions of system-critical packages are installed on a 64-bit system, uninstalling some items will render the system unbootable by removing dependencies needed by systemd.
This literally happened to me two days in a row, with different packages, both times leaving me with a broken system - it broke dnf AND made the system unbootable First time, I just reinstalled everything, second time I spent a few hours figuring out how to fix the system via recovery mode. Reproduction steps: Option #1 - Download atom 1.5.4 (atom.x86_64.rpm) from https://github.com/atom/atom/releases/tag/v1.6.0 - Install with dnf install ./atom.x86_64.rpm - Remove with dnf remove atom Your system is broken (sqlite and most likely something else is wiped). Option #2 - Install yakuake: dnf install yakuake - Delete yakuake: dnf remove yakuake Could you please investigate the issue and make the "dnf remove" command usable again? I don't feel like risking my entire system breaking over deleting packages.
put clean_requirements_on_remove=false in /etc/dnf/dnf.conf and dnf won't remove any other package , also you may read about clean_requirements_on_remove option , and how it works ... anyway seems the default clean_requirements_on_remove=true is a big disaster , maybe we should change this default.
Well, guys, this week I think I might have found the culprit: $ rpm -q --provides hipchat|sort | uniq aspell.so()(64bit) hipchat = 2.2.1388-1 hipchat(x86-64) = 2.2.1388-1 hunspell.so()(64bit) libadl_sdk.so()(64bit) libcanberra-alsa.so()(64bit) libcanberra-multi.so()(64bit) libcanberra-null.so()(64bit) libcanberra-oss.so()(64bit) libcanberra.so.0()(64bit) libcanberra.so.0(CANBERRA_0)(64bit) libcomposeplatforminputcontextplugin.so()(64bit) libcrypto.so.1.0.0()(64bit) libcrypto.so.1.0.0(OPENSSL_1.0.0)(64bit) libcrypto.so.1.0.0(OPENSSL_1.0.1)(64bit) libcrypto.so.1.0.0(OPENSSL_1.0.1d)(64bit) libdbusmenu-qt5.so.2()(64bit) libibusplatforminputcontextplugin.so()(64bit) libicudata.so.52()(64bit) libicui18n.so.52()(64bit) libicuuc.so.52()(64bit) libKF5IdleTime.so.5()(64bit) libKF5SonnetCore.so.5()(64bit) libKF5SonnetUi.so.5()(64bit) libKF5WindowSystem.so.5()(64bit) liblzma.so.5()(64bit) liblzma.so.5(XZ_5.0)(64bit) libogg.so.0()(64bit) libpng16.so.16()(64bit) libpng16.so.16(PNG16_0)(64bit) libqconnmanbearer.so()(64bit) libqgenericbearer.so()(64bit) libqgif.so()(64bit) libqico.so()(64bit) libqjpeg.so()(64bit) libqnmbearer.so()(64bit) libQt5Core.so.5()(64bit) libQt5DBus.so.5()(64bit) libQt5Gui.so.5()(64bit) libQt5Network.so.5()(64bit) libQt5OpenGL.so.5()(64bit) libQt5Positioning.so.5()(64bit) libQt5PrintSupport.so.5()(64bit) libQt5Qml.so.5()(64bit) libQt5Quick.so.5()(64bit) libQt5Sensors.so.5()(64bit) libQt5Sql.so.5()(64bit) libQt5WebKit.so.5()(64bit) libQt5WebKitWidgets.so.5()(64bit) libQt5Widgets.so.5()(64bit) libQt5X11Extras.so.5()(64bit) libQt5Xml.so.5()(64bit) libqtaccessiblequick.so()(64bit) libqtaccessiblewidgets.so()(64bit) libqtquick2plugin.so()(64bit) libqxcb.so()(64bit) libqxmpp.so.0()(64bit) libsqlite3.so.0()(64bit) libssl.so.1.0.0()(64bit) libssl.so.1.0.0(OPENSSL_1.0.0)(64bit) libssl.so.1.0.0(OPENSSL_1.0.1)(64bit) libssl.so.1.0.0(OPENSSL_1.0.1d)(64bit) libstdc++.so.6()(64bit) libstdc++.so.6(CXXABI_1.3.1)(64bit) libstdc++.so.6(CXXABI_1.3.2)(64bit) libstdc++.so.6(CXXABI_1.3.3)(64bit) libstdc++.so.6(CXXABI_1.3.4)(64bit) libstdc++.so.6(CXXABI_1.3.5)(64bit) libstdc++.so.6(CXXABI_1.3)(64bit) libstdc++.so.6(CXXABI_1.3.6)(64bit) libstdc++.so.6(CXXABI_1.3.7)(64bit) libstdc++.so.6(CXXABI_TM_1)(64bit) libstdc++.so.6(GLIBCXX_3.4.10)(64bit) libstdc++.so.6(GLIBCXX_3.4.11)(64bit) libstdc++.so.6(GLIBCXX_3.4.12)(64bit) libstdc++.so.6(GLIBCXX_3.4.13)(64bit) libstdc++.so.6(GLIBCXX_3.4.14)(64bit) libstdc++.so.6(GLIBCXX_3.4.15)(64bit) libstdc++.so.6(GLIBCXX_3.4.1)(64bit) libstdc++.so.6(GLIBCXX_3.4.16)(64bit) libstdc++.so.6(GLIBCXX_3.4.17)(64bit) libstdc++.so.6(GLIBCXX_3.4.18)(64bit) libstdc++.so.6(GLIBCXX_3.4.19)(64bit) libstdc++.so.6(GLIBCXX_3.4.2)(64bit) libstdc++.so.6(GLIBCXX_3.4.3)(64bit) libstdc++.so.6(GLIBCXX_3.4.4)(64bit) libstdc++.so.6(GLIBCXX_3.4.5)(64bit) libstdc++.so.6(GLIBCXX_3.4)(64bit) libstdc++.so.6(GLIBCXX_3.4.6)(64bit) libstdc++.so.6(GLIBCXX_3.4.7)(64bit) libstdc++.so.6(GLIBCXX_3.4.8)(64bit) libstdc++.so.6(GLIBCXX_3.4.9)(64bit) libtdb.so.1()(64bit) libtdb.so.1(TDB_1.2.10)(64bit) libtdb.so.1(TDB_1.2.1)(64bit) libtdb.so.1(TDB_1.2.2)(64bit) libtdb.so.1(TDB_1.2.3)(64bit) libtdb.so.1(TDB_1.2.4)(64bit) libtdb.so.1(TDB_1.2.5)(64bit) libtdb.so.1(TDB_1.2.6)(64bit) libtdb.so.1(TDB_1.2.7)(64bit) libtdb.so.1(TDB_1.2.8)(64bit) libtdb.so.1(TDB_1.2.9)(64bit) libuuid.so.1()(64bit) libuuid.so.1(UUID_1.0)(64bit) libuuid.so.1(UUID_2.20)(64bit) libuuid.so.1(UUIDD_PRIVATE)(64bit) libvorbisfile.so.3()(64bit) libvorbis.so.0()(64bit) libxcb-sync.so.0()(64bit) libxml2.so.2()(64bit) libxml2.so.2(LIBXML2_2.4.30)(64bit) libxml2.so.2(LIBXML2_2.5.0)(64bit) libxml2.so.2(LIBXML2_2.5.2)(64bit) libxml2.so.2(LIBXML2_2.5.4)(64bit) libxml2.so.2(LIBXML2_2.5.5)(64bit) libxml2.so.2(LIBXML2_2.5.6)(64bit) libxml2.so.2(LIBXML2_2.5.7)(64bit) libxml2.so.2(LIBXML2_2.5.8)(64bit) libxml2.so.2(LIBXML2_2.5.9)(64bit) libxml2.so.2(LIBXML2_2.6.0)(64bit) libxml2.so.2(LIBXML2_2.6.10)(64bit) libxml2.so.2(LIBXML2_2.6.11)(64bit) libxml2.so.2(LIBXML2_2.6.12)(64bit) libxml2.so.2(LIBXML2_2.6.14)(64bit) libxml2.so.2(LIBXML2_2.6.15)(64bit) libxml2.so.2(LIBXML2_2.6.1)(64bit) libxml2.so.2(LIBXML2_2.6.16)(64bit) libxml2.so.2(LIBXML2_2.6.17)(64bit) libxml2.so.2(LIBXML2_2.6.18)(64bit) libxml2.so.2(LIBXML2_2.6.19)(64bit) libxml2.so.2(LIBXML2_2.6.20)(64bit) libxml2.so.2(LIBXML2_2.6.21)(64bit) libxml2.so.2(LIBXML2_2.6.23)(64bit) libxml2.so.2(LIBXML2_2.6.24)(64bit) libxml2.so.2(LIBXML2_2.6.25)(64bit) libxml2.so.2(LIBXML2_2.6.2)(64bit) libxml2.so.2(LIBXML2_2.6.27)(64bit) libxml2.so.2(LIBXML2_2.6.28)(64bit) libxml2.so.2(LIBXML2_2.6.29)(64bit) libxml2.so.2(LIBXML2_2.6.32)(64bit) libxml2.so.2(LIBXML2_2.6.3)(64bit) libxml2.so.2(LIBXML2_2.6.5)(64bit) libxml2.so.2(LIBXML2_2.6.6)(64bit) libxml2.so.2(LIBXML2_2.6.7)(64bit) libxml2.so.2(LIBXML2_2.6.8)(64bit) libxml2.so.2(LIBXML2_2.7.0)(64bit) libxml2.so.2(LIBXML2_2.7.3)(64bit) libxml2.so.2(LIBXML2_2.7.4)(64bit) libxml2.so.2(LIBXML2_2.8.0)(64bit) libxslt.so.1()(64bit) libxslt.so.1(LIBXML2_1.0.11)(64bit) libxslt.so.1(LIBXML2_1.0.12)(64bit) libxslt.so.1(LIBXML2_1.0.13)(64bit) libxslt.so.1(LIBXML2_1.0.16)(64bit) libxslt.so.1(LIBXML2_1.0.17)(64bit) libxslt.so.1(LIBXML2_1.0.18)(64bit) libxslt.so.1(LIBXML2_1.0.22)(64bit) libxslt.so.1(LIBXML2_1.0.24)(64bit) libxslt.so.1(LIBXML2_1.0.30)(64bit) libxslt.so.1(LIBXML2_1.0.32)(64bit) libxslt.so.1(LIBXML2_1.0.33)(64bit) libxslt.so.1(LIBXML2_1.1.0)(64bit) libxslt.so.1(LIBXML2_1.1.1)(64bit) libxslt.so.1(LIBXML2_1.1.18)(64bit) libxslt.so.1(LIBXML2_1.1.20)(64bit) libxslt.so.1(LIBXML2_1.1.23)(64bit) libxslt.so.1(LIBXML2_1.1.24)(64bit) libxslt.so.1(LIBXML2_1.1.25)(64bit) libxslt.so.1(LIBXML2_1.1.2)(64bit) libxslt.so.1(LIBXML2_1.1.26)(64bit) libxslt.so.1(LIBXML2_1.1.3)(64bit) libxslt.so.1(LIBXML2_1.1.5)(64bit) libxslt.so.1(LIBXML2_1.1.7)(64bit) libxslt.so.1(LIBXML2_1.1.9)(64bit) libz.so.1()(64bit) libz.so.1(ZLIB_1.2.0.2)(64bit) libz.so.1(ZLIB_1.2.0)(64bit) libz.so.1(ZLIB_1.2.0.8)(64bit) libz.so.1(ZLIB_1.2.2.3)(64bit) libz.so.1(ZLIB_1.2.2.4)(64bit) libz.so.1(ZLIB_1.2.2)(64bit) libz.so.1(ZLIB_1.2.3.3)(64bit) libz.so.1(ZLIB_1.2.3.4)(64bit) libz.so.1(ZLIB_1.2.3.5)(64bit) libz.so.1(ZLIB_1.2.5.1)(64bit) libz.so.1(ZLIB_1.2.5.2)(64bit) This seems very wrong, but it doesn't seem it's dnf's fault if 3rd party packages advertise wrong provides. And of course if some other package advertises it can provide zlib, dnf is rightful in saying that the zlib package is not needed. However, all the libraries provided by HipChat are in /opt/HipChat and not in the default LIBRARY_PATH (as it should be). To identify the package that causes you the trouble, try a dnf provides on the library/ies that (would) get deleted if you try to remove something. For me it was zlib, so: $ sudo dnf provides 'libz.so.1()(64bit)' Last metadata expiration check: 2:44:15 ago on Sun Mar 20 03:40:13 2016. hipchat-2.2.1388-1.x86_64 : Persistent group chat using XMPP. Repo : @System zlib-1.2.8-9.fc23.x86_64 : The compression and decompression library Repo : @System zlib-1.2.8-9.fc23.x86_64 : The compression and decompression library Repo : fedora hipchat-2.2.1388-1.x86_64 : Persistent group chat using XMPP. Repo : atlassian-hipchat Cheers, Cristi
So far I have several possible clue of this problem (most of them are not related to DNF itself). 1. Installing software from PackageKit (it is called Software): It incorrectly mark installed software as installed as dependency, therefore if DNF remove something it also can remove such a software, if it was dependency of it or by use autoremove command. DNF really cannot solve this problem and it is not bug in DNF. (you can easily reproduce - save 'dnf autoremove' output; install something with PackageKit and than again compare output from 'dnf autoremove') 2. Installing software from command line: If you doesn't have tito package on your system, type "tito", into command-line, than it will ask you if you ``Install package 'tito' to provide command 'tito'? [N/y]``. After installing again ``dnf autoremove`` command will try to remove tito and other dependency. Again not bug in DNF. If something else mark installed package as a dependency and not as user-installed, dnf really cannot solve it. 3. As it was mentioned in Comment 10. If package provide something that it doesn't, dnf can remove other provide as a unnecessary dependency. Again dnf cannot solve this problem. It has to be solved on side of the packagers. 4. Bug in DNF - I will test all reproducers that you provided above, and try to eliminate this possibility. So far I failed here, but if something will not work correctly in DNF, I will try to create a fix.
Test of Description: I cannot reproduce it. If I install skype then twm as described, then ``dnf remove twm`` it works like expected. It even keeps both zlib (i686, x86_64). DNF autoremove correctly tries to remove i686 version of zlib. I tested on WM f23, fully updated (not much extra installed). Likely the problem was as described in No. 3 in Comment 11. Test of Comment 3: On system twm, skype (zlib.i686, zlib.x86_64). ``dnf remove zlib`` result in: Error: The operation would result in removing the following protected packages: dnf, systemd. ``dnf remove zlib.i686`` result in: remove skype with dependencies The reasons why I cannot reproduce: 1. Not installed package that provides something incorrectly (3rd party repository and their packages). 2. Different version of packages that caused the problem (provides something incorrectly). 3. Installed important packages as a dependency instead as an user-installed (this problem may be inherited from previous fedora versions when system upgrade or other method is used)
I am closing this bug, but please if you will find that problem is really related to DNF and not to points 1 to 3 from Comment 11, please don't hesitate to reopen it. For problems related to i686 - x86_64 preferences, please create a new bug report.
JFYI, in the reported case the hipchat package was the source of the issue. It claims to provide libz and libuuid.
*** Bug 1326894 has been marked as a duplicate of this bug. ***
*** Bug 1330723 has been marked as a duplicate of this bug. ***
*** Bug 1338921 has been marked as a duplicate of this bug. ***
(In reply to Jaroslav Mracek from comment #13) > I am closing this bug, but please if you will find that problem is really > related to DNF and not to points 1 to 3 from Comment 11, please don't > hesitate to reopen it. I'm going to take you up on that offer. Here is the situation: we now have many reports that dnf is blowing up people's systems where yum did not. Bug 1326894, bug 1330723, bug 1338921, this bug, https://ask.fedoraproject.org/en/question/75684/how-to-recover-yumdnfrpm-after-uninstall-sqlite/ http://jsn-techtips.blogspot.com/2016/03/fedora-install-accidentally-removed.html etc. And we know why: 1) dnf attempts to automatically remove "unneeded" dependencies where yum did not (see bug 1227066, especially my comments towards the end) 2) some packages declare that they provide things that the system linker cannot find, causing dnf to think the dependency is resolved but the actual programs to not find the needed library. So yes, while I get that there is not a bug in dnf's dependency resolution code per se, it's really not okay to just shrug and say "it's a packaging problem" when dnf is blowing up systems left and right where yum did not. Either one or both of the steps that lead to this problem can and should be fixed in dnf: 1) The auto-leaf-dependecy removal feature should be disabled (see https://bugzilla.redhat.com/show_bug.cgi?id=1227066#c9 ) 2) The thing that generates the automated library 'Provides' entries should be updated to work the same way as the linker; if the system linker cannot find it then the rpm should not 'Provide' it. (see https://bugzilla.redhat.com/show_bug.cgi?id=1338921#c8 ) I don't know if #2 is a bug on dnf or rpm or rpmbuild or what, but something does that. Feel free to redirect as appropriate. #1 is definitely a well-intentioned dnf feature that has unintended and very negative consequences. Or I'm fine with a completely different fix too. But something needs to be done. Yum did not blow up people's systems, dnf does. Therefore it is definitely a dnf bug.
Ad 2) As for the libraries that the system linker cannot find - sometimes it's correct e.g. in scl packages becuase they modify library path, sometimes it isn't. And it's hard to find a 100% correct common pattern among them. So unless packages bundle own copies of system libraries (which is forbidden in Fedora guidlines) current implementation works good.
It's rather workaround then a proper fix - make dnf depend on system libraries https://github.com/rpm-software-management/dnf/pull/502
Just recently installing and uninstalling a collection of X development packages resulted in the removal of several X libraries upon which GNOME depended. I was able to log into the system by switching to a console and reinstalling the missing packages. I would like to note that this was on a system without HipChat - in fact, the system had no non-Fedora packages installed, and dnf still removed a critical system package.
IMHO you should disable autoremove by default quickly , because this feature is a big mess.
I strongly disagree with a status of POST. Making people's systems unbootable is as high of a severity and priority as it is possible to get. This is a "we need to fix it now in every supported Fedora and RHEL (if applicable)" type of thing, not an "oh we'll do something about it later" type of thing. And as jking points out in comment 21, it's not just 3rd party rpms that can trigger this and it's not just "system libraries" that we need to make sure stay intact. X libraries or $WindowManager libraries also would need to be included, and there's no way you can ensure that all libraries needed for any of the supported Window Managers are properly represented in a work-around dependency list. I agree with Sergio, the first step needs to be that the auto-dependency-removal feature needs to be disabled immediately, and then after that you can figure out if anything else needs to be done.
*** Bug 1343916 has been marked as a duplicate of this bug. ***
libsolv-0.6.22-1.fc24 has been submitted as an update to Fedora 24. https://bodhi.fedoraproject.org/updates/FEDORA-2016-6b1f2faa7d
libsolv-0.6.22-1.fc24 has been pushed to the Fedora 24 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-2016-6b1f2faa7d
libsolv-0.6.22-1.fc24 has been pushed to the Fedora 24 stable repository. If problems still persist, please make note of it in this bug report.
An errata for F23 would be nice, as I have just been bitten by this when trying to upgrade to F24! [root@ultra ~]# fedup download --releasever=24 RPM Fusion for Fedora 24 - Free 574 kB/s | 326 kB 00:00 Fedora 24 - x86_64 3.0 MB/s | 47 MB 00:15 marmotte 154 kB/s | 15 kB 00:00 RPM Fusion for Fedora 24 - Nonfree 317 kB/s | 64 kB 00:00 RPM Fusion for Fedora 24 - Free - Updates 367 kB/s | 75 kB 00:00 Fedora 24 - x86_64 - Updates 672 kB/s | 13 MB 00:19 RPM Fusion for Fedora 24 - Nonfree - Updates 173 kB/s | 18 kB 00:00 Error: package motion-3.3.0.trunkREV561-1.fc23.x86_64 requires libavcodec.so.56()(64bit), but none of the providers can be installed (try to add '--allowerasing' to command line to replace conflicting packages) [root@ultra ~]# dnf remove motion Dependencies resolved. ================================================================================ Package Arch Version Repository Size ================================================================================ Removing: motion x86_64 3.3.0.trunkREV561-1.fc23 @rpmfusion-free-updates-testing 923 k sqlite-libs x86_64 3.11.0-3.fc23 @updates 879 k Transaction Summary ================================================================================ Remove 2 Packages Installed size: 1.8 M Is this ok [y/N]: y Running transaction check Transaction check succeeded. Running transaction test Transaction test succeeded. Running transaction Erasing : motion-3.3.0.trunkREV561-1.fc23.x86_64 1/2 Erasing : sqlite-libs-3.11.0-3.fc23.x86_64 2/2 Verifying : motion-3.3.0.trunkREV561-1.fc23.x86_64 1/2 Verifying : sqlite-libs-3.11.0-3.fc23.x86_64 2/2 Removed: motion.x86_64 3.3.0.trunkREV561-1.fc23 sqlite-libs.x86_64 3.11.0-3.fc23 Complete! ...and you imagine how it went from there! FWIW, I'm lucky enough to know how to quickly fix this, as dnf no longer works, but rpm neither (NSS error)!!! For reference, a quick fix : From another system, download and extract the package that was removed, then sync over the files : wget https://dl.fedoraproject.org/pub/fedora/linux/updates/23/x86_64/s/sqlite-libs-3.11.0-3.fc23.x86_64.rpm rpm2cpio sqlite-libs-3.11.0-3.fc23.x86_64.rpm | cpio -dimv rsync -avP usr/ root@ultra:/usr From there, just 'dnf install sqlite-libs' on the affected system to get back to a consistent state.
not fixed , we got one new report on f24 . https://ask.fedoraproject.org/en/question/92033/dnf-remove-a-packege-wants-to-remove-half-of-system/
(In reply to Sergio Monteiro Basto from comment #29) > not fixed , > we got one new report on f24 . > https://ask.fedoraproject.org/en/question/92033/dnf-remove-a-packege-wants- > to-remove-half-of-system/ there is no version of libsolv specified.
also, python-matplotlib is direct dependency of python-ipython. so that's quite expected.
Igor , we must have an opened bug about this feature of clean_requirements_on_remove in dnf , which is enabled by default , and destroys the system (not my words) , I talked with you in g+ , about this... What bug you have choose ? :)