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

[Ingo Klöcker]

On Friday 23 April 2010, Bernhard Reiter wrote:
> 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.

Denying the user the usage of a modern Kopete somehow doesn't fit with 
Free Software principles IMHO. Separating the config directories is the 
only solution that allows the user the execution of the rights 
guaranteed by the GPL.


Regards,
Ingo
-------------- 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/20100425/8d27d1fc/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/