Summary: | sys-apps/portage: Should recognize lib => lib64 symlink in preserved-libs code | ||
---|---|---|---|
Product: | Portage Development | Reporter: | Richard Li <admin> |
Component: | Core | Assignee: | Portage team <dev-portage> |
Status: | RESOLVED FIXED | ||
Severity: | normal | Keywords: | InVCS |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | AMD64 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 240323, 210077 |
Description
Richard Li
2008-11-03 05:42:06 UTC
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. |