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

[Bernhard Reiter]

Am Freitag, 23. April 2010 16:30:34 schrieb Volker Krause:
> On Friday 23 April 2010 12:35:22 Bernhard Reiter wrote:
> > Am Freitag, 23. April 2010 09:59:37 schrieb Volker Krause:
> > > > 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.

> > How hard do those packages depend on kdepimlibs?
>
> In order of appearance above the features affected are rss plasmoid,

Seems useful without Kontact, thought e35 comes with Akregator and people 
might want to see the same feeds in both.

> contact krunner search plugin, 
> addressbook integration in kopete,

Only useful if the contacts from Kontact can be accessed I assume.

> no idea  about kgpg, kdepimlibs python bindings. Possibly a few more.

The bindings for kdepimlibs could be separated from other kde4-python bindung.

> > Are there other drawbacks except double configuration?
> > E.g. can the new Kopete still access the contacts from the old Kontact?
>
> For vcf and ical files that should work, 

Sounds untested. :) Is there any locking going on if those two applications 
work on the very same .vcf file?

> for Kolab as well in theory, 
> although that would mean two local caches, so the data might not be in sync
> between KDE3 and KDE4 apps then.

Two local caches sound like a separate access not Kopete accessing the data 
via the KDE3 kdepim.

This looks to me like a viable solution for packaging is

1) Separate out the applications depending on kdepimlibs from  
plasma-dataengines-workspace and plasma-runners-addons
to resolve the conflict and do not install the -with-kdepimlibs variants.
Also for the kde4-python bindings.
2) Install the old Kopete. And the old kpgp if you must (Kleo should surpass 
it hopefully soon.)
3) conflict kdaddressbook e35 package with kdepimlibs5

This means users would not have a modern Kopete and not all of the plasmoids,
but an old integrated Kopete. No need for separate .kde35 and .kde 
directories.

I believe this should be prefered over separated config directories, because 
separated config directories will not give the expected integrated experience 
for Kopete and Rss plasmoids either, but would be more work given the current 
Debian package structure. The plus of separated config directories would be 
that you could use a modern Kopete if you wanted to.

Best,
Bernhard
-- 
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/20100423/a3702dc8/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/