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

[Paul Boddie]

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

[...]

> 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

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

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

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

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

> 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, 
too.)

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

Paul