Let's try the file command on this mystery file to see what we can find out about it:

# file etcskel-1.0-3.src.rpm

etcskel-1.0-3.src.rpm: RPM v2 src i386 etcskel-1.0-3

#

Well, it's a package file all, right—for version 1.0, release 3 of the etcskel package. It's in RPM version 2 format and built for Intel-based systems. But what does the src mean?

8.3.1. A Gentle Introduction to Source Code

This package file contains not the executable, or binary, files that a normal package contains, but rather the source files required to create those binaries. When a programmer creates a new program, he writes the instructions, often called code, in one or more files. The source code is then compiled into a binary that can be executed by the computer.

As part of the process of building package files (a process covered in great detail in Part II), two types of package files are created:

• The binary, or executable, package file
• The source package file

The source package contains everything needed to re-create not only the programs and associated files that are contained in the binary package file, but the binary and source package files themselves.

8.3.2. Do You Really Need More Information Than This?

The following discussion is going to get rather technical. Unless you're the type of person who likes to modify other people's code, chances are you won't need much more information than this. But if you're still interested, let's explore further.

8.3.3. So What Can I Do with It?

One thing you can do with source package files is install them. Let's try an install of a source package:

# rpm -i cdp-0.33-3.src.rpm

#

Well, that doesn't tell us very much and (take our word for it) adding -v doesn't improve the situation appreciably. Let's haul out the big guns and try -vv:

# rpm -ivv cdp-0.33-3.src.rpm

D: installing cdp-0.33-3.src.rpm

Installing cdp-0.33-3.src.rpm

D: package is a source package major = 2

D: installing a source package

D: sources in: ///usr/src/redhat/SOURCES

D: spec file in: ///usr/src/redhat/SPECS

D: file "cdp-0.33-cdplay.patch" complete

D: file "cdp-0.33-fsstnd.patch" complete

D: file "cdp-0.33.spec" complete

D: file "cdp-0.33.tgz" complete

D: renaming ///usr/src/redhat/SOURCES/cdp-0.33.spec

to

///usr/src/redhat/SPECS/cdp-0.33.spec

#

What does this output say? Well, RPM recognizes that the file is a source package. It mentions that sources (we know what they are) are in /usr/src/redhat/SOURCES. Let's take a look:

# ls -al /usr/src/redhat/SOURCES/

-rw-rw-r-- 1 root root 364 Apr 24 22:35 cdp-0.33-cdplay.patch

-rw-r--r-- 1 root root 916 Jan 8 12:07 cdp-0.33-fsstnd.patch

-rw-r--r-- 1 root root 148916 Nov 10 1995 cdp-0.33.tgz

#

Some files there seem to be related to cdp. The two files ending with .patch are patches to the source. RPM permits patches to be processed when building binary packages. The patches are bundled along with the original, unmodified sources in the source package.

The last file is a gzipped tar file. If you've gotten software off the Internet, you're probably familiar with tar files, gzipped or not. If we look inside the file, we should see all the usual kinds of things: readme files, a makefile or two, and some source code:

# tar ztf cdp-0.33.tgz

cdp-0.33/COPYING

cdp-0.33/ChangeLog

cdp-0.33/INSTALL

cdp-0.33/Makefile

cdp-0.33/README

cdp-0.33/cdp

cdp-0.33/cdp-0.33.lsm

cdp-0.33/cdp.1

cdp-0.33/cdp.1.Z

cdp-0.33/cdp.c

cdp-0.33/cdp.h

. . .

#

There's more, but you get the idea. Okay, so there are the sources. But what is that spec file mentioned in the output? It mentions something about /usr/src/redhat/SPECS, so let's see what we have in that directory:

# ls -al /usr/src/redhat/SPECS

-rw-r--r-- 1 root root 397 Apr 24 22:36 cdp-0.33.spec

Without making a long story too short, a spec file contains information used by RPM to create the binary and source packages. Using the spec file, RPM does the following:

1. Unpacks the sources.
2. Applies patches (if any exist).

3. Builds the software.
4. Creates the binary package file.
5. Creates the source package file.
6. Cleans up after itself.

The neatest part of this is that RPM does all this automatically, under the control of the spec file. That's about all we're going to say about how RPM builds packages. For more information, please see Part II.

8.3.4. Stick with Us!

As noted several times, we'll be covering the subject of building packages with RPM in Part II. Be forewarned, however: Package building, while straightforward, is not a task for people new to programming. But if you've written a program or two, you'll probably find RPM's package building a piece of cake.