Gentoo Archives: gentoo-amd64

From: Duncan <1i5t5.duncan@×××.net>
To: gentoo-amd64@l.g.o
Subject: [gentoo-amd64] Re: Messed up virtual/glibc?
Date: Tue, 12 Jul 2005 09:18:37
In Reply to: Re: [gentoo-amd64] Messed up virtual/glibc? by Richard Freeman
Richard Freeman posted <42D2F1D1.7080208@×××××××.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 -- gentoo-amd64@g.o mailing list