| Maximum RPM: Taking the Red Hat Package Manager to the Limit | ||
|---|---|---|
| Prev | Chapter 19. Building Packages for Multiple Architectures and Operating Systems | Next |
uname output against a number of rpmrc file entries.
Normally, it's not necessary to worry too much about the following rpmrc file entries, as 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.
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
xxx_canon: <label>: <string> <value>
|
The <label> is compared against information from uname(2). If a match is found, then <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
|
The arch_canon tag above is used to define the canonical architecture information for Sun Microsystems' 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 above 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.
The description above 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. Next, 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>
|
The <label> is compared against information from uname(2). If a match is found, then <string> is used by RPM as the build platform information, after it has been canonicalized by xxx_canon. Here are two examples:
buildarchtranslate: i586: i386
buildostranslate: Linux: Linux
|
The buildarchtranslate tag shown above 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
The xxx_compat
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, they should be separated by a space.
The names in the list are considered compatible to the name specified in the label.
arch_compat: i586: i486
arch_compat: i486: i386
os_compat: Linux: AIX
|
The arch_compati586, the compatible architectures would be i486, and i386. However, if the build system was an i486, the only compatible architecture would be an i386.
While the os_compat line shown above is entirely fictional, its purpose would be to declare AIX compatible with Linux. If it were only that simple…
By using the rpmrc 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 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, and then happily build a package for it.
builder. If someone has a need to override their build platform information, they should know what they're doing, and what the full implications of their 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.
Dangerous? Yes. But it can be indispensable in certain circumstances. Like 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.
| Главная |