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

[Marc Joliet]

Am Sonntag, den 15.07.2007, 10:23 +0000 schrieb 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)

I only activated it because I also run games and I recall it being
recommended to activate it when using 3rd party binaries.

> 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?

No, I haven't seen it. Though I can't tell if it may be related, plus
the bug is marked "resolved fixed", so I assume it still is. Though I am
confused as to how a collision in glibc could have been missed. That's
why I thought it may be an error on my account, or a broken file
somewhere (and the likes).

Also, I am very up to date. I run a cron-job every day at 23:00 to sync
and then manually update. So I have the most recent stable of everything
I have, along with a select few applications as ~amd64 and exactly 3
packages unmasked (ut99 related packages).

> 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!

Me neither :-|.

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

Thanks for the info. Sorry to say, but my gentoo install was originally
Sabayon. However, I moved to stable arch and removed the Sabayon
overlay. So my system seems to be pure gentoo now, with only a few
remnants of Sabayon: the boot splash, for instance, and the fact that
Sabayon per default creates all file systems on a logical volume. I'll
have to make some corrections to my fs setup sometime, like move /boot
off the volume and make a separate /home partition. Blegh.

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

Thanks for the help, I guess this means it ought to be reported as a
bug.
-- 
Marc Joliet