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