rpm-guide rpm-guide-intro-rpm-en.xml,1.1,1.2

Stuart Ellis (elliss) fedora-docs-commits at redhat.com
Tue Oct 25 00:33:00 UTC 2005 

Author: elliss

Update of /cvs/docs/rpm-guide
In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv7619

Modified Files:
	rpm-guide-intro-rpm-en.xml 
Log Message:

Tagging and minor style edits



Index: rpm-guide-intro-rpm-en.xml
===================================================================
RCS file: /cvs/docs/rpm-guide/rpm-guide-intro-rpm-en.xml,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- rpm-guide-intro-rpm-en.xml	4 Oct 2005 01:53:01 -0000	1.1
+++ rpm-guide-intro-rpm-en.xml	25 Oct 2005 00:32:57 -0000	1.2
@@ -1,62 +1,53 @@
-<!-- $Id: --> 
-<chapter id="ch-intro-rpm">
-<title>Introduction to RPM</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>
-    *Examining the history of package management
-  </para>
-
-  <para>
-    *Introducing RPM features
-  </para>
+<!-- $Id: -->
 
+<chapter id="ch-intro-rpm">
+  <title>Introduction to RPM</title>
   <para>
-    *Getting acquainted with RPM terminology
+    This chapter covers:
   </para>
-
+  <itemizedlist>
+    <listitem>
+      <para>
+        Examining the history of package management
+      </para>
+    </listitem>
+    <listitem>
+      <para>
+        Introducing RPM features
+      </para>
+    </listitem>
+    <listitem>
+      <para>
+        Getting acquainted with RPM terminology
+      </para>
+    </listitem>
+  </itemizedlist>
   <para>
-    Several package managers—software that tracks and manipulates the
-    applications installed on the system—are available for Linux. The
-    most widely used of these Linux package managers is the RPM Package
-    Manager (formerly the Red Hat Package Manager), or RPM for short,
-    the subject of this book
+    Several package managers are available for Linux to track and
+    manipulate the applications installed on the system. The most widely
+    used of these Linux package managers is the RPM Package Manager
+    (formerly the Red Hat Package Manager), or RPM for short, the
+    subject of this book
   </para>
-
   <para>
-    Although RPM was initially developed for Red Hat Linux, a
-    combination of technical features and good timing has resulted in
-    RPM’s becoming the de facto standard for packaging software on
-    most Linux distributions. The fact that Red Hat released the source
-    code to the RPM software under an open-source license also helped
-    its adoption.
+    Although RPM was initially developed for &RHL;, a combination of
+    technical features and good timing has resulted in RPM’s becoming
+    the de facto standard for packaging software on most Linux
+    distributions. The fact that &RH; released the source code to the
+    RPM software under an open-source license also helped its adoption.
   </para>
-
   <para>
     More recently, the RPM package file format has been adopted as the
     official standard for Linux as part of the Linux Standards Base, or
-    LSB. Described at www.linuxbase.org/, the Linux Standards Base is an
-    attempt to set a baseline that all Linux distributions should
-    follow. Some vendors have been pulled in kicking and screaming, but
-    the LSB for the most part has really helped the job of system
-    administrators by providing some commonality across distributions,
-    as in the location of certain files. The history of Linux package
-    managers is largely intertwined with the history of Linux
-    distributions.
+    LSB. Described at <ulink url="http://www.linuxbase.org/"/>, the
+    Linux Standards Base is an attempt to set a baseline that all Linux
+    distributions should follow. Some vendors have been pulled in
+    kicking and screaming, but the LSB for the most part has really
+    helped the job of system administrators by providing some
+    commonality across distributions, as in the location of certain
+    files. The history of Linux package managers is largely intertwined
+    with the history of Linux distributions.
   </para>
-
   <para>
     Strictly speaking, Linux refers to a single piece of software, the
     Unix-like kernel that Linus Torvalds and cohorts have scattered all
@@ -69,7 +60,6 @@
     such as watches and PDAs, to desktop and server systems, all the way
     up to mainframes and supercomputing clusters.
   </para>
-
   <sect1>
     <title>The Need for Linux Package Management Systems</title>
     <para>
@@ -83,16 +73,18 @@
       Despite this controversy, it is clear that most users of Linux
       require both the Linux kernel and a large suite of accompanying
       software (a shared C library; traditional Unix utilities such as
-      grep, awk, and sed; an editor, such as vi; a shell, such as the
-      Bourne-Again "bash" shell; and so forth) to complete the various
-      tasks for which they typically employ Linux.
+      <command>grep</command>, <command>awk</command>, and
+      <command>sed</command>; an editor, such as <command>vi</command>;
+      a shell, such as the Bourne-Again <command>bash</command> shell;
+      and so forth) to complete the various tasks for which they
+      typically employ Linux.
     </para>
     <para>
       Users expect Linux to include server software such as the Apache
       Web server, desktop software such as the OpenOffice.org office
       productivity suite, and a host of other packages. In fact, most
       Linux users don’t make the distinction between the kernel
