[Kolab-devel] Reworking pykolab, setup-kolab and packaging
paul at boddie.org.uk
Thu Dec 19 23:39:23 CET 2013
On Thursday 19. December 2013 22.14.21 Paul Klos wrote:
> Hi Paul,
Hello Paul! ;-)
> Op woensdag 18 december 2013 19:12:00 schreef Paul Boddie:
> > Hello,
> > I've been pressing on with looking at the work done by setup-kolab and
> > trying to make it play nice with Debian packaging. Just to make sure
> > that this work doesn't get lost or forgotten, I'll be making it
> > available for people to download and adapt. Here are some of the
> > highlights...
> Great work, I've been doing the same type of work, albeit not on pykolab.
> We sould coordinate, I suppose :-).
Indeed. Note that some of the work done on pykolab has general benefits and
isn't specific to setup-kolab, but most of it is admittedly setup-kolab-
> This is very much of interest.
> Let me share some items from my side. There's an initiative to get the
> Kolab debian packages into debian. My ultimate goal would be a 2-step
> 1. install debian
> 2. apt-get install kolab
Yes, this would be the nice and easy way to get Kolab without worrying about
the details. However, I think it would also be nice to "add Kolab" to an
existing configuration for those already using some of the components, which
might also involve the second command, but it would not assume or demand a
And I think that Kolab shouldn't automatically include Roundcube, even though
for convenience it might get pulled in for a complete solution. Similarly, I
think the free/busy solution could also be optional (and I think is optional
according to the current dependency graph).
> I think ultimately upgrades and manual configuration changes/additions
> should be handled by dpkg, debconf, ucf and all other debian goodies. I
> don't really see a place for a tool like setup_kolab in a debian setup
> done right. The key phrase here is "done right", obviously. This is a
> *serious* amount of work.
Yes, setup-kolab is a general solution, and that could make it conflict in
certain ways with a Debian-centric approach. Since I didn't want to reproduce
everything done by setup-kolab (although I did consider it initially), I
thought it best to work with it rather than against it, and I think there is
scope for continuing that approach for the time being.
Certainly, using setup-kolab is not really substantially different from using
various programs provided to configure other software. I would mention
a2ensite as an example but that's obviously a Debian-specific Apache
configuration program, but one could envisage other programs that do the
necessary work of configuring some software that need not be reimplemented for
For instance, I found it interesting that nice MySQL administration programs
are somewhat thin on the ground compared to PostgreSQL, and I suppose that
PostgreSQL is a prime example of a system where various generic commands are
available on pretty much any kind of system and need not be reimplemented. I
do know that there are also Debian-specific convenience scripts for
PostgreSQL, however, but the deciding factor is whether any given general
script or program does the right thing already or not. If it does, there's no
point in writing another one, which again makes me surprised about the MySQL
script situation on Debian, but anyway.
But I do agree about considering any diverging needs that Debian has. If the
use of the common kolab.conf file isn't too pervasive, I could understand
having a conf.d layout for Kolab, and that might be a motivation for doing
something special for Debian, for example.
> There's a pkg-kolab project on alioth:
> We're hosting a couple of git repositories for packaging already, to be
> precise: - libkolabxml (1.0 packaging done)
> - libkolab (0.5 packaging done)
> - roundcube-plugins-kolab (work in progress)
> - pykolab (copied from kolab systems apt repo, but I'm considering just
> starting over with the most recent upstream version)
> Unfortunately, these are not publicly accessible yet, but a support request
> to fix this is pending (something to do with access rights).
> Anybody who wants to help can register an alioth account and request
> membership of the pkg-kolab group. That will give you commit access.
I'm already on the pkg-kolab mailing list, but I imagine I didn't see the
repositories for the reasons you give. I'll certainly consider pushing stuff
> There are some challenges, for example:
> - Debian roundcube is at 0.9.5. This is the reason I'm packaging kolab 3.0
> plugins. This is a lot of work as it is, because the roundcube structure
> on debian is quite different. On the plus side, debian roundcube already
> comes with database configuration for mysql and postgresql, so that's one
> thing setup_kolab isn't needed for anymore right there.
Won't the Roundcube database need updating with the Kolab plugins, though?
Certainly, the actual initialisation of MySQL and the Roundcube database will
be superfluous - the former already is on a normal Debian system - and I've
tried to make setup-kolab skip such unnecessary things gracefully now. (Of
course, there are benefits in having such behaviour on other distributions,
> - We'll need to
> make kolab work with the official cyrus-imapd package. I know there have
> been threads about this in the past, but we'll need to look into that. -
> At the very least, packages will have to be lintian-clean, something that
> hasn't had a particularly high priority while kolab systems was hosting
> the repository. - Integrating the work that has been done on OBS, so we
> don't reintroduce all kinds of bugs
Package quality is something I've had to work towards before, so I'm quite
prepared to jump through all the hoops to catch up with the packaging
standards of the day. I can imagine a few things - man pages, as I noted
before, some reviewing of the metadata, even exotic stuff like multiarch -
that will need looking at before we're done. Given that you're on top of the
libkolab* packaging, I'm hoping multiarch will be a solved problem before I
have to consider it. ;-)
> And I'm sure there are more to come. But I'd really like to see Kolab
> become a first-class citizen on Debian, and this is where I'm directing my
> efforts at the moment.
I guess we should probably continue elements of this discussion on the pkg-
kolab list: it would be good to get feedback from more experienced Debian
packagers on the way the configuration work interacts with the packaging
scripts in my proposed (and implemented in the uploaded archives) dependency
More information about the devel