Avoid extra whitespace in <para>.

3 files changed, 60 insertions, 109 deletions

diff --git a/doc/guide/files/submit.xml b/doc/guide/files/submit.xml
index 1e85a0aff08..5c0aa8ed240 100644
--- a/doc/guide/files/submit.xml
+++ b/doc/guide/files/submit.xml
@@ -1,4 +1,4 @@
-<!-- $NetBSD: submit.xml,v 1.13 2006/09/08 07:38:37 rillig Exp $ -->
+<!-- $NetBSD: submit.xml,v 1.14 2006/09/10 19:32:22 wiz Exp $ -->
 
 <chapter id="submit"> <?dbhtml filename="submit.html"?>
 <title>Submitting and Committing</title>
@@ -87,84 +87,66 @@
 
 <sect1 id="committing-importing">
 <title>Committing: Importing a package into CVS</title>
-<para>
-  This section is only of interest for pkgsrc developers with write
+<para>This section is only of interest for pkgsrc developers with write
   access to the pkgsrc repository. Please remember that cvs
   imports files relative to the current working directory, and that
   the pathname that you
   give the <command>cvs import</command> command is so that it knows where
   to place the files in the repository.  Newly created packages should be
   imported with a vendor tag of <quote>TNF</quote> and a release tag of
-  <quote>pkgsrc-base</quote>, e.g:
-</para>
+  <quote>pkgsrc-base</quote>, e.g:</para>
 
 <programlisting>
     &uprompt; cd .../pkgsrc/category/pkgname
     &uprompt; cvs import pkgsrc/category/pkgname TNF pkgsrc-base
 </programlisting>
 
-<para>
-  Remember to move the directory from which you imported out of
+<para>Remember to move the directory from which you imported out of
   the way, or cvs will complain the next time you <quote>cvs
   update</quote> your source tree.  Also don't forget to add the new
-  package to the category's <filename>Makefile</filename>.
-</para>
+  package to the category's <filename>Makefile</filename>.</para>
 
-<para>
-  The commit message of the initial import should include part of the
+<para>The commit message of the initial import should include part of the
   <filename>DESCR</filename> file, so people reading the mailing lists know
-  what the package is/does.
-</para>
+  what the package is/does.</para>
 
-<para>
-  For new packages, <quote>cvs import</quote> is preferred to <quote>cvs
+<para>For new packages, <quote>cvs import</quote> is preferred to <quote>cvs
   add</quote> because the former gets everything with a single command,
-  and provides a consistent tag.
-</para>
+  and provides a consistent tag.</para>
 </sect1>
 
 <sect1 id="updating-package">
 <title>Updating a package to a newer version</title>
-<para>
-  Please always put a concise, appropriate and relevant summary of the
+<para>Please always put a concise, appropriate and relevant summary of the
   changes between old and new versions into the commit log when updating
-  a package. There are various reasons for this:
-</para>
+  a package. There are various reasons for this:</para>
 
 <itemizedlist>
 <listitem>
-<para>
-  A URL is volatile, and can change over time. It may go away completely
-  or its information may be overwritten by newer information.
-</para>
+<para>A URL is volatile, and can change over time. It may go away completely
+  or its information may be overwritten by newer information.</para>
 </listitem>
 
 <listitem>
-<para>
-  Having the change information between old and new versions in our CVS
-  repository is very useful for people who use either cvs or anoncvs.
-</para>
+<para>Having the change information between old and new versions in our CVS
+  repository is very useful for people who use either cvs or anoncvs.</para>
 </listitem>
 
 <listitem>
-<para>
-  Having the change information between old and new versions in our CVS
+<para>Having the change information between old and new versions in our CVS
   repository is very useful for people who read the pkgsrc-changes mailing
   list, so that they can make tactical decisions about when to upgrade
-  the package.
-</para>
+  the package.</para>
 </listitem>
 </itemizedlist>
 
