Maximum RPM (RPM):Building Packages for Multiple Architectures and Operating Systems:EarthWeb Inc.-






-->
















Previous | Table of Contents | Next


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.



19.3.1.2. buildxxxtranslate: Define Build Platform


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.



19.3.1.3. xxx_compat: Define Compatible Architectures


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….



19.3.2. Overriding Platform Information at Build Time


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.



19.3.3. Overriding Platform Information at Install Time


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.



19.4. optflags: The Other rpmrc File Entry


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.



19.5. Platform-Dependent Tags


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.



Previous | Table of Contents | Next