Библиотека сайта rus-linux.net
|Maximum RPM: Taking the Red Hat Package Manager to the Limit|
|Prev||Chapter 11. Building Packages: A Simple Example||Next|
cdplayer's spec file:
The a following the -b option directs RPM to perform all phases of the build process. Sometimes it is necessary to stop at various phases during the initial build to resolve problems that crop up while writing the spec file. In these cases, other letters can be used after the -b in order to stop the build at the desired phase. For this example however, we will continue through the entire build process.
In this example, the only other argument to the build command is the name of the package's spec file. This can be wild-carded to build more than one package, but in our example, we'll stick with one.
The output continues, but let's stop here for a moment, and discuss what has happened so far.
At the start of the output, RPM displays the package name
cdplayer), sets the umask, and starts executing
the %prep section. Thanks to the
%setup macro, RPM then changes directory into the
build area, removes any existing old sources, and extracts the sources
from the original compressed tar file. Although each file is listed as
it is extracted, we've omitted most of the files listed, to save space.
The %setup macro continues by changing directory into
cdplayer's top-level source directory and setting
the file ownership and permissions properly. As you can see, it does
quite a bit of work for you.
cdplayer's top-level directory, RPM issues the make command we put into the spec file. The rest of the output comes from make as it actually builds the software. Next comes the %install section:
cdplayer's install target, installing the newly built software on the build system. Those of you that carefully studied the spec file might have noticed that the
READMEfile is not part of the install section. It's not a problem, as we see here:
cdplayer's documentation directory. It then cleans out any preexisting directory and copies the
READMEfile into it. The
cdplayerapp is now installed on the build system. The only thing left to do is to create the actual package files, and perform some housekeeping. The binary package file is created first:
The first line says it all: RPM is creating the binary package for
cdplayer version 1.0, release 1. Next, RPM
determines what packages are required by
cdplayer-1.0-1. Part of this process entails
running ldd on each executable program in the
package. In this example, the package requires the libraries
libncurses.so.2.0. Other dependency information
can be included in the spec file, but for our example we'll keep it
Following the dependency information, there is a list of every directory
and file included in the package. The list displayed is actually the
output of cpio, which is the archiving software used
by RPM to bundle the package's files. The "
blocks" is also printed by cpio.
The line "
Generating signature: 0"
means that RPM has not been directed to add a PGP signature to the
package file. During this time, however, RPM still adds two signatures
that can be used to verify the size and the MD5 checksum of the package
file. Finally, we see confirmation that RPM has created the binary
In our example, there are no other files outside of the build directory
that are created during
cdplayer's build, so we
don't need to expend any additional effort to clean things up.
This file includes everything needed to recreate a binary package file, as well as a copy of itself. In this example, the only files needed to do that are the original sources and the spec file. In cases where the original sources needed to be modified, the source package includes one or more patch files. As when the binary package was created, we see cpio's output listing each file archived, along with the archive's block size.
Note that we built
cdplayer on an Intel-based
system, so RPM placed the binary package files in the
Everything went perfectly — we now have binary and source package files ready to use. But sometimes things don't go so well.