-      (technically the only part that is “Linux”) and all the extra
+      (technically the only part that is Linux) and all the extra
       packages (technically “everything else”) that comes with a
       Linux distribution. Most users simply refer to the whole thing as
       “Linux.”
@@ -175,25 +167,27 @@
       related applications, but what was really needed was installation
       and uninstallation on an application-by-application basis.
     </para>
+<!-- SE: Note that "Red Hat" should not replaced by entities when part of abbreviations -->
     <para>
       In late 1993, Rik Faith, Doug Hoffman, and Kevin Martin began
       releasing the first public betas of the BOGUS Linux distribution.
-      BOGUS was notable for the package management system (pms) software
-      that was used with it for installation and uninstallation of all
-      software on an application-by-application basis. Shortly
-      thereafter, in the summer of 1994, the first public betas of Red
-      Hat Commercial Linux were released. Red Hat initially used Red Hat
-      Software Program Packages (RPP) as the basis of its Linux
-      distribution. Like pms, RPP was a system-management tool that
+      BOGUS was notable for the package management system
+      (<command>pms</command>) software that was used with it for
+      installation and uninstallation of all software on an
+      application-by-application basis. Shortly thereafter, in the
+      summer of 1994, the first public betas of Red Hat Commercial Linux
+      were released. &RH; initially used Red Hat Software Program
+      Packages (RPP) as the basis of its Linux distribution. Like
+      <command>pms</command>, RPP was a system-management tool that
       allowed for easy installation and uninstallation of applications.
       In late 1993, Ian Murdock founded the Debian Gnu/Linux
-      distribution. He began seriously developing its dpkg
-      application-management software by the summer of 1994. Like pms
-      and RPP, dpkg made it possible to manage each application on the
-      system.
+      distribution. He began seriously developing its
+      <command>dpkg</command> application-management software by the
+      summer of 1994. Like <command>pms</command> and RPP,
+      <command>dpkg</command> made it possible to manage each
+      application on the system.
     </para>
   </sect1>
-
   <sect1>
     <title>RPM Design Goals</title>
     <para>
@@ -215,42 +209,60 @@
     </para>
     <para>
       Because of these concerns, after their initial releases of
-      RPP-based distributions, Red Hat looked closely at both their own
-      RPP software and other software such as BOGUS's pms software.
-      Developers at Red Hat, particularly Marc Ewing and Erik Troan, set
-      out to develop what they initially called the Red Hat Package
-      Manager (RPM). Based on experiences with earlier Linux packaging
-      software and knowledge about packaging tools used on other
-      platforms, Red Hat had several design goals in mind when they
+      RPP-based distributions, &RH; looked closely at both their own RPP
+      software and other software such as BOGUS's <command>pms</command>
+      software. Developers at &RH;, particularly Marc Ewing and Erik
+      Troan, set out to develop what they initially called the Red Hat
+      Package Manager (RPM). Based on experiences with earlier Linux
+      packaging software and knowledge about packaging tools used on
+      other platforms, &RH; had several design goals in mind when they
       developed RPM. These design points include the following features:
     </para>
+    <itemizedlist>
+      <listitem>
+        <para>
+          Ease of use
+        </para>
+      </listitem>
+      <listitem>
+        <para>
+          Package-oriented focus
+        </para>
+      </listitem>
+      <listitem>
+        <para>
+          Upgradability of packages
+        </para>
+      </listitem>
+      <listitem>
+        <para>
+          Tracking of package interdependencies
+        </para>
+      </listitem>
+      <listitem>
+        <para>
+          Query capabilities
+        </para>
+      </listitem>
+      <listitem>
+        <para>
+          Verification
+        </para>
+      </listitem>
+      <listitem>
+        <para>
+          Support for multiple architectures
+        </para>
+      </listitem>
+      <listitem>
+        <para>
+          Use of pristine sources
+        </para>
+      </listitem>
+    </itemizedlist>
     <para>
