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

Paul Boddie paul at boddie.org.uk
Fri Dec 20 12:14:14 CET 2013

On Friday 20. December 2013 10.56.38 Hans de Raad wrote:
> These improvements sound really interesting and promising!
> Especially the "check setup" function is also very usefull for update
> scenarios.

The "check setup" function is quite simple at the moment - it just checks 
something fairly obvious to see if setup-kolab has been there before (file 
contents, the presence of databases) - but the sky is the limit with regard to 
actually checking the configuration status.

> Please be advised that in the openSUSE community quite a lot of work has
> been done as well in the preparation of kolab setup (kolab-pre-setup),
> perhaps this could also be of service to other distro's:
> https://build.opensuse.org/package/show/server:Kolab:UNSTABLE/kolab-scripts

Yes, I saw this before, but I then started to wonder about the apparently 
separate kolab-setup script that was being mentioned and where this was (or 
whether it is just another name for setup-kolab). There are some things in 
these scripts which are very useful additions, but other things are probably 
superfluous in Debian in some ways, particularly if the appropriate packages 
are already configured (MySQL coming to mind again).

> Or some functionality could be integrated in setup-kolab in a later
> stage, personally i will be looking at this scenario end of q1 next
> year, this ofcourse if real-life/time permits. However i think some work
> from the openSUSE community (especially by Aeneas Jaissle) has already
> been done towards this goal.

Yes, I believe some work has been done, and my attention was drawn to a 
previous discussion about this. Amongst my changes to pykolab is more or less 
what Jeroen argued for in response to Aeneas' proposal of distribution-
specific functionality: there is a services module which determines which 
programs are being used to configure and manipulate services on the system, 
and which considers different naming conventions depending on the "flavour" of 

I think that the eventual solution may well end up with distribution-specific 
catalogues of things like package names - it may be too awkward to try and 
deduce things like what the ClamAV service is called on every distribution out 
there - but I've initially expanded on the existing work in pykolab to try and 
cover Debian (and Ubuntu) and Red Hat (and Fedora) naming.

> Best regards and happy holidays!

And the same to you! :-)


P.S. With the needless incompatibilities between distributions, one is tempted 
to think that the "architects" responsible didn't experience things like the 
proliferation of BASIC dialects back in the 1980s or other situations where 
avoidable differences between systems mostly created more work for the sake of 

More information about the devel mailing list