IPKG Howto

From OESF

Current revision

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://handhelds.org/moin/moin.cgi/Ipkg

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

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.

 foobar/home/text.txt

2. Create a directory named CONTROL at the top-level of this directory structure.

 foobar/home/text/txt
 foobar/CONTROL/

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.

 foobar/home/text/txt
 foobar/CONTROL/control

Here is an example control file which can be used as a template:

 ### Begin CONTROL/control example
 Package: foobar
 Priority: optional
 Section: Misc
 Version: 0.1
 Architecture: arm
 Maintainer: Familiar User famuser@foo.org
 Depends: libc6
 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 [[a-z0-9. -]\

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 )

Example: 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.

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 locations.

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:

 foobar/opt/!QtPalmtop/apps/Applications/foobar.desktop

and the file would look like this:

 [Desktop Entry]
 Comment=Don't really do much, just an example.
 Exec=foobar
 Icon=foobar
 Type=Application
 Name=FooBar

The binary and image would be place here:

 foobar/opt/QtPalmtop/bin/foobar
 foobar/opt/QtPalmtop/pics/foobar.png

For Java: The script starting the app needs to specify

 -!XappName=$0

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.

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).