-      *Ease of use
-    </para>
-    <para>
-      *Package-oriented focus
-    </para>
-    <para>
-      *Upgradability of packages
-    </para>
-    <para>
-      *Tracking of package interdependencies
-    </para>
-    <para>
-      *Query capabilities
-    </para>
-    <para>
-      *Verification
-    </para>
-    <para>
-      *Support for multiple architectures
-    </para>
-    <para>
-      *Use of pristine sources
-    </para>
-    <para>
-      The following sections demonstrate how Red Hat incorporated each
-      of these design goals into RPM.
+      The following sections demonstrate how &RH; incorporated each of
+      these design goals into RPM.
     </para>
     <sect2>
       <title>Ease of use</title>
@@ -259,38 +271,55 @@
         to use. Manual software installation has been the primary method
         of putting software onto Unix boxes for over 30 years now and
         has worked very well for those three decades. To offer a
-        compelling reason to use the new software, Red Hat's RPM must be
+        compelling reason to use the new software, RPM must be
         significantly easier to use than other Linux package-management
         tools. For that reason, most tasks that can be handled using RPM
         were designed to be carried out via a single command. For
         example, software installation using RPM requires a single
-        command (rpm -U software_package), while manual software
-        installation using older manual methods typically requires at
-        least six steps to complete the same task:
-      </para>
-      <para>
-        1.tar zxf software_package
-      </para>
-      <para>
-        2.cd software_package
-      </para>
-      <para>
-        3../configure
-      </para>
-      <para>
-        4.make
-      </para>
-      <para>
-        5.su
-      </para>
-      <para>
-        6.make install
-      </para>
+        command (<userinput>rpm -U software_package</userinput>), while
+        manual software installation using older manual methods
+        typically requires at least six steps to complete the same task:
+      </para>
+      <orderedlist>
+        <listitem>
+          <para>
+            <command>tar zxf
+            <replaceable>software_package</replaceable></command>
+          </para>
+        </listitem>
+        <listitem>
+          <para>
+            <command>cd
+            <replaceable>software_package</replaceable></command>
+          </para>
+        </listitem>
+        <listitem>
+          <para>
+            <command>./configure</command>
+          </para>
+        </listitem>
+        <listitem>
+          <para>
+            <command>make</command>
+          </para>
+        </listitem>
+        <listitem>
+          <para>
+            <command>su</command>
+          </para>
+        </listitem>
+        <listitem>
+          <para>
+            <command>make install</command>
+          </para>
+        </listitem>
+      </orderedlist>
       <para>
         Similarly, removal of applications installed using RPM requires
-        a single command (rpm -e software_package); manual removal of an
-        installed application requires that each file associated with
-        that application be manually deleted.
+        a single command (<userinput>rpm -e
+        <replaceable>software_package</replaceable></userinput>); manual
+        removal of an installed application requires that each file
+        associated with that application be manually deleted.
       </para>
     </sect2>
     <sect2>
@@ -330,11 +359,12 @@
         Apache's configuration information, which specifies things such
         as which files on the system should be made available as Web
         pages and who should be able to access those Web pages, is
-        stored in a text file, typically /etc/httpd/conf/httpd.conf.
-        Suppose Apache has been installed using RPM and that you have
-        then customized httpd.conf to specify its configuration. If you
-        upgrade Apache using RPM, as part of the upgrade procedure, the
-        RPM application will take precautions to preserve the
+        stored in a text file, typically
+        <filename>/etc/httpd/conf/httpd.conf</filename>. Suppose Apache
+        has been installed using RPM and that you have then customized
+        <filename>httpd.conf</filename> to specify its configuration. If
+        you upgrade Apache using RPM, as part of the upgrade procedure,
+        the RPM application will take precautions to preserve the
         customizations you have made to the Apache configuration. In
         contrast, manual upgrades of applications often overwrite any
         existing configuration files, losing all site customizations the
@@ -347,12 +377,12 @@
         Software that manages the applications installed on the system
         on an application level (such as RPM) does have one potential
         drawback in comparison with system-wide software management
-        systems (such as PC operating systems like Microsoft's Windows
-        or IBM's OS/2, which allow the entire system to be upgraded but
-        do not generally allow individual components to be upgraded,
-        added, or removed). Software applications often have
-        interdependencies; some applications work only when other
-        applications are installed.
+        systems (such as PC operating systems like Microsoft Windows or
+        OS/2, which allow the entire system to be upgraded but do not
+        generally allow individual components to be upgraded, added, or
+        removed). Software applications often have interdependencies;
+        some applications work only when other applications are
+        installed.
       </para>
       <para>
         The Postfix and Sendmail mail transfer agent (MTA) applications
@@ -379,35 +409,39 @@
         components, ensuring that all can still interoperate. On
         Microsoft Windows 2000, IIS (the application used on Windows to
         serve Web pages) requires several other applications such as
