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

[Paul Boddie]

On Saturday 21. December 2013 08.32.47 Richard wrote:
> Paul, Hans,
> 
> Op vrijdag 20 december 2013 12:14:14 schreef Paul Boddie:
> > 
> > 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).
> 
> The latter, just type kolab<tab><tab> and find all the goodies avaiable for
> kolab, in this case including kolab-setup.  kolab-setup = setup-kolab

I'm not sure this tab-completion trick will work on Debian with the packages 
we have today. ;-)

> > 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).
> 
> It's plugin driven.  If a check is not needed, do not distribute it or
> disable the check:
> 
> kolab-scripts> cat pre-setup.conf
> # Disable checks that are stored in /usr/share/kolab/pre-setup.d/
> # The checks are enabled by default and can (only) be disabled by assigning
> # the value "disable" to the check's filename (with hyphens (-) replaced by
> # underscores and the .sh suffix removed).
> #
> # Example for check (filename): kolab-check-update-pkgs.sh
> # kolab_run_update_pkgs=disable
> 
> Include in kolab-pre.conf
> check_sql_database=disable
> 
> and the mysql database will be disabled.
> 
> If another another check is desired, just drop it in the directory
> /usr/share/kolab/pre-setup.d, determine the order it has to be executed
> with KPS_CHECK_ORDER and that's it (KPS: Kolab Pre Setup).

So the aim of kolab-pre-setup is to make sure that setup-kolab won't do any 
inappropriate things to the configuration of certain components and that it 
will have required packages and components installed, but that it still 
requires setup-kolab to do its work?

Looking at check-cyrus-rpm.sh, for example, I see that the script checks the 
origin of the Cyrus package and offers to get the right one. On Debian, the 
aim here would be to make this happen within the existing packaging metadata, 
although I admit that this could be awkward - I don't know what the exact 
situation with the different Cyrus variants is, myself, but I know it was 
mentioned recently on this list - but merging any forked packages with the 
"proper" ones (or having a cleaner way of adding Kolab customisations to them) 
would be an essential part of getting Kolab into Debian, which should be the 
goal.

I think this pre-setup stuff is very useful as a way of documenting the 
installation requirements of Kolab, but I still think that setup-kolab should 
be able to deal with some of the common installation issues. Moving 
distribution-specific things out of setup-kolab may well be necessary, and 
eliminating setup-kolab may eventually happen if it turns out that it doesn't 
really do anything any more, but I worry about work that is common to all 
distributions being duplicated and the risk that some distributions don't keep 
up and no longer do the necessary setup work as the upstream code changes.

My feeling is that making setup-kolab do the right thing by changing its code 
directly is probably better than adding external code to encourage it to do 
the right thing. But there will obviously be a need to make sure that setup-
kolab isn't going to try and configure things that aren't installed, and my 
approach (which perhaps approximates to this pre-setup stuff) is to leverage 
the packaging system and to call setup-kolab to configure specific components 
(not everything at once) to achieve this goal.

Perhaps what we need to do is to catalogue the requirements for a usable Kolab 
installation - done largely by the pre-setup work already, I suppose - and 
determine what each distribution needs to do to satisfy those requirements. It 
may well be the case that many of them are satisfied during the normal process 
of installing Kolab's dependencies on some systems, but actually confirming 
this might be useful.

Paul