The package file describes where to get the application's source and how to
package it for Maemo. It is a simple XML file in in the
The name of the file should correspond to the Debian guidelines: all lower case, with dashes, underscores, dots and numbers also permissible. The smallest possible file is:
<package> <fetch type="debian"/> </package>
This will download the source of the Debian package named the same as the MUD package from the default (currently "etch") and build it, without overriding any of the defaults. Obviously, however, this is not suitable for all packages and so more flexibility is possible.
The complete file is divided into three sections, only one of which is required, and has the following outline:
<package> <fetch type="…"> … </fetch> <build> <result>single</result> <copyright>gpl</copyright> <include>examples,man</include> … </build> <deb> <icon>http://www.example.com/logo.png</icon> … </deb> </package>
As can be seen, the three sections are:
mud-builderhow to download the package. Plugin-specific options, such as the location of the source, are specified here. This element is mandatory.
<fetch type="plugin"> … </fetch>
The content of this tag is entirely dependent on the plugin chosen:
.zipare supported file extensions). This is downloaded and unpacked in the build directory.
/bin/sh. This command should unpack the source in an appropriate subdirectory. This will be most used for CVS or Subversion exports.
The Debian fetcher is designed to fetch the source of one of the thousands of packages packaged
and supported by the Debian distribution. It supports the following child
elements of the
<name>…</name>- the name of the package in Debian. (Defaults to the name of the MUD package)
<deb-src>…</deb-src>- the line in
sources.listwhich is prefixed with
deb-srcto find the build package, and
debto find build dependencies. (Defaults to
http://ftp.debian.org/ etch main)
<depends>…</depends>- overrides the Build Depends in
debian/controlif the package author knows better what packages are present/are needed for this build. For example, there's no need to specify
debhelperas it is implicitly available.
The command fetcher is very basic: it relies on a given command - or sequence
of commands - to provide the source in the appropriate build directory. It
supports the following child element of the
fetch node only:
<command>…</command>- the shell script to be executed to fetch the time. It is executed using
/bin/shand starts from the working directory for the package, that is
build/packagename. Ideally the source would be created in a directory named
<build> <result>(single|multiple|library)</result> <copyright>(gpl|lgpl|artistic|bsd)</copyright> <include>(changelogs|docs|examples|info|man)*</include> <configure-append>…</configure-append> <env> <SOMEOPT>true</SOMEOPT> <PATH>/usr/sbin:$PATH</PATH> </env> </build>
Out of all of the sections, this is the "most" optional: for many packages all of the information here will be determined automatically, from the package licence, to whether a single, multiple or library-style packages should be produced. However, if the auto-detection fails, or there is a need to override the defaults, that power is available.
<deb prefix-section="(0|1)" optify="(0|1)"> <icon>file or URL</icon> <version>…</version> <description> short description\nlong description </description> <description file="filename"/> <section>section name</section> <library>library package name</library> <libdev>library development package name</libdev> <maintainer>Some Name <email@address></maintainer> <upgrade-description> short description for upgrade\nlong description for upgrade </upgrade-description> <upgrade-description file="filename"/> <display-name>Application name</display-name> <bugtracker>URL</bugtracker> … </deb>
Most of the child elements of the
deb node correspond to fields
within the debian/control,
allowing you to change their value without patching the file.
The capitalised tag name is used as the field name, and the value is used as
the content. Multi-line entries can be entered, such as the description, by entering
\n within the text.
The description should contain two parts: the synopsis at around 60 characters, and the extended description over several lines following it. It can either be specified as text in the value of the tag or a filename can be specified as an attribute.
The section will be automatically prefixed with
user/, if not already by mud-builder unless the
prefix-section attribute is set to
0, or a section is specified explicitly. Packages which
end-users can install directly (rather than libraries) are prefixed like this,
according to the Maemo packaging guide. In addition,
certain sections are recommended, if possible:
Other sections should have the second word capitalised,
user/Fonts A selection of third-party sections is available in the Maemo.org wiki.
The icon can either be used to specify a file in the package source directory
(note the file must be available before the package is built) or a URL
and it defaults to
If a URL is specified it is copied to the
If the icon file exists, it is resized (using the
convert program) to 26x26
and is specified as the Application Manager icon for the package
(using the XB-Maemo-Icon-26 field in the control file).
Note: this requires that the
uuencode program is installed -- this can be found in the
package in the Maemo SDK.
There are two tags designed for use when creating library packages: library and libdev.
These can be used to specify the package names used for the library package itself and the development
library is the name to be used for the library package: it defaults to the name of the package file but
is useful when the name has to be modified in some way (for example to append the major id number).
libdev is similarly used to rename the development package: it defaults to the name of the package file
The maintainer tag should be used to specify the name and email address of the maintainer of the maemo package (which is not likely to be the maintainer of the upstream package).
The upgrade-description tag is used to specify different description text to be displayed by the
Application Manager when the package is being upgraded (the normal description text is used for
the first installation of a package). The value should be specified in the same way as for the description tag.
This corresponds to the
XB-Maemo-Upgrade-Description control file field.
The display-name tag is used to specify the name the Application Manager should display to the user instead of the
package name. This corresponds to the
XB-Maemo-Display-Name control file field.
The bugtracker tag is used to specify the URL of where bugs may be logged.
This currently corresponds to the
Xsbc-Bugtracker control file field.
The optify attribute tells MUD to add the
maemo-optify script to debian/rules and to add
maemo-optify as a build dependency. This is a process used in Maemo Fremantle to move large files to the /opt partition to save
space on the user's root partition.