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

Bernhard Reiter bernhard at intevation.de
Thu Apr 22 16:00:13 BST 2010


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.


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

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

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.

Best,
Bernhard

[1] Most of you will know about e35 already. We needed extra stability and more flexibility in regard to the standard 
KDEPIM 3.5 line and we are still fixing defects and adding important business functions to e35 and thus KDEPIM 
for KDE SC 3.5 as this is what some customers really want and pay for.

[2]
kdeinit4: preparing to launch /usr/lib/libkdeinit4_kconf_update.so
klauncher(22767)/kio (KLauncher) KLauncher::processRequestReturn: "kconf_update"
 (pid 22840) up and running.
krunner(22795)/kdepimlibs (kabc) KABC::StdAddressBook::self: asynchronous= true
krunner(22795)/kresources KRES::Factory::self:
[..]
krunner(22795)/kresources KRES::Factory::Private::resourceInternal: ( "imap" , config )
krunner(22795)/kresources KRES::Factory::Private::resourceInternal: no such type "imap"
krunner(22795)/kresources KRES::Factory::Private::resourceInternal: no such type "imap"
krunner(22795)/kresources KRES::ManagerImpl::readResourceConfig: Failed to create resource with 
id "pYoqdTkyur"
krunner(22795)/kdepimlibs (kabc) KABC::StdAddressBook::StdAddressBook:
krunner(22795)/kdepimlibs (kabc) KABC::StdAddressBook::self: calling init after instance creation
krunner(22795)/kresources KRES::Resource::open: Opening resource "Default Address Book"
krunner(22795)/kresources KRES::ManagerImpl::writeConfig:
krunner(22795)/kresources KRES::ManagerImpl::writeResourceConfig: Saving resource "iI8Vo0qCaa"
krunner(22795)/kresources KRES::Resource::writeConfig:

 

-- 
Managing Director - Owner: www.intevation.net       (Free Software Company)
Deputy Coordinator Germany: fsfe.org. Board member: www.kolabsys.com.
Intevation GmbH, Osnabrück, DE; Amtsgericht Osnabrück, HRB 18998
Geschäftsführer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20100422/4ea115bb/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/


More information about the kde-pim mailing list