[Kolab-devel] Debian packages, upstream source patching and quilt

[Paul Boddie]

Hello,

I finally managed to get pbuilder to build the Development packages for Debian 
Wheezy using various tricks with hooks and a build dependencies directory that 
I will write up in a blog post that should then appear on Planet Kolab. (This 
can save a lot of time: pbuilder isn't quick itself, but OBS can take up to 9 
minutes on my system to just set up the build environment for a single 
package.) The packages also appeared to install cleanly, and I didn't need to 
use aptitude to navigate a multitude of packaging choices - apt-get was good 
enough - so things certainly seem to be going my way.

I've previously referred to problems with cmake, but these did not occur this 
time round, although since the build environment was Wheezy and not Sid 
there's a chance that something still needs fixing, but I suppose we'll deal 
with that in the future. I didn't bother with the 389 packages just out of 
curiosity as to whether the stock Debian packages would be sufficient, and it 
looks as if they are, at least to install Kolab.

When doing the building I found two packages that seemed to need additional 
packages installed before pbuilder would even get started:

python-icalendar needed python-setuptools, but since I dislike setuptools 
intensely and won't risk it breaking my system (and since I wasn't building 
inside another chroot), I made a patch to replace its use with distutils 
because what setuptools attempts to do when employed most ambitiously isn't 
really attempted here (and generally isn't relevant in a package building 
situation anyway). In other situations I have tended to patch setup.py files 
to remove setuptools dependencies where the upstream developers could have 
easily used good old distutils, and I don't see any significant problems doing 
so here.

php-http-request2 needs pkg-php-tools, and I just accepted that because I 
don't run any PHP stuff myself. I imagine that the Debian build system is 
clever enough to have this as some kind of "pre-build" dependency.

(I noticed that in OBS, the build dependencies are maintained in two places - 
the control file and the .dsc file - so removing python-setuptools as a build 
dependency needed to be done in two places, whereas the .dsc would be updated 
to reflect the control file in a pbuilder-based workflow.)

Doing patches on upstream sources led me to consider how they are delivered. I 
noticed that there were quite a few packages where I got complaints about how 
the patches should be managed using quilt. I don't know whether this is fully 
supported in OBS, but quilt patches typically reside in debian/patches and so 
could be bundled in the debian.tar.gz file that sits in each OBS package 
directory. When building python-icalendar with a modified debian.tar.gz 
containing patches, OBS seemed to apply such patches, but amongst the 
resulting output files there doesn't seem to be a special "debian" patch 
archive like this...

python-icalendar_3.4-1.debian.tar.gz

...but only a file like this:

python-icalendar_3.4-1.diff.gz

I'm sure a lot of the above doesn't really matter, but I know that some people 
prefer recent best practices to be observed, so I thought I should investigate 
whether they can indeed be followed. If it doesn't cause inconvenience, I can 
add quilt patch series to the following packages to make Debian happy:

irony, kolab-freebusy, libkolab, libkolabxml, mozilla-ldap-sdk, roundcubemail, 
roundcubemail-plugin-threadingasdefault

Paul