[pkg-kolab] Bug#730600: [Kolab-devel] Bug#730600: Bug#730600: libkolab(xml): New upstream version available
sune at debian.org
Wed Jul 2 12:09:10 UTC 2014
On Wednesday 02 July 2014 13:36:52 Sandro Knauß wrote:
> 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.
More information about the pkg-kolab-devel