Making Source RPMs Work

A key feature of Linux is the easy accessibility to the source code. Since Red Hat Linux is built on RPM packages, that means access to the source RPMs (SRPMs). An SRPM includes the code and instructions needed to build abinary RPM, which you can then install on your Red Hat Linux computer.

Processing source code now requires the rpm-build RPM package. While the rpm command still provides legacy support for managing SRPMs, you ll need to use the rpmbuild command for this purpose in the future.

To understand how to use a source RPM, you need to know the default directory structure and understand that .spec files are used to build a binary RPM.


By convention, SRPMs are easy to identify; they have the .src.rpm extension. SRPMs include specification and other files, which you can set up in various /usr/src/redhat subdirectories. Any SRPM that you build into a binary file is also set up in the same directory structure. The five key SRPM directories are shown in Table 10.2.

Table 10.2: Source RPM Directories




Any source code that you process is unpacked and built here.


Binary RPMs that you create from an SPRM are found here.


Contains the actual source code.


Includes the files that control the RPM build process.


Includes SRPMs created during the build process.

To break an SPRM down into these directories, you need to install it. For example, if you want to work with the anonftp package, you ll need to install the associated .src.rpm file. For example, if you ve mounted an SRPM Red Hat CD, you might use the following command:

 # rpm -i /mnt/cdrom/RedHat/SRPMS/anaconda-*.src.rpm 

The Spec File

The key to managing an SRPM is in its spec file. Once you ve installed an SRPM, you should be able to find its spec file in the /usr/src/redhat/SPECS directory. This file controls how packages are built, and configures commands when an RPM is installed or deleted.

The key sections in a spec file are %prep , %build , and %install . They allow you to build source and binary RPMs. One important variable is Requires or BuildRequires , which lists other packages that you should install first. Other typical sections in a .spec file include:

%define Includes basic parameters such as the location of the top-level directory for that package. For example, you might see a ROOT /var/ftp line in this section. The section includes basic summary information for the RPM. When this RPM is installed, this is what a user will see in response to the rpm -qi packagename command.

%package Lists packages that depend on this particular RPM.

%description Provides more information for the rpm -qi packagename command.

%prep Includes preparation commands for archives and patches.

%setup Contains processing commands for unpacking archives.

%build Builds the code to be compiled.

%install Adds the commands that actually build the files and install the package in well-defined directories.

%clean Includes basic commands for deleting any intermediate files from your system.

%post Contains post-installation scripts, such as a script that modifies a user account.

%postun Contains scripts after you remove a package.

%pre Contains pre-installation scripts, such as a script that prepares a directory.

%preun Contains scripts before you remove a package.

%triggerin Contains parts of other packages you ve copied .

%config Lists configuration files for /etc .

Spec files are not as difficult as they may look. For the most part, they include regular Linux commands and descriptions, which you can modify in a text editor.

Building Binaries from a Tarball

You can create an RPM from a tarball. But first, you need a spec file. As you ve seen in the previous section, this can be a little difficult.


A tarball is a single file that is a package, or an archive, of a group of files. When you unpack a tarball, the files in the package are copied to the computer. In that way, a tarball is similar to a Microsoft Windows compressed zip file archive. Tarballs are typically available in a compressed format, with extensions such as .tar.gz , .tgz , and .tar.bz2 .

One way to learn more about this process is to read different spec files. For example, take the following excerpts from a dosemu .spec file:

 %define vimver 5.8 %define vim vim58 Summary: A DOS emulator. Name: dosemu Version: 1.1.1 Release: 3 Exclusivearch: %{ix86} License: distributable Group: Applications/Emulators Source0:{version}.tar.bz2 Patch0: dosemu-0.66.7-config.patch %package -n xdosemu Requires: dosemu = %{PACKAGE_VERSION} Summary: A DOS emulator for the X Window System. Group: Applications/Emulators 

This file was taken from a dosemu-*.src.rpm package. The system is fairly straightforward; from the code, you can find the release version, the URL for the source and related patch(es), and the summary description. You can also see that the xdosemu package requires dosemu , which sets up an RPM dependency.

Building a Binary RPM

All you need to create a binary RPM is the source code (which you can get from a source RPM or a tarball) and a spec file. You can create a spec file from scratch, or modify an existing spec file from a source RPM.

