Chapter contents:

Creating Debian packages

This chapter will introduce you to the Debian packaging system. We will restrict ourselves to cover the tools that are of immediate interest when creating new packages. Issues like building your own package repositories are not covered here, but there is ample information available with Internet search engines.

Packaging Basics

Most modern Linux distributions utilize some kind of packaging system. Two of the most popular ones are the Red Hat package Manager and Debian's dpkg-based system (although it's mainly popular because of a tool called apt-get).

All packaging systems strive to solve the same problems. Mainly, how to keep track which file belongs to which software package, so that a group of files may be upgraded in a coherent fashion, or removed all together. Keeping track of files necessitates some kind of local database and packaging systems are quite different in which technical solutions they select.

Before packaging systems existed on Linux, it was common to distribute source code as source tarballs (make dist makes it easy now, but back then it was a bit more difficult). This made installing software quite easy when you knew the tools that were used in building the software, but for a novice, it was sometimes painful. Removing the software was still quite hard, since targets like uninstall weren't common.

Slackware was the first Linux distribution to think about developing a common mechanism for software distribution, and they chose to distribute software as binary packages (this is what most distributions do now). You could of course get the source code for the software as well, but ordinary users weren't so much interested in source code, but wanted to get the software running. Computers were somewhat slower back then as well, so compiling software sometimes took long times (2.0 series kernel building took over 24 hours). Hence, the idea that one could build the binaries once, collect the relevant configuration and manual files together and then distribute them, was seen as an improvement.

Slackware used tarballs as the distribution mechanism. Each package tarball also contained a script that was executed on software install and this script could then modify some system configuration files so that the software could run (set the runlevel related symbolic links for example).

Along came Red Hat, and they decided that the Slackware way was ugly and they could do better. They wrote their own packaging system (which also uses compressed binary archives, but not tar.gz). Red Hat's packaging system could relatively easily be used to rebuild the binaries if one so wanted or needed. The RPM system has a Berkeley DB-based local database in which the system keeps track of files that were installed from each package. The RPM system also provides some searching tools into the database as well as other features.

The Debian project started to think about package management at about the same time and implemented a packaging system that would also contain dependency information about what a package required to be installed before-hand before it could be installed safely. The reason why Debian didn't use RPMs was that RPM back then didn't support dependencies and wasn't available when Debian started thinking about these things. Nowadays both RPM and the Debian packaging system contain similar technical capabilities and it can be a matter of taste which one to choose when starting a new Linux distribution.


Soon after introducing the concept of software packages, it was evident that there needed to be some way to codify the rules within the packages which would guard against installing incompatible packages into the same system. The typical example was installing a mail server when there were multiple different choices for one (there have been alternatives to sendmail for many years). Suppose you wanted to install an alternative mail server and you already had sendmail installed. Since both of the services would access the same directory paths (mail spools), this would create chaos. They could not listen to the same TCP port either (not on the same IP address at least). This would cause problems to the administrator, so a system for describing package conflicts was developed. Soon after this, people noticed that applications started to use shared libraries and it didn't make sense to link libraries in static form into binaries, so a need for describing dependencies between installed packages arose.

In all modern Linux distributions it is the dependencies and their quality that determine how easy or hard it is for the busy system administrator to manage a Linux server. This applies to the desktop arena as well.

We will cover the syntax and operation of the Debian package dependencies and conflicts but other packaging systems have similar mechanisms.

Packaging infrastructure

The one thing that set apart the Debian packaging tools for a long time was a program called apt-get. It does not install software packages into the system, neither does it modify the local database. It is a program that reads package dependency and conflict information and tries to solve them in an intelligent way so that users may install or remove the packages that they want to.

