 @@ -118,33 +118,34 @@
 <dt><span class="sect1"><a href="#settings-for-creationg-of-binary-packages">7.2. Settings for creation of binary packages</a></span></dt>
 </dl></dd>
 <dt><span class="chapter"><a href="#bulk">8. Creating binary packages for everything in pkgsrc (bulk
 builds)</a></span></dt>
 <dd><dl>
 <dt><span class="sect1"><a href="#bulk.pre">8.1. Preparations</a></span></dt>
 <dt><span class="sect1"><a href="#bulk.pbulk">8.2. Running a bulk build</a></span></dt>
 <dd><dl><dt><span class="sect2"><a href="#bulk.pbulk.conf">8.2.1. Configuration</a></span></dt></dl></dd>
 <dt><span class="sect1"><a href="#bulk.req">8.3. Requirements of a full bulk build</a></span></dt>
 <dt><span class="sect1"><a href="#bulk.var">8.4. Bulk build variants</a></span></dt>
 <dd><dl>
 <dt><span class="sect2"><a href="#bulk.var.confopt">8.4.1. Detect unknown configure options</a></span></dt>
 <dt><span class="sect2"><a href="#bulk.var.comperr">8.4.2. Detect classes of bugs by forcing compiler warnings</a></span></dt>
-<dt><span class="sect2"><a href="#bulk.var.dirs">8.4.3. Use custom directories</a></span></dt>
+<dt><span class="sect2"><a href="#bulk.var.builderr">8.4.3. Force compiler options only in the build phase</a></span></dt>
-<dt><span class="sect2"><a href="#bulk.var.warn">8.4.4. Turn warnings into errors</a></span></dt>
+<dt><span class="sect2"><a href="#bulk.var.dirs">8.4.4. Use custom directories</a></span></dt>
-<dt><span class="sect2"><a href="#bulk.var.pkglint">8.4.5. Reject packages for which pkglint reports errors</a></span></dt>
+<dt><span class="sect2"><a href="#bulk.var.warn">8.4.5. Turn warnings into errors</a></span></dt>
-<dt><span class="sect2"><a href="#bulk.var.strings">8.4.6. Reject packages that contain forbidden strings</a></span></dt>
+<dt><span class="sect2"><a href="#bulk.var.pkglint">8.4.6. Reject packages for which pkglint reports errors</a></span></dt>
-<dt><span class="sect2"><a href="#bulk.var.test">8.4.7. Reject packages whose self-test fails</a></span></dt>
+<dt><span class="sect2"><a href="#bulk.var.strings">8.4.7. Reject packages that contain forbidden strings</a></span></dt>
-<dt><span class="sect2"><a href="#bulk.var.shvar">8.4.8. Reject packages that use undefined shell variables</a></span></dt>
+<dt><span class="sect2"><a href="#bulk.var.test">8.4.8. Reject packages whose self-test fails</a></span></dt>
-<dt><span class="sect2"><a href="#bulk.var.quiet">8.4.9. Turn off verbose logging</a></span></dt>
+<dt><span class="sect2"><a href="#bulk.var.shvar">8.4.9. Reject packages that use undefined shell variables</a></span></dt>
 <dt><span class="sect2"><a href="#bulk.var.quiet">8.4.10. Turn off verbose logging</a></span></dt>
 </dl></dd>
 <dt><span class="sect1"><a href="#creating-cdroms">8.5. Creating a multiple CD-ROM packages collection</a></span></dt>
 <dd><dl><dt><span class="sect2"><a href="#cdpack-example">8.5.1. Example of cdpack</a></span></dt></dl></dd>
 </dl></dd>
 <dt><span class="chapter"><a href="#files">9. Directory layout of the installed files</a></span></dt>
 <dd><dl>
 <dt><span class="sect1"><a href="#files.localbase">9.1. File system layout in <code class="literal">${LOCALBASE}</code></a></span></dt>
 <dt><span class="sect1"><a href="#files.varbase">9.2. File system layout in <code class="literal">${VARBASE}</code></a></span></dt>
 </dl></dd>
 <dt><span class="chapter"><a href="#faq">10. Frequently Asked Questions</a></span></dt>
 <dd><dl>
 <dt><span class="sect1"><a href="#mailing-list-pointers">10.1. Are there any mailing lists for pkg-related discussion?</a></span></dt>
 <dt><span class="sect1"><a href="#faq-pkgtools">10.2. Utilities for package management (pkgtools)</a></span></dt>
 @@ -875,33 +876,34 @@ minutes!
 <dt><span class="sect1"><a href="#settings-for-creationg-of-binary-packages">7.2. Settings for creation of binary packages</a></span></dt>
 </dl></dd>
 <dt><span class="chapter"><a href="#bulk">8. Creating binary packages for everything in pkgsrc (bulk
 builds)</a></span></dt>
 <dd><dl>
 <dt><span class="sect1"><a href="#bulk.pre">8.1. Preparations</a></span></dt>
 <dt><span class="sect1"><a href="#bulk.pbulk">8.2. Running a bulk build</a></span></dt>
 <dd><dl><dt><span class="sect2"><a href="#bulk.pbulk.conf">8.2.1. Configuration</a></span></dt></dl></dd>
 <dt><span class="sect1"><a href="#bulk.req">8.3. Requirements of a full bulk build</a></span></dt>
 <dt><span class="sect1"><a href="#bulk.var">8.4. Bulk build variants</a></span></dt>
 <dd><dl>
 <dt><span class="sect2"><a href="#bulk.var.confopt">8.4.1. Detect unknown configure options</a></span></dt>
 <dt><span class="sect2"><a href="#bulk.var.comperr">8.4.2. Detect classes of bugs by forcing compiler warnings</a></span></dt>
