Django on Debian Sarge

Note: This entry has been restored from old archives.

The main reason I’m posting this is so that other people can avoid trying to play “chase the dependency trail” in back-porting the Debian etch Django source package to sarge. If you want to do that I suggest working on modifications to the source package rather than following the trail.

[Note: If you want Django on Debian etch then you can simply: apt-get install python-django (not the latest and greatest though, 0.95.1 at this time, your best bet in all cases is probably a local user install from SVN)]

Here’s how I successfully installed Django as a Debian package, followed by the way I failed to do so.

Creating a Django Debian package (successfully)

After my trail following led me to a cliff I gave up on the 0.95.1 Debian source and moved on to this hackish method of getting a package. There are plenty of ways to get to packages on Debian. Let me scare you with this:

:; su -c 'apt-get install rpm alien'

(I’ll used Sam’s neat prompt to differentiate between commands and other crud.)


:; wget
:; tar xzf Django-0.96.tar.gz
:; cd Django-0.96
:; python bdist_rpm --packager="Yvan Seth" --vendor "django" 
            --release 1 --distribution-name Debian

However, the last step fails with “Illegal char '-' in version: Version: 0.96-None” so I edit build/bdist.linux-i686/rpm/SPECS/Django.spec and remove the -None from version (can’t see a way to do this with the bdist_rpm options):

:; vim build/bdist.linux-i686/rpm/SPECS/Django.spec
:; cp ../Django-0.96.tar.gz build/bdist.linux-i686/rpm/SOURCES/
:; rpmbuild -ba --define "_topdir 
        $HOME/source/Django-0.96/build/bdist.linux-i686/rpm" --clean 
:; fakeroot alien -k 

Joy! Now I have a django_0.96-1_all.deb, do I dare to install this critter?

:; su -c 'dpkg -i django_0.96-1_all.deb'
Selecting previously deselected package django.
(Reading database ... 41757 files and directories currently installed.)
Unpacking django (from django_0.96-1_all.deb) ...
Setting up django (0.96-1) ...

This sucks like a 747 engine (or blows, all a matter of perspective), but the deed is done. Probably better than “su -c 'python install'” but in the end it would probably have been best to just do a local --prefix=$HOME/blah type of install.

Setting it up

The Django site documents installation at

The Django documentation is rather good, once I was though with my packaging débâcle the doco got me up and running in next to no time. My notes here are specific to my system and probably not useful to anyone.


I’m already running both PostgreSQL and MySQL. I chose to use PostgreSQL because the sarge package for python-psycopg fits the specification given by the Django instructions while the python-mysqldb version is a little older than the specified minimum version. I’m also more familiar with postgres. So:

:; su -c 'apt-get install python-psycopg'

You’ll want to set up a database, so get an appropriately privileged psql shell and, for example, do:

CREATE DATABASE django_mysite;
CREATE USER django_mysite WITH PASSWORD 'dumbpassword';
GRANT ALL PRIVILEGES ON DATABASE django_mysite TO django_mysite;


The mod_python setup is documented here:

I have mod_python installed and it makes sense to use it. I’m using a pretty funky Apache vhost setup though and I’m not going to detail it here. In essence you want to find the appropriate VirtualHost section and insert something like this:

    <Location "/djangotest/">
        SetHandler python-program
        PythonHandler django.core.handlers.modpython
        SetEnv DJANGO_SETTINGS_MODULE mysite.settings
        PythonPath "['/home/vhost/'] + sys.path"
        PythonDebug On

