The DESCRIPTION File (GNU Octave (version 11.2.0))

#### 37.5.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 URL to the homepage or repository related to the package.

`Tracker`

  Optional URL to the bug tracker related to the package. It is highly encouraged that maintainers utilize a dedicated tracker for reporting issues related to the package’s functionality in order to keep Octave’s bug tracker at Savannah.org less bloated and solely for core Octave bug reports.

`Depends`

  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 `<`, `<=`, `==`, `>=` 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. This can be used to define a range of versions of a particular package:

      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)

`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.