Maximum RPM (RPM):Building Packages: A Simple Example:EarthWeb Inc.-






-->
















Previous | Table of Contents | Next


Page 135




usr/doc/cdplayer-1.0-1
usr/doc/cdplayer-1.0-1/README
usr/local/bin/cdp
usr/local/bin/cdplay
usr/local/man/man1/cdp.1
93 blocks
Generating signature: 0
Wrote: /usr/src/redhat/RPMS/i386/cdplayer-1.0-1.i386.rpm



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, 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.
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.


At this point, the application has been built and the application's files have been
packaged. There is no longer any need for any files created during the build, so they may be removed.
In the case of the sources extracted into RPM's build directory, we can see that, at worst, they
will be removed the next time the package is built. But what if there were files we needed to
remove? Well, they could be deleted here, in the
%clean section:




+ umask 022
+ echo Excuting: %clean
Excuting: %clean
+ cd /usr/src/redhat/BUILD
+ cd cdplayer-1.0
+ exit 0



In this example, there are no other files outside the build directory that are created
during cdplayer's build, so we don't need to expend any additional effort to clean things up.


The very last step performed by RPM is to create the source package file:



Source Packaging: cdplayer-1.0-1
cdplayer-1.0.spec
cdplayer-1.0.tgz
80 blocks
Generating signature: 0
Wrote: /usr/src/redhat/SRPMS/cdplayer-1.0-1.src.rpm
#



This file includes everything needed to re-create 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


Page 136



cases where the original sources need 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.


Just like a binary package, a source package file can have a PGP signature attached to it. In
our case, we see that a PGP signature was not attached. The last message from RPM is to
confirm the creation of the source package. Let's take a look at the end products. First, look at the
binary package:



# ls -lF /usr/src/redhat/RPMS/i386/cdplayer-1.0-1.i386.rpm
-rw-r--r-- 1 root root 24698 Aug 6 22:22 RPMS/i386/cdplayer-1.0-1.i386.rpm
#



Note that we built cdplayer on an Intel-based system, so RPM placed the binary package
files in the i386 subdirectory.


Next, look at the source package file:



# ls -lF /usr/src/redhat/SRPMS/cdplayer-1.0-1.src.rpm
-rw-r--r-- 1 root root 41380 Aug 6 22:22 SRPMS/cdplayer-1.0-1.src.rpm
#



Everything went perfectly—we now have binary and source package files ready to use.
But sometimes things don't go so well.



11.5. When Things Go Wrong


This example is a bit of a fairy tale in that it went perfectly the first time. In real life, it
often takes several tries to get it right.



11.5.1. Problems During the Build


As alluded to earlier in the chapter, RPM can stop at various points in the build process.
This allows package builders to look through the build directory and make sure everything is
proceeding properly. If there are problems, stopping during the build process permits them to
see exactly what is going wrong and where. Here is a list of points at which RPM can be
stopped during the build:



After the
%prep section
After doing some cursory checks on the
%files list
After the
%build section
After the
%install section
After the binary package has been created


In addition, there is a method that permits the package builder to short-circuit the build
process and direct RPM to skip over the initial steps. This is handy when the application is not
yet


Page 137



ready for packaging and needs some fine-tuning. This way, once the package builds,
installs, and operates properly, the required patches to the original sources can be created and
plugged into the package's spec file.



11.5.2. Testing Newly Built Packages


Of course, the fact that an application has been packaged successfully doesn't necessarily
mean that it will operate correctly when the package is actually installed. Testing is required. In
the case of our example, it's perfect and doesn't need such testing. (As we said, it's a fairy tale!)
But the following paragraphs explain how testing would proceed.


The first step is to find a test system. If you thought of simply using the build system, try
again! Think about it—in the course of building the package, the build system actually had the
application installed on it. That is how RPM gets the files that are to be packaged: by building
the software, installing it, and grabbing copies of the installed files, which are found using the
%files list.


Some of you dissenters who have read the first half of the book might be wondering why
not just install the package on the build system using the
--replacefiles option. That way, it'll just blow away the files installed by the build process and replace them with the packaged
files. Well, you folks get a bzzzzt, too!


Say, for example, that the software you're packaging installs a bunch of files—maybe 100.
What does this mean? Well, for one thing, it means that the package's
%files list is going to be quite large. For another thing, the sheer number of files makes it likely that you'll miss 1 or 2.
What would happen then?


When RPM builds the software, there's no problem: The software builds and the
application's makefile merrily installs all the files. The next step in RPM's build process is to collect the
files by reading the %files list and to add each file listed to a
cpio archive. What happens to the files you've missed? Nothing. They aren't added to the package file, but they are on your build
system, installed just where they should be.


Next, when the package is installed using
--replacefiles, RPM dutifully installs each of the packaged files, replacing the ones originally installed on the build system. The missed
files? They aren't overwritten by RPM since they weren't in the package. But they're still on
disk, right where the application expects them to be! If you go to test the application then, it
will find every file it needs. But not every file came from the package. Bad news! Using a
different system on which the application had never been built is one sure way to test for missing files.



11.6. Summary


That wraps up our fictional build. Now that we have some experience with RPM's build
process, we can take a more in-depth look at RPM's build command.



Previous | Table of Contents | Next