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 system 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 the Section called Using Build Roots in a Package in Chapter 16.
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 2.
Default value: (none)
The ftpport entry is used to define the port RPM should use when manipulating package files via FTP. See the Section called --ftpport <port>: Use <port> In FTP-based Installs in Chapter 2 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 the Section called --ftpproxy <host>: Use <host> As Proxy In FTP-based Installs in Chapter 2 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 17.
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 17.
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 17.
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 the Section called --timecheck <secs> — Print a warning if files to be packaged are over <secs> old in Chapter 12.
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:
builddir
rpmdir
sourcedir
specdir
srcrpmdir
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.
| [1] | The buildostranslate rpmrc file entry is discussed on the Section called buildostranslate. |