Re: libkolab

On Tuesday, April 23, 2013 05:30:57 AM Paul Klos wrote:
> 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 had both as a build requires, so I guess, it took randomly one of the lib files.
(I will not delete libcalendaring as a BuildRequires and make it obsolete on the Distro

BTW, I get this error with and w/o the libcalendaring  installed:
/libkolab/BUILD/libkolab-0.4.2/calendaring/event.h:0: Note: No relevant 
classes found. No output generated.
/home/spuhler/MageiaSVN/kolab-3.0/libkolab/BUILD/libkolab-0.4.2/calendaring/event.h:0: 
Note: No relevant classes found. No output generated.


> 
> 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
> 
> _______________________________________________
> Kolab-devel mailing list
> [email protected]
> https://www.intevation.de/mailman/listinfo/kolab-devel

-- 
Best regards
Thomas Spuhler

_______________________________________________
Kolab-devel mailing list
[email protected]
https://www.intevation.de/mailman/listinfo/kolab-devel

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEABECAAYFAlF2vagACgkQjsMgV2ARTmOjOwCfcg0QtsGI+vGJmttI4d7/FWRg
8OEAn2ZGPHaDNu+5P9P6RS913LCRCfWQ
=GSP9
-----END PGP SIGNATURE-----