/usr/lib64/libXxf86misc.so.1 got uninstalled even though it was used by /usr/lib64/kde4/libexec/kscreenlocker (confirmed via scanelf -n). From ~/.xsession-errors: --- kscreenlocker: error while loading shared libraries: libXxf86misc.so.1: cannot open shared object file: No such file or directory startkde: Initial session lock failed. Terminating for security reasons. kglobalaccel: Fatal IO error: client killed kdeinit4: Fatal IO error: client killed kdeinit4: sending SIGHUP to children. klauncher: Exiting on signal 1 kdeinit4: Fatal IO error: client killed kdeinit4: sending SIGHUP to children. --- The issue was particularly ugly, because xsession-errors was empty almost all the time: Only one time it contained the text quoted above. Thus it took me several hours to figure this out. Reproducible: Always
binaries in /usr/lib64/kde4/libexec require the libs, but do not have to be preserved. Fixing summary accordingly
This is more for portage team than for the kde team.
(In reply to comment #0) > /usr/lib64/libXxf86misc.so.1 got uninstalled even though it was used by > /usr/lib64/kde4/libexec/kscreenlocker (confirmed via scanelf -n). How did it get uninstalled? I only see one version of the providing package: http://packages.gentoo.org/package/x11-libs/libXxf86misc FEATURES=preserve-libs currently only handles upgrades, not uninstalls. So, maybe this is a duplicate of bug #286714.
(In reply to comment #3) > (In reply to comment #0) > > /usr/lib64/libXxf86misc.so.1 got uninstalled even though it was used by > > /usr/lib64/kde4/libexec/kscreenlocker (confirmed via scanelf -n). > > How did it get uninstalled? I only see one version of the providing package: I really dont know anymore. If the major version of libXxf86misc (i.e. .so.1) has never changed, yes, maybe I ran --depclean. But then, shouldn't the library check phase of that have prevented the uninstall?
(In reply to comment #4) > I really dont know anymore. If the major version of libXxf86misc (i.e. .so.1) > has never changed, yes, maybe I ran --depclean. But then, shouldn't the library > check phase of that have prevented the uninstall? If you install it again with --oneshot, does --depclean still fail to recognize that it has reverse link-level dependencies?
No response for > 4 months
(In reply to comment #5) > If you install it again with --oneshot, does --depclean still fail to recognize > that it has reverse link-level dependencies? Note that since bug 286714 got fixed, --depclean won't check for link-level dependencies (--depclean-lib-check) when FEATURES=preserve-libs is enabled. You can temporarily disable FEATURES=preserve-libs if you want --depclean-lib-check to work.
