Bugzilla – Bug 1130626
zypper forgets package dependencies
Last modified: 2020-01-14 11:31:49 UTC
This bug is relevant for all versions of openSUSE Leap, as well as for openSUSE Tumbleweed. The essence of the problem: I installed a clean system, updated, and then installed, for example, wine. Then no other packages were installed. Just an update. If you run wine removal right away, zypper will ask you to remove wine and all its dependencies(75 packages in my case). So everything works fine for a while. BUT. After a couple of days, a week or a maximum of two weeks, the removal of wine with the key `-u' will start the removal of only three packages - wine-mono wine-staging winetricks. The remaining 72 remain in the system and are not displayed in unnecessary dependencies or anywhere else. Wine is used here only as an example. This situation is absolutely with any package, even from official repositories, even from packman, even from community repositories. And this is a really serious problem.
(In reply to Vitaly Korotkov from comment #0) What's probably happening is that now other packages are also dependent on many of those 75 packages.
(In reply to Joseph Mitzen from comment #1) > (In reply to Vitaly Korotkov from comment #0) > What's probably happening is that now other packages are also dependent on > many of those 75 packages. Yes, some packages explicitly move depending on other packages. But not all at the same time! For example, the wine-staging-32bit package is also not removed, and it is doubtful that it is needed for anything without wine-staging installed.
(In reply to Joseph Mitzen from comment #1) > (In reply to Vitaly Korotkov from comment #0) > What's probably happening is that now other packages are also dependent on > many of those 75 packages. wine-staging-32bit is not removed, as well as wine-gecko, as well as dosbox, which is installed together with wine. If you can't believe that my system doesn't have packages that need some wine dependencies installed, then at least this small list should show that dependency management does not work properly.
"zypper rm -u glibc-32bit" will uninstall the remaining 72 rpms. I couldn't tell you why glibc-32bit isn't removed by default though. But there's your answer.
There might also be a flaw in packaging of wine or deps that prevents the packages from getting uninstalled. But you can write a solver testcase, by adding --debug-solver and uploading the resulting testcase here with the list of packages that do not get uninstalled. To clarify zypper does not store any package dependencies itself, thus it can also not forget them. You most likely installed new packages, that added other dependencies which blocked the remaining 75 packages from getting uninstalled.
Created attachment 801460 [details] wine-staging
Hey you'd need to zip up the whole directory (usually /var/log/zypper.solverTestCase), not just the xml file
Created attachment 801479 [details] wine-staging remove
OK, I checked your solver testcase. Lots of the 32bit wine packages are used by the steam client you have installed ( which is a 32bit binary ). Generally zypper does not remember any dependency lists on its own. Rather for every run all dependencies are read from the rpm packages and registered into the Solver which calculates the best possible solution on the fly. This is not a bug.
Edit: I had a typo there, the steam client does not use the 32bit wine packages directly but of course shares a lot of dependencies on other 32bit packages from the repositories.
Created attachment 801699 [details] remove wine, lutris, steam
What about the case with a fresh VM installation of Tumbleweed. "zypper in wine" installs 229 packages. "zypper rm -u wine" only removes 157 of those packages. This is repeatable. I don't personally care, but I was curious as to why it misses 72 packages in this case. "zypper rm -u glibc-32bit" will remove the 72 packages, but why isn't glibc-32bit removed automatically. As far as I can tell, it believes that 64-bit /bin/sh depends on glibc-32bit, maybe this is a problem.
(In reply to Benjamin Zeller from comment #10) > Edit: I had a typo there, the steam client does not use the 32bit wine > packages directly but of course shares a lot of dependencies on other 32bit > packages from the repositories. Okay. This is my last attempt. Today I reinstalled the system, installed the necessary software, and this time the packages were removed without the dependencies at once after a reboot. Here I am trying to remove anything that may have to do with wine. If there is no mistake here, I apologize for the time spent.
@Michael: Any obvious explanation for the behavior described in c#12 ?
That's hard to tell. The solver testcases have a suspicious low amount of "autoinst" lines. Maybe that's what's tripping up the solver. Benjamin, Michael, can you please reproduce this in a VM and check if the autoinst list is correct or not?
(In reply to Michael Schröder from comment #15) > That's hard to tell. The solver testcases have a suspicious low amount of > "autoinst" lines. Maybe that's what's tripping up the solver. > > Benjamin, Michael, can you please reproduce this in a VM and check if the > autoinst list is correct or not? @Michael The autoinst list is indeed small but does not seem to be the issue, I tried the same in a TW VM I had set up before. And I can confirm that installing and uninstalling wine-staging will leaves those packages behind ( comparing installed vs uninstalled packages list ): +glibc-32bit +gnome-keyring-32bit +gnome-keyring-pam-32bit +krb5-32bit +libacl1-32bit +libaudit1-32bit +libavahi-client3-32bit +libavahi-common3-32bit +libbz2-1-32bit +libcap2-32bit +libcom_err2-32bit +libcrack2-32bit +libcrypt1-32bit +libcups2-32bit +libdb-4_8-32bit +libdbus-1-3-32bit +libdcerpc0-32bit +libdcerpc-binding0-32bit +libfam0-gamin-32bit +libffi7-32bit +libgcc_s1-32bit +libgcrypt20-32bit +libgdbm6-32bit +libgdbm_compat4-32bit +libgmp10-32bit +libgnutls30-32bit +libgpg-error0-32bit +libhogweed4-32bit +libidn2-0-32bit +libjansson4-32bit +libkeyutils1-32bit +libldap-2_4-2-32bit +libldb1-32bit +liblz4-1-32bit +liblzma5-32bit +libndr0-32bit +libndr-krb5pac0-32bit +libndr-nbt0-32bit +libndr-standard0-32bit +libnetapi0-32bit +libnettle6-32bit +libnsl2-32bit +libopenssl1_1-32bit +libp11-kit0-32bit +libpcre1-32bit +libpopt0-32bit +libsamba-credentials0-32bit +libsamba-errors0-32bit +libsamba-hostconfig0-32bit +libsamba-passdb0-32bit +libsamba-util0-32bit +libsamdb0-32bit +libsasl2-3-32bit +libselinux1-32bit +libsmbconf0-32bit +libsmbldap2-32bit +libstdc++6-32bit +libsystemd0-32bit +libtalloc2-32bit +libtasn1-6-32bit +libtdb1-32bit +libtevent0-32bit +libtevent-util0-32bit +libtirpc3-32bit +libunistring2-32bit +libverto1-32bit +libwbclient0-32bit +libz1-32bit +pam-32bit +perl-32bit +samba-client-32bit +samba-libs-32bit +samba-winbind-32bit +systemd-32bit
Why is the autoinst list not an issue? libsolv will not uninstall packages that are not part of the autoinst list (as it thinks they are user installed). Can you please create two testcases, one for the install and one for the uninstall?
Created attachment 802505 [details] Testcase of installing the packages
Created attachment 802506 [details] Testcase of removal of the packages
(In reply to Michael Schröder from comment #17) > Why is the autoinst list not an issue? libsolv will not uninstall packages > that are not part of the autoinst list (as it thinks they are user > installed). You are right, lets see if the testcases help
Yes, they did. It turned out because the cleandeps code "pins" the pam32-bit package when removing supplemented packages. See the comment from the dep_pkgcheck function in cleandeps.c: /* * This functions collects all packages that are looked at * when a dependency is checked. We need it to "pin" installed * packages when removing a supplemented package in createcleandepsmap. * Here's an not uncommon example: * A contains "Supplements: packageand(B, C)" * B contains "Requires: A" * Now if we remove C, the supplements is no longer true, * thus we also remove A. Without the dep_pkgcheck function, we * would now also remove B, but this is wrong, as adding back * C doesn't make the supplements true again. Thus we "pin" B * when we remove A. * There's probably a better way to do this, but I haven't come * up with it yet ;) */ Well, the last sentence still applies ;) samba-winbind-32bit supplements (samba-winbind and pam-32bit), so when samba-winbind is removed, samba-winbind-32bit will also be removed but pam-32bit will stay. So yes, it's kind of a bug in the solver, but I need to find a different way how to solve this.
Moving to libsolv, since it can only be solved there.
Fair. Changed the severity to "minor", though.
Congrats Vitaly, you've pinned a bug on libzypp! Thanks for helping make Tumbleweed even better. In the mean time though, looks like you have to manually uninstall pam-32bit or glib-32bit after uninstalling wine for now.