As we saw in the first half of this book, 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 that sling code for a living? Does RPM have anything to offer them? The answer is 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 that would be using it to build many packages. So the design philosophy of RPM has a definite bias toward making life easier for developers. Here are some of the reasons you should consider building packages with RPM:
While 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. Because of this, 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, they often get 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 are a world of possible differences:
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 has been 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 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:
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 recreate 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.
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.
One of the biggest problems facing developers is reproducing a particular build. This single problem is the main reason so much effort is put into creating and deploying version control systems to manage sources.
While 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 we mentioned above? 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.
As we mentioned above, completely building a package takes only one RPM command. This makes it easy to set up automated build procedures that can build one hundred packages as easily as one. Anything from a single package consisting of one application to the several hundred packages that comprise an entire operating system, can be built automatically using RPM.
It has always been a fact of life 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 ability to support multiple architectures and operating systems makes it easy to build the same package for many OS/platform combinations. A package may be configured to build on only one architecture/OS combination, or on several. The only limitation is the application's portability.
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.
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.
Configuration files -- nearly every application has them. They may 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.
RPM takes special care with a user's config files. By using MD5 checksums, RPM can determine what action is most appropriate with a config file. If a config file has been modified by the user and has to be replaced, it is saved. That way a user's modifications are never lost.
RPM uses a database to keep track of all files it installs. RPM's database provides other benefits, such as the wide variety of information that can be easily retrieved from it. RPM's query command makes it easy for users to quickly answer a number of questions, such as:
These are just a few examples of the many ways RPM can provide information about one or more packages on a user's system.
Another way that RPM leverages the information stored in its database, is by providing an easy way to verify that a package is properly installed. With this capability, RPM makes it easy to determine, for example, what packages were damaged by a wildcard delete in /usr/bin. In addition, RPM's verification command can detect changes to file attributes, such as a file's permissions, ownership, and size.
RPM was written by developers for developers. It makes building packages as easy as possible, even if the software being packaged hasn't been developed in-house. In addition, RPM presents some significant advantages to users, thereby reducing support needs.
In the next chapter, we'll introduce the basic concepts of package building with RPM.