From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lists.gentoo.org ([140.105.134.102] helo=robin.gentoo.org) by nuthatch.gentoo.org with esmtp (Exim 4.50) id 1EX0qx-0005k2-Fc for garchives@archives.gentoo.org; Tue, 01 Nov 2005 18:27:23 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.5/8.13.5) with SMTP id jA1IOQDi005283; Tue, 1 Nov 2005 18:24:26 GMT Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by robin.gentoo.org (8.13.5/8.13.5) with ESMTP id jA1IOQtf019562 for ; Tue, 1 Nov 2005 18:24:26 GMT Received: from list by ciao.gmane.org with local (Exim 4.43) id 1EX0lq-00048n-AQ for gentoo-amd64@lists.gentoo.org; Tue, 01 Nov 2005 19:22:06 +0100 Received: from ip68-230-97-182.ph.ph.cox.net ([68.230.97.182]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 01 Nov 2005 19:22:06 +0100 Received: from 1i5t5.duncan by ip68-230-97-182.ph.ph.cox.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 01 Nov 2005 19:22:06 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-amd64@lists.gentoo.org From: Duncan <1i5t5.duncan@cox.net> Subject: [gentoo-amd64] Re: Re: libungif and giflib conflict. Date: Tue, 01 Nov 2005 11:19:22 -0700 Organization: Sometimes Message-ID: References: <3ab1ed150510312136j4ea70304g81186f14c5cab492@mail.gmail.com> <20051101055203.GA19589@crud.crud.mn.org> <20051101060037.GA30285@localhost> <20051101173928.GA13381@localhost> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-amd64@gentoo.org Reply-to: gentoo-amd64@lists.gentoo.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: ip68-230-97-182.ph.ph.cox.net User-Agent: Pan/0.14.2.91 (As She Crawled Across the Table) Sender: news X-Archives-Salt: 78c87a40-a54a-470b-87f0-afc54d37996b X-Archives-Hash: f628315fb98c5137cb0cda0c210e4c57 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