37.4.1 The DESCRIPTION File

The DESCRIPTION file contains various information about the package, such as its name, author, and version. This file has a very simple format

• Lines starting with ‘#’ are comments.
• Lines starting with a blank character are continuations from the previous line.
• Everything else is of the form NameOfOption: ValueOfOption.

The following is a simple example of a DESCRIPTION file

Name: The name of my package
Version: 1.0.0
Date: 2007-18-04
Author: The name (and possibly email) of the package author.
Maintainer: The name (and possibly email) of the current
 package maintainer.
Title: The title of the package
Description: A short description of the package.  If this
 description gets too long for one line it can continue
 on the next by adding a space to the beginning of the
 following lines.
License: GPLv3+

The package manager currently recognizes the following keywords

Name

Name of the package.

Version

Version of the package. A package version is typically digits separated by dots but may also contain ‘+’, ‘-’, ‘~’, and alphanumeric characters (in the "C" locale). For example, "2.1.0+" could indicate a development version of a package. Versions are compared using compare_versions.

Date

Date of last update.

Author

Original author of the package.

Maintainer

Maintainer of the package.

Title

A one line description of the package.

Description

A one paragraph description of the package.

Categories

Optional keyword describing the package (if no INDEX file is given this is mandatory).

Problems

Optional list of known problems.

Url

Optional list of homepages related to the package.

Depends

A list of other Octave packages that this package depends on. This can include dependencies on particular versions, with a format

Depends: package (>= 1.0.0)

Possible operators are <, <=, ==, >= or >. If the part of the dependency in () is missing, any version of the package is acceptable. Multiple dependencies can be defined as a comma separated list.

License

An optional short description of the used license (e.g., GPL version 3 or newer). This is optional since the file COPYING is mandatory.

SystemRequirements

These are the external install dependencies of the package and are not checked by the package manager. This is here as a hint to the distribution packager. They follow the same conventions as the Depends keyword.

BuildRequires

These are the external build dependencies of the package and are not checked by the package manager. This is here as a hint to the distribution packager. They follow the same conventions as the Depends keyword. Note that in general, packaging systems such as rpm or deb autoprobe the install dependencies from the build dependencies, and therefore a BuildRequires dependency usually removes the need for a SystemRequirements dependency.

The developer is free to add additional arguments to the DESCRIPTION file for their own purposes. One further detail to aid the packager is that the SystemRequirements and BuildRequires keywords can have a distribution dependent section, and the automatic build process will use these. An example of the format of this is

BuildRequires: libtermcap-devel [Mandriva] libtermcap2-devel

where the first package name will be used as a default and if the RPMs are built on a Mandriva distribution, then the second package name will be used instead.