-        EventLog (the Windows application that records system events,
-        much like the Linux syslogd and klogd software) to be present.
-        Since Windows is managed on a system level, not a package level,
-        this dependency is guaranteed to be satisfied. On Linux systems
-        using RPM, however, the situation is different. On Linux, for
-        example, the Postfix application requires the syslogd
-        application, which records system events. However, RPM provides
-        the flexibility to install some applications but not install
-        others or to uninstall others later. When you install Postfix,
-        you have no guarantee that syslogd is already installed. If
-        syslogd is not installed, Postfix will not work correctly.
-      </para>
-      <para>
-        To avoid problems, Red Hat developers realized that RPMs must
-        also track dependency information about what software they
-        require for correct functionality, and that the RPM install and
+        <command>EventLog</command> (the Windows application that
+        records system events, much like the Linux
+        <command>syslogd</command> and <command>klogd</command>
+        software) to be present. Since Windows is managed on a system
+        level, not a package level, this dependency is guaranteed to be
+        satisfied. On Linux systems using RPM, however, the situation is
+        different. On Linux, for example, the Postfix application
+        requires the <command>syslogd</command> application, which
+        records system events. However, RPM provides the flexibility to
+        install some applications but not install others or to uninstall
+        others later. When you install Postfix, you have no guarantee
+        that <command>syslogd</command> is already installed. If
+        <command>syslogd</command> is not installed, Postfix will not
+        work correctly.
+      </para>
+      <para>
+        To avoid problems, &RH; developers realized that RPMs must also
+        track dependency information about what software they require
+        for correct functionality, and that the RPM install and
         uninstall applications must use this dependency information.
         Because of dependencies, installing Postfix using RPM on a
-        system without syslogd installed generates a warning that
-        syslogd must also be installed. Similarly, attempting to
-        uninstall syslogd from a system that already has Postfix
-        installed generates a warning that installed applications
-        require the software that is being deleted. These warnings can
-        be overridden if necessary, but by default RPM enforces these
-        dependencies (refusing, for example, to let you uninstall
-        syslogd without also uninstalling applications that require it,
-        such as Postfix), preventing you from accidentally breaking
-        applications by inadvertently uninstalling other software that
-        they require to operate.
+        system without <command>syslogd</command> installed generates a
+        warning that <command>syslogd</command> must also be installed.
+        Similarly, attempting to uninstall <command>syslogd</command>
+        from a system that already has Postfix installed generates a
+        warning that installed applications require the software that is
+        being deleted. These warnings can be overridden if necessary,
+        but by default RPM enforces these dependencies (refusing, for
+        example, to let you uninstall <command>syslogd</command> without
+        also uninstalling applications that require it, such as
+        Postfix), preventing you from accidentally breaking applications
+        by inadvertently uninstalling other software that they require
+        to operate.
       </para>
     </sect2>
     <sect2>
@@ -429,21 +463,21 @@
       <para>
         RPM also maintains a variety of information about each installed
         file in this system database, such as what permissions each file
-        should have and what size each file should be. Red Hat
-        developers designed this database to be useful for software
-        verification. Over time, installed software will fail to work
-        for reasons as mundane as the system administrator setting
-        incorrect permissions on files or as exotic as nuclear decay of
-        one of the computer's atoms releasing an alpha particle that can
-        affect the computer's memory, corrupting that bit of memory and
-        causing errors. Although RPM cannot prevent all errors that
-        cause installed software to fail (obviously, there's not a
-        single thing any software can do to prevent nuclear decay), it
-        can be used to eliminate common errors. When an application
-        fails, you can use the RPM database to make sure that all files
-        associated with that application still have correct Unix file
-        permissions and that no files associated with that application
-        have become altered or corrupted.
+        should have and what size each file should be. &RH; developers
+        designed this database to be useful for software verification.
+        Over time, installed software will fail to work for reasons as
+        mundane as the system administrator setting incorrect
+        permissions on files or as exotic as nuclear decay of one of the
+        computer's atoms releasing an alpha particle that can affect the
+        computer's memory, corrupting that bit of memory and causing
+        errors. Although RPM cannot prevent all errors that cause
+        installed software to fail (obviously, there's not a single
+        thing any software can do to prevent nuclear decay), it can be
+        used to eliminate common errors. When an application fails, you
+        can use the RPM database to make sure that all files associated
+        with that application still have correct Unix file permissions
+        and that no files associated with that application have become
+        altered or corrupted.
       </para>
     </sect2>
     <sect2>
@@ -468,8 +502,8 @@
         series of processors were among the first additional CPUs that
         Linux supported. These days, Linux supports dozens of CPU
         architectures.) This posed a problem for distribution developers
