1.
Packaging Applications for the Maemo Platform

2.
First, find something you want to package <ul><li>Sounds obvious, but if you're not interested, you won't maintain your package. </li></ul><ul><li>Pull down sources of software that you use locally, or use your own software. :-) </li></ul><ul><li>Packaging your own software is a common thing to do, in debian as well. I have no evidence, but anecdotal data seems to suggest most packages in Maemo, the packager is also 'upstream' as well. </li></ul>

3.
In the beginging was the tarball <ul><li>You can create a tarball from your VCS repository, or pull it down from upstream </li></ul><ul><li>Then add the debian directory </li></ul><ul><li>Debian requires that the source code be pristine . You can create files in the debian/ directory, but you may not alter the source code, (unless it is your source code, of course) </li></ul><ul><li>Note the license if you are porting software – you don't want to package non-free software into a free software environment. </li></ul>

4.
Automated <ul><li>I can recommend using one of Debian's tools to create the first package skeleton. </li></ul><ul><ul><li>dh-make for single packages or libs </li></ul></ul><ul><ul><li>dh-make-perl for perl packages </li></ul></ul><ul><ul><li>dh-make-php . . . </li></ul></ul><ul><ul><li>etc </li></ul></ul><ul><li>Takes care of most of the boilerplate </li></ul>

5.
dh_make example export DEBFULLNAME=”Hack Er” dh_make –email [email_address] --copyright=bsd --file ../foo.tar.gz This is all you really need to get started in most cases. Note that you should be in the source directory to run this.

6.
What do we end up with? $ tar xvf pyyaml_3.05.orig.tar.gz $ ls examples ext lib LICENSE PKG-INFO README setup.cfg setup.py setup_with_libyaml.py $ mv PyYAML-3.05 pyyaml-3.05 $ ls debian examples ext lib LICENSE PKG-INFO README setup.cfg setup.py setup_with_libyaml.py Oh! A debian dir!

7.
Lots of extraneous files <ul><li>Even if you are packaging for Debian, dh-make adds a lot of unncessary files. </li></ul><ul><li>You can remove many of them since they are only examples of files you might need, like man pages </li></ul><ul><li>Since maemo does not use man pages due to space constraints you can safely remove a lot of these files. </li></ul>

8.
Absolutely necessary files <ul><li>There is a skeleton provided by Nokia here: https://garage.maemo.org/svn/maemoexamples/trunk/maemo-examples/debian/ </li></ul><ul><li>This is actually a really good starting point, it provides some excellent examples and you know that it should work on the platform since Nokia provides these templates. </li></ul><ul><li>At the very least you need: changelog, control, copyright, and rules </li></ul>

9.
changelog <ul><li>This holds the canonical version number, this is where the build tools will look for version info – so it has to be there. </li></ul><ul><li>It also should hold information regarding any changes to your software, or to the upstream software if you are packaging only </li></ul><ul><li>It should also hold a valid email address and not the upstream email address. :) </li></ul>

10.
copyright <ul><li>Obviously, very important. Copyright is crucial to legal enforcement of licensing, you would not want pirated software in your free software device and repos </li></ul><ul><li>Note the boilerplate saying to look deeper into the package and check for copyright work; something like: </li></ul><ul><li>Find -type f -exec grep copyright {} ; </li></ul>

11.
control <ul><li>This is where the fun is, the packaging specification if you will. </li></ul><ul><li>Please make sure you change the maintainers name and add the XSBC-Original-Maintainer field; </li></ul><ul><li>Maintainer: Jeremiah Foster <jeremiah@maemo.org> </li></ul><ul><li>XSBC-Original-Maintainer: Debian Python Modules Team < [email_address] > </li></ul>

12.
rules <ul><li>'rules' is a Make file, an executable makefile </li></ul><ul><li>From the New Maintainer's Guide: </li></ul><ul><li>“ The important part to know about the rules file created by dh_make, is that it is just a suggestion. It will work for simple packages but for more complicated ones, don't be afraid to add and subtract from it to fit your needs. Only thing that you must not change are the names of the rules, because all the tools use these names, as mandated by the Policy.” </li></ul>

