Gentoo Archives: gentoo-amd64

From: Duncan <1i5t5.duncan@×××.net>
To: gentoo-amd64@l.g.o
Subject: [gentoo-amd64] Re: libungif and giflib conflict.
Date: Tue, 01 Nov 2005 08:39:51
Message-Id: pan.2005.11.01.08.36.22.985763@cox.net
In Reply to: Re: [gentoo-amd64] libungif and giflib conflict. by Brian Litzinger
1 Brian Litzinger posted <20051101060037.GA30285@localhost>, excerpted
2 below, on Mon, 31 Oct 2005 22:00:37 -0800:
3
4 >> Nick Currier <docfreezzzz@×××××.com> writes:
5 >> > I have to run libungif as all my media is built around mplayer and it
6 >> > simply won't run on the giflib libraries.
7 >
8 > On Mon, Oct 31, 2005 at 11:52:03PM -0600, Barry.SCHWARTZ@×××××××××××××.org
9 > wrote:
10 >> My mplayer is linked with giflib and AFAIK it works as it should. I
11 >> suspect you need to run revdep-rebuild. Otherwise I would try installing
12 >> libungif in /usr/local, the old-fashioned way, and put an entry in
13 >> package.provided or something like that.
14 >
15 > I had cross dependecies between mplayer and another app.
16 >
17 > One required giflib the other libungif.
18 >
19 > After getting tired of emerging back and forth I did
20 >
21 > (unmerged the other lib)
22 >
23 > emerge giflib
24 > cd /usr/lib
25 > ln -s libgif.so.4.1.3 libungif.so.4
26
27 That works, but it's an unneeded hack.
28
29 Here's the history behind libgif/libungif. Unisys apparently had a patent
30 on the compression method normally used in gif. They let gif format
31 graphics become rather a standard, and then started demanding royalties
32 for the compression patent. Of course, royalties aren't something very
33 compatible with open source, so that didn't work too well.
34
35 There were two responses among both the open source community and the web
36 community (which used both gif and jpeg). One was to develop an
37 uncompromised standard, the PING graphic standard, and switch to using it
38 on most web pages and the like. (This was complicated by the fact that
39 MSIE didn't properly support PING for a long time.)
40
41 The other, as we have here, was to work with a library that used the same
42 standard but without the compression. Apparently, it was possible to read
43 compressed gifs without violating the patent, but it wasn't possible to
44 create or do graphics work in the format, at least not and compress it.
45 Thus, libungif was born, using the workaround to decompress gifs, but when
46 used to work with gifs, it would store them uncompressed.
47
48 The patents apparently expired between 2001 and late 2003, depending on
49 the location, so gifs can now use the normal compression without issue,
50 and there's little use for libungif any longer.
51
52 According to a discussion some weeks/months ago on gentoo-dev, Gentoo is
53 deprecating libungif, and will eventually remove it from the tree.
54 Apparently, new versions of everything that could depend on either is now
55 set to depend on libgif only. After a suitable length of time, or when
56 it becomes difficult to support libungif any longer (I don't believe
57 there's anything being done with it upstream any longer), it will be
58 removed from the tree.
59
60 So... no new ebuilds should depend on libungif. If they do, it's a bug
61 and probably should be filed as such.
62
63 Meanwhile, existing ebuilds, particularly as currently merged, may still
64 depend on libungif. However, most of them should work just fine if
65 rebuilt against libgif. Unmerge libungif (and remove that symlink you
66 created) so there's no libungif on the system. Then ensure you have a
67 current libgif merged and do a revdep-rebuild -p to see what is detected
68 as needing remerged. Then go ahead and do the remerge of those packages,
69 either by running the command without the -p, or by emerging the
70 individual packages by name.
71
72 Nothing should need to pull in libungif. It's still possible that some
73 old stable packages might want it. However, sticking those in
74 package.keyword with ~amd64 should result in a newer package that merges
75 fine without libungif. If it's still required, then it's time to file a
76 bug (check first, of course, to see if there's already been one filed on
77 it).
78
79 --
80 Duncan - List replies preferred. No HTML msgs.
81 "Every nonfree program has a lord, a master --
82 and if you use the program, he is your master." Richard Stallman in
83 http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html
84
85
86 --
87 gentoo-amd64@g.o mailing list

Replies

Subject Author
Re: [gentoo-amd64] Re: libungif and giflib conflict. Nick Currier <docfreezzzz@×××××.com>
Re: [gentoo-amd64] Re: libungif and giflib conflict. Brian Litzinger <brian@××××××××××××.com>