Gentoo Archives: gentoo-amd64

From: Duncan <1i5t5.duncan@×××.net>
To: gentoo-amd64@l.g.o
Subject: [gentoo-amd64] Re: Revdep-rebuild - broken dependencies
Date: Mon, 10 Apr 2006 11:57:41
Message-Id: pan.2006.04.10.11.55.13.371988@cox.net
In Reply to: [gentoo-amd64] Revdep-rebuild - broken dependencies by Clemente Aguiar
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