Gentoo Archives: gentoo-amd64

From: Nick Currier <docfreezzzz@×××××.com>
To: gentoo-amd64@l.g.o
Subject: Re: [gentoo-amd64] Re: Re: libungif and giflib conflict.
Date: Wed, 02 Nov 2005 04:32:25
In Reply to: [gentoo-amd64] Re: Re: libungif and giflib conflict. by Duncan <>
Looks like that got it guys. Thanks tons for the help.... It seems I broke
portage by running only part ~amd64 packages. 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.


On 11/1/05, Duncan <1i5t5.duncan@×××.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/ -> > > > > > > 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 > > > > -- > gentoo-amd64@g.o mailing list > >


Subject Author
Re: [gentoo-amd64] Re: Re: libungif and giflib conflict. Harm Geerts <harmgeerts@××××.nl>