[gentoo-amd64] Re: libungif again kdegraphics 3.4.3

[Duncan]

R. Müller posted <438D5EFF.4080201@××××××××××××××.de>, excerpted below, 
on Wed, 30 Nov 2005 09:12:47 +0100:

> Hallo group,
>
> the current kdegraphics-package (3.4.3) seems to make use of the libungif.
> since i unmerged libungif (blocking issue) , merged libgif instead and
> putting libungif to package.provided, i thought everything's
>   fine.
>
> But so i putted these links to /usr/lib and hope that works ...
>
> ln -s libgif.so.4.1.3 libungif.so.4
> ln -s libgif.la libungif.la
>
> What is offical way to solve this issue ?

Well, actually, 3.4.3 is a bit old, tho it's probably the newest stable.
KDE 3.5.0 release finally came out just today, and I have it fully merged
and am (partially) running it now.  (Partially, because I merged it on top
of the -rc I was running, and I haven't shut down KDE and X all the way
and restarted them, so the base stuff is still the rc, but any newly
started KDE apps are of course the newly merged version.)  So, 3.5 would
be "current", but that doesn't really answer your question, does it?

There's a bit of history behind libgif and libungif.  The root of the
problem was a Unisys patent it claimed over the compression algorithm gif
used.  libgif used the patented compression, libungif didn't use it.  They
were apparently designed to be more or less interchangeable other than
that.

The patent expired in 2003 (IIRC, some regions had a later patent that
didn't expire until 2004, but anyway, they're all expired now), so there's
little reason to have both libraries remaining.  libungif has therefore
been deprecated and will eventually be fully removed, having served its
useful purpose.

That's the history.  What it means for real deployed Gentoo systems is
that some packages, merged before the deprecation, will still be looking
for libungif even after it has been unmerged due to blocking, as you see.

The root solution is to remerge any packages dependant on the now unmerged
library, so they can get their dependencies straightened out.  However,
keeping track of all such things manually is a rather daunting task, so
there's a tool that can help with the process -- revdep-rebuild, part of
the gentoolkit package.

So, if you don't already have it on your system, merge gentoolkit, then
run revdep-rebuild FIRST WITH THE -p OPTION to see what it thinks it needs
to rebuild.  If you haven't been running it regularly, it might spit out
quite a list.

Once you have the list, you can either manually remerge each item on the
list (my usual method), or run the command again without the -p, and let
it do its thing.

You can also use the --library <library> option to revdep-rebuild, to
scan for and rebuild just the packages dependant on a specific library,
libungif, in this case.  However, personally, I never use this option,
because it's best to keep everything updated.  It's there, tho, if you
want to use it.  Of course, you can also simply remerge individual
packages as you come across them, and not worry about revdep-rebuild.

Of course, in this particular case, the link method should work as well,
because the libraries are basically compatible.  It won't always work,
however, if the replacement library had a different interface, which must
be directly compiled into all the apps that use it.

Finally, you have the option of upgrading to a newer version of KDE, if
desired.  It appears the 3.5 version is ~amd64 now.  The information on
stable vs. ~arch, and how to upgrade to ~arch for specific packages only,
is in the Gentoo handbook, if this suits you.  Otherwise, wait a month or
so for those of us that like running testing packages to test things
out, and if there aren't any issues, it should go stable at that point.

-- 
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@g.o mailing list