Part II

RPM and Developers: How to Distribute
Your Software More
Easily with RPM

Chapter 9
The Philosophy
Behind RPM

As you saw in Part I, "RPM and Computer Users: How to Use RPM to Effectively Manage Your Computer," RPM can make life much easier for the user. With automated installs, upgrades, and erasures, RPM can take a lot of the guesswork out of keeping a computer system up-to-date.

But what about people who sling code for a living? Does RPM have anything to offer them? Yes! One of the best things about RPM is that although it was designed to make life easier for users, it was written by people who would be using it to build many packages. So the design philosophy of RPM has a definite bias toward making life easier for developers. The following sections list some of the reasons you should consider building packages with RPM.

9.1. Pristine Sources

Although many developers might use RPM to package their own software, just as many, if not more, are going to be packaging software that they have not written. Therefore, there are some aspects to RPM's design that are geared toward third-party package builders. One such aspect is RPM's use of pristine sources.

When a third-party package builder decides to package someone else's software, he often gets the software from the Net, normally as a tar file compressed with something like GNU zip. That's probably about the only generalization we can make when talking about software that is eligible for packaging. Once we look inside the tar file, there is a world of possible differences:

• The application could be available in pure source form, in pure binary form, or some combination of both.
• The application might have been written to be built using make, imake, or a script included with the sources. Or, it might have to be built entirely by hand.
• The application might need to be configured prior to use. Maybe it uses GNU configure, a custom configuration script, or one or more files that need to be edited to reflect the target environment.
• The application might have been written to reside in specific directories, and those directories do not exist, or are not appropriate on the target system.
• The application might not even support the target environment, requiring all manner of changes to port it to the target environment.

We could go on, but you probably get the idea. It's a rare application that comes off the Net ready to package, and the changes required vary widely. What to do?

This is where the concept of pristine sources comes in. RPM is designed to use the sources as they come from the application's developer, no matter how it has been packaged and configured. The main benefit is that the changes you as a package builder need to make remain separate from the original sources, in a distinct collection of patches.

This may not sound like much of an advantage, but consider how this would work if a new version of the application came out. If the new version had a few localized bug fixes, it's entirely possible that the original patches could be applied and a new package built, with a single RPM command. Even if the patches didn't apply cleanly, it would at least give an indication as to what might need to be done to get the new version built and packaged.

If your users sometimes customize packages, having pristine sources makes it easier for them, too. They can see what patches you've created and can easily add their own.

Another benefit to using pristine sources is that it makes keeping track of multiple versions of a package simple. Instead of keeping patched sources around, or battling a revision control system, it's only necessary to keep the following:

• The original sources in their tar file
• A copy of the patches you applied to get the application to build
• A file used by RPM to control the package-building process

With these three items, it's possible to easily build the package at any time. Keeping track of multiple versions only entails keeping track of each version of these three components, rather than hundreds or thousands of patched source files.

In fact, it gets better than that. RPM can also build a source package containing these three components. The source package, named using RPM's standard naming convention, keeps everything you need to re-create a specific version of a package in one uniquely named file. Keeping track of multiple versions of multiple packages is simply a matter of keeping the appropriate source packages around. Everything else can be built from them.

9.2. Easy Builds

RPM makes it easy to build packages. Just as with the use of pristine sources, the fact that the build process is simple is an even greater advantage to the third-party package builders responsible for many packages than it is to a one-package software development house. But in either case, RPM's ease of building is a welcome relief. The following sections document some of the ways that RPM makes building packages a straightforward process.

9.2.1. Reproducible Builds

One of the biggest problems facing developers is reproducing a particular build. This problem is the main reason so much effort is put into creating and deploying version control systems to manage sources.

Although RPM cannot compete with a full-blown revision control system, it does an excellent job of keeping in one place everything required to build a particular version of a package. Remember the source package mentioned earlier? With one command, RPM can open the

package, extract the sources, patch them, perform a build, and create a new binary package, ready for your users. The best part is that the binary package will be the same every time you build it because everything needed to create it is kept in one source package.

9.2.2. Unattended Builds

As mentioned earlier, completely building a package takes only one RPM command. This makes it easy to set up automated build procedures that can build 100 packages as easily as 1. Anything from a single package consisting of 1 application to the several hundred packages that comprise an entire operating system can be built automatically using RPM.

9.3. Multiarchitecture/Operating System Support

It has always been a fact for software developers that their applications may need to be ported to multiple operating systems. It is also becoming more common that a particular operating system might run on several different platforms, or architectures.

RPM's capability to support multiple architectures and operating systems makes it easy to build the same package for many OS/platform combinations. A package might be configured to build on only one architecture/OS combination, or on several. The only limitation is the application's portability.

9.4. Easier for Your Users

While we are primarily concerned with RPM's advantages from the developer's point of view, it's worth looking at RPM from the user's standpoint for a moment. After all, if RPM makes life easier for your users, that can translate into lower support costs.

9.4.1. Easy Upgrades

Probably the biggest headache for user and developer alike is the upgrade of an application, or worse yet, an entire operating system! RPM can make upgrading a one-step process. With one command, a new package can be installed, and the remnants of the old package removed.

9.4.2. Intelligent Configuration File Handling

Configuration files—nearly every application has them. They might go by different names, but they all control the behavior of their application. Users normally customize config files to their liking and would be upset if their customizations were lost during the installation, upgrade, or removal of a package.