-<dt><span class="sect2"><a href="#bulk.var.dirs">8.4.3. Use custom directories</a></span></dt>
+<dt><span class="sect2"><a href="#bulk.var.builderr">8.4.3. Force compiler options only in the build phase</a></span></dt>
-<dt><span class="sect2"><a href="#bulk.var.warn">8.4.4. Turn warnings into errors</a></span></dt>
+<dt><span class="sect2"><a href="#bulk.var.dirs">8.4.4. Use custom directories</a></span></dt>
-<dt><span class="sect2"><a href="#bulk.var.pkglint">8.4.5. Reject packages for which pkglint reports errors</a></span></dt>
+<dt><span class="sect2"><a href="#bulk.var.warn">8.4.5. Turn warnings into errors</a></span></dt>
-<dt><span class="sect2"><a href="#bulk.var.strings">8.4.6. Reject packages that contain forbidden strings</a></span></dt>
+<dt><span class="sect2"><a href="#bulk.var.pkglint">8.4.6. Reject packages for which pkglint reports errors</a></span></dt>
-<dt><span class="sect2"><a href="#bulk.var.test">8.4.7. Reject packages whose self-test fails</a></span></dt>
+<dt><span class="sect2"><a href="#bulk.var.strings">8.4.7. Reject packages that contain forbidden strings</a></span></dt>
-<dt><span class="sect2"><a href="#bulk.var.shvar">8.4.8. Reject packages that use undefined shell variables</a></span></dt>
+<dt><span class="sect2"><a href="#bulk.var.test">8.4.8. Reject packages whose self-test fails</a></span></dt>
-<dt><span class="sect2"><a href="#bulk.var.quiet">8.4.9. Turn off verbose logging</a></span></dt>
+<dt><span class="sect2"><a href="#bulk.var.shvar">8.4.9. Reject packages that use undefined shell variables</a></span></dt>
 <dt><span class="sect2"><a href="#bulk.var.quiet">8.4.10. Turn off verbose logging</a></span></dt>
 </dl></dd>
 <dt><span class="sect1"><a href="#creating-cdroms">8.5. Creating a multiple CD-ROM packages collection</a></span></dt>
 <dd><dl><dt><span class="sect2"><a href="#cdpack-example">8.5.1. Example of cdpack</a></span></dt></dl></dd>
 </dl></dd>
 <dt><span class="chapter"><a href="#files">9. Directory layout of the installed files</a></span></dt>
 <dd><dl>
 <dt><span class="sect1"><a href="#files.localbase">9.1. File system layout in <code class="literal">${LOCALBASE}</code></a></span></dt>
 <dt><span class="sect1"><a href="#files.varbase">9.2. File system layout in <code class="literal">${VARBASE}</code></a></span></dt>
 </dl></dd>
 <dt><span class="chapter"><a href="#faq">10. Frequently Asked Questions</a></span></dt>
 <dd><dl>
 <dt><span class="sect1"><a href="#mailing-list-pointers">10.1. Are there any mailing lists for pkg-related discussion?</a></span></dt>
 <dt><span class="sect1"><a href="#faq-pkgtools">10.2. Utilities for package management (pkgtools)</a></span></dt>
 @@ -2083,33 +2085,34 @@ PKG_OPTIONS.apache=     suexec
 <a name="bulk"></a>Chapter�8.�Creating binary packages for everything in pkgsrc (bulk
 builds)</h2></div></div></div>
 <div class="toc">
 <p><b>Table of Contents</b></p>
 <dl class="toc">
 <dt><span class="sect1"><a href="#bulk.pre">8.1. Preparations</a></span></dt>
 <dt><span class="sect1"><a href="#bulk.pbulk">8.2. Running a bulk build</a></span></dt>
 <dd><dl><dt><span class="sect2"><a href="#bulk.pbulk.conf">8.2.1. Configuration</a></span></dt></dl></dd>
 <dt><span class="sect1"><a href="#bulk.req">8.3. Requirements of a full bulk build</a></span></dt>
 <dt><span class="sect1"><a href="#bulk.var">8.4. Bulk build variants</a></span></dt>
 <dd><dl>
 <dt><span class="sect2"><a href="#bulk.var.confopt">8.4.1. Detect unknown configure options</a></span></dt>
 <dt><span class="sect2"><a href="#bulk.var.comperr">8.4.2. Detect classes of bugs by forcing compiler warnings</a></span></dt>
-<dt><span class="sect2"><a href="#bulk.var.dirs">8.4.3. Use custom directories</a></span></dt>
+<dt><span class="sect2"><a href="#bulk.var.builderr">8.4.3. Force compiler options only in the build phase</a></span></dt>
-<dt><span class="sect2"><a href="#bulk.var.warn">8.4.4. Turn warnings into errors</a></span></dt>
+<dt><span class="sect2"><a href="#bulk.var.dirs">8.4.4. Use custom directories</a></span></dt>
-<dt><span class="sect2"><a href="#bulk.var.pkglint">8.4.5. Reject packages for which pkglint reports errors</a></span></dt>
+<dt><span class="sect2"><a href="#bulk.var.warn">8.4.5. Turn warnings into errors</a></span></dt>
-<dt><span class="sect2"><a href="#bulk.var.strings">8.4.6. Reject packages that contain forbidden strings</a></span></dt>
+<dt><span class="sect2"><a href="#bulk.var.pkglint">8.4.6. Reject packages for which pkglint reports errors</a></span></dt>
-<dt><span class="sect2"><a href="#bulk.var.test">8.4.7. Reject packages whose self-test fails</a></span></dt>
+<dt><span class="sect2"><a href="#bulk.var.strings">8.4.7. Reject packages that contain forbidden strings</a></span></dt>
-<dt><span class="sect2"><a href="#bulk.var.shvar">8.4.8. Reject packages that use undefined shell variables</a></span></dt>
+<dt><span class="sect2"><a href="#bulk.var.test">8.4.8. Reject packages whose self-test fails</a></span></dt>
-<dt><span class="sect2"><a href="#bulk.var.quiet">8.4.9. Turn off verbose logging</a></span></dt>
+<dt><span class="sect2"><a href="#bulk.var.shvar">8.4.9. Reject packages that use undefined shell variables</a></span></dt>
 <dt><span class="sect2"><a href="#bulk.var.quiet">8.4.10. Turn off verbose logging</a></span></dt>
 </dl></dd>
 <dt><span class="sect1"><a href="#creating-cdroms">8.5. Creating a multiple CD-ROM packages collection</a></span></dt>
 <dd><dl><dt><span class="sect2"><a href="#cdpack-example">8.5.1. Example of cdpack</a></span></dt></dl></dd>
 </dl>
 </div>
 <p>For a number of reasons, you may want to build binary packages
 for a large selected set of packages in pkgsrc, or even for all pkgsrc packages.
 For instance, when you have multiple machines that should run the same software,
 it is wasted time if they all build their packages themselves from source.
 Or you may want to build a list of packages you want and check them before
 deploying onto production systems.
 There is a way of getting a set of binary packages:
 the bulk build system, or pbulk ("p" stands for "parallel").
 @@ -2280,111 +2283,194 @@ BUILDLINK_TRANSFORM+=   rm:-Werror=char-
 .endif
 </pre>
 <p>If the error messages from the compiler are valid and the code
 needs to be fixed, prepare a local patch (see
 <code class="varname">LOCALPATCHES</code>) and report the bug to the upstream
 authors of the package, providing them with the information you collected
 above.</p>
 <p>Patches that are not essential for the package to work should only
 be reported upstream but not committed to pkgsrc, to make future updates
 easier.</p>
 </div>
 <div class="sect2">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="bulk.var.dirs"></a>8.4.3.�Use custom directories</h3></div></div></div>
