Page 267
The arch_canon tag here is used to define the canonical architecture information for Sun Microsystems's SPARC architecture. In this case, the output from uname is compared against sun4. If there's a match, the canonical architecture name is set to sparc, and the architecture number is set to 3.
The os_canon tag here is used to define the canonical operating system information for the Linux operating system. In this case, the output from uname is compared against Linux. If there's a match, the canonical operating system name is set to Linux, and the operating system number is set to 1.
This description is not 100% complete—there is an additional step performed during the time RPM gets the system information from uname and compares it against a canonical name. Let's look at the rpmrc file entry that comes into play during this intermediate step.
The buildxxxtranslate entry is used to define the build platform information. Specifically, these entries are used to create a table that maps information from uname to the appropriate architecture/operating system name.
The buildxxxtranslate entry looks like this:
buildxxxtranslate:<label>: <string>
<label> is compared against information from uname(2). If a match is found, <string> is used by RPM as the build platform information after it has been processed by xxx_canon. Here are two examples:
buildarchtranslate: i586: i386 buildostranslate: Linux: Linux
The buildarchtranslate tag shown here is used to define the build architecture for an Intel Pentium (or i586, as it's shown here) processor. Any Pentium-based system will, by default, build packages for the Intel 80386 (or i386) architecture.
The buildostranslate tag shown here is used to define the build operating system for systems running the Linux operating system. In this case, the build operating system remains unchanged.
The xxx_compat entry is used to define which architectures and operating systems are compatible with one another. It is used at install time only. The format of the entry is
xxx_compat:<label>: <list>
The <label> is a name string as defined by an xxx_canon entry. The <list> following it consists of one or more names, also defined by arch_canon. If there is more than one name in the list, the names should be separated by a space.
Page 268
The names in the list are considered compatible to the name specified in the label.
The following arch_compat lines illustrate how a family of upwardly compatible architectures may be represented. For example, if the build architecture was defined as i586, the compatible architectures would be i486 and i386. However, if the build system were an i486, the only compatible architecture would be an i386.
While the os_compat line shown here is entirely fictional, its purpose would be to declare AIX compatible with Linux:
arch_compat: i586: i486 arch_compat: i486: i386 os_compat: Linux: AIX
If only it were that simple….
By using the rpmrc file entries discussed in the preceding section, RPM usually makes the
right decisions in selecting the build and install platforms. However, there might be times when
RPM's selections aren't the best. Normally the circumstances are unusual, as in the case of cross-
compiling software. In these cases, it is nice to have an easy way of overriding the build
time architecture and operating system.
The --buildarch and --buildos options can be used to set the build time architecture and operating system rather than relying on RPM's automatic detection capabilities. These options are added to a normal RPM build command. One important point to remember is that although RPM does try to find the specified architecture name, it does no checking as to the sanity of the entered architecture or operating system. For example, if you enter an entirely fictional operating system, RPM will issue a warning message, but then happily build a package for it.
Why? Wouldn't it make more sense for RPM to perform some sort of sanity check? In a word, no. One of RPM's main design goals was to never get in the way of the package builder. If someone has a need to override his build platform information, he should know what he's doing and what the full implications of his actions are.
Bottom line: Unless you know why you need to use --buildarch or --buildos, you probably don't need to use them.
It's also possible to direct RPM to ignore platform information while a package is being installed. The --ignorearch and --ignoreos options, when added to any install or upgrade command, will direct RPM to proceed with the install or upgrade, even if the package's platform doesn't match the install platform.
Page 269
Dangerous? Yes. But it can be indispensable in certain circumstances. As with the ability to override platform information at build time, unless you know why you need to use --ignorearch or --ignoreos, you probably don't need to use them.
While the optflags entry doesn't play a part in determining the build or install platform, it does play a role in multiplatform package building. The optflags entry is used to define a standard set of options that can be used during the build process, specifically during compilation.
The optflags entry looks like this:
optflags:<architecture> <value>
For example, assume that the following optflags entries were placed in an rpmrc file:
optflags: i386 -O2 -m486 -fno-strength-reduce optflags: sparc -O2
If RPM were running on an Intel 80386-compatible architecture, the optflags value would be set to -O2 -m486 -fno-strength-reduce. If, however, RPM were running on a Sun SPARC-based system, optflags would be set to -O2.
This entry sets the RPM_OPT_FLAGS environment variable, which can be used in the %prep, %build, and %install scripts.
Once RPM has determined the build platform's information, that information can be used
in the build process. The first way this information can be used is to determine whether a
given package should be built on a given platform. This is done through the use of four tags
(discussed in the following sections) that can be added to a spec file.
There can be many reasons to do this. For example, the software may not build correctly on a given platform. Or the software may be platform specific, such that packaging the software on any other platform, while technologically possible, would really make no sense.
The real world is not always so clear cut, so there might even be cases where a package should be built on, say, three different platforms, but no others. By carefully using the tags described in the following sections, any conceivable situation can be covered.
As with the rpmrc file entries we've already discussed, there are identical tags for architecture and operating system, so we'll discuss them together.