| rpm -e ( or - -erase) options pkg1 ... pkgN | ||
| Parameters | ||
|
pkg1 ... pkgN | One or more installed packages | |
|
Erase--specific Options | Page | |
|
- -test | Perform erase tests only | [*] |
|
- -noscripts | Do not execute pre- and post-uninstall scripts | [*] |
|
- -nodeps | Do not check dependencies | [*] |
|
General Options | Page | |
|
-vv | Display debugging information | [*] |
|
- -root <path> | Set alternate root to <path> | [*] |
|
- -rcfile <rcfile> | Set alternate rpmrc file to <rcfile> | [*] |
|
- -dbpath <path> | Use <path> to find the RPM database | [*] |
|
| ||
The rpm -e command (- -erase is equivalent) removes, or erases, one or more packages from the system. RPM performs a series of steps whenever it erases a package:
That's quite a bit of activity for a single command. No wonder RPM can be such a time-saver!
The most basic erase command is:
# rpm -e eject
#
In this case, the eject package was erased. There isn't much in the way of feedback, is there? Could we get more if we add -v?
# rpm -ev eject
#
Still nothing. However, there's another option that can be counted on to give a wealth of information. Let's give it a try:
By adding -vv to the command line, we can often get a better feel for what's going on inside RPM. The -vv option was really meant for the RPM developers, and its output may change, but it is a great way to gain insight into RPM's inner workings. Let's try it with rpm -e:
# rpm -evv eject
D: uninstalling record number 286040
D: running preuninstall script (if any)
D: removing files test = 0
D: /usr/man/man1/eject.1 - removing
D: /usr/bin/eject - removing
D: running postuninstall script (if any)
D: removing database entry
D: removing name index
D: removing group index
D: removing file index for /usr/bin/eject
D: removing file index for /usr/man/man1/eject.1
#
Although -v had no effect on RPM's output, -vv gave us a torrent of output. But what does it tell us?
First, RPM displays the package's record number. The number is normally of use only to people that work on RPM's database code.
Next, RPM executes a ``pre-uninstall'' script, if one exists. This script can execute any commands required to remove the package before any files are actually deleted.
The ``files test = 0'' line indicates that RPM is to actually erase the package. If the number had been non-zero, RPM would only be performing a test of the package erasure. This happens when the - -test option is used. Refer to section [*] on page [*] for more information on the use of the - -test option with rpm -e.
The next two lines log the actual removal of the files comprising the package. Packages with many files can result in a lot of output when using -vv!
Next, RPM executes a ``post-uninstall'' script, if one exists. Like the pre-uninstall script, this script is used to perform any processing required to cleanly erase the package. Unlike the pre-uninstall script, however, the post-uninstall script runs after all the package's files have been removed.
Finally, the last five lines show the process RPM uses to remove every trace of the package from its database. From the messages, we can see that the database contains some per-package data, followed by information on every file installed by the package.
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.
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
D: uninstalling record number 286040
D: running preuninstall script (if any)
D: would remove files test = 1
D: /usr/man/man1/eject.1 - would remove
D: /usr/bin/eject - would remove
D: running postuninstall 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:
By using - -test in conjunction with -vv, it's easy to see exactly what RPM would do during an actual erase.
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
#
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 erasure.
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.
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.
In section [*] on page [*], 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 file named .rpmrc located in your login directory.
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 [*] on page [*].
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>.[fnsymbol{footnote}]
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 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.
If you've made changes to a configuration file that was originally installed by RPM, your changes won't be lost if you erase the package. Say, for example, that we've made changes to /etc/skel/.bashrc (a config file), which was installed as part of the etcskel package. Later, we remove etcskel:
# rpm -e etcskel
#
But if we take a look in /etc/skel, look what's there:
# ls -al
total 5
drwxr-xr-x 3 root root 1024 Jun 17 22:01 .
drwxr-xr-x 8 root root 2048 Jun 17 19:01 ..
-rw-r-r- 1 root root 152 Jun 17 21:54 .bashrc.rpmsave
drwxr-xr-x 2 root root 1024 May 13 13:18 .xfm
#
Sure enough: .bashrc.rpmsave is a copy of your modified .bashrc file! Remember, however, that this feature only works with config files. Not sure how to determine which files RPM thinks are config files? Chapter [*], specifically, section [*] on page [*] will show you how.
RPM takes most of the work out of removing software from your system, and that's great. As with everything else in life, however, there's a downside. RPM also makes it easy to erase packages that are critical to your system's continued operation. Here are some examples of packages not to erase:
In many cases, RPM's dependency processing will prevent inadvertent erasures from causing massive problems. However, if you're not sure, use rpm -q to get more information about the package you'd like to erase.[fnsymbol{footnote}]