📄 0066-0068.html
字号:
<HTML>
<HEAD>
<TITLE>Maximum RPM (RPM):Getting Information About Packages:EarthWeb Inc.-</TITLE>
<META NAME="ROBOTS" CONTENT="NOINDEX, NOFOLLOW">
<SCRIPT>
<!--
function displayWindow(url, width, height) {
var Win = window.open(url,"displayWindow",'width=' + width +
',height=' + height + ',resizable=1,scrollbars=yes');
}
//-->
</SCRIPT>
</HEAD>
-->
<!-- ISBN=0672311054 //-->
<!-- TITLE=Maximum RPM (RPM)//-->
<!-- AUTHOR=Edward Bailey//-->
<!-- PUBLISHER=Macmillan Computer Publishing//-->
<!-- IMPRINT=Sams//-->
<!-- CHAPTER=05 //-->
<!-- PAGES=0053-0078 //-->
<!-- UNASSIGNED1 //-->
<!-- UNASSIGNED2 //-->
<P><CENTER>
<a href="0063-0065.html">Previous</A> | <a href="../ewtoc.html">Table of Contents</A> | <a href="0069-0071.html">Next</A>
</CENTER></P>
<A NAME="PAGENUM-66"><P>Page 66</P></A>
<P>In cases where there are requirements, they are displayed as follows:
</P>
<!-- CODE SNIP //-->
<PRE>
# rpm -q --requires rpm
libz.so.1
libdb.so.2
libc.so.5
#
</PRE>
<!-- END CODE SNIP //-->
<P>It's also possible that you'll come across something like this:
</P>
<!-- CODE SNIP //-->
<PRE>
# rpm -q --requires blather
bother >= 3.1
#
</PRE>
<!-- END CODE SNIP //-->
<P>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).
</P>
<P>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:
</P>
<!-- CODE SNIP //-->
<PRE>
# rpm -q --whatprovides bother
no package provides bother
#
</PRE>
<!-- END CODE SNIP //-->
<P>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:
</P>
<!-- CODE SNIP //-->
<PRE>
# rpm -q bother
bother-3.5-1
#
</PRE>
<!-- END CODE SNIP //-->
<P>Bingo! However, if we see what capabilities the
bother package provides, we come up dry:
</P>
<!-- CODE SNIP //-->
<PRE>
# rpm -q --provides bother
#
</PRE>
<!-- END CODE SNIP //-->
<P>The reason for the lack of output is that all packages, by default, provide their package
name (and version).
</P>
<B>
5.2.2.9. --dump: Display All Verifiable Information for Each File
</B>
<P>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):
</P>
<!-- CODE //-->
<PRE>
# rpm -ql --dump adduser
/usr/sbin/adduser 4442 841083888 ca5fa53dc74952aa5b5e3a5fa5d8904b 0100755
root root 0 0 0 X
#
</PRE>
<!-- END CODE //-->
<A NAME="PAGENUM-67"><P>Page 67</P></A>
<P>What does all this stuff mean? Let's go through it, item by item:
</P>
<UL>
<LI>/usr/sbin/adduser is simple: It's the name of the file being
dumped.
<LI> 4442 is the size of the file, in bytes.
<LI> How about
841083888? It's the time the file was last modified, in seconds past
the UNIX zero date of January 1, 1970.
<LI>ca5fa53dc74952aa5b5e3a5fa5d8904b is the MD5 checksum of the file's contents,
all 128 bits of it.
<LI>If you guessed
0100755 was the file's mode, you were right.
<LI>The first
root represents the file's owner.
<LI>The second
root is the file's group.
<LI>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.
<LI>The final 0 represents the file's major and minor numbers. These are set only
for device special files. Otherwise, it will be 0.
<LI> If the file were a symlink, the spot taken by
X would contain a path pointing to the linked file.
</UL>
<P>Normally, the --dump option is used by people who want to extract the file-related
information from RPM and process it somehow.
</P>
<B>
5.2.2.10. --scripts: Show Scripts Associated with a Package
</B>
<P>If you add --scripts (that's two dashes) to a query,
you get to see a little bit more of RPM's underlying magic:
</P>
<!-- CODE //-->
<PRE>
# 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
</PRE>
<!-- END CODE //-->
<A NAME="PAGENUM-68"><P>Page 68</P></A>
<!-- CODE SNIP //-->
<PRE>
verify script:
(none)
#
</PRE>
<!-- END CODE SNIP //-->
<P>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.
</P>
<P>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:
</P>
<UL>
<LI> The preinstall script, which is executed just before the package's files are installed.
<LI> The postinstall script, which is executed just after the package's files are installed.
<LI> The preuninstall script, which is executed just before the package's files are removed.
<LI> The postuninstall script, which is executed just after the package's files are removed.
<LI> 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.")
</UL>
<P>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!
</P>
<B>
5.2.2.11. --queryformat: Construct a Custom Query Response
</B>
<P>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 (`).
</P>
<P>The format string can consist of a number of different components:
</P>
<UL>
<LI> Literal text, including escape sequences
<LI> Tags, with optional field width, formatting, and iteration information
<LI> Array iterators
</UL>
<P>Let's look at each of these components.
</P>
<P><CENTER>
<a href="0063-0065.html">Previous</A> | <a href="../ewtoc.html">Table of Contents</A> | <a href="0069-0071.html">Next</A>
</CENTER></P>
</td>
</tr>
</table>
<!-- begin footer information -->
</body></html>
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -