> -----Mensagem original-----
> De: news [mailto:news@...] Em nome de Duncan
> Enviada: segunda-feira, 10 de Abril de 2006 12:55
> Para: gentoo-amd64@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-1.4.2.03/jre/lib/amd64/libjsoundalsa.so
> > (requires libasound.so.2)
> > broken /usr/bin/xterm (requires  libXaw.so.8)
> > broken /usr/kde/3.4//lib64/kde3/kded_mediamanager.so (requires 
> > libdbus-1.so.0 libhal-storage.so.0 libhal.so.0) broken 
> > /usr/kde/3.4/lib/kde3/kded_mediamanager.so (requires libdbus-1.so.0 
> > libhal-storage.so.0 libhal.so.0)
> > ----------
> > 
> > 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, libasound.so.2 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 libasound.so.2, 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 kded_mediamanager.so 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