yum-software-management yum-software-management-en.xml,1.20,1.21

Paul W. Frields (pfrields) fedora-docs-commits at redhat.com
Sat Jul 23 00:18:46 UTC 2005


Author: pfrields

Update of /cvs/docs/yum-software-management
In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv27952

Modified Files:
	yum-software-management-en.xml 
Log Message:
More style editing, through package arch section


Index: yum-software-management-en.xml
===================================================================
RCS file: /cvs/docs/yum-software-management/yum-software-management-en.xml,v
retrieving revision 1.20
retrieving revision 1.21
diff -u -r1.20 -r1.21
--- yum-software-management-en.xml	22 Jul 2005 22:31:08 -0000	1.20
+++ yum-software-management-en.xml	23 Jul 2005 00:18:43 -0000	1.21
@@ -261,19 +261,20 @@
 
         <para>
           All of the software provided by the &FP; is Open Source
-          software, or and can therefore be downloaded and installed
+          software, and can therefore be downloaded and installed
           from the network of &FED; repositories without restrictions.
         </para>
       </note>
 <!-- SE: The key point here is that users can install Fedora packages as many times as they like on as many systems as they like, as opposed to widely prevalent no-cost but not freely redistributable software -->
       <indexterm>
-        <primary>package groups, defined</primary>
+        <primary>package groups</primary>
+	<secondary>defined</secondary>
       </indexterm>
       <para>
-        You may also manage related packages as sets by using the
-        <firstterm>package groups</firstterm> provided by the &FED;
-        repositories. Some third-party repositories add packages to
-        these groups, or provide their packages as additional groups.
+        You may also use the <firstterm>package groups</firstterm>
+	provided by the &FED; repositories to manage related packages as
+	sets. Some third-party repositories add packages to these
+	groups, or provide their packages as additional groups.
       </para>
 <!-- SE: Some repositories use groups and some don't: I've tried to put this nicely. -->
 <!-- SE: Using the admonition for this is not optimal, it just doesn't fit anywhere else. -->
@@ -282,74 +283,86 @@
 
         <para>
           To view a list of all of the available package groups for your
-          &FED; system, run the command <command>yum
-          <option>grouplist</option></command>.
+	  &FED; system, run the command <command>yum
+	    grouplist</command>.
         </para>
       </note>
-
-      <para>
-        Using repositories ensures that you always receive the current
-        version of the software. If several versions of the same package
-        are available then your management utility automatically selects
-        the latest version.
-      </para>
-
-      <para>
-        For all of these reasons you should only manually install
-        software when you are confident that there is no repository that
-        can currently provide it. If a piece of software on your system
-        is not available from a repository then you cannot automatically
-        find or install newer versions. You must keep that product
-        updated yourself.
-      </para>
-
-      <note>
-        <title>Manual Package Installation</title>
-
+<!-- I removed the extra option tag above. I used to do the same thing -->
+<!-- and Karsten and Tammy both cautioned me against overtagging -->
+<!-- commands. [PWF] -->
+      <para>
+        Use repositories to ensure that you always receive current
+	versions of software. If several versions of the same package
+	are available, your management utility automatically selects the
+	latest version.
+      </para>
+
+      <caution>
+	<title>Installing Software not from a Repository</title>
+	<para>
+	  Install software using manual methods only when you are
+	  confident there is no repository which can currently provide
+	  it. You may not be able to manage such software using &FED;
+	  software management utilities. You may need to update that
+	  software with manual methods.
+	</para>
         <para>
           The <command>yum</command> commands shown in this document use
-          repositories as package sources. Refer to
+	  repositories as package sources. Refer to
           <xref linkend="sn-yum-installing-frompackage"/> for details of
-          using <command>yum</command> to manually install software from
-          a package file.
+	  using <command>yum</command> to install software from a
+	  package file.
         </para>
-      </note>
+      </caution>
     </section>
 
     <section id="sn-about-dependencies">
       <title>About Dependencies</title>
       <indexterm>
-        <primary>dependencies, defined</primary>
+        <primary>dependencies</primary>
+	<secondary>defined</secondary>
       </indexterm>
       <para>
-        You must consider package <firstterm>dependencies</firstterm>
-        when manually installing software. To avoid conflicts and
-        inconsistencies Linux distributions supply program library files
-        as separate packages to the applications that use their
-        functions. Many libraries and command-line utilities are used by
-        multiple applications.
+	Some of the files installed on a &FED; distribution are
+	<firstterm>libraries</firstterm> which may provide functions to
+	multiple applications.  When an application requires a specific
+	library, the package which contains that library is a
+	<firstterm>dependency</firstterm>.  To properly install a
+	package, &FED; must first satisfy its dependencies.  The
+	dependency information for a RPM package is stored within the
+	RPM file.
       </para>
 
       <para>
