[Kolab-devel] [pkg-kolab] Bug#730600: Bug#730600: libkolab(xml): New upstream version available
Jeroen van Meeuwen (Kolab Systems)
vanmeeuwen at kolabsys.com
Fri Jul 4 02:35:50 CEST 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
libcalendaring.
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 devel
mailing list