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 <docfreezzzz@gmail.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@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