-        such as Red Hat and Debian and for application vendors who
-        desired to package their software for use on Linux. Because the
+        such as &RH; and Debian, and for application vendors who desired
+        to package their software for use on Linux. Because the
         available packaging methods could not produce packages for
         multiple architectures, packagers making software for multiple
         CPUs had to do extra work to prepare their packages.
@@ -481,7 +515,7 @@
         machine types they could install the packages.
       </para>
       <para>
-        Red Hat decided to overcome these limitations by incorporating
+        &RH; decided to overcome these limitations by incorporating
         architecture support into RPM, adding features so that the basic
         setup a packager performs to create a package could be leveraged
         to produce packages that would run on various CPUs, and so that
@@ -492,19 +526,19 @@
     <sect2>
       <title>Pristine sources</title>
       <para>
-        The BOGUS distribution's pms packaging system introduced the use
-        of pristine source code to prepare packages. With Red Hat's
-        early RPP package system and other similar early efforts,
-        software packagers would compile software manually, then run
-        commands to produce a package of that compiled software. Any
-        changes made to the application's original source code were not
-        recorded and would have to be recreated by the next person to
-        package that software. Furthermore, end users wanting to know
-        what changes had been made to the software they were running had
-        no method of accessing that information.
+        The BOGUS distribution's <command>pms</command> packaging system
+        introduced the use of pristine source code to prepare packages.
+        With Red Hat's early RPP package system and other similar early
+        efforts, software packagers would compile software manually,
+        then run commands to produce a package of that compiled
+        software. Any changes made to the application's original source
+        code were not recorded and would have to be recreated by the
+        next person to package that software. Furthermore, end users
+        wanting to know what changes had been made to the software they
+        were running had no method of accessing that information.
       </para>
       <para>
-        With RPM, Red Hat developed a package system that produced two
+        With RPM, &RH; developed a package system that produced two
         types of packages: binary and source. Binary packages are
         compiled software that can be installed and used. Source
         packages contain the source code for that software, along with a
@@ -523,7 +557,6 @@
       </para>
     </sect2>
   </sect1>
-
   <sect1>
     <title>RPM Terminology</title>
     <para>
@@ -540,82 +573,102 @@
     </para>
     <para>
       To help in installation and management, all package files are
-      labeled with highly identifiable names. Red Hat Linux package
-      files have four-part names, which typically look something like:
-    </para>
-    <para>
-      kernel-smp-2.4.18-3.athlon.rpm
-    </para>
-    <para>
-      kernel-smp-2.4.18-3.i586.rpm
-    </para>
-    <para>
-      kernel-smp-2.4.18-3.i686.rpm
-    </para>
-    <para>
-      kernel-source-2.4.18-3.i386.rpm
-    </para>
-    <para>
-      rootfiles-7.2-1.noarch.rpm
+      labeled with highly identifiable names. Package files have
+      four-part names, which typically look something like:
     </para>
+    <itemizedlist>
+      <listitem>
+        <para>
+          <filename>kernel-smp-2.4.18-3.athlon.rpm</filename>
+        </para>
+      </listitem>
+      <listitem>
+        <para>
+          <filename>kernel-smp-2.4.18-3.i586.rpm</filename>
+        </para>
+      </listitem>
+      <listitem>
+        <para>
+          <filename>kernel-smp-2.4.18-3.i686.rpm</filename>
+        </para>
+      </listitem>
+      <listitem>
+        <para>
+          <filename>kernel-source-2.4.18-3.i386.rpm</filename>
+        </para>
+      </listitem>
+      <listitem>
+        <para>
+          <filename>rootfiles-7.2-1.noarch.rpm</filename>
+        </para>
+      </listitem>
+    </itemizedlist>
     <para>
       Here, the four parts of each name are separated from each other by
       dashes or periods. The structure of the package file name is
     </para>
     <para>
-      name-version-release.architecture.rpm
+      <filename>name-version-release.architecture.rpm</filename>
     </para>
     <para>
       The name identifies what software is contained within the archive
       file. Typically, this is a name of an application or package that
