Re: [Kolab-devel] [pkg-kolab] Bug#730600: Bug#730600: libkolab(xml): New upstream version available
Mike Gabriel <[email protected]>
| Newsgroups | gmane.comp.kde.devel.kolab |
|---|---|
| Organization | DAS-NETZWERKTEAM |
| Message-ID | <20140626120423.Horde.TDqitv5ysr8CY9w2y0c3eg5__28506.3608935618$1403784425$gmane$org@mail.das-netzwerkteam.de> |
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: [email protected], http://das-netzwerkteam.de freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xfb _______________________________________________ devel mailing list [email protected] https://lists.kolab.org/mailman/listinfo/devel
signature.asc
(application/pgp-signature, 819 B)
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAABAgAGBQJTrAxHAAoJEJr0azAldxsxARwP/3AmHxuLbbnl96Ql96oP732Y 12N96XN0n9LtmdEQKq0FdOYoCVuMS9A5VvLwveBnr0K8Q7G+RlCu97T7SK4aSFz+ xiY5C0d3mmyQ/HlujRnHJZAYhmuRvhUZMfM37ZaEBcMjo/Yru1RjN7Oji14HLBue N47UTMnGGn+2XtU7M5GiFkErr0u29BzPbdmj2QRizJj0BLzAgafwIWk32474joeP 2r/dYbRO4rffaWv+gLJFqhBoSKlcioZTmqukSRzYWXOV/xBmZ6i1CjekX1Uwkclh iLr+0ExG4nzgiNYWxzusTu1pQmXci9zrWoqEr5YnIswpgUr+zVdJefhOZoOHtAcp kdbEGjStVMOVcnRNO3vDl+04fWh7CLLUgMAkQJlgN8bbBQnJGImXlo2ajJXUuAa8 uANAp+gnXYgjJkaCXL+uuJVtKmSYrrajbmXUu7mDAplHexmkIOHrkAWZ9PwxUv2z U7+konGcEtNjrjwFLprAyYPuep1opYtOBS2A29/wfIMG0Wq7AITq/rYsZQaH9OlT /uabdFQX3yCpaAaysTE2rkck+rEEKzqBYrHhPpMS+j/K4A1ggBYpG0BYtAe7It0+ QwKdBW/lELBTkEslarwIM9sci1Co/URiA6HsStmh0DRM7pjm6vYPN4TV+aJEbGMC bGp3SFlAkPWBZIDmEx5P =EXzG -----END PGP SIGNATURE-----