Re: libkolab

On Monday, April 22, 2013 02:11:01 PM Paul Klos wrote:
> ----- Oorspronkelijk bericht -----
> 
> > On Monday, April 22, 2013 01:18:48 PM Paul Klos wrote:
> > > All,
> > > 
> > > Libkolab version 0.4.2. has now been packaged for Debian. However, as
> > > long as it depends on libcalendaring, there is no chance it will find
> > > its way into Debian.
> > > 
> > > The only way this is going to happen is if libkolab only depends on
> > > kdepimlibs, which will mean pulling in the kde stuff on the server as
> > > well.
> > > 
> > > We thought about creating 2 versions of libkolab, but that's not going
> > > to work either. For example, someone using KDE would not be able to
> > > test-install a kolab server on his workstation, because he'd end up
> > > with 2 conflicting versions of libkolab. Also, 'the possibility of
> > > loading two symbols of the same name into the same process is a no-go'
> > > - one of the milder quotes from my IRC talk :-).
> > > 
> > > 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?
> > > 
> > > Paul
> > 
> > If we have kde-4.10, and their libs we don't need libcalendaring?
> > 
> > I get:
> > $ urpmq --whatrequires lib64calendaring-devel
> > lib64calendaring-devel
> > libkolab-devel
> 
> Correct. Actually kdepimlibs5-dev from kde 4.8.4 is already enough to build
> libkolab without libcalendaring. Of course this will pull in kdelibs5-dev
> and qtlibs-dev as build-dependenies.
> 
> Paul
Thanks. I may make this change, although we are already at RC 1
-- 
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)

iEYEABECAAYFAlF10zMACgkQjsMgV2ARTmNV1QCdFNvHuQye/KrEGcg05ILaHYGh
rioAnRnKINZBDqSSCDJVuKlCuJAVnP0J
=8xNG
-----END PGP SIGNATURE-----