-      the archive installs on the system. For example, kernel-smp can be
-      installed to provide a very important application, the SMP
-      (symmetric multiprocessing, meaning it supports systems with more
-      than one CPU in them) version of the Linux kernel, on the system.
-      Sometimes, rather than an application, the software is a
-      collection of other files needed on the system. The rootfiles
-      package, for example, is not an application but is a collection of
-      basic environmental configuration files for the root user's
-      account (such as /root/.bashrc, the root user's Bash configuration
-      file) that provides a usable, preconfigured working environment
-      for the root user on Red Hat Linux systems.
-    </para>
-    <para>
-      The second field in every Red Hat Linux package file's name is the
-      version field. This field identifies the version number of the
-      software that is contained in the package file. For example,
-      kernel-smp-2.4.18 indicates the RPM holds the 2.4.18 release of
-      the SMP version of the Linux kernel, and rootfiles-7.2 is the 7.2
-      release of the rootfiles configuration files.
-    </para>
-    <para>
-      Every Red Hat Linux package file name also has a third component:
-      the release field. This field identifies which release of that
-      version of the software the package file contains. Package files
-      contain both software and instructions about how to install that
-      software. As packages of a particular version of software are
-      being prepared, mistakes are sometimes made in these instruction
-      files, or bugs are sometimes fixed within a software version; more
-      recent package files of that software version need to be prepared
-      that correct the problem. The –1 in the rootfiles-7.2-1 package
-      shows this is the first release of the 7.2 version of the
-      rootfiles software. The packager of rootfiles version 7.2 got
-      everything right on the first try and had no need to prepare more
-      than one release. The –3 in the kernel-smp-2.4.18-3 package, on
-      the other hand, is the third release of the 2.4.18 version of the
-      SMP-capable Linux kernel. This release incorporates new patches to
-      fix bugs present in older releases of the 2.4.18 version of the
-      Linux SMP kernel. The software packager increased the release
-      number so that end users could distinguish the more recent,
-      bug-fixed package file from the older, less bug-free package file.
-    </para>
-    <para>
-      The final field in Red Hat Linux package file names is the
-      architecture, which identifies the system types for which the
-      package file is appropriate. For example, the
-      kernel-smp-2.4.18-3.athlon package is intended for use on machines
-      with an AMD Athlon CPU, and kernel-smp-2.4.18-3.i586 is intended
-      for use on machines with an i586 (Pentium-class) CPU or better. An
+      the archive installs on the system. For example,
+      <filename>kernel-smp</filename> can be installed to provide a very
+      important application, the SMP (symmetric multiprocessing, meaning
+      it supports systems with more than one CPU in them) version of the
+      Linux kernel, on the system. Sometimes, rather than an
+      application, the software is a collection of other files needed on
+      the system. The <filename>rootfiles</filename> package, for
+      example, is not an application but is a collection of basic
+      environmental configuration files for the
+      <systemitem class="username">root</systemitem> user's account
+      (such as <filename>/root/.bashrc</filename>, the
+      <systemitem class="username">root</systemitem> user's Bash
+      configuration file) that provides a usable, preconfigured working
+      environment for the <systemitem class="username">root</systemitem>
+      user.
+    </para>
+    <para>
+      The second field in every package file's name is the version
+      field. This field identifies the version number of the software
+      that is contained in the package file. For example,
+      <filename>kernel-smp-2.4.18</filename> indicates the RPM holds the
+      2.4.18 release of the SMP version of the Linux kernel, and
+      <filename>rootfiles-7.2</filename> is the 7.2 release of the
+      <filename>rootfiles</filename> configuration files.
+    </para>
+    <para>
+      Every package file name also has a third component: the release
+      field. This field identifies which release of that version of the
+      software the package file contains. Package files contain both
+      software and instructions about how to install that software. As
+      packages of a particular version of software are being prepared,
+      mistakes are sometimes made in these instruction files, or bugs
+      are sometimes fixed within a software version; more recent package
+      files of that software version need to be prepared that correct
+      the problem. The –1 in the <filename>rootfiles-7.2-1</filename>
+      package shows this is the first release of the 7.2 version of the
+      <filename>rootfiles</filename> software. The packager of
+      <filename>rootfiles</filename> version 7.2 got everything right on
+      the first try and had no need to prepare more than one release.
+      The –3 in the <filename>kernel-smp-2.4.18-3</filename> package,
+      on the other hand, is the third release of the 2.4.18 version of
+      the SMP-capable Linux kernel. This release incorporates new
+      patches to fix bugs present in older releases of the 2.4.18
+      version of the Linux SMP kernel. The software packager increased
+      the release number so that end users could distinguish the more
+      recent, bug-fixed package file from the older, less bug-free
+      package file.
+    </para>
+    <para>
+      The final field in package file names is the architecture, which
+      identifies the system types for which the package file is
+      appropriate. For example, the
+      <filename>kernel-smp-2.4.18-3.athlon</filename> package is
+      intended for use on machines with an AMD Athlon CPU, and
+      <filename>kernel-smp-2.4.18-3.i586</filename> is intended for use
+      on machines with an i586 (Pentium-class) CPU or better. An
       architecture name of noarch indicates this is a special
       architecture such that the files in the package work on any
       architecture. Typically, this is because the files are all
