Technical Ramblings

I took the last week of the year off from work, and I spent most of the time doing a push to get some of the software that I help develop into Debian.

Debian is a Linux distribution that is built and maintained almost entirely by volunteers: it is the basis of the very popular Ubuntu operating system used on desktops, and is also used heavily for both desktops and servers at MetaCarta. Getting a package into Debian’s main repository is an indication that it meets the projects (relatively stringent) guidelines for inclusion into the repository.

The first package that I did this for was TileCache. TileCache is a relatively simple to install utility, but it has significant benefits from being installed directly on the system — such as the ability to place the configuration file into the main configuration files locations, etc. In addition, TileCache is a relatively widely used piece of software — meaning it could have benefits for a number of users.

New packages are typically packaged by a user, then a ‘sponsor’ is searched for. A sponsor is a Debian Developer — someone with the rights to upload packages to Debian — who will take on the review of the packaging materials to ensure that the meet Debian’s guidelines.

Thanks to a thorough and patient review by Paul Wise, from the DebianGIS list, TileCache was able to be put into Debian in less than a week’s time, and is now available to users of Debian “Sid”/unstable. Barring any problems with TileCache showing up, in 10 days, TileCache will be migrated to “Lenny”/testing. Additionally, I believe that this means that TileCache may be included in the next Ubuntu release. (I’m not sure on that — I don’t know the exact way that Ubuntu pulls its packages in.) You can see information on the TileCache package on the TileCache Debian package info page.

As a result of this, I’ve also packed the python-memcache library, maintained by tummy.com, ltd, which will make it easier for TileCache users to use the Memcached cache class.

All in all, my initial experiences with Debian have been very positive, and I’m looking forward to continuing to work on building more of the software I build into Debian packages for wider distribution. Indeed, cleaning up things for Debian has resulted in a lot of other improvements to the code as well: meeting guidelines for documentation, packaging, etc. has resulted in adding documentation that didn’t otherwise exist, and cleaning up what did exist.

You can track some of what I’m now maintaining or working to get into Debian via my maintainer page, as well.

I just spent 30 minutes or so trying to understand the Python Packaging Policy for Debian. I’m no more informed than I was an hour ago, and my head hurts a lot more. :/

This isn’t helped by the fact that I want to support etch++ (because that’s what most people use) and sarge (because that’s what I’m working on at work). Sigh. Packaging is hard.

For most of the stuff I package, I just dump things in someplace in /usr/lib/, but now I need to figure out how to get my python code into the right place in /usr/lib/pythonX.Y/site-packages … but my modules support any version of Python that debian ships! So where do they go? I have no clue. Do I need to build multiple binary packages — one for each version of Python — for my single source pacakge? I have a feeling that something is supposed to take care of this for me, but I don’t know if it’s dh_pycentral, dh_python, or dh_pythonsupport or what have you, and I don’t know how to get any of them to kick in. Augh.

Oh well. Packaging this one will just have to wait a bit longer.