1 |
Richard Freeman posted <42D2F1D1.7080208@×××××××.net>, excerpted below, |
2 |
on Mon, 11 Jul 2005 18:25:21 -0400: |
3 |
|
4 |
> I had thought of doing the grep on /usr/portage, but you had a good point |
5 |
> in checking the overlay. I discovered I had a glibc package hidden in |
6 |
> there, and after I nuked it the problem went away. I'm not quite sure why |
7 |
> - it wasn't the version I was actually running. |
8 |
|
9 |
It wouldn't /have/ to be the version you had merged. If a package appears |
10 |
in the dependency tree or system requirements at all, it becomes part of |
11 |
the dependency tree portage must calculate to see what's available and |
12 |
match that against what's required. If one of those packages has a |
13 |
screwed up dependency that nothing matches, it screws up the dependency |
14 |
calculation for the entire tree, as it did here. |
15 |
|
16 |
If I'm piecing information I've read on gentoo-dev together correctly with |
17 |
information I've gathered from other sources, what happened here is that a |
18 |
former dependency on glibc itself has been virtuallized to a virtual/libc |
19 |
dependency instead, thus allowing other libc implementations such as ulibc |
20 |
(micro-libc, for embedded) and the FreeBSD libc (for the Gentoo-FBSD |
21 |
project now nearing its first official release) to also provide |
22 |
virtual/libc and fill the dependency in most instances. Stuff that's in |
23 |
the normal portage tree has of course been updated and kept in sync so |
24 |
there's no issue there. However, ebuilds in the overlay are be definition |
25 |
not updated with the portage tree, so that ebuild in your overlay wasn't |
26 |
updated to reflect the necessary changes, and when the changes got drastic |
27 |
enough, began causing issues. |
28 |
|
29 |
Once you figure it out, the fix is easy enough -- deleting or changing the |
30 |
old ebuilds in the overlay. Unfortunately, with portage's dependency |
31 |
tracking blown up, it's not possible for it to map the dependencies it |
32 |
needs to be able to figure out what went wrong, only to point out which |
33 |
dependency is broken, and an error message to that effect doesn't always |
34 |
point one at the real problem, particularly for someone who doesn't |
35 |
have at least a minimal understanding of the sorts of things portage has |
36 |
to do to actually sort all this stuff out. |
37 |
|
38 |
Really, it continues to amaze me how well portage actually /does/ do in |
39 |
calculating dependencies, or rather, that it does it so well in such |
40 |
little time, instead of taking hours to actually figure it all out. That |
41 |
it can manage all that in almost real-time, in the few seconds (if the |
42 |
data is cached) to minutes (if it must be read in from disk) it actually |
43 |
takes, is truly amazing, when I think about it. |
44 |
|
45 |
-- |
46 |
Duncan - List replies preferred. No HTML msgs. |
47 |
"Every nonfree program has a lord, a master -- |
48 |
and if you use the program, he is your master." Richard Stallman in |
49 |
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html |
50 |
|
51 |
|
52 |
-- |
53 |
gentoo-amd64@g.o mailing list |