13.
An Average rules file <ul><li>#!/usr/bin/make -f </li></ul><ul><li>build: </li></ul><ul><li>dh build </li></ul><ul><li>clean: </li></ul><ul><li>dh clean </li></ul><ul><li>binary-arch: </li></ul><ul><li>dh binary-arch </li></ul><ul><li>binary-indep: </li></ul><ul><li>dh binary-indep </li></ul><ul><li>binary: </li></ul><ul><li>dh binary </li></ul>

14.
More rules <ul><li>We can in fact convert the entire rules file to this: </li></ul><ul><li>#!/usr/bin/make -f </li></ul><ul><li>%: </li></ul><ul><li>dh $@ </li></ul><ul><li>That's it, that is everything! This will build with dpkg-buildpackage -rfakeroot </li></ul>

15.
All those dh_* commands in your rules file <ul><li>“ A collection of programs that can be used in a debian/rules file to automate common tasks related to building debian packages. Programs are included to install various files into your package, compress files, fix file permissions, integrate your package with the debian menu system, debconf, doc-base, etc. Most debian packages use debhelper as part of their build process.” </li></ul><ul><li>A modular, elegant solution to a complex problem </li></ul>

16.
What does dh_* do? <ul><li>dh_auto_configure -> ./configure --prefix=/usr </li></ul><ul><li>dh_auto_build -> make </li></ul><ul><li>dh_auto_test -> make test || check </li></ul><ul><li>dh_auto_install -> make install </li></ul><ul><li>du_auto_clean -> make distclean || clean </li></ul><ul><li>That looks like a regular autotools recipe </li></ul>

17.
dh_auto_* <ul><li>dh_auto_configure -> perl Build.PL </li></ul><ul><li>dh_auto_build -> perl Build </li></ul><ul><li>dh_auto_test -> perl Build test </li></ul><ul><li>dh_auto_install -> perl Build install </li></ul><ul><li>du_auto_clean -> perl Build distclean </li></ul><ul><li>That looks like a regular perl build recipe </li></ul>

18.
dh_auto_* <ul><li>dh_auto_configure -> </li></ul><ul><li>dh_auto_build -> ./setup.py build </li></ul><ul><li>dh_auto_test -> </li></ul><ul><li>dh_auto_install -> ./setup.py install --blah </li></ul><ul><li>du_auto_clean -> ./setup.py clean </li></ul><ul><li>That looks like a regular python recipe </li></ul>

19.
There is more than one way to build it <ul><li>I prefer dpkg-buildpackage in combination with debhelper. I think it is a powerful set of tools, and modular. </li></ul><ul><li>There are other build systems, like CDBS: “Common Debian Build System, an abstract build system based on Makefile inheritance which is completely extensible and overridable. “ </li></ul>

20.
Market share

