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)">
<icon>URL</icon>
<version>…</version>
<description>
short description\nlong description
</description>
<section>section name</section>
<library>library package name</library>
<libdev>library development package name</libdev>
<maintainer>Some Name <email@address></maintainer>
…
</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. 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.
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).
<< Creating a new package Admin merge workflow >>
© Andrew Flegg 2007. Released under the Artistic Licence.