Marc Joliet <marcec gmx.de> posted
1184460910.24252.59.camelmarcec.huntemann.uni-oldenburg.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://b
ugs.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-amd64gentoo.org mailing list
|
