[gentoo-amd64] Re: [gentoo-user] Collisions when compiling glibc-2.5-r3 and r4 on amd64

[Duncan]

Marc Joliet <marcec@×××.de> posted
1184460910.24252.59.camel@××××××××××××××××××××××××××××××.de, excerpted
below, on  Sun, 15 Jul 2007 02:55:10 +0200:

> making executable: usr/lib32/libc.so
> making executable: usr/lib32/libpthread.so making executable:
> usr/lib64/libc.so
> making executable: usr/lib64/libpthread.so
> * checking 2373 files for package collisions [...]
> existing file /lib is not owned by this package
> * This package is blocked because it wants to overwrite
> * files belonging to other packages (see messages above).
> * If you have no clue what this is all about report it
> * as a bug for this package on http://bugs.gentoo.org
>
> package sys-libs/glibc-2.5-r4 NOT merged
>
>
> Searching all installed packages for file collisions... Press Ctrl-C to
> Stop
>
>  * x11-drivers/nvidia-drivers-1.0.9746-r1:
>
>      '/lib'

[snip]
 
> Is there a 'clean' work around? The only option I found is to set
> COLLISION_IGNORE="/lib" in make.conf. That seems to do the trick insofar
> that glibc merges. For "emerge --info" see attachment.
>
> Apparently, from what I read, the collision-protect[1] option is
> supposed to ignore directories. Since this was asked in other reports I
> found while searching for info: /lib is not a symlink, rather /lib64 is
> a symlink to /lib. Out of curiosity: when would /lib ever be a symlink?

It's probably a portage bug, confusion due to lib64 being a symlink to 
lib for amd64.  The thing is, not a lot of folks run collision-protect, 
and while many devs do, in a lot of cases they aren't running stable, but 
~arch.  Thus, they'll have long since moved past that version of portage, 
and may not have caught the issue (tho packages /are/ supposed to be 
tested on stable with collision-protect on, before stabilizing)

Have you seen http://bugs.gentoo.org/show_bug.cgi?id=80846 (which is 
linked from the bug you mentioned)?  It looks like either that bug or a 
special case very similar to that bug.  What portage are you running?  Is 
it the 2.1.2 series past the -pre1 mentioned in that bug?  Is portage 
updated to the latest stable on your system?

Beyond that, you'll need to let the experts tell you.  It's close enough 
to 80846 to be a dup, but if you are running portage 2.1.2 or later, 
according to that, it /should/ be fixed, so maybe it's a corner case that 
was missed, or... I don't know!

As for symlinks and lib/lib64, Gentoo/amd64 has gone both ways over the 
years.  Some release stage tarballs had lib64 -> lib, others lib -> 
lib64.  FWIW, here's what I have here/now:

$ls -d -l /lib /lib64
lrwxrwxrwx  1 root root    5 2007-05-22 23:49 /lib -> lib64/
drwxr-xr-x 10 root root 4376 2007-07-13 10:17 /lib64/

FWIW, my /usr location symlink points in the same direction as well.  
However, that's because when I switched off multilib, I tried running the 
two as separate dirs.  It didn't quite work, however, because a few 
ebuilds install to lib64 but call or install scripts that call the app in 
(hardcoded) lib, or the reverse, so they can't be separate dirs, or the 
system will be expecting it in one and not finding it, because it's in 
the other.  So, once I figured out it wouldn't work, I resymlinked them, 
and it was easiest to cp from lib to lib64, then delete lib and make it a 
symlink, so that's what I did.  IDR what it was before, or know which way 
the current release stage tarballs set it up.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

-- 
gentoo-amd64@g.o mailing list