Title: Possible failure to preserve libraries
Author: Sam James <email@example.com>
Author: Hank Leininger <firstname.lastname@example.org>
We have observed in some cases corruption of Portage's internal database
(VDB), where the libraries provided by a package are not recorded. This
can break the "preserve-libs" functionality, and thus in rare cases
break your system during much later updates (even if you do not use
"preseved-libs" now, but decide to switch it on later).
The underlying problem occurs usually when glibc has been upgraded to a
new major version, but pax-utils has not yet been upgraded to a version
compatible with it (but at that moment stays undetected).
The full technical details and investigation can be found on a Wiki page
 and on Bugzilla . Changes have been made to prevent this happening
again both within Portage  (with possibly more to come ) and within the
glibc and pax-utils ebuilds .
To detect whether a system is affected, emerge the
$ emerge --ask --verbose --oneshot app-portage/recover-broken-vdb
which provides two tools: recover-broken-vdb-find-broken.sh and
Then run recover-broken-vdb-find-broken.sh:
$ recover-broken-vdb-find-broken.sh | tee broken_vdb_packages
This check should be run on all Gentoo systems. It is only necessary
to run this as a one-off, as changes have been made to prevent such
problems occurring in future.
If you have any output, read on.
Fixing a broken system is not always straightforward. It is strongly
recommended to take a backup of your full system before proceeding,
as well as a copy of /var/db/pkg (the VDB):
Step 1. A tool has been developed  to attempt to fix the consistency
of the Portage database. Using this tool to modify the VDB is NOT
mandatory (read the full news item before proceeding) - you can skip
to Step 2 if you wish, but fixing the integrity of the VDB
makes it as safe as reasonably possible to proceed with
# Take a backup of /var/db/pkg before proceeding, such as by doing:
$ cp -a /var/db/pkg /var/db/pkg.orig
# And then:
$ emerge --ask --verbose --oneshot --noreplace \
# The tool will output to a random temporary directory.
# Inspect the results, and then update the real /var/db/pkg/
# by doing either:
$ recover-broken-vdb --output /var/db/pkg
# Or, manually copying the new files from the temporary directory tree
# into your real /var/db/pkg/ directory tree.
Step 2. Attempt to rebuild the affected packages, first upgrading
app-misc/pax-utils to the latest version:
$ emerge --ask --verbose --oneshot ">=app-misc/pax-utils-1.3.3"
$ emerge --ask --verbose --oneshot --usepkg=n $(grep -v '#' broken_vdb_packages)
It's possible that the relevant versions have disappeared from the tree, so
if the emerge command fails, please attempt a normal world upgrade.
Step 3. Given that there are possible other side-effects of the corruption/bug,
it is strongly recommended that if any corruption is detected, all
packages on the system should be rebuilt, after following the above
$ emerge --ask --emptytree --usepkg=n @world
Note that binary packages may need to be discarded given they may
contain corrupt metadata.
If no libraries were broken, it is likely safe to skip this step. It
should be sufficient, for resource-constrained machines, to simply
rebuild any broken libraries and their consumers (reverse-dependencies):
revdep-rebuild may help you do this.
(If you do not know what that means, please proceed with Step 3.)
Please see the wiki  for a full description of the background
of this problem and handling corner cases such as e.g. already
being affected by system breakage  as a result of the bug.