A spec file may define more than one package. This type of additional package is called a subpackage. Subpackages exist to handle cases where you don’t want to associate one spec file with one package. Instead, you can define multiple packages within the spec file, as needed. For example, you may want to build the runtime and developer packages together, or the client and server portions of an application using subpackages. Splitting large documentation sets into separate subpackages is also common.

With subpackages, you get:

*One spec file

*One source RPM

*One set of build commands

*Multiple binary RPMs, one per package or subpackage

In most cases, subpackages are created just as a means to partition the files produced by a package into separate packages. For example, you will often see development libraries and header files split into a separate package from the main application package. Sometimes documentation is split out into a separate package, or client and server applications are divided into separate packages. In the end, though, this usually results in shifting files into subpackages and nothing more.

To define a subpackage within a spec file, you start with the %package directive. For example:

%package sub_package_name

By default, the name of the subpackage will be the name of the package, a dash, and the subpackage name provided with the %package directive. For example:

%package server

This example names a subpackage server, which is a real subpackage inside the telnet package. In this case, the name for the server subpackage will be telnet-server, that is, the naming format is package-subpackage.

If you don’t want this naming format, you can use the –n option to the %package directive to define an entirely new name, using the following syntax:

%package -n new_sub_package_name

For example:

%package –n my-telnet-server

With the –n option, you specify the full name for the subpackage. The RPM system will not prefix the name with the enclosing package name.