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

[Paul Klos]

Hi 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 :-).

> 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

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 process:

1. install debian
2. apt-get install kolab

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.

There's a pkg-kolab project on alioth: https://alioth.debian.org/projects/pkg-kolab/.

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.

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

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.

Cheers,

Paul
 

PGP: 8FE6E0BD
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.kolab.org/pipermail/devel/attachments/20131219/695ff95e/attachment.sig>