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

[Bernhard Reiter]

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.
>
> This is correct in my understanding.

How hard do those packages depend on kdepimlibs?

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

Those are the Debian KDE SC 4.3.4 packages as far as I  have understood. 

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

To me it looks like it is the other way around. KDE 4.3+ code using the old 
config files. Migration was done once what afterwards e35 code wrote new 
config files.

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

Yes, which means I have to make sure that only one code generation accesses 
the configuration files at a time.

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

Are there other drawbacks except double configuration?
E.g. can the new Kopete still access the contacts from the old Kontact?

Thanks,
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/236393aa/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/