Summary: | sys-apps/portage-2.2_rc12: fails handling multi-level preserved-libs | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Matthias Schwarzott <zzam> |
Component: | New packages | Assignee: | Portage team <dev-portage> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | pesa |
Priority: | High | Keywords: | InVCS |
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
See Also: | https://bugs.gentoo.org/show_bug.cgi?id=652382 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 240323, 210077 | ||
Attachments: | exclude preserved libs themselves when calculating consumers of preserved libs |
Description
Matthias Schwarzott
2008-10-21 10:38:50 UTC
I had the same problem with ffmpeg and x264 upgrade.
Moreover, portage keeps saying:
!!! existing preserved libs:
>>> package: media-libs/x264-0.0.20081006
* - /usr/lib64/libx264.so.60
Use emerge @preserved-rebuild to rebuild packages using these libraries
but @preserved-rebuild is empty:
# emerge @preserved-rebuild
emerge: 'preserved-rebuild' is an empty set
emerge: no targets left after set expansion
This may confuse users a lot imho.
This happened again, with portage-2.2_rc13 this time. The preserved-libs chain was more or less the same: x264 <- ffmpeg <- k3b (and many others, k3b was the last of them). The result is that rc13 performed vastly better than rc12: the "second failure" outlined by zzam (recursive deletion of preserved libs) has been fixed! So the only remaining problem now is the "first failure", i.e. `emerge @preserved-rebuild` wants to rebuild ffmpeg when it's not necessary. Created attachment 171153 [details, diff]
exclude preserved libs themselves when calculating consumers of preserved libs
If this patch is saved as /tmp/exclude_plibs.patch then it can be applied as follows:
patch /usr/lib/portage/pym/portage/sets/libs.py /tmp/exclude_plibs.patch
This is fixed in 2.2_rc14. |