Additional Options

--test — Go Through the Process of Erasing the Package, But Do Not Erase It

If you're a bit gun-shy about erasing a package, you can use the --test option first to see what rpm -e would do:

# rpm -e --test bother removing these packages would break dependencies: bother >= 3.1 is needed by blather-7.9-1 #

It's pretty easy to see that the blather package wouldn't work very well if bother were erased. To be fair, however, RPM wouldn't have erased the package in this example unless we used the --nodeps option, which we'll discuss shortly.

However, if there are no problems erasing the package, you won't see very much:

# rpm -e --test eject #

We know, based on previous experience, that -v doesn't give us any additional output with rpm -e. However, we do know that -vv works wonders. Let's see what it has to say:

# rpm -evv --test eject script (if any) D: would remove database entry #

As you can see, the output is similar to that of a regular erase command using the -vv option, with the following exceptions:

• The "would remove files test = 1" line ends with a non-zero number. This is because --test has been added. If the command hadn't included --test, the number would have been 0, and the package would have been erased.

• There is a line for each file that RPM would have removed, each one ending with "would remove" instead of "removing".

• There is only one line at the end, stating: "would remove database entry", versus the multi-line output showing the cleanup of the RPM database during an actual erase.

By using --test in conjunction with -vv, it's easy to see exactly what RPM would do during an actual erase.

--nodeps: Do Not Check Dependencies Before Erasing Package

It's likely that one day while erasing a package, you'll see something like this:

# rpm -e bother removing these packages would break dependencies: bother >= 3.1 is needed by blather-7.9-1 #

In our example, the blather package won't work properly unless the bother package (and more specifically, bother version 3.1 or later) is installed. Since we're trying to erase bother, RPM aborted the erasure.

else in life, there are exceptions to the rule. And that is why there is a --nodeps option.

Adding the --nodeps options to an erase command directs RPM to ignore any dependency-related problems, and to erase the package. Going back to our example above, let's add the --nodeps option to the command line and see what happens:

# rpm -e --nodeps bother #

The package was erased without a peep. Whether the blather package will work properly is another matter. In general, it's not a good idea to use --nodeps to get around dependency problems. The package builders included the dependency requirements for a reason, and it's best not to second-guess them.

--noscripts — Do Not Execute Pre- and Post-uninstall Scripts

In the section called Getting More Information With -vv, we used the -vv required during the process of erasing a package.

The --noscripts option prevents these scripts from being executed during an erase. This is a very dangerous thing to do! The --noscripts builder can keep a buggy package from bringing down their development system. Once the bugs are found and eliminated, there's very little need to prevent these scripts from running; in fact, doing so can cause problems!

--rcfile <rcfile> — Read <rcfile> For RPM Defaults

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.

using the --rcfile option. For more information on rpmrc files, see Appendix B.

--root <path> — Use <path> As the 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 post-install scripts are run with <path> as their root directory (using chroot(2), if you must know). In addition, RPM expects its database to reside in the directory specified by the dbpath rpmrc file entry, relative to <path>. [1]

--dbpath <path>: Use <path> To Find 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 handle any other way.