With that done you should see a basic status page at the configured URL (i.e.

All Good!

Now to follow the great tutorial that starts here: I’m mildly impressed already, and web stuff usually pisses me off before I even touch it. We’ll see how it fares after I try and actually do something with it though.

How Not To Do It

Backporting python-django from Debian etch to sarge

This was a supposed to be a command log for a successfully back-ported Django package build. But it didn’t turn out so well.

We start with a Debian sarge server box. I really don’t want to risk dist-upgrading a box that’s in another country a 2 hour flight away. The box runs with some packages for the likes of Apache2, SpamAssassin, and ClamAV updates. Consider it a fully up to date general server with this sources.list file:

:; cat /etc/apt/sources.list
deb sarge main contrib non-free
deb sarge/updates main
deb sarge-backports main

What I want on this box is this cool new Django thing I’ve heard so much about, but rather than download and work with the tarball I’d prefer a Debian package (call it a form of OCD if you like). A fairly up-to-date package is available in current the currently stable etch and we can trust Debian to track this for security fixes, if I track this package manually we ought to be able to have a relatively safe install. So! Time to try and build the etch sources for sarge.

;: su
:; cat << END >> /etc/apt/source.list
deb-src etch main contrib non-free
deb-src etch/updates main
deb-src etch-backports main
:; apt-get update
:; exit

Create and install python-django?

:; mkdir -p pkgbuild
:; cd pkgbuild
:; apt-get source python-django
:; pushd python-django-0.95.1
:; fakeroot dpkg-buildpackage
dpkg-checkbuilddeps: Unmet build dependencies: debhelper (>=
    python-dev cdbs (>= 0.4.42) python-setuptools (>= 0.6b3-1)
    python-support (>= 0.3)

In a perfect world this would build your package! But things are rarely perfect. The dpkg-buildpackage reports any missing build dependencies, I had to install the parts that I could:

:; su -c 'apt-get install debhelper python-dev cdbs python-setuptools'
Setting up cdbs (0.4.28-1) ...
Setting up python2.3-dev (2.3.5-3sarge2) ...
Setting up python-dev (2.3.5-2) ...
Setting up python2.3-setuptools ( ...

Notice the versions aren’t really what I’m after, I’ll be punished for that later.

Create and install python-support?

Alas is isn’t as simple as that, another build dependency was python-support which wasn’t available for sarge, so…

:; popd
:; apt-get source python-support
:; pushd python-support-0.5.6
:; fakeroot dpkg-buildpackage
:; su -c 'dpkg -i ../python-support_0.5.6_all.deb'
 python-support conflicts with debhelper (<< 5.0.38)

Nope, no luck. Looks like the version of debhelper installed really needs an upgrade… I’ll prefer to trust the package maintainers and not try and force an older debhelper version on things.

Create and install debhelper?

:; popd
:; apt-get source debhelper
:; pushd debhelper-5.0.42
:; fakeroot dpkg-buildpackage
dpkg-checkbuilddeps: Unmet build dependencies: po4a (>= 0.24)
:; su -c 'apt-get install po4a'
Setting up po4a (0.20-2) ...
:; popd

Create and install po4a?

It is getting a bit over the top now… another route would be advisable at this point. While there’s got to be a better way I’m possessed of a zombie-like persistence so keep going…

:; apt-get source po4a
:; pushd po4a-0.29
:; fakeroot dpkg-buildpackage
:; # Joy! It builds!!
:; popd
:; su -c 'dpkg -i po4a_0.29-1_all.deb'
:; # Joyjoy! It installs!!!

Pass 2 of: create and install debhelper?

:; fakeroot dpkg-buildpackage
:; # Joy! It builds!!
:; popd
:; su -c 'dpkg -i debhelper_5.0.42_all.deb'
 debhelper depends on dpkg-dev (>= 1.13.13); however
  Version of dpkg-dev on system is 1.10.28.

Sigh. Is it really worth following this path any further?

Create and install dpkg-dev >= 1.13.13?

No, I really don’t want to do this. Time to stop! Additionally:

:; popd
:; apt-get source dpkg-dev
:; pushd dpkg-1.13.25
:; fakeroot dpkg-buildpackage
dpkg-checkbuilddeps: Unmet build dependencies: debhelper (>= 4.1.81)
  pkg-config libncurses5-dev | libncurses-dev zlib1g-dev (>= 1:1.1.3-19.1)
  libbz2-dev libselinux1-dev (>= 1.28-4)

A circular dependency on my debhelper/dpkg requirements. Version requirements for libselinux1-dev and zlib1g-dev that are too up to date for sarge and would require builds. No, it’s gone too far.

Another route would be to try modifying the package build information to get a Django package that doesn’t have any of these requirements. But that also tends to be a slippery slope.

Yeah… just don’t do this. OK?