during the development of their packages. By preventing the pre- and postinstall scripts from running, a package builder can keep a buggy package from bringing down his development system. Once the bugs are found and eliminated, the --noscripts option is no longer necessary.

2.4.11. --percent: Not Meant for Human Consumption

An option that will probably never be very popular is --percent. This option is meant to be used by programs that interact with the user, perhaps presenting a graphical user interface for RPM. When the --percent option is used, RPM displays a series of numbers. Each number is a percentage that indicates how far along the install is. When the number reaches 100%, the install is complete. Here's an example:

# rpm -i --percent iBCS-1.2-3.i386.rpm

%f iBCS:1.2:3

%% 0.002140

%% 1.492386

%% 5.296632

%% 9.310026

%% 15.271010

%% 26.217846

%% 31.216000

%% 100.000000

%% 100.000000

#

The list of percentages will vary depending on the number of files in the package, but every package ends at 100% when completely installed.

2.4.12. --rcfile <rcfile>: Use <rcfile> As an Alternate
rpmrc File

The --rcfile option is used to specify a file containing default settings for RPM. Normally, this option is not needed. By default, RPM uses /etc/rpmrc and a file named .rpmrc located in your login directory.

This option would be used if there were a need to switch between several sets of RPM defaults. Software developers and package builders will normally be the only people using the --rcfile option. For more information on rpmrc files, see Appendix B.

2.4.13. --root <path>: Use <path> As an Alternate Root

Adding --root <path> to an install command forces RPM to assume that the directory specified by <path> is actually the root directory. The --root option affects every aspect of the install process, so pre- and postinstall scripts are run with <path> as their root directory (using chroot(2). In addition, RPM expects its database to reside in the directory specified by the dbpath rpmrc file entry, relative to <path>. (For more information on rpmrc file entries, see Appendix B.)

Normally, this option is used only during an initial system install or when a system has been booted off a rescue disk and some packages need to be reinstalled.

2.4.14. --dbpath <path>: Use <path> to Find an RPM Database

In order for RPM to do its handiwork, it needs access to an RPM database. Normally, this database exists in the directory specified by the rpmrc file entry dbpath. By default, dbpath is set to /var/lib/rpm.

Although the dbpath entry can be modified in the appropriate rpmrc file, the --dbpath option is probably a better choice when the database path needs to be changed temporarily. An example of a time the --dbpath option would come in handy is when it's necessary to examine an RPM database copied from another system. Granted, it's not a common occurrence, but it's difficult to handle any other way.

2.4.15. --ftpport <port>: Use <port> in FTP-Based Installs

Back in section 2.2.1 you saw how RPM can access package files with the use of a URL. You also learned that some systems may not use the standard FTP port. In those cases, it's necessary to give RPM the proper port number to use. As mentioned earlier, one approach is to embed the port number in the URL itself.

Another approach is to use the --ftpport option. RPM will access the desired port when this option, along with the port number, is added to the command line. In cases where the desired port seldom changes, it may be entered in an rpmrc file by using the ftpport entry. For more information on the use of rpmrc files, see Appendix B.

2.4.16. --ftpproxy <host>: Use <host> As a Proxy in
FTP-Based Installs

Many companies and Internet service providers (ISPs) employ various methods to protect their network connections against misuse. One of these methods is to use a system that will process all FTP requests on behalf of the other systems on the company or ISP network. Having a single computer act as a proxy for the other systems serves to protect the other systems against any FTP-related misuse.

When RPM is employed on a network with an FTP proxy system, it will be necessary for RPM to direct all its FTP requests to the FTP proxy. RPM will send its FTP requests to the specified proxy system when the --ftpproxy option, along with the proxy hostname, is added to the command line.

In cases where the proxy host seldom changes, you can enter it in an rpmrc file by using the ftpproxy entry.

2.4.17. --ignorearch: Do Not Verify Package Architecture

When a package file is created, RPM specifies the architecture, or type of computer hardware, for which the package was created. This is a good thing because the architecture is one of the main factors in determining whether a package written for one computer is going to be compatible with another computer.

When a package is installed, RPM uses the arch_compat rpmrc entries to determine what are normally considered compatible architectures. Unless you're porting RPM to a new architecture, you shouldn't make any changes to these entries. (You'll find more on arch_compat in section 19.3.1 in Chapter 19, "Building Packages for Multiple Architectures and Operating Systems.") Although RPM attempts to make the right decisions regarding package compatibility, there are times when it errs on the side of conservatism. In those cases, it's necessary to override RPM's decision. The --ignorearch option is used in those cases. When it's added to the command line, RPM will not perform any architecture-related checking.

2.4.18. --ignoreos: Do Not Verify the Package Operating System

When a package file is created, RPM specifies the operating system for which the package was created. This is good because the operating system is one of the main factors in determining whether a package written for one computer is going to be compatible with another computer.

When a package is installed, RPM uses the os_compat rpmrc entries to determine what are normally considered compatible operating systems. Unless you're porting RPM to a new operating system, you shouldn't make any changes to these entries. (You'll find more on oscompat in section 19.3.1 in Chapter 19.) Although RPM attempts to make the right decisions regarding package compatibility, there are times when it errs on the side of conservatism. In those cases, it's necessary to override RPM's decision. The --ignoreos option is used in those cases. When it's added to the command line, RPM will not perform any operating system_related checking.