Re: libkolab
Paul Klos <[email protected]>
| Newsgroups | gmane.comp.kde.devel.kolab,gmane.comp.kde.kolab.devel |
|---|---|
| Message-ID | <1366665061.2345.5.camel@Nokia-N900> |
----- 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 > > -- > Best regards > Thomas Spuhler 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 _______________________________________________ Kolab-devel mailing list [email protected] https://www.intevation.de/mailman/listinfo/kolab-devel