Unix/GNU Windows

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


Change Log

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 fink project. 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:

  • bin
  • lib
  • shlibs
  • runtime
  • devel
  • doc
  • src

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 [1] 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:

  • runtime*
  • for the .dll, .exe and corresponding manual pages;

  • doc
  • for the developer documentation; and

  • devel
  • 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. For instance:

	# Runtime sub-package

	# Documentation sub-package

	# Development sub-package
NOTE: 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:

	Package: wpkg
	Sub-Packages: runtime*, doc, devel
	Architecture: win32-i386
	Architecture/doc: any
	Version: 0.5
	Maintainer: alexis_wilke@sourceforge.net
	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 follow:


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.