1 |
R. Müller posted <438D5EFF.4080201@××××××××××××××.de>, excerpted below, |
2 |
on Wed, 30 Nov 2005 09:12:47 +0100: |
3 |
|
4 |
> Hallo group, |
5 |
> |
6 |
> the current kdegraphics-package (3.4.3) seems to make use of the libungif. |
7 |
> since i unmerged libungif (blocking issue) , merged libgif instead and |
8 |
> putting libungif to package.provided, i thought everything's |
9 |
> fine. |
10 |
> |
11 |
> But so i putted these links to /usr/lib and hope that works ... |
12 |
> |
13 |
> ln -s libgif.so.4.1.3 libungif.so.4 |
14 |
> ln -s libgif.la libungif.la |
15 |
> |
16 |
> What is offical way to solve this issue ? |
17 |
|
18 |
Well, actually, 3.4.3 is a bit old, tho it's probably the newest stable. |
19 |
KDE 3.5.0 release finally came out just today, and I have it fully merged |
20 |
and am (partially) running it now. (Partially, because I merged it on top |
21 |
of the -rc I was running, and I haven't shut down KDE and X all the way |
22 |
and restarted them, so the base stuff is still the rc, but any newly |
23 |
started KDE apps are of course the newly merged version.) So, 3.5 would |
24 |
be "current", but that doesn't really answer your question, does it? |
25 |
|
26 |
There's a bit of history behind libgif and libungif. The root of the |
27 |
problem was a Unisys patent it claimed over the compression algorithm gif |
28 |
used. libgif used the patented compression, libungif didn't use it. They |
29 |
were apparently designed to be more or less interchangeable other than |
30 |
that. |
31 |
|
32 |
The patent expired in 2003 (IIRC, some regions had a later patent that |
33 |
didn't expire until 2004, but anyway, they're all expired now), so there's |
34 |
little reason to have both libraries remaining. libungif has therefore |
35 |
been deprecated and will eventually be fully removed, having served its |
36 |
useful purpose. |
37 |
|
38 |
That's the history. What it means for real deployed Gentoo systems is |
39 |
that some packages, merged before the deprecation, will still be looking |
40 |
for libungif even after it has been unmerged due to blocking, as you see. |
41 |
|
42 |
The root solution is to remerge any packages dependant on the now unmerged |
43 |
library, so they can get their dependencies straightened out. However, |
44 |
keeping track of all such things manually is a rather daunting task, so |
45 |
there's a tool that can help with the process -- revdep-rebuild, part of |
46 |
the gentoolkit package. |
47 |
|
48 |
So, if you don't already have it on your system, merge gentoolkit, then |
49 |
run revdep-rebuild FIRST WITH THE -p OPTION to see what it thinks it needs |
50 |
to rebuild. If you haven't been running it regularly, it might spit out |
51 |
quite a list. |
52 |
|
53 |
Once you have the list, you can either manually remerge each item on the |
54 |
list (my usual method), or run the command again without the -p, and let |
55 |
it do its thing. |
56 |
|
57 |
You can also use the --library <library> option to revdep-rebuild, to |
58 |
scan for and rebuild just the packages dependant on a specific library, |
59 |
libungif, in this case. However, personally, I never use this option, |
60 |
because it's best to keep everything updated. It's there, tho, if you |
61 |
want to use it. Of course, you can also simply remerge individual |
62 |
packages as you come across them, and not worry about revdep-rebuild. |
63 |
|
64 |
Of course, in this particular case, the link method should work as well, |
65 |
because the libraries are basically compatible. It won't always work, |
66 |
however, if the replacement library had a different interface, which must |
67 |
be directly compiled into all the apps that use it. |
68 |
|
69 |
Finally, you have the option of upgrading to a newer version of KDE, if |
70 |
desired. It appears the 3.5 version is ~amd64 now. The information on |
71 |
stable vs. ~arch, and how to upgrade to ~arch for specific packages only, |
72 |
is in the Gentoo handbook, if this suits you. Otherwise, wait a month or |
73 |
so for those of us that like running testing packages to test things |
74 |
out, and if there aren't any issues, it should go stable at that point. |
75 |
|
76 |
-- |
77 |
Duncan - List replies preferred. No HTML msgs. |
78 |
"Every nonfree program has a lord, a master -- |
79 |
and if you use the program, he is your master." Richard Stallman in |
80 |
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html |
81 |
|
82 |
|
83 |
-- |
84 |
gentoo-amd64@g.o mailing list |