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