The following table describes the fields and variables
currently understood by wpkg. It also includes those reserved for later
versions of wpkg. The order of the fields is not important.
You will find the
complete control file grammar
as supported by wpkg at the bottom of this page. However, there is a
brief overview of what is supported in this file format:
- Empty lines (ignored)
- Comments (ignored)
- Fields; a name followed by a colon (:) and an optional value
- Variables; a name followed by an equal (=) and an optional value
Long field and variable lines are supported.
To continue a field or a variable on the following lines, hit enter
and put at least one space before the content. This can be done on
any number of lines as required.
Not standard for debian control files,
wpkg supports empty lines and comments introduced with
the # character. If you use the
command with wpkg, empty lines and comments will be removed
before saving the control file in the binary package. This ensures
better compatibility. As a side effect, the fields are saved in
Trying to install or build a package with another architecture will
fail with an error.
The --build option manages an architecture of
in a special way when it comes to automatically name an output
package. A source package gets
src as its architecture
in the filename. For instance, for the wpkg project it would
||URL to a page where bugs in link with this package
can be reported.
||Binary dependencies required to build (i.e. compile) this
package. This is the same as the Depends
field but for developers.
No other source package can be required. This makes sense since header
files, static and dynamic libraries are put in binary packages with
the -devel added to the package name. Also it would not make sense
that you'd need to include files from the source directory of another
package without having to install that package first.
This is ignored by version 0.5 of wpkg.
||Defines the list of packages that cannot be installed
at the same time as this one. For instance, there are two regex libraries
one from Spencer and one from GNU. Both define the same POSIX header file:
regex.h and thus both cannot be installed simultaneously (and since both
offer the same functionality, it would not be necessary to have both at
once.) This Conflicts field can be used to make sure both packages
cannot be installed simultaneously.
||Dependencies required to install this package
on your system. The installation of a package fails until all
of of its dependencies are satisfied. In general these are
binary dependencies, yet it is possible for a documentation
or other non-binary package to reference another.
The syntax of this field is a list of library names separated
by commas and optionally followed by a version between parenthesis.
The version number can be preceeded by a comparison operator.
There is no comparison for a range. If you want to support only
a library within only a small range of versions, then you need to
define the lower bound and the higher bound separately.
Depends: libz (>= 1.2.3), jpeg (= 6b),
png (>= 1.2.3), png (< 2.0)
The following is the full grammar for this entry:
DEPENDS ':' depends_list
| depspec ',' depends_list
| DEPNAME depversion
'(' VERSION ')'
| '(' '<<' VERSION ')'
| '(' '<=' VERSION ')'
| '(' '>>' VERSION ')'
| '(' '>=' VERSION ')'
| '(' '=' VERSION ')'
The version comparisons are strictly equal (=), strictly earlier (<<),
strictly later (>>), earlier or equal (<=) and later or equal (>=).
By default, when no operator is specified, it is assumed that later or
equal (>=) was specified.
|Describe the package on one short line (max. about 70 chars)
followed by a long description. The long description must start on the
next line. The long description is optional.
required if yes
|This flag is a boolean value, which by default is assumed to be
set to no. When set to yes, the corresponding package cannot be
removed. In general, this is used for system packages that cannot be removed
without breaking your system (in which case you could as well delete the
whole directory tree.)
||The size in kilobytes (1024 bytes round up) written in decimal of
the amount of disk space necessary to install the files from this package.
One can use wpkg with
or the dirsize tool to define this size.
When using the --build
option, the Installed-Size field is automatically added if not already
defined. It is strongly suggested that, unless you do some magic such as
create large files in a postinst script, you let wpkg define this
|The name and email address of the maintainer of this package.
Alexis Wilke (email@example.com)
||The name of the project where the source comes from
(UniGW, GNU, Debian, Gnome, etc.)
|Specify the exact name of the package. Any package name
can include letters [a-zA-Z], digits [0-9], plus (+), minus (-) and
periods (.). It must start with a letter or a digit and be at least
2 characters. It is prefered to use an English name for packages
to be used worldwide.
||Name of the packages that must be installed and configured before
this package can be installed at all. Otherwise, this is the same as the
wpkg is a required package. It is the minimum package necessary
to run wpkg properly and add new software to your environment.
Some of the MSYS packages are marked important (so your configure scripts
function) or standard (these are not required for a configure script to
work.) Most of the gnuwin32 packages are marked optional unless they
are used by most of the other software (i.e. gettext) in which case
they are marked standard. Those packages that conflict with any
others are marked extra. This means you may have to remove some other
packages to install a given extra package.
- required (cannot be removed with wpkg)
||The name following the Provides field must follow the same rules
the name of a Package follows. This can
later be used as the name of a package in the
Depends fields of another package as long
as no version is specified.
In general, it is used when two completely different projects offer exactly
the same functionality. The most common example are two packages offering
a mail server. The Depends field can be written like this:
If the packages providing the mail server define a Provides field like this:
info file variable
|The ROOT_TREE variable can be used in a .info file to specify
the directory where the files to be packaged are. It is possible to specify
the path to the root tree on the command line in which case the ROOT_TREE
variable is ignored.
When the variable ROOT_TREE is not an absolute path, it is taken as a local
path from the directory where the .info file is located (i.e. if you create
C:\MyProject\fields.info and have a
then the root is expected to be:
C:\MyProject\packages). This is
different from a local path on the command line that is instead taken from the
|The Section field describes what this package is used for. The
currently valid section names are:
[To Be Determined! these are from Debian]
mandatory in info files,
forbidden in control files
|This field is used to list all the sub-packages that wpkg needs to create.
It is part of the info file and not the control file. If it appears in a control file,
wpkg fails creating the package. Each sub-package name must be separated by a comma.
Sub-Packages: runtime*, devel, doc, src
The sub-package names are used to generate the mangled name of a package:
The Sub-Packages name is not used when it ends with an asterisk. In that case it is
There is one other case when the mangling is different: when the Architecture is set to
source. In that case, the Package name is used and the <architecture>
part of the name is set to
|Specify the exact version of the package content. The
format is [epoch:]source_version[-revision].
More about versions.
||URL to the source tarball
This section is highly technical and it should only
interest developers who want to create tools parsing control files as supported
by wpkg. Though, in the next version of wpkg (0.6, I hope) you
will be able to use the libdebpackages.a library instead. That way you will be
This information is based on the dpkg definitions:
5.3 Binary package control files -- DEBIAN/control
| field_or_comment fields_and_comments
| nl // empty lines
| field field_list
name ':' value
| name ':' value extended_field
| variable variable_list
name '=' value
| name '=' value extended_field
| nl_value extended_field
nl space value
| letter_or_digit name
'A' through 'Z' case insensitive
| '0' through '9'
| char value
any non-control character (' '..0x7E)
'#' char '\n'
| '\r' '\n'