Posts Tagged ‘install’

Building .deb packages for Python applications

Tuesday, June 2nd, 2009

Building .deb packages for Python applications

Recently I wanted to build a .deb package for an internal IBM application I was writing so that users could easily install it and also so we could distribute them through some internal repositories. This proved a bit harder than I expected so this is a quick summary of how I ended up doing it. Note that your requirements might be entirely different!

The first thing to do is to create the files required by the packaging process. I discovered that the dh_make command can create a load of sample files that can be used as part of this process. To do this, create a directory in the format [package-name]-[version] (e.g. my-great-app-1.0) and run dh_make from within it (I specified ’s’ for single binary when prompted). This will create a load of sample files in a ‘debian’ subdirectory. Delete any of these you don’t need (which is probably most of them); I kept the following:

  • changelog – change history for all versions of the app (keep to the format specified by the Debian Policy Manual)
  • compat – no idea why I needed this but things don’t work properly later if I don’t
  • control – the details of the package you are creating (see the specification for all configuration options)
  • dirs – the list of directories in which your app will install files (e.g. /usr/bin, /usr/share/pyshared/my-great-app, /usr/share/applications)
  • README.Debian – the README for your app
  • rules – a MakeFile with instructions for how to create the package (for my Python app the important bit here was in the ‘install’ section; here I created a $(CURDIR)/debian/my-great-app subdirectory and copied all files into it as if it were /, e.g. binary to $(CURDIR)/debian/my-great-app/usr/bin/my-great-app)

Once I’d created all those files and put them in my-great-app/packaging/debian and my source in my-great-app/src I created a simple build script my-great-app/bin/build. This looked something like the following:


#!/bin/bash

export VERSION=1.0
export DEBFULLNAME="Gareth Jones"
export DEBEMAIL="my-real-email-not-this@somewhere.com"

cd ../build
sudo rm -rf my-great-app*
mkdir -p my-great-app-$VERSION
cp -u ../src/*.py ../src/*.desktop ../src/*.ico ../packaging/my-great-app my-great-app-$VERSION
tar -czf my-great-app-$VERSION.orig.tar.gz my-great-app-$VERSION/
cd my-great-app-$VERSION
mkdir debian
cp -u ../../packaging/debian/* debian/
gksu dpkg-buildpackage

This should create you a my-great-app_1.0-1_all.deb and the my-great-app_1.0-1_i386.changes, my-great-app_1.0-1.dsc and my-great-app_1.0-1.tar.gz files your repository maintainer might want.

A really useful video I found for helping me fill in the contents of the debian control files (and getting me through the whole process) was here. Definitely worth checking out if you need to do this yourself.

PackageKit presentation

Friday, March 20th, 2009

On Wednesday we had the pleasure of Richard Hughes joining us at Hursley to talk about PackageKit. I’ve heard of it but never quite bothered finding out any more than the name but having gone to the presentation I’m pretty glad. PackageKit is (yet another) attempt at making software updating/installation easier on Linux. There are many existing tools for this already but PackageKit seems to be particularly interesting because it’s not actually trying to replace anything; it works with and makes use of the existing tools whilst providing some real value on top. Below is a very quick summary of Richard’s presentation.

Existing stuff

  • Good packaging formats
  • Depency solvers, downloaders and UIs bolted on
  • Can’t have automatic updates (needs password authentication)
  • Can’t use fast-user switching (lock out install applications/databases)
  • Errors/warnings in English only and really confusing to average user
  • Installation is done by package names not application names (many to many relationships)
  • Can power down during update – bit dangerous!

PackageKit implementation

  • The ‘glue’
  • Integrates with existing tools (including dependency mangement etc)
  • Improves authentication (uses PolicyKit – fine grained control)
  • System activited daemon (only running when you need it)
  • Only need to write simple integration between tools and PackageKit (doesn’t even need to be complete and done for most tools already) plus thin UI
  • Uses DBUS (two layers – one for full control, one “just do it”)
  • Applications can integrate directly (e.g. install clipart from openoffice)
  • Installation/update by application not package (users know what it is they’re installing!)
  • Doesn’t allow shutdown during installs

PackageKit project

  • Easy to contribute (git with anonymous access – merged to release daily)
  • Rapid development (roughly one minor release per month)
  • Shipped with Fedora 9 (and others)
  • Strong interest from OpenMOKO, Ubuntu (and others)

I’ve installed an old-ish release on my Ubuntu machine (straight from the repositories) and it looks pretty good. Definitely gonna pay attention to this project, it looks like a big step in the right direction.