-<para>
-  Please also recognize that, just because a new version of a package
+<para>Please also recognize that, just because a new version of a package
   has been released, it should not automatically be upgraded in the CVS
   repository.  We prefer to be conservative in the packages that are
   included in pkgsrc - development or beta packages are not really the
   best thing for most places in which pkgsrc is used. Please use your
   judgement about what should go into pkgsrc, and bear in mind that
-  stability is to be preferred above new and possibly untested features.
-</para>
+  stability is to be preferred above new and possibly untested features.</para>
 </sect1>
 
 <sect1 id="moving-package">
@@ -174,13 +156,9 @@
 <listitem><para>Make a copy of the directory somewhere else.</para></listitem>
 
 <listitem><para>Remove all CVS dirs.</para>
-<para>
-  Alternatively to the first two steps you can also do:
-</para>
+<para>Alternatively to the first two steps you can also do:</para>
 <screen><prompt>%</prompt> <userinput>cvs -d user@cvs.NetBSD.org:/cvsroot export -D today pkgsrc/category/package</userinput></screen>
-<para>
-  and use that for further work.
-</para>
+<para>and use that for further work.</para>
 </listitem>
 
 <listitem><para>Fix <varname>CATEGORIES</varname> and any
@@ -193,8 +171,7 @@ place.</para></listitem>
 
 <listitem><para>Check if any package depends on it:
 <screen><prompt>%</prompt> <userinput>cd /usr/pkgsrc</userinput>
-<prompt>%</prompt> <userinput>grep /package */*/Makefile* */*/buildlink*</userinput></screen>
-</para>
+<prompt>%</prompt> <userinput>grep /package */*/Makefile* */*/buildlink*</userinput></screen></para>
 </listitem>
 
 <listitem><para>Fix paths in packages from step 5 to point to new location.</para></listitem>
@@ -207,9 +184,7 @@ place.</para></listitem>
 
 <listitem><para>Commit the changed and removed files:</para>
 <screen><prompt>%</prompt> <userinput>cvs commit oldcategory/package oldcategory/Makefile newcategory/Makefile</userinput></screen>
-<para>
-  (and any packages from step 5, of course).
-</para>
+<para>(and any packages from step 5, of course).</para>
 </listitem>
 </orderedlist>
 
diff --git a/doc/guide/files/tools.xml b/doc/guide/files/tools.xml
index 1e8ba3d4456..182090d923b 100644
--- a/doc/guide/files/tools.xml
+++ b/doc/guide/files/tools.xml
@@ -1,103 +1,82 @@
-<!-- $NetBSD: tools.xml,v 1.3 2006/05/10 22:43:15 rillig Exp $ -->
+<!-- $NetBSD: tools.xml,v 1.4 2006/09/10 19:32:55 wiz Exp $ -->
 
 <chapter id="tools">
 <title>Tools needed for building or running</title>
 
-<para>
-The <varname>USE_TOOLS</varname> definition is used both internally
+<para>The <varname>USE_TOOLS</varname> definition is used both internally
 by pkgsrc and also for individual packages to define what commands
 are needed for building a package (like <varname>BUILD_DEPENDS</varname>)
 or for later run-time of an installed packaged (such as
 <varname>DEPENDS</varname>).
 If the native system provides an adequate tool, then in many cases, a pkgsrc
-package will not be used.
-</para>
+package will not be used.</para>
 
-<para>
-When building a package, the replacement tools are
+<para>When building a package, the replacement tools are
 made available in a directory (as symlinks or wrapper scripts)
 that is early in the executable search path. Just like the buildlink
-system, this helps with consistent builds.
-</para>
+system, this helps with consistent builds.</para>
 
-<para>
-A tool may be needed to help build a specific package. For example,
-perl, GNU make (gmake) or yacc may be needed.
-</para>
+<para>A tool may be needed to help build a specific package. For example,
+perl, GNU make (gmake) or yacc may be needed.</para>
 
-<para>
-Also a tool may be needed, for example, because the native system's supplied
+<para>Also a tool may be needed, for example, because the native system's supplied
 tool may be inefficient for building a package with pkgsrc.
 For example, a package may need GNU awk, bison (instead of
-yacc) or a better sed.
-</para>
+yacc) or a better sed.</para>
 
