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
In Reply to: [gentoo-amd64] Revdep-rebuild - broken dependencies by Clemente Aguiar
Clemente Aguiar posted
excerpted below,  on Mon, 10 Apr 2006 10:57:17 +0100:

> Actually everything went quite well and the system is running, but I do > have a weird problem with the results of revdep-rebuild. > > When I run revdep-rebuild I get the following list of broken > dependencies: > ---------- > Checking dynamic linking consistency... > broken /opt/blackdown-jdk- > (requires > broken /usr/bin/xterm (requires > broken /usr/kde/3.4//lib64/kde3/ (requires > > broken /usr/kde/3.4/lib/kde3/ (requires > > ---------- > > At the end revdep-rebuild just re-emerges blackdown-jdk. > If I re-run revdep-rebuild then the same list of broken dependencies are > shown and the same package is re-emerged. > So basically running revdep-rebuild does not solve the problem of broken > dependencies.
Well, blackdown-jdk is a binary package. As such, remerging it will normally just remerge the same package with the same dependencies, since it's compiled not against what's on your system but against what existed on the supplier's system when they compiled it. Unfortunately, revdep-rebuild isn't really smart enough to figure that out. What version of gentoolkit (the package that contains revdep-rebuild) do you have? Are you on ~arch or stable arch? Newer revdep-rebuilds include a method for blacklisting certain packages, normally binaries, so it knows not to remerge them. However, I'm not sure how old that feature is or if it's in stable gentoolkit yet. In any case, check the revdep-rebuild manpage and examine /etc/revdep-rebuild/* if you have that dir. In this case, is part of alsa-lib (according to equery). However, if you have a 32-bit java, you'd need a 32-bit alsa-lib as well. I'm not sure if that's provided by one of the 32-bit compatibility libraries or not. (It's not provided by anything I have merged, but I have the bare minimal 32-bit stuff merged as about the only thing I use it for other than the multilib stuff for sandbox/gcc/glibc is grub.) If you have the 32-bit compatibility libraries merged, and one of them contains the correct library, revdep-rebuild obviously can't see it, so you'll need to add the dir where it is to the search-path. Of course, if you have a 64-bit java and have alsa-lib with, then revdep-rebuild should be finding it. For the other errors, see what equery belongs <file> (where file is the broken one) returns. Normally, revdep-rebuild will rebuild that package. If the equery returns nothing, then that file is orphaned and you either installed it manually (not using portage) or portage somehow lost track of it. You may wish to consider deleting it, unless you installed it manually. If the equery returns a package, then you probably hit a known bug with revdep-rebuild. The newest ~arch version may fix it, or not. I'm not sure as I solved the problem manually. Basically, what's happening is that on amd64, there's something returning /lib64 when it should be returning lib64 (no prepended /). This causes certain packages (KDE's arts among them) to put a path with a doubled // in one of the config files where it should of course be a regular path (single / dir separator). Most stuff can figure out that // means / and work around the issue, but revdep-rebuild wasn't doing so, and was therefore skipping a path that it needed to search, breaking its dependency resolution. There's a patch in the newest gentoolkit that's supposed to resolve this, I think, but I believe I saw one report that it didn't. In any case, once I figured out the revdep-rebuild issue (with the help of the related bugs), I was able to correct the offending // paths (grep // /etc/env.d/* , then edit the files appropriately, removing the // paths) by hand, then run env-update, and after that revdep-rebuild could find what it was missing before. -- 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 -- gentoo-amd64@g.o mailing list