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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.