10.4. Creating Subpackages
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.
10.4.1. Providing information for subpackages
When you define a subpackage, you need to provide as many of the package information directives as you need, including at the least Summary:, Group:, and %description directives. Anything not specified will use the parent package’s value, such as the version. Place these directives after the %package directive. For example:
%package server
Requires: xinetd
Group: System Environment/Daemons
Summary: The server program for the telnet remote login protocol.
The %description directive for subpackages requires the name of the subpackage using the following syntax:
%description subpackage
For example:
%description server
Telnet is a popular protocol for logging into remote systems
over the Internet. The telnet-server package includes a telnet daemon that supports remote logins into the host machine. The
telnet daemon is enabled by default. You may disable the telnet
daemon by editing /etc/xinetd.d/telnet.
If you used the –n option with the %package directive, you need to repeat the –n option with the %description directive. For example:
%description –n my-telnet-server
Telnet is a popular protocol for logging into remote systems
over the Internet. The telnet-server package includes a telnet daemon that supports remote logins into the host machine. The
telnet daemon is enabled by default. You may disable the telnet
daemon by editing /etc/xinetd.d/telnet.
The same concept works for the %files section. You need a separate %files section for each subpackage. For example:
%files server
%defattr(-,root,root)
%{_sbindir}/in.telnetd
%{_mandir}/man5/issue.net.5*
%{_mandir}/man8/in.telnetd.8*
%{_mandir}/man8/telnetd.8*
Again, if you used the –n option with the %package directive, you need to repeat the –n option with the %files section. For example:
%files –n my-telnet-server
%defattr(-,root,root)
%{_sbindir}/in.telnetd
%{_mandir}/man5/issue.net.5*
%{_mandir}/man8/in.telnetd.8*
%{_mandir}/man8/telnetd.8*