KDE 4.5 libraries problem with Skype

[Duncan]

Manuel Escudero posted on Mon, 30 Aug 2010 18:48:54 -0500 as excerpted:

> I have installed Fedora 13 Goddard x86_64 in my machine and I've updated
> to KDE 4.5, in order to run Skype I installed some 32 bit Qt libraries
> and when I installed the new KDE desktop I had to remove them because
> KDE 4.4 uses the "1:4.6" version of these libraries and KDE 4.5 the
> "1:4.7"... Now I have KDE 4.5 and everything is fine but I can't run
> lastest Skype because it needs the "1:4.6" Qt libraries, it doesn't work
> with the new ones, but if I remove the new ones and I replace them with
> the older ones, many apps seem to be "downgraded" or they just don't
> work anymore... Does this mean we're not having Skype in any KDE Linux
> distro of 64 bit with the new KDE 4.5 installed?
> 
> Many users need skype (in my case I'm running it in a Windows 7 VM) But
> without it we can't offer a reliable service to the Linux User who uses
> Skype...

Of course, skype's proprietary servant-ware.  They have no respect for 
your freedom and you're at their mercy, as here.  At least when kde 
dropped kde3, it was possible for someone to pick up the pieces and 
continue with it, and that's exactly what has happened (tho their success 
over a longer term remains to be seen).  With proprietaryware, you're 
simply left "up a creek without a paddle", as they say, totally at the 
mercy of the provider who has already demonstrated a lack of respect for 
the rights of their users, in terms of what the provider chooses to do 
support-wise and upgrade-wise.  This is just one more example (tho I 
expect they will eventually upgrade).

Now I'm not going to pretend to be able to make the choice for someone 
else, as unlike some softwaire providers, I actually do respect the 
freedom of others (tho as it is said, their freedom ends where my nose 
begins... tho unfortunately, many don't see it that way).  However, it's a 
definite risk that people take, and they really should be aware of the 
implications of their choice when they make it.  Once they are, great, but 
too often people don't realize those implications, which is just... sad.  
If this post causes one person to think a bit before they make the choice, 
regardless of which choice they then make, it has done its job.

All that said, for those who /do/ go prorietary for some of their 
software...

At least for amd64 (aka x86_64), the problem shouldn't be too bad, because 
32-bit and 64-bit libraries can be kept in different locations and 
shouldn't interfere with each other.  If you're running 64-bit kde, then 
you're using 64-bit qt4 libraries.  They should be upgradeable without 
worrying about any 32-bit versions of the libraries you may have to keep 
around for compatibility with black-box software that hasn't upgraded yet, 
and that you have no practical way of fixing the upgrade issues with 
yourself.

Now, whether the package manager is sufficiently advanced to properly 
track both the 32-bit and 64-bit versions separately, is an entirely 
different question.  I'm on Gentoo, and know our package managers have 
problems in that regard (tho I also know there's a documented solution, 
which I use to solve a different problem, as I have a separate 32-bit 
build-image chroot install on my main 64-bit machine, which I use to build 
the Gentoo image for my 32-bit-only netbook), but I had actually thought 
that Fedora was a leader in multi-lib compatibility, and am surprised 
you're having the issue, there.

But as I mentioned, there is definitely a solution possible.  If your 
package manager can't handle it directly, one possible workaround is a 32-
bit chroot install on the same machine.

Actually, the same solution should work for 32-bit/32-bit as well.  Just 
because the main native install is 64-bit doesn't make it different in 
that regard.  A 32-bit system should be able to handle a separate chrooted 
install, with one upgraded and the other kept at early versions for 
compatibility reasons.

Of course, that's a bit extreme.  A reasonable multilib solution will work 
in most cases.  I'm just pointing out that if it's not provided by your 
distributor, there are ways of taking the solution into your own hands, 
even if they are a lot more work at the individual system level (as 
opposed to the distribution level) than a multilib solution would be, for 
the same problem.

-- 
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

___________________________________________________
This message is from the kde mailing list.
Account management:  https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.