Summary: | portage does not preserve libs for binaries in /usr/lib64/kde4/libexec | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Dennis Schridde <dschridde+gentoobugs> |
Component: | [OLD] KDE | Assignee: | Portage team <dev-portage> |
Status: | RESOLVED NEEDINFO | ||
Severity: | normal | CC: | kde |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
See Also: | https://bugs.gentoo.org/show_bug.cgi?id=928345 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 240323 |
Description
Dennis Schridde
2011-03-14 20:59:35 UTC
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. |