Библиотека сайта rus-linux.net
|Maximum RPM: Taking the Red Hat Package Manager to the Limit
|Chapter 6. Using RPM to Verify Installed Packages
There are several ways to verify packages installed on your system. If you've taken a look at RPM's query command, you'll find that many of them are similar. Let's start with the simplest method of specifying packages — the package label.
While it looks like RPM didn't do anything, the following steps were performed:
For every file in the package, RPM checked the nine file attributes that were discussed above.
If the package was built with dependencies, the RPM database was searched to ensure the packages that satisfy those dependencies were installed.
If the package was built with a verification script, that script was executed.
In our example, each of these steps was performed without error — the package verified successfully. Remember, with rpm -V you'll only see output if a package fails to verify.
Don't be too surprised if rpm -Va turns up a surprising number of files that failed verification. RPM's verification process is very strict! In many cases, the changes flagged don't indicate problems — they are only an indication of your system's configuration being different than what the builders of the installed packages had on their system. Also, some attributes change during normal system operation. However, it would be wise to check into each verification failure, just to make sure.
Imagine this: you're hard at work when a program you've used a million times before suddenly stops working. What do you do? Well, before using RPM, you probably tried to find other files associated with that program and see if they had changed recently.
(Note that the issue surrounding RPM and symbolic links mentioned in the section called A Tricky Detail in Chapter 5 also applies to rpm -Vf. Watch those symlinks!)
Unlike the previous options to rpm -V, each of which verified one or more packages against RPM's database, the -p option performs the same verification, but against a package file. Why on earth would you want to do this when the RPM database is sitting there just waiting to be used?
Well, what if you didn't have an RPM database? While it isn't a common occurrence, power failures, hardware problems, and inadvertent deletions (along with non-existent backups) can leave your system "sans database". Then your system hiccups — what do you do now?
Whatever else might be wrong with this system, at least we can add new users. But what if you have many packages to verify? It would be a very slow process doing it one package at a time. That's where the next option comes in handy…
Shells. This group consists of packages that
contain, strangely enough, shells. Let's verify the proper
installation of every shell-related package on the system:
As we can see, there are three different capabilities that the rpm package requires:
D: verifying record number
2341208 indicates that RPM's normal file-based
verification proceeded normally.
As expected, the output is identical to the prior example — minus the lines dealing with the verification script, of course.
This is not to say that the missing file problem is solved, just that no file verification was performed.
If you're looking for more insight into RPM's inner workings, you'll have to try the next option:
The lines starting with
D: have been
added by using -vv. We can see where the RPM
database is located and what record number contains information on the
rpm-2.3-1 package. Following that is the list of
dependencies that the
rpm package requires.
In the vast majority of cases, it will not be necessary to use -vv. It is normally used by software engineers working on RPM itself, and the output can change without notice. However, it's a handy way to gain insights into RPM.
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.
<path> to a verify command
forces RPM to assume that the directory specified by
<path> is actually
the "root" directory. In addition, RPM expects its database to reside
in the directory specified by the dbpath
rpmrc 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 to restore normal operation.
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 options. Software developer and package builders
will be the people using --rcfile. For more
rpmrc files, see Appendix B.
Failure messages will always be displayed.
For more information on