Page 263
Page 264
While RPM certainly makes packaging software as easy as possible, it doesn't stop there. RPM gives you the tools you need to build a package on different types of computers. More importantly, RPM makes it possible to build packages on different types of computers using a single spec file. Those of you who have developed software for different computers know the importance of maintaining a single set of sources. RPM lets you continue that practice through the package-building phase.
Before we get into RPM's capabilities, let's quickly review what is involved in developing software for different types of computer systems.
From a software engineering standpoint, there are only two major differences between any two computer systems:
The first difference is built into the computer. The architecture is the manner in which the computer system was designed. It includes the number and type of registers present in the processor, the number of machine instructions, what operations they perform, and so on. For example, every PC today, no matter who built it, is based on the Intel x86 architecture.
The second difference is more under our control. The operating system is software that controls how the system operates. Different operating systems have different methods of storing information on disk, different ways of implementing functions used by programs, and different hardware requirements.
As far as package building is concerned, two systems with the same architecture running two different operating systems are as different as two systems with different architectures running the same operating system. In the first case, the software being packaged for the different operating systems will differ due to the differences between the operating systems. In the second case, the software being packaged for different architectures will differ due to the underlying differences in hardware. (This is a somewhat simplistic view of the matter; it's common for incompatibilities to crop up between two different implementations of the same operating system on different architectures.)
RPM supports differences in architecture and operating system equally. If there is a tag, rpmrc file entry, or conditional that is used to support architectural differences, there is a corresponding tag, entry, or conditional that supports operating system differences.
Page 265
In order to keep the duplication in this chapter to a minimum, we'll refer to a computer of a given architecture running a given operating system as a platform. If another system differs in either aspect, it is considered a different platform.
Okay, now that we've gotten through the preliminaries, let's look at RPM's multiplatform capabilities.
As we mentioned, RPM supports multiplatform package building through a set of tags, rpmrc file entries, and conditionals. None of these tools is difficult to use. In fact, the hardest part of multiplatform package building is figuring out how the software needs to be changed to support different platforms.
Let's take a look at each multiplatform tool RPM provides.
The first thing necessary for easy multiplatform package building is to identify which platform the package is to be built for. Except in the fairly esoteric case of cross-compilation, the build platform is the platform on which the package is built. RPM does this for you automatically, although it can be overridden at build time.
The other important platform in package building is the platform on which the package is to be installed. Here again, RPM does this for you, although it's possible to override this when the package is installed.
But there is more to multiplatform package building than simply being able to determine the platform during package building and installation. The next component in multiplatform package building is a set of platform-dependent tags.
RPM uses a number of tags that control which platforms can build a package. These tags make it easier for the package builder to build multiple packages automatically since the tags keep RPM from attempting to build packages that are incompatible with the build platform.
Page 266
Whereas the platform-dependent tags provide a crude level of multiplatform control (that is, the package will be built or not, depending on the tags and the build platform), RPM's platform-dependent conditionals provide a much finer level of control. By using these conditionals, it's possible to excise those parts of the spec file that are specific to another platform and replace them with one or more lines that are compatible with the build platform.
Now that you have a basic idea of RPM's multiplatform support features, let's take a more in-depth look at each one.
As mentioned earlier, the first step to multiplatform package building is to identify the build platform. This is done by matching information from the build system's uname output against a number of rpmrc file entries.
Normally, it's not necessary to worry too much about the following rpmrc file entries because RPM comes with a set of entries that support all platforms that currently run RPM. However, when adding support for new platforms, it will be necessary to use the following entries to add support for the new build platform.
Normally, the file /usr/lib/rpmrc contains the following rpmrc file entries. They can be overridden by entries in /etc/rpmrc or ~ /.rpmrc. This is discussed more completely in Appendix B, "The rpmrc File."
Because each entry type is available in both architecture and operating system flavors, we'll just use xxx in place of arch and os in the following descriptions.
The xxx_canon entry is used to convert information obtained from the system running RPM into a canonical name and number that RPM will use internally. Here's the format:
xxx_canon:<label>: <string> <value>
<label> is compared against information from uname(2). If a match is found, <string> is used by RPM as the canonical name, and <value> is used as a unique numeric value. Here are two examples:
arch_canon: sun4: sparc 3 os_canon: Linux: Linux 1