 @@ -92,27 +92,26 @@
 </dl></dd>
 </dl></dd>
 <dt><span class="chapter"><a href="#using">4. Using pkgsrc</a></span></dt>
 <dd><dl>
 <dt><span class="sect1"><a href="#using-pkg">4.1. Using binary packages</a></span></dt>
 <dd><dl>
 <dt><span class="sect2"><a href="#finding-binary-packages">4.1.1. Finding binary packages</a></span></dt>
 <dt><span class="sect2"><a href="#installing-binary-packages">4.1.2. Installing binary packages</a></span></dt>
 <dt><span class="sect2"><a href="#using.pkg_delete">4.1.3. Deinstalling packages</a></span></dt>
 <dt><span class="sect2"><a href="#using.pkg_info">4.1.4. Getting information about installed packages</a></span></dt>
 <dt><span class="sect2"><a href="#vulnerabilities">4.1.5. Checking for security vulnerabilities in installed packages</a></span></dt>
 <dt><span class="sect2"><a href="#pkg_versions">4.1.6. Finding if newer versions of your installed packages are in pkgsrc</a></span></dt>
 <dt><span class="sect2"><a href="#using.pkg_admin">4.1.7. Other administrative functions</a></span></dt>
 <dt><span class="sect2"><a href="#a-word-of-warning">4.1.8. A word of warning</a></span></dt>
 </dl></dd>
 <dt><span class="sect1"><a href="#building-packages-from-source">4.2. Building packages from source</a></span></dt>
 <dd><dl>
 <dt><span class="sect2"><a href="#requirements">4.2.1. Requirements</a></span></dt>
 <dt><span class="sect2"><a href="#fetching-distfiles">4.2.2. Fetching distfiles</a></span></dt>
 <dt><span class="sect2"><a href="#how-to-build-and-install">4.2.3. How to build and install</a></span></dt>
 </dl></dd>
 </dl></dd>
 <dt><span class="chapter"><a href="#configuring">5. Configuring pkgsrc</a></span></dt>
 <dd><dl>
 <dt><span class="sect1"><a href="#general-configuration">5.1. General configuration</a></span></dt>
 <dt><span class="sect1"><a href="#variables-affecting-build">5.2. Variables affecting the build process</a></span></dt>
 <dt><span class="sect1"><a href="#variables-affecting-installation">5.3. Variables affecting the installation process</a></span></dt>
 @@ -174,56 +173,54 @@ builds)
 <dt><span class="sect1"><a href="#creating.common">10.1. Common types of packages</a></span></dt>
 <dd><dl>
 <dt><span class="sect2"><a href="#creating.perl-module">10.1.1. Perl modules</a></span></dt>
 <dt><span class="sect2"><a href="#creating.kde-app">10.1.2. KDE3 applications</a></span></dt>
 <dt><span class="sect2"><a href="#creating.python-module">10.1.3. Python modules and programs</a></span></dt>
 </dl></dd>
 <dt><span class="sect1"><a href="#creating.examples">10.2. Examples</a></span></dt>
 <dd><dl><dt><span class="sect2"><a href="#creating.nvu">10.2.1. How the www/nvu package came into pkgsrc</a></span></dt></dl></dd>
 </dl></dd>
 <dt><span class="chapter"><a href="#components">11. Package components - files, directories and contents</a></span></dt>
 <dd><dl>
 <dt><span class="sect1"><a href="#components.Makefile">11.1. <code class="filename">Makefile</code></a></span></dt>
 <dt><span class="sect1"><a href="#components.distinfo">11.2. <code class="filename">distinfo</code></a></span></dt>
