Chapter 11

Building Packages:
A Simple Example

In Chapter 10, "The Basics of Developing with RPM," we looked at RPM's build process from a conceptual level. In this chapter, we will be performing an actual build using RPM. In order to keep things understandable for this first pass, the build will be very simple. Once we've covered the basics, we'll present more real-world examples in later chapters.

11.1. Creating the Build Directory Structure

RPM requires a set of directories in which to perform the build. Although the directories' locations and names can be changed, it's best to use the default layout. Note that if you've installed RPM, the build directories are most likely in place already.

The normal directory layout consists of a single top-level directory (the default name is /usr/src/redhat) with five subdirectories. The five subdirectories and their functions are

• /usr/src/redhat/SOURCES—Contains the original sources, patches, and icon files.
• /usr/src/redhat/SPECS—Contains the spec files used to control the build process.
• /usr/src/redhat/BUILD—The directory in which the sources are unpacked and the software is built.
• /usr/src/redhat/RPMS—Contains the binary package files created by the build process.
• /usr/src/redhat/SRPMS—Contains the source package files created by the build process.

In general, there are no special requirements that need to be met when creating these directories. In fact, the only important requirement is that the BUILD directory be part of a filesystem with sufficient free space to build the largest package expected. Here is a directory listing showing a typical build directory tree:

# ls -lF /usr/src/redhat

total 5

drwxr-xr-x 3 root root 1024 Aug 5 13:12 BUILD/

drwxr-xr-x 3 root root 1024 Jul 17 17:51 RPMS/

drwxr-xr-x 4 root root 1024 Aug 4 22:31 SOURCES/

drwxr-xr-x 2 root root 1024 Aug 5 13:12 SPECS/

drwxr-xr-x 2 root root 1024 Aug 4 22:28 SRPMS/

#

Now that we have the directories ready to go, it's time to prepare for the build. For the remainder of this chapter, we'll be building a fictional piece of software known as cdplayer.

11.2. Getting the Sources

The first thing we need to do in order to build a package for cdplayer is to obtain the sources. Being avid cdplayer fans from way back, we know that the latest source can be found at GnomoVision's FTP site, so we go get a copy.

We now have a gzipped tar file of cdplayer version 1.0 on our system. After putting a copy in the SOURCES directory, we're ready to tell RPM what to do with it.

11.3. Creating the Spec File

The way we direct RPM in the build process is to create a spec file. As we saw in Chapter 10, the spec file contains eight different sections, most of which are required. Let's go through each section and create cdplayer's spec file as we go.

11.3.1. The Preamble

The preamble contains a wealth of information about the package being built and the people who built it. Here's cdplayer's preamble:

#

# Sample spec file for cdplayer app...

#

Summary: A CD player app that rocks!

Name: cdplayer

Version: 1.0

Release: 1

Copyright: GPL

Group: Applications/Sound

Source: ftp://ftp.gnomovision.com/pub/cdplayer/cdplayer-1.0.tgz

URL: 

http://www.gnomovision.com/cdplayer/cdplayer.html

Distribution: WSS Linux

Vendor: White Socks Software, Inc.

Packager: Santa Claus <sclaus@northpole.com>



%description

It slices! It dices! It's a CD player app that can't be beat. By using

the resonant frequency of the CD itself, it is able to simulate 20X

oversampling. This leads to sound quality that cannot be equaled with

more mundane software...

In general, the preamble consists of entries, one per line, that start with a tag followed by a colon, and then some information. For example, the line starting with Summary: gives a short description of the packaged software that can be displayed by RPM. The order of the lines is not important, as long as they appear in the preamble.

Let's take a look at each line and see what function it performs:

• Name—The name line defines what the package will actually be called. In general, it's a good idea to use the name of the software. The name will also be included in the package label and the package filename.
• Version—The version line should be set to the version of the software being packaged. The version will also be included in the package label and the package filename.
• Release—The release is a number used to represent the number of times the software, at the present version, has been packaged. You can think of it as the package's version number. The release is also part of the package label and package filename.
• Copyright—The copyright line is used to hold the packaged software's copyright information. This makes it easy to determine which packages can be freely redistributed and which cannot. In our case, cdplayer is made available under the terms of the GNU General Public License, so we've put GPL on the line.
• Group—The group line is used to hold a string that defines how the packaged software should be grouped with other packages. The string consists of a series of words separated by slashes. From left to right, the words describe the packaged software more explicitly. We grouped cdplayer under Applications because it is an application, and then under Sound because it is an application that is sound related.
• Source—The source line serves two purposes:
  • To document where the packaged software's sources can be found
  • To give the name of the source file as it exists in the SOURCES subdirectory

  In our example, the cdplayer sources are contained in the file cdplayer-1.0.tgz, which is available from ftp.gnomovision.com, in the directory /pub/cdplayer. RPM actually ignores everything prior to the last filename in the source line, so the first part of the source string could be anything you'd like. Traditionally, the source line contains a uniform resource locator, or URL.

• URL—The URL line is used to contain a URL, like the source line. How are they different? While the source line is used to provide the source filename to RPM, the URL line points to documentation for the software being packaged.
• Distribution—The distribution line contains the name of the product that the packaged software is a part of. In the Linux world, the operating system is often packaged together into a distribution, hence the name. Because we're using a fictional application in this example, we've filled in the distribution line with the name of a fictional distribution. There's no requirement that the spec file contain a distribution line, so individuals will probably omit this.