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