<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">

<html><head>

    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">

    <meta name="generator" content="Osso Notes">

    <title></title></head>

<body>

<p>----- Oorspronkelijk bericht -----

<br>> On Monday, April 22, 2013 01:18:48 PM Paul Klos wrote:

<br>> > All,

<br>> > 

<br>> > Libkolab version 0.4.2. has now been packaged for Debian. However, as

<br>> > long as it depends on libcalendaring, there is no chance it will find

<br>> > its way into Debian.

<br>> > 

<br>> > The only way this is going to happen is if libkolab only depends on

<br>> > kdepimlibs, which will mean pulling in the kde stuff on the server as

<br>> > well.

<br>> > 

<br>> > We thought about creating 2 versions of libkolab, but that's not going

<br>> > to work either. For example, someone using KDE would not be able to

<br>> > test-install a kolab server on his workstation, because he'd end up

<br>> > with 2 conflicting versions of libkolab. Also, 'the possibility of

<br>> > loading two symbols of the same name into the same process is a no-go'

<br>> > - one of the milder quotes from my IRC talk :-).

<br>> > 

<br>> > Is there any objection to letting go of the whole libcalendaring idea,

<br>> > and just bite the bullet and pull in kdepimlibs and the rest on a

<br>> > Kolab server install?

<br>> > 

<br>> > Paul

<br>> 

<br>> If we have kde-4.10, and their libs we don't need libcalendaring?

<br>> 

<br>> I get: 

<br>> $ urpmq --whatrequires lib64calendaring-devel

<br>> lib64calendaring-devel

<br>> libkolab-devel

<br>> 

<br>> -- 

<br>> Best regards

<br>> Thomas Spuhler

<br>

<br>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.

<br>

<br>Paul</p>

</body>

</html>