Sub-Package (.info file)

This field is used to define the list of sub-package names in a control.info file.

Common Sub-Package names are: runtime, dev, src, doc. These are all the packages that you want to create from your project. One of those names can be followed by an asterisk. This asterisk indicate that this Sub-Package name is not to be used in the output filename. This is most often used with the runtime name:

Sub-Package: runtime*, dev, doc
Package: my-package

results in 3 packages:

my-package_<version>_win32-i386.deb  (instead of my-package-runtime_<version>_win32-i386.deb)
my-package-dev_<version>_win32-i386.deb
my-package-doc_<version>.deb

Important: Note that does not apply to source packages (-src or -source is never added to the package name.) Also, if you define a Package/<name>: ... field, then that Package field value is used instead. In other words, you can always force the name of your package.

These names can then be used with other fields such as the Architecture field:

Architecture/runtime: win32
Architecture/doc: all

The different fields that support the sub-package name are marked as such1. At this point the following fields cannot be used with a sub-package name:

• Bugs
• Maintainer
• Origin
• Section
• Sub-Package
• Version
• X-Source

Note that fields with sub-package names that do not match a name defined in the Sub-Package field are ignored.

The field name by itself represents the default value. Thus, if only the following are defined, the runtime would use the default of win32:

Architecture/doc: all
Architecture: win32

However, a field that is required and has no default and no specific definition will be considered missing. So if you have a definition for runtime, another for doc (as in our first example) and also defined a dev version in the Sub-Package field, the build process will return an error because it won't know what to use as the Architecture of the dev package.

Note that this field is mandatory in a control.info file and forbidden in a regular control file.

• 1. Note that we considered doing the opposite as a small set of fields do not support the Sub-Package name and all others accept it. But it seemed better to use a positive link. Note that user defined fields support the Sub-Package name capability.