@@ -627,7 +680,7 @@
       4.1.
     </para>
     <para>
-      Table 2-1Supported Architectures
+      Table 2-1 Supported Architectures
     </para>
     <informaltable frame="all">
       <tgroup cols="2">
@@ -792,32 +845,32 @@
         </tbody>
       </tgroup>
     </informaltable>
-    <para>
-      Tip
-    </para>
-    <para>
-      When choosing an appropriate architecture for your machine, be
-      aware that more recent architectures typically run software that
-      targets older architectures within the same family; the reverse,
-      however, is not true. For example, within the 32-bit
-      Intel-compatible architectures, a 686-class (Pentium II / III /
-      IV) machine runs files within i386, i486, i586, and i686 RPM
-      package files, but a 386-class (80386) machine runs files within
-      i386 RPM package files only. Similarly, for the Alpha
-      architecture, more recent Alpha EV68 CPUs can run programs from
-      RPM package files with alphaev67, alphaev6, alphaev56, alphaev5,
-      and alpha architectures, but an older Alpha EV56 machine can run
-      programs from RPM package files with alpha, alphaev5, or alphaev56
-      architectures only.
-    </para>
+    <tip>
+      <title>Architecture Compatibility</title>
+      <para>
+        When choosing an appropriate architecture for your machine, be
+        aware that more recent architectures typically run software that
+        targets older architectures within the same family; the reverse,
+        however, is not true. For example, within the 32-bit
+        Intel-compatible architectures, a 686-class (Pentium II / III /
+        IV) machine runs files within i386, i486, i586, and i686 RPM
+        package files, but a 386-class (80386) machine runs files within
+        i386 RPM package files only. Similarly, for the Alpha
+        architecture, more recent Alpha EV68 CPUs can run programs from
+        RPM package files with alphaev67, alphaev6, alphaev56, alphaev5,
+        and alpha architectures, but an older Alpha EV56 machine can run
+        programs from RPM package files with alpha, alphaev5, or
+        alphaev56 architectures only.
+      </para>
+    </tip>
     <para>
       Notice that the four fields in RPM package file names are
       separated from each other by punctuation, either a dash (-) or a
       period (.). Periods and dashes, however, are also allowed within
-      fields. 7.2 is a valid version number, just as kernel-source is a
-      valid software name. Finally, keep in mind that all RPM package
-      files use an .rpm file-name extension to denote that they are
-      RPMs.
+      fields. 7.2 is a valid version number, just as
+      <filename>kernel-source</filename> is a valid software name.
+      Finally, keep in mind that all RPM package files use an .rpm
+      file-name extension to denote that they are RPMs.
     </para>
     <para>
       Once installed, package names are slightly different from package
@@ -825,24 +878,28 @@
       Internet, copied off of CDs, and otherwise easily transferred
       between machines, always have names that looks like
       name-version-release.architecture.rpm. Installed packages,
-      however, have names that look like name-version-release. Once
-      installed, packages are referred to without the architecture field
-      and the .rpm extension. Furthermore, installed packages consist of
-      lots of files, not a single RPM file. For example, the package
-      file kernel-smp-2.4.18-3.i686.rpm after installation is referred
-      to as kernel-smp-2.4.18-3. To simplify usage even further,
-      installed packages can be referred to by their name field only, so
-      this file would become simply kernel-smp.
-    </para>
-    <para>
-      Warning
-    </para>
-    <para>
-      Once installed, the name of the package does not have to be the
-      same as the name portion of the original package file. By
-      convention though, the package name matches the name, version, and
-      release part of the file name.
+      however, have names that look like
+      <filename>name-version-release</filename>. Once installed,
+      packages are referred to without the architecture field and the
+      .rpm extension. Furthermore, installed packages consist of lots of
+      files, not a single RPM file. For example, the package file
+      <filename>kernel-smp-2.4.18-3.i686.rpm</filename> after
+      installation is referred to as
+      <filename>kernel-smp-2.4.18-3</filename>. To simplify usage even
+      further, installed packages can be referred to by their name field
+      only, so this file would become simply
+      <filename>kernel-smp</filename>.
     </para>
+    <warning>
+      <title>Software Names May Differ from Package Names</title>
+
+      <para>
+        Once installed, the name of the package does not have to be the
+        same as the name portion of the original package file. By
+        convention though, the package name matches the name, version,
+        and release part of the file name.
+      </para>
+    </warning>
     <para>
       Usage of the name field by itself to name packages assumes that
       multiple versions or releases of that particular software are not
