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 1EWrgN-0008Pw-EQ for garchives@archives.gentoo.org; Tue, 01 Nov 2005 08:39:51 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.5/8.13.5) with SMTP id jA18cNJ4030421; Tue, 1 Nov 2005 08:38:23 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 jA18cM7k017353 for ; Tue, 1 Nov 2005 08:38:23 GMT Received: from list by ciao.gmane.org with local (Exim 4.43) id 1EWrdY-0007FJ-JO for gentoo-amd64@lists.gentoo.org; Tue, 01 Nov 2005 09:36:56 +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 09:36:56 +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 09:36:56 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-amd64@lists.gentoo.org From: Duncan <1i5t5.duncan@cox.net> Subject: [gentoo-amd64] Re: libungif and giflib conflict. Date: Tue, 01 Nov 2005 01:36:23 -0700 Organization: Sometimes Message-ID: References: <3ab1ed150510312136j4ea70304g81186f14c5cab492@mail.gmail.com> <20051101055203.GA19589@crud.crud.mn.org> <20051101060037.GA30285@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: 87abfd49-5302-446a-8497-2084862b8394 X-Archives-Hash: 9705a6e67e4f7b590789d5d358e3a8ad Brian Litzinger posted <20051101060037.GA30285@localhost>, excerpted below, on Mon, 31 Oct 2005 22:00:37 -0800: >> Nick Currier writes: >> > I have to run libungif as all my media is built around mplayer and it >> > simply won't run on the giflib libraries. > > On Mon, Oct 31, 2005 at 11:52:03PM -0600, Barry.SCHWARTZ@chemoelectric.org > wrote: >> My mplayer is linked with giflib and AFAIK it works as it should. I >> suspect you need to run revdep-rebuild. Otherwise I would try installing >> libungif in /usr/local, the old-fashioned way, and put an entry in >> package.provided or something like that. > > I had cross dependecies between mplayer and another app. > > One required giflib the other libungif. > > After getting tired of emerging back and forth I did > > (unmerged the other lib) > > emerge giflib > cd /usr/lib > ln -s libgif.so.4.1.3 libungif.so.4 That works, but it's an unneeded hack. Here's the history behind libgif/libungif. Unisys apparently had a patent on the compression method normally used in gif. They let gif format graphics become rather a standard, and then started demanding royalties for the compression patent. Of course, royalties aren't something very compatible with open source, so that didn't work too well. There were two responses among both the open source community and the web community (which used both gif and jpeg). One was to develop an uncompromised standard, the PING graphic standard, and switch to using it on most web pages and the like. (This was complicated by the fact that MSIE didn't properly support PING for a long time.) The other, as we have here, was to work with a library that used the same standard but without the compression. Apparently, it was possible to read compressed gifs without violating the patent, but it wasn't possible to create or do graphics work in the format, at least not and compress it. Thus, libungif was born, using the workaround to decompress gifs, but when used to work with gifs, it would store them uncompressed. The patents apparently expired between 2001 and late 2003, depending on the location, so gifs can now use the normal compression without issue, and there's little use for libungif any longer. According to a discussion some weeks/months ago on gentoo-dev, Gentoo is deprecating libungif, and will eventually remove it from the tree. Apparently, new versions of everything that could depend on either is now set to depend on libgif only. After a suitable length of time, or when it becomes difficult to support libungif any longer (I don't believe there's anything being done with it upstream any longer), it will be removed from the tree. So... no new ebuilds should depend on libungif. If they do, it's a bug and probably should be filed as such. Meanwhile, existing ebuilds, particularly as currently merged, may still depend on libungif. However, most of them should work just fine if rebuilt against libgif. Unmerge libungif (and remove that symlink you created) so there's no libungif on the system. Then ensure you have a current libgif merged and do a revdep-rebuild -p to see what is detected as needing remerged. Then go ahead and do the remerge of those packages, either by running the command without the -p, or by emerging the individual packages by name. Nothing should need to pull in libungif. It's still possible that some old stable packages might want it. However, sticking those in package.keyword with ~amd64 should result in a newer package that merges fine without libungif. If it's still required, then it's time to file a bug (check first, of course, to see if there's already been one filed on it). -- 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