[Kde-pim] kdepim from 3.5 running within KDE SC 4.3

[Volker Krause]

On Thursday 22 April 2010 17:00:13 Bernhard Reiter wrote:
> KDEPIM is in a transition period from my point of view:
> From e35 to e5 and while that transition is not done,
> we mustsupport KDEPIM from KDE SC 3.5 running on SC 4.x.
> Let me explain:
>
> Intevation and KDAB have a number of customers that really need a stable
> Kontact client for email and groupware functions. I would say: All larger
> organisations would need that stability if they are going to use KDEPIM in
> a business environment.
> Currently only a Kontact from KDE SC 3.5 can provide this.
> Our companies and the Kolab Community even maintain
> an enterprise3.5 branch of Kontact - short "e35". [1]
>
> On the other hand, a lot of distributions are on the point of shipping a
> current KDE SC 4. I've encountered 4.3 twice in GNU distributions that are
> going to be out there for a while, I guess at least a year.
>
> KDE SC 4 is nice, but the KDEPIM coming with it is not really there yet,
> because is it based on a Qt4 port of the old architecture without akonadi
> and only some parts have been ported to akonadi now. Even when all is
> ported, which should be there soon - it will take a few rounds to stabilise
> everything up to a point where it compares in the same leaque as e35. The
> stable new Kontact goes under the name Enterprise5 and it is
> becoming beta quality somewhat this year. My hope even is to have it being
> quite stable at the end of the year.
>
> But until the, we need to run e35 on KDE SC 4.
> We have been checking into Ubuntu and UCS all Debian based a bit for this
> so far. One problem is that the kdepimlibs are build in a way that packages
> like  plasma-dataengines-workspace, plasma-runners-addons, kopete,
> kgpg and  python-kde4 depend on it.

This is correct in my understanding.

> Kopete and kpgp could be downgraded if they are still required.
> (Though I believe kpgp should be phased out completely as Kleopatra can
> replace it and it uses the old deprecated Gnupg interface, which means you
> must have an old version of gnup1 around for it to work.)
>
> If the following packages are installed, not surprisingly the contacts
> resource gets deleted from .kde/share/config/kresources/contact/stdrc

What probably happens here is the migration of the old KResource configuration 
to Akonadi. IIRC this was still disabled in the 4.3 release though and should 
only happen from KDE 4.4 onwards. Again, this is the correct and expected 
behaviour.

> ii  kdepimlibs-dat 4:4.3.4-1.1.20 core shared data for KDE PIM 4
> applications ii  kdepimlibs5    4:4.3.4-1.1.20 core libraries for KDE PIM 4
> applications
>
> Of course it seems like the new kdepimlibs want to access the configuration
> and have no "imap" resource (because that is called kimap with
> kaddressbook, if I remember correctly.) See part of the kdebug output below
> at [2].

What you are doing here, if I understand correctly, is using KDE 4.3+ config 
files with KDE 3.5 code. This is not supported by KDE. Configuration files 
are migrated forward on upgrades, but are not guranteed to be backward 
compatible. So, accessing them with older versions will result in undefined 
behaviour.

> Trying dpkg --purge --force-depends kdepimlibs5 kdepimlibs-data works,
> but what is the real solution?
>
> Can a new kopete speak with the kabc infos? Or are we forced on the old
> kopete to have the full functionality? I darkly remember that somebody
> wanted to start a discussion about this, does any of you have a pointer?
> I guess this will have to be examined for the other packages depending on
> kdepimlibs5 as well.

The problem is not Kopete or any of the other apps mentioned here, there is 
nothing in there that you could change to make this work. The problem is 
using a new kdepimlibs anywhere, since that will trigger the config file 
format update. And besides not installing kdepimlibs (which is pretty much 
impossible), the only way around this I see is separating the config files 
entirely, as already suggested in this thread. 

That's also what I use here to run a e35 Kontact on my KDE 4.4 desktop. Of 
course the downside of this is that you have to configure your PIM stuff 
twice, for KDE3 and KDE4.

regards
Volker
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20100423/11f5bfe0/attachment.sig>
-------------- next part --------------
_______________________________________________
KDE PIM mailing list kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/