[Kolab-devel] Upgrade report 3.1 to 3.2 on Debian Wheezy

[Paul Boddie]

On Thursday 13. March 2014 23.37.25 Daniel Hoffend wrote:
> >
> >Is there a Web-viewable summary of these fixes?
> 
> It's a combination of resources.
> * bugzilla reports (maybe with patches)
> * stuff that actually gets applied to git.kolab.org
> * reports of users on the mailling list and on irc
> * check which packages got applied already to the obs package definition
> 
> I think there are still a couple bugs that have already been fixed on
> git but havn't made their way into the package (for example the empty
> amavisd.conf bug for rpm systems).
> 
> I can just describe what I did to get hotfixes applied to the official
> packages. Maybe this will help others to understand how things are
> rolling and maybe someone is willing to participate as well.

I have to admit that although I check the Bugzilla instance, I don't do it 
that often even when I do have time to look at Kolab. Occasionally, though, I 
do browse randomly for stuff that looks familiar.

> Example 1)
> Debian packages didn't called the script to update the roundcube
> database:
> 
> I looked into OBS and compared the RPM script with the DEBIAN script.
> Once I realized that the commands were missing in the debian postinst
> script, I forked the package on OBS, updated the script and a few other
> files (versionnr, changelog, etc) (Timotheos has a good guide on
> planet.kolab.org about it) and submitted to changes with the request to
> get it merged back into kolab:development and kolab:3.2.

I've submitted only a few things to OBS. Generally, I find it cumbersome and 
the way the packaging files are maintained is unhelpfully opaque. I'm not 
really complaining, though, but just indicating why I'm not motivated to go 
and update stuff there. Also, since a lot of the stuff I've done has been on 
my own fork of the actual pykolab code, there's been little point in changing 
the packages in OBS.

> Example 2)
> The outdated mysql initial file
> 
> I was testing a clean installation while I figured out that the mysql
> initial file was outdated compared to the upgrade files. I opened a bug
> report on bugzilla with the request to get the the intial file updated
> on git.
> Once the file was fixed on git, I forked the package on OBS and added
> the .patch files (taken from git), updated changelog and submitted the
> package back to the kolab team.
> 
> This is basically the way how hotfixes are making their way into the
> official kolab packages once they get accepted. Of course once the kolab
> team decides to ship a new upstream version of the package they'll have
> to remove the patches which should be included in the new version
> (hopefully).

Generally, I've maintained the Debian patches as strictly packaging patches 
instead of integrating them into a fork of the upstream source, with the 
exception being pykolab. The MySQL stuff is, however, an example of where my 
packaging interests probably collide with the original intent: generally, you 
won't configure MySQL from scratch when installing Debian packages. But I've 
not removed support for that in pykolab/setup-kolab, and I've reworked a lot 
of this code, anyway.

> I know that this might not be the way how you like to maintain and
> create debian packages (since you wrote a guide on creating deb packages
> with pbuilder, but it's the way the kolab team decided to go with and
> how they can provide packages for multiple architecture at once from a
> single repository. When you apply a hotfix into OBS, the fix will can
> get applied to the RPM and DEB version at the same time.

I accept that getting stuff upstream is the right thing to do, but I've also 
been hoping that there might still be more momentum behind making official 
Debian packages just like there used to be. It's at that point that I hesitate 
in using OBS to make such packages because it isn't actually needed to do so - 
such things could be done elsewhere and would eventually need to be done 
elsewhere to be "proper" Debian packages - and because it doesn't seem to be 
producing current-policy-compliant packages.

I accept that a convenient way of making packages for many distributions is 
what matters to the Kolab team, and maybe it'll stay this way indefinitely 
unless there's more visible interest in getting packages sponsored and 
incorporated into Debian proper, although I really hope it doesn't end up like 
this. If Kolab were to get into Debian as a supported set of packages, the 
burden of making packages (and for many architectures, ARM fans!) would 
hopefully be taken on by the Debian infrastructure. I think that would only 
really leave the publishing and propagation of hotfixes as an issue to be 
resolved.

Paul