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

[Paul Boddie]

(Replying to all, even though I think it's probably excessively cross-posted.)

On Thursday 26. June 2014 21.14.57 Mike Gabriel wrote:
> Hi Sandro,
> 
> On  Do 26 Jun 2014 15:36:27 CEST, Sandro Knauß wrote:
> > Hi,
> > 
> >> So, is libcalendaring actually a REAL fork? Or is it a partial extract
> >> of the kdepimlibs that should better be maintained inside kdepimlibs?
> > 
> > well actually it is code copy from kdepimlibs and strip out many
> > dependencies. We only update it, when we need new featuers or wanna remove
> > bugs. But we have no code that lives in libcalendering only.

My impression from what I was told on IRC - maybe by one of you :-) - was that 
libcalendaring was a dirty hack involving a lot of copy-paste from kdepimlibs, 
but if it really can be built from the same sources and if people will 
entertain that in kdepimlibs, I can't see this being any worse than some of 
the other things you see in Debian involving different kinds of builds and 
dependency trees of package variants. (Don't ask me for examples, though: I 
don't have any conveniently to hand, although I vaguely remember things to do 
with libvorbis and integer-only builds.)

> > The concept is, that everthing goes upstream ( kdepimlibs) and than we
> > port back the parts we need into libcalendering. We want to get rid of
> > libcalendering, if kdepim will be ported to frameworks. But this will take
> > at least one or two years till this will happen for kdepim [0].
> 
> So if this an intermediary malheur, we should get libcalendaring into
> Debian until this is fixed properly upstream. Important to my
> supportive disposition on this is, that someone from upstream is
> actively working on a server-side usable kdepimlibs. If that is the
> case I can reason with other DDs if the issue of code duplication
> comes up. For now, I consider libcalendaring as a maintained and
> minimalized fork of kdepimlibs that is a requirement for getting the
> server-side part of Kolab (and also the webmailers) into Debian.
> 
> My Kolab2 server is getting old, so let's get this thing rocked for
> Debian jessie!!!

It's nice to see such enthusiasm. :-) I have to say that if the alternative is 
an indefinite stand-off then it starts to look more attractive to strip away 
the KDE-originating dependencies altogether, but that means more work that 
shouldn't really need doing. (I did think about it anyway recently, though, 
when I was fighting with testing pykolab.xml, noticing the broken python-
kolab, and seeing that there's a sizeable "thunk" when starting up the 
libkolab stuff in Python.)

> >> 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)?
> > 
> > The build/cmake option is available and is called
> > -DUSE_LIBCALENDARING=TRUE
> > 
> > Both can be installed at the same machine. the libs from caledering are
> > called:
> > calendaring-kcalcore
> > calendering-*
> > [...]
> > see cmake/modules/FindLibcalendaring.cmake
> 
> Great!

It's amazing what can happen with a bit of conversation. I did try and look 
into building libkolab outside pbuilder, but there's an apparent lack of 
documentation, and the kolab.org documentation (once I'd searched for it) 
didn't make it easily manageable.

> As a member of Kolab Systems and a Debian Maintainer (IIRC I saw your
> application and approval(?)), I guess it would be appropriate that you
> file the ITP and provide the packaging of libcalendaring. I will
> sponsor the upload and support the ITP if needed in upcoming
> discussions.
> 
> Will that work for you?

May I encourage this course of action? It would allow us to move on to more 
productive things.

Paul