+<a name="bulk.var.builderr"></a>8.4.3.�Force compiler options only in the build phase</h3></div></div></div>
 <p>When adding custom compiler flags via <code class="varname">CFLAGS</code>,
 these apply to all phases of the package build process. Especially in the
 configure phase, adding <code class="literal">-Werror</code> leads to wrong
 decisions. The GNU configure scripts feed many small test programs to the
 C compiler to see whether certain headers are available, functions are
 defined in a library and programs can be run. In many cases these
 programs would not survive a strict compiler run with <code class="literal">-Wall
 -Wextra -Werror</code>.</p>
 <p>The pkgsrc infrastructure is flexible enough to support compiler
 options being added between the <code class="literal">configure</code> and
 <code class="literal">build</code> phases. It's a little more complicated than the
 other examples in this section but still easy enough.</p>
 <p>The basic idea is to use the pkgsrc compiler wrapper to inject the
 desired compiler options. The compiler wrapper's original task is to hide
 unwanted directories of include files and to normalize compiler options.
 It does this by wrapping the compiler command and rewriting the command
 line. To see this in action, run <span class="command"><strong>bmake patch</strong></span> in a
 package directory and examine the
 <code class="filename">work/.cwrappers/config</code> directory. It contains
 individual configurations for the C compiler and the related tools. The
 plan is to find a hook between the configure and build phases, and to
 modify these configuration files at that point.</p>
 <p>To find this hook, have a look at
 <code class="filename">mk/build/build.mk</code>, which contains among others the
 <code class="literal">pre-build-checks-hook</code>. The word
 <code class="literal">checks</code> doesn't quite fit, but the
 <code class="literal">pre-build-hook</code> sounds good enough.</p>
 <p>The code to be included in <a class="link" href="#mk.conf"><code class="filename">mk.conf</code></a> is:</p>
 <pre class="programlisting">
 # Just a few example options.
 BUILD_ONLY_CFLAGS=      -Wall -Werror -O2 -DTEMPDIR='"/tmp"'
 .if ${BUILD_ONLY_CFLAGS:U:M*}
 pre-build-checks-hook: add-build-only-cflags
 add-build-only-cflags: .PHONY
         ${RUN} cd ${CWRAPPERS_CONFIG_DIR};      \
         ${TEST} ! -f ${.TARGET} || exit 0;      \
         for flag in ${BUILD_ONLY_CFLAGS}; do    \
                 ${ECHO} "append=$$flag" &gt;&gt; cc;  \
         done;                                   \
         &gt; ${.TARGET}
 .endif
 </pre>
 <p>(When editing the <a class="link" href="#mk.conf"><code class="filename">mk.conf</code></a>, make sure that the commands of the
 <code class="literal">add-build-only-cflags</code> target are indented with a tab,
 not with spaces.)</p>
 <p>The condition in the <code class="literal">.if</code> statement contains the
 <code class="literal">:U</code> modifier to prevent parse errors if the variable
 should be undefined, possibly because it is only defined for a subset of
 the packages. The <code class="literal">:M*</code> modifier ensures that there is
 at least one compiler option, to prevent a syntax error in the shell
 parser.</p>
 <p>The code around the <code class="literal">${.TARGET}</code> variable ensures
 that the additional compiler options are only appended once, even if
 <span class="command"><strong>bmake build</strong></span> is run multiple times. To do this, it
 creates a marker file.</p>
 <p>To verify that this setup works, run <span class="command"><strong>bmake
 configure</strong></span> in a package directory. Up to now, everything works
 as usual. Examine the directory
 <code class="filename">work/.cwrappers/config</code> to see that the compiler
 options from <code class="varname">BUILD_ONLY_CFLAGS</code> are not yet added to
 the file <code class="filename">cc</code>. Examine the tail of the
 <code class="filename">work/.work.log</code> file to see that the normal compiler
 options are used.</p>
 <p>Now run <span class="command"><strong>bmake build</strong></span>. This will append the
 options to the file <code class="filename">cc</code> and will create the marker
 file in the same directory. After that, the build starts as usual, but
 with the added compiler options. Examine the tail of the file
 <code class="filename">work/.work.log</code> to see that the lines starting with
 <code class="literal">[*]</code> don't contain the compiler options, but the
 corresponding lines starting with <code class="literal">&lt;.&gt;</code> do end
 with these options.</p>
 <p>Building packages using this setup variant and fixing the resulting
 bugs is the same as in <a class="xref" href="#bulk.var.comperr" title="8.4.2.�Detect classes of bugs by forcing compiler warnings">Section�8.4.2, &#8220;Detect classes of bugs by forcing compiler warnings&#8221;</a>.</p>
 </div>
 <div class="sect2">
 <div class="titlepage"><div><div><h3 class="title">
 <a name="bulk.var.dirs"></a>8.4.4.�Use custom directories</h3></div></div></div>
 <p>Some directories like <code class="varname">PREFIX</code>,
 <code class="varname">VARBASE</code>, <code class="varname">PKG_SYSCONFDIR</code>,
 <code class="varname">PKGMANDIR</code>, <code class="varname">PKG_INFODIR</code> can be
 configured in pkgsrc. Set these to arbitrary paths during bootstrap or
 afterwards in <a class="link" href="#mk.conf"><code class="filename">mk.conf</code></a>.</p>
 <pre class="programlisting">
 PREFIX=         /a-random-uuid
 PKG_SYSCONFDIR= /a-random-uuid
 VARBASE=        /a-random-uuid
 PKGMANDIR=	a-random-uuid
 PKG_INFODIR=	a-random-uuid
 </pre>
 </div>
 <div class="sect2">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="bulk.var.warn"></a>8.4.4.�Turn warnings into errors</h3></div></div></div>
