Bug 245362 - sys-apps/portage: Should recognize lib => lib64 symlink in preserved-libs code
Bug#: 245362 Product:  Portage Development Version: unspecified Platform: AMD64
OS/Version: Linux Status: RESOLVED Severity: normal Priority: P2
Resolution: FIXED Assigned To: dev-portage@gentoo.org Reported By: admin@chys.info
Component: Core
URL: 
Summary: sys-apps/portage: Should recognize lib => lib64 symlink in preserved-libs code
Keywords:  InSVN
Status Whiteboard: 
Opened: 2008-11-03 05:42 0000
Description:   Opened: 2008-11-03 05:42 0000 
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 From Zac Medico 2008-11-03 06:39:43 0000 ------- 
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 From Richard Li 2008-11-03 07:13:09 0000 ------- 
(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 From Zac Medico 2008-11-03 07:26:27 0000 ------- 
(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 From Zac Medico 2008-11-09 07:22:48 0000 ------- 
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 From Zac Medico 2008-11-11 22:28:03 0000 ------- 
This is fixed in 2.2_rc14.