Библиотека сайта rus-linux.net
| Maximum RPM: Taking the Red Hat Package Manager to the Limit | ||
|---|---|---|
| Prev | Chapter 11. Building Packages: A Simple Example | Next |
Starting the Build
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 README
file 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 README
file into it. The cdplayer app 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
libc.so.5, and
libncurses.so.2.0. Other dependency information
can be included in the spec file, but for our example we'll keep it
simple.
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 "93
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
package file.
|
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
i386 subdirectory.
|
Everything went perfectly — we now have binary and source package files ready to use. But sometimes things don't go so well.