-<dt><span class="sect1"><a href="#components.patches">11.3. patches/*</a></span></dt>
+<dt><span class="sect1"><a href="#components.patches">11.3. <code class="filename">patches/*</code></a></span></dt>
 <dd><dl>
 <dt><span class="sect2"><a href="#components.patch.structure">11.3.1. Structure of a single patch file</a></span></dt>
 <dt><span class="sect2"><a href="#components.patches.caveats">11.3.2. Creating patch files</a></span></dt>
 <dt><span class="sect2"><a href="#components.patches.sources">11.3.3. Sources where the patch files come from</a></span></dt>
 <dt><span class="sect2"><a href="#components.patches.guidelines">11.3.4. Patching guidelines</a></span></dt>
 <dt><span class="sect2"><a href="#components.patches.feedback">11.3.5. Feedback to the author</a></span></dt>
 </dl></dd>
 <dt><span class="sect1"><a href="#other-mandatory-files">11.4. Other mandatory files</a></span></dt>
 <dt><span class="sect1"><a href="#components.optional">11.5. Optional files</a></span></dt>
 <dd><dl>
 <dt><span class="sect2"><a href="#components.optional.bin">11.5.1. Files affecting the binary package</a></span></dt>
 <dt><span class="sect2"><a href="#components.optional.build">11.5.2. Files affecting the build process</a></span></dt>
 <dt><span class="sect2"><a href="#components.optional.none">11.5.3. Files affecting nothing at all</a></span></dt>
 </dl></dd>
 <dt><span class="sect1"><a href="#work-dir">11.6. <code class="filename">work*</code></a></span></dt>
 <dt><span class="sect1"><a href="#files-dir">11.7. <code class="filename">files/*</code></a></span></dt>
 </dl></dd>
 <dt><span class="chapter"><a href="#makefile">12. Programming in <code class="filename">Makefile</code>s</a></span></dt>
 <dd><dl>
 <dt><span class="sect1"><a href="#makefile.style">12.1. Caveats</a></span></dt>
 <dt><span class="sect1"><a href="#makefile.variables">12.2. <code class="filename">Makefile</code> variables</a></span></dt>
 <dd><dl><dt><span class="sect2"><a href="#makefile.variables.names">12.2.1. Naming conventions</a></span></dt></dl></dd>
 <dt><span class="sect1"><a href="#makefile.code">12.3. Code snippets</a></span></dt>
 <dd><dl>
 <dt><span class="sect2"><a href="#adding-to-list">12.3.1. Adding things to a list</a></span></dt>
-<dt><span class="sect2"><a href="#converting-internal-to-external">12.3.2. Converting an internal list into an external list</a></span></dt>
+<dt><span class="sect2"><a href="#passing-variable-to-shell">12.3.2. Passing variables to a shell command</a></span></dt>
-<dt><span class="sect2"><a href="#passing-variable-to-shell">12.3.3. Passing variables to a shell command</a></span></dt>
+<dt><span class="sect2"><a href="#quoting-guideline">12.3.3. Quoting guideline</a></span></dt>
 <dt><span class="sect2"><a href="#quoting-guideline">12.3.4. Quoting guideline</a></span></dt>
 <dt><span class="sect2"><a href="#bsd-make-bug-workaround">12.3.5. Workaround for a bug in BSD Make</a></span></dt>
 </dl></dd>
 </dl></dd>
 <dt><span class="chapter"><a href="#plist">13. PLIST issues</a></span></dt>
 <dd><dl>
 <dt><span class="sect1"><a href="#rcs-id">13.1. RCS ID</a></span></dt>
 <dt><span class="sect1"><a href="#automatic-plist-generation">13.2. Semi-automatic <code class="filename">PLIST</code> generation</a></span></dt>
 <dt><span class="sect1"><a href="#print-PLIST">13.3. Tweaking output of <span class="command"><strong>make print-PLIST</strong></span></a></span></dt>
 <dt><span class="sect1"><a href="#plist.misc">13.4. Variable substitution in PLIST</a></span></dt>
 <dt><span class="sect1"><a href="#manpage-compression">13.5. Man page compression</a></span></dt>
 <dt><span class="sect1"><a href="#using-PLIST_SRC">13.6. Changing PLIST source with <code class="varname">PLIST_SRC</code></a></span></dt>
 <dt><span class="sect1"><a href="#platform-specific-plist">13.7. Platform-specific and differing PLISTs</a></span></dt>
 <dt><span class="sect1"><a href="#build-plist">13.8. Build-specific PLISTs</a></span></dt>
 <dt><span class="sect1"><a href="#faq.common-dirs">13.9. Sharing directories between packages</a></span></dt>
 @@ -410,39 +407,35 @@ builds)
 <dt><span class="sect1"><a href="#infr.design.intf">24.5. Designing interfaces for Makefile fragments</a></span></dt>
 <dd><dl>
 <dt><span class="sect2"><a href="#infr.design.intf.proc">24.5.1. Procedures with parameters</a></span></dt>
 <dt><span class="sect2"><a href="#infr.design.intf.action">24.5.2. Actions taken on behalf of parameters</a></span></dt>
 </dl></dd>
 <dt><span class="sect1"><a href="#infr.order">24.6. The order in which files are loaded</a></span></dt>
 <dd><dl>
 <dt><span class="sect2"><a href="#infr.order.prefs">24.6.1. The order in <code class="filename">bsd.prefs.mk</code></a></span></dt>
 <dt><span class="sect2"><a href="#infr.order.pkg">24.6.2. The order in <code class="filename">bsd.pkg.mk</code></a></span></dt>
 </dl></dd>
 </dl></dd>
 <dt><span class="chapter"><a href="#regression">25. Regression tests</a></span></dt>
 <dd><dl>
-<dt><span class="sect1"><a href="#regression.descr">25.1. The regression tests framework</a></span></dt>
+<dt><span class="sect1"><a href="#regression.run">25.1. Running the regression tests</a></span></dt>
-<dt><span class="sect1"><a href="#regression.run">25.2. Running the regression tests</a></span></dt>
+<dt><span class="sect1"><a href="#regression.new">25.2. Adding a new regression test</a></span></dt>
 <dt><span class="sect1"><a href="#regression.new">25.3. Adding a new regression test</a></span></dt>
 <dd><dl>
-<dt><span class="sect2"><a href="#regression.fun.override">25.3.1. Overridable functions</a></span></dt>
+<dt><span class="sect2"><a href="#regression.fun.override">25.2.1. Overridable functions</a></span></dt>
-<dt><span class="sect2"><a href="#regression.fun.helper">25.3.2. Helper functions</a></span></dt>
+<dt><span class="sect2"><a href="#regression.fun.helper">25.2.2. Helper functions</a></span></dt>
 </dl></dd>
 </dl></dd>
 <dt><span class="chapter"><a href="#porting">26. Porting pkgsrc</a></span></dt>
-<dd><dl>
+<dd><dl><dt><span class="sect1"><a href="#porting.opsys">26.1. Porting pkgsrc to a new operating system</a></span></dt></dl></dd>
 <dt><span class="sect1"><a href="#porting.opsys">26.1. Porting pkgsrc to a new operating system</a></span></dt>
 <dt><span class="sect1"><a href="#porting.compiler">26.2. Adding support for a new compiler</a></span></dt>
 </dl></dd>
 </dl></dd>
 <dt><span class="appendix"><a href="#examples">A. A simple example package: bison</a></span></dt>
 <dd><dl>
 <dt><span class="sect1"><a href="#example-files">A.1. files</a></span></dt>
 <dd><dl>
 <dt><span class="sect2"><a href="#example-Makefile">A.1.1. Makefile</a></span></dt>
 <dt><span class="sect2"><a href="#example-descr">A.1.2. DESCR</a></span></dt>
 <dt><span class="sect2"><a href="#example-plist">A.1.3. PLIST</a></span></dt>
 <dt><span class="sect2"><a href="#checking-package-with-pkglint">A.1.4. Checking a package with <span class="command"><strong>pkglint</strong></span></a></span></dt>
 </dl></dd>
 <dt><span class="sect1"><a href="#steps-for-b-i-p">A.2. Steps for building, installing, packaging</a></span></dt>
 </dl></dd>
 <dt><span class="appendix"><a href="#logs">B. Build logs</a></span></dt>
 @@ -507,27 +500,27 @@ to handle binary packages, so that not e
 packages for himself, which is a time-costly task.</p>
 <p>pkgsrc currently contains several thousand packages,
       including:</p>
 <div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; ">
 <li class="listitem"><p><a href="ftp://ftp.NetBSD.org/pub/pkgsrc/current/pkgsrc/www/apache24/README.html" target="_top"><code class="filename">www/apache24</code></a> - The Apache
 	  web server</p></li>
 <li class="listitem"><p><a href="ftp://ftp.NetBSD.org/pub/pkgsrc/current/pkgsrc/www/firefox/README.html" target="_top"><code class="filename">www/firefox</code></a> - The Firefox
 	  web browser</p></li>
 <li class="listitem"><p><a href="ftp://ftp.NetBSD.org/pub/pkgsrc/current/pkgsrc/meta-pkgs/gnome/README.html" target="_top"><code class="filename">meta-pkgs/gnome</code></a> - The GNOME
 	  Desktop Environment</p></li>
 <li class="listitem"><p><a href="ftp://ftp.NetBSD.org/pub/pkgsrc/current/pkgsrc/meta-pkgs/kde4/README.html" target="_top"><code class="filename">meta-pkgs/kde4</code></a> - The K
 	  Desktop Environment</p></li>
 </ul></div>
-<p>...just to name a few.</p>
+<p>&#8230; just to name a few.</p>
 <p>pkgsrc has built-in support for handling varying dependencies,
       such as pthreads and X11, and extended features such as IPv6 support on
       a range of platforms.</p>
 <div class="sect2">
 <div class="titlepage"><div><div><h3 class="title">
 <a name="why-pkgsrc"></a>1.1.1.�Why pkgsrc?</h3></div></div></div>
 <p>
 pkgsrc provides the following key features:
 </p>
 <div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; ">
 <li class="listitem"><p>Easy building of software from source as well as the creation
   and installation of binary packages. The source and latest
   patches are retrieved from a master or mirror download site, checksum
 @@ -848,27 +841,26 @@ minutes!
 </dl></dd>
 </dl></dd>
 <dt><span class="chapter"><a href="#using">4. Using pkgsrc</a></span></dt>
 <dd><dl>
 <dt><span class="sect1"><a href="#using-pkg">4.1. Using binary packages</a></span></dt>
 <dd><dl>
 <dt><span class="sect2"><a href="#finding-binary-packages">4.1.1. Finding binary packages</a></span></dt>
 <dt><span class="sect2"><a href="#installing-binary-packages">4.1.2. Installing binary packages</a></span></dt>
 <dt><span class="sect2"><a href="#using.pkg_delete">4.1.3. Deinstalling packages</a></span></dt>
 <dt><span class="sect2"><a href="#using.pkg_info">4.1.4. Getting information about installed packages</a></span></dt>
 <dt><span class="sect2"><a href="#vulnerabilities">4.1.5. Checking for security vulnerabilities in installed packages</a></span></dt>
 <dt><span class="sect2"><a href="#pkg_versions">4.1.6. Finding if newer versions of your installed packages are in pkgsrc</a></span></dt>
 <dt><span class="sect2"><a href="#using.pkg_admin">4.1.7. Other administrative functions</a></span></dt>
 <dt><span class="sect2"><a href="#a-word-of-warning">4.1.8. A word of warning</a></span></dt>
 </dl></dd>
 <dt><span class="sect1"><a href="#building-packages-from-source">4.2. Building packages from source</a></span></dt>
 <dd><dl>
 <dt><span class="sect2"><a href="#requirements">4.2.1. Requirements</a></span></dt>
 <dt><span class="sect2"><a href="#fetching-distfiles">4.2.2. Fetching distfiles</a></span></dt>
 <dt><span class="sect2"><a href="#how-to-build-and-install">4.2.3. How to build and install</a></span></dt>
 </dl></dd>
 </dl></dd>
 <dt><span class="chapter"><a href="#configuring">5. Configuring pkgsrc</a></span></dt>
 <dd><dl>
 <dt><span class="sect1"><a href="#general-configuration">5.1. General configuration</a></span></dt>
 <dt><span class="sect1"><a href="#variables-affecting-build">5.2. Variables affecting the build process</a></span></dt>
 <dt><span class="sect1"><a href="#variables-affecting-installation">5.3. Variables affecting the installation process</a></span></dt>
 @@ -1178,27 +1170,26 @@ release -d
 </div>
 <div class="note" style="margin-left: 0.5in; margin-right: 0.5in;">
 <h3 class="title">Note</h3>
 <p>It is possible to bootstrap multiple instances of pkgsrc
       using non-intersecting directories. Use <span class="command"><strong>bmake</strong></span>
       corresponding to the installation you're working with to build
       and install packages.
       </p>
 </div>
 </div>
 <div class="sect1">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
 <a name="platform-specific-notes"></a>3.3.�Platform-specific notes</h2></div></div></div>
 <p>Here are some platform-specific notes you should be aware of.</p>
 <div class="sect2">
 <div class="titlepage"><div><div><h3 class="title">
 <a name="cygwin"></a>3.3.1.�Cygwin</h3></div></div></div>
 <p>Cygwin 1.7.x and later are supported.</p>
 <p>You need to install minimal base packages in `Base' category
       plus any of compiler, gcc, gcc4, and/or clang.
       For gcc and gcc4, C and C++ compiler will be installed by default,
       but you can install Fortran compiler additionally
       because it will be required to use libtool.
       If it is not installed (or too old), Fortran compiler will be
       installed with pkgsrc automatically.</p>
 <p>As noted in
       <a class="ulink" href="http://cygwin.com/faq-nochunks.html#faq.using.su" target="_top">Cygwin FAQ: `Why doesn't su work?'</a>,
 @@ -1692,27 +1683,26 @@ WRAPPER_SHELL=  ${LOCALBASE}/bin/bash
 <a name="using"></a>Chapter�4.�Using pkgsrc</h2></div></div></div>
 <div class="toc">
 <p><b>Table of Contents</b></p>
 <dl class="toc">
 <dt><span class="sect1"><a href="#using-pkg">4.1. Using binary packages</a></span></dt>
 <dd><dl>
 <dt><span class="sect2"><a href="#finding-binary-packages">4.1.1. Finding binary packages</a></span></dt>
 <dt><span class="sect2"><a href="#installing-binary-packages">4.1.2. Installing binary packages</a></span></dt>
 <dt><span class="sect2"><a href="#using.pkg_delete">4.1.3. Deinstalling packages</a></span></dt>
 <dt><span class="sect2"><a href="#using.pkg_info">4.1.4. Getting information about installed packages</a></span></dt>
 <dt><span class="sect2"><a href="#vulnerabilities">4.1.5. Checking for security vulnerabilities in installed packages</a></span></dt>
 <dt><span class="sect2"><a href="#pkg_versions">4.1.6. Finding if newer versions of your installed packages are in pkgsrc</a></span></dt>
 <dt><span class="sect2"><a href="#using.pkg_admin">4.1.7. Other administrative functions</a></span></dt>
 <dt><span class="sect2"><a href="#a-word-of-warning">4.1.8. A word of warning</a></span></dt>
 </dl></dd>
 <dt><span class="sect1"><a href="#building-packages-from-source">4.2. Building packages from source</a></span></dt>
 <dd><dl>
 <dt><span class="sect2"><a href="#requirements">4.2.1. Requirements</a></span></dt>
 <dt><span class="sect2"><a href="#fetching-distfiles">4.2.2. Fetching distfiles</a></span></dt>
 <dt><span class="sect2"><a href="#how-to-build-and-install">4.2.3. How to build and install</a></span></dt>
 </dl></dd>
 </dl>
 </div>
 <p>Basically, there are two ways of using pkgsrc. The first
 is to only install the package tools and to use binary packages
 that someone else has prepared. This is the <span class="quote">&#8220;<span class="quote">pkg</span>&#8221;</span>
 in pkgsrc. The second way is to install the <span class="quote">&#8220;<span class="quote">src</span>&#8221;</span>
 @@ -1889,41 +1879,26 @@ and you can still use binary packages fr
 ...
 Version mismatch: 'tcsh' 6.09.00 vs 6.10.00
     </pre>
 <p>You can then use <span class="command"><strong>make update</strong></span> to update the
     package on your system and rebuild any dependencies.
     </p>
 </div>
 <div class="sect2">
 <div class="titlepage"><div><div><h3 class="title">
 <a name="using.pkg_admin"></a>4.1.7.�Other administrative functions</h3></div></div></div>
 <p>The <span class="command"><strong>pkg_admin</strong></span> executes various
     administrative functions on the package system.</p>
 </div>
 <div class="sect2">
 <div class="titlepage"><div><div><h3 class="title">
 <a name="a-word-of-warning"></a>4.1.8.�A word of warning</h3></div></div></div>
 <p>Please pay very careful attention to the warnings
     expressed in the <a class="citerefentry" href="http://netbsd.gw.com/cgi-bin/man-cgi?pkg_add+1+NetBSD-5.0.1+i386"><span class="citerefentry"><span class="refentrytitle">pkg_add</span>(1)</span></a> manual page about the
     inherent dangers of installing binary packages which you did
     not create yourself, and the security holes that can be
     introduced onto your system by indiscriminate adding of such
     files.</p>
 <p>The same warning of course applies to every package you
     install from source when you haven't completely read and
     understood the source code of the package, the compiler that
     is used to build the package and all the other tools that are
     involved.</p>
 </div>
 </div>
 <div class="sect1">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
 <a name="building-packages-from-source"></a>4.2.�Building packages from source</h2></div></div></div>
 <p>After obtaining pkgsrc, the <code class="filename">pkgsrc</code>
   directory now contains a set of packages, organized into
   categories. You can browse the online index of packages, or run
   <span class="command"><strong>make readme</strong></span> from the <code class="filename">pkgsrc</code>
   directory to build local <code class="filename">README.html</code> files for
   all packages, viewable with any web browser such as <a href="ftp://ftp.NetBSD.org/pub/pkgsrc/current/pkgsrc/www/lynx/README.html" target="_top"><code class="filename">www/lynx</code></a> or <a href="ftp://ftp.NetBSD.org/pub/pkgsrc/current/pkgsrc/www/firefox/README.html" target="_top"><code class="filename">www/firefox</code></a>.</p>
 <p>The default <span class="emphasis"><em>prefix</em></span> for installed packages
   is <code class="filename">/usr/pkg</code>. If you wish to change this, you
   should do so by setting <code class="varname">LOCALBASE</code> in
 @@ -2205,47 +2180,47 @@ works.
 	    release (<span class="quote">&#8220;<span class="quote">2.0</span>&#8221;</span>, etc.) and architecture
 	    (<span class="quote">&#8220;<span class="quote">mipsel</span>&#8221;</span>, etc.).</p></li>
 <li class="listitem"><p><code class="varname">ACCEPTABLE_LICENSES</code>:
 	    List of acceptable licenses. License names are case-sensitive.
 	    Whenever you try to build a package whose license is not in this
 	    list, you will get an error message. If the license condition is
 	    simple enough, the error message will include specific
 	    instructions on how to change this variable.</p></li>
 </ul></div>
 </div>
 <div class="sect1">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
 <a name="variables-affecting-build"></a>5.2.�Variables affecting the build process</h2></div></div></div>
-<p>XXX
+<p>
       </p>
 <div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; ">
 <li class="listitem"><p><code class="varname">PACKAGES</code>: The top level
 	    directory for the binary packages. The default is
 	    <code class="filename">${PKGSRCDIR}/packages</code>.</p></li>
 <li class="listitem"><p><code class="varname">WRKOBJDIR</code>:
 	    The top level directory where, if defined, the separate
 	    working directories will get created, and symbolically
 	    linked to from <code class="filename">${WRKDIR}</code> (see below).
 	    This is useful for building packages on several
 	    architectures, then <code class="filename">${PKGSRCDIR}</code>
 	    can be NFS-mounted while <code class="filename">${WRKOBJDIR}</code>
 	    is local to every architecture. (It should be noted that
 	    <code class="varname">PKGSRCDIR</code> should not be set by the user
 	    &mdash; it is an internal definition which refers to the
 	    root of the pkgsrc tree. It is possible to have many
 	    pkgsrc tree instances.)</p></li>
 <li class="listitem"><p><code class="varname">LOCALPATCHES</code>:
 	    Directory for local patches that aren't part of pkgsrc.
-	    See <a class="xref" href="#components.patches" title="11.3.�patches/*">Section�11.3, &#8220;patches/*&#8221;</a> for more
+	    See <a class="xref" href="#components.patches" title="11.3.�patches/*">Section�11.3, &#8220;<code class="filename">patches/*</code>&#8221;</a> for more
 	    information.</p></li>
 <li class="listitem"><p><code class="varname">PKGMAKECONF</code>: Location of
 	    the <a class="link" href="#mk.conf"><code class="filename">mk.conf</code></a> file used by a package's
 	    BSD-style Makefile. If this is not set,
 	    <code class="varname">MAKECONF</code> is set to
 	    <code class="filename">/dev/null</code> to avoid picking up
 	    settings used by builds in <code class="filename">/usr/src</code>.</p></li>
 <li class="listitem"><p><code class="varname">DEPENDS_TARGET</code>:
 	    By default, dependencies are only installed, and no binary
 	    package is created for them. You can set this variable to
 	    <code class="literal">package-install</code> to automatically create binary
 	    packages after installing dependencies. Please note that the
 	    <code class="varname">PKGSRC_KEEP_BIN_PKGS</code> can be set to
 @@ -3006,43 +2981,34 @@ etc:
 </ul></div>
 <p>Utilities for people maintaining pkgsrc (or: more obscure pkg
 utilities)</p>
 <div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; ">
 <li class="listitem"><p><a href="ftp://ftp.NetBSD.org/pub/pkgsrc/current/pkgsrc/pkgtools/pkg_comp/README.html" target="_top"><code class="filename">pkgtools/pkg_comp</code></a>: Build
       packages in a chrooted area.</p></li>
 <li class="listitem"><p><a href="ftp://ftp.NetBSD.org/pub/pkgsrc/current/pkgsrc/pkgtools/libkver/README.html" target="_top"><code class="filename">pkgtools/libkver</code></a>: Spoof
       kernel version for chrooted cross builds.</p></li>
 </ul></div>
 </div>
 <div class="sect1">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
 <a name="non-root-pkgsrc"></a>9.3.�How to use pkgsrc as non-root</h2></div></div></div>
-<p>If you want to use pkgsrc as non-root user, you can set some
+<p>To install packages from source as a non-root user, download
-variables to make pkgsrc work under these conditions.  At the very least,
+pkgsrc as described in <a class="xref" href="#getting" title="Chapter�2.�Where to get pkgsrc and how to keep it up-to-date">Chapter�2, <i>Where to get pkgsrc and how to keep it up-to-date</i></a>, cd into that
-you need to set <code class="varname">UNPRIVILEGED</code> to <span class="quote">&#8220;<span class="quote">yes</span>&#8221;</span>; this
+directory and run the command <span class="command"><strong>./bootstrap/bootstrap
-will turn on unprivileged mode and set multiple related variables to allow
+--unprivileged</strong></span>.</p>
-installation of packages as non-root.</p>
+<p>This will install the binary part of pkgsrc to
-<p>In case the defaults are not enough, you may want to tune some other
+<code class="filename">~/pkg</code> and put the pkgsrc configuration <a class="link" href="#mk.conf"><code class="filename">mk.conf</code></a>
-variables used.  For example, if the automatic user/group detection leads
+into <code class="filename">~/pkg/etc</code>.</p>
-to incorrect values (or not the ones you would like to use), you can change
+<p>For more details, see <code class="filename">mk/unprivileged.mk</code>.</p>
 them by setting <code class="varname">UNPRIVILEGED_USER</code> and
 <code class="varname">UNPRIVILEGED_GROUP</code> respectively.</p>
 <p>As regards bootstrapping, please note that the
 <span class="command"><strong>bootstrap</strong></span> script will ease non-root configuration when
 given the <span class="quote">&#8220;<span class="quote">--ignore-user-check</span>&#8221;</span> flag, as it will choose and
 use multiple default directories under <code class="filename">~/pkg</code> as the
 installation targets.  These directories can be overridden by the
 <span class="quote">&#8220;<span class="quote">--prefix</span>&#8221;</span> flag provided by the script, as well as some others
 that allow finer tuning of the tree layout.</p>
 </div>
 <div class="sect1">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
 <a name="resume-transfers"></a>9.4.�How to resume transfers when fetching distfiles?</h2></div></div></div>
 <p>By default, resuming transfers in pkgsrc is disabled, but you can
 enable this feature by adding the option
 <code class="varname">PKG_RESUME_TRANSFERS=YES</code> into
 <a class="link" href="#mk.conf"><code class="filename">mk.conf</code></a>.  If, during a fetch step, an incomplete
 distfile is found, pkgsrc will try to resume it.</p>
 <p>You can also
 use a different program than the platform default program by changing the
 <code class="varname">FETCH_USING</code> variable.  You can specify the program by
 using of ftp, fetch, wget or curl.  Alternatively, fetching can be disabled
 @@ -3332,56 +3298,54 @@ anymore, you can remove that file and ru
 <dt><span class="sect1"><a href="#creating.common">10.1. Common types of packages</a></span></dt>
 <dd><dl>
 <dt><span class="sect2"><a href="#creating.perl-module">10.1.1. Perl modules</a></span></dt>
 <dt><span class="sect2"><a href="#creating.kde-app">10.1.2. KDE3 applications</a></span></dt>
 <dt><span class="sect2"><a href="#creating.python-module">10.1.3. Python modules and programs</a></span></dt>
 </dl></dd>
 <dt><span class="sect1"><a href="#creating.examples">10.2. Examples</a></span></dt>
 <dd><dl><dt><span class="sect2"><a href="#creating.nvu">10.2.1. How the www/nvu package came into pkgsrc</a></span></dt></dl></dd>
 </dl></dd>
 <dt><span class="chapter"><a href="#components">11. Package components - files, directories and contents</a></span></dt>
 <dd><dl>
 <dt><span class="sect1"><a href="#components.Makefile">11.1. <code class="filename">Makefile</code></a></span></dt>
 <dt><span class="sect1"><a href="#components.distinfo">11.2. <code class="filename">distinfo</code></a></span></dt>
-<dt><span class="sect1"><a href="#components.patches">11.3. patches/*</a></span></dt>
+<dt><span class="sect1"><a href="#components.patches">11.3. <code class="filename">patches/*</code></a></span></dt>
 <dd><dl>
 <dt><span class="sect2"><a href="#components.patch.structure">11.3.1. Structure of a single patch file</a></span></dt>
 <dt><span class="sect2"><a href="#components.patches.caveats">11.3.2. Creating patch files</a></span></dt>
 <dt><span class="sect2"><a href="#components.patches.sources">11.3.3. Sources where the patch files come from</a></span></dt>
 <dt><span class="sect2"><a href="#components.patches.guidelines">11.3.4. Patching guidelines</a></span></dt>
 <dt><span class="sect2"><a href="#components.patches.feedback">11.3.5. Feedback to the author</a></span></dt>
 </dl></dd>
 <dt><span class="sect1"><a href="#other-mandatory-files">11.4. Other mandatory files</a></span></dt>
 <dt><span class="sect1"><a href="#components.optional">11.5. Optional files</a></span></dt>
 <dd><dl>
 <dt><span class="sect2"><a href="#components.optional.bin">11.5.1. Files affecting the binary package</a></span></dt>
 <dt><span class="sect2"><a href="#components.optional.build">11.5.2. Files affecting the build process</a></span></dt>
 <dt><span class="sect2"><a href="#components.optional.none">11.5.3. Files affecting nothing at all</a></span></dt>
 </dl></dd>
 <dt><span class="sect1"><a href="#work-dir">11.6. <code class="filename">work*</code></a></span></dt>
 <dt><span class="sect1"><a href="#files-dir">11.7. <code class="filename">files/*</code></a></span></dt>
 </dl></dd>
 <dt><span class="chapter"><a href="#makefile">12. Programming in <code class="filename">Makefile</code>s</a></span></dt>
 <dd><dl>
 <dt><span class="sect1"><a href="#makefile.style">12.1. Caveats</a></span></dt>
 <dt><span class="sect1"><a href="#makefile.variables">12.2. <code class="filename">Makefile</code> variables</a></span></dt>
 <dd><dl><dt><span class="sect2"><a href="#makefile.variables.names">12.2.1. Naming conventions</a></span></dt></dl></dd>
 <dt><span class="sect1"><a href="#makefile.code">12.3. Code snippets</a></span></dt>
 <dd><dl>
 <dt><span class="sect2"><a href="#adding-to-list">12.3.1. Adding things to a list</a></span></dt>
-<dt><span class="sect2"><a href="#converting-internal-to-external">12.3.2. Converting an internal list into an external list</a></span></dt>
+<dt><span class="sect2"><a href="#passing-variable-to-shell">12.3.2. Passing variables to a shell command</a></span></dt>
-<dt><span class="sect2"><a href="#passing-variable-to-shell">12.3.3. Passing variables to a shell command</a></span></dt>
+<dt><span class="sect2"><a href="#quoting-guideline">12.3.3. Quoting guideline</a></span></dt>
 <dt><span class="sect2"><a href="#quoting-guideline">12.3.4. Quoting guideline</a></span></dt>
 <dt><span class="sect2"><a href="#bsd-make-bug-workaround">12.3.5. Workaround for a bug in BSD Make</a></span></dt>
 </dl></dd>
 </dl></dd>
 <dt><span class="chapter"><a href="#plist">13. PLIST issues</a></span></dt>
 <dd><dl>
 <dt><span class="sect1"><a href="#rcs-id">13.1. RCS ID</a></span></dt>
 <dt><span class="sect1"><a href="#automatic-plist-generation">13.2. Semi-automatic <code class="filename">PLIST</code> generation</a></span></dt>
 <dt><span class="sect1"><a href="#print-PLIST">13.3. Tweaking output of <span class="command"><strong>make print-PLIST</strong></span></a></span></dt>
 <dt><span class="sect1"><a href="#plist.misc">13.4. Variable substitution in PLIST</a></span></dt>
 <dt><span class="sect1"><a href="#manpage-compression">13.5. Man page compression</a></span></dt>
 <dt><span class="sect1"><a href="#using-PLIST_SRC">13.6. Changing PLIST source with <code class="varname">PLIST_SRC</code></a></span></dt>
 <dt><span class="sect1"><a href="#platform-specific-plist">13.7. Platform-specific and differing PLISTs</a></span></dt>
 <dt><span class="sect1"><a href="#build-plist">13.8. Build-specific PLISTs</a></span></dt>
 <dt><span class="sect1"><a href="#faq.common-dirs">13.9. Sharing directories between packages</a></span></dt>
 @@ -3953,27 +3917,27 @@ everything worked.
 </pre>
 </div>
 </div>
 </div>
 </div>
 <div class="chapter">
 <div class="titlepage"><div><div><h2 class="title">
 <a name="components"></a>Chapter�11.�Package components - files, directories and contents</h2></div></div></div>
 <div class="toc">
 <p><b>Table of Contents</b></p>
 <dl class="toc">
 <dt><span class="sect1"><a href="#components.Makefile">11.1. <code class="filename">Makefile</code></a></span></dt>
 <dt><span class="sect1"><a href="#components.distinfo">11.2. <code class="filename">distinfo</code></a></span></dt>
-<dt><span class="sect1"><a href="#components.patches">11.3. patches/*</a></span></dt>
+<dt><span class="sect1"><a href="#components.patches">11.3. <code class="filename">patches/*</code></a></span></dt>
 <dd><dl>
 <dt><span class="sect2"><a href="#components.patch.structure">11.3.1. Structure of a single patch file</a></span></dt>
 <dt><span class="sect2"><a href="#components.patches.caveats">11.3.2. Creating patch files</a></span></dt>
 <dt><span class="sect2"><a href="#components.patches.sources">11.3.3. Sources where the patch files come from</a></span></dt>
 <dt><span class="sect2"><a href="#components.patches.guidelines">11.3.4. Patching guidelines</a></span></dt>
 <dt><span class="sect2"><a href="#components.patches.feedback">11.3.5. Feedback to the author</a></span></dt>
 </dl></dd>
 <dt><span class="sect1"><a href="#other-mandatory-files">11.4. Other mandatory files</a></span></dt>
 <dt><span class="sect1"><a href="#components.optional">11.5. Optional files</a></span></dt>
 <dd><dl>
 <dt><span class="sect2"><a href="#components.optional.bin">11.5.1. Files affecting the binary package</a></span></dt>
 <dt><span class="sect2"><a href="#components.optional.build">11.5.2. Files affecting the build process</a></span></dt>
 <dt><span class="sect2"><a href="#components.optional.none">11.5.3. Files affecting nothing at all</a></span></dt>
 @@ -4125,75 +4089,74 @@ converters    games         mbone
       <span class="quote">&#8220;<span class="quote">${PREFIX}</span>&#8221;</span> in all files (see patches,
       below).</p></li>
 <li class="listitem"><p>If the package installs any info files, see <a class="xref" href="#faq.info-files" title="19.6.7.�Packages installing info files">Section�19.6.7, &#8220;Packages installing info files&#8221;</a>.</p></li>
 </ul></div>
 </div>
 <div class="sect1">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
 <a name="components.distinfo"></a>11.2.�<code class="filename">distinfo</code>
 </h2></div></div></div>
 <p>The <code class="filename">distinfo</code> file contains the message
   digest, or checksum, of each distfile needed for the package. This
   ensures that the distfiles retrieved from the Internet have not been
   corrupted during transfer or altered by a malign force to introduce
-  a security hole. Due to recent rumor about weaknesses of digest
+  a security hole. To provide maximum security, all distfiles are
-  algorithms, all distfiles are protected using both SHA1 and RMD160
+  protected using three different message digest algorithms (SHA1,
-  message digests, as well as the file size.</p>
+  RMD160, SHA512), as well as the file size.</p>
 <p>The <code class="filename">distinfo</code> file also contains the
   checksums for all the patches found in the
-  <code class="filename">patches</code> directory (see <a class="xref" href="#components.patches" title="11.3.�patches/*">Section�11.3, &#8220;patches/*&#8221;</a>).</p>
+  <code class="filename">patches</code> directory (see <a class="xref" href="#components.patches" title="11.3.�patches/*">Section�11.3, &#8220;<code class="filename">patches/*</code>&#8221;</a>).</p>
 <p>To regenerate the <code class="filename">distinfo</code> file, use the
-  <span class="command"><strong>make makedistinfo</strong></span> or <span class="command"><strong>make mdi</strong></span>
+  <span class="command"><strong>make distinfo</strong></span> command.</p>
   command.</p>
 <p>Some packages have different sets of distfiles depending on
   the platform, for example <a href="ftp://ftp.NetBSD.org/pub/pkgsrc/current/pkgsrc/lang/openjdk7/README.html" target="_top"><code class="filename">lang/openjdk7</code></a>. These are kept in the same
   <code class="filename">distinfo</code> file and care should be taken when
   upgrading such a package to ensure distfile information is not
   lost.</p>
 </div>
 <div class="sect1">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="components.patches"></a>11.3.�patches/*</h2></div></div></div>
+<a name="components.patches"></a>11.3.�<code class="filename">patches/*</code>
-<p>Many packages still don't work out-of-the box on the various
+</h2></div></div></div>
-  platforms that are supported by pkgsrc. Therefore, a number of custom
+<p>Some packages don't work out-of-the box on the various
-  patch files are needed to make the package work. These patch files are
+  platforms that are supported by pkgsrc. These packages need
   to be patched to make them work. The patch files can be
   found in the <code class="filename">patches/</code> directory.</p>
 <p>In the <span class="emphasis"><em>patch</em></span> phase, these patches are
   applied to the files in <code class="varname">WRKSRC</code> directory after
-  extracting them, in <a class="ulink" href="http://www.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html#tag_02_13_03" target="_top">alphabetic
+  extracting them, in alphabetic order.</p>
   order</a>.</p>
 <div class="sect2">
 <div class="titlepage"><div><div><h3 class="title">
 <a name="components.patch.structure"></a>11.3.1.�Structure of a single patch file</h3></div></div></div>
 <p>The <code class="filename">patch-*</code> files should be in
   <span class="command"><strong>diff -bu</strong></span> format, and apply without a fuzz to avoid
   problems. (To force patches to apply with fuzz you can set
   <code class="varname">PATCH_FUZZ_FACTOR=-F2</code>). Furthermore, each patch
   should contain only changes for a single file, and no file should be
   patched by more than one patch file. This helps to keep future
   modifications simple.</p>
 <p>Each patch file is structured as follows: In the first line,
   there is the RCS Id of the patch itself. The second line should be
   empty for aesthetic reasons. After that, there should be a comment for
   each change that the patch does. There are a number of standard
   cases:</p>
 <div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; ">
 <li class="listitem"><p>Patches for commonly known vulnerabilities should
   mention the vulnerability ID (CAN, CVE).</p></li>
 <li class="listitem"><p>Patches that change source code should mention the
   platform and other environment (for example, the compiler) that the
   patch is needed for.</p></li>
 </ul></div>
-<p>In all, the patch should be commented so that any
+<p>The patch should be commented so that any
   developer who knows the code of the application can make some use of
   the patch. Special care should be taken for the upstream developers,
   since we generally want that they accept our patches, so we have less
   work in the future.</p>
 </div>
 <div class="sect2">
 <div class="titlepage"><div><div><h3 class="title">
 <a name="components.patches.caveats"></a>11.3.2.�Creating patch files</h3></div></div></div>
 <p>One important thing to mention is to pay attention that no RCS
   IDs get stored in the patch files, as these will cause problems when
   later checked into the NetBSD CVS tree. Use the
   <span class="command"><strong>pkgdiff</strong></span> command from the <a href="ftp://ftp.NetBSD.org/pub/pkgsrc/current/pkgsrc/pkgtools/pkgdiff/README.html" target="_top"><code class="filename">pkgtools/pkgdiff</code></a> package to avoid these
   problems.</p>
 @@ -4564,30 +4527,28 @@ FILESDIR=${.CURDIR}/../xemacs/files
 </div>
 <div class="chapter">
 <div class="titlepage"><div><div><h2 class="title">
 <a name="makefile"></a>Chapter�12.�Programming in <code class="filename">Makefile</code>s</h2></div></div></div>
 <div class="toc">
 <p><b>Table of Contents</b></p>
 <dl class="toc">
 <dt><span class="sect1"><a href="#makefile.style">12.1. Caveats</a></span></dt>
 <dt><span class="sect1"><a href="#makefile.variables">12.2. <code class="filename">Makefile</code> variables</a></span></dt>
 <dd><dl><dt><span class="sect2"><a href="#makefile.variables.names">12.2.1. Naming conventions</a></span></dt></dl></dd>
 <dt><span class="sect1"><a href="#makefile.code">12.3. Code snippets</a></span></dt>
 <dd><dl>
 <dt><span class="sect2"><a href="#adding-to-list">12.3.1. Adding things to a list</a></span></dt>
-<dt><span class="sect2"><a href="#converting-internal-to-external">12.3.2. Converting an internal list into an external list</a></span></dt>
+<dt><span class="sect2"><a href="#passing-variable-to-shell">12.3.2. Passing variables to a shell command</a></span></dt>
-<dt><span class="sect2"><a href="#passing-variable-to-shell">12.3.3. Passing variables to a shell command</a></span></dt>
+<dt><span class="sect2"><a href="#quoting-guideline">12.3.3. Quoting guideline</a></span></dt>
 <dt><span class="sect2"><a href="#quoting-guideline">12.3.4. Quoting guideline</a></span></dt>
 <dt><span class="sect2"><a href="#bsd-make-bug-workaround">12.3.5. Workaround for a bug in BSD Make</a></span></dt>
 </dl></dd>
 </dl>
 </div>
 <p>Pkgsrc consists of many <code class="filename">Makefile</code> fragments,
   each of which forms a well-defined part of the pkgsrc system. Using
   the <a class="citerefentry" href="http://netbsd.gw.com/cgi-bin/man-cgi?make+1+NetBSD-5.0.1+i386"><span class="citerefentry"><span class="refentrytitle">make</span>(1)</span></a> system as a programming language for a big system
   like pkgsrc requires some discipline to keep the code correct and
   understandable.</p>
 <p>The basic ingredients for <code class="filename">Makefile</code>
   programming are variables (which are actually macros) and shell
   commands. Among these shell commands may even be more complex ones
   like <a class="citerefentry" href="http://netbsd.gw.com/cgi-bin/man-cgi?awk+1+NetBSD-5.0.1+i386"><span class="citerefentry"><span class="refentrytitle">awk</span>(1)</span></a> programs. To make sure that every shell command runs
   as intended it is necessary to quote all variables correctly when they
 @@ -4636,44 +4597,34 @@ correct:
     ``:='', and ``!='', which are described in the <a class="citerefentry" href="http://netbsd.gw.com/cgi-bin/man-cgi?make+1+NetBSD-5.0.1+i386"><span class="citerefentry"><span class="refentrytitle">make</span>(1)</span></a> man
     page.</p>
 <p>When a variable's value is parsed from a
     <code class="filename">Makefile</code>, the hash character ``#'' and the
     backslash character ``\'' are handled specially. If a backslash is
     followed by a newline, any whitespace immediately in front of the
     backslash, the backslash, the newline, and any whitespace
     immediately behind the newline are replaced with a single space. A
     backslash character and an immediately following hash character are
     replaced with a single hash character. Otherwise, the backslash is
     passed as is. In a variable assignment, any hash character that is
     not preceded by a backslash starts a comment that continues upto the
     end of the logical line.</p>
-<p><span class="emphasis"><em>Note:</em></span> Because of this parsing algorithm
+<p>The evaluation of variables either happens immediately or lazy.
-    the only way to create a variable consisting of a single backslash
+    It happens immediately when the variable occurs
-    is using the ``!='' operator, for example: <code class="varname">BACKSLASH!=echo "\\"</code>.</p>
+    on the right-hand side of the ``:='' or the ``!='' operator, in a
-<p>So far for defining variables. The other thing you can do with
+    <code class="varname">.if</code> condition or a <code class="varname">.for</code> loop.
-    variables is evaluating them. A variable is evaluated when it is
+    In the other cases, it is evaluated lazily.</p>
     part of the right side of the ``:='' or the ``!='' operator, or
     directly before executing a shell command which the variable is part
     of. In all other cases, <a class="citerefentry" href="http://netbsd.gw.com/cgi-bin/man-cgi?make+1+NetBSD-5.0.1+i386"><span class="citerefentry"><span class="refentrytitle">make</span>(1)</span></a> performs lazy evaluation, that
     is, variables are not evaluated until there's no other way. The
     ``modifiers'' mentioned in the man page also evaluate the
     variable.</p>
 <p>Some of the modifiers split the string into words and then
     operate on the words, others operate on the string as a whole. When
-    a string is split into words, it is split as you would expect
+    a string is split into words, it is split like in <a class="citerefentry" href="http://netbsd.gw.com/cgi-bin/man-cgi?sh+1+NetBSD-5.0.1+i386"><span class="citerefentry"><span class="refentrytitle">sh</span>(1)</span></a>.</p>
     it from <a class="citerefentry" href="http://netbsd.gw.com/cgi-bin/man-cgi?sh+1+NetBSD-5.0.1+i386"><span class="citerefentry"><span class="refentrytitle">sh</span>(1)</span></a>.</p>
 <p>No rule without exception&mdash;the <span class="command"><strong>.for</strong></span>
     loop does not follow the shell quoting rules but splits at sequences
     of whitespace.</p>
 <p>There are several types of variables that should be handled
     differently. Strings and two types of lists.</p>
 <div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; ">
 <li class="listitem"><p><span class="emphasis"><em>Strings</em></span> can contain arbitrary
       characters. Nevertheless, you should restrict yourself to only
       using printable characters. Examples are
       <code class="varname">PREFIX</code> and
       <code class="varname">COMMENT</code>.</p></li>
 <li class="listitem"><p><span class="emphasis"><em>Internal lists</em></span> are lists that
       are never exported to any shell command. Their elements are
       separated by whitespace. Therefore, the elements themselves cannot
       have embedded whitespace. Any other characters are allowed.
       Internal lists can be used in <span class="command"><strong>.for</strong></span> loops.
 @@ -4722,86 +4673,52 @@ ANOTHER_EXT_LIST=       a=b c=d
 INT_LIST+=              ${STRING}               # 1
 INT_LIST+=              ${ANOTHER_INT_LIST}     # 2
 EXT_LIST+=              ${STRING:Q}             # 3
 EXT_LIST+=              ${ANOTHER_EXT_LIST}     # 4
 </pre>
 <p>When you add a string to an external list (example 3), it
       must be quoted. In all other cases, you must not add a quoting
       level. You must not merge internal and external lists, unless you
       are sure that all entries are correctly interpreted in both
       lists.</p>
 </div>
 <div class="sect2">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="converting-internal-to-external"></a>12.3.2.�Converting an internal list into an external list</h3></div></div></div>
+<a name="passing-variable-to-shell"></a>12.3.2.�Passing variables to a shell command</h3></div></div></div>
 <pre class="programlisting">
 EXT_LIST=       # empty
 .for i in ${INT_LIST}
 EXT_LIST+=      ${i:Q}""
 .endfor
 </pre>
 <p>This code converts the internal list
       <code class="varname">INT_LIST</code> into the external list
       <code class="varname">EXT_LIST</code>. As the elements of an internal list
       are unquoted they must be quoted here. The reason for appending
       <code class="varname">""</code> is explained below.</p>
 </div>
 <div class="sect2">
 <div class="titlepage"><div><div><h3 class="title">
 <a name="passing-variable-to-shell"></a>12.3.3.�Passing variables to a shell command</h3></div></div></div>
 <p>Sometimes you may want to print an arbitrary string. There
 	are many ways to get it wrong and only few that can handle every
 	nastiness.</p>
 <pre class="programlisting">
 STRING=         foo bar &lt;    &gt; * `date` $$HOME ' "
-EXT_LIST=       string=${STRING:Q} x=second\ item
+EXAMPLE_ENV=    string=${STRING:Q} x=multiple\ quoted\ words
 all:
         echo ${STRING}                  # 1
-        echo "${STRING}"                # 2
+        echo ${STRING:Q}                # 2
-        echo "${STRING:Q}"              # 3
+        printf '%s\n' ${STRING:Q}''     # 3
-        echo ${STRING:Q}                # 4
+        env ${EXAMPLE_ENV} sh -c 'echo "$$string"; echo "$$x"' # 4
         echo x${STRING:Q} | sed 1s,.,,  # 5
         printf "%s\\n" ${STRING:Q}""    # 6
         env ${EXT_LIST} /bin/sh -c 'echo "$$string"; echo "$$x"'
 </pre>
 <p>Example 1 leads to a syntax error in the shell, as the
       characters are just copied.</p>
-<p>Example 2 leads to a syntax error too, and if you leave out
+<p>Example 2 can handle all strings, except those starting
-      the last " character from <code class="varname">${STRING}</code>,
+      with a dash or those containing backslashes.</p>
-      <a class="citerefentry" href="http://netbsd.gw.com/cgi-bin/man-cgi?date+1+NetBSD-5.0.1+i386"><span class="citerefentry"><span class="refentrytitle">date</span>(1)</span></a> will be executed. The <code class="varname">$HOME</code> shell
+<p>Example 3 can handle arbitrary strings.</p>
-      variable would be evaluated, too.</p>
+<p>In example 4, the <code class="varname">EXT_LIST</code> does not
-<p>Example 3 outputs each space character preceded by a
+      need to be quoted because the quoting has already been done
-      backslash (or not), depending on the implementation of the
+      when adding elements to the list.</p>
       <a class="citerefentry" href="http://netbsd.gw.com/cgi-bin/man-cgi?echo+1+NetBSD-5.0.1+i386"><span class="citerefentry"><span class="refentrytitle">echo</span>(1)</span></a> command.</p>
 <p>Example 4 handles correctly every string that does not start
       with a dash. In that case, the result depends on the
       implementation of the <a class="citerefentry" href="http://netbsd.gw.com/cgi-bin/man-cgi?echo+1+NetBSD-5.0.1+i386"><span class="citerefentry"><span class="refentrytitle">echo</span>(1)</span></a> command. As long as you can
       guarantee that your input does not start with a dash, this form is
       appropriate.</p>
 <p>Example 5 handles even the case of a leading dash
       correctly.</p>
 <p>Example 6 also works with every string and is the
       light-weight solution, since it does not involve a pipe, which has
       its own problems.</p>
 <p>The <code class="varname">EXT_LIST</code> does not need to be quoted
       because the quoting has already been done when adding elements to
       the list.</p>
 <p>As internal lists shall not be passed to the shell, there is
       no example for it.</p>
 </div>
 <div class="sect2">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="quoting-guideline"></a>12.3.4.�Quoting guideline</h3></div></div></div>
+<a name="quoting-guideline"></a>12.3.3.�Quoting guideline</h3></div></div></div>
 <p>There are many possible sources of wrongly quoted variables.
       This section lists some of the commonly known ones.</p>
 <div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; ">
 <li class="listitem">
 <p>Whenever you use the value of a list, think
 	about what happens to leading or trailing whitespace. If the
 	list is a well-formed shell expression, you can apply the
 	<code class="varname">:M*</code> modifier to strip leading and trailing
 	whitespace from each word. The <code class="varname">:M</code> operator
 	first splits its argument according to the rules of the shell,
 	and then creates a new list consisting of all words that match
 	the shell glob expression <code class="varname">*</code>, that is: all.
 	One class of situations where this is needed is when adding a
 @@ -4862,40 +4779,26 @@ for_test:
 	<code class="varname">${EMPTY:Q}""</code>. This pattern can be often found
 	as <code class="varname">${TEST} -z ${VAR:Q}</code> or as <code class="varname">${TEST}
 	-f ${FNAME:Q}</code> (both of these are wrong).</p>
 <p>The second example will only print three lines instead of
 	four. The first line looks like <code class="varname">a:\ echo foo</code>.
 	This is because the backslash of the value
 	<code class="varname">a:\</code> is interpreted as a line-continuation by
 	<a class="citerefentry" href="http://netbsd.gw.com/cgi-bin/man-cgi?make+1+NetBSD-5.0.1+i386"><span class="citerefentry"><span class="refentrytitle">make</span>(1)</span></a>, which makes the second line the arguments of the
 	<a class="citerefentry" href="http://netbsd.gw.com/cgi-bin/man-cgi?echo+1+NetBSD-5.0.1+i386"><span class="citerefentry"><span class="refentrytitle">echo</span>(1)</span></a> command from the first line. To avoid this, write
 	<code class="varname">${i:Q}""</code>.</p>
 </li>
 </ul></div>
 </div>
 <div class="sect2">
 <div class="titlepage"><div><div><h3 class="title">
 <a name="bsd-make-bug-workaround"></a>12.3.5.�Workaround for a bug in BSD Make</h3></div></div></div>
 <p>The pkgsrc bmake program does not handle the following
       assignment correctly. In case <code class="varname">_othervar_</code>
       contains a ``-'' character, one of the closing braces is included
       in <code class="varname">${VAR}</code> after this code executes.</p>
 <pre class="programlisting">
 VAR:=   ${VAR:N${_othervar_:C/-//}}
 </pre>
 <p>For a more complex code snippet and a workaround, see the
       package <a href="ftp://ftp.NetBSD.org/pub/pkgsrc/current/pkgsrc/regress/make-quoting/README.html" target="_top"><code class="filename">regress/make-quoting</code></a>, testcase
       <code class="varname">bug1</code>.</p>
 </div>
 </div>
 </div>
 <div class="chapter">
 <div class="titlepage"><div><div><h2 class="title">
 <a name="plist"></a>Chapter�13.�PLIST issues</h2></div></div></div>
 <div class="toc">
 <p><b>Table of Contents</b></p>
 <dl class="toc">
 <dt><span class="sect1"><a href="#rcs-id">13.1. RCS ID</a></span></dt>
 <dt><span class="sect1"><a href="#automatic-plist-generation">13.2. Semi-automatic <code class="filename">PLIST</code> generation</a></span></dt>
 <dt><span class="sect1"><a href="#print-PLIST">13.3. Tweaking output of <span class="command"><strong>make print-PLIST</strong></span></a></span></dt>
 <dt><span class="sect1"><a href="#plist.misc">13.4. Variable substitution in PLIST</a></span></dt>
 <dt><span class="sect1"><a href="#manpage-compression">13.5. Man page compression</a></span></dt>
 @@ -6306,27 +6209,27 @@ details.
 <div class="sect1">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
 <a name="build.prefix"></a>17.2.�Program location</h2></div></div></div>
 <p>Before outlining the process performed by the NetBSD package system in
     the next section, here's a brief discussion on where programs are
     installed, and which variables influence this.</p>
 <p>The automatic variable <code class="varname">PREFIX</code> indicates
     where all files of the final program shall be installed. It is
     usually set to <code class="varname">LOCALBASE</code>
     (<code class="filename">/usr/pkg</code>), or <code class="varname">CROSSBASE</code>
     for pkgs in the <code class="filename">cross</code> category.  The value of
     <code class="varname">PREFIX</code> needs to be put
     into the various places in the program's source where paths to
-    these files are encoded.  See <a class="xref" href="#components.patches" title="11.3.�patches/*">Section�11.3, &#8220;patches/*&#8221;</a> and <a class="xref" href="#fixes.libtool" title="19.3.1.�Shared libraries - libtool">Section�19.3.1, &#8220;Shared libraries - libtool&#8221;</a> for more details.</p>
+    these files are encoded.  See <a class="xref" href="#components.patches" title="11.3.�patches/*">Section�11.3, &#8220;<code class="filename">patches/*</code>&#8221;</a> and <a class="xref" href="#fixes.libtool" title="19.3.1.�Shared libraries - libtool">Section�19.3.1, &#8220;Shared libraries - libtool&#8221;</a> for more details.</p>
 <p>When choosing which of these variables to use,
     follow the following rules:</p>
 <div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; ">
 <li class="listitem"><p><code class="varname">PREFIX</code> always points to the location
 	where the current pkg will be installed.  When referring to a
 	pkg's own installation path, use
 	<span class="quote">&#8220;<span class="quote">${PREFIX}</span>&#8221;</span>.</p></li>
 <li class="listitem"><p><code class="varname">LOCALBASE</code> is where all non-X11 pkgs
 	are installed.  If you need to construct a -I or -L argument
 	to the compiler to find includes and libraries installed by
 	another non-X11 pkg, use <span class="quote">&#8220;<span class="quote">${LOCALBASE}</span>&#8221;</span>. The name
 	<code class="varname">LOCALBASE</code> stems from FreeBSD, which
 	installed all packages in <code class="filename">/usr/local</code>. As
 @@ -6640,27 +6543,27 @@ ${FETCH_CMD} ${FETCH_BEFORE_ARGS} ${site
 <div class="sect1">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
 <a name="build.patch"></a>17.8.�The <span class="emphasis"><em>patch</em></span> phase</h2></div></div></div>
 <p>After extraction, all the patches named by the
     <code class="varname">PATCHFILES</code>, those present in the patches
     subdirectory of the package as well as in
     $LOCALPATCHES/$PKGPATH (e.g.
     <code class="filename">/usr/local/patches/graphics/png</code>) are
     applied.  Patchfiles ending in <code class="filename">.Z</code> or
     <code class="filename">.gz</code> are uncompressed before they are
     applied, files ending in <code class="filename">.orig</code> or
     <code class="filename">.rej</code> are ignored. Any special options to
     <a class="citerefentry" href="http://netbsd.gw.com/cgi-bin/man-cgi?patch+1+NetBSD-5.0.1+i386"><span class="citerefentry"><span class="refentrytitle">patch</span>(1)</span></a> can be handed in
-    <code class="varname">PATCH_DIST_ARGS</code>.  See <a class="xref" href="#components.patches" title="11.3.�patches/*">Section�11.3, &#8220;patches/*&#8221;</a> for more details.</p>
+    <code class="varname">PATCH_DIST_ARGS</code>.  See <a class="xref" href="#components.patches" title="11.3.�patches/*">Section�11.3, &#8220;<code class="filename">patches/*</code>&#8221;</a> for more details.</p>
 <p>By default <a class="citerefentry" href="http://netbsd.gw.com/cgi-bin/man-cgi?patch+1+NetBSD-5.0.1+i386"><span class="citerefentry"><span class="refentrytitle">patch</span>(1)</span></a> is given special args to make
     it fail if the patches apply with some lines of fuzz. Please
     fix (regen) the patches so that they apply cleanly. The
     rationale behind this is that patches that don't apply cleanly
     may end up being applied in the wrong place, and cause severe
     harm there.</p>
 </div>
 <div class="sect1">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
 <a name="build.tools"></a>17.9.�The <span class="emphasis"><em>tools</em></span> phase</h2></div></div></div>
 <p>This is covered in <a class="xref" href="#tools" title="Chapter�18.�Tools needed for building or running">Chapter�18, <i>Tools needed for building or running</i></a>.
     </p>
 </div>
 @@ -7357,67 +7260,67 @@ the name of the common tools. For exampl
 .if exists(/usr/bin/bzcat)
 TOOLS_PLATFORM.bzcat?=          /usr/bin/bzcat
 .elif exists(/usr/bin/bzip2)
 TOOLS_PLATFORM.bzcat?=          /usr/bin/bzip2 -cd
 .endif
 TOOLS_PLATFORM.true?=           true                    # shell builtin
 </pre>
 </div>
 <div class="sect1">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
 <a name="tools.questions"></a>18.4.�Questions regarding the tools</h2></div></div></div>
 <div class="qandaset">
-<a name="idm83805728"></a><dl>
+<a name="idm83808672"></a><dl>
 <dt>18.4.1. <a href="#tools.new">How do I add a new tool?</a>
 </dt>
 <dt>18.4.2. <a href="#tools.listall">How do I get a list of all available
 	tools?</a>
 </dt>
 <dt>18.4.3. <a href="#tools.used">How can I get a list of all the tools that a
 	package is using while being built? I want to know whether it
 	uses sed or not.</a>
 </dt>
 </dl>
 <table border="0" style="width: 100%;">
 <colgroup>
 <col align="left" width="1%">
 <col>
 </colgroup>
 <tbody>
 <tr class="question">
 <td align="left" valign="top">
-<a name="tools.new"></a><a name="idm83805344"></a><p><b>18.4.1.</b></p>
+<a name="tools.new"></a><a name="idm83808288"></a><p><b>18.4.1.</b></p>
 </td>
 <td align="left" valign="top"><p>How do I add a new tool?</p></td>
 </tr>
 <tr class="answer">
 <td align="left" valign="top"></td>
 <td align="left" valign="top"><p>TODO</p></td>
 </tr>
 <tr class="question">
 <td align="left" valign="top">
-<a name="tools.listall"></a><a name="idm83804320"></a><p><b>18.4.2.</b></p>
+<a name="tools.listall"></a><a name="idm83807264"></a><p><b>18.4.2.</b></p>
 </td>
 <td align="left" valign="top"><p>How do I get a list of all available
 	tools?</p></td>
 </tr>
 <tr class="answer">
 <td align="left" valign="top"></td>
 <td align="left" valign="top"><p>TODO</p></td>
 </tr>
 <tr class="question">
 <td align="left" valign="top">
-<a name="tools.used"></a><a name="idm83803296"></a><p><b>18.4.3.</b></p>
+<a name="tools.used"></a><a name="idm83806240"></a><p><b>18.4.3.</b></p>
 </td>
 <td align="left" valign="top"><p>How can I get a list of all the tools that a
 	package is using while being built? I want to know whether it
 	uses sed or not.</p></td>
 </tr>
 <tr class="answer">
 <td align="left" valign="top"></td>
 <td align="left" valign="top"><p>Currently, you can't. (TODO: But I want to be able
 	to do it.)</p></td>
 </tr>
 </tbody>
 </table>
 </div>
 @@ -7508,34 +7411,35 @@ TOOLS_PLATFORM.true?=           true
 <div class="sect2">
 <div class="titlepage"><div><div><h3 class="title">
 <a name="pulling-vars-from-etc-mk.conf"></a>19.1.1.�How to pull in user-settable variables from <a class="link" href="#mk.conf"><code class="filename">mk.conf</code></a>
 </h3></div></div></div>
 <p>The pkgsrc user can configure pkgsrc by overriding several
     variables in the file pointed to by <code class="varname">MAKECONF</code>,
     which is <a class="link" href="#mk.conf"><code class="filename">mk.conf</code></a> by default. When you
     want to use those variables in the preprocessor directives of
     <a class="citerefentry" href="http://netbsd.gw.com/cgi-bin/man-cgi?make+1+NetBSD-5.0.1+i386"><span class="citerefentry"><span class="refentrytitle">make</span>(1)</span></a> (for example <code class="literal">.if</code> or
     <code class="literal">.for</code>), you need to include the file
     <code class="filename">../../mk/bsd.prefs.mk</code> before, which in turn
     loads the user preferences.</p>
 <p>But note that some variables may not be completely defined
-    after <code class="filename">../../mk/bsd.prefs.mk</code> has been included,
+    after <code class="filename">../../mk/bsd.prefs.mk</code> has been
-    as they may contain references to variables that are not yet
+    included, as they may contain references to variables that are
-    defined. In shell commands (the lines in
+    not yet defined. In shell commands (the lines in
-    <code class="filename">Makefile</code> that are indented with a tab) this is
+    <code class="filename">Makefile</code> that are indented with a tab) this
-    no problem, since variables are only expanded when they are used.
+    is no problem, since variables are only expanded when they are
-    But in the preprocessor directives mentioned above and in dependency
+    used. But in the preprocessor directives mentioned above and in
-    lines (of the form <code class="literal">target: dependencies</code>) the
+    dependency lines (of the form <code class="literal">target:
-    variables are expanded at load time.</p>
+    dependencies</code>) the variables are expanded at load
     time.</p>
 <div class="note" style="margin-left: 0.5in; margin-right: 0.5in;">
 <h3 class="title">Note</h3>
 <p>To check whether a variable can be used at load time,
     run <span class="command"><strong>pkglint -Wall</strong></span> on your package.</p>
 </div>
 </div>
 <div class="sect2">
 <div class="titlepage"><div><div><h3 class="title">
 <a name="user-interaction"></a>19.1.2.�User interaction</h3></div></div></div>
 <p>Occasionally, packages require interaction from the user,
     and this can be in a number of ways:</p>
 <div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; ">
 <li class="listitem"><p>When fetching the distfiles, some packages require user
 @@ -7557,28 +7461,32 @@ INTERACTIVE_STAGE=      configure instal
     <code class="varname">BATCH</code> variable. Packages that require interaction
     are also excluded from bulk builds.</p>
 </div>
 <div class="sect2">
 <div class="titlepage"><div><div><h3 class="title">
 <a name="handling-licenses"></a>19.1.3.�Handling licenses</h3></div></div></div>
 <p>Authors of software can choose the licence under which
     software can be copied.  This is due to copyright law, and reasons
     for license choices are outside the scope of pkgsrc.  The pkgsrc
     system recognizes that there are a number of licenses which some
     users may find objectionable or difficult or impossible to comply
     with.  The Free Software Foundation has declared some licenses
     "Free", and the Open Source Initiative has a definition of "Open
-    Source".  Note that a package whose license forbids to copy does
+    Source".  The pkgsrc system, as a policy choice, does not label
-    not meet either the Free or Open Source test.</p>
+    packages which have licenses that are Free or Open Source.
     However, packages without a license meeting either of those tests
     are labeled with a license tag denoting the license.  Note that a
     package with no license to copy trivially does not meet either the
     Free or Open Source test.</p>
 <p>For packages which are not Free or Open Source, pkgsrc will
     not build the package unless the user has indicated to pkgsrc that
     packages with that particular license may be built.  Note that
     this documentation avoids the term "accepted the license".  The
     pkgsrc system is merely providing a mechanism to avoid
     accidentally building a package with a non-free license;
     judgement and responsibility remain with the user.  (Installation
     of binary packages are not currently subject to this mechanism;
     this is a bug.)</p>
 <p>One might want to only install packages with a BSD license,
     or the GPL, and not the other.  The free licenses are added to the
     default <code class="varname">ACCEPTABLE_LICENSES</code> variable.  The
     user can override the default by setting the
 @@ -9544,27 +9452,27 @@ place.
 </li>
 </ol></div>
 </div>
 </div>
 <div class="chapter">
 <div class="titlepage"><div><div><h2 class="title">
 <a name="devfaq"></a>Chapter�22.�Frequently Asked Questions</h2></div></div></div>
 <p>This section contains the answers to questions that may
 	arise when you are writing a package. If you don't find your
 	question answered here, first have a look in the other chapters,
 	and if you still don't have the answer, ask on the
 	<code class="literal">pkgsrc-users</code> mailing list.</p>
 <div class="qandaset">
-<a name="idm83229600"></a><dl>
+<a name="idm83207968"></a><dl>
 <dt>22.1. <a href="#devfaq.makeflags">What is the difference between
 	MAKEFLAGS, .MAKEFLAGS and
 	MAKE_FLAGS?</a>
 </dt>
 <dt>22.2. <a href="#devfaq.make">What is the difference between
 	MAKE, GMAKE and
 	MAKE_PROGRAM?</a>
 </dt>
 <dt>22.3. <a href="#devfaq.cc">What is the difference between
 	CC, PKG_CC and
 	PKGSRC_COMPILER?</a>
 </dt>
 <dt>22.4. <a href="#devfaq.bl3flags">What is the difference between
 @@ -9589,157 +9497,157 @@ place.
 </dt>
 <dt>22.9. <a href="#devfaq.too-much-time">I have a little time to kill.  What shall I
 do?</a>
 </dt>
 </dl>
 <table border="0" style="width: 100%;">
 <colgroup>
 <col align="left" width="1%">
 <col>
 </colgroup>
 <tbody>
 <tr class="question">
 <td align="left" valign="top">
-<a name="devfaq.makeflags"></a><a name="idm83229216"></a><p><b>22.1.</b></p>
+<a name="devfaq.makeflags"></a><a name="idm83207584"></a><p><b>22.1.</b></p>
 </td>
 <td align="left" valign="top"><p>What is the difference between
 	<code class="varname">MAKEFLAGS</code>, <code class="varname">.MAKEFLAGS</code> and
 	<code class="varname">MAKE_FLAGS</code>?</p></td>
 </tr>
 <tr class="answer">
 <td align="left" valign="top"></td>
 <td align="left" valign="top"><p><code class="varname">MAKEFLAGS</code> are the flags passed
 	to the pkgsrc-internal invocations of <a class="citerefentry" href="http://netbsd.gw.com/cgi-bin/man-cgi?make+1+NetBSD-5.0.1+i386"><span class="citerefentry"><span class="refentrytitle">make</span>(1)</span></a>, while
 	<code class="varname">MAKE_FLAGS</code> are the flags that are passed to
 	the <code class="varname">MAKE_PROGRAM</code> when building the
 	package. [FIXME: What is .MAKEFLAGS for?]</p></td>
 </tr>
 <tr class="question">
 <td align="left" valign="top">
-<a name="devfaq.make"></a><a name="idm83225248"></a><p><b>22.2.</b></p>
+<a name="devfaq.make"></a><a name="idm83203488"></a><p><b>22.2.</b></p>
 </td>
 <td align="left" valign="top"><p>What is the difference between
 	<code class="varname">MAKE</code>, <code class="varname">GMAKE</code> and
 	<code class="varname">MAKE_PROGRAM</code>?</p></td>
 </tr>
 <tr class="answer">
 <td align="left" valign="top"></td>
 <td align="left" valign="top"><p><code class="varname">MAKE</code> is the path to the
 	<a class="citerefentry" href="http://netbsd.gw.com/cgi-bin/man-cgi?make+1+NetBSD-5.0.1+i386"><span class="citerefentry"><span class="refentrytitle">make</span>(1)</span></a> program that is used in the pkgsrc
 	infrastructure. <code class="varname">GMAKE</code> is the path to GNU
 	Make, but you need to say <code class="varname">USE_TOOLS+=gmake</code> to
 	use that. <code class="varname">MAKE_PROGRAM</code> is the path to the
 	Make program that is used for building the
 	package.</p></td>
 </tr>
 <tr class="question">
 <td align="left" valign="top">
-<a name="devfaq.cc"></a><a name="idm83220768"></a><p><b>22.3.</b></p>
+<a name="devfaq.cc"></a><a name="idm83199136"></a><p><b>22.3.</b></p>
 </td>
 <td align="left" valign="top"><p>What is the difference between
 	<code class="varname">CC</code>, <code class="varname">PKG_CC</code> and
 	<code class="varname">PKGSRC_COMPILER</code>?</p></td>
 </tr>
 <tr class="answer">
 <td align="left" valign="top"></td>
 <td align="left" valign="top"><p><code class="varname">CC</code> is the path to the real C
 	compiler, which can be configured by the pkgsrc user.
 	<code class="varname">PKG_CC</code> is the path to the compiler wrapper.
 	<code class="varname">PKGSRC_COMPILER</code> is <span class="emphasis"><em>not</em></span> a
 	path to a compiler, but the type of compiler that should be
 	used. See <code class="filename">mk/compiler.mk</code> for more
 	information about the latter variable.</p></td>
 </tr>
 <tr class="question">
 <td align="left" valign="top">
-<a name="devfaq.bl3flags"></a><a name="idm83216672"></a><p><b>22.4.</b></p>
+<a name="devfaq.bl3flags"></a><a name="idm83194912"></a><p><b>22.4.</b></p>
 </td>
 <td align="left" valign="top"><p>What is the difference between
 	<code class="varname">BUILDLINK_LDFLAGS</code>,
 	<code class="varname">BUILDLINK_LDADD</code> and
 	<code class="varname">BUILDLINK_LIBS</code>?</p></td>
 </tr>
 <tr class="answer">
 <td align="left" valign="top"></td>
 <td align="left" valign="top"><p>[FIXME]</p></td>
 </tr>
 <tr class="question">
 <td align="left" valign="top">
-<a name="devfaq.bl3prefix"></a><a name="idm83214368"></a><p><b>22.5.</b></p>
+<a name="devfaq.bl3prefix"></a><a name="idm83192736"></a><p><b>22.5.</b></p>
 </td>
 <td align="left" valign="top"><p>Why does <span class="command"><strong>make show-var
 	VARNAME=BUILDLINK_PREFIX.<em class="replaceable"><code>foo</code></em></strong></span>
 	say it's empty?</p></td>
 </tr>
 <tr class="answer">
 <td align="left" valign="top"></td>
 <td align="left" valign="top"><p>For optimization reasons, some variables are only
 	available in the <span class="quote">&#8220;<span class="quote">wrapper</span>&#8221;</span> phase and later. To
 	<span class="quote">&#8220;<span class="quote">simulate</span>&#8221;</span> the wrapper phase, append
 	<span class="command"><strong>PKG_PHASE=wrapper</strong></span> to the above
 	command.</p></td>
 </tr>
 <tr class="question">
 <td align="left" valign="top">
-<a name="devfaq.master_sites"></a><a name="idm83211296"></a><p><b>22.6.</b></p>
+<a name="devfaq.master_sites"></a><a name="idm83189664"></a><p><b>22.6.</b></p>
 </td>
 <td align="left" valign="top"><p>What does
 	<code class="literal">${MASTER_SITE_SOURCEFORGE:=package/}</code> mean? I
 	don't understand the <code class="literal">:=</code> inside
 	it.</p></td>
 </tr>
 <tr class="answer">
 <td align="left" valign="top"></td>
 <td align="left" valign="top"><p>The <code class="literal">:=</code> is not really an
 	assignment operator, like you might expect at first sight.
 	Instead, it is a degenerate form of
 	<code class="literal">${LIST:<em class="replaceable"><code>old_string</code></em>=<em class="replaceable"><code>new_string</code></em>}</code>,
 	which is documented in the <a class="citerefentry" href="http://netbsd.gw.com/cgi-bin/man-cgi?make+1+NetBSD-5.0.1+i386"><span class="citerefentry"><span class="refentrytitle">make</span>(1)</span></a> man page and which you
 	may have seen as in <code class="literal">${SRCS:.c=.o}</code>. In the
 	case of <code class="varname">MASTER_SITE_*</code>,
 	<em class="replaceable"><code>old_string</code></em> is the empty string and
 	<em class="replaceable"><code>new_string</code></em> is
 	<code class="literal">package/</code>. That's where the
 	<code class="literal">:</code> and the <code class="literal">=</code> fall
 	together.</p></td>
 </tr>
 <tr class="question">
 <td align="left" valign="top">
-<a name="devfaq.mailinglists"></a><a name="idm83203232"></a><p><b>22.7.</b></p>
+<a name="devfaq.mailinglists"></a><a name="idm83173408"></a><p><b>22.7.</b></p>
 </td>
 <td align="left" valign="top"><p>Which mailing lists are there for package
 	developers?</p></td>
 </tr>
 <tr class="answer">
 <td align="left" valign="top"></td>
 <td align="left" valign="top"><div class="variablelist"><dl class="variablelist">
 <dt><span class="term"><a class="ulink" href="http://www.NetBSD.org/mailinglists/index.html#tech-pkg" target="_top">tech-pkg</a></span></dt>
 <dd><p>This is a list for technical discussions related
 	to pkgsrc development, e.g. soliciting feedback for changes to
 	pkgsrc infrastructure, proposed new features, questions related
 	to porting pkgsrc to a new platform, advice for maintaining a
 	package, patches that affect many packages, help requests moved
 	from pkgsrc-users when an infrastructure bug is found,
 	etc.</p></dd>
 <dt><span class="term"><a class="ulink" href="http://www.NetBSD.org/mailinglists/index.html#pkgsrc-bugs" target="_top">pkgsrc-bugs</a></span></dt>
 <dd><p>All bug reports in category "pkg" sent with
 	<a class="citerefentry" href="http://netbsd.gw.com/cgi-bin/man-cgi?send-pr+1+NetBSD-5.0.1+i386"><span class="citerefentry"><span class="refentrytitle">send-pr</span>(1)</span></a> appear here. Please do not report your bugs here
 	directly; use one of the other mailing
 	lists.</p></dd>
 </dl></div></td>
 </tr>
 <tr class="question">
 <td align="left" valign="top">
-<a name="devfaq.documentation"></a><a name="idm83199392"></a><p><b>22.8.</b></p>
+<a name="devfaq.documentation"></a><a name="idm83169568"></a><p><b>22.8.</b></p>
 </td>
 <td align="left" valign="top"><p>Where is the pkgsrc
 	documentation?</p></td>
 </tr>
 <tr class="answer">
 <td align="left" valign="top"></td>
 <td align="left" valign="top">
 <p>There are many places where you can find
 	documentation about pkgsrc:</p>
 <div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; ">
 <li class="listitem"><p>The pkgsrc guide (this document) is a collection
 	of chapters that explain large parts of pkgsrc, but some
 	chapters tend to be outdated. Which ones they are is hard to
 @@ -9767,27 +9675,27 @@ do?
 	documented</span>&#8221;</span>, that is the documentation exists only in the
 	mind of the developer who wrote the code. To get this
 	information, use the <span class="command"><strong>cvs annotate</strong></span> command
 	to see who has written it and ask on the
 	<code class="literal">tech-pkg</code> mailing list, so that others can
 	find your questions later (see above). To be sure that the
 	developer in charge reads the mail, you may CC him or
 	her.</p></li>
 </ul></div>
 </td>
 </tr>
 <tr class="question">
 <td align="left" valign="top">
-<a name="devfaq.too-much-time"></a><a name="idm83192992"></a><p><b>22.9.</b></p>
+<a name="devfaq.too-much-time"></a><a name="idm83163168"></a><p><b>22.9.</b></p>
 </td>
 <td align="left" valign="top"><p>I have a little time to kill.  What shall I
 do?</p></td>
 </tr>
 <tr class="answer">
 <td align="left" valign="top"></td>
 <td align="left" valign="top">
 <p>This is not really an FAQ yet, but here's the answer
 anyway.</p>
 <div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; ">
 <li class="listitem"><p>Run <span class="command"><strong>pkg_chk -N</strong></span> (from the
     <a href="ftp://ftp.NetBSD.org/pub/pkgsrc/current/pkgsrc/pkgtools/pkg_chk/README.html" target="_top"><code class="filename">pkgtools/pkg_chk</code></a> package).  It
     will tell you about newer versions of installed packages that are
 @@ -10126,39 +10034,35 @@ details.
 <dt><span class="sect1"><a href="#infr.design.intf">24.5. Designing interfaces for Makefile fragments</a></span></dt>
 <dd><dl>
 <dt><span class="sect2"><a href="#infr.design.intf.proc">24.5.1. Procedures with parameters</a></span></dt>
 <dt><span class="sect2"><a href="#infr.design.intf.action">24.5.2. Actions taken on behalf of parameters</a></span></dt>
 </dl></dd>
 <dt><span class="sect1"><a href="#infr.order">24.6. The order in which files are loaded</a></span></dt>
 <dd><dl>
 <dt><span class="sect2"><a href="#infr.order.prefs">24.6.1. The order in <code class="filename">bsd.prefs.mk</code></a></span></dt>
 <dt><span class="sect2"><a href="#infr.order.pkg">24.6.2. The order in <code class="filename">bsd.pkg.mk</code></a></span></dt>
 </dl></dd>
 </dl></dd>
 <dt><span class="chapter"><a href="#regression">25. Regression tests</a></span></dt>
 <dd><dl>
-<dt><span class="sect1"><a href="#regression.descr">25.1. The regression tests framework</a></span></dt>
+<dt><span class="sect1"><a href="#regression.run">25.1. Running the regression tests</a></span></dt>
-<dt><span class="sect1"><a href="#regression.run">25.2. Running the regression tests</a></span></dt>
+<dt><span class="sect1"><a href="#regression.new">25.2. Adding a new regression test</a></span></dt>
 <dt><span class="sect1"><a href="#regression.new">25.3. Adding a new regression test</a></span></dt>
 <dd><dl>
-<dt><span class="sect2"><a href="#regression.fun.override">25.3.1. Overridable functions</a></span></dt>
+<dt><span class="sect2"><a href="#regression.fun.override">25.2.1. Overridable functions</a></span></dt>
-<dt><span class="sect2"><a href="#regression.fun.helper">25.3.2. Helper functions</a></span></dt>
+<dt><span class="sect2"><a href="#regression.fun.helper">25.2.2. Helper functions</a></span></dt>
 </dl></dd>
 </dl></dd>
 <dt><span class="chapter"><a href="#porting">26. Porting pkgsrc</a></span></dt>
-<dd><dl>
+<dd><dl><dt><span class="sect1"><a href="#porting.opsys">26.1. Porting pkgsrc to a new operating system</a></span></dt></dl></dd>
 <dt><span class="sect1"><a href="#porting.opsys">26.1. Porting pkgsrc to a new operating system</a></span></dt>
 <dt><span class="sect1"><a href="#porting.compiler">26.2. Adding support for a new compiler</a></span></dt>
 </dl></dd>
 </dl>
 </div>
 </div>
 <div class="chapter">
 <div class="titlepage"><div><div><h2 class="title">
 <a name="infr.design"></a>Chapter�24.�Design of the pkgsrc infrastructure</h2></div></div></div>
 <div class="toc">
 <p><b>Table of Contents</b></p>
 <dl class="toc">
 <dt><span class="sect1"><a href="#infr.vardef">24.1. The meaning of variable definitions</a></span></dt>
 <dt><span class="sect1"><a href="#infr.vardef.problems">24.2. Avoiding problems before they arise</a></span></dt>
 <dt><span class="sect1"><a href="#infr.var">24.3. Variable evaluation</a></span></dt>
 <dd><dl>
 @@ -10421,68 +10325,62 @@ CFLAGS+=                -Wall
 	matter.</p>
 <p>At last, some more files are included that don't set any
 	interesting variables but rather just define make targets to be
 	executed.</p>
 </div>
 </div>
 </div>
 <div class="chapter">
 <div class="titlepage"><div><div><h2 class="title">
 <a name="regression"></a>Chapter�25.�Regression tests</h2></div></div></div>
 <div class="toc">
 <p><b>Table of Contents</b></p>
 <dl class="toc">
-<dt><span class="sect1"><a href="#regression.descr">25.1. The regression tests framework</a></span></dt>
+<dt><span class="sect1"><a href="#regression.run">25.1. Running the regression tests</a></span></dt>
-<dt><span class="sect1"><a href="#regression.run">25.2. Running the regression tests</a></span></dt>
+<dt><span class="sect1"><a href="#regression.new">25.2. Adding a new regression test</a></span></dt>
 <dt><span class="sect1"><a href="#regression.new">25.3. Adding a new regression test</a></span></dt>
 <dd><dl>
-<dt><span class="sect2"><a href="#regression.fun.override">25.3.1. Overridable functions</a></span></dt>
+<dt><span class="sect2"><a href="#regression.fun.override">25.2.1. Overridable functions</a></span></dt>
-<dt><span class="sect2"><a href="#regression.fun.helper">25.3.2. Helper functions</a></span></dt>
+<dt><span class="sect2"><a href="#regression.fun.helper">25.2.2. Helper functions</a></span></dt>
 </dl></dd>
 </dl>
 </div>
 <p>The pkgsrc infrastructure consists of a large codebase,
 	and there are many corners where every little bit of a file is
 	well thought out, making pkgsrc likely to fail as soon as
 	anything is changed near those parts. To prevent most changes
 	from breaking anything, a suite of regression tests should go
 	along with every important part of the pkgsrc infrastructure.
 	This chapter describes how regression tests work in pkgsrc and
 	how you can add new tests.</p>
 <div class="sect1">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="regression.descr"></a>25.1.�The regression tests framework</h2></div></div></div>
+<a name="regression.run"></a>25.1.�Running the regression tests</h2></div></div></div>
 <p></p>
 </div>
 <div class="sect1">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
 <a name="regression.run"></a>25.2.�Running the regression tests</h2></div></div></div>
 <p>You first need to install the <a href="ftp://ftp.NetBSD.org/pub/pkgsrc/current/pkgsrc/pkgtools/pkg_regress/README.html" target="_top"><code class="filename">pkgtools/pkg_regress</code></a> package, which
 	provides the <span class="command"><strong>pkg_regress</strong></span> command. Then you
 	can simply run that command, which will run all tests in the
 	<code class="filename">regress</code> category.</p>
 </div>
 <div class="sect1">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="regression.new"></a>25.3.�Adding a new regression test</h2></div></div></div>
+<a name="regression.new"></a>25.2.�Adding a new regression test</h2></div></div></div>
 <p>Every directory in the <code class="filename">regress</code>
 	category that contains a file called <code class="filename">spec</code>
 	is considered a regression test. This file is a shell program
 	that is included by the <span class="command"><strong>pkg_regress</strong></span> command.
 	The following functions can be overridden to suit your
 	needs.</p>
 <div class="sect2">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="regression.fun.override"></a>25.3.1.�Overridable functions</h3></div></div></div>
+<a name="regression.fun.override"></a>25.2.1.�Overridable functions</h3></div></div></div>
 <p>These functions do not take any parameters. Although they
 	are called in <span class="quote">&#8220;<span class="quote">set -e</span>&#8221;</span> mode, they don't stop at the
 	first failing command. See <a class="ulink" href="http://stackoverflow.com/q/4072984" target="_top">this StackOverflow
 	question</a> for details.</p>
 <div class="variablelist"><dl class="variablelist">
 <dt><span class="term"><code class="varname">do_setup</code></span></dt>
 <dd><p>This function prepares the environment for the
 	test. By default it does nothing.</p></dd>
 <dt><span class="term"><code class="varname">do_test</code></span></dt>
 <dd>
 <p>This function runs the actual test. By default,
 	it calls <code class="varname">TEST_MAKE</code> with the arguments
 	<code class="varname">MAKEARGS_TEST</code> and writes its output including
 @@ -10509,61 +10407,59 @@ check_result() {
 	output_require "Example"
 	output_require "^[[:alpha:]+[[:space:]][[:alpha:]]{6}$"
 	output_prohibit "no such file or directory"
+}
 </pre>
 </dd>
 <dt><span class="term"><code class="varname">do_cleanup</code></span></dt>
 <dd><p>This function cleans everything up after the
 	test has been run. By default it does nothing.</p></dd>
 </dl></div>
 </div>
 <div class="sect2">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="regression.fun.helper"></a>25.3.2.�Helper functions</h3></div></div></div>
+<a name="regression.fun.helper"></a>25.2.2.�Helper functions</h3></div></div></div>
 <div class="variablelist"><dl class="variablelist">
 <dt><span class="term"><code class="varname">exit_status expected</code></span></dt>
 <dd><p>This function compares the exitcode of the
 	<span class="command"><strong>do_test</strong></span> function with its first parameter.
 	If they differ, the test will fail.</p></dd>
 <dt><span class="term"><code class="varname">output_require regex...</code></span></dt>
 <dd>
 <p>This function checks for each of its parameters
 	if the output from <span class="command"><strong>do_test</strong></span> matches the
 	extended regular expression. If it does not, the test will
 	fail. Example:</p>
 <pre class="programlisting">
-output_require
+output_require "looks fine"
 output_require "^[[:alpha:]+[[:space:]][[:alpha:]]{6}$"
 </pre>
 </dd>
 <dt><span class="term"><code class="varname">output_prohibit(regex...)</code></span></dt>
 <dd><p>This function checks for each of its parameters
 	if the output from <span class="command"><strong>do_test()</strong></span> does
 	<span class="emphasis"><em>not</em></span> match the extended regular expression.
 	If any of the regular expressions matches, the test will
 	fail.</p></dd>
 </dl></div>
 </div>
 </div>
 </div>
 <div class="chapter">
 <div class="titlepage"><div><div><h2 class="title">
 <a name="porting"></a>Chapter�26.�Porting pkgsrc</h2></div></div></div>
 <div class="toc">
 <p><b>Table of Contents</b></p>
-<dl class="toc">
+<dl class="toc"><dt><span class="sect1"><a href="#porting.opsys">26.1. Porting pkgsrc to a new operating system</a></span></dt></dl>
 <dt><span class="sect1"><a href="#porting.opsys">26.1. Porting pkgsrc to a new operating system</a></span></dt>
 <dt><span class="sect1"><a href="#porting.compiler">26.2. Adding support for a new compiler</a></span></dt>
 </dl>
 </div>
 <p>The pkgsrc system has already been ported to many
 	operating systems, hardware architectures and compilers. This
 	chapter explains the necessary steps to make pkgsrc even more
 	portable.</p>
 <div class="sect1">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
 <a name="porting.opsys"></a>26.1.�Porting pkgsrc to a new operating system</h2></div></div></div>
 <p>To port pkgsrc to a new operating system (called
 	<code class="literal">MyOS</code> in this example), you need to touch the
 	following files:</p>
 <div class="variablelist"><dl class="variablelist">
 <dt><span class="term"><code class="filename">pkgtools/bootstrap-mk-files/files/mods/<em class="replaceable"><code>MyOS</code></em>.sys.mk</code></span></dt>
 @@ -10582,31 +10478,26 @@ output_require
 <dd><p>This file contains the platform-specific
 	definitions that are used by pkgsrc. Start by copying one of the
 	other files and edit it to your
 	needs.</p></dd>
 <dt><span class="term"><code class="filename">mk/tools/tools.<em class="replaceable"><code>MyOS</code></em>.mk</code></span></dt>
 <dd><p>This file defines the paths to all the tools
 	that are needed by one or the other package in pkgsrc, as well
 	as by pkgsrc itself. Find out where these tools are on your
 	platform and add them.</p></dd>
 </dl></div>
 <p>Now, you should be able to build some basic packages, like
 	<a href="ftp://ftp.NetBSD.org/pub/pkgsrc/current/pkgsrc/lang/perl5/README.html" target="_top"><code class="filename">lang/perl5</code></a>, <a href="ftp://ftp.NetBSD.org/pub/pkgsrc/current/pkgsrc/shells/bash/README.html" target="_top"><code class="filename">shells/bash</code></a>.</p>
 </div>
 <div class="sect1">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
 <a name="porting.compiler"></a>26.2.�Adding support for a new compiler</h2></div></div></div>
 <p>TODO</p>
 </div>
 </div>
 </div>
 <div class="appendix">
 <div class="titlepage"><div><div><h1 class="title">
 <a name="examples"></a>Appendix�A.�A simple example package: bison</h1></div></div></div>
 <div class="toc">
 <p><b>Table of Contents</b></p>
 <dl class="toc">
 <dt><span class="sect1"><a href="#example-files">A.1. files</a></span></dt>
 <dd><dl>
 <dt><span class="sect2"><a href="#example-Makefile">A.1.1. Makefile</a></span></dt>
 <dt><span class="sect2"><a href="#example-descr">A.1.2. DESCR</a></span></dt>
 <dt><span class="sect2"><a href="#example-plist">A.1.3. PLIST</a></span></dt>

 @@ -74,27 +74,26 @@ I. The pkgsrc user's guide
 . Using pkgsrc
 .1. Using binary packages
 .1.1. Finding binary packages
 .1.2. Installing binary packages
 .1.3. Deinstalling packages
 .1.4. Getting information about installed packages
 .1.5. Checking for security vulnerabilities in installed packages
 .1.6. Finding if newer versions of your installed packages are in
                 pkgsrc
 .1.7. Other administrative functions
 .1.8. A word of warning
 .2. Building packages from source
 .2.1. Requirements
 .2.2. Fetching distfiles
 .2.3. How to build and install
 . Configuring pkgsrc
 .1. General configuration
 .2. Variables affecting the build process
 .3. Variables affecting the installation process
 .4. Selecting and configuring the compiler
 @@ -186,30 +185,28 @@ II. The pkgsrc developer's guide
 .6. work*
 .7. files/*
 . Programming in Makefiles
 .1. Caveats
 .2. Makefile variables
 .2.1. Naming conventions
 .3. Code snippets
 .3.1. Adding things to a list
-.3.2. Converting an internal list into an external list
+.3.2. Passing variables to a shell command
-.3.3. Passing variables to a shell command
+.3.3. Quoting guideline
 .3.4. Quoting guideline
 .3.5. Workaround for a bug in BSD Make
 . PLIST issues
 .1. RCS ID
 .2. Semi-automatic PLIST generation
 .3. Tweaking output of make print-PLIST
 .4. Variable substitution in PLIST
 .5. Man page compression
 .6. Changing PLIST source with PLIST_SRC
 .7. Platform-specific and differing PLISTs
 .8. Build-specific PLISTs
 .9. Sharing directories between packages
 @@ -396,37 +393,35 @@ III. The pkgsrc infrastructure internals
 .4. How can variables be specified?
 .5. Designing interfaces for Makefile fragments
 .5.1. Procedures with parameters
 .5.2. Actions taken on behalf of parameters
 .6. The order in which files are loaded
 .6.1. The order in bsd.prefs.mk
 .6.2. The order in bsd.pkg.mk
 . Regression tests
-.1. The regression tests framework
+.1. Running the regression tests
-.2. Running the regression tests
+.2. Adding a new regression test
 .3. Adding a new regression test
-.3.1. Overridable functions
+.2.1. Overridable functions
-.3.2. Helper functions
+.2.2. Helper functions
 . Porting pkgsrc
 .1. Porting pkgsrc to a new operating system
 .2. Adding support for a new compiler
 A. A simple example package: bison
     A.1. files
         A.1.1. Makefile
         A.1.2. DESCR
         A.1.3. PLIST
         A.1.4. Checking a package with pkglint
     A.2. Steps for building, installing, packaging
 B. Build logs
 @@ -478,27 +473,27 @@ is exactly what The NetBSD Packages Coll
 some basic commands to handle binary packages, so that not every user has to
 build the packages for himself, which is a time-costly task.
 pkgsrc currently contains several thousand packages, including:
   * www/apache24 - The Apache web server
   * www/firefox - The Firefox web browser
   * meta-pkgs/gnome - The GNOME Desktop Environment
   * meta-pkgs/kde4 - The K Desktop Environment
-...just to name a few.
+? just to name a few.
 pkgsrc has built-in support for handling varying dependencies, such as pthreads
 and X11, and extended features such as IPv6 support on a range of platforms.
 .1.1. Why pkgsrc?
 pkgsrc provides the following key features:
   * Easy building of software from source as well as the creation and
     installation of binary packages. The source and latest patches are
     retrieved from a master or mirror download site, checksum verified, then
     built on your system. Support for binary-only distributions is available
     for both native platforms and NetBSD emulated platforms.
 @@ -725,27 +720,26 @@ Table of Contents
 . Using pkgsrc
 .1. Using binary packages
 .1.1. Finding binary packages
 .1.2. Installing binary packages
 .1.3. Deinstalling packages
 .1.4. Getting information about installed packages
 .1.5. Checking for security vulnerabilities in installed packages
 .1.6. Finding if newer versions of your installed packages are in
             pkgsrc
 .1.7. Other administrative functions
 .1.8. A word of warning
 .2. Building packages from source
 .2.1. Requirements
 .2.2. Fetching distfiles
 .2.3. How to build and install
 . Configuring pkgsrc
 .1. General configuration
 .2. Variables affecting the build process
 .3. Variables affecting the installation process
 .4. Selecting and configuring the compiler
 @@ -1026,28 +1020,26 @@ You can change default layout using comm
 Note
 The bootstrap installs a bmake tool. Use this bmake when building via pkgsrc.
 For examples in this guide, use bmake instead of "make".
 Note
 It is possible to bootstrap multiple instances of pkgsrc using non-intersecting
 directories. Use bmake corresponding to the installation you're working with to
 build and install packages.
 .3. Platform-specific notes
 Here are some platform-specific notes you should be aware of.
 .3.1. Cygwin
 Cygwin 1.7.x and later are supported.
 You need to install minimal base packages in `Base' category plus any of
 compiler, gcc, gcc4, and/or clang. For gcc and gcc4, C and C++ compiler will be
 installed by default, but you can install Fortran compiler additionally because
 it will be required to use libtool. If it is not installed (or too old),
 Fortran compiler will be installed with pkgsrc automatically.
 As noted in Cygwin FAQ: `Why doesn't su work?', su(1) command has been in
 Cygwin distribution, but it has never worked. Unless you bootstrap pkgsrc with
 the --unprivileged option, workaround is:
 @@ -1494,27 +1486,26 @@ Then, rebuild the devel/libtool-base pac
 Chapter 4. Using pkgsrc
 Table of Contents
 .1. Using binary packages
 .1.1. Finding binary packages
 .1.2. Installing binary packages
 .1.3. Deinstalling packages
 .1.4. Getting information about installed packages
 .1.5. Checking for security vulnerabilities in installed packages
 .1.6. Finding if newer versions of your installed packages are in pkgsrc
 .1.7. Other administrative functions
 .1.8. A word of warning
 .2. Building packages from source
 .2.1. Requirements
 .2.2. Fetching distfiles
 .2.3. How to build and install
 Basically, there are two ways of using pkgsrc. The first is to only install the
 package tools and to use binary packages that someone else has prepared. This
 is the "pkg" in pkgsrc. The second way is to install the "src" of pkgsrc, too.
 Then you are able to build your own packages, and you can still use binary
 packages from someone else.
 @@ -1655,38 +1646,26 @@ if your packages are up-to-date, e.g.
 % lintpkgsrc -i
 ...
 Version mismatch: 'tcsh' 6.09.00 vs 6.10.00
 You can then use make update to update the package on your system and rebuild
 any dependencies.
 .1.7. Other administrative functions
 The pkg_admin executes various administrative functions on the package system.
 .1.8. A word of warning
 Please pay very careful attention to the warnings expressed in the pkg_add(1)
 manual page about the inherent dangers of installing binary packages which you
 did not create yourself, and the security holes that can be introduced onto
 your system by indiscriminate adding of such files.
 The same warning of course applies to every package you install from source
 when you haven't completely read and understood the source code of the package,
 the compiler that is used to build the package and all the other tools that are
 involved.
 .2. Building packages from source
 After obtaining pkgsrc, the pkgsrc directory now contains a set of packages,
 organized into categories. You can browse the online index of packages, or run
 make readme from the pkgsrc directory to build local README.html files for all
 packages, viewable with any web browser such as www/lynx or www/firefox.
 The default prefix for installed packages is /usr/pkg. If you wish to change
 this, you should do so by setting LOCALBASE in mk.conf. You should not try to
 use multiple different LOCALBASE definitions on the same system (inside a
 chroot is an exception).
 The rest of this chapter assumes that the package is already in pkgsrc. If it
 @@ -1909,28 +1888,26 @@ each variable's intent.
     {DIST_SUBDIR}/.
   * BINPKG_SITES: List of sites carrying binary pkgs. rel and arch are replaced
     with OS release ("2.0", etc.) and architecture ("mipsel", etc.).
   * ACCEPTABLE_LICENSES: List of acceptable licenses. License names are
     case-sensitive. Whenever you try to build a package whose license is not in
     this list, you will get an error message. If the license condition is
     simple enough, the error message will include specific instructions on how
     to change this variable.
 .2. Variables affecting the build process
 XXX
   * PACKAGES: The top level directory for the binary packages. The default is $
     {PKGSRCDIR}/packages.
   * WRKOBJDIR: The top level directory where, if defined, the separate working
     directories will get created, and symbolically linked to from ${WRKDIR}
     (see below). This is useful for building packages on several architectures,
     then ${PKGSRCDIR} can be NFS-mounted while ${WRKOBJDIR} is local to every
     architecture. (It should be noted that PKGSRCDIR should not be set by the
     user ? it is an internal definition which refers to the root of the pkgsrc
     tree. It is possible to have many pkgsrc tree instances.)
   * LOCALPATCHES: Directory for local patches that aren't part of pkgsrc. See
     Section 11.3, "patches/*" for more information.
 @@ -2591,41 +2568,34 @@ Utilities for people maintaining or crea
   * pkgtools/pkgdiff: Automate making and maintaining patches for a package
     (includes pkgdiff, pkgvi, mkpatches, etc.).
   * pkgtools/url2pkg: Aids in converting to pkgsrc.
 Utilities for people maintaining pkgsrc (or: more obscure pkg utilities)
   * pkgtools/pkg_comp: Build packages in a chrooted area.
   * pkgtools/libkver: Spoof kernel version for chrooted cross builds.
 .3. How to use pkgsrc as non-root
-If you want to use pkgsrc as non-root user, you can set some variables to make
+To install packages from source as a non-root user, download pkgsrc as
-pkgsrc work under these conditions. At the very least, you need to set
+described in Chapter 2, Where to get pkgsrc and how to keep it up-to-date, cd
-UNPRIVILEGED to "yes"; this will turn on unprivileged mode and set multiple
+into that directory and run the command ./bootstrap/bootstrap --unprivileged.
 related variables to allow installation of packages as non-root.
 This will install the binary part of pkgsrc to ~/pkg and put the pkgsrc
-In case the defaults are not enough, you may want to tune some other variables
+configuration mk.conf into ~/pkg/etc.
 used. For example, if the automatic user/group detection leads to incorrect
-values (or not the ones you would like to use), you can change them by setting
+For more details, see mk/unprivileged.mk.
 UNPRIVILEGED_USER and UNPRIVILEGED_GROUP respectively.
 As regards bootstrapping, please note that the bootstrap script will ease
 non-root configuration when given the "--ignore-user-check" flag, as it will
 choose and use multiple default directories under ~/pkg as the installation
 targets. These directories can be overridden by the "--prefix" flag provided by
 the script, as well as some others that allow finer tuning of the tree layout.
 .4. How to resume transfers when fetching distfiles?
 By default, resuming transfers in pkgsrc is disabled, but you can enable this
 feature by adding the option PKG_RESUME_TRANSFERS=YES into mk.conf. If, during
 a fetch step, an incomplete distfile is found, pkgsrc will try to resume it.
 You can also use a different program than the platform default program by
 changing the FETCH_USING variable. You can specify the program by using of ftp,
 fetch, wget or curl. Alternatively, fetching can be disabled by using the value
 manual. A value of custom disables the system defaults and dependency tracking
 for the fetch program. In that case you have to provide FETCH_CMD,
 FETCH_BEFORE_ARGS, FETCH_RESUME_ARGS, FETCH_OUTPUT_ARGS, FETCH_AFTER_ARGS.
 @@ -2893,30 +2863,28 @@ Table of Contents
 .6. work*
 .7. files/*
 . Programming in Makefiles
 .1. Caveats
 .2. Makefile variables
 .2.1. Naming conventions
 .3. Code snippets
 .3.1. Adding things to a list
-.3.2. Converting an internal list into an external list
+.3.2. Passing variables to a shell command
-.3.3. Passing variables to a shell command
+.3.3. Quoting guideline
 .3.4. Quoting guideline
 .3.5. Workaround for a bug in BSD Make
 . PLIST issues
 .1. RCS ID
 .2. Semi-automatic PLIST generation
 .3. Tweaking output of make print-PLIST
 .4. Variable substitution in PLIST
 .5. Man page compression
 .6. Changing PLIST source with PLIST_SRC
 .7. Platform-specific and differing PLISTs
 .8. Build-specific PLISTs
 .9. Sharing directories between packages
 @@ -3560,72 +3528,72 @@ Please pay attention to the following go
     package. For packages using BSD-style makefiles which honor MANZ, there is
     MANCOMPRESSED_IF_MANZ.
   * Replace /usr/local with "${PREFIX}" in all files (see patches, below).
   * If the package installs any info files, see Section 19.6.7, "Packages
     installing info files".
 .2. distinfo
 The distinfo file contains the message digest, or checksum, of each distfile
 needed for the package. This ensures that the distfiles retrieved from the
 Internet have not been corrupted during transfer or altered by a malign force
-to introduce a security hole. Due to recent rumor about weaknesses of digest
+to introduce a security hole. To provide maximum security, all distfiles are
-algorithms, all distfiles are protected using both SHA1 and RMD160 message
+protected using three different message digest algorithms (SHA1, RMD160,
-digests, as well as the file size.
+SHA512), as well as the file size.
 The distinfo file also contains the checksums for all the patches found in the
 patches directory (see Section 11.3, "patches/*").
-To regenerate the distinfo file, use the make makedistinfo or make mdi command.
+To regenerate the distinfo file, use the make distinfo command.
 Some packages have different sets of distfiles depending on the platform, for
 example lang/openjdk7. These are kept in the same distinfo file and care should
 be taken when upgrading such a package to ensure distfile information is not
 lost.
 .3. patches/*
-Many packages still don't work out-of-the box on the various platforms that are
+Some packages don't work out-of-the box on the various platforms that are
-supported by pkgsrc. Therefore, a number of custom patch files are needed to
+supported by pkgsrc. These packages need to be patched to make them work. The
-make the package work. These patch files are found in the patches/ directory.
+patch files can be found in the patches/ directory.
 In the patch phase, these patches are applied to the files in WRKSRC directory
 after extracting them, in alphabetic order.
 .3.1. Structure of a single patch file
 The patch-* files should be in diff -bu format, and apply without a fuzz to
 avoid problems. (To force patches to apply with fuzz you can set
 PATCH_FUZZ_FACTOR=-F2). Furthermore, each patch should contain only changes for
 a single file, and no file should be patched by more than one patch file. This
 helps to keep future modifications simple.
 Each patch file is structured as follows: In the first line, there is the RCS
 Id of the patch itself. The second line should be empty for aesthetic reasons.
 After that, there should be a comment for each change that the patch does.
 There are a number of standard cases:
   * Patches for commonly known vulnerabilities should mention the vulnerability
     ID (CAN, CVE).
   * Patches that change source code should mention the platform and other
     environment (for example, the compiler) that the patch is needed for.
-In all, the patch should be commented so that any developer who knows the code
+The patch should be commented so that any developer who knows the code of the
-of the application can make some use of the patch. Special care should be taken
+application can make some use of the patch. Special care should be taken for
-for the upstream developers, since we generally want that they accept our
+the upstream developers, since we generally want that they accept our patches,
-patches, so we have less work in the future.
+so we have less work in the future.
 .3.2. Creating patch files
 One important thing to mention is to pay attention that no RCS IDs get stored
 in the patch files, as these will cause problems when later checked into the
 NetBSD CVS tree. Use the pkgdiff command from the pkgtools/pkgdiff package to
 avoid these problems.
 For even more automation, we recommend using mkpatches from the same package to
 make a whole set of patches. You just have to backup files before you edit them
 to filename.orig, e.g. with cp -p filename filename.orig or, easier, by using
 pkgvi again from the same package. If you upgrade a package this way, you can
 easily compare the new set of patches with the previously existing one with
 @@ -3880,30 +3848,28 @@ FILESDIR=${.CURDIR}/../xemacs/files
 Chapter 12. Programming in Makefiles
 Table of Contents
 .1. Caveats
 .2. Makefile variables
 .2.1. Naming conventions
 .3. Code snippets
 .3.1. Adding things to a list
-.3.2. Converting an internal list into an external list
+.3.2. Passing variables to a shell command
-.3.3. Passing variables to a shell command
+.3.3. Quoting guideline
 .3.4. Quoting guideline
 .3.5. Workaround for a bug in BSD Make
 Pkgsrc consists of many Makefile fragments, each of which forms a well-defined
 part of the pkgsrc system. Using the make(1) system as a programming language
 for a big system like pkgsrc requires some discipline to keep the code correct
 and understandable.
 The basic ingredients for Makefile programming are variables (which are
 actually macros) and shell commands. Among these shell commands may even be
 more complex ones like awk(1) programs. To make sure that every shell command
 runs as intended it is necessary to quote all variables correctly when they are
 used.
 This chapter describes some patterns, that appear quite often in Makefiles,
 @@ -3943,43 +3909,34 @@ Makefile variables contain strings that
 operators ``='', ``+='', ``?='', ``:='', and ``!='', which are described in the
 make(1) man page.
 When a variable's value is parsed from a Makefile, the hash character ``#'' and
 the backslash character ``\'' are handled specially. If a backslash is followed
 by a newline, any whitespace immediately in front of the backslash, the
 backslash, the newline, and any whitespace immediately behind the newline are
 replaced with a single space. A backslash character and an immediately
 following hash character are replaced with a single hash character. Otherwise,
 the backslash is passed as is. In a variable assignment, any hash character
 that is not preceded by a backslash starts a comment that continues upto the
 end of the logical line.
-Note: Because of this parsing algorithm the only way to create a variable
+The evaluation of variables either happens immediately or lazy. It happens
-consisting of a single backslash is using the ``!='' operator, for example:
+immediately when the variable occurs on the right-hand side of the ``:='' or
-BACKSLASH!=echo "\\".
+the ``!='' operator, in a .if condition or a .for loop. In the other cases, it
 is evaluated lazily.
 So far for defining variables. The other thing you can do with variables is
 evaluating them. A variable is evaluated when it is part of the right side of
 the ``:='' or the ``!='' operator, or directly before executing a shell command
 which the variable is part of. In all other cases, make(1) performs lazy
 evaluation, that is, variables are not evaluated until there's no other way.
 The ``modifiers'' mentioned in the man page also evaluate the variable.
 Some of the modifiers split the string into words and then operate on the
 words, others operate on the string as a whole. When a string is split into
-words, it is split as you would expect it from sh(1).
+words, it is split like in sh(1).
 No rule without exception?the .for loop does not follow the shell quoting rules
 but splits at sequences of whitespace.
 There are several types of variables that should be handled differently.
 Strings and two types of lists.
   * Strings can contain arbitrary characters. Nevertheless, you should restrict
     yourself to only using printable characters. Examples are PREFIX and
     COMMENT.
   * Internal lists are lists that are never exported to any shell command.
     Their elements are separated by whitespace. Therefore, the elements
     themselves cannot have embedded whitespace. Any other characters are
     allowed. Internal lists can be used in .for loops. Examples are DEPENDS and
     BUILD_DEPENDS.
 @@ -4013,80 +3970,52 @@ ANOTHER_INT_LIST=       apache-[0-9]*:..
 EXT_LIST=               # empty
 ANOTHER_EXT_LIST=       a=b c=d
 INT_LIST+=              ${STRING}               # 1
 INT_LIST+=              ${ANOTHER_INT_LIST}     # 2
 EXT_LIST+=              ${STRING:Q}             # 3
 EXT_LIST+=              ${ANOTHER_EXT_LIST}     # 4
 When you add a string to an external list (example 3), it must be quoted. In
 all other cases, you must not add a quoting level. You must not merge internal
 and external lists, unless you are sure that all entries are correctly
 interpreted in both lists.
-.3.2. Converting an internal list into an external list
+.3.2. Passing variables to a shell command
 EXT_LIST=       # empty
 .for i in ${INT_LIST}
 EXT_LIST+=      ${i:Q}""
 .endfor
 This code converts the internal list INT_LIST into the external list EXT_LIST.
 As the elements of an internal list are unquoted they must be quoted here. The
 reason for appending "" is explained below.
 .3.3. Passing variables to a shell command
 Sometimes you may want to print an arbitrary string. There are many ways to get
 it wrong and only few that can handle every nastiness.
 STRING=         foo bar <    > * `date` $$HOME ' "
-EXT_LIST=       string=${STRING:Q} x=second\ item
+EXAMPLE_ENV=    string=${STRING:Q} x=multiple\ quoted\ words
 all:
         echo ${STRING}                  # 1
-        echo "${STRING}"                # 2
+        echo ${STRING:Q}                # 2
-        echo "${STRING:Q}"              # 3
+        printf '%s\n' ${STRING:Q}''     # 3
-        echo ${STRING:Q}                # 4
+        env ${EXAMPLE_ENV} sh -c 'echo "$$string"; echo "$$x"' # 4
         echo x${STRING:Q} | sed 1s,.,,  # 5
         printf "%s\\n" ${STRING:Q}""    # 6
         env ${EXT_LIST} /bin/sh -c 'echo "$$string"; echo "$$x"'
 Example 1 leads to a syntax error in the shell, as the characters are just
 copied.
-Example 2 leads to a syntax error too, and if you leave out the last "
+Example 2 can handle all strings, except those starting with a dash or those
-character from ${STRING}, date(1) will be executed. The $HOME shell variable
+containing backslashes.
 would be evaluated, too.
 Example 3 outputs each space character preceded by a backslash (or not),
 depending on the implementation of the echo(1) command.
-Example 4 handles correctly every string that does not start with a dash. In
+Example 3 can handle arbitrary strings.
 that case, the result depends on the implementation of the echo(1) command. As
 long as you can guarantee that your input does not start with a dash, this form
 is appropriate.
-Example 5 handles even the case of a leading dash correctly.
+In example 4, the EXT_LIST does not need to be quoted because the quoting has
 already been done when adding elements to the list.
-Example 6 also works with every string and is the light-weight solution, since
+.3.3. Quoting guideline
 it does not involve a pipe, which has its own problems.
 The EXT_LIST does not need to be quoted because the quoting has already been
 done when adding elements to the list.
 As internal lists shall not be passed to the shell, there is no example for it.
 .3.4. Quoting guideline
 There are many possible sources of wrongly quoted variables. This section lists
 some of the commonly known ones.
   * Whenever you use the value of a list, think about what happens to leading
     or trailing whitespace. If the list is a well-formed shell expression, you
     can apply the :M* modifier to strip leading and trailing whitespace from
     each word. The :M operator first splits its argument according to the rules
     of the shell, and then creates a new list consisting of all words that
     match the shell glob expression *, that is: all. One class of situations
     where this is needed is when adding a variable like CPPFLAGS to
     CONFIGURE_ARGS. If the configure script invokes other configure scripts, it
     strips the leading and trailing whitespace from the variable and then
 @@ -4131,37 +4060,26 @@ some of the commonly known ones.
     The first example will only print two of the three lines we might have
     expected. This is because ${EMPTY:Q} expands to the empty string, which the
     shell cannot see. The workaround is to write ${EMPTY:Q}"". This pattern can
     be often found as ${TEST} -z ${VAR:Q} or as ${TEST} -f ${FNAME:Q} (both of
     these are wrong).
     The second example will only print three lines instead of four. The first
     line looks like a:\ echo foo. This is because the backslash of the value a:
     \ is interpreted as a line-continuation by make(1), which makes the second
     line the arguments of the echo(1) command from the first line. To avoid
     this, write ${i:Q}"".
 .3.5. Workaround for a bug in BSD Make
 The pkgsrc bmake program does not handle the following assignment correctly. In
 case _othervar_ contains a ``-'' character, one of the closing braces is
 included in ${VAR} after this code executes.
 VAR:=   ${VAR:N${_othervar_:C/-//}}
 For a more complex code snippet and a workaround, see the package regress/
 make-quoting, testcase bug1.
 Chapter 13. PLIST issues
 Table of Contents
 .1. RCS ID
 .2. Semi-automatic PLIST generation
 .3. Tweaking output of make print-PLIST
 .4. Variable substitution in PLIST
 .5. Man page compression
 .6. Changing PLIST source with PLIST_SRC
 .7. Platform-specific and differing PLISTs
 .8. Build-specific PLISTs
 .9. Sharing directories between packages
 @@ -6317,28 +6235,31 @@ interaction. This should be done in the
 INTERACTIVE_STAGE=      configure install
 The user can then decide to skip this package by setting the BATCH variable.
 Packages that require interaction are also excluded from bulk builds.
 .1.3. Handling licenses
 Authors of software can choose the licence under which software can be copied.
 This is due to copyright law, and reasons for license choices are outside the
 scope of pkgsrc. The pkgsrc system recognizes that there are a number of
 licenses which some users may find objectionable or difficult or impossible to
 comply with. The Free Software Foundation has declared some licenses "Free",
-and the Open Source Initiative has a definition of "Open Source". Note that a
+and the Open Source Initiative has a definition of "Open Source". The pkgsrc
-package whose license forbids to copy does not meet either the Free or Open
+system, as a policy choice, does not label packages which have licenses that
 are Free or Open Source. However, packages without a license meeting either of
 those tests are labeled with a license tag denoting the license. Note that a
 package with no license to copy trivially does not meet either the Free or Open
 Source test.
 For packages which are not Free or Open Source, pkgsrc will not build the
 package unless the user has indicated to pkgsrc that packages with that
 particular license may be built. Note that this documentation avoids the term
 "accepted the license". The pkgsrc system is merely providing a mechanism to
 avoid accidentally building a package with a non-free license; judgement and
 responsibility remain with the user. (Installation of binary packages are not
 currently subject to this mechanism; this is a bug.)
 One might want to only install packages with a BSD license, or the GPL, and not
 the other. The free licenses are added to the default ACCEPTABLE_LICENSES
 variable. The user can override the default by setting the ACCEPTABLE_LICENSES
 @@ -8338,37 +8259,35 @@ Table of Contents
 .4. How can variables be specified?
 .5. Designing interfaces for Makefile fragments
 .5.1. Procedures with parameters
 .5.2. Actions taken on behalf of parameters
 .6. The order in which files are loaded
 .6.1. The order in bsd.prefs.mk
 .6.2. The order in bsd.pkg.mk
 . Regression tests
-.1. The regression tests framework
+.1. Running the regression tests
-.2. Running the regression tests
+.2. Adding a new regression test
 .3. Adding a new regression test
-.3.1. Overridable functions
+.2.1. Overridable functions
-.3.2. Helper functions
+.2.2. Helper functions
 . Porting pkgsrc
 .1. Porting pkgsrc to a new operating system
 .2. Adding support for a new compiler
 Chapter 24. Design of the pkgsrc infrastructure
 Table of Contents
 .1. The meaning of variable definitions
 .2. Avoiding problems before they arise
 .3. Variable evaluation
 .3.1. At load time
 .3.2. At runtime
 .4. How can variables be specified?
 @@ -8577,56 +8496,53 @@ The code to check PKG_FAIL_REASON and PK
 restricts the use of these variables to all the files that have been included
 before. Appearances in later files will be silently ignored.
 Then, the files for the main targets are included, in the order of later
 execution, though the actual order should not matter.
 At last, some more files are included that don't set any interesting variables
 but rather just define make targets to be executed.
 Chapter 25. Regression tests
 Table of Contents
-.1. The regression tests framework
+.1. Running the regression tests
-.2. Running the regression tests
+.2. Adding a new regression test
 .3. Adding a new regression test
-.3.1. Overridable functions
+.2.1. Overridable functions
-.3.2. Helper functions
+.2.2. Helper functions
 The pkgsrc infrastructure consists of a large codebase, and there are many
 corners where every little bit of a file is well thought out, making pkgsrc
 likely to fail as soon as anything is changed near those parts. To prevent most
 changes from breaking anything, a suite of regression tests should go along
 with every important part of the pkgsrc infrastructure. This chapter describes
 how regression tests work in pkgsrc and how you can add new tests.
-.1. The regression tests framework
+.1. Running the regression tests
 .2. Running the regression tests
 You first need to install the pkgtools/pkg_regress package, which provides the
 pkg_regress command. Then you can simply run that command, which will run all
 tests in the regress category.
-.3. Adding a new regression test
+.2. Adding a new regression test
 Every directory in the regress category that contains a file called spec is
 considered a regression test. This file is a shell program that is included by
 the pkg_regress command. The following functions can be overridden to suit your
 needs.
-.3.1. Overridable functions
+.2.1. Overridable functions
 These functions do not take any parameters. Although they are called in "set -e
 " mode, they don't stop at the first failing command. See this StackOverflow
 question for details.
 do_setup
     This function prepares the environment for the test. By default it does
     nothing.
 do_test
     This function runs the actual test. By default, it calls TEST_MAKE with the
 @@ -8648,53 +8564,53 @@ check_result
     check_result() {
             exit_status 0
             output_require "Example"
             output_require "^[[:alpha:]+[[:space:]][[:alpha:]]{6}$"
             output_prohibit "no such file or directory"
+    }
 do_cleanup
     This function cleans everything up after the test has been run. By default
     it does nothing.
-.3.2. Helper functions
+.2.2. Helper functions
 exit_status expected
     This function compares the exitcode of the do_test function with its first
     parameter. If they differ, the test will fail.
 output_require regex...
     This function checks for each of its parameters if the output from do_test
     matches the extended regular expression. If it does not, the test will
     fail. Example:
-    output_require
+    output_require "looks fine"
     output_require "^[[:alpha:]+[[:space:]][[:alpha:]]{6}$"
 output_prohibit(regex...)
     This function checks for each of its parameters if the output from do_test
     () does not match the extended regular expression. If any of the regular
     expressions matches, the test will fail.
 Chapter 26. Porting pkgsrc
 Table of Contents
 .1. Porting pkgsrc to a new operating system
 .2. Adding support for a new compiler
 The pkgsrc system has already been ported to many operating systems, hardware
 architectures and compilers. This chapter explains the necessary steps to make
 pkgsrc even more portable.
 .1. Porting pkgsrc to a new operating system
 To port pkgsrc to a new operating system (called MyOS in this example), you
 need to touch the following files:
 pkgtools/bootstrap-mk-files/files/mods/MyOS.sys.mk
     This file contains some basic definitions, for example the name of the C
 @@ -8710,30 +8626,26 @@ mk/platform/MyOS.mk
     This file contains the platform-specific definitions that are used by
     pkgsrc. Start by copying one of the other files and edit it to your needs.
 mk/tools/tools.MyOS.mk
     This file defines the paths to all the tools that are needed by one or the
     other package in pkgsrc, as well as by pkgsrc itself. Find out where these
     tools are on your platform and add them.
 Now, you should be able to build some basic packages, like lang/perl5, shells/
 bash.
 .2. Adding support for a new compiler
 TODO
 Appendix A. A simple example package: bison
 Table of Contents
 A.1. files
     A.1.1. Makefile
     A.1.2. DESCR
     A.1.3. PLIST
     A.1.4. Checking a package with pkglint
 A.2. Steps for building, installing, packaging