[Kolab-devel] libkolab

[Paul Klos]

Hi Torsten,

Torsten Grote schreef op 23-04-2013 10:17:
> On Monday 22 April 2013 22:18:48 Paul Klos wrote:
>> Is there any objection to letting go of the whole libcalendaring 
>> idea, and
>> just bite the bullet and pull in kdepimlibs and the rest on a Kolab 
>> server
>> install?

To clarify, I meant this only for Debian(-based) installations.

> If I remember correctly, the (temporary) creation of libcalendering 
> was
> intentional and the pros and cons were deliberated upon. As far as I 
> know
> libcalendering was supposed to die as soon as KDE Frameworks is ready 
> (and
> shipped on all of Kolab's platforms) which I think it isn't.

We don't necessarily need to kill off libcalendaring for all platforms, 
if we decide not to use it on Debian. But you're right, if certain 
platforms would keep using libcalendaring, and others don't, there would 
be a divergence between Kolab platforms.

> Do you happen to know how other distributions that ship libkolab 
> handle this
> problem?

I can't check right now, but I have a libkolab(xml) on my Gentoo box 
and I would be very surprised if it depends on libcalendaring. Of 
course, this is a desktop scenario, where libkolab(xml) is used in 
conjunction with akonadi/kontact, so the KDE dependencies are there 
already in any case.

I don't know about other distros.

> Maybe it can be a solution to keep libcalendering in the up2date Kolab 
> repo
> and depend on kdepimlibs in the official Debian repo for now. It 
> probably will
> take a while before the entire Kolab server enters Debian upstream and 
> until
> that happens libkolab will be only used to provide Kolab client 
> support for
> Kontact which requires kdepimlibs anyway.

This would mean two separate packages built from the libkolab source 
package, both providing libkolab. This will cause a conflict if a 
Debian/Ubuntu KDE user decides to try out a Kolab server on his desktop 
machine, because that would pull in 2 different libkolabs.

Maybe this could be resolved by providing libkolab under 2 different 
names, but then you have 2 libraries providing the same set of symbols, 
which is another objection Sune had.

To summarize, even if we can separate between a Debian libkolab and 
Kolab-provided libkolab, there is no guarantee that that will never 
cause conflicts. Whereas if the Debian libkolab and Kolab-provided 
libkolab are one and the same, you can be sure there will be no 
conflicts.

And the reality is, that there will be no Debian libkolab, as long as 
libcalendaring is somehow involved.

Paul