[Kolab-devel] [pkg-kolab] Bug#730600: Bug#730600: libkolab(xml): New upstream version available

[Mike Gabriel]

Hi Sandro, hi all,

... getting kolab-devel (upstream) into the discussion... Maybe some  
of you guys can provide some answers / feedback to the below questions  
/ plan...

On  Do 26 Jun 2014 12:22:06 CEST, Sandro Knauß wrote:

> Hi,
>
>> Last time I tried libkolab(xml) (I have the rouncube-plugins-kolab
>> pending for upload here, I tried that 6 months back), I observed my
>> apache2 server starting up the complete KDE (kdelibs) stack as user
>> www-data (in /var/log/apache/error.log I saw all KDE-related messages
>> you normally get when you run STARTUP=startkde startx from a terminal).
>>
>> Did that get fixed with that new release if libkolab???
>
> the point is, that libkolab can be compiled  with two different libraries.
> Either kdepimlibs are used or libcalendering. For using libkolab for kontact
> kdepimlibs is the thing you want to use, 'cause you need it anyway :)
>
> For serverside it looks different. There you don't want to install  
> so many kde
> depenencies, that's why kolab starts shipping libcalendering [1]. This is a
> subset of kdepimlibs to be using only qt without kdelibs. But this
> libcalendering isn't available inside debian.
>
> So to make it short: Until now, if you install libkolab you'll  
> install kdelibs
> as dependeny too.
>
> Regads,
>
> sandro
>
> [1] http://git.kolab.org/libcalendaring/

yeah, now that I read your lines I remember this nasty code  
duplication named "libcalendaring".

So, is libcalendaring actually a REAL fork? Or is it a partial extract  
of the kdepimlibs that should better be maintained inside kdepimlibs?

If it has its own upstream development and that development is really  
split off of its origin, we should consider packaging it for Debian.

Without that, I don't see the Kolab Server coming into Debian at all  
at the moment.

As a prerequisite for packaging it for Debian, libcalendaring and  
kdepimlibs need to be installable on the same machine. The  
libkolab(xml) configure scripts should support build switches  
(--with-kdepimlibs, --with-libcalendaring). I haven't looked closer,  
so far. Is the parallel installability already given? Is there such a  
build option for libkolab(xml)?

If so, we could run the build process for the same sources twice, on  
first build: build against kdepimlibs. On second build: build against  
libcalendaring. The resulting builds should be shipped in two  
different bin:packages (libkolab-kdepimlibs, libkolab-calendaring, or  
libkolab-client, libkolab-server, or whatever seems most appropriate).

Mike




-- 

DAS-NETZWERKTEAM
mike gabriel, herweg 7, 24357 fleckeby
fon: +49 (1520) 1976 148

GnuPG Key ID 0x25771B31
mail: mike.gabriel at das-netzwerkteam.de, http://das-netzwerkteam.de

freeBusy:
https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xfb
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: Digitale PGP-Signatur
URL: <http://lists.kolab.org/pipermail/devel/attachments/20140626/b6cd9a0a/attachment.sig>