Author: elliss
Update of /cvs/docs/rpm-guide
In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv1023
Added Files:
rpm-guide-rpm-overview-en.xml
Log Message:
--- NEW FILE rpm-guide-rpm-overview-en.xml ---
<!-- $Id: -->
<chapter id="ch-rpm-overview">
<title>RPM Overview</title>
<para>
Copyright (c) 2005 by Eric Foster-Johnson. This material may be
distributed only subject to the terms and conditions set forth in
the Open Publication License, v1.0 or later (the latest version is
presently available at
http://www.opencontent.org/openpub/).
</para>
<para/>
<para>
In This Chapter
</para>
<para>
*Understanding the package file
</para>
<para>
*Querying the RPM database
</para>
<para>
*Running RPM commands
</para>
<para>
Working with RPM packages, files, commands, and databases can be
complicated. There are thousands of files, for hundreds if not
thousands of packages, installed on your system. You need some way
to manage it all. The RPM system can help you do that.
</para>
<para>
This chapter provides an overview of the components that make up the
RPM system for package management: package files, databases, and RPM
commands.
</para>
<sect1>
<title>Understanding the Package File</title>
<para>
RPM provides for installing, upgrading and removing packages.
Typically, each package is an application and all the necessary
files associated with that application. For example, the Apache
Web server comes with a number of configuration files, a large set
of documentation files, and the Apache server itself. All of this
fits into one RPM package.
</para>
<para>
One of the main advantages of the RPM system is that each .rpm
file holds a complete package. For example, the following file
holds the xcopilot package:
</para>
<para>
xcopilot-0.6.6-3.i386.rpm
</para>
<para>
Based on the naming conventions discussed in Chapter 2, this
package represents xcopilot package, version 0.6.6, third build of
an RPM package, for i386 (Intel) architecture systems.
</para>
<para>
With a single command, you can copy an .rpm file to another Linux
system and install it, getting the complete contents of the
package, or you can use other commands to remove or update the
package.
</para>
<sect2>
<title>RPM file format</title>
<para>
RPM files hold a number of tagged data items and a payload, the
files to install on your system. The tagged data items describe
the package and can contain optional features. For example, the
NAME tag holds the package name. The optional PRE tag holds a
pre-installation script, a script that the rpm command runs
prior to installing the files in the package payload.
</para>
<para>
Under the covers, RPM package files contain four sections. The
first is a leading identification area that marks the file as an
RPM package (created with a particular version of the RPM
system). The remaining sections are the signature, the tagged
data (called the header), and the payload. Each of these
sections has important information about the package, although
the payload section contains the actual content of the package.
</para>
<para>
*The signature appears after the lead or identifier section,
which marks the file as an RPM file. Like your signature when
you sign a check, the RPM signature helps verify the integrity
of the package. No, the signature doesn���t check for bugs in
software applications. Instead, it ensures that you have
downloaded a valid RPM archive.
</para>
<para>
The signature works by performing a mathematical function on the
header and archive sections of the file. The mathematical
function can be an encryption process, such as PGP (Pretty Good
Privacy), or a message digest in MD5 format.
</para>
<para>
*The header contains zero or more tagged blocks of data that
pertain to the package. The header contains information such as
copyright messages, version numbers, and package summaries.
</para>
<para>
*The payload section contains the actual files used in the
package. These files are installed when you install the package.
To save space, data in the archive section is compressed in GNU
gzip format.
</para>
<para>
Once uncompressed, the data is in cpio format, which is how the
rpm2cpio command (introduced in the "Other RPM commands" section
later in this chapter) can do its work.
</para>
</sect2>
<sect2>
<title>Binary RPMs and Source RPMs</title>
<para>
There are two main types of RPM packages: binary (or
applications) and source. A binary RPM has been compiled for a
particular architecture. For example, the Apache Web server
compiled for an Intel Pentium, or i586, architecture won���t
work on a Sharp Zaurus, which runs an Intel ARM processor. To
run on both systems, you would need two separate packages: one
for the Pentium i586 and one for the ARM.
</para>
<para>
In addition to binary RPMs, you can get source code RPMs. These
RPMs are packages that provide the source code for other
packages. Sounds kind of circular, doesn���t it?
</para>
<sect3>
<title>binary RPMs</title>
<para>
Binary RPMs hold complete applications or libraries of
functions compiled for a particular architecture. Most binary
RPMs contain complete applications, such as the Apache Web
server or the AbiWord word processor. These application binary
RPMs usually depend on a number of system libraries which are,
in turn, also provided by binary RPMs.
</para>
<para>
Cross Reference
</para>
<para>
Chapter 8 covers a number of locations where you can find RPM
applications galore. Your Linux installation CDs are also a
great source for applications. Most Linux distributions come
with more applications than you can imagine using.
</para>
<para>
Although most binary RPMs are complete applications, others
provide libraries. For example, the Simple DirectMedia Layer
library (SDL), which provides really cool graphics for many
games, can be packaged as an RPM file. A number of programs,
mostly games, use this library for enhanced multimedia such as
rich graphics. RPMs that provide libraries allow multiple
applications to share the same library. Typically, the
libraries are packaged into separate RPMs from the
applications.
</para>
<para>
In addition to binary RPMs that hold applications or libraries
compiled for a particular architecture, RPM supports the
concept of platform-independent binary RPMs. These
platform-independent RPMs, called noarch as a shorted form of
���no architecture��� dependencies, provide applications or
libraries that are not dependent on any platform. Applications
written in Perl, Python, or other scripting languages often do
not depend on code compiled for a particular architecture. In
addition, compiled Java applications are usually free of
platform dependencies.
</para>
</sect3>
</sect2>
<sect2>
<title>Source RPMs</title>
<para>
The xcopilot package, mentioned previously, contains the
xcopilot application used for synchronization with Palm handheld
devices. The source code used to create this application is
stored in an xcopilot source RPM, for example:
</para>
<para>
xcopilot-0.6.6-3.src.rpm
</para>
<para>
By convention, source RPMs have a file name ending in .src.rpm.
</para>
<para>
Source RPMs should contain all the commands, usually in scripts,
necessary
</para>
<para>
to recreate the binary RPM. Having a source RPM means that you
can recreate the binary RPM at any time. This is a very
important goal of the RPM system.
</para>
<para>
Note
</para>
<para>
Source RPMs have nothing to do with open-source software
licenses. Linux is famous for being an open-source operating
system. In RPM terms, that means the source code for the Linux
kernel and most Linux applications are freely available as
source RPMs. But you can also make source RPMs for proprietary
programs. The key issue is that you are unlikely to distribute
the source RPMs for proprietary packages.
</para>
<para>
Furthermore, a number of open-source applications are not
available as source RPMs. That's a shame, since source RPMs
would make these applications easier to install.
</para>
<para>
While source RPMs hold the commands necessary to create the
binary RPM, there may be differences in your Linux environment
that would result in rebuilding a binary RPM that is different
from the original binary RPM. For example, the compile scripts
for some packages may add in optional code depending on which
libraries or which versions of libraries are found on your
system. Chapter 14 covers many issues in creating RPMs, and
Chapters 19 and 20 cover issues related to other versions of
Linux and other operating systems, respectively. If you follow
the guidelines when making your own RPMs, you should result in
source RPMs that reproduce binary RPMs as consistently as
possible.
</para>
</sect2>
</sect1>
<sect1>
<title>Querying the RPM Database</title>
<para>
The RPM database holds information about all the RPM packages
installed on your system. You can use this database to query what
is installed, to help determine if you have the latest versions of
software, and to verify that your system is properly set up, at
least from a packaging point of view.
</para>
<para>
The RPM database itself is stored in the directory /var/lib/rpm,
and should contain files like the following:
</para>
<para>
Basenames
</para>
<para>
Conflictname
</para>
<para>
__db.001
</para>
<para>
__db.002
</para>
<para>
__db.003
</para>
<para>
Dirnames
</para>
<para>
Filemd5s
</para>
<para>
Group
</para>
<para>
Installtid
</para>
<para>
Name
</para>
<para>
Packages
</para>
<para>
Providename
</para>
<para>
Provideversion
</para>
<para>
Pubkeys
</para>
<para>
Requirename
</para>
<para>
Requireversion
</para>
<para>
Sha1header
</para>
<para>
Sigmd5
</para>
<para>
Triggername
</para>
<para>
Cross-reference
</para>
<para>
Chapter 5 covers the database in more detail.
</para>
<para>
These files make up the RPM database. The file __db.001 and
similar files are lock files used by the RPM system. The other
files are databases in Berkeley DB format. The most important file
is Packages. The Packages file contains the header tag information
for each package indexed by an index number for each package. This
number slowly grows with time.
</para>
<para>
The other files, such as Name, Providename, and Group, exist to
speed access to particular types of information. Treat your RPM
database with care. Back up the files, especially after upgrading,
installing, or removing packages.
</para>
<para>
Note
</para>
<para>
Only the Packages file is essential. You can recreate the rest of
the files using the rpm --rebuilddb command, introduced in Chapter
5.
</para>
</sect1>
<sect1>
<title>Running RPM Commands</title>
<para>
The primary RPM command is simply rpm. One of the original goals
of the RPM system is providing ease of use. In support of this
goal, just about everything you want to do with the RPM system can
be done with this one command. For most usage, the command-line
parameters to the rpm command determine the actions it should
take.
</para>
<sect2>
<title>Working with the rpm command</title>
<para>
The rpm command performs the most common package-management
functions, along with a host of uncommon functions as well.
Table 3-1 lists the main operations you can perform with the rpm
command and the command-line options to specify the given
operations.
</para>
<para>
Table 3-1 The main rpm operations
</para>
<informaltable frame="all">
<tgroup cols="3">
<tbody>
<row>
<entry>
<para>
Operation
</para>
</entry>
<entry>
<para>
Short Option
</para>
</entry>
<entry>
<para>
Long Option
</para>
</entry>
</row>
<row>
<entry>
<para>
Upgrade/install
</para>
</entry>
<entry>
<para>
-U
</para>
</entry>
<entry>
<para>
--upgrade
</para>
</entry>
</row>
<row>
<entry>
<para>
Install
</para>
</entry>
<entry>
<para>
-I
</para>
</entry>
<entry>
<para>
--install
</para>
</entry>
</row>
<row>
<entry>
<para>
Remove
</para>
</entry>
<entry>
<para>
-e
</para>
</entry>
<entry>
<para>
--erase
</para>
</entry>
</row>
<row>
<entry>
<para>
Query
</para>
</entry>
<entry>
<para>
-q
</para>
</entry>
<entry>
<para>
--query
</para>
</entry>
</row>
<row>
<entry>
<para>
Verify
</para>
</entry>
<entry>
<para>
-V
</para>
</entry>
<entry>
<para>
--verify
</para>
</entry>
</row>
<row>
<entry>
<para>
Check signature
</para>
</entry>
<entry>
<para>
-K
</para>
</entry>
<entry>
<para>
--checksig
</para>
</entry>
</row>
<row>
<entry>
<para>
Freshen (upgrade) already-installed package
</para>
</entry>
<entry>
<para>
-F
</para>
</entry>
<entry>
<para>
--freshen
</para>
</entry>
</row>
<row>
<entry>
<para>
Initialize database
</para>
</entry>
<entry>
<para>
None
</para>
</entry>
<entry>
<para>
--initdb
</para>
</entry>
</row>
<row>
<entry>
<para>
Rebuild database
</para>
</entry>
<entry>
<para>
None
</para>
</entry>
<entry>
<para>
--rebuilddb
</para>
</entry>
</row>
</tbody>
</tgroup>
</informaltable>
<para>
Using Table 3-1 as a guide, you can explore the options to the
rpm command. To install or upgrade a package, use the -U
command-line option:
</para>
<para>
# rpm -U filename.rpm
</para>
<para>
For example, to install the xcopilot RPM used as an example in
this chapter,
</para>
<para>
run the following command:
</para>
<para>
# rpm -U xcopilot-0.6.6-3.i386.rpm
</para>
<para>
To get extra feedback, you can use a command like the following,
with the
</para>
<para>
-h and -v options in conjunction with the ���U option:
</para>
<para>
# rpm -Uhv xcopilot-0.6.6-3.i386.rpm
</para>
<para>
When you run this command you will see more output than the
default, which is no output unless there are errors. With the
���h option, the rpm command will print a series of hash marks,
#, to provide feedback that the command is still running. With
the ���v option, the rpm command provides more verbose messages.
</para>
<para>
Note
</para>
<para>
The most common command to install a package is:
</para>
<para>
# rpm -Uhv package_file.rpm
</para>
<para>
This command upgrades a package with extra output. If the
package has not been installed, this command installs the
package. See Chapter 4 for more on upgrading and installing.
</para>
<para>
To remove a package (called erase in RPM terminology), use the
���e command-line option:
</para>
<para>
# rpm ���e package_name
</para>
<para>
Note
</para>
<para>
Notice that you install a package file using the file name that
ends in .rpm, but uninstall or erase a package without the .rpm
extension. This is because you install RPM files, but once
installed, you work with the installed packages. The file name
and the package name do not have to correspond, but typically
(and sanely) they have the same base name.
</para>
<para>
To list every RPM package installed on your system, use a
command like the following.
</para>
<para>
$ rpm ���qa
</para>
<para>
Expect to wait while this command completes. Most Linux systems
have numerous packages installed, which will result in many
lines of output. To better see the output, you can pipe this
command to the more command, as shown following:
</para>
<para>
rpm ���qa | more
</para>
<para>
You will then see the package listing one screen at a time.
</para>
<para>
Cross Reference
</para>
<para>
Appendix A lists all the options for the rpm command.
</para>
</sect2>
<sect2>
<title>Other RPM commands</title>
<para>
In addition to rpm, the RPM system includes a few more commands,
including rpmbuild and rpm2cpio.
</para>
<para>
The rpmbuild command helps build RPM packages. I describe its
usage in depth in Part II of this book.
</para>
<para>
The rpm2cpio command exports an RPM package file into the format
that the cpio command expects. The cpio command works with many
tape-backup packages. You can also take advantage of the fact
that cpio can list the individual files in a cpio archive or
extract files. To list the files in an RPM package, use a
command like the following:
</para>
<para>
$ rpm2cpio package_file.rpm | cpio ���t
</para>
<para>
For example, the following command lists all the files in the
xcopilot package:
</para>
<para>
$ rpm2cpio xcopilot-0.6.6-3.i386.rpm | cpio ���t
</para>
<para>
/etc/X11/applink/Applications/xcopilot.desktop
</para>
<para>
usr/bin/xcopilot
</para>
<para>
usr/doc/xcopilot-0.6.6
</para>
<para>
usr/doc/xcopilot-0.6.6/README
</para>
<para>
usr/include/X11/pixmaps/xcopilot.xpm
</para>
<para>
usr/include/X11/pixmaps/xcopilot2.xpm
</para>
<para>
3120 blocks
</para>
<para>
The rpm2cpio command can also help if you want to extract a
single file from the RPM package, using the cpio ���ivd
command-line options, as follows:
</para>
<para>
$ rpm2cpio xcopilot-0.6.6-3.i386.rpm | cpio ���ivd
usr/doc/xcopilot-0.6.6/README
</para>
<para>
This command will output local usr/doc/xcopilot-0.6.6
subdirectories and the README file located under
usr/doc/xcopilot-0.6.6.
</para>
<para>
The ���i option tells cpio to extract files. The ���d option
tells cpio to make any local subdirectories as needed
(usr/doc/xcopilot-0.6.6, in this example), and the ���v option
asks cpio to politely output verbose messages about what it
does. Of course, verbose is in the eye of the beholder; with
many Unix and Linux commands, verbose output is still somewhat
terse.
</para>
</sect2>
</sect1>
<sect1>
<title>Summary</title>
<para>
The RPM files, the RPM database, and the RPM commands are the
primary components that make up the RPM system. This chapter
introduces you to the format and types of RPM files, the
importance of maintaining the database, and the basic rpm command.
</para>
<para>
The next chapter covers the most frequently used RPM commands.
These commands allow you to install, uninstall, and update RPM
packages.
</para>
</sect1>
</chapter>
<!--
Local variables:
mode: xml
sgml-parent-document:("rpm-guide-en.xml" "book" "chapter")
fill-column: 72
End:
-->