In cases like bug 284458, in which lzma-utils needs to be uninstalled, it would be helpful to preserve liblzmadec.*. In this case the preserve-libs registry will reference a package which is no longer installed, and it will reference libraries which belong to a package that has been uninstalled. It should reference all preserved libraries in this same way, regardless of whether a replacement package in the same slot is installed. We may also want to consider preserving the libraries in a "quarantine directory". This will make it easier to identify preserved libraries, in case the preserve-libs registry gets corrupted, or in case we implement a way to force exclusion of the "quarantine directory" from the ld.so path used in the ebuild environment. The "quarantine directory" will also be helpful for cases like binutils upgrades, where the original path of the preserved libraries is not in the ld.so path because those libraries are added to the path by symlinks created in /usr/$CHOST/lib/ by the binutils-config program.
Currently the PreservedLibsRegistry class keeps a mapping between cp:slot and (cpv, counter, list of paths). Would you accept a patch that makes it track only paths and makes it not caring about packages at all?
Yeah, that seems reasonable.
Then no package would own any preserved lib, is that ok? If yes, do we want to remove the preserved libs from the CONTENTS of installed packages if we encounter an old preserved libs registry on disk?
Maybe we can keep the existing format but change the way it's used. In the PreservedLibsRegistry.register(cpv, slot, counter, paths) method we can pass in the information about the original package that installed the libraries. And of course we won't record preserved libs in the CONTENTS of replacement packages anymore (they'll just be listed in the preserved_libs_registry for the original package). If we do decide to change the preserved_libs_registry format then I'd suggest a plain text file with one library path listed per line.
*** Bug 319061 has been marked as a duplicate of this bug. ***
*** Bug 326411 has been marked as a duplicate of this bug. ***
Random idea: When uninstalling a package while preserving a library, can you "auto-install" a dummy package holding just that library? So uninstallation would look something like: <<< app-misc/coolpackage-1.2.3:0 >>> app-misc/coolpackage-1.2.3:preserved That way you can do the library/package reference without any extra database.
This is fixed in git: http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=c64d4abee145d083c70273be8fd23bd56dffe7ec Now the emerge --depclean-lib-check option (bug 230053) will now be ignored when FEATURES=preserve-libs is enabled, since any libraries that have consumers will simply be preserved.
(In reply to comment #7) > Random idea: When uninstalling a package while preserving a library, can you > "auto-install" a dummy package holding just that library? So uninstallation > would look something like: > <<< app-misc/coolpackage-1.2.3:0 > >>> app-misc/coolpackage-1.2.3:preserved > That way you can do the library/package reference without any extra database. We can't use the same database since we don't want has_version calls to return misleading results. Use `portageq list_preserved_libs /` if you want to query the preserved libs.
(In reply to comment #8) > This is fixed in git: > > http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=c64d4abee145d083c70273be8fd23bd56dffe7ec And here are a couple of important fixes: http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=c331b8725f4ef53d7f65b624d085cd6dad5f29e9 http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=828768a94b8aec78f2b044becf3c32a20fe05b4e
This is fixed in 2.2.0_alpha34.