21.
Open Build System <ul><ul><li>SuSE has as service that certain members of our community swear by (I'm looking at you David Greaves) and already has Maemo packages on it. </li></ul></ul><ul><ul><li>Might be an excellent choice since it builds debs and other formats, like rpms, and is used by Mer. </li></ul></ul><ul><ul><li>http://en.opensuse.org/Build_Service/Testing </li></ul></ul>

22.
Dependencies <ul><li>The packager is responsible for tracking down all necessary dependencies. There are tools to help you, like dpkg-shlibsdep </li></ul><ul><li>In maemo, the packager and the developer are often the same person, so tracking down dependencies should not be so hard </li></ul><ul><li>dh_make will try to calculate them in certain circumstances </li></ul>

23.
Dependencies 2 <ul><li>Tracking down and adding dependencies is both necessary and powerful. </li></ul><ul><li>Obviously since we are building a package based on the architecture of the platform (armel) then we have to provide all the libraries to build it </li></ul><ul><li>Benefit: the user doesn't have to go through “dependency hell” </li></ul>

24.
Dependencies 3 <ul><li>Sometimes, you'll have to track down dependencies not already in maemo, or even in debian. Or they may have a different name. </li></ul><ul><li>Example libproxy0.2.3 is called libproxy in debian – it is in 'squeeze' so the packager has to 'backport' it to Lenny and upload it to the repositories. </li></ul>

25.
Dependencies 4 <ul><li>http://packages.debian.org Is your friend! </li></ul><ul><li>Whatever you are missing, check in debian first, it should be there. </li></ul><ul><li>dpkg-shlibdeps should help as well but needs to be run against symbols files or other shlibs files in debian. It is the tool that tries to create dependency chains </li></ul><ul><li>Sometimes you'll have build dependencies as well, </li></ul>

26.
auto-apt <ul><li>Automatically determines, and installs, build dependencies found in automake / autoconf files configuration files </li></ul><ul><li>Caveat emptor </li></ul>

27.
dpkg-buildpackage <ul><li>Yet another perl script! No surprise really since debian pretty much began it's life as a kernel, a bunch of C libraries and perl. </li></ul><ul><li>Builds both the binary deb and your source package </li></ul>

28.
Maemo is (and isn't) debian <ul><li>Yeah, there is apt-get and .debs, but don't be fooled, maemo is not debian </li></ul><ul><li>This means that maemo does not have to follow debian's conventions, it is free to innovate without having to go through the traditional debian decision making process – which debian's founder calls “Process run amok.” </li></ul>

29.
Maemo's own build system <ul><li>Maemo does not use the build tools that debian does in the way debian does </li></ul><ul><li>You can get involved in shaping how packages are built on maemo </li></ul>

30.
Pbuilder and cowbuilder <ul><li>Pbuilder stands for personal builder </li></ul><ul><li>Automatically builds debian packages in a “clean-room” environment </li></ul><ul><li>Helps to verify that a package can be built on the average debian system </li></ul><ul><li>It creates a base chroot image, downloads and installs a complete, but minimal, debian system </li></ul><ul><li>Cowbuilder is pbuilder sped up by using cowdancer, a copy-on-write system in userland </li></ul>

31.
Other debian goodies <ul><li>There are a number of tools inside debian that can make a packager's life easier. Tools like; </li></ul><ul><li>debdiff: compare file lists in two binary Debian packages </li></ul><ul><li>pbuilder: clean room (chroot) build environment to verify the build dependencies </li></ul><ul><li>mc (mindnight commander) is a file browser that can read debs </li></ul><ul><li>Linitan is being transformed into maemian, which may become a stand-alone tool you can run locally. </li></ul><ul><li>dch: Simple tool for writing and formatting changelogs </li></ul><ul><li>debian-goodies: dgrep - Search all files in specified packages for a regex for example. </li></ul>

32.
Sources <ul><li>http://www.debian.org/doc/maint-guide/ch-first.en.html </li></ul><ul><ul><li>Debian New Maintainer's Guide </li></ul></ul><ul><li>http://wiki.debian.org/DebianPython/NewPolicy </li></ul><ul><ul><li>Debian's python policy </li></ul></ul><ul><li>https://garage.maemo.org/svn/maemoexamples/trunk/maemo-examples/debian/ </li></ul><ul><ul><li>Package file examples from maemo </li></ul></ul><ul><li>http://wiki.maemo.org/Documentation/Maemo_5_Developer_Guide/Packaging%2C_Deploying_and_Distributing </li></ul><ul><ul><li>Maemo packaging guide on the Maemo wiki </li></ul></ul><ul><li>http://meetings-archive.debian.net/pub/debian-meetings/2009/debconf9/low/1060_Not_your_grandpas_debhelper.ogv </li></ul><ul><ul><li>Joey Hess' talk at debconf 2009 on debhelper </li></ul></ul>