Re: [gentoo-amd64] Re: libungif and giflib conflict.

[Nick Currier]

Thanks guys. Really appreciate the help. Will try ~amd64 for mplayer.

NIck Currier

On 11/1/05, Duncan <1i5t5.duncan@×××.net> wrote:
>
> Brian Litzinger posted <20051101060037.GA30285@localhost>, excerpted
> below, on Mon, 31 Oct 2005 22:00:37 -0800:
>
> >> Nick Currier <docfreezzzz@×××××.com> 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@×××××××××××××.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@g.o mailing list
>
>