Current wpkg Version: 0.5
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 |
Architecture[1]
mandatory |
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 ':' depends_list
depends_list:
depspec
| depspec ',' depends_list
depspec:
DEPNAME
| DEPNAME depversion
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.
|
Description[1]
mandatory |
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. |
Essential[1]
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. |
Maintainer
mandatory |
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.) |
Package[1]
mandatory |
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. |
Priority[1]
recommended |
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
|
ROOT_TREE 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.
|
Section recommended |
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
|
Sub-Packages
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:
<Package>-<Sub-Packages>_<version>_<architecture>.deb
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 .
|
Version mandatory |
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 |
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
start:
fields_and_comments
fields_and_comments:
field_or_comment
| field_or_comment fields_and_comments
field_or_comment
field_list
| variable_list
| comment
| nl // empty lines
field_list:
field
| field field_list
field:
name ':' value
| name ':' value extended_field
variable_list:
variable
| variable variable_list
variable:
name '=' value
| name '=' value extended_field
extended_field:
nl_value
| nl_value extended_field
nl_value:
nl space value
name:
letter_or_digit
| letter_or_digit name
letter_or_digit:
'A' through 'Z' case insensitive
| '0' through '9'
| '-'
value:
char
| char value
char:
any non-control character (' '..0x7E)
comment:
'#' char '\n'
space:
' '
| '\t'
nl:
'\n'
| '\r'
| '\r' '\n'
|