There are two basic ways to build a binary RPM:

 # rpmbuild -ba packagename.spec # rpmbuild -bb packagename.spec 

The first command ( rpmbuild -ba ) creates binary and source RPM packages. The second command ( rpmbuild -bb ) creates only the binary RPM package.


The rpm -ba and rpm -bb commands no longer work starting with Red Hat Linux 9. Their functionality has been moved to the rpmbuild command, from the rpm-build-* RPM.


RPM Security

Once you ve learned to use RPMs, it s easy to become too dependent. A cracker might post a virus or a Trojan horse on an RPM posted online. The rpm command includes ways to check the integrity of an RPM, using the Pretty Good Privacy (PGP) system (see the next section). You can also verify the contents of a package, or even a specific file.

RPM and Pretty Good Privacy

The RPM system uses one of the security standards associated with e-mail security, known as Pretty Good Privacy (PGP). Developed by Phil Zimmerman, PGP provides a private- and public-key system. With Red Hat Linux, the GNU way of using PGP is known as the GNU Privacy Guard (GPG).

The key to all of this is the Red Hat GPG key. It should be installed by default as /usr/share/doc/rpm- version /RPM-GPG-KEY . If it isn t there, you can get it from at least one of the following sources:

  • From the Red Hat Linux installation CDs, in the main directory. If you install CDs in the default location, the key will be in /mnt/cdrom/RPM-GPG-KEY .

  • From . As of this writing, it is available at security/news/ publickey .html .

Next, import the GPG public key. For example, if you re importing from the installation CD, you should import to the /var/lib/rpm/Pubkeys file with the following command:

 # rpm --import /mnt/cdrom/RPM-GPG-KEY 

The rpm --import command is fairly new. If you re using an older version of Red Hat Linux (before 7.3), you may need to use the gpg --import publickey command.

Verifying a Package

Now you can verify any RPM package for a genuine Red Hat Linux signature. For example, it may be a good idea to verify the integrity of the kernel sources before recompiling. To perform this task on a kernel-sources RPM in the /tmp directory, run the following command:

 #  rpm -K /tmp/kernel-source-*.rpm  /tmp/kernel-sources-  versionnumber  .rpm: (sha1) dsa sha1 md5 gpg OK 

This verifies the integrity of the kernel-source RPM to the noted encryption schemes, including GPG.

Verifying a File

It s useful to check files against the original configuration. For example, if a cracker changes a file on your computer, you want to know about it. There are a number of standard things about every file you can check against the original. The data associated with every file installed through an RPM package is stored in the RPM database in the /var/lib/rpm directory.

If you suspect that a certain command isn t working quite as it should, you can check it against the RPM database. Let s take the mount command as an example. You can check the integrity of mount with the following command:

 # rpm -Vf /bin/mount 

If you don t see any output, the command matches what was originally installed.

Alternatively, if someone tampered with the mount command, you might see output similar to the following:

 #  rpm -Vf /bin/mount  SM5....T    /bin/mount 

This command checks nine different attributes of /bin/mount . If you see one of the letters shown in Table 10.3, the file differs from the original in some way. In this particular case, there are changes to the file size , permissions, the MD5 checksum, and the file modification time.

Table 10.3: rpm File Verification Issues


Failed Test


File size mismatch


Mode (different permissions and file type)


MD5 checksum wrong


Symbolic link incorrect


Device number wrong


User ownership changed


Group ownership changed


File modification time mismatch


Unreadable file


Configuration file flag

In some cases, a failure is not a problem. For example, if you ve revised your /etc/inittab file, you ll see what looks like a verification failure:

 #  rpm -Vf /etc/inittab  ..5....T c /etc/inittab 

However, this particular failure may not mean that a problem exists. For example, I got this result after modifying the initdefault variable in this configuration file. In other words, the checksum ( 5 ) changed because I changed the content of the file; and the file modification time ( T ) is different from when Red Hat Linux was installed on my computer.


Mastering Red Hat Linux 9
Building Tablet PC Applications (Pro-Developer)
ISBN: 078214179X
EAN: 2147483647
Year: 2005
Pages: 220

Similar book on Amazon © 2008-2017.
If you may any questions please contact us: