Yvan Seth's Hole in the Internet

There are a lot more "Debian", aka Ubuntu, users around the place these days. In general it seems many newer users have been spoilt by Ubuntu's regular release schedule. Back in the old days we sometimes waited years between Debian releases, if there was something you needed that wasn't in your antique but "stable" Debian you'd have to use backports, if you were lucky enough to find what you wanted there, backport a package for yourself (thanks to the Debian package build tools being mostly friendly), or just compile from source.

Perhaps self-backporting has become an anachrnism? Still, I find myself doing it from time to time. Right now I want spatialite because I'm playing with GeoDjango and don't want to mess with PostgreSQL or MySQL – I'm just fiddling. In general on the 'net you find people are just grabbing precompiled binary tarballs or, shudder, the game are self-compiling and doing a make install … won't somebody think about the package management system!

Still another approach is to just upgrade to "testing" (or is it "unstable" - I think "stable" Ubuntu is closer to what we might have called "testing" Debian back in the day.) But the koala isn't fully baked yet, so why risk that? Backporting the karmic package is safer, and probably quicker. (Yes, yes, I know there's only 10 more days of baking to go.)

Here's a recipe to help avoid unbaked koalas:

sudo -s
# Put the Karmic 'universe' deb-src line into your sources
echo "deb-src http://gb.archive.ubuntu.com/ubuntu/ karmic universe" > \
    /etc/apt/sources.list.d/karmic-universe.list
# Install a few pre-requsites 
# you may find you need more than this
# but you'll definitely need at least the following
apt-get install autotools-dev debhelper doxygen dpatch dpkg-dev fakeroot \
    libgeos-dev libsqlite3-dev quilt ruby ruby-dev sharutils swig
exit

# Get, compile, and install a newer libgeos
apt-get source libgeos-dev
cd geos-3.1.0
dpkg-buildpackage -rfakeroot
cd ..
sudo dpkg -i libgeos-3.1.0_3.1.0-1_i386.deb \
    libgeos-dev_3.1.0-1_i386.deb libgeos-c1_3.1.0-1_i386.deb

# Get, compile, and install libproj
apt-get source libproj-dev
cd proj-4.6.1
dpkg-buildpackage -rfakeroot
cd ..
sudo dpkg -i libproj0_4.6.1-5_i386.deb \
    libproj-dev_4.6.1-5_i386.deb  proj-data_4.6.1-5_i386.deb

# Get, compile, and install spatialite - see a pattern emerging?
apt-get source spatialite
cd spatialite-2.3.0
dpkg-buildpackage -rfakeroot
cd ..
sudo dpkg -i libspatialite2_2.3.0-1_i386.deb  spatialite-bin_2.3.0-1_i386.deb

The advantage of this approach is that your additional bleeding edge software is installed "properly". The package management system is aware of it, and when the koala is baked and you upgrade you'll be certain to get any important updates.

Of course, the sequence above makes it look like plain sailing. The reality of the process is that you start by adding the deb-src line, then you get the spatialite source, then you try to build it. The build fails with a long list of the packages it needs as build dependencies. You install each of the build dependencies as required, grabbing some from the "unstable" source repository when needed (as for libgeos and libproj above.) In this case it all came from universe, so my restrictive deb-src line was fine, but usually you'll find you need things from "main" or even "multiverse" as well. Be warned, if you start needing to upgrade things like your libc it is time to stop and either venture the dist-upgrade or resort to make install (or try hacking the Debian package source to lower a dependency version;)

This post is a little tongue-in-cheek in some ways. I wouldn't expect people, developers especially, to stick with "stable" religiously - nothing ventured nothing gained! But I decided to pollute the 'net with these thoughts after coming across some young developers who had never seen the apt-get source command, let alone built a Debian package (die-hard Ubuntu fans who're young enough that Ubuntu was the first "Debian" they installed.) No, don't risk the koala I shouted! It is not the right way! (Then I hobbled back up to my hermit hole while the young fellows pitied the poor old crazy man.)

I do think backporting is usually a better approach than risking a premature system upgrade though. That said, we live in a pretty bleeding-edge world these days. I myself use most of my direct dependencies from SVN trunks, stuff releases - they're old and dusty, and a lot of these newfangled frameworks/technologies/whathaveyou even recommend this.

Also, I'd be dishonest if I didn't mention that sometimes when trying to backport something from proper Debian/Ubuntu package sources you can end up chasing your tail for ages. Quickly leading to frustration, and giving up, followed by either a make install or a dist-upgrade … ah, technology.

For the interested, after doing the above the rest of the process to get my Django sqlite database primed for geospatial data was simply:

wget http://www.gaia-gis.it/spatialite/init_spatialite-2.3.sql.gz
gunzip init_spatialite-2.3.sql.gz
spatialite mydatabase.db  < init_spatialite-2.3.sql
./manage.py syncdb

Oh, you want the fancy Open Street Maps editor widget too do you?

apt-get source libogdi3.2
sudo apt-get install python-gdal gdal-bin libgdal1-1.5.0 libogdi3.2
cd ogdi-dfsg-3.2.0~beta2
dpkg-buildpackage -rfakeroot
cd ..
sudo dpkg -i libogdi3.2_3.2.0~beta2-4_i386.deb ogdi-bin_3.2.0~beta2-4_i386.deb
sudo apt-get install python-gdal
./manage.py shell
Python 2.6.2 (release26-maint, Apr 19 2009, 01:56:41) 
[GCC 4.3.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
(InteractiveConsole)
>>> from django.contrib.gis.gdal import SpatialReference
>>> from django.contrib.gis.utils import add_postgis_srs
>>> add_postgis_srs(SpatialReference(900913))
>>> from django.contrib.gis import gdal
>>> gdal.HAS_GDAL
True

w00t!