-<para>
-The tools used by a package can be listed by running
-<command>make show-tools</command>.
-</para>
+<para>The tools used by a package can be listed by running
+<command>make show-tools</command>.</para>
 
 <sect1 id="pkgsrc-tools">
 <title>Tools for pkgsrc builds</title>
 
-<para>
-The default set of tools used by pkgsrc is defined in
+<para>The default set of tools used by pkgsrc is defined in
 <filename>bsd.pkg.mk</filename>. This includes standard Unix tools,
 such as: <command>cat</command>, <command>awk</command>,
 <command>chmod</command>, <command>test</command>, and so on.
 These can be seen by running:
-<command>make show-var VARNAME=USE_TOOLS</command>.
-</para>
+<command>make show-var VARNAME=USE_TOOLS</command>.</para>
 
-<para>
-If a package needs a specific program to build
+<para>If a package needs a specific program to build
 then the <varname>USE_TOOLS</varname> variable can be used
-to define the tools needed.
-</para>
+to define the tools needed.</para>
 
 </sect1>
 
 <sect1 id="package-tools">
 <title>Tools needed by packages</title>
 
-<para>
-In the following examples, the :pkgsrc means to use the pkgsrc version
+<para>In the following examples, the :pkgsrc means to use the pkgsrc version
 and not the native version for a build dependency.
 And the :run means that it is used for a
 run-time dependencies also (and becomes a DEPENDS).
 The default is a build dependency which can be set with
 :build. (So in this example, it is the same as gmake:build
-and pkg-config:build.)
-</para>
+and pkg-config:build.)</para>
 
 <programlisting>
 USE_TOOLS+=     mktemp:pkgsrc
 USE_TOOLS+=     gmake perl:run pkg-config
 </programlisting>
 
-<para>
-When using the tools framework, a
+<para>When using the tools framework, a
 <varname>TOOLS_PATH.foo</varname> variable is defined
 which contains the full path to the appropriate tool. For example,
 <varname>TOOLS_PATH.bash</varname> could be <quote>/bin/bash</quote>
-on Linux systems.
-</para>
+on Linux systems.</para>
 
-<para>
-If you always need a pkgsrc version of the
+<para>If you always need a pkgsrc version of the
 tool at run-time, then just use <varname>DEPENDS</varname> instead.
 <!-- jlam said: This is not to
 say that we can't extend the tools framework to do that, but it hasn't been
 something that's come up frequently enough to make it worthwhile to do.
--->
-</para>
+--></para>
 
 </sect1>
 <sect1 id="platform-tools">
 <title>Tools provided by platforms</title>
 
-<para>
-When improving or porting pkgsrc to a new platform, have a look
+<para>When improving or porting pkgsrc to a new platform, have a look
 at (or create) the corresponding platform specific make file fragment under
 <filename>pkgsrc/mk/tools/tools.${OPSYS}.mk</filename> which defines
 the name of the common tools. For example:</para>
diff --git a/doc/guide/files/using.xml b/doc/guide/files/using.xml
index d41dc7944e8..2a3178234eb 100644
--- a/doc/guide/files/using.xml
+++ b/doc/guide/files/using.xml
@@ -1,4 +1,4 @@
-<!-- $NetBSD: using.xml,v 1.24 2006/09/02 11:26:16 schwarz Exp $ -->
+<!-- $NetBSD: using.xml,v 1.25 2006/09/10 19:33:05 wiz Exp $ -->
 
 <chapter id="using"> <?dbhtml filename="using.html"?>
 <title>Using pkgsrc</title>
@@ -74,22 +74,21 @@
 <sect2 id="installing-binary-packages">
 <title>Installing binary packages</title>
 
-      <para> If you have the files on a CD-ROM or downloaded them to
+      <para>If you have the files on a CD-ROM or downloaded them to
         your hard disk, you can install them with the following command
         (be sure to <command>su</command> to root first):</para>
 
         <screen><prompt>#</prompt> <userinput>pkg_add /path/to/package.tgz</userinput></screen>
 
