Howto create "ipk" packages for the Zaurus
The Zaurus uses the ipk package format. iPKG is a very lightweight package
management system. It was designed for Linux installations with severe storage
limitations such as handheld computers. This howto provides the basic knowledge
on how to build an ipk.
Advanced features, history and a more detailed explanations of ipk can be found at http://www.handhelds.org/z/wiki/iPKG
1) What is the .ipk format?
An .ipk file is a gzipped tar archive containing 3 members:
./data.tar.gz contains the actual files belonging to this package. The contents
of this directory will be extracted to "/" (The root directory) when installed by ipkg. So it should contain entries such as ./usr and ./etc as top-level directory entries.
./control.tar.gz contains meta-data and scripts for the package. It must contain a file named control. It also may contain the following files: conffiles,
preinst, postinst, prerm, postrm. It may contain anything else for that matter,
but it wouldn't be useful at this time. See section 3 on Install scripts.
./debian-binary This file is currently ignored by ipkg. However, in all
current ipkgs it is a text file with a single line: 2.0
2) Building an ipk.
Here are the steps to make an example package called foobar that places
a file called "test.txt" in the /home/ directory on the Zaurus. You need the ipkg-build.sh script which comes with familiar and is mirrored
here. There is another script called "mkipks", but it is not recommended that it is used for it has several problems.
1) Create the directory structure and files as they should appear on the
installed system. For our example we create a dir called foobar. From
the standpoint of the ipk any file inside of foobar will be "/" so foobar/home/text.txt
will get installed to /home/text.txt on the Zaurus.
2) Create a directory named CONTROL at the top-level of this directory structure.
3) Inside CONTROL create a file named "control" with lines of the form "Field:
value". Required fields are Package, Version, Architecture, Maintainer, Section,
and Description. Optional fields include Priority and Depends.
Here is an example control file which can be used as a template:
### Begin CONTROL/control example
Maintainer: Familiar User firstname.lastname@example.org
Description: foo is the ever-present example program -- it does everything
foo is not a real package. This is simply an example.
When modifying this example, be sure to change the Package, Version,
Maintainer, Depends, and Description fields.
### End CONTROL/control example
The meaning of the various fields in CONTROL/control is as follows:
Package is the name of the package and should match the regular expression
Version should have at least one digit and should match [a-zA-Z0-9.+]*.
Version may also contain an optional trailing revision matching "-fam![0-9]\+".
This revision should be incremented each time the package changes but the
version does not, (ie. a packaging tweak). It may be reset, (or simply omitted),
each time the version is incremented.
Architecture should specify the architecture for which the package
is compiled. Valid values for Familiar currently include "arm" and "all".
Maintainer should be the name and email address of the person responsible
for maintaining the package, (not necessarily the author of the program).
Description should be a short, (less than 80 characters) description
of the program. It may also include a long description on subsequent lines,
(each indented by a single space character). Blank lines in the long description
may be indicated by a line consisting of a space character followed by a
period, ie " ."
Priority should be one of: required, standard, important, optional,
or extra. Most programs should use optional.
Section The catagory that best fits this type of package.
Games (Puzz-le, JavaChess, etc)
Multimedia (Graphics, video, audio, picture viewer, mp3 player, movie player)
Communications (KismitQt, Kinkatta, email, etc)
Settings (Backup tool, wireless settings app, tab manager, hidecf, etc) -
anything that modifies the system.
Utilities (password keeper, tip calc) - more often smaller apps.
Applications (Anything that couldn't fit in any of the above (more often then
nor procuctivity type apps)
// Doesn't have a tab, but needs a catagory.
Console (fdisk, kismit, perl, boa, apache, smb etc)
Misc (If it _can't_ go anywhere else such as the Zaurus faq )
SeverManager would go in Settings
Boa would go under Console
Depends indicates packages which must also be installed in order
for this package to work. The packages should be listed on a single line,
separated by commas.
4) If a package has any configuration files, then create a file CONTROL/conffiles
which lists the absolute path of each configuration file, (as it will appear
on the installed system), one per line. This will prevent the package management
system from automatically overwriting configuration changes when the user
upgrades the package.
5) If a special script is needed to be run at the start or end of the install, see section 3.
6) Now to make the new ipk simply run:
ipkg-build.sh directory [destination_directory]
where directory is the directory that has been created. The destination_directory is optional and defaults to the current directory. The ipkg-build.sh script performs several sanity checks on the package directory and should guide you through any problems.
3) Ipk Scripts
If needed, the package may include some scripts that will be involved
by the package maintenance system. There are four possible times a script
will be run: just before the package is installed, just after the package
is installed, just before the package is removed, and just after the package
is removed. These scripts are named preinst, postinst, prerm, and postrm and should be located
in the CONTROL directory. The scripts should return 0 on success, (a non-zero
return value from preinst will prevent the package from being installed --
this can be useful in rare situations). The scripts should not assume a tty is available
so they may not prompt the user.
Note that the variable PKG_ROOT is set to the root of the package
installation and can be used to refer to the packages contents in their installed
4) User Applications.
To have the application show up in the tabs of Qtopia it needs to add a
desktop file, binary, and icon. Continuing with the foobar example the
desktop file would be placed here:
and the file would look like this:
The binary and image would be place here:
Comment=Don't really do much, just an example.
The script starting the app needs to specify
This does the magic connecting Jeode to Qtopia, thusly giving a little
icon to bring the app to the foreground in the status bar. See the links page for a much more indepth Java Zaurus site.
4) Mime Type.
To add more MIME types to the system, use the qtopia-addmimetype command in a .postinst file. For example: qtopia-addmimetype type/subtype myextension
Note that Zaurus does not have this qtopia-addmimetype tool encluded, so you need to ship your application with this tool or just append the line of text to the file (i.e. echo "bla/txt" >> /home/QtPalmtop/etc/mime.types).