Библиотека сайта rus-linux.net
|Maximum RPM: Taking the Red Hat Package Manager to the Limit|
|Prev||Chapter 3. Using RPM to Erase Packages||Next|
If you're interested in a complex command with lots of options, rpm -e is not the place to look. There just aren't that many different ways to erase a package! But there are a few options you should know about.
It's pretty easy to see that the
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.
As you can see, the output is similar to that of a regular erase command using the -vv option, with the following exceptions:
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 "
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.
What happened? The problem is that one or more of the packages
installed on your system require the package you're trying to erase.
Without it, they won't work properly. 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
Now, 99 times out of 100, this is exactly the right thing for RPM to do. After all, if the package is needed by other packages, why try to erase it? As with everything else in life, there are exceptions to the rule. And that is why there is a --nodeps option.
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.
In the section called Getting More Information With -vv, we used the -vv option to see what RPM was actually doing when it erased a package. We noted that there were two scripts, a pre-uninstall and a post-uninstall, that were used to execute commands 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 option is really meant for package builders to use during the development of their packages. By preventing the pre- and post-uninstall scripts from running, a package 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!
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
.rpmrc located in your login
This option would be used if there was 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.
to an install command forces RPM to assume that the directory
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
chroot(2), if you must know).
In addition, RPM expects its database to reside in the directory
specified by the dbpath
file entry, relative to
Normally this option is only used during an initial system install, or when a system has been booted off a "rescue disk" and some packages need to be re-installed.
In order for RPM to do its handiwork, it needs access to an RPM
database. Normally, this database exists in the directory specified
rpmrc file entry,
dbpath. By default, dbpath is
Although the dbpath entry can be modified in the
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.
For more information on