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: Nick Currier <docfreezzzz@...>
Subject: Re: Re: Re: libungif and giflib conflict.
Date: Tue, 1 Nov 2005 22:30:54 -0600
Looks like that got it guys.&nbsp; Thanks tons for the help.... It
seems I broke portage by running only part ~amd64 packages.&nbsp;
revdep-rebuild found it but it took twice to fix..... depclean wants to
get rid of tons of stuff though so I'm thinking this is a bad idea or I
have bigger problems.... Kudos to AMD64 Gentoo for the best support
team in open source.<br>
<br>
Nick<br><br><div><span class="gmail_quote">On 11/1/05, <b class="gmail_sendername">Duncan</b> &lt;<a href="mailto:1i5t5.duncan@...">1i5t5.duncan@...</a>&gt; wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Brian Litzinger posted &lt;20051101173928.GA13381@localhost
&gt;, excerpted<br>below,&nbsp;&nbsp;on Tue, 01 Nov 2005 09:39:29 -0800:<br><br>&gt; Been ~amd64 since the day I got this laptop.<br>&gt;<br>&gt; The last time I hit the problem was on
<br>&gt;<br>&gt; lrwxrwxrwx&nbsp;&nbsp;1 root root 15 Oct 21 14:43 /usr/lib/libungif.so.4 -&gt;<br>&gt; libgif.so.4.1.3<br>&gt;<br>&gt; when I finally got tired and created the link.<br>&gt;<br>&gt; Thus on Oct 21st at 13:43 (PST) you could still experience the
<br>&gt; problem as a ~amd64 type.<br>&gt;<br>&gt; I got slapped in the face as a small child for filing a duplicate<br>&gt; bug.&nbsp;&nbsp;Thus I am, as an adult, unable to file bugs. :(<br><br>Did you do what I and others have suggested, a revdep-rebuild?&nbsp;&nbsp;Note that
<br>existing packages on your system may still be linked against the old<br>library.&nbsp;&nbsp;Once it's in their binaries...<br><br>revdep-rebuild (as with anything portage related, run it with the -p the<br>first time thru to see what it's going to do) is designed to scan your
<br>existing binaries to see what they need, and your existing library path<br>(that ld uses to find the libs it needs) to see what's provided.&nbsp;&nbsp;Then it<br>makes a list of all the binaries (both executables, and libs that load
<br>other libs) that have unfilled dependencies using the existing libraries,<br>traces down the packages they belong to, and remerges them (or with -p,<br>displays what it would merge), the intent being to recompile and relink
<br>anything that's missing dependencies, either linking against new or<br>alternate versions of same, or pulling in the required dependencies to<br>merge as well.<br><br>Of course, this only works once that library has gone missing.&nbsp;&nbsp;If you run
<br>revdep-rebuild with the library (or a symlink pointing to an alternate)<br>still there, it'll think everything is fine and not list the package<br>owning the library in question for remerge.<br><br>Decently updated packages that formerly linked against libungif should now
<br>link against libgif without difficulty.&nbsp;&nbsp;However, with existing package on<br>the system linked against libungif, it's only to be expected that said<br>binaries would have issues.&nbsp;&nbsp;The easiest way to fix them is to run
<br>revdep-rebuild.&nbsp;&nbsp;In fact, revdep-rebuild, along with emerge --newuse<br>--update --deep world, should be a regular part of the routine to keep a<br>well maintained and upto date system.<br><br>(Another part of the same routine should be emerge depclean, but be sure
<br>the revdep-rebuild and emerge --newuse are completed first, and check the<br>output of a --pretend depclean for stuff you know you want to keep around,<br>before letting it do its thing.&nbsp;&nbsp;Then run revdep-rebuild again afterward,
<br>just to be sure.)<br><br>These apply to some degree to everyone, but a bit less to slower moving<br>stable, than to faster moving ~arch.&nbsp;&nbsp;Since ~arch may merge three versions<br>for every version that goes stable, including beta and rc versions on
<br>occasion, cruft tends to buildup rather faster than it will on a stable<br>system.<br><br>--<br>Duncan - List replies preferred.&nbsp;&nbsp; No HTML msgs.<br>&quot;Every nonfree program has a lord, a master --<br>and if you use the program, he is your master.&quot;&nbsp;&nbsp;Richard Stallman in
<br><a href="http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html">http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html</a><br><br><br>--<br><a href="mailto:gentoo-amd64@g.o">gentoo-amd64@g.o
</a> mailing list<br><br></blockquote></div><br>
Replies:
Re: Re: Re: libungif and giflib conflict.
-- Harm Geerts
References:
libungif and giflib conflict.
-- Nick Currier
Re: libungif and giflib conflict.
-- Barry . SCHWARTZ
Re: libungif and giflib conflict.
-- Brian Litzinger
Re: libungif and giflib conflict.
-- Duncan
Re: Re: libungif and giflib conflict.
-- Brian Litzinger
Re: Re: libungif and giflib conflict.
-- Duncan
Navigation:
Lists: gentoo-amd64: < Prev By Thread Next > < Prev By Date Next >
Previous by thread:
Re: Re: libungif and giflib conflict.
Next by thread:
Re: Re: Re: libungif and giflib conflict.
Previous by date:
Re: Root on Raid and LVM - Solved
Next by date:
Re: Re: Root on Raid and LVM


Updated Jun 17, 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.