On 11/1/05, Duncan <1i5t5.duncan@cox.net> wrote:

Brian Litzinger posted <20051101173928.GA13381@localhost>, excerpted
below,  on Tue, 01 Nov 2005 09:39:29 -0800:

> Been ~amd64 since the day I got this laptop.
>
> The last time I hit the problem was on
>
> lrwxrwxrwx  1 root root 15 Oct 21 14:43 /usr/lib/libungif.so.4 ->
> libgif.so.4.1.3
>
> when I finally got tired and created the link.
>
> Thus on Oct 21st at 13:43 (PST) you could still experience the
> problem as a ~amd64 type.
>
> I got slapped in the face as a small child for filing a duplicate
> bug.  Thus I am, as an adult, unable to file bugs. :(

Did you do what I and others have suggested, a revdep-rebuild?  Note that
existing packages on your system may still be linked against the old
library.  Once it's in their binaries...

revdep-rebuild (as with anything portage related, run it with the -p the
first time thru to see what it's going to do) is designed to scan your
existing binaries to see what they need, and your existing library path
(that ld uses to find the libs it needs) to see what's provided.  Then it
makes a list of all the binaries (both executables, and libs that load
other libs) that have unfilled dependencies using the existing libraries,
traces down the packages they belong to, and remerges them (or with -p,
displays what it would merge), the intent being to recompile and relink
anything that's missing dependencies, either linking against new or
alternate versions of same, or pulling in the required dependencies to
merge as well.

Of course, this only works once that library has gone missing.  If you run
revdep-rebuild with the library (or a symlink pointing to an alternate)
still there, it'll think everything is fine and not list the package
owning the library in question for remerge.

Decently updated packages that formerly linked against libungif should now
link against libgif without difficulty.  However, with existing package on
the system linked against libungif, it's only to be expected that said
binaries would have issues.  The easiest way to fix them is to run
revdep-rebuild.  In fact, revdep-rebuild, along with emerge --newuse
--update --deep world, should be a regular part of the routine to keep a
well maintained and upto date system.

(Another part of the same routine should be emerge depclean, but be sure
the revdep-rebuild and emerge --newuse are completed first, and check the
output of a --pretend depclean for stuff you know you want to keep around,
before letting it do its thing.  Then run revdep-rebuild again afterward,
just to be sure.)

These apply to some degree to everyone, but a bit less to slower moving
stable, than to faster moving ~arch.  Since ~arch may merge three versions
for every version that goes stable, including beta and rc versions on
occasion, cruft tends to buildup rather faster than it will on a stable
system.

--
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@gentoo.org mailing list