One thing that makes apt-get special is its support for multiple ways of accessing repositories of packages (physical storage for packages in Debian). One of the most popular mechanism to use apt-get is the http-method (ftp being available as well). This means that when installing a package (which you don't have to download first), apt-get will first do some calculations and tell you which other packages (and their versions) need to be installed so that the original (and other) packages' dependencies won't be broken. After pressing ENTER, apt-get will download the necessary packages and invoke the low-level package management tool (dpkg) in the order necessary to complete the user's wishes.

One point needs to be re-iterated: writing correct dependencies (not too strict, but complete) is critical for tools like apt-get to work properly. Otherwise things will break and users will be unhappy. This is often the hardest thing to get right.

Some important program options and locations:

Please note that these commands and paths will be present on any real Debian system, but might be absent from special purpose target devices. An Internet Tablet for example might not contain all of these, and also some files have been removed to conserve storage space. The SDK environment contains them and you can even use apt-get to install new software from the public repositories and get source code for most of the programs and libraries. This will require an connection to the Internet. You can sometimes even do an upgrade to a newer version of the SDK (you should check the SDK release notes and installation instructions before doing this).

Debian packages

Packages generally contain all the files necessary to implement a set of related commands and/or features.

There are two kinds of Debian packages:

The package filename is structured as follows:


Package filename components:

The maemoRevision field might change when the control file or installable configuration files change. It will also sometimes change when a quick bug fix is done but the upstream maintainer hasn't yet released a version that includes this bug fix.

Some examples from one release of the SDK follow:

One noteworthy thing above is that source package names don't always correspond to binary package names. This is especially true with large source package which will produce multiple binary packages, or will package documentation separately.

The binary packages that can be built from one source package are listed using the Binary field of the Debian source control file:

Format: 1.0
Source: db4.2
Version: 4.2.52-18osso
Binary: libdb4.2++, db4.2-doc, libdb4.2-dev, libdb4.2++-dev, libdb4.2
Maintainer: Debian Berkeley DB Maintainers
Architecture: any
Standards-Version: 3.6.1
Build-Depends: procps [!hurd-i386]
Uploaders: Clint Adams <>,
 Matthew Wilcox <>,
 Andreas Barth <>
 cbc77517c9278cdb47613ce8cb55779f 4073147 db4.2_4.2.52.orig.tar.gz
 4926da646ea05246767da25aac139aef 80499 db4.2_4.2.52-18osso.diff.gz

[ Contents of db4.2_4.2.52-18osso.dsc. ]

If a package is significantly different from the upstream version, it won't always have a .diff.gz file.

Installation process

When a package is installed by dpkg, the installation goes through various stages in the order specified below (from the dpkg man-page):

Package relationships

Each package contains a control-file which contains all the dependency, conflict and feature information. These are collectively called package relationships.

Debian supports the following kinds of relationships:

Syntax for the package specifications when declaring the relationships is as follows:

Some examples:

Depends: foo (=1.2.0)
Depends on package foo's exact version 1.2.0 (no other installed version will do)

Conflicts: foo
Conflicts with all versions of package foo

Depends: foo (>=1.2.3) | foobars, foozonkle
Package installation requires that package foo's version 1.2.3 or higher is installed, or package foobars is installed. Package foozonkle must be installed as well (irrespective of the previous restriction) but any version of it will do.

Package control file (aka Debian control file)

Package: packagename
Priority: optional (to aid intelligent tools wrt desktop installation)
Section: devel (which part of the ftp archives on Debian this package lives in)
Installed-Size: 45 (in KiB) to aid intelligent inst tools (filled in automatically)
Maintainer: First Lastname 
Architecture: i386 (filled in automatically)
Version: 1.3-16 (-16 = Debian revision, filled in automatically)
Depends: libc6 (>= 2.1) (filled automatically when using shlibs:Depends-macro)
Description: The classic greeting, and a good example
 Long description starts always with a space
 Empty lines are not permitted (they terminate the long description)
 So, there is a mechanism to allow this:
 That was an "empty line"

[ An example Debian control file ]

For full syntax and canonical explanation, please see the Debian Policy Manual, Section 5.

Depends lists the packages which need to be installed for this package to install successfully (explained above).

Debian is split into three main sections: main (free software), non-free (not really free according to Debian policy), contrib (free software that depends on non-free).

However, in maemo, only one section has been defined so far: user. This has been further split into application categories which should be used when possible so that automatic localization can be done in the Application manager.

The subsections as of this moment are:

If you cannot find a subsection that suits you, you can create a new one of your choosing, but it will not be automatically localized.

If you do not use the user section, the Application manager will not show your package as installable.

Each package is assigned a priority by the distribution maintainer (normally) to signify the relative importance with respect to proper functioning of the installed system. These control intelligent installation tools like apt-get. However, in maemo, only the priority optional should be used for your packages.

A maemo example control file

The Application manager supports special control directives as well as the normal Debian ones. This is how packages are provided with icons that the user will see on installation. These special directives start all with the prefix XB-Maemo-.

As example control file from the HOWTOs looks like this:

Source: myapplication
Section: user/other 
Priority: optional 
Maintainer: Your Name <>
Build-Depends: debhelper (>= 5) 
Standards-Version: 3.7.2

Package: myapplication 
Architecture: any
Depends: libhildon1 (>= 1.0.11)
Description: A simple test application
 A very simple application with a short description.
 Which spans multiple lines actually. 

The icon is embedded as an MIME-encoded 26×26 pixel PNG file directly into the control directive.

For more information, please see Creating a Debian package HOWTO .

Creating your package

In this section we'll cover step by step instructions on how to convert an autotoolized project into a Debianized project and how to generate the binary package based on the Debian control file.

Step by step instructions (with screen captures shortly):

Let's see what will happen when we follow these instructions. We have already tested the autotoolized package before and verified that it works with make distcheck. We start by from a clean setup, by doing the dist target we'll get the source tarball that we'll need to start with the package building process.

[sbox-CHINOOK_X86: ~/hhwx-autotoolized] > ls -la
total 80
drwxr-xr-x   2 user user  4096 Nov 18 20:37 .
drwxr-xr-x  10 user root  4096 Nov 18 20:36 ..
-rw-r--r--   1 user user   124 Nov 18 20:36 AUTHORS
-rw-r--r--   1 user user  1174 Nov 18 20:36 COPYING
-rw-r--r--   1 user user   159 Nov 18 20:36 ChangeLog
-rw-r--r--   1 user user  1174 Nov 18 20:36 License
-rw-r--r--   1 user user   847 Nov 18 20:36
-rw-r--r--   1 user user    85 Nov 18 20:36 NEWS
-rw-r--r--   1 user user    73 Nov 18 20:36 README
-rwxr-xr-x   1 user user   706 Nov 18 20:36
-rwxr-xr-x   1 user user  1024 Nov 18 20:36
-rw-rw-r--   1 user user  1542 Nov 18 20:36
-rw-rw-r--   1 user user 23910 Nov 18 20:36 hhwX.c
-rw-r--r--   1 user user   162 Nov 18 20:36
-rw-r--r--   1 user user    59 Nov 18 20:36
[sbox-CHINOOK_X86: ~/hhwx-autotoolized] > ./
.. output cut .. installing `./depcomp'
Ready to go (run configure)
[sbox-CHINOOK_X86: ~/hhwx-autotoolized] > ./configure
checking for a BSD-compatible install... /scratchbox/tools/bin/install -c
checking whether build environment is sane... yes
.. output cut ..
checking pkg-config is at least version 0.9.0... yes
checking for HHW... yes
configure: creating ./config.status
config.status: creating Makefile
config.status: executing depfiles commands
configure: creating ./config.status
config.status: creating Makefile
config.status: creating hhwX.desktop
config.status: creating org.maemo.hhwX.service
config.status: executing depfiles commands
[sbox-CHINOOK_X86: ~/hhwx-autotoolized] > make dist
{ test ! -d hhwx-0.1 || .. output cut.. 
[sbox-CHINOOK_X86: ~/hhwx-autotoolized] > ls -l *.tar.gz
-rw-rw-r--  1 user user 80229 Nov 18 20:51 hhwx-0.1.tar.gz

[ Preparing the source code for Debian packaging ]

You might notice that the step was omitted above. Since the source code was in a pristine condition, running was unnecessary (as running the make distcheck -step).

Next, let's create a directory one level up where we'll extract the package and then prepare the extracted source for Debianization:

[sbox-CHINOOK_X86: ~/hhwx-autotoolized] > mkdir ../packaging
[sbox-CHINOOK_X86: ~/hhwx-autotoolized] > cp hhwx-0.1.tar.gz ../packaging
[sbox-CHINOOK_X86: ~/hhwx-autotoolized] > cd ../packaging
[sbox-CHINOOK_X86: ~/packaging] > tar xzvf hhwx-0.1.tar.gz
[sbox-CHINOOK_X86: ~/packaging] > cd hhwx-0.1

[ Creating the packaging working space and extracting the source ]

Next, we use the dh_make program to create the necessary Debian files so that we don't have to write everything ourselves:

[sbox-CHINOOK_X86: ~/packaging/hhwx-0.1] > DEBFULLNAME="User Universal"  \
 dh_make -e -f ../hhwx-0.1.tar.gz

Type of package: single binary, multiple binary, library, kernel module or cdbs?
 [s/m/l/k/b] s

Maintainer name : User Universal
Email-Address   :
Date            : Sun, 18 Nov 2007 21:06:26 +0200
Package Name    : hhwx
Version         : 0.1
License         : blank
Type of Package : Single
Hit <enter> to confirm: [ENTER]
Done. Please edit the files in the debian/ subdirectory now. hhwx
uses a configure script, so you probably don't have to edit the Makefiles.
[sbox-CHINOOK_X86: ~/packaging/hhwx-0.1] > cd debian
[sbox-CHINOOK_X86: ~/packaging/hhwx-0.1/debian] > ls -l
total 104
-rw-rw-r--  1 user user  171 Nov 18 21:06 README.Debian
-rw-rw-r--  1 user user  181 Nov 18 21:06 changelog
-rw-rw-r--  1 user user    2 Nov 18 21:06 compat
-rw-rw-r--  1 user user  337 Nov 18 21:06 control
-rw-rw-r--  1 user user  621 Nov 18 21:06 copyright
-rw-rw-r--  1 user user   77 Nov 18 21:06 cron.d.ex
-rw-rw-r--  1 user user   17 Nov 18 21:06 dirs
-rw-rw-r--  1 user user   12 Nov 18 21:06 docs
-rw-rw-r--  1 user user 1224 Nov 18 21:06 emacsen-install.ex
-rw-rw-r--  1 user user  456 Nov 18 21:06 emacsen-remove.ex
-rw-rw-r--  1 user user 1111 Nov 18 21:06 emacsen-startup.ex
-rw-rw-r--  1 user user  226 Nov 18 21:06 hhwx-default.ex
-rw-rw-r--  1 user user  486 Nov 18 21:06 hhwx.doc-base.EX
-rw-rw-r--  1 user user 2106 Nov 18 21:06 init.d.ex
-rw-rw-r--  1 user user 1731 Nov 18 21:06 manpage.1.ex
-rw-rw-r--  1 user user 4640 Nov 18 21:06 manpage.sgml.ex
-rw-rw-r--  1 user user 4597 Nov 18 21:06 manpage.xml.ex
-rw-rw-r--  1 user user  109 Nov 18 21:06 menu.ex
-rw-rw-r--  1 user user  956 Nov 18 21:06 postinst.ex
-rw-rw-r--  1 user user  929 Nov 18 21:06 postrm.ex
-rw-rw-r--  1 user user  689 Nov 18 21:06 preinst.ex
-rw-rw-r--  1 user user  876 Nov 18 21:06 prerm.ex
-rwxr-xr-x  1 user user 2515 Nov 18 21:06 rules
-rw-rw-r--  1 user user  659 Nov 18 21:06 watch.ex
[sbox-CHINOOK_X86: ~/packaging/hhwx-0.1/debian] > cat ../COPYING > copyright
[sbox-CHINOOK_X86: ~/packaging/hhwx-0.1/debian] > ls -l ../COPYING copyright
-rw-r--r--  1 user user 1174 Nov 18 20:36 ../COPYING
-rw-rw-r--  1 user user 1174 Nov 18 21:07 copyright

[ Creating template files for packaging and overwriting the default copyright file. ]

The copyright file was overwritten because the default one (a GPL template) didn't suite the project. You should check the template whether it is suitable for use (dh_make also supports couple of other open source copyright/license templates).

Now we need to remove the files that we don't need:

[sbox-CHINOOK_X86: ~/packaging/hhwx-0.1/debian] > rm *.ex *.EX dirs docs README.Debian
[sbox-CHINOOK_X86: ~/packaging/hhwx-0.1/debian] > ls -l
total 20
-rw-rw-r--  1 user user  181 Nov 18 21:06 changelog
-rw-rw-r--  1 user user    2 Nov 18 21:06 compat
-rw-rw-r--  1 user user  337 Nov 18 21:06 control
-rw-rw-r--  1 user user 1174 Nov 18 21:07 copyright
-rwxr-xr-x  1 user user 2515 Nov 18 21:06 rules

[ Removing unnecessary example files ]

Then edit the control file to contain the necessary dependencies, the necessary Section and other settings. We're not adding the icon to our package at this time.

Source: hhwx
Section: user/other
Priority: extra
Maintainer: User Universal <>
Build-Depends: debhelper (>= 5), libgtk2.0-dev, libhildon1-dev,
 libhildonfm2-dev, libosso-gnomevfs2-dev, libgconf2-dev,
Standards-Version: 3.7.2

Package: hhwx
Architecture: any
Depends: ${shlibs:Depends}
Description: The ultimate Hello World
 This is the tenth version of Hello World.
 Demonstrates simple GUI things with Hildon and support

[ The modified version of control file ]

And now everything should be ready for us to build the package:

[sbox-CHINOOK_X86: ~/packaging/hhwx-0.1] > dpkg-buildpackage -rfakeroot
dpkg-buildpackage: source package is hhwx
dpkg-buildpackage: source version is 0.1-1
dpkg-buildpackage: source changed by User Universal <>
dpkg-buildpackage: host architecture i386
dpkg-buildpackage: source version without epoch 0.1-1
: Using Scratchbox tools to satisfy builddeps
 fakeroot debian/rules clean
.. output cut ..
dpkg-deb: building package `hhwx' in `../hhwx_0.1-1_i386.deb'.
dpkg-genchanges: including full source code in upload
dpkg-buildpackage: full upload (original source is included)
[sbox-CHINOOK_X86: ~/packaging/hhwx-0.1] > cd ..
[sbox-CHINOOK_X86: ~/packaging] > ls -l
total 216
drwxrwxr-x  4 user user  4096 Nov 18 21:44 hhwx-0.1
-rw-rw-r--  1 user user 80229 Nov 18 21:00 hhwx-0.1.tar.gz
-rw-rw-r--  1 user user 24248 Nov 18 21:44 hhwx_0.1-1.diff.gz
-rw-rw-r--  1 user user   400 Nov 18 21:44 hhwx_0.1-1.dsc
-rw-rw-r--  1 user user   727 Nov 18 21:44 hhwx_0.1-1_i386.changes
-rw-r--r--  1 user user 11750 Nov 18 21:44 hhwx_0.1-1_i386.deb
-rw-rw-r--  1 user user 80229 Nov 18 21:00 hhwx_0.1.orig.tar.gz
[sbox-CHINOOK_X86: ~/packaging] > dpkg --info hhwx_0.1-1_i386.deb
 new debian package, version 2.0.
 size 11750 bytes: control archive= 773 bytes.
     641 bytes,    13 lines      control
     409 bytes,     6 lines      md5sums
 Package: hhwx
 Version: 0.1-1
 Section: user/other
 Priority: extra
 Architecture: i386
 Depends: libatk1.0-0 (>= 1.12.2), libc6 (>= 2.5.0-1), libcairo2 (>= 1.4.10),
  libdbus-1-3 (>= 0.94), libdbus-glib-1-2 (>= 0.74), libgconf2-6 (>= 2.13.5),
  libglib2.0-0 (>= 2.12.12-1osso3), libgtk2.0-0 (>= 2:2.10.12-0osso15),
  libhildon1 (>= 1.0.11), libhildonfm2 (>= 1:1.9.46), libosso-gnomevfs2-0,
  libosso1 (>= 2.13), libpango1.0-0 (>= 1.16.4)
 Installed-Size: 84
 Maintainer: User Universal <>
 Description: The ultimate Hello World
  This is the tenth version of Hello World.
  Demonstrates simple GUI things with Hildon and support
[sbox-CHINOOK_X86: ~/packaging] > dpkg --contents hhwx_0.1-1_i386.deb
drwxr-xr-x root/root     0 2007-11-18 21:44:44 ./
drwxr-xr-x root/root     0 2007-11-18 21:44:43 ./usr/
drwxr-xr-x root/root     0 2007-11-18 21:44:44 ./usr/bin/
-rwxr-xr-x root/root 20384 2007-11-18 21:44:44 ./usr/bin/hhwX
drwxr-xr-x root/root     0 2007-11-18 21:44:43 ./usr/share/
drwxr-xr-x root/root     0 2007-11-18 21:44:43 ./usr/share/applications/
drwxr-xr-x root/root     0 2007-11-18 21:44:43 ./usr/share/applications/hildon/
-rw-r--r-- root/root   158 2007-11-18 21:44:43 ./usr/share/applications/hildon/hhwX.desktop
drwxr-xr-x root/root     0 2007-11-18 21:44:43 ./usr/share/dbus-1/
drwxr-xr-x root/root     0 2007-11-18 21:44:43 ./usr/share/dbus-1/services/
-rw-r--r-- root/root    55 2007-11-18 21:44:43 ./usr/share/dbus-1/services/org.maemo.hhwX.service
drwxr-xr-x root/root     0 2007-11-18 21:44:43 ./usr/share/doc/
drwxr-xr-x root/root     0 2007-11-18 21:44:44 ./usr/share/doc/hhwx/
-rw-r--r-- root/root  1174 2007-11-18 21:07:54 ./usr/share/doc/hhwx/copyright
-rw-r--r-- root/root   158 2007-11-18 20:36:56 ./usr/share/doc/hhwx/changelog.gz
-rw-r--r-- root/root   189 2007-11-18 21:06:40 ./usr/share/doc/hhwx/changelog.Debian.gz

[ Building the package and listing its information and contents ]

Now we're ready to install the package using dpkg.

[sbox-CHINOOK_X86: ~/packaging] > fakeroot dpkg -i hhwx_0.1-1_i386.deb
Selecting previously deselected package hhwx.
(Reading database ... 19483 files and directories currently installed.)
Unpacking hhwx (from hhwx_0.1-1_i386.deb) ...
Setting up hhwx (0.1-1) ...

[ Installing the package manually ]

After the installation, the menu should now be updated and you should be able to start the application.

[ Everything seems to be in order ]

We then also remove the package manually.

[sbox-CHINOOK_X86: ~/packaging] > fakeroot dpkg --purge hhwx
(Reading database ... 19490 files and directories currently installed.)
Removing hhwx ...

[ Removing the package manually. ]

You can verify that the application has been removed from the menus now.

End users normally will not use dpkg manually, but instead they will use the Application manager program in the target device. In order for the Application manager to find the file to install, it will need to be located under ~/MyDocs/. You then need to use the "install from a file..." function from the menu.

Adding debugging support for a package

So that your application can be debugged by others, you should consider adding a separate package for your application which will contain the debugging information. Normally debugging symbols are stripped as part of the package building process above, so the resulting package ends up being without debugging support. This is an issue on the ARMEL target.

In order to create a debugging version of your package, please see the "How to make a Debian debug package" HOWTO, available at

Building the package for a device

At this point you should make sure that you have the ARMEL target in your Scratchbox as well as the X86 one which you've (hopefully) been using so far:

[sbox-CHINOOK_X86: ~] > sb-conf ls -T

[ Listing set up targets in Scratchbox. ]

If you only have the X86 target setup, you will need to setup the ARMEL target now, before proceeding. Please see the last chapter of "maemo Getting Started" material for instructions. If you used the automatic installation script, you should automatically have both targets.

If you have your software, or the AF running, you'll need to stop both now ( stop to stop the AF). It is important to do this before switching targets, although sbox normally won't allow you to switch anyway if you have any processes running in the current target.

When you're done with shutting down the current target, switch your target to ARMEL:

[sbox-CHINOOK_X86: ~] > sb-conf select CHINOOK_ARMEL
.. screen clears ..
[sbox-CHINOOK_ARMEL: ~] > arch

[ Switching the Scratchbox target. ]

To build the Debian package in the ARMEL target:

One noteworthy thing about the ARMEL target is that it's not really meant to act as a testing environment. How much of your software will work, will depend on the version of Qemu that will be used to emulate the ARM instructions. In short, it's best to test the ARMEL versions of your packages on a real device.

Installing packages into an Internet Tablet

Once you've built the ARM-version of your package, you'll next need to transfer it to the device. Since the device appears as an USB mass storage device to your Linux, it is normally enough to attach the USB cable and then mount the device into some suitable directory under Linux. Also most modern graphical environments will do the mounting step for you, so don't be surprised if you don't need to do the mounting manually.

The storage that you can access this way is restricted to the memory card inside the device. It is not possible to access the internal flash memory of the device in this way. The filesystem on the memory card will be VFAT, so it will contain all the normal problems that are related to Windows filenames. Copy the package to the mounted directory and then un-mount the USB storage (pumount is normally enough, or you can use the graphical interface). After detaching the cable from the device the device will mount the card internally and it can access the contents on the card.

Because the storage space is not available to both the device and your Linux desktop at the same time, some people opt to use an SSH server and use scp to copy files directly. Setting up an SSH server on the device is not covered here, but is pretty simple. Just remember to set your device into "R&D"-mode.

Once the package file is on the device (under /home/user/MyDocs), use the Application manager and select the package file to install. If something will go wrong, you'll probably need a command line access to the device. Use the supplied X-Term emulator, and sudo gainroot to get root privileges (device needs to be in "R&D"-mode for gainroot to work).

Copyright © 2007-2008 Nokia Corporation. All rights reserved.