Gentoo Archives: gentoo-amd64

From: Clemente Aguiar <clemente.aguiar@××××××××××××××××.pt>
To: gentoo-amd64@l.g.o
Subject: RE: [gentoo-amd64] Re: Revdep-rebuild - broken dependencies
Date: Mon, 10 Apr 2006 14:37:51
> -----Mensagem original----- > De: news [mailto:news@×××××××××.org] Em nome de Duncan > Enviada: segunda-feira, 10 de Abril de 2006 12:55 > Para: gentoo-amd64@l.g.o > Assunto: [gentoo-amd64] Re: Revdep-rebuild - broken dependencies > > > 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.
Well my problems are practically solved, except for one (blackdown-jdk). The 2 broken dependencies of the where solve removing one of the two / as you mentioned. The broken dependency of xterm was solved by manually re-emerging xterm (no revdep-rebuild did not do it automatically, maybe some little bug?) But for blackdown-jdk, I just don't know how to tell revdep-rebuild not to re-emerge the package. My gentoolkit version is 0.2.1, I am running stable arch and I do not need sound (it is a server, no sound needed). Clemente -- gentoo-amd64@g.o mailing list