• Ease of rebuilding large numbers of packages. By making it easy for people who were trying to create a Linux distribution consisting of several hundred packages, RPM was a step in the right direction.
• Ease of use. Many of the concepts used in RPP had withstood the test of time and were used in RPM. For instance, the ability to verify the installation of a package was one of the features that set RPP apart. It was adapted and expanded in RPM version 1.

But RPM version 1 wasn't perfect. There were a number of flaws, some of them major:

• It was slow. While the use of Perl made RPM's development proceed more quickly, it also meant that RPM wouldn't run as quickly as it would have had it been written in C.
• Its database design was fragile. Unfortunately, under RPM version 1 it was not unusual for there to be problems with the database. While dedicating a database to package management was a good idea, the implementation used in RPM version 1 left a lot to be desired.
• It was big. This is another artifact of using Perl. Normally, RPM's size requirements were not an issue, except in one area. When performing an initial system installation, RPM was run from a small, floppy-based system environment. The need to have Perl available meant that space on the boot floppies was always a problem.
• It didn't support multiple architectures (different types of computers) well. The need to have a package manager support more than one type of computer hadn't been acknowledged before. With RPM version 1, an initial stab was taken at the problem, but the implementation was incomplete. Nonetheless, RPM had been ported to a number of other computer systems. It was becoming obvious that the issue of multiarchitecture support was not going away and had to be addressed.
• The package file format wasn't extensible. This made it very difficult to add functionality since any change to the file format would cause older versions of RPM to break.

Even though their Linux distribution was a success, and RPM was much of the reason for it, Ewing and Troan knew that some changes were going to be necessary to carry RPM to the next level.

Looking back on their experiences with RPM version 1, Ewing and Troan made a major change to RPM's design: They rewrote it entirely in C. This did wonderful things to RPM's speed and size. Querying the database was quicker now, and there was no need to have Perl around just to do package management.

In addition, the database format was redesigned to improve both performance and reliability. Displaying package information can take as little as a tenth of the time spent in RPM version 1, for example.

Realizing RPM's potential in the non-Linux arena, Ewing and Troan also created rpmlib, a library of RPM routines that allow the use of RPM functionality in other programs. RPM's ability to function on more than one architecture was also enhanced. Finally, the package file format was made more extensible, clearing the way for future enhancements to RPM.

So is RPM perfect? No program can ever reach perfection, and RPM is no exception. But as a package manager that can run on several different types of systems, RPM has a lot to offer, and it will only get better. Let's take a look at the design criteria that drove the development of RPM.

1.3. RPM Design Goals

The design goals of RPM could best be summed up with the phrase "something for everyone." While the main reason for the existence of RPM was to make it easier for Red Hat Software to build the several hundred packages that comprised the Linux distribution, it was not the only reason RPM was created. The following sections take a look at the various requirements the Red Hat team used in its design of RPM.

1.3.1. Making It Easy to Get Packages on and off the System

As you've learned in this chapter, the act of installing a package can involve many complex steps. Entrusting these steps to a person who may not have the necessary experience is a strategy for failure. So the goal for RPM was to make it as easy as possible for anyone to install and uninstall packages. These are complex and error-prone operations, which RPM should handle for the user.

The other side of this issue is that RPM should give the package builder almost total control in terms of how the package is installed. The reason for this is simple: If the package builders do their homework, their packages should install and uninstall properly.

1.3.2. Making It Easy to Verify That a Package Was
Installed Correctly

Because software problems are a fact of life, the ability to verify the proper installation of a package is vital. If done properly, it should be possible to catch a variety of problems, including things such as missing or modified files.

1.3.3. Making It Easy for the Package Builder

Although we're dedicating an entire book to package management, it really should be a small portion of the package builder's job. Why? He's got better things to do! If the package builders are the people who are actually creating the software to be packaged, that's where they should be spending the majority of their time.

Even if the package builder isn't actually writing software, he still has better things to do than worry about building packages. For instance, he might be responsible for building many packages. The less time spent on building an individual package, the more packages that can be built.

1.3.4. Making It Start with the Original Source Code

It was deemed important that RPM start with the original, unmodified source code. Why is this so important?

Using the original sources makes it possible to separate the changes required to build the package from any changes implemented to fix bugs, add new features, or anything else. This is a good thing for package builders because many of them are not the original authors of the programs they package.

This separation makes it easy, months down the road, to know exactly what changes were made in order to get the package to build. This is important when a new version of the packaged software becomes available. Many times it's only necessary to apply the original package building changes to the newer software. At worst, the changes provide a starting point to determine what sorts of things might need to be changed in the new version.

1.3.5. Making It Work on Different Computer Architectures

One of the tougher things for a package builder to do is to take a program, make it run on more than one type of computer, and distribute packages for each. Because RPM makes it easy to use a program's original source code, add the changes necessary to get it to build, and produce a package for each architecture in one step, it can be pretty handy.

1.4. What's in a Package?

With all the magical things we've claimed that package management software in general (and RPM in particular) can do, you'd think there was a tiny computer guru bundled in every package. However, the reality is not that magical. The following sections give a quick overview of the more important parts of an RPM package.