Sun, 10 Sep 2006

Packaging Python Maemo applications on a non-Debian platform

Over the past few days I've been working on packaging my application to be a "real" installable Nokia 770 application. After working through the basic desktop integration side of things it was time to create the installable package. The packaging process as described in the tutorial appeared to be relatively straight-forward, if a little tedious...

Alas--as often seems to be the case for me--apparently I was trying to do something just a little bit different from the norm and the documented approach did not work. The main sticking point seemed to be I was running the packaging process on a non-Debian box--specifically Mac OS X.

dh_make

First up I attempted to use the dh_make script to generate the required template files. Although the script is written in Perl unfortunately I couldn't even get a usage message to display--I got multiple lines of error messages instead: 

$ ./dh_make --help
awk: invalid -v option

Can't match key XXXX in map passwd.byname. Reason: Request arguments bad
ldap_sasl_interactive_bind_s: Can't contact LDAP server (-1)
ldap_sasl_interactive_bind_s: Can't contact LDAP server (-1)
Unable to find 822-date program in /usr/bin!
So, the moral of that story for script writers is: if you're only asked for a usage message please don't do a whole lot of processing before you (don't) display it. :-)

From reading the source I discovered you could set environment variables to supply the username and email address it was attempting to find which fixed a couple of the errors. In addition, rather than integrating the downloaded but non-installed 822-date script I just chucked in a hardcoded value for the date. I then changed the hardcoded dh_make install location and by also changing two cp -a to a cp -pR I got it to do enough to generate the required control and rules files.

As a side note: the dh_make script is in the dh-make package. (Note: the change from underscore ('_') to dash ('-') in the name which I think contributes to the bad Google-juice for the script name.) It also wasn't immediately obvious to me but at the bottom of the just linked Debian package page is a link to the actual dh_make / dh-make source tar ball.

debhelper, dpkg-dev, fakeroot and friends

I'll spare you the full story but needless to say--after downloading the required packages debhelper, dpkg-dev and the like--when I ran the required tool I wasn't over-awed by my extreme success: 

$ dpkg-buildpackage.sh -rfakeroot
dpkg-buildpackage.sh: source package is test-package
dpkg-buildpackage.sh: source version is 1.0.0-1
dpkg-buildpackage.sh: source maintainer is fullname <a@b.com>
dpkg-architecture: warning: Unknown gcc system type powerpc-apple-darwin8, falling back to default (native compilation)
dpkg-architecture: warning: Specified GNU system type powerpc-darwin does not match gcc system type powerpc-apple-darwin8.
dpkg-architecture: warning: Unknown gcc system type powerpc-apple-darwin8, falling back to default (native compilation)
dpkg-architecture: warning: Specified GNU system type powerpc-darwin does not match gcc system type powerpc-apple-darwin8.
dpkg-buildpackage.sh: host architecture is darwin-powerpc
/var/lib/dpkg/status: No such file or directory
dpkg-buildpackage.sh: Build dependencies/conflicts unsatisfied; aborting.
dpkg-buildpackage.sh: (Use -d flag to override.)
And so on, and so forth. While I admit I didn't have all the scripts installed (i.e. I was trying to point the scripts to the uninstalled locations), by this time it was seeming like a whole lot of effort to get anywhere for what wasn't that complicated an operation. So, I did a -d and hit the next bump: 
 ...
dpkg-buildpackage.sh: host architecture is darwin-powerpc
 fakeroot debian/rules clean
dpkg-buildpackage.sh: line 175: fakeroot: command not found
And indeed it wasn't. (Found, that is.)

Turns out fakeroot is a not-entirely trivial piece of code apparently not currently available on OS X--although it seems someone has at least tried porting fakeroot to Mac OS X. By this stage I had no real interest in trying the fakeroot port (I'm only packaging a Python script for pete's sake!) so I decided I needed to find another approach.

Apparently I'm not the only person to get frustrated by Debian packaging tools--but the thread in question does cover some interesting material. (Also, here's Ubuntu's take on Debian packaging.)

bdist_deb or not

Need some sleep so this is to be continued... (But, you know, thought I'd release early and often...)

Rest assured--while this is a bit of a rant I do have a constructive purpose and solution in hand and I'm only documenting things so thoroughly to provide Google-bait to hopefully help prevent someone else from spending the same time discovering the same things. :-)

Update: Part two

Posted at: 01:25 | category: /maemo | Comments ()