Gentoo Logo
Gentoo Spaceship




Note: Due to technical difficulties, the Archives are currently not up to date. GMANE provides an alternative service for most mailing lists.
c.f. bug 424647
List Archive: gentoo-amd64
Navigation:
Lists: gentoo-amd64: < Prev By Thread Next > < Prev By Date Next >
Headers:
To: gentoo-amd64@g.o
From: Duncan <1i5t5.duncan@...>
Subject: Re: Revdep-rebuild - broken dependencies
Date: Mon, 10 Apr 2006 04:55:14 -0700
Clemente Aguiar posted
<6A0C419392D7BA45BD141D0BA4F253C7F71A13@...>,
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.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman in
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html


-- 
gentoo-amd64@g.o mailing list


References:
Revdep-rebuild - broken dependencies
-- Clemente Aguiar
Navigation:
Lists: gentoo-amd64: < Prev By Thread Next > < Prev By Date Next >
Previous by thread:
Revdep-rebuild - broken dependencies
Next by thread:
Cannot emerge gcc-3.4.5
Previous by date:
Re: really need help
Next by date:
Cannot emerge gcc-3.4.5


Updated Jun 18, 2009

Summary: Archive of the gentoo-amd64 mailing list.

Donate to support our development efforts.

Copyright 2001-2013 Gentoo Foundation, Inc. Questions, Comments? Contact us.