Wpkg can build multiple packages from a single tarball
using a single .info file (read "a dot info file".) A .info file is similar
to a control file except that it can represent any number of packages whereas
a control file is specific to one package.
The idea of using a .info file with wpkg is based
on the .info file as used by the
However, the syntax to define sub-packages is quite different.
The .info file includes all the usual
control file fields plus the
Sub-Packages field which, in a .info file, is mandatory (and it is
forbidden in a valid control file.)
The list of sub-packages can include one name followed
by an asterisk (i.e. shlibs* or runtime*) and any number of other names.
The name followed by an asterisk does not appear in the mangled name of
the output package. The order is not important. The sub-package names
are limited to the same characters as a Package name, including the
first character limit (i.e. [A-Za-z0-9][A-Za-z0-9+-.]*). Yet, a sub-package
name can be 1 character if it makes sense to you. Each sub-package name
must be unique.
Usual sub-package names:
Some of the fields in a .info file can be made specific
to a sub-package by appending a foreward slash (/) and the name of the sub-package
at the end of the field name. For instance, the Description field can be made
specific to each sub-package as follow:
Sub-Packages: runtime*, doc, devel
Description: This is my project to do Foo
Description/doc: My project documentation, read it please!
Description/devel: If you're a programmer, you'll need this one too.
Notice that for some fields, it is an error to try to make
them sub-package specific. For instance, the Version field just cannot be specific
to a sub-package. The same version always applies to all the sub-packages. The fields
that can be made specific to a sub-package are marked with a  in the
control file documentation page.
To get everything ready, you need to create a directory
structure that wpkg will stick in the sub-packages. This is very similar
to the usual structure created for a Debian package with one additional level
so as to separate the different files according to the sub-package definitions.
Say your project includes three sub-packages, one for users
and two for developers as follow:
for the .dll, .exe and corresponding manual pages;
for the developer documentation; and
for the .a and .h files.
Then create a directory named package (that name can
be anything, really) and place in it three sub-directories named runtime, doc and
devel. Finally, place your files in sub-directories as required for your project.
# Runtime sub-package
# Documentation sub-package
# Development sub-package
The lack of /usr/ in these directories reflects the lack
of that directory in MinGW. Really, any valid tree will
work just fine with wpkg. Don't forget that wpkg
transforms /usr into /mingw when installing a package.
Assuming that you are in the parent directory of the
package directory and that a file named wpkg.info exists in that directory,
you can type the following command to generate the three packages:
wpkg --build wpkg.info package/
With wpkg.info file defined as follow:
Sub-Packages: runtime*, doc, devel
Description: The package manager for the MinGW environment
Description/doc: Documentation for the package manager developers
Description/devel: Extra libraries to link the package manager
The output will be three .deb files named as
Notice that the documentation package has no
architecture specified. Also the documentation and development
packages got the extra -doc and -devel respectively. The runtime
package did not get -runtime since that sub-package name was
followed by an asterisk.
It is possible to define a specific Package
field for each sub-package in which case the name up to the first
underscore will be what you specify and not the automatically
generated name (<Package name>-<Sub-Packages name>).
It is advised, however, that you do not use this feature.