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
packages directory.
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-builder how 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:
.tar.gz, .tgz, .tar.bz2 and
.zip are 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 fetch node:
<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.list which is prefixed with deb-src to find
the build package, and deb to find build dependencies. (Defaults to http://ftp.debian.org/ etch main)<depends>…</depends> - overrides the
Build Depends in debian/control if the package author knows better
what packages are present/are needed for this build. For example, there's no
need to specify debhelper as it is implicitly available.TBC...
TBC...
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/sh and
starts from the working directory for the package, that is
build/packagename. Ideally the source would be created
in a directory named packagename-version.<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.
TBC...
<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,
such as 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 icon/package.
If a URL is specified it is copied to the icon/package file.
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 sharutils
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
package.
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
followed by -dev.
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.
<< Creating a new package Admin merge workflow >>
© Andrew Flegg 2007. Released under the Artistic Licence.