Maximum RPM (RPM):Using RPM to Install Packages:EarthWeb Inc.-






-->
















Previous | Table of Contents | Next


Page 33



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


Page 34

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.


Page 35



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.







CAUTION



Unless you really know what you're doing, you should never use
--ignorearch!




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.







CAUTION



Unless you really know what you're doing, you should never use
--ignoreos!




Previous | Table of Contents | Next