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

[Sune Vuorela]

On Wednesday 02 July 2014 13:36:52 Sandro Knauß wrote:
> Hey,
> 
> I have some comments/questions:
> > 1) libcalendaring-* doesn't have a single symbol in common with kdepimlibs
> > *and* 
> why is that needed? all libs are named differently, have a different version
> and the headers will lay in /usr/include/calendaring/  ->I don't see the
> point, why compile two times one with kdepimlibs and the other one with
> libcalendering is not enough?

To ensure that if something ends up loading libcalendaring into the kontact 
process that everything still works.


> > 2) there are two versions of libkolab(-xml) that doesn't conflict and
> that should be easy solvable with different install destinations.

All libs in Debian go to a shared install directory, /usr/lib (or 
/usr/lib/TRIPLET ), so different destinations are not good enough. That also 
implies different SONAME's for the libraries.

> > 3) these versions of libkolab(-xml) doesn't share symbols.
> 
> Well actually, if the both versions have different symbols, than all
> applications has be updated to have the support for libcalendering.

What applications would have to use it interchangeable ? I'd expect the kolab 
server people to just use the libcalendaring versions, while the kontact users 
would use the kdepimlibs versions.  

> Why it should blow up, if there are two libs lying around with same symbols?
> The linking is done against a library and not against the symbols. Or do

I want to ensure that neither of us gets to debug weird crashes if both 
libraries are loaded into the same application.

/Sune