From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lists.gentoo.org ([140.105.134.102] helo=robin.gentoo.org) by nuthatch.gentoo.org with esmtp (Exim 4.62) (envelope-from ) id 1IA1Hi-0004DL-Nz for garchives@archives.gentoo.org; Sun, 15 Jul 2007 10:25:03 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.14.0/8.14.0) with SMTP id l6FANBUH025171; Sun, 15 Jul 2007 10:23:11 GMT Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by robin.gentoo.org (8.14.0/8.14.0) with ESMTP id l6FANBxK025166 for ; Sun, 15 Jul 2007 10:23:11 GMT Received: from list by ciao.gmane.org with local (Exim 4.43) id 1IA1Ft-0003ML-9P for gentoo-amd64@lists.gentoo.org; Sun, 15 Jul 2007 12:23:09 +0200 Received: from ip68-230-68-110.ph.ph.cox.net ([68.230.68.110]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 15 Jul 2007 12:23:09 +0200 Received: from 1i5t5.duncan by ip68-230-68-110.ph.ph.cox.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 15 Jul 2007 12:23:09 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-amd64@lists.gentoo.org From: Duncan <1i5t5.duncan@cox.net> Subject: [gentoo-amd64] Re: [gentoo-user] Collisions when compiling glibc-2.5-r3 and r4 on amd64 Date: Sun, 15 Jul 2007 10:23:02 +0000 (UTC) Message-ID: References: <1184460910.24252.59.camel@marcec.huntemann.uni-oldenburg.de> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-amd64@gentoo.org Reply-to: gentoo-amd64@lists.gentoo.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: ip68-230-68-110.ph.ph.cox.net User-Agent: Pan/0.131 (Ghosts: First Variation) Sender: news X-Archives-Salt: 47ff9ba8-6660-402c-9068-3f49cd35774d X-Archives-Hash: 277508ab8b1dfeeec70327ae065e93e9 Marc Joliet posted 1184460910.24252.59.camel@marcec.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://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@gentoo.org mailing list