[pkg-kolab] Bug#730600: [Kolab-devel] Bug#730600: Bug#730600: libkolab(xml): New upstream version available

Jeroen van Meeuwen (Kolab Systems) vanmeeuwen at kolabsys.com
Fri Jul 4 00:35:50 UTC 2014

On 2014-07-02 21:14, Mike Gabriel wrote:
> On  Mi 02 Jul 2014 14:09:10 CEST, Sune Vuorela wrote:
>> I want to ensure that neither of us gets to debug weird crashes if 
>> both
>> libraries are loaded into the same application.
> @Sandro/Kolabsys: to me it feels as if Sune suggestions should be
> implemented in libcalendaring (first there) by upstream and not by
> some Debianic patch work. Do you see any chance that any coder at
> kolabsys could get those namespace changes into libcalendaring?

Please note that libcalendaring's original purpose had been to 
circumvent needing to provide a (near-)complete KDE stack >= 4.9 to 
older platforms such as RHEL 5, 6 and UCS (based on Squeeze).

As such, it has always been a very deliberate Frankenstein-baby and we 
have the intention to burn it at the earliest opportunity.

If the Debian version you are seeking to package this for has KDE >= 4.9 
(not unlikely, I reckon), then technically you should have no 
requirement for libcalendaring / to compile libkolab{,xml} against 

That said, libcalendaring is the "lighter weight" version of what 
libkolab needs from kdepimlibs. We are not experiencing the same 
problems with ld / symbols on RPM-based systems where the libcalendaring 
.so names are .0 and .0.1, while upstream's are .4 and .4.$x, and we're 
compiling libkolab{,-xml} against kdepimlibs.

Or am I not understanding the problem correctly?

Kind regards,

Jeroen van Meeuwen

Systems Architect, Kolab Systems AG

e: vanmeeuwen at kolabsys.com
m: +44 74 2516 3817
w: http://www.kolabsys.com

pgp: 9342 BF08

More information about the pkg-kolab-devel mailing list