> -----Mensagem original-----
> De: news [mailto:news@...] Em nome de Duncan
> Enviada: segunda-feira, 10 de Abril de 2006 12:55
> Para: firstname.lastname@example.org
> 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
> > 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).
email@example.com mailing list