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,
docs-commits@lists.fedoraproject.org