@@ -852,42 +909,47 @@
       uses an SMP-capable Linux kernel. On it, I have the following
       Linux SMP kernels installed:
     </para>
-    <para>
-      $ rpm -q kernel-smp
-    </para>
-    <para>
-      kernel-smp-2.4.18-4
-    </para>
-    <para>
-      kernel-smp-2.4.18-3
-    </para>
-    <para>
-      kernel-smp-2.5.21-4
-    </para>
-    <para>
-      $
-    </para>
-    <para>
-      This example uses the rpm –q command to query for all installed
-      versions of the given package, kernel-smp.
-    </para>
-    <para>
-      Cross Reference
-    </para>
-    <para>
-      Chapter 5 covers querying the RPM database in depth.
+    <itemizedlist>
+      <listitem>
+        <para>
+          kernel-smp-2.4.18-4
+        </para>
+      </listitem>
+      <listitem>
+        <para>
+          kernel-smp-2.4.18-3
+        </para>
+      </listitem>
+      <listitem>
+        <para>
+          kernel-smp-2.5.21-4
+        </para>
+      </listitem>
+    </itemizedlist>
+    <para>
+      This example uses the <command>rpm <option>–q</option></command>
+      command to query for all installed versions of the given package,
+      <filename>kernel-smp</filename>.
     </para>
+    <note>
+      <title>The RPM Database</title>
+
+      <para>
+        <xref linkend="ch-using-rpm-db"/> covers querying the RPM
+        database in depth.
+      </para>
+    </note>
     <para>
       I have two different package file releases (release 3 and release
       4) of the 2.4.18 version of the Linux kernel, and I have a
       development kernel, version 2.5.21, installed. On this system,
-      since I have multiple packages installed of the kernel-smp
-      software, I have to use the full package name (such as
-      kernel-smp-2.4.18-4) whenever I want to work with my installed
-      kernel-smp packages.
+      since I have multiple packages installed of the
+      <filename>kernel-smp</filename> software, I have to use the full
+      package name (such as <filename>kernel-smp-2.4.18-4</filename>)
+      whenever I want to work with my installed
+      <filename>kernel-smp</filename> packages.
     </para>
   </sect1>
-
   <sect1>
     <title>Summary</title>
     <para>
@@ -909,7 +971,7 @@
       include nearly so many applications. From the OpenOffice.org
       office suite to the Apache Web server, Linux distributions are
       literally packed with applications. As a final point, most other
-      operating systems provide mostly closed-source applications.
+      operating systems provide mainly closed-source applications.
       Linux, on the other hand, includes thousands of open-source
       applications.
     </para>
@@ -919,22 +981,43 @@
       for end users, the solution to these problems helps make the RPM
       system better able to manage user systems:
     </para>
-    <para>
-      *The RPM system tags each package with the processor architecture
-      and allows for multiple versions of the same package to be
-      installed on the same system. RPM also packs all the files in a
-      package into one file, called an RPM file, for easy transfer to
-      other systems.
-    </para>
-    <para>
-      *Most RPM operations such as installing or removing packages
-      require only a single command to run.
-    </para>
-    <para>
-      *The RPM system supports building RPM packages from a pristine set
-      of sources. This means you can reproduce the commands required to
-      build an application, improving quality.
-    </para>
+    <orderedlist>
+      <listitem>
+        <para>
+          Supports Multiple Architectures — The RPM system tags
+          each package with the processor architecture.
+        </para>
+      </listitem>
+      <listitem>
+        <para>
+          Permits Multiple Software Versions in Parallel — RPM
+          allows for multiple versions of the same package to be
+          installed on the same system.
+        </para>
+      </listitem>
+      <listitem>
+        <para>
+          One File Per Program — RPM packs all of the files in a
+          package into one file, called an RPM file, for easy transfer
+          to other systems.
+        </para>
+      </listitem>
+      <listitem>
+        <para>
+          Requires Only One Command Per Action — Most RPM
+          operations such as installing or removing packages require
+          only a single command to run.
+        </para>
+      </listitem>
+      <listitem>
+        <para>
+          Uses Pristine Sourcecode — The RPM system supports
+          building RPM packages from a pristine set of sources. This
+          means you can reproduce the commands required to build an
+          application, improving quality.
+        </para>
+      </listitem>
+    </orderedlist>
     <para>
       This chapter introduced the RPM system and the history behind it.
       The next chapter delves into the RPM basics, including files,

More information about the Fedora-docs-commits mailing list