+<a name="bulk.var.warn"></a>8.4.5.�Turn warnings into errors</h3></div></div></div>
 <p>When building a package, warnings are typically ignored since they
 just flow by and do not cause the build to fail immediately. To find
 these warnings, redefine them to errors in <a class="link" href="#mk.conf"><code class="filename">mk.conf</code></a>.</p>
 <pre class="programlisting">
 DELAYED_WARNING_MSG=    ${DELAYED_ERROR_MSG} "(was warning)"
 WARNING_MSG=            ${FAIL_MSG} "(was warning)"
 </pre>
 <p>(There are many more classes of warnings in pkgsrc, and most of
 them can be redefined with a simple definition like above.</p>
 <p>If a package suggests to add <code class="varname">USE_TOOLS+=perl</code> to
 the package Makefile, research whether the package actually needs Perl.
 If it does, add <code class="varname">USE_TOOLS+=perl</code> to the package
 Makefile, and if it doesn't, add
 <code class="varname">TOOLS_BROKEN+=perl</code>.</p>
 </div>
 <div class="sect2">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="bulk.var.pkglint"></a>8.4.5.�Reject packages for which pkglint reports errors</h3></div></div></div>
+<a name="bulk.var.pkglint"></a>8.4.6.�Reject packages for which pkglint reports errors</h3></div></div></div>
 <p>Using pkglint as part of the regular build process is mostly a
 waste of time. If you want to fix some of the warnings, just run pkglint
 recursively on the whole pkgsrc tree. This will take a few minutes (up to
 ), which is much faster than a complete bulk build.</p>
 </div>
 <div class="sect2">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="bulk.var.strings"></a>8.4.6.�Reject packages that contain forbidden strings</h3></div></div></div>
+<a name="bulk.var.strings"></a>8.4.7.�Reject packages that contain forbidden strings</h3></div></div></div>
 <p>To ensure that the binary packages don't contain references to the
 build directory, there is already <code class="varname">CHECK_WRKREF</code>. If
 that variable includes the item <code class="literal">extra</code>, it is
 possible to define additional patterns that must not appear in any
 installed file. This is specified in <a class="link" href="#mk.conf"><code class="filename">mk.conf</code></a>.</p>
 <pre class="programlisting">
 CHECK_WRKREF=                   extra
 CHECK_WRKREF_EXTRA_DIRS+=       /usr/local
 CHECK_WRKREF_EXTRA_DIRS+=       /usr/pkg
 CHECK_WRKREF_EXTRA_DIRS+=	@[A-Z][A-Z]*@
 </pre>
 <p>The above patterns will probably generate many false positives,
 therefore the results need to be taken with a grain of salt.</p>
 </div>
 <div class="sect2">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="bulk.var.test"></a>8.4.7.�Reject packages whose self-test fails</h3></div></div></div>
+<a name="bulk.var.test"></a>8.4.8.�Reject packages whose self-test fails</h3></div></div></div>
 <p>To run the test suites that come with each package, add this line
 to <a class="link" href="#mk.conf"><code class="filename">mk.conf</code></a>.</p>
 <pre class="programlisting">
 PKGSRC_RUN_TEST=        yes
 </pre>
 <p>Be prepared that even the most basic packages fail this test. When
 doing a bulk build with this, it will often abort in the early phase
 where the packages are scanned for their dependencies since there are
 cyclic dependencies. There is still a lot to do in this area.</p>
 </div>
 <div class="sect2">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="bulk.var.shvar"></a>8.4.8.�Reject packages that use undefined shell variables</h3></div></div></div>
+<a name="bulk.var.shvar"></a>8.4.9.�Reject packages that use undefined shell variables</h3></div></div></div>
 <p>To catch typos in the shell snippets from the Makefile fragments,
 add the <code class="literal">-u</code> flag to most of the commands by adding this
 line to <a class="link" href="#mk.conf"><code class="filename">mk.conf</code></a>.</p>
 <pre class="programlisting">
 RUN=    @set -eu;
 </pre>
 <p>After that, ensure that none of the bulk build log files (even
 those for successfully built packages) contains the string
 <code class="literal">parameter not set</code> or whatever error message the
 command <span class="command"><strong>sh -ceu '$undefined'</strong></span> outputs.</p>
 <p>See <code class="filename">mk/misc/common.mk</code> for the existing
 definition.</p>
 </div>
 <div class="sect2">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="bulk.var.quiet"></a>8.4.9.�Turn off verbose logging</h3></div></div></div>
+<a name="bulk.var.quiet"></a>8.4.10.�Turn off verbose logging</h3></div></div></div>
 <p>The build logs of a package are often quite long. This allows error
 messages or other interesting details to hide between the noise. To make
 the actual error message stand out more, add these lines to
 <a class="link" href="#mk.conf"><code class="filename">mk.conf</code></a>.</p>
 <pre class="programlisting">
 GNU_CONFIGURE_QUIET=    yes
 MAKE_FLAGS+=            -s
 </pre>
 <p>The <code class="literal">-s</code> option works for both GNU Make and BSD
 Make. On exotic platforms with their own make, it may be a little
 different.</p>
 </div>
 </div>
 @@ -6952,60 +7038,26 @@ ${FETCH_CMD} ${FETCH_BEFORE_ARGS} ${site
 	  result before putting it into
 	  <code class="filename">PLIST</code>. On upgrades, it's useful to
 	  diff the output of this command against an already
 	  existing <code class="filename">PLIST</code> file.</p>
 <p>If the package installs files via <a class="citerefentry" href="https://netbsd.gw.com/cgi-bin/man-cgi?tar+1.i386+NetBSD-9.0"><span class="citerefentry"><span class="refentrytitle">tar</span>(1)</span></a> or
 	  other methods that don't update file access times, be
 	  sure to add these files manually to your
 	  <code class="filename">PLIST</code>, as the <span class="quote">&#8220;<span class="quote">find
 	  -newer</span>&#8221;</span> command used by this target won't catch
 	  them!</p>
 <p>See <a class="xref" href="#print-PLIST" title="15.3.�Tweaking output of make print-PLIST">Section�15.3, &#8220;Tweaking output of <span class="command"><strong>make print-PLIST</strong></span>&#8221;</a> for more
 	  information on this target.</p>
 </dd>
 <dt><span class="term">bulk-package</span></dt>
 <dd>
 <p>Used to do bulk builds. If an appropriate binary
 	  package already exists, no action is taken. If not, this
 	  target will compile, install and package it (and its
 	  depends, if <code class="varname">PKG_DEPENDS</code> is set
 	  properly. See <a class="xref" href="#bulk" title="Chapter�8.�Creating binary packages for everything in pkgsrc (bulk builds)">Chapter�8, <i>Creating binary packages for everything in pkgsrc (bulk
 builds)</i></a>).
 	  After creating the binary package, the sources, the
 	  just-installed package and its required packages are
 	  removed, preserving free disk space.</p>
 <p><span class="emphasis"><em>Beware that this target may deinstall
 	  all packages installed on a system!</em></span></p>
 </dd>
 <dt><span class="term">bulk-install</span></dt>
 <dd>
 <p>Used during bulk-installs to install required
 	  packages. If an up-to-date binary package is available,
 	  it will be installed via <a class="citerefentry" href="https://netbsd.gw.com/cgi-bin/man-cgi?pkg_add+1.i386+NetBSD-9.0"><span class="citerefentry"><span class="refentrytitle">pkg_add</span>(1)</span></a>. If not,
 	  <span class="command"><strong>make bulk-package</strong></span> will be executed,
 	  but the installed binary won't be removed.</p>
 <p>A binary package is considered
 	  <span class="quote">&#8220;<span class="quote">up-to-date</span>&#8221;</span> to be installed via
 	  <a class="citerefentry" href="https://netbsd.gw.com/cgi-bin/man-cgi?pkg_add+1.i386+NetBSD-9.0"><span class="citerefentry"><span class="refentrytitle">pkg_add</span>(1)</span></a> if:</p>
 <div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; ">
 <li class="listitem"><p>None of the package's files
 	      (<code class="filename">Makefile</code>, ...) were modified
 	      since it was built.</p></li>
 <li class="listitem"><p>None of the package's required (binary)
 	      packages were modified since it was built.</p></li>
 </ul></div>
 <p><span class="emphasis"><em>Beware that this target may deinstall
 	  all packages installed on a system!</em></span></p>
 </dd>
 </dl></div>
 </div>
 </div>
 <div class="chapter">
 <div class="titlepage"><div><div><h2 class="title">
 <a name="tools"></a>Chapter�20.�Tools needed for building or running</h2></div></div></div>
 <div class="toc">
 <p><b>Table of Contents</b></p>
 <dl class="toc">
 <dt><span class="sect1"><a href="#pkgsrc-tools">20.1. Tools for pkgsrc builds</a></span></dt>
 <dt><span class="sect1"><a href="#package-tools">20.2. Tools needed by packages</a></span></dt>
 <dt><span class="sect1"><a href="#platform-tools">20.3. Tools provided by platforms</a></span></dt>
 </dl>
 @@ -7796,49 +7848,49 @@ pre-configure or post-configure instead.
 <p>A typical use is to update pkg-config files to include the rpath
 compiler options.</p>
 </dd>
 <dt><span class="term"><code class="literal">pre-install</code></span></dt>
 <dd><p>In general, the install phase should be as simple as
 possible. As with the pre-build and post-build stages, it should not be
 used to fix pathnames or user names, these belong in pre-configure
 instead. There are only few legitimate use cases for applying
 substitutions in this stage.</p></dd>
 </dl></div>
 </div>
 <div class="sect3">
 <div class="titlepage"><div><div><h4 class="title">
-<a name="fixes.subst.where"></a>21.1.11.2.�Choosing the time where the substitutions happen</h4></div></div></div>
+<a name="fixes.subst.where"></a>21.1.11.2.�Choosing the files where the substitutions happen</h4></div></div></div>
 <p>The <code class="varname">SUBST_FILES.*</code> variable contains a list of
 filename patterns. These patterns are relative to
 <code class="varname">WRKSRC</code> since that is where most substitutions happen.
 A typical example is:</p>
 <pre class="programlisting">
 SUBST_FILES.path=       Makefile */Makefile */*/Makefile *.[ch]
 </pre>
 <p>The above patterns, especially the last, are quite broad. The SUBST
 implementation checks that each filename pattern that is mentioned here
 has an effect. For example, if none of the
 <code class="filename">*/*/Makefile</code> files contains the patterns to be found
 and substituted, that filename pattern is redundant and should be left
-out. If the text to be substituted occurs in some of the files from a
+out. By default, the SUBST framework will complain with an error message.
-single pattern, but not in all of them, that is totally ok, and the SUBST
+If the text to be substituted occurs in some of the files from a single
 pattern, but not in all of them, that is totally ok, and the SUBST
 framework will only print an INFO message for those files.</p>
 <p>If there is a good reason for having redundant filename patterns,
-set <code class="varname">SUBST_NOOP_OK.path=yes</code> in the above
+set <code class="varname">SUBST_NOOP_OK.*</code> to <code class="literal">yes</code>.</p>
 example.</p>
 <p>Another popular way of choosing the files for the substitutions is
 via a shell command, like this:</p>
 <pre class="programlisting">
-C_FILES_CMD=            cd ${WRKSRC} &amp;&amp; ${FIND} -name '*.c'
+C_FILES_CMD=            cd ${WRKSRC} &amp;&amp; ${FIND} . -name '*.c'
 SUBST_FILES.path=       ${C_FILES_CMD:sh}
 </pre>
 <p>The variable name <code class="varname">C_FILES_CMD</code> in this example is
 freely chosen and independent of the SUBST framework.</p>
 <p>In this variant, the <code class="varname">SUBST_FILES.*</code> variable
 lists each file individually. Thereby chances are higher that there are
 filename patterns in which no substitution happens. Since the SUBST
 framework cannot know whether the filename patterns in
 <code class="varname">SUBST_FILES.*</code> have been explicitly listed in the
 Makefile (where any redundant filename pattern would be suspicious) or
 been generated by a shell command (in which redundant filename patterns
 are more likely and to be expected), it will complain about these
 redundant filename patterns. Therefore, SUBST blocks that use a shell
 @@ -7856,35 +7908,35 @@ SUBST_SED.path=         -e 's|/usr/local
 <p>Each of the sed commands needs to be preceded by the
 <code class="literal">-e</code> option and should be specified on a line of its
 own, to avoid hiding short sed commands at the end of a line.</p>
 <p>Since the sed commands often contain shell metacharacters as the
 separator (the <code class="literal">|</code> in the above example), it is common
 to enclose them in single quotes.</p>
 <p>A common substitution is to replace placeholders of the form
 <code class="literal">@VARNAME@</code> with their pkgsrc counterpart variable
 <code class="literal">${VARNAME}</code>. A typical example is:</p>
 <pre class="programlisting">
 SUBST_VARS.path=        PREFIX
 </pre>
 <p>This type of substitutions is typically done by the GNU configure
-scripts, but in some cases these need to be overridden. The same pattern
+scripts during the do-configure stage, but in some cases these need to be
-is also used when a package defines patches that replace previously
+overridden. The same pattern is also used when a package defines patches
-hard-coded paths like <code class="literal">/usr/local</code> with a
+that replace previously hard-coded paths like
-<code class="literal">@PREFIX@</code> placeholder first, which then gets
+<code class="literal">/usr/local</code> with a <code class="literal">@PREFIX@</code>
-substituted by the actual <code class="literal">${PREFIX}</code> in the
+placeholder first, which then gets substituted by the actual
-pre-configure stage. In many of these cases, it works equally well to
+<code class="literal">${PREFIX}</code> in the pre-configure stage. In many of these
-just use the SUBST framework to directly replace
+cases, it works equally well to just use the SUBST framework to directly
-<code class="literal">/usr/local</code> with <code class="literal">${PREFIX}</code>, thereby
+replace <code class="literal">/usr/local</code> with <code class="literal">${PREFIX}</code>,
-omitting the intermediate patch file.</p>
+thereby omitting the intermediate patch file.</p>
 <p>If the above is not flexible enough, it is possible to not use sed
 at all for the substitution but to specify an entirely different command,
 like this:</p>
 <pre class="programlisting">
 SUBST_FILTER_CMD.path=  LC_ALL=C ${TR} -d '\r'
 </pre>
 <p>This is used for the few remaining packages in which the
 distributed files use Windows-style line endings that need to be
 converted to UNIX-style line endings.</p>
 </div>
 <div class="sect3">
 <div class="titlepage"><div><div><h4 class="title">
 <a name="fixes.subst.other"></a>21.1.11.4.�Other SUBST variables</h4></div></div></div>
 @@ -13756,152 +13808,156 @@ source packages
 <tr>
 <td>sendto</td>
 <td>setenv</td>
 </tr>
 <tr>
 <td>setgid</td>
 <td>setprogname</td>
 </tr>
 <tr>
 <td>setuid</td>
 <td>sh</td>
 </tr>
 <tr>
 <td>shebang</td>
 <td>show</td>
 <td>show-all</td>
 </tr>
 <tr>
 <td>show-all</td>
 <td>show-build-defs</td>
 <td>show-depends</td>
 </tr>
 <tr>
 <td>show-depends</td>
 <td>show-deps</td>
 <td>show-distfiles</td>
 </tr>
 <tr>
 <td>show-distfiles</td>
 <td>show-downlevel</td>
 <td>show-subdir-var</td>
 </tr>
 <tr>
 <td>show-subdir-var</td>
 <td>show-tools</td>
 <td>show-var</td>
 </tr>
 <tr>
 <td>show-var</td>
 <td>show-vars</td>
 <td>snprintf</td>
 </tr>
 <tr>
 <td>snprintf</td>
 <td>socket</td>
 <td>ssp</td>
 </tr>
 <tr>
 <td>ssp</td>
 <td>st_mode</td>
 <td>stage-install</td>
 </tr>
 <tr>
 <td>stage-install</td>
 <td>strcasestr</td>
 <td>strict</td>
 </tr>
 <tr>
 <td>strict</td>
 <td>strip</td>
 <td>strndup</td>
 </tr>
 <tr>
 <td>strndup</td>
 <td>strnlen</td>
 <td>strsep</td>
 </tr>
 <tr>
 <td>strsep</td>
 <td>subst</td>
 <td>substitutions</td>
 </tr>
 <tr>
 <td>substitutions</td>
 <td>subversion</td>
 <td>sun</td>
 </tr>
 <tr>
 <td>sun</td>
 <td>sunpro</td>
 <td>sunwspro</td>
 </tr>
 <tr>
 <td>sunwspro</td>
 <td>svn</td>
 <td>symlink</td>
 </tr>
 <tr>
 <td>symlink</td>
 <td>test</td>
 <td>test-env</td>
 </tr>
 <tr>
 <td>test-env</td>
 <td>tex</td>
 <td>texlive</td>
 </tr>
 <tr>
 <td>texlive</td>
 <td>tmp</td>
 <td>tool</td>
 </tr>
 <tr>
 <td>tool</td>
 <td>tools</td>
 <td>tools-libtool-m4-override</td>
 </tr>
 <tr>
 <td>tools-libtool-m4-override</td>
 <td>type</td>
 <td>ulimit</td>
 </tr>
 <tr>
 <td>ulimit</td>
 <td>undefined</td>
 <td>undo-replace</td>
 </tr>
 <tr>
 <td>undo-replace</td>
 <td>unlimit</td>
 <td>unprivileged</td>
 </tr>
 <tr>
 <td>unprivileged</td>
 <td>unprivileged-install-hook</td>
 <td>unstripped</td>
 </tr>
 <tr>
 <td>unstripped</td>
 <td>update</td>
 <td>upload</td>
 </tr>
 <tr>
 <td>upload</td>
 <td>upload-distfiles</td>
 <td>use_tools</td>
 </tr>
 <tr>
 <td>use_tools</td>
 <td>user</td>
 <td>utimes</td>
 </tr>
 <tr>
 <td>utimes</td>
 <td>vasprintf</td>
 <td>verbose</td>
 </tr>
 <tr>
 <td>verbose</td>
 <td>vsnprintf</td>
 <td>warn</td>
 </tr>
 <tr>
 <td>warn</td>
 <td>warning</td>
 <td>warnings</td>
 </tr>
 <tr>
 <td>warnings</td>
 <td>warnx</td>
 <td>wattr_off</td>
 </tr>
 <tr>
 <td>wattr_off</td>
 <td>wattr_on</td>
 <td>work</td>
 </tr>
 <tr>
 <td>work</td>
 <td>wrapper</td>
 </tr>
 <tr>
 <td>wrkdir</td>
 <td>�</td>
 </tr>
 </table>
 </div>
 <div class="appendix">
 <div class="titlepage"><div><div><h1 class="title">
 <a name="editing"></a>Appendix�E.�Editing guidelines for the pkgsrc guide</h1></div></div></div>
 <div class="toc">
 <p><b>Table of Contents</b></p>
 <dl class="toc">
 <dt><span class="sect1"><a href="#targets">E.1. Make targets</a></span></dt>
 <dt><span class="sect1"><a href="#procedure">E.2. Procedure</a></span></dt>
 </dl>
 </div>

 @@ -101,33 +101,34 @@ I. The pkgsrc user's guide
 . Creating binary packages for everything in pkgsrc (bulk builds)
 .1. Preparations
 .2. Running a bulk build
 .2.1. Configuration
 .3. Requirements of a full bulk build
 .4. Bulk build variants
 .4.1. Detect unknown configure options
 .4.2. Detect classes of bugs by forcing compiler warnings
-.4.3. Use custom directories
+.4.3. Force compiler options only in the build phase
-.4.4. Turn warnings into errors
+.4.4. Use custom directories
-.4.5. Reject packages for which pkglint reports errors
+.4.5. Turn warnings into errors
-.4.6. Reject packages that contain forbidden strings
+.4.6. Reject packages for which pkglint reports errors
-.4.7. Reject packages whose self-test fails
+.4.7. Reject packages that contain forbidden strings
-.4.8. Reject packages that use undefined shell variables
+.4.8. Reject packages whose self-test fails
-.4.9. Turn off verbose logging
+.4.9. Reject packages that use undefined shell variables
 .4.10. Turn off verbose logging
 .5. Creating a multiple CD-ROM packages collection
 .5.1. Example of cdpack
 . Directory layout of the installed files
 .1. File system layout in ${LOCALBASE}
 .2. File system layout in ${VARBASE}
 . Frequently Asked Questions
 .1. Are there any mailing lists for pkg-related discussion?
 @@ -754,33 +755,34 @@ Table of Contents
 . Creating binary packages for everything in pkgsrc (bulk builds)
 .1. Preparations
 .2. Running a bulk build
 .2.1. Configuration
 .3. Requirements of a full bulk build
 .4. Bulk build variants
 .4.1. Detect unknown configure options
 .4.2. Detect classes of bugs by forcing compiler warnings
-.4.3. Use custom directories
+.4.3. Force compiler options only in the build phase
-.4.4. Turn warnings into errors
+.4.4. Use custom directories
-.4.5. Reject packages for which pkglint reports errors
+.4.5. Turn warnings into errors
-.4.6. Reject packages that contain forbidden strings
+.4.6. Reject packages for which pkglint reports errors
-.4.7. Reject packages whose self-test fails
+.4.7. Reject packages that contain forbidden strings
-.4.8. Reject packages that use undefined shell variables
+.4.8. Reject packages whose self-test fails
-.4.9. Turn off verbose logging
+.4.9. Reject packages that use undefined shell variables
 .4.10. Turn off verbose logging
 .5. Creating a multiple CD-ROM packages collection
 .5.1. Example of cdpack
 . Directory layout of the installed files
 .1. File system layout in ${LOCALBASE}
 .2. File system layout in ${VARBASE}
 . Frequently Asked Questions
 .1. Are there any mailing lists for pkg-related discussion?
 @@ -1724,33 +1726,34 @@ Chapter 8. Creating binary packages for
 Table of Contents
 .1. Preparations
 .2. Running a bulk build
 .2.1. Configuration
 .3. Requirements of a full bulk build
 .4. Bulk build variants
 .4.1. Detect unknown configure options
 .4.2. Detect classes of bugs by forcing compiler warnings
-.4.3. Use custom directories
+.4.3. Force compiler options only in the build phase
-.4.4. Turn warnings into errors
+.4.4. Use custom directories
-.4.5. Reject packages for which pkglint reports errors
+.4.5. Turn warnings into errors
-.4.6. Reject packages that contain forbidden strings
+.4.6. Reject packages for which pkglint reports errors
-.4.7. Reject packages whose self-test fails
+.4.7. Reject packages that contain forbidden strings
-.4.8. Reject packages that use undefined shell variables
+.4.8. Reject packages whose self-test fails
-.4.9. Turn off verbose logging
+.4.9. Reject packages that use undefined shell variables
 .4.10. Turn off verbose logging
 .5. Creating a multiple CD-ROM packages collection
 .5.1. Example of cdpack
 For a number of reasons, you may want to build binary packages for a large
 selected set of packages in pkgsrc, or even for all pkgsrc packages. For
 instance, when you have multiple machines that should run the same software, it
 is wasted time if they all build their packages themselves from source. Or you
 may want to build a list of packages you want and check them before deploying
 onto production systems. There is a way of getting a set of binary packages:
 the bulk build system, or pbulk ("p" stands for "parallel"). This chapter
 describes how to set it up.
 @@ -1916,97 +1919,173 @@ this in your local mk.conf, like this, t
 # code
 # Reason why the code does not need to be fixed.
 BUILDLINK_TRANSFORM+=   rm:-Werror=char-subscripts
 .endif
 If the error messages from the compiler are valid and the code needs to be
 fixed, prepare a local patch (see LOCALPATCHES) and report the bug to the
 upstream authors of the package, providing them with the information you
 collected above.
 Patches that are not essential for the package to work should only be reported
 upstream but not committed to pkgsrc, to make future updates easier.
-.4.3. Use custom directories
+.4.3. Force compiler options only in the build phase
 When adding custom compiler flags via CFLAGS, these apply to all phases of the
 package build process. Especially in the configure phase, adding -Werror leads
 to wrong decisions. The GNU configure scripts feed many small test programs to
 the C compiler to see whether certain headers are available, functions are
 defined in a library and programs can be run. In many cases these programs
 would not survive a strict compiler run with -Wall -Wextra -Werror.
 The pkgsrc infrastructure is flexible enough to support compiler options being
 added between the configure and build phases. It's a little more complicated
 than the other examples in this section but still easy enough.
 The basic idea is to use the pkgsrc compiler wrapper to inject the desired
 compiler options. The compiler wrapper's original task is to hide unwanted
 directories of include files and to normalize compiler options. It does this by
 wrapping the compiler command and rewriting the command line. To see this in
 action, run bmake patch in a package directory and examine the work/.cwrappers/
 config directory. It contains individual configurations for the C compiler and
 the related tools. The plan is to find a hook between the configure and build
 phases, and to modify these configuration files at that point.
 To find this hook, have a look at mk/build/build.mk, which contains among
 others the pre-build-checks-hook. The word checks doesn't quite fit, but the
 pre-build-hook sounds good enough.
 The code to be included in mk.conf is:
 # Just a few example options.
 BUILD_ONLY_CFLAGS=      -Wall -Werror -O2 -DTEMPDIR='"/tmp"'
 .if ${BUILD_ONLY_CFLAGS:U:M*}
 pre-build-checks-hook: add-build-only-cflags
 add-build-only-cflags: .PHONY
         ${RUN} cd ${CWRAPPERS_CONFIG_DIR};      \
         ${TEST} ! -f ${.TARGET} || exit 0;      \
         for flag in ${BUILD_ONLY_CFLAGS}; do    \
                 ${ECHO} "append=$$flag" >> cc;  \
         done;                                   \
         > ${.TARGET}
 .endif
 (When editing the mk.conf, make sure that the commands of the
 add-build-only-cflags target are indented with a tab, not with spaces.)
 The condition in the .if statement contains the :U modifier to prevent parse
 errors if the variable should be undefined, possibly because it is only defined
 for a subset of the packages. The :M* modifier ensures that there is at least
 one compiler option, to prevent a syntax error in the shell parser.
 The code around the ${.TARGET} variable ensures that the additional compiler
 options are only appended once, even if bmake build is run multiple times. To
 do this, it creates a marker file.
 To verify that this setup works, run bmake configure in a package directory. Up
 to now, everything works as usual. Examine the directory work/.cwrappers/config
 to see that the compiler options from BUILD_ONLY_CFLAGS are not yet added to
 the file cc. Examine the tail of the work/.work.log file to see that the normal
 compiler options are used.
 Now run bmake build. This will append the options to the file cc and will
 create the marker file in the same directory. After that, the build starts as
 usual, but with the added compiler options. Examine the tail of the file work
 /.work.log to see that the lines starting with [*] don't contain the compiler
 options, but the corresponding lines starting with <.> do end with these
 options.
 Building packages using this setup variant and fixing the resulting bugs is the
 same as in Section 8.4.2, "Detect classes of bugs by forcing compiler warnings"
+.
 .4.4. Use custom directories
 Some directories like PREFIX, VARBASE, PKG_SYSCONFDIR, PKGMANDIR, PKG_INFODIR
 can be configured in pkgsrc. Set these to arbitrary paths during bootstrap or
 afterwards in mk.conf.
 PREFIX=         /a-random-uuid
 PKG_SYSCONFDIR= /a-random-uuid
 VARBASE=        /a-random-uuid
 PKGMANDIR=      a-random-uuid
 PKG_INFODIR=    a-random-uuid
-.4.4. Turn warnings into errors
+.4.5. Turn warnings into errors
 When building a package, warnings are typically ignored since they just flow by
 and do not cause the build to fail immediately. To find these warnings,
 redefine them to errors in mk.conf.
 DELAYED_WARNING_MSG=    ${DELAYED_ERROR_MSG} "(was warning)"
 WARNING_MSG=            ${FAIL_MSG} "(was warning)"
 (There are many more classes of warnings in pkgsrc, and most of them can be
 redefined with a simple definition like above.
 If a package suggests to add USE_TOOLS+=perl to the package Makefile, research
 whether the package actually needs Perl. If it does, add USE_TOOLS+=perl to the
 package Makefile, and if it doesn't, add TOOLS_BROKEN+=perl.
-.4.5. Reject packages for which pkglint reports errors
+.4.6. Reject packages for which pkglint reports errors
 Using pkglint as part of the regular build process is mostly a waste of time.
 If you want to fix some of the warnings, just run pkglint recursively on the
 whole pkgsrc tree. This will take a few minutes (up to 10), which is much
 faster than a complete bulk build.
-.4.6. Reject packages that contain forbidden strings
+.4.7. Reject packages that contain forbidden strings
 To ensure that the binary packages don't contain references to the build
 directory, there is already CHECK_WRKREF. If that variable includes the item
 extra, it is possible to define additional patterns that must not appear in any
 installed file. This is specified in mk.conf.
 CHECK_WRKREF=                   extra
 CHECK_WRKREF_EXTRA_DIRS+=       /usr/local
 CHECK_WRKREF_EXTRA_DIRS+=       /usr/pkg
 CHECK_WRKREF_EXTRA_DIRS+=       @[A-Z][A-Z]*@
 The above patterns will probably generate many false positives, therefore the
 results need to be taken with a grain of salt.
-.4.7. Reject packages whose self-test fails
+.4.8. Reject packages whose self-test fails
 To run the test suites that come with each package, add this line to mk.conf.
 PKGSRC_RUN_TEST=        yes
 Be prepared that even the most basic packages fail this test. When doing a bulk
 build with this, it will often abort in the early phase where the packages are
 scanned for their dependencies since there are cyclic dependencies. There is
 still a lot to do in this area.
-.4.8. Reject packages that use undefined shell variables
+.4.9. Reject packages that use undefined shell variables
 To catch typos in the shell snippets from the Makefile fragments, add the -u
 flag to most of the commands by adding this line to mk.conf.
 RUN=    @set -eu;
 After that, ensure that none of the bulk build log files (even those for
 successfully built packages) contains the string parameter not set or whatever
 error message the command sh -ceu '$undefined' outputs.
 See mk/misc/common.mk for the existing definition.
-.4.9. Turn off verbose logging
+.4.10. Turn off verbose logging
 The build logs of a package are often quite long. This allows error messages or
 other interesting details to hide between the noise. To make the actual error
 message stand out more, add these lines to mk.conf.
 GNU_CONFIGURE_QUIET=    yes
 MAKE_FLAGS+=            -s
 The -s option works for both GNU Make and BSD Make. On exotic platforms with
 their own make, it may be a little different.
 .5. Creating a multiple CD-ROM packages collection
 @@ -5749,55 +5828,26 @@ print-PLIST
     attempt to generate a new PLIST from a find -newer work/.extract_done. An
     attempt is made to care for shared libs etc., but it is strongly
     recommended to review the result before putting it into PLIST. On upgrades,
     it's useful to diff the output of this command against an already existing
     PLIST file.
     If the package installs files via tar(1) or other methods that don't update
     file access times, be sure to add these files manually to your PLIST, as
     the "find -newer" command used by this target won't catch them!
     See Section 15.3, "Tweaking output of make print-PLIST" for more
     information on this target.
 bulk-package
     Used to do bulk builds. If an appropriate binary package already exists, no
     action is taken. If not, this target will compile, install and package it
     (and its depends, if PKG_DEPENDS is set properly. See Chapter 8, Creating
     binary packages for everything in pkgsrc (bulk builds)). After creating the
     binary package, the sources, the just-installed package and its required
     packages are removed, preserving free disk space.
     Beware that this target may deinstall all packages installed on a system!
 bulk-install
     Used during bulk-installs to install required packages. If an up-to-date
     binary package is available, it will be installed via pkg_add(1). If not,
     make bulk-package will be executed, but the installed binary won't be
     removed.
     A binary package is considered "up-to-date" to be installed via pkg_add(1)
     if:
       + None of the package's files (Makefile, ...) were modified since it was
         built.
       + None of the package's required (binary) packages were modified since it
         was built.
     Beware that this target may deinstall all packages installed on a system!
 Chapter 20. Tools needed for building or running
 Table of Contents
 .1. Tools for pkgsrc builds
 .2. Tools needed by packages
 .3. Tools provided by platforms
 The USE_TOOLS definition is used both internally by pkgsrc and also for
 individual packages to define what commands are needed for building a package
 (like TOOL_DEPENDS) or for later run-time of an installed packaged (such as
 DEPENDS). If the native system provides an adequate tool, then in many cases, a
 pkgsrc package will not be used.
 @@ -6453,49 +6503,50 @@ post-build
     with ${PREFIX}) or user names (such as replacing @MY_USER@ with the actual
     username) belong in pre-configure or post-configure instead.
     A typical use is to update pkg-config files to include the rpath compiler
     options.
 pre-install
     In general, the install phase should be as simple as possible. As with the
     pre-build and post-build stages, it should not be used to fix pathnames or
     user names, these belong in pre-configure instead. There are only few
     legitimate use cases for applying substitutions in this stage.
-.1.11.2. Choosing the time where the substitutions happen
+.1.11.2. Choosing the files where the substitutions happen
 The SUBST_FILES.* variable contains a list of filename patterns. These patterns
 are relative to WRKSRC since that is where most substitutions happen. A typical
 example is:
 SUBST_FILES.path=       Makefile */Makefile */*/Makefile *.[ch]
 The above patterns, especially the last, are quite broad. The SUBST
 implementation checks that each filename pattern that is mentioned here has an
 effect. For example, if none of the */*/Makefile files contains the patterns to
 be found and substituted, that filename pattern is redundant and should be left
-out. If the text to be substituted occurs in some of the files from a single
+out. By default, the SUBST framework will complain with an error message. If
-pattern, but not in all of them, that is totally ok, and the SUBST framework
+the text to be substituted occurs in some of the files from a single pattern,
-will only print an INFO message for those files.
+but not in all of them, that is totally ok, and the SUBST framework will only
 print an INFO message for those files.
 If there is a good reason for having redundant filename patterns, set
-SUBST_NOOP_OK.path=yes in the above example.
+SUBST_NOOP_OK.* to yes.
 Another popular way of choosing the files for the substitutions is via a shell
 command, like this:
-C_FILES_CMD=            cd ${WRKSRC} && ${FIND} -name '*.c'
+C_FILES_CMD=            cd ${WRKSRC} && ${FIND} . -name '*.c'
 SUBST_FILES.path=       ${C_FILES_CMD:sh}
 The variable name C_FILES_CMD in this example is freely chosen and independent
 of the SUBST framework.
 In this variant, the SUBST_FILES.* variable lists each file individually.
 Thereby chances are higher that there are filename patterns in which no
 substitution happens. Since the SUBST framework cannot know whether the
 filename patterns in SUBST_FILES.* have been explicitly listed in the Makefile
 (where any redundant filename pattern would be suspicious) or been generated by
 a shell command (in which redundant filename patterns are more likely and to be
 expected), it will complain about these redundant filename patterns. Therefore,
 SUBST blocks that use a shell command to generate the list of filename patterns
 @@ -6510,33 +6561,34 @@ SUBST_SED.path=         -e 's|/usr/local
 Each of the sed commands needs to be preceded by the -e option and should be
 specified on a line of its own, to avoid hiding short sed commands at the end
 of a line.
 Since the sed commands often contain shell metacharacters as the separator (the
 | in the above example), it is common to enclose them in single quotes.
 A common substitution is to replace placeholders of the form @VARNAME@ with
 their pkgsrc counterpart variable ${VARNAME}. A typical example is:
 SUBST_VARS.path=        PREFIX
-This type of substitutions is typically done by the GNU configure scripts, but
+This type of substitutions is typically done by the GNU configure scripts
-in some cases these need to be overridden. The same pattern is also used when a
+during the do-configure stage, but in some cases these need to be overridden.
-package defines patches that replace previously hard-coded paths like /usr/
+The same pattern is also used when a package defines patches that replace
-local with a @PREFIX@ placeholder first, which then gets substituted by the
+previously hard-coded paths like /usr/local with a @PREFIX@ placeholder first,
-actual ${PREFIX} in the pre-configure stage. In many of these cases, it works
+which then gets substituted by the actual ${PREFIX} in the pre-configure stage.
-equally well to just use the SUBST framework to directly replace /usr/local
+In many of these cases, it works equally well to just use the SUBST framework
-with ${PREFIX}, thereby omitting the intermediate patch file.
+to directly replace /usr/local with ${PREFIX}, thereby omitting the
 intermediate patch file.
 If the above is not flexible enough, it is possible to not use sed at all for
 the substitution but to specify an entirely different command, like this:
 SUBST_FILTER_CMD.path=  LC_ALL=C ${TR} -d '\r'
 This is used for the few remaining packages in which the distributed files use
 Windows-style line endings that need to be converted to UNIX-style line
 endings.
 .1.11.4. Other SUBST variables
 When a SUBST block is applied during a package build, a message is logged. The
 @@ -9700,58 +9752,59 @@ print-plist                      print-s
 privileged-install-hook          pypi
 python                           readme-all
 recv                             recvfrom
 regcomp                          release-localbase-lock
 release-lock                     relro
 rename                           reorder
 replace                          replace_interpreter
 reproducible                     resolv
 root                             ruby
 send                             sendfile
 sendto                           setenv
 setgid                           setprogname
 setuid                           sh
-show                             show-all
+shebang                          show
-show-build-defs                  show-depends
+show-all                         show-build-defs
-show-deps                        show-distfiles
+show-depends                     show-deps
-show-downlevel                   show-subdir-var
+show-distfiles                   show-downlevel
-show-tools                       show-var
+show-subdir-var                  show-tools
-show-vars                        snprintf
+show-var                         show-vars
-socket                           ssp
+snprintf                         socket
-st_mode                          stage-install
+ssp                              st_mode
-strcasestr                       strict
+stage-install                    strcasestr
-strip                            strndup
+strict                           strip
-strnlen                          strsep
+strndup                          strnlen
-subst                            substitutions
+strsep                           subst
-subversion                       sun
+substitutions                    subversion
-sunpro                           sunwspro
+sun                              sunpro
-svn                              symlink
+sunwspro                         svn
-test                             test-env
+symlink                          test
-tex                              texlive
+test-env                         tex
-tmp                              tool
+texlive                          tmp
-tools                            tools-libtool-m4-override
+tool                             tools
-type                             ulimit
+tools-libtool-m4-override        type
-undefined                        undo-replace
+ulimit                           undefined
-unlimit                          unprivileged
+undo-replace                     unlimit
-unprivileged-install-hook        unstripped
+unprivileged                     unprivileged-install-hook
-update                           upload
+unstripped                       update
-upload-distfiles                 use_tools
+upload                           upload-distfiles
-user                             utimes
+use_tools                        user
-vasprintf                        verbose
+utimes                           vasprintf
-vsnprintf                        warn
+verbose                          vsnprintf
-warning                          warnings
+warn                             warning
-warnx                            wattr_off
+warnings                         warnx
-wattr_on                         work
+wattr_off                        wattr_on
-wrapper                          wrkdir
+work                             wrapper
 wrkdir
 Appendix E. Editing guidelines for the pkgsrc guide
 Table of Contents
 E.1. Make targets
 E.2. Procedure
 This section contains information on editing the pkgsrc guide itself.
 E.1. Make targets
 The pkgsrc guide's source code is stored in pkgsrc/doc/guide/files, and several