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.43) id 1DsGuS-0002Xn-UP for garchives@archives.gentoo.org; Tue, 12 Jul 2005 09:18:37 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.4/8.13.4) with SMTP id j6C9FQp7020374; Tue, 12 Jul 2005 09:15:26 GMT Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by robin.gentoo.org (8.13.4/8.13.4) with ESMTP id j6C9FPGS013789 for ; Tue, 12 Jul 2005 09:15:25 GMT Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DsGru-000389-Nf for gentoo-amd64@lists.gentoo.org; Tue, 12 Jul 2005 11:15:58 +0200 Received: from ip68-230-66-193.ph.ph.cox.net ([68.230.66.193]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 12 Jul 2005 11:15:58 +0200 Received: from 1i5t5.duncan by ip68-230-66-193.ph.ph.cox.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 12 Jul 2005 11:15:58 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-amd64@lists.gentoo.org From: Duncan <1i5t5.duncan@cox.net> Subject: [gentoo-amd64] Re: Messed up virtual/glibc? Date: Tue, 12 Jul 2005 02:15:03 -0700 Organization: Sometimes Message-ID: References: <42D1C203.3050609@verizon.net> <42D2391E.6020900@gentoo.org> <42D256F1.3060103@verizon.net> <1121089729.30416.1.camel@localhost> <42D2F1D1.7080208@verizon.net> 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=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: ip68-230-66-193.ph.ph.cox.net User-Agent: Pan/0.14.2.91 (As She Crawled Across the Table) Sender: news X-Archives-Salt: cc83eefc-f895-45f3-bb17-28fe1f92265f X-Archives-Hash: 156b02ad6a15041b596f10ee50486ac4 Richard Freeman posted <42D2F1D1.7080208@verizon.net>, excerpted below, on Mon, 11 Jul 2005 18:25:21 -0400: > I had thought of doing the grep on /usr/portage, but you had a good point > in checking the overlay. I discovered I had a glibc package hidden in > there, and after I nuked it the problem went away. I'm not quite sure why > - it wasn't the version I was actually running. It wouldn't /have/ to be the version you had merged. If a package appears in the dependency tree or system requirements at all, it becomes part of the dependency tree portage must calculate to see what's available and match that against what's required. If one of those packages has a screwed up dependency that nothing matches, it screws up the dependency calculation for the entire tree, as it did here. If I'm piecing information I've read on gentoo-dev together correctly with information I've gathered from other sources, what happened here is that a former dependency on glibc itself has been virtuallized to a virtual/libc dependency instead, thus allowing other libc implementations such as ulibc (micro-libc, for embedded) and the FreeBSD libc (for the Gentoo-FBSD project now nearing its first official release) to also provide virtual/libc and fill the dependency in most instances. Stuff that's in the normal portage tree has of course been updated and kept in sync so there's no issue there. However, ebuilds in the overlay are be definition not updated with the portage tree, so that ebuild in your overlay wasn't updated to reflect the necessary changes, and when the changes got drastic enough, began causing issues. Once you figure it out, the fix is easy enough -- deleting or changing the old ebuilds in the overlay. Unfortunately, with portage's dependency tracking blown up, it's not possible for it to map the dependencies it needs to be able to figure out what went wrong, only to point out which dependency is broken, and an error message to that effect doesn't always point one at the real problem, particularly for someone who doesn't have at least a minimal understanding of the sorts of things portage has to do to actually sort all this stuff out. Really, it continues to amaze me how well portage actually /does/ do in calculating dependencies, or rather, that it does it so well in such little time, instead of taking hours to actually figure it all out. That it can manage all that in almost real-time, in the few seconds (if the data is cached) to minutes (if it must be read in from disk) it actually takes, is truly amazing, when I think about it. -- 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 in http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html -- gentoo-amd64@gentoo.org mailing list