Thanks guys. Really appreciate the help. Will try ~amd64 for mplayer. NIck Currier On 11/1/05, Duncan <1i5t5.duncan@cox.net> wrote: > > 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 > >