-        Management tools like <command>yum</command> use the information
-        on dependencies stored within packages to ensure that all of the
-        requirements are met when you install an application. The
-        packages for any supporting software are automatically be
-        installed first, if they are not already present on your system.
-        If a new application has requirements that conflict with
-        existing software then the installation process safely aborts
-        without making any changes to your system.
-      </para>
-<!-- SE: Note that this is a generality: the behaviour described is standard for rpm, up2date etc.-->
+        The <command>yum</command> utility uses package dependency data
+	to ensure all its requirements are met during installation. The
+	<command>yum</command> utility automatically installs packages
+	for any required software not already present on your system. If
+	a new application has requirements that conflict with existing
+	software, <command>yum</command> aborts without making any
+	changes to your system.
+      </para>
+<!-- SE: Note that this is a generality: the behaviour described is -->
+<!-- standard for rpm, up2date etc.-->
+
+<!-- I totally understand; however, I've used yum specifically for two -->
+<!-- reasons:  (1) Even though this is a section about concepts, the -->
+<!-- tutorial is still about yum; and more importantly, (2) the -->
+<!-- continual use of "Software management tools such as yum" was -->
+<!-- becoming redundant and unwieldy, and would force us to use very -->
+<!-- awkward sentence structures. -->
+
     </section>
 
     <section id="sn-package-names">
       <title>Understanding Package Names</title>
       <indexterm>
-        <primary>packages, hardware compatibility</primary>
+        <primary>packages</primary>
+	<secondary>hardware compatibility</secondary>
       </indexterm>
       <indexterm>
-        <primary>packages, naming</primary>
+        <primary>packages</primary>
+	<secondary>naming</secondary>
       </indexterm>
       <para>
         Each package file has a long name that indicates several key
@@ -360,17 +373,6 @@
 <filename>tsclient-0.132-4.i386.rpm</filename>
 </screen>
       <para>
-        Use just the name of the package itself with
-        <command>yum</command>, except when it is necessary to specify
-        the exact version or type. For example, use
-        <filename>name-version</filename> to specify the exact version
-        of the application. The package listings provided by
-        <command>yum</command> itself use the format
-        <filename>name.architecture</filename>, to specify the type of
-        computer that the package is intended for.
-      </para>
-
-      <para>
         These naming conventions are valid for the file shown above:
       </para>
 
@@ -383,8 +385,10 @@
         <listitem>
           <para>
             Package name with version number:
-            <filename>tsclient-0.132</filename>
+            <filename>tsclient-0.132-4</filename>
           </para>
+<!-- I'm pretty sure the release number is needed; feel free to check -->
+<!-- this. [PWF] -->
         </listitem>
         <listitem>
           <para>
@@ -395,25 +399,38 @@
       </itemizedlist>
 
       <para>
+        Use only the name of the package with <command>yum</command>,
+	except when the exact version or type is necessary. <remark
+	  role="fixme">When exactly is that required? I fixed the
+	  sentence structure but the meaning is obscure here.
+	  [PWF]</remark> For example, use
+	<filename>name-version</filename> to specify the exact version
+	of the application. The package listings provided by
+	<command>yum</command> use the format
+	<filename>name.architecture</filename> to specify the type of
+	computer for which the package is intended.
+      </para>
+
+      <para>
         The hardware architecture is the <emphasis>minimum</emphasis>
-        type of machine required for that specific package. Packages for
-        <option>i386</option> run on any current Intel-compatible
-        computer. Packages for PowerPC machines, such as Apple Macs, are
-        indicated with <option>ppc</option>. Packages specified as
-        <option>noarch</option> have no architecture requirement.
+	type of machine required for that specific package. Packages
+	with architecture <option>i386</option> run on any current
+	Intel-compatible computer. Packages for PowerPC systems, such as
+	Apple Power Macintosh, are indicated with <option>ppc</option>.
+	Packages for systems with 64-bit processors such as Opterons are
+	indicated with <option>x86_64</option>. Packages specified as
+	<option>noarch</option> have no architecture requirement.
       </para>
 
       <para>
         Some software may be optimized for particular types of
-        Intel-compatible machine. For these products, separate packages
-        may be provided for <option>i386</option>,
-        <option>i586</option>, <option>i686</option> and
-        <option>x86_64</option> computers. A machine with at least an
-        Intel Pentium, VIA C3 or compatible CPU is an
-        <option>i586</option>. Computers with an Intel Pentium II and
-        above, or a current model of AMD chip, are <option>i686</option>
-        machines. 64-bit PCs use <option>x86_64</option> packages for
-        full 64-bit support.
+	Intel-compatible machine. Separate packages may be provided for
+	<option>i386</option>, <option>i586</option>,
+	<option>i686</option> and <option>x86_64</option> computers. A
+	machine with at least an Intel Pentium, VIA C3 or compatible CPU
+	may use <option>i586</option> packages. Computers with an Intel
+	Pentium Pro and above, or a current model of AMD chip, may use
+	<option>i686</option> packages.
       </para>
     </section>
   </section>




More information about the docs-commits mailing list