If on amd64 system you'll change in ebuild /lib/ on $(get_libdir) after emerge portage will clean some files from newly installed package. Test case follows.
Created attachment 127835 [details] foo-0.ebuild Consider the following ebuild. It'll install /lib/foo/test.lib.so. Install it. After this do sed -ie 's:lib/:$(get_libdir)/:g' foo-0.ebuild and emerge foo again. I see the following output: >>> Merging net-analyzer/foo-0 to / --- /lib64/ --- /lib64/foo/ >>> /lib64/foo/test.lib.so >>> Safely unmerging already-installed instance... No package files given... Grabbing a set. <<< obj /lib/foo/test.lib.so --- replaced dir /lib/foo --- replaced dir /lib >>> Original instance of package unmerged safely. >>> net-analyzer/foo-0 merged. Look: portage cleaned newly installed test.lib.so. Reverse is also correct. sed -ie 's:$(get_libdir)/:lib/:g' foo-0.ebuild This means if we fix some ebuilds in the tree so that they work on amd64 update could fail for some users. I've encountered this problem during work on ebtables and fond that one lib, and only one while it have about ten libs, is unmerged. Thank you for your time.
As grobian correctly pointed me in IRC I forgot to note, that lib is symlink of lib64 and thus /lib/foo/test.lib.so and /lib64/foo/test.lib.so are the same files.
Created attachment 127852 [details, diff] invalidate dblink._contents_inodes as necessary This is fixed in svn r7592. The bug is only triggered when FEATURES=collision-protect is enabled.
This has been released in 2.1.3.5.
