octave: The DESCRIPTION File

 
 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 must be 3 numbers
      separated by dots.
 
 ‘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 either as a comma
      separated list or on separate ‘Depends’ lines.
 
 ‘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.