-      <para> If you have FTP access and you don't want to download the
+      <para>If you have FTP access and you don't want to download the
         packages via FTP prior to installation, you can do this
-        automatically by giving <command>pkg_add</command> an FTP URL:
-        </para>
+        automatically by giving <command>pkg_add</command> an FTP URL:</para>
 
       <screen><prompt>#</prompt> <userinput>pkg_add ftp://ftp.NetBSD.org/pub/NetBSD/packages/&lt;OSVERSION&gt;/&lt;ARCH&gt;/All/package</userinput></screen>
 
       <para>Note that any prerequisite packages needed to run the
         package in question will be installed, too, assuming they are
-        present where you install from. </para>
+        present where you install from.</para>
 
       <para>To save some typing, you can set the
         <varname>PKG_PATH</varname> environment variable to a semicolon-separated
@@ -113,7 +112,7 @@
       <para>After you've installed packages, be sure to have
         <filename>/usr/pkg/bin</filename> and <filename>/usr/pkg/sbin</filename> in your
         <varname>PATH</varname> so you can actually start the just
-        installed program. </para>
+        installed program.</para>
     </sect2>
 
 <sect2 id="using.pkg_delete">
@@ -237,8 +236,7 @@ package on your system and rebuild any dependencies.
   <sect1 id="building-packages-from-source">
     <title>Building packages from source</title>
 
-<para>
-After obtaining pkgsrc, the <filename>pkgsrc</filename> directory
+<para>After obtaining pkgsrc, the <filename>pkgsrc</filename> directory
 now contains a set of packages, organized into categories. You can browse
 the online index of packages, or run <command>make readme</command>
 from the <filename>pkgsrc</filename> directory to build local
@@ -327,7 +325,7 @@ compile time.
         use the pkgsrc <command>bmake</command> command instead of
         <quote>make</quote> in the examples in this guide.</para></note>
 
-     <para>For example, type </para>
+     <para>For example, type</para>
 
       <screen>&cprompt; <userinput>cd misc/figlet</userinput>
 &cprompt; <userinput>make</userinput></screen>
@@ -449,17 +447,16 @@ You can now enter:
       <title>Selecting the compiler</title>
 
       <para>By default, pkgsrc will use GCC to build packages.  This may be
-        overridden by setting the following variables in /etc/mk.conf:
-        </para>
+        overridden by setting the following variables in /etc/mk.conf:</para>
 
       <variablelist>
         <varlistentry>
           <term><varname>PKGSRC_COMPILER</varname>:</term>
 
           <listitem>
-            <para> This is a list of values specifying the chain of
+            <para>This is a list of values specifying the chain of
               compilers to invoke when building packages.  Valid values
-              are: </para>
+              are:</para>
 
 <!-- TODO: update this list after jlam's changes in May 2005 -->
             <itemizedlist>
@@ -488,14 +485,14 @@ You can now enter:
               </listitem>
             </itemizedlist>
 
-            <para> The default is
+            <para>The default is
               <quote><varname>gcc</varname></quote>.  You can use
               <varname>ccache</varname> and/or
               <varname>distcc</varname> with an appropriate
               <varname>PKGSRC_COMPILER</varname> setting,
               e.g. <quote><varname>ccache gcc</varname></quote>.  This
               variable should always be
-              terminated with a value for a real compiler.  </para>
+              terminated with a value for a real compiler.</para>
 	  </listitem>
         </varlistentry>
 
@@ -506,10 +503,10 @@ You can now enter:
    is not gcc?
 -->
           <listitem>
-            <para> This specifies the minimum version of GCC to use
+            <para>This specifies the minimum version of GCC to use
               when building packages.  If the system GCC doesn't
               satisfy this requirement, then pkgsrc will build and
-              install one of the GCC packages to use instead. </para>
+              install one of the GCC packages to use instead.</para>
           </listitem>
         </varlistentry>
       </variablelist>