The rpmrc file is used to control RPM's actions. The file's entries have an effect on nearly every aspect of RPM's operations. Here, we describe the rpmrc files in more detail, as well as the command used to show how RPM interprets the files.
As we'll see in a moment, RPM can read more than one rpmrc file, and each file can contain nearly thirty different types of entries. This can make it difficult to determine what values RPM is actually using.
Luckily, there's an option that can be used to help make sense of it all. The - -showrc option displays the value for each of the entries. The output is divided into two sections:
The architecture and operating system values define the architecture and operating system that RPM is running on. These values define the environment for both building and installing packages. They also define which architectures and operating systems are compatible with each other.
The rpmrc values define many aspects of RPM's operation. These values range from the path to RPM's database, to the name of the person listed as having built the package.
Here's an example of - -showrc's output:
# rpm - -showrc
ARCHITECTURE AND OS: build arch : i386 build os : Linux install arch : i486 install os : Linux compatible arch list : i486 i386 compatible os list : Linux RPMRC VALUES: builddir : /usr/src/redhat/BUILD buildroot : (not set) cpiobin : cpio dbpath : /var/lib/rpm defaultdocdir : /usr/doc distribution : (not set) excludedocs : (not set) ftpport : (not set) ftpproxy : (not set) messagelevel : (not set) netsharedpath : (not set) optflags : -O2 -m486 -fno-strength-reduce packager : (not set) pgp_name : (not set) pgp_path : (not set) require_distribution : (not set) require_icon : (not set) require_vendor : (not set) root : (not set) rpmdir : /usr/src/redhat/RPMS signature : none sourcedir : /usr/src/redhat/SOURCES specdir : /usr/src/redhat/SPECS srcrpmdir : /usr/src/redhat/SRPMS timecheck : (not set) tmppath : /var/tmp topdir : /usr/src/redhat vendor : (not set) #
As you can see, the - -showrc option clearly displays the values RPM will use. - -showrc can also be used with the - -rcfile option, which makes it easy to see the effect of specifying a different rpmrc file.
RPM looks for rpmrc files in four places:
The first three files are read in the order listed, such that if a given rmprc entry is present in each file, the value of the entry read last is the one used by RPM. This means, for example, that an entry in .rpmrc in the user's login directory will always override the same entry in /etc/rpmrc. Likewise, an entry in /etc/rpmrc will always override the same entry in /usr/lib/rpmrc.
If the - -rcfile option is used, then only /usr/lib/rpmrc and the file following the - -rcfile option are read, in that order. The /usr/lib/rpmrc file is always read first. This cannot be changed.
Let's look at each of these files, starting with /usr/lib/rpmrc.
The file /usr/lib/rpmrc is always read. It contains information that RPM uses to set some default values. This file should never be modified! Doing so may cause RPM to operate incorrectly.
After this stern warning, we should note that it's perfectly all right to look at it. Here it is, in fact:
############################################################# # Default values, often overridden in /etc/rpmrc dbpath: /var/lib/rpm topdir: /usr/src/redhat tmppath: /var/tmp cpiobin: cpio defaultdocdir: /usr/doc ############################################################# # Please send new entries to rpm-list@@redhat.com ############################################################# # Values for RPM_OPT_FLAGS for various platforms optflags: i386 -O2 -m486 -fno-strength-reduce optflags: alpha -O2 optflags: sparc -O2 optflags: m68k -O2 -fomit-frame-pointer ############################################################# # Canonical arch names and numbers arch_canon: i986: i986 1 arch_canon: i886: i886 1 arch_canon: i786: i786 1 arch_canon: i686: i686 1 arch_canon: i586: i586 1 arch_canon: i486: i486 1 arch_canon: i386: i386 1 arch_canon: alpha: alpha 2 arch_canon: sparc: sparc 3 arch_canon: sun4: sparc 3 arch_canon: sun4m: sparc 3 arch_canon: sun4c: sparc 3 # This is really a place holder for MIPS. arch_canon: mips: mips 4 arch_canon: ppc: ppc 5 # This is really a place holder for 68000 arch_canon: m68k: m68k 6 # This is wrong. We really need globbing in here :-( arch_canon: IP: sgi 7 arch_canon: IP22: sgi 7 arch_canon: 9000/712: hppa1.1 9 arch_canon: sun4u: usparc 10 ############################################################# # Canonical OS names and numbers os_canon: Linux: Linux 1 os_canon: IRIX: Irix 2 # This is wrong os_canon: SunOS5: solaris 3 os_canon: SunOS4: SunOS 4 os_canon: AmigaOS: AmigaOS 5 os_canon: AIX: AIX 5 os_canon: HP-UX: hpux10 6 os_canon: OSF1: osf1 7 os_canon: FreeBSD: FreeBSD 8 ############################################################# # For a given uname().machine, the default build arch buildarchtranslate: osfmach3_i986: i386 buildarchtranslate: osfmach3_i886: i386 buildarchtranslate: osfmach3_i786: i386 buildarchtranslate: osfmach3_i686: i386 buildarchtranslate: osfmach3_i586: i386 buildarchtranslate: osfmach3_i486: i386 buildarchtranslate: osfmach3_i386: i386 buildarchtranslate: i986: i386 buildarchtranslate: i886: i386 buildarchtranslate: i786: i386 buildarchtranslate: i686: i386 buildarchtranslate: i586: i386 buildarchtranslate: i486: i386 buildarchtranslate: i386: i386 buildarchtranslate: osfmach3_ppc: ppc ############################################################# # Architecture compatibility arch_compat: alpha: axp arch_compat: i986: i886 arch_compat: i886: i786 arch_compat: i786: i686 arch_compat: i686: i586 arch_compat: i586: i486 arch_compat: i486: i386 arch_compat: osfmach3_i986: i986 osfmach3_i886 arch_compat: osfmach3_i886: i886 osfmach3_i786 arch_compat: osfmach3_i786: i786 osfmach3_i686 arch_compat: osfmach3_i686: i686 osfmach3_i586 arch_compat: osfmach3_i586: i586 osfmach3_i486 arch_compat: osfmach3_i486: i486 osfmach3_i386 arch_compat: osfmach3_i386: i486 arch_compat: osfmach3_ppc: ppc arch_compat: usparc: sparc
Quite a bunch of stuff, isn't it? With the exception of the first five lines, which indicate where several important directories and programs are located, the remainder of this file contains rpmrc entries that are related to RPM's architecture and operating system processing. As you might imagine, any tinkering here will probably not be very productive, so leave any modifications here to the RPM developers.
Next, we have /etc/rpmrc.
The file /etc/rpmrc, unlike /usr/lib/rpmrc, is fair game for modifications and additions. In fact, /etc/rpmrc isn't created by default, so its contents are entirely up to you. It's the perfect place to keep rpmrc entries of a system-wide or global nature.
The vendor entry is a great example of a good candidate for inclusion in /etc/rpmrc. In most cases, a particular system is dedicated to building packages for one vendor. In these instances, setting the vendor entry in /etc/rpmrc is best.
Next in the hierarchy is a file named .rpmrc, residing in the user's login directory.
As you might imagine, a file called .rpmrc in a user's login directory is only going to be read by that user when he or she runs RPM. Like /etc/rpmrc, this file is not created by default, but it can contain the same rpmrc entries as the other files. The packager entry, which should contain the name and contact information for the person who built the package, is an appropriate candidate for /.rpmrc.
The - -rcfile option is best used only when a totally different RPM configuration is desired for one or two packages. Since the only other rpmrc file read is /usr/lib/rpmrc with its low-level default settings, the file specified with the - -rcfile option will have to be more comprehensive than either /etc/rpmrc or /.rmprc.
As you might have surmised from the example file we briefly reviewed, the basic syntax of an rpmrc file entry is:
<name>:<value>
The <name> part of the entry is not case sensitive, so any capitalization is acceptable. The colon separating the name from its value must immediately follow the name. No spaces are allowed here. The formatting requirements on the value side of the entry vary from value to value and will be discussed along with each entry.
In this section, we discuss the various entries that can be used in each of the rpmrc files.
The arch_canon entry is used to define a table of architecture names and their associated numbers. These canonical architecture names and numbers are then used internally by RPM whenever architecture-specific processing takes place. This entry's format is:
arch_canon:<label>: <string> <value>
The <label> is compared against information from uname(2) after it's been translated using the appropriate buildarchtranslate entry. If a match is found, then <string> is used by RPM to reference the system's architecture. When building a binary package, RPM uses <string> as part of the package's filename, for instance.
The <value> is a numeric value RPM uses internally to identify the architecture. For example, this number is written in the header of each package file so that the file command can identify the architecture for which the package was built.
The os_canon entry is used to define a table of operating system names and their associated numbers. These canonical operating system names and numbers are then used internally by RPM whenever operating system-specific processing takes place. This entry's format is:
os_canon:<label>: <string> <value>
The <label> is compared against information from uname(2) after it's been translated using the appropriate buildostranslate entry.1 If a match is found, then <string> is used by RPM to reference the operating system.
The <value> is a numeric value used to uniquely identify the operating system.
The buildarchtranslate entry is used in the process of defining the architecture that RPM will use as the ``build'' architecture. As the name implies, it is used to translate the raw information returned from uname(2) to the canonical architecture defined by arch_canon.
The format of the buildarchtranslate entry is slightly different from most other rpmrc file entries. Instead of the usual <name>:<value> format, the buildarchtranslate entry looks like this:
buildarchtranslate:<label>: <string>
The <label> is compared against information from uname(2). If a match is found, then <string> is used by RPM to define the build architecture.
The buildostranslate entry is used in the process of defining the operating system RPM will use as the ``build'' operating system. As the name implies, it is used to translate the raw information returned by uname(2) to the canonical operating sysetm defined by os_canon.
The format of the buildostranslate entry is slightly different from most other rpmrc file entries. Instead of the usual <name>:<value> format, the buildostranslate entry looks like this:
buildostranslate:<label>: <string>
The <label> is compared against information from uname(2). If a match is found, then <string> is used by RPM to define the build operating system.
The arch_compat entry is used to define which architectures are compatible with one another. This information is used when packages are installed; in this way, RPM can determine whether a given package file is compatible with the system. The format of the entry is:
arch_compat:<label>: <list>
The <label> is an architecture string, as defined by an arch_canon entry. The <list> following it consists of one or more architectures, also defined by arch_canon. If there is more than one architecture in the list, they should be separated by a space.
The architectures in the list are considered compatible to the architecture specified in the label.
Default value: (operating system-specific)
The os_compat entry is used to define which operating systems are compatible with one another. This information is used when packages are installed; in this way, RPM can determine whether a given package file is compatible with the system. The format of the entry is:
<name>:<label>: <list>
The <label> is an operating system string, as defined by an os_canon entry. The <list> following it consists of one or more operating systems, also defined by os_canon. If there is more than one operating system in the list, they should be separated by a space.
The operating systems in the list are considered compatible to the operating system specified in the label.
Default value: (topdir)/BUILD
The builddir entry is used to define the path to the directory in which RPM will build packages. Its default value is taken from the value of the topdir entry, with ``/BUILD'' appended to it. Note that if you redefine builddir, you'll need to specify a complete path.
Default value: (none)
The buildroot entry defines the path used as the root directory during the install phase of a package build. For more information on using build roots, please see chapter [*], specifically, section [*] on page [*].
Default value: cpio
The cpiobin entry is used to define the name (and optionally, path) of the cpio program. RPM uses cpio to perform a variety of functions, and needs to know where the program can be found.
Default value: /var/lib/rpm
The dbpath entry is used to define the directory in which the RPM database files are stored. It can be overridden by using the - -dbpath option on the RPM command line.
Default value: /usr/doc
The defaultdocdir entry is used to define the directory in which RPM will store documentation for all installed packages. It is used only during builds to support the %doc directive.
Default value: (none)
The distribution entry is used to define the distribution for each package. The distribution can also be set by adding the distribution tag to a particular spec file. The distribution tag in the spec file overrides the distribution rpmrc file entry.
Default value: 0
The excludedocs entry is used to control if documentation should
be written to disk when a package is installed. By default, documentation
is installed; however, this can be overridden by setting the value
of excludedocs to 1. Note also that the
- -excludedocs and - -includedocs options can be added
to the RPM command line to override the excludedocs entry's
behavior. For more information on the - -excludedocs and
- -includedocs options, please refer to chapter [*] on
page [*].
Default value: (none)
The ftpport entry is used to define the port RPM should use when manipulating package files via FTP. See section [*] on page [*] for more information on how FTP ports are used by RPM.
Default value: (none)
The ftpproxy entry is used to define the hostname of the FTP proxy system RPM should use when manipulating package files via FTP. See section [*] on page [*] for more information on how FTP proxy systems are used by RPM.
Default value: 3
The messagelevel entry is used to define the desired verbosity level. Levels less than 3 produce greater amounts of output, while levels greater than 3 produce less output.
Default value: (none)
The netsharedpath entry is used to define one or more paths that, on the local system, are shared with other systems. If more than one path is specified, they must be separated with colons.
Default value: (architecture-specific)
The optflags entry is used to define a standard set of options that can be used during the build process, specifically during compilation.
The format of the optflags entry is slightly different from most other rpmrc file entries. Instead of the usual <name>:<value> format, the optflags entry looks like this:
optflags:<architecture> <value>
For example, assume the following optflags entries were placed in an rpmrc file:
optflags: i386 -O2 -m486 -fno-strength-reduce
optflags: sparc -O2
If RPM was running on an Intel 80386-compatible architecture, the optflags value would be set to -O2 -m486 -fno-strength-reduce. If, however, RPM was 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.
Default value: (none)
The packager entry is used to define the name and contact information for the individual responsible for building the package. The contact information is traditionally defined in the following format:
packager:Erik Troan <ewt@@redhat.com>
Default value: (none)
The pgp_name entry is used to define the name of the PGP public key that will be used to sign each package built. The value is not case sensitive, but the key name entered here must match the actual key name in every other aspect.
For more information on signing packages with PGP, please read chapter [*] on page [*].
Default value: (none)
The pgp_path entry is used to point to a directory containing PGP keyring files. These files will be searched for the public key specified by the pgp_name entry.
For more information on signing packages with PGP, please read chapter [*] on page [*].
Default value: 0
The require_distribution entry is used to direct RPM to require that every package built must contain distribution information. The default value directs RPM to not enforce this requirement. If the entry has a non-zero value, RPM will only build packages that define a distribution.
Default value: 0
The require_icon entry is used to direct RPM to require that every package built must contain an icon. The default value directs RPM to not enforce this requirement. If the entry has a non-zero value, RPM will only build packages that contain an icon.
Default value: 0
The require_vendor entry is used to direct RPM to require that every package built must contain vendor information. The default value directs RPM to not enforce this requirement. If the entry has a non-zero value, RPM will only build packages that define a vendor.
Default value: (topdir)/RPMS
The rpmdir entry is used to define the path to the directory in which RPM will write binary package files. Its default value is taken from the value of the topdir entry, with ``/RPMS'' appended to it. Note that if you redefine rpmdir, you'll need to specify a complete path. RPM will automatically add an architecture-specific directory to the end of the path. For example, on an Intel-based system, the actual path would be:
/usr/src/redhat/RPMS/i386
Default value: (none)
The signature entry is used to define the type of signature that is to be added to each package built. At the present time, only signatures from PGP are supported. Therefore, the only acceptable value is ``pgp''.
For more information on signing packages with PGP, please read chapter [*] on page [*].
Default value: (topdir)/SOURCES
The sourcedir entry is used to define the path to the directory in which RPM will look for sources. Its default value is taken from the value of the topdir entry, with ``/SOURCES'' appended to it. Note that if you redefine sourcedir, you'll need to specify a complete path.
Default value: (topdir)/SPECS
The specdir entry is used to define the path to the directory in which RPM will look for spec files. Its default value is taken from the value of the topdir entry, with ``/SPECS'' appended to it. Note that if you redefine specdir, you'll need to specify a complete path.
Default value: (topdir)/SRPMS
The srcrpmdir entry is used to define the path to the directory in which RPM will write source package files. Its default value is taken from the value of the topdir entry, with ``/SRPMS'' appended to it. Note that if you redefine srcrpmdir, you'll need to specify a complete path.
Default value: (none)
The timecheck entry is used to define the default number of seconds to apply to the - -timecheck option when building packages. For more information on the - -timecheck option, please see section [*] on page [*].
Default value: /var/tmp
The tmpdir entry is used to define a path to the directory that RPM will use for temporary work space. This normally consists of temporary scripts that are used during the build process. It should be set to an absolute path (ie, starting with ``/'').
Default value: /usr/src/redhat
The topdir entry is used to define the path to the top-level directory in RPM's build directory tree. It should be set to an absolute path (ie, starting with ``/''). The following entries base their default values on the value of topdir:
Default value: (none)
The vendor entry is used to define the name of the organization that is responsible for distributing the packaged software. Normally, this would be the name of a business or other such entity.