Thanks guys. Really appreciate the help. Will try ~amd64 for mplayer.<br>
NIck Currier<br><br><div><span class="gmail_quote">On 11/1/05, <b class="gmail_sendername">Duncan</b> <<a href="mailto:1i5t5.duncan@...">1i5t5.duncan@...</a>> 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 <20051101060037.GA30285@localhost
>, excerpted<br>below, on Mon, 31 Oct 2005 22:00:37 -0800:<br><br>>> Nick Currier <<a href="mailto:docfreezzzz@...">docfreezzzz@...</a>> writes:
<br>>> > I have to run libungif as all my media is built around mplayer and it<br>>> > simply won't run on the giflib libraries.<br>><br>> On Mon, Oct 31, 2005 at 11:52:03PM -0600, <a href="mailto:Barry.SCHWARTZ@...">
Barry.SCHWARTZ@...</a><br>> wrote:<br>>> My mplayer is linked with giflib and AFAIK it works as it should. I<br>>> suspect you need to run revdep-rebuild. Otherwise I would try installing<br>>> libungif in /usr/local, the old-fashioned way, and put an entry in
<br>>> package.provided or something like that.<br>><br>> I had cross dependecies between mplayer and another app.<br>><br>> One required giflib the other libungif.<br>><br>> After getting tired of emerging back and forth I did
<br>><br>> (unmerged the other lib)<br>><br>> emerge giflib<br>> cd /usr/lib<br>> ln -s libgif.so.4.1.3 libungif.so.4<br><br>That works, but it's an unneeded hack.<br><br>Here's the history behind libgif/libungif. Unisys apparently had a patent
<br>on the compression method normally used in gif. They let gif format<br>graphics become rather a standard, and then started demanding royalties<br>for the compression patent. Of course, royalties aren't something very
<br>compatible with open source, so that didn't work too well.<br><br>There were two responses among both the open source community and the web<br>community (which used both gif and jpeg). One was to develop an<br>uncompromised standard, the PING graphic standard, and switch to using it
<br>on most web pages and the like. (This was complicated by the fact that<br>MSIE didn't properly support PING for a long time.)<br><br>The other, as we have here, was to work with a library that used the same<br>standard but without the compression. Apparently, it was possible to read
<br>compressed gifs without violating the patent, but it wasn't possible to<br>create or do graphics work in the format, at least not and compress it.<br>Thus, libungif was born, using the workaround to decompress gifs, but when
<br>used to work with gifs, it would store them uncompressed.<br><br>The patents apparently expired between 2001 and late 2003, depending on<br>the location, so gifs can now use the normal compression without issue,<br>and there's little use for libungif any longer.
<br><br>According to a discussion some weeks/months ago on gentoo-dev, Gentoo is<br>deprecating libungif, and will eventually remove it from the tree.<br>Apparently, new versions of everything that could depend on either is now
<br>set to depend on libgif only. After a suitable length of time, or when<br>it becomes difficult to support libungif any longer (I don't believe<br>there's anything being done with it upstream any longer), it will be<br>
removed from the tree.<br><br>So... no new ebuilds should depend on libungif. If they do, it's a bug<br>and probably should be filed as such.<br><br>Meanwhile, existing ebuilds, particularly as currently merged, may still
<br>depend on libungif. However, most of them should work just fine if<br>rebuilt against libgif. Unmerge libungif (and remove that symlink you<br>created) so there's no libungif on the system. Then ensure you have a<br>
current libgif merged and do a revdep-rebuild -p to see what is detected<br>as needing remerged. Then go ahead and do the remerge of those packages,<br>either by running the command without the -p, or by emerging the<br>individual packages by name.
<br><br>Nothing should need to pull in libungif. It's still possible that some<br>old stable packages might want it. However, sticking those in<br>package.keyword with ~amd64 should result in a newer package that merges
<br>fine without libungif. If it's still required, then it's time to file a<br>bug (check first, of course, to see if there's already been one filed on<br>it).<br><br>--<br>Duncan - List replies preferred. No HTML msgs.
<br>"Every nonfree program has a lord, a master --<br>and if you use the program, he is your master." 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:email@example.com">firstname.lastname@example.org</a> mailing list<br><br></blockquote></div><br>