1 |
Clemente Aguiar posted |
2 |
<6A0C419392D7BA45BD141D0BA4F253C7F71A13@×××××××××××××××××××××××××.pt>, |
3 |
excerpted below, on Mon, 10 Apr 2006 10:57:17 +0100: |
4 |
|
5 |
> Actually everything went quite well and the system is running, but I do |
6 |
> have a weird problem with the results of revdep-rebuild. |
7 |
> |
8 |
> When I run revdep-rebuild I get the following list of broken |
9 |
> dependencies: |
10 |
> ---------- |
11 |
> Checking dynamic linking consistency... |
12 |
> broken /opt/blackdown-jdk-1.4.2.03/jre/lib/amd64/libjsoundalsa.so |
13 |
> (requires libasound.so.2) |
14 |
> broken /usr/bin/xterm (requires libXaw.so.8) |
15 |
> broken /usr/kde/3.4//lib64/kde3/kded_mediamanager.so (requires |
16 |
> libdbus-1.so.0 libhal-storage.so.0 libhal.so.0) |
17 |
> broken /usr/kde/3.4/lib/kde3/kded_mediamanager.so (requires |
18 |
> libdbus-1.so.0 libhal-storage.so.0 libhal.so.0) |
19 |
> ---------- |
20 |
> |
21 |
> At the end revdep-rebuild just re-emerges blackdown-jdk. |
22 |
> If I re-run revdep-rebuild then the same list of broken dependencies are |
23 |
> shown and the same package is re-emerged. |
24 |
> So basically running revdep-rebuild does not solve the problem of broken |
25 |
> dependencies. |
26 |
|
27 |
Well, blackdown-jdk is a binary package. As such, remerging it will |
28 |
normally just remerge the same package with the same dependencies, since |
29 |
it's compiled not against what's on your system but against what existed |
30 |
on the supplier's system when they compiled it. Unfortunately, |
31 |
revdep-rebuild isn't really smart enough to figure that out. |
32 |
|
33 |
What version of gentoolkit (the package that contains revdep-rebuild) do |
34 |
you have? Are you on ~arch or stable arch? Newer revdep-rebuilds include |
35 |
a method for blacklisting certain packages, normally binaries, so it knows |
36 |
not to remerge them. However, I'm not sure how old that feature is or if |
37 |
it's in stable gentoolkit yet. In any case, check the revdep-rebuild |
38 |
manpage and examine /etc/revdep-rebuild/* if you have that dir. |
39 |
|
40 |
In this case, libasound.so.2 is part of alsa-lib (according to equery). |
41 |
However, if you have a 32-bit java, you'd need a 32-bit alsa-lib as well. |
42 |
I'm not sure if that's provided by one of the 32-bit compatibility |
43 |
libraries or not. (It's not provided by anything I have merged, but I |
44 |
have the bare minimal 32-bit stuff merged as about the only thing I use it |
45 |
for other than the multilib stuff for sandbox/gcc/glibc is grub.) If you |
46 |
have the 32-bit compatibility libraries merged, and one of them contains |
47 |
the correct library, revdep-rebuild obviously can't see it, so you'll need |
48 |
to add the dir where it is to the search-path. Of course, if you have a |
49 |
64-bit java and have alsa-lib with libasound.so.2, then revdep-rebuild |
50 |
should be finding it. |
51 |
|
52 |
For the other errors, see what equery belongs <file> (where file is the |
53 |
broken one) returns. Normally, revdep-rebuild will rebuild that package. |
54 |
If the equery returns nothing, then that file is orphaned and you either |
55 |
installed it manually (not using portage) or portage somehow lost track of |
56 |
it. You may wish to consider deleting it, unless you installed it |
57 |
manually. |
58 |
|
59 |
If the equery returns a package, then you probably hit a known |
60 |
bug with revdep-rebuild. The newest ~arch version may fix it, or not. |
61 |
I'm not sure as I solved the problem manually. Basically, what's |
62 |
happening is that on amd64, there's something returning /lib64 when it |
63 |
should be returning lib64 (no prepended /). This causes certain packages |
64 |
(KDE's arts among them) to put a path with a doubled // in one of the |
65 |
config files where it should of course be a regular path (single / dir |
66 |
separator). Most stuff can figure out that // means / and work around the |
67 |
issue, but revdep-rebuild wasn't doing so, and was therefore skipping a |
68 |
path that it needed to search, breaking its dependency resolution. |
69 |
There's a patch in the newest gentoolkit that's supposed to resolve this, |
70 |
I think, but I believe I saw one report that it didn't. |
71 |
|
72 |
In any case, once I figured out the revdep-rebuild issue (with the help of |
73 |
the related bugs), I was able to correct the offending // paths (grep // |
74 |
/etc/env.d/* , then edit the files appropriately, removing the // paths) |
75 |
by hand, then run env-update, and after that revdep-rebuild could find |
76 |
what it was missing before. |
77 |
|
78 |
-- |
79 |
Duncan - List replies preferred. No HTML msgs. |
80 |
"Every nonfree program has a lord, a master -- |
81 |
and if you use the program, he is your master." Richard Stallman in |
82 |
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html |
83 |
|
84 |
|
85 |
-- |
86 |
gentoo-amd64@g.o mailing list |