Unix/GNU Windows

By Alexis Wilke
Started in Dec. 2006
   Home       Documentation       Download       Bugs   


Change Log

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 --build 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 alphabetical order.

Field Comment
wpkg supports:
  • win32-i386
  • any
  • all
  • source
Trying to install or build a package with another architecture will fail with an error.

The --build option manages an architecture of source 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 be wpkg_0.5_src.deb.
Bugs URL to a page where bugs in link with this package can be reported.
Build-Depends[1] Binary dependencies required to build (i.e. compile) this package. This is the same as the Depends field but for developers.
Rational: 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.

WARNING: This is ignored by version 0.5 of wpkg.
Conflicts[1] 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.
Depends[1] 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.
# Example
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.)
Installed-Size[1] 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 --directory-size <path> 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 field.
The name and email address of the maintainer of this package. For example:
	Alexis Wilke (alexis_wilke@sourceforge.net)
Origin 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.
Pre-Depends[1] 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 Depends field.
One of:
  • required (cannot be removed with wpkg)
  • important
  • standard
  • optional
  • extra
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.
Provides[1] 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:
Depends: mail-server
If the packages providing the mail server define a Provides field like this:
Provides: mail-server
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 ROOT_TREE=packages, 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 current directory.
The Section field describes what this package is used for. The currently valid section names are: [To Be Determined! these are from Debian]
  • admin
  • base
  • comm
  • contrib
  • devel
  • doc
  • editors
  • electronics
  • embedded
  • games
  • gnome
  • graphics
  • hamradio
  • interpreters
  • kde
  • libs
  • libdevel
  • mail
  • math
  • misc
  • net
  • news
  • non-free
  • oldlibs
  • otherosfs
  • perl
  • python
  • science
  • shells
  • sound
  • tex
  • text
  • utils
  • web
  • x11
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. For instance:

  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 totally ignored.

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 src.
Specify the exact version of the package content. The format is [epoch:]source_version[-revision].
More about versions.
X-Source URL to the source tarball

[1] This field can be made specific to a sub-package by appending the sub-package name after a foreward slash (/). For instance, if you have a doc sub-package, you can write:

  Architecture/doc: any

meaning that the doc sub-package has no architecture specific requirements. See the info file definition for more information.

Control file grammar

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 100% compatible!

This information is based on the dpkg definitions: 5.3 Binary package control files -- DEBIAN/control


	| field_or_comment fields_and_comments

	| variable_list
	| comment
	| 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'

	  ' '
	| '\t'

	| '\r'
	| '\r' '\n'