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 |