I upgraded app-emulation/virtualbox-ose from 2.0.2 to 2.0.4 and found some files missing. (/usr/lib64/virtualbox-ose/VBoxDD2.so etc.) I think this should be a problem with Portage: In amd64 systems /usr/lib is a symlink to /usr/lib64. For virtualbox-ose-2.0.2, these files are known to Portage as /usr/lib/virtualbox-ose/VBox*.so; for 2.0.4, they are known as /usr/lib64/virtualbox-ose/VBox*.so. Because Portage does not recognize the /usr/lib => /usr/lib64 symlink, it installed the new files as '/usr/lib64/virtualbox-ose/VBox*.so' and then attempted to remove the old files '/usr/lib/virtualbox-ose/VBox*.so', which in effect removed the files that had just been installed. Reproducible: Always Steps to Reproduce: 1. Install portage-2.2_rc13 2. Install app-emulation/virtualbox-ose-2.0.2 3. Upgrade virtualbox-ose to 2.0.4 4. Try running VirtualBox Actual Results: VirtualBox complains missing .so files. Must reemerge virtualbox-ose-2.0.4.
It's supposed to work, and I'm not able to reproduce the problem that you report. Can you reproduce it with --verbose and attach the log of the merge process? For example, here's the output of a testcase that I tried locally: >>> Installing app-portage/libdir-test-1.2 * checking 1 files for package collisions --- /usr/ --- /usr/lib64/ >>> /usr/lib64/libdir-test >>> Safely unmerging already-installed instance... No package files given... Grabbing a set. --- replaced obj /usr/lib/libdir-test --- replaced dir /usr --- !empty dir /usr/lib My testcase works as expected. The way that it handles symlinked directories is that the device and inode numbers of the files, returned from lstat() calls, are compared when checking if the newly installed package owns a given file.
(In reply to comment #1) I tried downgrading and then upgrading virtualbox-ose, but now virtualbox-ose-2.0.2 uses /usr/lib64 too, so I am not able to reproduce it. (I tried a simple example like you did, but this time it works well..) I lost the log of my first emerging, but I remember there was something like this: ---replace obj /usr/lib64/virtualbox-ose/VBoxVMM.so ---replace obj /usr/lib64/virtualbox-ose/VBoxRT.so ...... !needed /usr/lib/virtualbox-ose/VBoxVMM.so !needed /usr/lib/virtualbox-ose/VBoxRT.so app-emulation/virtualbox-ose was known as app-emulation/virtualbox. My original 2.0.2 was installed before the name change. Is it possible that it had something to do with that? (This is completely guessing....)
(In reply to comment #2) > !needed /usr/lib/virtualbox-ose/VBoxVMM.so > !needed /usr/lib/virtualbox-ose/VBoxRT.so It's because the preserve-libs code relies on path comparison instead of comparing inodes. We can fix that.
This is fixed in svn r11831. The new lib preservation code uses inode comparison so it will recognize that paths under /usr/lib64/ and /usr/lib/ refer to the same files, which should prevent it from unnecessarily preserving libraries like VBoxVMM.so and VBoxRT.so were.
This is fixed in 2.2_rc14.
