[gentoo-amd64] Re: Messed up virtual/glibc?

[Duncan]

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
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html


-- 
gentoo-amd64@g.o mailing list