The DESCRIPTION file contains various information about the package, such as its name, author, and version. This file has a very simple format
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 of the package.
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 of last update.
Original author of the package.
Maintainer of the package.
A one line description of the package.
A one paragraph description of the package.
Optional keyword describing the package (if no INDEX file is given this is mandatory).
Optional list of known problems.
Optional list of homepages related to the package.
A list of other Octave packages that this package depends on. This can include dependencies on particular versions, with the following format:
Depends: package (>= 1.0.0)
Possible operators are
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. This can be used to define a range of versions of a particular
Depends: package (>= 1.0.0), package (< 1.5.0)
It is also possible to depend on particular versions of Octave core:
Depends: octave (>= 3.8.0)
An optional short description of the used license (e.g., GPL version 3 or newer). This is optional since the file COPYING is mandatory.
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
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
deb autoprobe the
install dependencies from the build dependencies, and therefore a
BuildRequires dependency usually removes the need for a
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
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.