<font face="tahoma,sans-serif"><br></font><br><div class="gmail_quote">2010/8/30 Duncan <span dir="ltr"><<a href="mailto:1i5t5.duncan@cox.net">1i5t5.duncan@cox.net</a>></span><br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">

Manuel Escudero posted on Mon, 30 Aug 2010 18:48:54 -0500 as excerpted:<br>
<div class="im"><br>
> I have installed Fedora 13 Goddard x86_64 in my machine and I've updated<br>
> to KDE 4.5, in order to run Skype I installed some 32 bit Qt libraries<br>
> and when I installed the new KDE desktop I had to remove them because<br>
> KDE 4.4 uses the "1:4.6" version of these libraries and KDE 4.5 the<br>
> "1:4.7"... Now I have KDE 4.5 and everything is fine but I can't run<br>
> lastest Skype because it needs the "1:4.6" Qt libraries, it doesn't work<br>
> with the new ones, but if I remove the new ones and I replace them with<br>
> the older ones, many apps seem to be "downgraded" or they just don't<br>
> work anymore... Does this mean we're not having Skype in any KDE Linux<br>
> distro of 64 bit with the new KDE 4.5 installed?<br>
> Many users need skype (in my case I'm running it in a Windows 7 VM) But<br>
> without it we can't offer a reliable service to the Linux User who uses<br>
> Skype...<br>
</div>Of course, skype's proprietary servant-ware.  They have no respect for<br>
your freedom and you're at their mercy, as here.  At least when kde<br>
dropped kde3, it was possible for someone to pick up the pieces and<br>
continue with it, and that's exactly what has happened (tho their success<br>
over a longer term remains to be seen).  With proprietaryware, you're<br>
simply left "up a creek without a paddle", as they say, totally at the<br>
mercy of the provider who has already demonstrated a lack of respect for<br>
the rights of their users, in terms of what the provider chooses to do<br>
support-wise and upgrade-wise.  This is just one more example (tho I<br>
expect they will eventually upgrade).<br>
Now I'm not going to pretend to be able to make the choice for someone<br>
else, as unlike some softwaire providers, I actually do respect the<br>
freedom of others (tho as it is said, their freedom ends where my nose<br>
begins... tho unfortunately, many don't see it that way).  However, it's a<br>
definite risk that people take, and they really should be aware of the<br>
implications of their choice when they make it.  Once they are, great, but<br>
too often people don't realize those implications, which is just... sad.<br>
If this post causes one person to think a bit before they make the choice,<br>
regardless of which choice they then make, it has done its job.<br>
All that said, for those who /do/ go prorietary for some of their<br>
At least for amd64 (aka x86_64), the problem shouldn't be too bad, because<br>
32-bit and 64-bit libraries can be kept in different locations and<br>
shouldn't interfere with each other.  If you're running 64-bit kde, then<br>
you're using 64-bit qt4 libraries.  They should be upgradeable without<br>
worrying about any 32-bit versions of the libraries you may have to keep<br>
around for compatibility with black-box software that hasn't upgraded yet,<br>
and that you have no practical way of fixing the upgrade issues with<br>
Now, whether the package manager is sufficiently advanced to properly<br>
track both the 32-bit and 64-bit versions separately, is an entirely<br>
different question.  I'm on Gentoo, and know our package managers have<br>
problems in that regard (tho I also know there's a documented solution,<br>
which I use to solve a different problem, as I have a separate 32-bit<br>
build-image chroot install on my main 64-bit machine, which I use to build<br>
the Gentoo image for my 32-bit-only netbook), but I had actually thought<br>
that Fedora was a leader in multi-lib compatibility, and am surprised<br>
you're having the issue, there.<br>
But as I mentioned, there is definitely a solution possible.  If your<br>
package manager can't handle it directly, one possible workaround is a 32-<br>
bit chroot install on the same machine.<br>
Actually, the same solution should work for 32-bit/32-bit as well.  Just<br>
because the main native install is 64-bit doesn't make it different in<br>
that regard.  A 32-bit system should be able to handle a separate chrooted<br>
install, with one upgraded and the other kept at early versions for<br>
compatibility reasons.<br>
Of course, that's a bit extreme.  A reasonable multilib solution will work<br>
in most cases.  I'm just pointing out that if it's not provided by your<br>
distributor, there are ways of taking the solution into your own hands,<br>
even if they are a lot more work at the individual system level (as<br>
opposed to the distribution level) than a multilib solution would be, for<br>
the same problem.<br>
Duncan - List replies preferred.   No HTML msgs.<br>
"Every nonfree program has a lord, a master --<br>
and if you use the program, he is your master."  Richard Stallman<br>
This message is from the kde mailing list.<br>
Account management:  <a href="https://mail.kde.org/mailman/listinfo/kde" target="_blank">https://mail.kde.org/mailman/listinfo/kde</a>.<br>
Archives: <a href="http://lists.kde.org/" target="_blank">http://lists.kde.org/</a>.<br>
More info: <a href="http://www.kde.org/faq.html" target="_blank">http://www.kde.org/faq.html</a>.<br>
</blockquote></div><br>I've got the solution, thanks!! Now Skype is working and I have the 
lastest 32 Bit Qt libraries installed in my 64 bit Fedora 13 with KDE 
4.5!! :D<br clear="all"><br>-- <br><-Manuel Escudero-><br>Linux User #509052<br>@GWave: <a href="mailto:jmlevick@googlewave.com">jmlevick@googlewave.com</a><br>@Blogger: <a href="http://www.blogxenode.tk/">http://www.blogxenode.tk/</a> (Xenode Systems Blog)<br>

PGP/GnuPG: DAE3 82E9 D68E 7AE4 ED31  1F8F 4AF4 D00C 50E7 ABC6<br><br>