[Kolab-devel] Reworking pykolab, setup-kolab and packaging

Paul Boddie paul at boddie.org.uk
Wed Dec 18 19:12:00 CET 2013


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

The setup-kolab command now avoids doing configuration work if it is able to. 
This means that it tests for databases, database users and modified 
configuration settings and avoids asking for input if it believes that the 
work has already been done.

The setup-kolab command now also supports a --check (or -C) option that 
reports its view of the work that needs doing. If it reports "setup done" for 
everything, the configuration of the system should be a working one; if it 
reports "needs setup", the components affected need to be configured. I also 
changed setup-kolab to show the component listing if invoked without arguments 
as I didn't realise that it even had such a help message until I discovered 
that there was a "help" component by looking at the code.

Some "reset" options are added to setup-kolab to support explicit 
reconfiguration for certain components, updating configuration files so that 
they contain valid credentials, for example.

In order to integrate setup-kolab with Debian packaging, I've added some 
debconf support so that setup-kolab can be run in a postinst script and show 
debconf dialogues - only in situations where interactions with the user are 
necessary - and this requires some modifications to the dependency tree, 
particularly around the role of the kolab-conf package which has to be 
available for the various dependent packages to be configured (as they now use 
setup-kolab, of course). I'll follow up with the Debian-specific mailing list 
for Kolab packaging: there are probably some things I've done in a suboptimal 
fashion.

Some more things probably need doing such as maintaining man pages for the 
different commands. I see that reference documentation has been generated for 
Sphinx somehow, so perhaps there's a toolchain being used that also might feed 
into man page generation, particularly if restructured text is being used 
(since I've already come across tools that make acceptable man pages from 
reST).

I've written this work up from a Debian packaging perspective here:

http://blogs.fsfe.org/pboddie/?p=623

Once again, I hope this is of interest to people, and I'll post the location 
of my modifications to pykolab and to the packaging in the near future.

Paul


More information about the devel mailing list