In cases where there are requirements, they are displayed as follows:

# rpm -q --requires rpm

libz.so.1

libdb.so.2

libc.so.5

#

It's also possible that you'll come across something like this:

# rpm -q --requires blather

bother >= 3.1

#

Packages may also be built to require another package. This requirement can also include specific versions. In the preceding example, the bother package is required by blather (specifically, a version of bother greater than or equal to 3.1).

Here's something worth understanding. Let's say we decide to track down the bother that blather says it requires. If we use RPM's query capabilities, we could use the --whatprovides package selection option to try to find it:

# rpm -q --whatprovides bother

no package provides bother

#

No dice. This might lead you to believe that the blather package has a problem. The moral of this story is that, when trying to find out which package fulfills another package's requirements, it's a good idea to also try a simple query using the requirement as a package name. Continuing our earlier example, let's see if there's a package called bother:

# rpm -q bother

bother-3.5-1

#

Bingo! However, if we see what capabilities the bother package provides, we come up dry:

# rpm -q --provides bother

#

The reason for the lack of output is that all packages, by default, provide their package name (and version).

The --dump option is used to display every piece of information RPM has on one or more files listed in its database. The information is listed in a very concise fashion. Because the --dump option displays file-related information, the list of files must be chosen by using the -l, -c, or -d options (or some combination thereof):

# rpm -ql --dump adduser

/usr/sbin/adduser 4442 841083888 ca5fa53dc74952aa5b5e3a5fa5d8904b 0100755

root root 0 0 0 X

#

What does all this stuff mean? Let's go through it, item by item:

• /usr/sbin/adduser is simple: It's the name of the file being dumped.
• 4442 is the size of the file, in bytes.
• How about 841083888? It's the time the file was last modified, in seconds past the UNIX zero date of January 1, 1970.
• ca5fa53dc74952aa5b5e3a5fa5d8904b is the MD5 checksum of the file's contents, all 128 bits of it.
• If you guessed 0100755 was the file's mode, you were right.
• The first root represents the file's owner.
• The second root is the file's group.
• We'll take the next part (0 0) in one chunk. The first 0 shows whether the file is a config file. If 0, as in this case, the file is not a config file. The next 0 shows whether the file is documentation. Again, since there is a 0 here, this file isn't documentation either.
• The final 0 represents the file's major and minor numbers. These are set only for device special files. Otherwise, it will be 0.
• If the file were a symlink, the spot taken by X would contain a path pointing to the linked file.

Normally, the --dump option is used by people who want to extract the file-related information from RPM and process it somehow.

If you add --scripts (that's two dashes) to a query, you get to see a little bit more of RPM's underlying magic:

# rpm -q --scripts XFree86

preinstall script:

(none)



postinstall script:

/sbin/ldconfig

/sbin/pamconfig --add --service=xdm --password=none --sesslist=none





preuninstall script:

(none)



postuninstall script:

/sbin/ldconfig

if [ "$1" = 0 ] ; then

/sbin/pamconfig --remove --service=xdm --password=none --sesslist=none

fi

verify script:

(none)

#

In this particular case, the XFree86 package has two scripts: One labeled postinstall and one labeled postuninstall. As you might imagine, the postinstall script is executed just after the package's files have been installed; the postuninstall script is executed just after the package's files have been erased.

Based on the labels in this example, you'd probably imagine that a package can have as many as five different scripts. You'd be right:

• The preinstall script, which is executed just before the package's files are installed.
• The postinstall script, which is executed just after the package's files are installed.
• The preuninstall script, which is executed just before the package's files are removed.
• The postuninstall script, which is executed just after the package's files are removed.
• And finally, the verify script. While it's easy to figure out the other scripts' functions based on their name, what does a script called verify do? Well, we haven't gotten to it yet, but packages can also be verified for proper installation. This script is used during verification. (For more information on package verification, see section 6.1 in Chapter 6, "Using RPM to Verify Installed Packages.")

Is this something you'll need very often? As in the case of displaying file states, not really. But when you need it, you really need it!

Okay, say you're still not satisfied. You'd like some additional information, or you think a different format would be easier on the eyes. Maybe you want to take some information on the packages you've installed and run it through a script for some specialized processing. You can do it, using the --queryformat option. In fact, if you look back at the output of the -i option, you'll notice that RPM was using --queryformat internally. Here's how it works: On the RPM command line, include --queryformat. Right after that, enter a format string, enclosed in single quotes (`).

The format string can consist of a number of different components:

• Literal text, including escape sequences
• Tags, with optional field width, formatting, and iteration information
• Array iterators

Let's look at each of these components.