Bug 188559 – sys-apps/portage-2.1.3.4 lib -> $(get_libdir) cause some libs to be cleaned

• Product: Portage Development
• Status: RESOLVED FIXED

[Description Peter Volkov (RETIRED) 2007-08-12 10:27:11 UTC]

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.

[Comment 1 Peter Volkov (RETIRED) 2007-08-12 10:34:58 UTC]

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.

[Comment 2 Peter Volkov (RETIRED) 2007-08-12 11:08:51 UTC]

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.

[Comment 3 Zac Medico 2007-08-12 11:47:50 UTC]

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.

[Comment 4 Zac Medico 2007-08-12 16:27:48 UTC]

This has been released in 2.1.3.5.