RE: [gentoo-amd64] Re: Revdep-rebuild - broken dependencies

[Clemente Aguiar]

> -----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-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