Page 89
This is not to say that the missing file problem is solved, just that no file verification was performed.
Although RPM won't report an error with the command syntax if you include the -v option, you won't see much in the way of additional output:
# rpm -Vv bash #
Even if there are verification errors, adding -v won't change the output:
# rpm -Vv apmd S.5....T /etc/rc.d/init.d/apm S.5....T /usr/X11R6/bin/xapm #
The only time that the -v option will produce output is when the package being verified has a verification script. Any normal output from the script won't be displayed by RPM when run without -v (note that failure messages will always be displayed):
# rpm -V bother #
But when -v is added, the script's non-error-related output is displayed:
# rpm -Vv bother This is the bother 3.5 verification script #
Sometimes it's necessary to have even more information than we can get with -v. By adding another v, that's just what we'll get:
# rpm -Vvv rpm D: opening database in //var/lib/rpm/ D: verifying record number 2341208 D: dependencies: looking for libz.so.1 D: dependencies: looking for libdb.so.2 D: dependencies: looking for libc.so.5 #
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.
Page 90
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.
Adding --root <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 <path>. (For more information on rpmrc file entries, see Appendix B, "The rpmrc File.")
Normally this option is only used during an initial system install or when a system has been booted off a rescue disk.
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 options. Software developer and package builders will be the people using --rcfile. For more information on rpmrc files, see Appendix B.
Not really; we just omitted a few details until you've had a chance to see rpm -V in action. These details are described in the following sections.
Depending on the type of file being verified, RPM will not verify every possible attribute. Table 6.2 shows the attributes checked for each of the different file types.
Page 91
Table 6.2. File attributes verified for each file type.
| File Type | File Size | Mode | MD5 Check- sum | Major Number | Minor Number | Symlink String | Owner | Group | Modification Time |
| Directory File | X | X | X | ||||||
| Symbolic Links | X | X | X | X | |||||
| FIFO | X | X | X | ||||||
| Devices | X | X | X | X X | Regular Files | ||||
| X | X | X | X | X | X |
When a package builder creates a new package, he can control what attributes are to be verified on a file-by-file basis. The reasons for excluding specific attributes from verification can be quite involved, but here's an example just to give you the flavor: When a person logs into a system, there are device files associated with that user's terminal session. In order for the terminal device (called tty) to function properly, the owner and group of the device must change to that of the person logging in. Therefore, if RPM were to verify the package that created the tty device files, any ttys that were in use at the time would fail to verify. However, by using the %verify directive (see Chapter 13, "Inside the Spec File," for details on %verify), a package builder can save you from trivial verification failures.
Page 92