Bug 245362 – sys-apps/portage: Should recognize lib => lib64 symlink in preserved-libs code

• Product: Portage Development
• Status: RESOLVED FIXED

[Description Richard Li 2008-11-03 05:42:06 UTC]

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.

[Comment 1 Zac Medico 2008-11-03 06:39:43 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.

[Comment 2 Richard Li 2008-11-03 07:13:09 UTC]

(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....)

[Comment 3 Zac Medico 2008-11-03 07:26:27 UTC]

(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.

[Comment 4 Zac Medico 2008-11-09 07:22:48 UTC]

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.

[Comment 5 Zac Medico 2008-11-11 22:28:03 UTC]

This is fixed in 2.2_rc14.