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.
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*
Much as you define separate %files and %description sections for subpackages, you can also define install and uninstall scripts for subpackages. The syntax is similar to that for the %files and %description sections:
%pre subpackage
For example, Listing 11-2 shows the scripts from the VNC package.
Listing 11-2: VNC package install and uninstall scripts.
%post server
if [ "$1" = 1 ]; then
/sbin/chkconfig --add vncserver
fi
%preun server
if [ "$1" = 0 ]; then
/sbin/service vncserver stop >/dev/null 2>&1
/sbin/chkconfig --del vncserver
fi
%postun server
if [ "$1" -ge "1" ]; then
/sbin/service vncserver condrestart >/dev/null 2>&1
fi
The build sections in the spec file serve double duty. These sections are used for building the main package as well as subpackages. This is one reason why there are so many options on the %setup macro.
The %setup macro allows for selectively unpacking the sources, rather than the default option of unpacking all the sources. For example, the following %setup macro definition gives rpmbuild specific instructions for unpacking one source file:
%setup –D- T –a 1
In this example, the –D option disables the automatic deletion of the directory where the sources will be unpacked. This means any previous contents of this directory, perhaps for other subpackages, will be left alone. The –T option disables the automatic unpacking of the source files, and the –a 1 option specifies to only unpack the first source file. You may need to use options like these when working with subpackages. Though, in most cases, subpackages are just means to partition the package files into separate packages. In cases like this, you will likely not need any of these special %setup options.
Cross Reference
Chapter 10 covers the %setup macro and lists the available options.