 @@ -557,34 +557,34 @@ pkgsrc provides the following key featur
 <li><p>The installation prefix, acceptable software licenses,
   international encryption requirements and build-time options for a
   large number of packages are all set in a simple, central
   configuration file.</p></li>
 <li><p>The entire source (not including the distribution files) is
   freely available under a BSD license, so you may extend and adapt
   pkgsrc to your needs. Support for local packages and patches is
   available right out of the box, so you can configure it specifically
   for your environment.</p></li>
 </ul></div>
 <p>The following principles are basic to pkgsrc:</p>
 <div class="itemizedlist"><ul type="disc">
 <li><p>&#8220;<span class="quote">It should only work if it's right.</span>&#8221;
-&mdash; That means, if a package contains bugs, it's better to find
+&#8212; That means, if a package contains bugs, it's better to find
 them and to complain about them rather than to just install the package
 and hope that it works. There are numerous checks in pkgsrc that try to
 find such bugs: Static analysis tools (<a href="ftp://ftp.NetBSD.org/pub/pkgsrc/current/pkgsrc/pkgtools/pkglint/README.html" target="_top"><code class="filename">pkgtools/pkglint</code></a>), build-time checks (portability
 of shell scripts), and post-installation checks (installed files,
 references to shared libraries, script interpreters).</p></li>
 <li><p>&#8220;<span class="quote">If it works, it should work everywhere</span>&#8221;
-&mdash; Like NetBSD has been ported to many hardware architectures,
+&#8212; Like NetBSD has been ported to many hardware architectures,
 pkgsrc has been ported to many operating systems. Care is taken that
 packages behave the same on all platforms.</p></li>
 </ul></div>
 </div>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
 <a name="intro.platforms"></a>1.1.2. Supported platforms</h3></div></div></div>
 <p>pkgsrc consists of both a source distribution and a binary
 distribution for these operating systems. After retrieving the required
 source or binaries, you can be up and running with pkgsrc in just
 minutes!</p>
 <p>pkgsrc was derived from FreeBSD's ports system, and
       initially developed for NetBSD only. Since then, pkgsrc has
 @@ -1749,27 +1749,27 @@ and you can still use binary packages fr
 <code class="prompt">#</code> <strong class="userinput"><code>pkg_add openoffice2</code></strong>
 <code class="prompt">#</code> <strong class="userinput"><code>pkg_add kde-3.5.7</code></strong>
 <code class="prompt">#</code> <strong class="userinput"><code>pkg_add ap2-php5-*</code></strong>
 </pre>
 <p>Note that any prerequisite packages needed to run the
     package in question will be installed, too, assuming they are
     present where you install from.</p>
 <p>As mentioned above, packages for which vulnerabilities get
     known are not stored in the <code class="filename">All</code> subdirectory.
     They don't get deleted since that could be very frustrating if many
     other packages depend on it. Instead, they are moved to the
     <code class="filename">vulnerable</code> subdirectory. So you may need to add
     this directory to the <code class="varname">PKG_PATH</code> variable.
-    However, you should run <span class="command"><strong>audit-packages</strong></span>
+    However, you should run <span class="command"><strong>pkg_admin audit</strong></span>
     regularly, especially after installing new packages, and verify
     that the vulnerabilities are acceptable for your configuration.</p>
 <p>After you've installed packages, be sure to have
     <code class="filename">/usr/pkg/bin</code> and <code class="filename">/usr/pkg/sbin</code> in your
     <code class="varname">PATH</code> so you can actually start the just
     installed program.</p>
 </div>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
 <a name="using.pkg_delete"></a>4.1.3. Deinstalling packages</h3></div></div></div>
 <p>To deinstall a package, it does not matter whether it was
     installed from source code or from a binary package. The
     <span class="command"><strong>pkg_delete</strong></span> command does not know it anyway.
 @@ -1799,48 +1799,65 @@ and you can still use binary packages fr
 <p>The <span class="command"><strong>pkg_info</strong></span> shows information about
     installed packages or binary package files.</p>
 </div>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
 <a name="vulnerabilities"></a>4.1.5. Checking for security vulnerabilities in installed packages</h3></div></div></div>
 <p>
       The NetBSD Security-Officer and Packages Groups maintain a list of
       known security vulnerabilities to packages which are (or have been)
       included in pkgsrc.  The list is available from the NetBSD
       FTP site at <a class="ulink" href="ftp://ftp.NetBSD.org/pub/pkgsrc/distfiles/vulnerabilities" target="_top">ftp://ftp.NetBSD.org/pub/pkgsrc/distfiles/vulnerabilities</a>.
     </p>
 <p>
-      Through <a href="ftp://ftp.NetBSD.org/pub/pkgsrc/current/pkgsrc/security/audit-packages/README.html" target="_top"><code class="filename">security/audit-packages</code></a>,
+      Through <span class="command"><strong>pkg_admin fetch-pkg-vulnerabilities</strong></span>,
       this list can be downloaded
       automatically, and a security audit of all packages installed on a system
       can take place.
     </p>
 <p>
-      There are two components to
+      There are two components to auditing.  The first
-      <a href="ftp://ftp.NetBSD.org/pub/pkgsrc/current/pkgsrc/security/audit-packages/README.html" target="_top"><code class="filename">security/audit-packages</code></a>.  The first
+      step, <span class="command"><strong>pkg_admin fetch-pkg-vulnerabilities</strong></span>,
-      component, &#8220;<span class="quote">download-vulnerability-list</span>&#8221;, is for downloading
+      is for downloading
       the list of vulnerabilities from the NetBSD FTP site.  The second
-      component, &#8220;<span class="quote">audit-packages</span>&#8221;, checks to see if any of your
+      step, <span class="command"><strong>pkg_admin audit</strong></span>, checks to see if any of your
       installed packages are vulnerable.  If a package is vulnerable, you
       will see output similar to the following:
     </p>
 <pre class="screen">Package samba-2.0.9 has a local-root-shell vulnerability, see
     http://www.samba.org/samba/whatsnew/macroexploit.html</pre>
 <p>
-      One can set up <a href="ftp://ftp.NetBSD.org/pub/pkgsrc/current/pkgsrc/security/audit-packages/README.html" target="_top"><code class="filename">security/audit-packages</code></a> to download the
+      You may wish to have the
       <a class="ulink" href="ftp://ftp.NetBSD.org/pub/pkgsrc/distfiles/vulnerabilities" target="_top">vulnerabilities</a>
-      file daily, and include a package audit in the daily security script.
+      file downloaded daily so that
-      Details on this are located in the <a class="ulink" href="http://cvsweb.NetBSD.org/bsdweb.cgi/pkgsrc/security/audit-packages/MESSAGE?rev=HEAD&amp;content-type=text/x-cvsweb-markup" target="_top">MESSAGE</a>
+      it remains current.  This may be done by adding an appropriate entry
-      file for <a href="ftp://ftp.NetBSD.org/pub/pkgsrc/current/pkgsrc/security/audit-packages/README.html" target="_top"><code class="filename">security/audit-packages</code></a>.
+      to the root users <a class="citerefentry" href="http://netbsd.gw.com/cgi-bin/man-cgi?crontab+5+NetBSD-current"><span class="citerefentry"><span class="refentrytitle">crontab</span>(5)</span></a> entry.  For example the entry
       </p>
 <pre class="screen">
 # download vulnerabilities file
 3 * * * /usr/sbin/pkg_admin fetch-pkg-vulnerabilities &gt;/dev/null 2&gt;&amp;1
       </pre>
 <p>
       will update the vulnerability list every day at 3AM. You may wish to do
       this more often than once a day.
       In addition, you may wish to run the package audit from the daily
       security script.  This may be accomplished by adding the following
       line to <code class="filename">/etc/security.local</code>:
       </p>
 <pre class="screen">
 /usr/sbin/pkg_admin audit
       </pre>
 <p>
     </p>
 </div>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
 <a name="pkg_versions"></a>4.1.6. Finding if newer versions of your installed packages are in pkgsrc</h3></div></div></div>
 <p>
       Install <a href="ftp://ftp.NetBSD.org/pub/pkgsrc/current/pkgsrc/pkgtools/lintpkgsrc/README.html" target="_top"><code class="filename">pkgtools/lintpkgsrc</code></a> and run
       <span class="command"><strong>lintpkgsrc</strong></span> with the &#8220;<span class="quote">-i</span>&#8221;
       argument to check if your packages are up-to-date, e.g.
     </p>
 <pre class="screen">
 <code class="prompt">%</code> <strong class="userinput"><code>lintpkgsrc -i</code></strong>
 ...
 @@ -2152,50 +2169,52 @@ works.
 	    if not found locally or in
 	    <code class="filename">${MASTER_SITES}</code> or
 	    <code class="filename">${PATCH_SITES}</code> respectively.
 	    The defaults are
 	    <code class="filename">ftp://ftp.NetBSD.org/pub/NetBSD/packages/distfiles/${DIST_SUBDIR}/</code>
 	    and
 	    <code class="filename">ftp://ftp.freebsd.org/pub/FreeBSD/distfiles/${DIST_SUBDIR}/</code>.</p></li>
 <li><p><code class="varname">BINPKG_SITES</code>:
 	    List of sites carrying binary pkgs. <em class="replaceable"><code>rel</code></em> and
 	    <em class="replaceable"><code>arch</code></em> are replaced with OS
 	    release (&#8220;<span class="quote">2.0</span>&#8221;, etc.) and architecture
 	    (&#8220;<span class="quote">mipsel</span>&#8221;, etc.).</p></li>
 <li><p><code class="varname">ACCEPTABLE_LICENSES</code>:
-	    List of acceptable licenses. Whenever you try to build a package
+	    List of acceptable licenses. License names are case-sensitive.
-	    whose license is not in this list, you will get an error message
+	    Whenever you try to build a package whose license is not in this
-	    that includes instructions on how to change this variable.</p></li>
+	    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" lang="en">
 <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>
 <div class="itemizedlist"><ul type="disc">
 <li><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><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
+	    &#8212; 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><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
 	    information.</p></li>
 <li><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><p><code class="varname">DEPENDS_TARGET</code>:
 @@ -2618,37 +2637,37 @@ way.
 	<code class="filename">pkgsrc/mk/bulk/build.conf-example</code>. To use
 	it, copy <code class="filename">build.conf-example</code> to
 	<code class="filename">build.conf</code> and edit it, following the
 	comments in that file.</p>
 </div>
 <div class="sect3" lang="en">
 <div class="titlepage"><div><div><h4 class="title">
 <a name="binary.mk.conf"></a>7.3.1.2. <a class="link" href="#mk.conf"><code class="filename">mk.conf</code></a>
 </h4></div></div></div>
 <p>You may want to set variables in <a class="link" href="#mk.conf"><code class="filename">mk.conf</code></a>.
 	Look at <code class="filename">pkgsrc/mk/defaults/mk.conf</code> for
 	details of the default settings. You will want to ensure that
 	<code class="varname">ACCEPTABLE_LICENSES</code> meet your local policy.
-	As used in this example, <code class="varname">_ACCEPTABLE=yes</code>
+	As used in this example, <code class="varname">SKIP_LICENSE_CHECK=yes</code>
 	completely bypasses the license check.</p>
 <pre class="programlisting">
 PACKAGES?=      ${_PKGSRCDIR}/packages/${MACHINE_ARCH}
 WRKOBJDIR?=     /usr/tmp/pkgsrc   # build here instead of in pkgsrc
 BSDSRCDIR=      /usr/src
 BSDXSRCDIR=     /usr/xsrc         # for x11/xservers
 OBJHOSTNAME?=   yes               # use work.`hostname`
 FAILOVER_FETCH= yes               # insist on the correct checksum
 PKG_DEVELOPER?= yes
-_ACCEPTABLE=    yes
+SKIP_LICENSE_CHECK=    yes
 </pre>
 <p>Some options that are especially useful for bulk builds
 	can be found at the top lines of the file
 	<code class="filename">mk/bulk/bsd.bulk-pkg.mk</code>. The most useful
 	options of these are briefly described here.</p>
 <div class="itemizedlist"><ul type="disc">
 <li><p>If you are on a slow machine, you may want to
 	  set <code class="varname">USE_BULK_BROKEN_CHECK</code> to
 	  &#8220;<span class="quote">no</span>&#8221;.</p></li>
 <li><p>If you are doing bulk builds from a read-only
 	  copy of pkgsrc, you have to set <code class="varname">BULKFILESDIR</code>
 	  to the directory where all log files are created. Otherwise the
 	  log files are created in the pkgsrc directory.</p></li>
 @@ -2846,27 +2865,27 @@ fi
 <p><code class="filename">/etc/resolv.conf</code> (for <a href="ftp://ftp.NetBSD.org/pub/pkgsrc/current/pkgsrc/security/smtpd/README.html" target="_top"><code class="filename">security/smtpd</code></a> and mail):</p>
 <pre class="screen"><code class="prompt">#</code> <strong class="userinput"><code>cp /etc/resolv.conf /usr/sandbox/etc</code></strong></pre>
 </li>
 <li>
 <p>Working(!) mail config (hostname, sendmail.cf):</p>
 <pre class="screen"><code class="prompt">#</code> <strong class="userinput"><code>cp /etc/mail/sendmail.cf /usr/sandbox/etc/mail</code></strong></pre>
 </li>
 <li>
 <p><code class="filename">/etc/localtime</code> (for <a href="ftp://ftp.NetBSD.org/pub/pkgsrc/current/pkgsrc/security/smtpd/README.html" target="_top"><code class="filename">security/smtpd</code></a>):</p>
 <pre class="screen"><code class="prompt">#</code> <strong class="userinput"><code>ln -sf /usr/share/zoneinfo/UTC /usr/sandbox/etc/localtime</code></strong></pre>
 </li>
 <li>
 <p><code class="filename">/usr/src</code> (system sources,
-	  e.&nbsp;g. for <a href="ftp://ftp.NetBSD.org/pub/pkgsrc/current/pkgsrc/sysutils/aperture/README.html" target="_top"><code class="filename">sysutils/aperture</code></a>):</p>
+	  e. g. for <a href="ftp://ftp.NetBSD.org/pub/pkgsrc/current/pkgsrc/sysutils/aperture/README.html" target="_top"><code class="filename">sysutils/aperture</code></a>):</p>
 <pre class="screen"><code class="prompt">#</code> <strong class="userinput"><code>ln -s ../disk1/cvs .</code></strong>
 	  <code class="prompt">#</code> <strong class="userinput"><code>ln -s cvs/src-2.0 src</code></strong></pre>
 </li>
 <li>
 <p>Create <code class="filename">/var/db/pkg</code> (not part of default install):</p>
 <pre class="screen"><code class="prompt">#</code> <strong class="userinput"><code>mkdir /usr/sandbox/var/db/pkg</code></strong></pre>
 </li>
 <li>
 <p>Create <code class="filename">/usr/pkg</code> (not part of default install):</p>
 <pre class="screen"><code class="prompt">#</code> <strong class="userinput"><code>mkdir /usr/sandbox/usr/pkg</code></strong></pre>
 </li>
 <li>
 <p>Checkout pkgsrc via cvs into
 @@ -3009,27 +3028,27 @@ nbftp% c
 <a name="bulk.pbulk.prepare"></a>7.4.1. Preparation</h3></div></div></div>
 <p>First, you need to create a pkgsrc installation for the pbulk infrastructure. No matter on which platform you are (even on NetBSD), you should bootstrap into its own directory. Let's take the directory <code class="filename">/usr/pbulk</code> or <code class="filename">$HOME/pbulk</code> for it. This installation will be bootstrapped and all the tools that are required for the bulk build will be installed there.</p>
 <pre class="screen">
 $ <strong class="userinput"><code>cd /usr/pkgsrc</code></strong>
 $ <strong class="userinput"><code>./bootstrap/bootstrap --prefix=/usr/pbulk --varbase=/usr/pbulk/var --workdir=/tmp/pbulk-bootstrap</code></strong>
 $ <strong class="userinput"><code>rm -rf /tmp/pbulk-bootstrap</code></strong>
 </pre>
 <p>Now the basic environment for the pbulk infrastructure is installed. The specific tools are still missing. This is a good time to edit the pkgsrc configuration file <code class="filename">/usr/pbulk/etc/mk.conf</code> to fit your needs. Typical things you might set now are:</p>
 <div class="itemizedlist"><ul type="disc">
 <li><p><code class="literal"><code class="varname">PKG_DEVELOPER</code>=yes</code>, to enable many consistency checks,</p></li>
 <li><p><code class="literal"><code class="varname">WRKOBJDIR</code>=/tmp/pbulk-outer</code>, to keep <code class="filename">/usr/pkgsrc</code> free from any modifications,</p></li>
 <li><p><code class="literal"><code class="varname">DISTDIR</code>=/distfiles</code>, to have only one directory in which all distfiles (for the infrastructure and for the actual packages) are downloaded,</p></li>
 <li><p><code class="literal"><code class="varname">ACCEPTABLE_LICENSES</code>+=...</code>, to select some licenses additional to the usual Free/Open Source licenses that are acceptable to you,</p></li>
-<li><p><code class="literal"><code class="varname">_ACCEPTABLE</code>=yes</code>, to accept all licenses, no matter how restrictive they are.</p></li>
+<li><p><code class="literal"><code class="varname">SKIP_LICENSE_CHECK</code>=yes</code>, to bypass the license checks.</p></li>
 </ul></div>
 <p>Now you are ready to build the rest of the pbulk infrastructure.</p>
 <pre class="screen">
 $ <strong class="userinput"><code>cd pkgtools/pbulk</code></strong>
 $ <strong class="userinput"><code>/usr/pbulk/bin/bmake install</code></strong>
 $ <strong class="userinput"><code>rm -rf /tmp/pbulk-outer</code></strong>
 </pre>
 <p>Now the pbulk infrastructure is built and installed. It still needs to be configured, and after some more preparation, we will be able to start the real bulk build.</p>
 </div>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
 <a name="bulk.pbulk.conf"></a>7.4.2. Configuration</h3></div></div></div>
 <p>TODO; see pkgsrc/doc/HOWTO-pbulk for more information.</p>
 @@ -4574,27 +4593,27 @@ PATCHDIR= ${.CURDIR}/../xemacs/patches
 </div>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
 <a name="components.patches.guidelines"></a>11.3.4. Patching guidelines</h3></div></div></div>
 <p>When fixing a portability issue in the code do not use
       preprocessor magic to check for the current operating system nor
       platform.  Doing so hurts portability to other platforms because
       the OS-specific details are not abstracted appropriately.</p>
 <p>The general rule to follow is: instead of checking for the
       operating system the application is being built on, check for the
       specific <span class="emphasis"><em>features</em></span> you need.  For example,
       instead of assuming that kqueue is available under NetBSD and
       using the <code class="varname">__NetBSD__</code> macro to conditionalize
-      kqueue support, add a check that detects kqueue itself &mdash;
+      kqueue support, add a check that detects kqueue itself &#8212;
       yes, this generally involves patching the
       <span class="command"><strong>configure</strong></span> script.  There is absolutely nothing
       that prevents some OSes from adopting interfaces from other OSes
       (e.g. Linux implementing kqueue), something that the above checks
       cannot take into account.</p>
 <p>Of course, checking for features generally involves more
       work on the developer's side, but the resulting changes are
       cleaner and there are chances they will work on many other
       platforms.  Not to mention that there are higher chances of being
       later integrated into the mainstream sources.  Remember:
       <span class="emphasis"><em>It doesn't work unless it is right!</em></span></p>
 <p>Some typical examples:</p>
 <div class="table">
 @@ -4945,27 +4964,27 @@ correct:
     is using the ``!='' operator, for example: <code class="varname">BACKSLASH!=echo "\\"</code>.</p>
 <p>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, <a class="citerefentry" href="http://netbsd.gw.com/cgi-bin/man-cgi?make+1+NetBSD-current"><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
     it from <a class="citerefentry" href="http://netbsd.gw.com/cgi-bin/man-cgi?sh+1+NetBSD-current"><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>
+<p>No rule without exception&#8212;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 type="disc">
 <li><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><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
 @@ -5367,74 +5386,42 @@ ${PLIST.foo}@dirrm share/bar
 <div class="itemizedlist"><ul type="disc">
 <li><p><code class="filename">PLIST.common</code></p></li>
 <li><p><code class="filename">PLIST.${OPSYS}</code></p></li>
 <li><p><code class="filename">PLIST.${MACHINE_ARCH}</code></p></li>
 <li><p><code class="filename">PLIST.${OPSYS}-${MACHINE_ARCH}</code></p></li>
 <li><p><code class="filename">PLIST.common_end</code></p></li>
 </ul></div>
 </div>
 <div class="sect1" lang="en">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
 <a name="faq.common-dirs"></a>13.8. Sharing directories between packages</h2></div></div></div>
 <p>A &#8220;<span class="quote">shared directory</span>&#8221; is a directory where
     multiple (and unrelated) packages install files.  These
-    directories are problematic because you have to add special tricks
+    directories were problematic because you had to add special
-    in the PLIST to conditionally remove them, or have some
+    tricks in the PLIST to conditionally remove them, or have some
     centralized package handle them.</p>
-<p>Within pkgsrc, you'll find both approaches.  If a directory
+<p>In pkgsrc, it is now easy: Each package should create
-    is shared by a few unrelated packages, it's often not worth to add
+    directories and install files as needed; <span class="command"><strong>pkg_delete</strong></span>
-    an extra package to remove it.  Therefore, one simply does:</p>
+    will remove any directories left empty after uninstalling a
-<pre class="programlisting">
+    package.</p>
-@unexec ${RMDIR} %D/path/to/shared/directory 2&gt;/dev/null || ${TRUE}
+<p>If a package needs an empty directory to work, create
-    </pre>
+    the directory during installation as usual, and also add an
-<p>in the PLISTs of all affected packages, instead of the
+    entry to the PLIST:
-    regular "@dirrm" line.</p>
+    </p>
 <p>However, if the directory is shared across many packages, two
     different solutions are available:</p>
 <div class="orderedlist"><ol type="1">
 <li><p>If the packages have a common dependency, the directory
 	can be removed in that.  For example, see
 	<a href="ftp://ftp.NetBSD.org/pub/pkgsrc/current/pkgsrc/textproc/scrollkeeper/README.html" target="_top"><code class="filename">textproc/scrollkeeper</code></a>, which
 	removes the shared directory
 	<code class="filename">share/omf</code>.</p></li>
 <li><p>If the packages using the directory are not related at
 	all (they have no common dependencies), a *-dirs package is
 	used.</p></li>
 </ol></div>
 <p>From now on, we'll discuss the second solution.  To get an
     idea of the *-dirs packages available, issue:</p>
 <pre class="programlisting">
 <code class="prompt">%</code> cd .../pkgsrc
 <code class="prompt">%</code> ls -d */*-dirs
     </pre>
 <p>Their use from other packages is very simple.  The
     <code class="varname">USE_DIRS</code> variable takes a list of package names
     (without the &#8220;<span class="quote">-dirs</span>&#8221; part) together with the required
     version number (always pick the latest one when writing new
     packages).</p>
 <p>For example, if a package installs files under
     <code class="filename">share/applications</code>, it should have the
     following line in it:</p>
 <pre class="programlisting">
-USE_DIRS+=      xdg-1.1
+@pkgdir path/to/empty/directory
     </pre>
-<p>After regenerating the PLIST using <span class="command"><strong>make
+<p>
-    print-PLIST</strong></span>, you should get the right (commented out)
+    </p>
     lines.</p>
 <p>Note that even if your package is using
     <code class="filename">$X11BASE</code>, it must not depend on the
     *-x11-dirs packages.  Just specify the name without that part and
     pkgsrc (in particular, <code class="filename">mk/dirs.mk</code>) will take
     care of it.</p>
 </div>
 </div>
 <div class="chapter" lang="en">
 <div class="titlepage"><div><div><h2 class="title">
 <a name="buildlink"></a>Chapter 14. Buildlink methodology</h2></div></div></div>
 <div class="toc">
 <p><b>Table of Contents</b></p>
 <dl>
 <dt><span class="sect1"><a href="#converting-to-buildlink3">14.1. Converting packages to use buildlink3</a></span></dt>
 <dt><span class="sect1"><a href="#creating-buildlink3.mk">14.2. Writing buildlink3.mk files</a></span></dt>
 <dd><dl>
 <dt><span class="sect2"><a href="#anatomy-of-bl3">14.2.1. Anatomy of a buildlink3.mk file</a></span></dt>
 <dt><span class="sect2"><a href="#updating-buildlink-depends">14.2.2. Updating BUILDLINK_API_DEPENDS.pkg in buildlink3.mk files</a></span></dt>
 @@ -6773,26 +6760,29 @@ http://www.somewhereelse.com/mirror/some
 </pre>
 <p>When actually fetching the distfiles, each item from
       <code class="varname">MASTER_SITES</code> or
       <code class="varname">SITES.*</code> gets the name of each distfile
       appended to it, without an intermediate slash. Therefore,
       all site values have to end with a slash or other separator
       character. This allows for example to set
       <code class="varname">MASTER_SITES</code> to a URL of a CGI script
       that gets the name of the distfile as a parameter. In this
       case, the definition would look like:</p>
 <pre class="programlisting">
 MASTER_SITES=   http://www.example.com/download.cgi?file=
 </pre>
 <p> The exception to this rule are URLs starting with a dash.
       In that case the URL is taken as is, fetched and the result stored
       under the name of the distfile.</p>
 <p>There are some predefined values for
       <code class="varname">MASTER_SITES</code>, which can be used in
       packages.  The names of the variables should speak for
       themselves.</p>
 <pre class="programlisting">
 ${MASTER_SITE_APACHE}
 ${MASTER_SITE_BACKUP}
 ${MASTER_SITE_CYGWIN}
 ${MASTER_SITE_DEBIAN}
 ${MASTER_SITE_FREEBSD}
 ${MASTER_SITE_FREEBSD_LOCAL}
 ${MASTER_SITE_GENTOO}
 ${MASTER_SITE_GNOME}
 @@ -7627,48 +7617,48 @@ TOOLS_PLATFORM.true?=           true
 <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" summary="Q and A Set">
 <col align="left" width="1%">
 <tbody>
 <tr class="question">
 <td align="left" valign="top">
-<a name="tools.new"></a><a name="id1168230299569"></a><p><b>18.4.1.</b></p>
+<a name="tools.new"></a><a name="id1168230298940"></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="id1168230299577"></a><p><b>18.4.2.</b></p>
+<a name="tools.listall"></a><a name="id1168230298949"></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="id1168230299587"></a><p><b>18.4.3.</b></p>
+<a name="tools.used"></a><a name="id1168230298957"></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>
 @@ -9248,46 +9238,47 @@ PERL5_PACKLIST= ${PERL5_SITEARCH}/auto/P
     <a class="link" href="#mk.conf"><code class="filename">mk.conf</code></a>. This option will copy the scripts
     into <code class="filename">/etc/rc.d</code> when a package is installed, and
     it will automatically remove the scripts when the package is
     deinstalled.</p>
 </div>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
 <a name="tex-packages"></a>19.6.17. Packages installing TeX modules</h3></div></div></div>
 <p>If a package installs TeX packages into the texmf tree,
     the <code class="filename">ls-R</code> database of the tree needs to be
     updated.</p>
 <div class="note" style="margin-left: 0.5in; margin-right: 0.5in;">
 <h3 class="title">Note</h3>
-<p>Except the main TeX packages such as teTeX-texmf,
+<p>Except the main TeX packages such as kpathsea,
     packages should install files
-    into <code class="varname">PKG_LOCALTEXMFPREFIX</code>,
+    into <code class="filename">${PREFIX}/share/texmf-dist</code>,
-    not <code class="varname">PKG_TEXMFPREFIX</code>.</p>
+    not <code class="filename">${PREFIX}/share/texmf</code>.</p>
 </div>
 <div class="orderedlist"><ol type="1">
 <li><p>Include
-      <code class="filename">../../print/teTeX/module.mk</code> instead
+      <code class="filename">../../print/kpathsea/texmf.mk</code>.  This
       of <code class="filename">../../mk/tex.buildlink3.mk</code>.  This
       takes care of rebuilding the <code class="filename">ls-R</code>
       database at installation and deinstallation time.</p></li>
 <li>
 <p>If your package installs files into a texmf
       tree other than the one
-      at <code class="varname">PKG_LOCALTEXMFPREFIX</code>,
+      at <code class="filename">${PREFIX}/share/texmf-dist</code>,
-      set <code class="varname">TEXMFDIRS</code> to the list of all texmf
+      set <code class="varname">TEX_TEXMF_DIRS</code> to the list of all texmf
       trees that need database update.</p>
 <p>If your package also installs font map files that need
       to be registered using <span class="command"><strong>updmap</strong></span>,
-      set <code class="varname">TEX_FONTMAPS</code> to the list of all
+      include <code class="filename">../../print/texlive-tetex/map.mk</code> and
       set <code class="varname">TEX_MAP_FILES</code> and/or
       <code class="varname">TEX_MIXEDMAP_FILES</code> to the list of all
       such font map files.  Then <span class="command"><strong>updmap</strong></span> will
       be run automatically at installation/deinstallation to
       enable/disable font map files for TeX output
       drivers.</p>
 </li>
 <li><p>Make sure that none of <code class="filename">ls-R</code>
       databases are included in <code class="filename">PLIST</code>, as
       they will be removed only by the teTeX-bin package.</p></li>
 </ol></div>
 </div>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
 <a name="emulation-packages"></a>19.6.18. Packages supporting running binaries in
 @@ -9340,46 +9331,33 @@ PERL5_PACKLIST= ${PERL5_SITEARCH}/auto/P
 <li><p>Check the PLIST and remove the entry that refers to the
 	  <code class="filename">share/applications/mimeinfo.cache</code> file.
 	  It will be handled automatically.</p></li>
 </ol></div>
 <p>The best way to verify that the PLIST is correct with
       respect to the last point is to regenerate it using <span class="command"><strong>make
       print-PLIST</strong></span>.</p>
 </div>
 </div>
 <div class="sect1" lang="en">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
 <a name="punting"></a>19.7. Marking packages as having problems</h2></div></div></div>
 <p>In some cases one does not have the time to solve a problem
-  immediately.  There are currently two ways to declare that one knows
+  immediately. In this case, one can plainly mark a package as broken.  For
-  that a package has problems.</p>
+  this, one just sets the variable <code class="varname">BROKEN</code> to the
-<div class="itemizedlist"><ul type="disc">
+  reason why the package is broken (similar to the
-<li><p>The first way is to plainly mark it as broken.  For
+  <code class="varname">RESTRICTED</code> variable).  A user trying to build
-    this, one just sets the variable <code class="varname">BROKEN</code> to the
+  the package will immediately be shown this message, and the build
-    reason why the package is broken (similar to the
+  will not be even tried.</p>
-    <code class="varname">RESTRICTED</code> variable).  A user trying to build
+<p><code class="varname">BROKEN</code> packages are removed from pkgsrc in irregular
     the package will immediately be shown this message, and the build
     will not be even tried.</p></li>
 <li><p>After each pkgsrc freeze period (a time when the
     tree is stabilized and a new pkgsrc branch is cut), the packages
     that were not building in the official branch build on the latest
     NetBSD release will be marked as broken on that branch.  This is
     done by setting the <code class="varname">BROKEN_IN</code> variable to the
     branch name (or appending the branch name to it).  If a user tries
     to build such a package and the build fails, the user gets a
     message that says that the package was broken on the respective
     branch(es).</p></li>
 </ul></div>
 <p>Both types of packages are removed from pkgsrc in irregular
   intervals.</p>
 </div>
 </div>
 <div class="chapter" lang="en">
 <div class="titlepage"><div><div><h2 class="title">
 <a name="debug"></a>Chapter 20. Debugging</h2></div></div></div>
 <p>To check out all the gotchas when building a package, here are
   the steps that I do in order to get a package working.  Please note
   this is basically the same as what was explained in the previous
   sections, only with some debugging aids.</p>
 <div class="itemizedlist"><ul type="disc">
 <li><p>Be sure to set <code class="varname">PKG_DEVELOPER=yes</code> in <a class="link" href="#mk.conf"><code class="filename">mk.conf</code></a>.</p></li>
 <li>
 @@ -9531,28 +9509,34 @@ PERL5_PACKLIST= ${PERL5_SITEARCH}/auto/P
 	cases it's the developer's decision.</p>
 <p>There is a make target that helps in creating proper
   <code class="filename">CHANGES-<em class="replaceable"><code>YYYY</code></em></code> entries:  <span class="command"><strong>make
   changes-entry</strong></span>. It uses the optional <code class="varname">CTYPE</code>
   and <code class="varname">NETBSD_LOGIN_NAME</code> variables. The general
   usage is to first make sure that your <code class="filename">CHANGES-<em class="replaceable"><code>YYYY</code></em></code>
   file is up-to-date (to avoid having to resolve conflicts later-on)
   and then to <span class="command"><strong>cd</strong></span> to the package directory.  For
   package updates, <span class="command"><strong>make changes-entry</strong></span> is enough.
   For new packages, or package moves or removals, set the
   <code class="varname">CTYPE</code> variable on the command line to "Added",
   "Moved", or "Removed".  You can set <code class="varname">NETBSD_LOGIN_NAME</code>
   in <a class="link" href="#mk.conf"><code class="filename">mk.conf</code></a> if your local login name is
-  not the same as your NetBSD login name. Don't forget to commit
+  not the same as your NetBSD login name. The target also automatically
-  the changes to <code class="filename">pkgsrc/doc/CHANGES-<em class="replaceable"><code>YYYY</code></em></code>!</p>
+  removes possibly existing entries for the package in the
   <code class="filename">TODO</code> file. Don't forget to commit
   the changes, e.g. by using <span class="command"><strong>make changes-entry-commit</strong></span>!
   If you are not using a checkout directly from cvs.netbsd.org, but e.g.
   a local copy of the repository, you can set USE_NETBSD_REPO=yes. This
   makes the cvs commands use the main repository.
   </p>
 </div>
 <div class="sect1" lang="en">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
 <a name="committing-importing"></a>21.4. Committing: Importing a package into CVS</h2></div></div></div>
 <p>This section is only of interest for pkgsrc developers with write
   access to the pkgsrc repository. Please remember that cvs
   imports files relative to the current working directory, and that
   the pathname that you
   give the <span class="command"><strong>cvs import</strong></span> command is so that it knows where
   to place the files in the repository.  Newly created packages should be
   imported with a vendor tag of &#8220;<span class="quote">TNF</span>&#8221; and a release tag of
   &#8220;<span class="quote">pkgsrc-base</span>&#8221;, e.g:</p>
 <pre class="programlisting">
 @@ -9701,157 +9685,157 @@ place.
 </dt>
 <dt>22.8. <a href="#devfaq.documentation">Where is the pkgsrc
 	documentation?</a>
 </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" summary="Q and A Set">
 <col align="left" width="1%">
 <tbody>
 <tr class="question">
 <td align="left" valign="top">
-<a name="devfaq.makeflags"></a><a name="id1168230286914"></a><p><b>22.1.</b></p>
+<a name="devfaq.makeflags"></a><a name="id1168230286524"></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-current"><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="id1168230286947"></a><p><b>22.2.</b></p>
+<a name="devfaq.make"></a><a name="id1168230286557"></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-current"><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="id1168230286984"></a><p><b>22.3.</b></p>
+<a name="devfaq.cc"></a><a name="id1168230286595"></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="id1168230287019"></a><p><b>22.4.</b></p>
+<a name="devfaq.bl3flags"></a><a name="id1168230286629"></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="id1168230287037"></a><p><b>22.5.</b></p>
+<a name="devfaq.bl3prefix"></a><a name="id1168230286648"></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 &#8220;<span class="quote">wrapper</span>&#8221; phase and later. To
 	&#8220;<span class="quote">simulate</span>&#8221; 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="id1168230287063"></a><p><b>22.6.</b></p>
+<a name="devfaq.master_sites"></a><a name="id1168230286674"></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-current"><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="id1168230287198"></a><p><b>22.7.</b></p>
+<a name="devfaq.mailinglists"></a><a name="id1168230286741"></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>
 <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-current"><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="id1168230287230"></a><p><b>22.8.</b></p>
+<a name="devfaq.documentation"></a><a name="id1168230286772"></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 type="disc">
 <li><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
 @@ -9879,43 +9863,43 @@ do?
 	documented</span>&#8221;, 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="id1168230287284"></a><p><b>22.9.</b></p>
+<a name="devfaq.too-much-time"></a><a name="id1168230286826"></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 type="disc">
 <li><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
     available, but not yet updated in pkgsrc.</p></li>
 <li><p>Browse <code class="filename">pkgsrc/doc/TODO</code>
-    &mdash; it contains a list of suggested new packages and a list of
+    &#8212; it contains a list of suggested new packages and a list of
     cleanups and enhancements for pkgsrc that would be nice to
     have.</p></li>
 <li><p>Review packages for which review was requested on
     the <a class="ulink" href="http://pkgsrc-wip.sourceforge.net/" target="_top">pkgsrc-wip</a> review
     mailing list.</p></li>
 </ul></div>
 </td>
 </tr>
 </tbody>
 </table>
 </div>
 </div>
 <div class="chapter" lang="en">
 @@ -10413,28 +10397,28 @@ CFLAGS+=                -Wall
 </div>
 <div class="sect1" lang="en">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
 <a name="infr.design.intf"></a>24.5. Designing interfaces for Makefile fragments</h2></div></div></div>
 <p>Most of the <code class="filename">.mk</code> files fall into one
 	of the following classes. Cases where a file falls into more
 	than one class should be avoided as it often leads to subtle
 	bugs.</p>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
 <a name="infr.design.intf.proc"></a>24.5.1. Procedures with parameters</h3></div></div></div>
 <p>In a traditional imperative programming language some of
 	the <code class="filename">.mk</code> files could be described as
-	procedures. They take some input parameters and&mdash;after
+	procedures. They take some input parameters and&#8212;after
-	inclusion&mdash;provide a result in output parameters. Since all
+	inclusion&#8212;provide a result in output parameters. Since all
 	variables in <code class="filename">Makefile</code>s have global scope
 	care must be taken not to use parameter names that have already
 	another meaning. For example, <code class="varname">PKGNAME</code> is a
 	bad choice for a parameter name.</p>
 <p>Procedures are completely evaluated at preprocessing time.
 	That is, when calling a procedure all input parameters must be
 	completely resolvable. For example,
 	<code class="varname">CONFIGURE_ARGS</code> should never be an input
 	parameter since it is very likely that further text will be
 	added after calling the procedure, which would effectively apply
 	the procedure to only a part of the variable. Also, references
 	to other variables wit will be modified after calling the
 	procedure.</p>

 @@ -1587,27 +1587,27 @@ in PKG_PATH.
 After these preparations, installing a package is very easy:
 # pkg_add openoffice2
 # pkg_add kde-3.5.7
 # pkg_add ap2-php5-*
 Note that any prerequisite packages needed to run the package in question will
 be installed, too, assuming they are present where you install from.
 As mentioned above, packages for which vulnerabilities get known are not stored
 in the All subdirectory. They don't get deleted since that could be very
 frustrating if many other packages depend on it. Instead, they are moved to the
 vulnerable subdirectory. So you may need to add this directory to the PKG_PATH
-variable. However, you should run audit-packages regularly, especially after
+variable. However, you should run pkg_admin audit regularly, especially after
 installing new packages, and verify that the vulnerabilities are acceptable for
 your configuration.
 After you've installed packages, be sure to have /usr/pkg/bin and /usr/pkg/sbin
 in your PATH so you can actually start the just installed program.
 .1.3. Deinstalling packages
 To deinstall a package, it does not matter whether it was installed from source
 code or from a binary package. The pkg_delete command does not know it anyway.
 To delete a package, you can just run pkg_delete package-name. The package name
 can be given with or without version number. Wildcards can also be used to
 deinstall a set of packages, for example *emacs*. Be sure to include them in
 @@ -1624,41 +1624,54 @@ jpeg package.
 .1.4. Getting information about installed packages
 The pkg_info shows information about installed packages or binary package
 files.
 .1.5. Checking for security vulnerabilities in installed packages
 The NetBSD Security-Officer and Packages Groups maintain a list of known
 security vulnerabilities to packages which are (or have been) included in
 pkgsrc. The list is available from the NetBSD FTP site at ftp://ftp.NetBSD.org/
 pub/pkgsrc/distfiles/vulnerabilities.
-Through security/audit-packages, this list can be downloaded automatically, and
+Through pkg_admin fetch-pkg-vulnerabilities, this list can be downloaded
-a security audit of all packages installed on a system can take place.
+automatically, and a security audit of all packages installed on a system can
 take place.
 There are two components to security/audit-packages. The first component,
-"download-vulnerability-list", is for downloading the list of vulnerabilities
+There are two components to auditing. The first step, pkg_admin
-from the NetBSD FTP site. The second component, "audit-packages", checks to see
+fetch-pkg-vulnerabilities, is for downloading the list of vulnerabilities from
-if any of your installed packages are vulnerable. If a package is vulnerable,
+the NetBSD FTP site. The second step, pkg_admin audit, checks to see if any of
-you will see output similar to the following:
+your installed packages are vulnerable. If a package is vulnerable, you will
 see output similar to the following:
 Package samba-2.0.9 has a local-root-shell vulnerability, see
     http://www.samba.org/samba/whatsnew/macroexploit.html
-One can set up security/audit-packages to download the vulnerabilities file
+You may wish to have the vulnerabilities file downloaded daily so that it
-daily, and include a package audit in the daily security script. Details on
+remains current. This may be done by adding an appropriate entry to the root
-this are located in the MESSAGE file for security/audit-packages.
+users crontab(5) entry. For example the entry
 # download vulnerabilities file
 3 * * * /usr/sbin/pkg_admin fetch-pkg-vulnerabilities >/dev/null 2>&1
 will update the vulnerability list every day at 3AM. You may wish to do this
 more often than once a day. In addition, you may wish to run the package audit
 from the daily security script. This may be accomplished by adding the
 following line to /etc/security.local:
 /usr/sbin/pkg_admin audit
 .1.6. Finding if newer versions of your installed packages are in pkgsrc
 Install pkgtools/lintpkgsrc and run lintpkgsrc with the "-i" argument to check
 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.
 @@ -1903,29 +1916,31 @@ each variable's intent.
   * MASTER_SITE_OVERRIDE: If set, override the packages' MASTER_SITES with this
     value.
   * MASTER_SITE_BACKUP: Backup location(s) for distribution files and patch
     files if not found locally or in ${MASTER_SITES} or ${PATCH_SITES}
     respectively. The defaults are ftp://ftp.NetBSD.org/pub/NetBSD/packages/
     distfiles/${DIST_SUBDIR}/ and ftp://ftp.freebsd.org/pub/FreeBSD/distfiles/$
     {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. Whenever you try to build
+  * ACCEPTABLE_LICENSES: List of acceptable licenses. License names are
-    a package whose license is not in this list, you will get an error message
+    case-sensitive. Whenever you try to build a package whose license is not in
-    that includes instructions on how to change this variable.
+    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
 @@ -2260,36 +2275,36 @@ There are two ways of doing a bulk build
 The build.conf file is the main configuration file for bulk builds. You can
 configure how your copy of pkgsrc is kept up to date, how the distfiles are
 downloaded, how the packages are built and how the report is generated. You can
 find an annotated example file in pkgsrc/mk/bulk/build.conf-example. To use it,
 copy build.conf-example to build.conf and edit it, following the comments in
 that file.
 .3.1.2. mk.conf
 You may want to set variables in mk.conf. Look at pkgsrc/mk/defaults/mk.conf
 for details of the default settings. You will want to ensure that
 ACCEPTABLE_LICENSES meet your local policy. As used in this example,
-_ACCEPTABLE=yes completely bypasses the license check.
+SKIP_LICENSE_CHECK=yes completely bypasses the license check.
 PACKAGES?=      ${_PKGSRCDIR}/packages/${MACHINE_ARCH}
 WRKOBJDIR?=     /usr/tmp/pkgsrc   # build here instead of in pkgsrc
 BSDSRCDIR=      /usr/src
 BSDXSRCDIR=     /usr/xsrc         # for x11/xservers
 OBJHOSTNAME?=   yes               # use work.`hostname`
 FAILOVER_FETCH= yes               # insist on the correct checksum
 PKG_DEVELOPER?= yes
-_ACCEPTABLE=    yes
+SKIP_LICENSE_CHECK=    yes
 Some options that are especially useful for bulk builds can be found at the top
 lines of the file mk/bulk/bsd.bulk-pkg.mk. The most useful options of these are
 briefly described here.
   * If you are on a slow machine, you may want to set USE_BULK_BROKEN_CHECK to
     "no".
   * If you are doing bulk builds from a read-only copy of pkgsrc, you have to
     set BULKFILESDIR to the directory where all log files are created.
     Otherwise the log files are created in the pkgsrc directory.
   * Another important variable is BULK_PREREQ, which is a list of packages that
 @@ -2627,28 +2642,27 @@ configuration file /usr/pbulk/etc/mk.con
 might set now are:
   * PKG_DEVELOPER=yes, to enable many consistency checks,
   * WRKOBJDIR=/tmp/pbulk-outer, to keep /usr/pkgsrc free from any
     modifications,
   * DISTDIR=/distfiles, to have only one directory in which all distfiles (for
     the infrastructure and for the actual packages) are downloaded,
   * ACCEPTABLE_LICENSES+=..., to select some licenses additional to the usual
     Free/Open Source licenses that are acceptable to you,
-  * _ACCEPTABLE=yes, to accept all licenses, no matter how restrictive they
+  * SKIP_LICENSE_CHECK=yes, to bypass the license checks.
     are.
 Now you are ready to build the rest of the pbulk infrastructure.
 $ cd pkgtools/pbulk
 $ /usr/pbulk/bin/bmake install
 $ rm -rf /tmp/pbulk-outer
 Now the pbulk infrastructure is built and installed. It still needs to be
 configured, and after some more preparation, we will be able to start the real
 bulk build.
 .4.2. Configuration
 @@ -4619,72 +4633,39 @@ following files:
   * PLIST.common
   * PLIST.${OPSYS}
   * PLIST.${MACHINE_ARCH}
   * PLIST.${OPSYS}-${MACHINE_ARCH}
   * PLIST.common_end
 .8. Sharing directories between packages
 A "shared directory" is a directory where multiple (and unrelated) packages
-install files. These directories are problematic because you have to add
+install files. These directories were problematic because you had to add
 special tricks in the PLIST to conditionally remove them, or have some
 centralized package handle them.
-Within pkgsrc, you'll find both approaches. If a directory is shared by a few
+In pkgsrc, it is now easy: Each package should create directories and install
-unrelated packages, it's often not worth to add an extra package to remove it.
+files as needed; pkg_delete will remove any directories left empty after
-Therefore, one simply does:
+uninstalling a package.
 @unexec ${RMDIR} %D/path/to/shared/directory 2>/dev/null || ${TRUE}
 in the PLISTs of all affected packages, instead of the regular "@dirrm" line.
 However, if the directory is shared across many packages, two different
 solutions are available:
 . If the packages have a common dependency, the directory can be removed in
     that. For example, see textproc/scrollkeeper, which removes the shared
     directory share/omf.
-. If the packages using the directory are not related at all (they have no
+If a package needs an empty directory to work, create the directory during
-    common dependencies), a *-dirs package is used.
+installation as usual, and also add an entry to the PLIST:
-From now on, we'll discuss the second solution. To get an idea of the *-dirs
+@pkgdir path/to/empty/directory
 packages available, issue:
 % cd .../pkgsrc
 % ls -d */*-dirs
 Their use from other packages is very simple. The USE_DIRS variable takes a
 list of package names (without the "-dirs" part) together with the required
 version number (always pick the latest one when writing new packages).
 For example, if a package installs files under share/applications, it should
 have the following line in it:
 USE_DIRS+=      xdg-1.1
 After regenerating the PLIST using make print-PLIST, you should get the right
 (commented out) lines.
 Note that even if your package is using $X11BASE, it must not depend on the
 *-x11-dirs packages. Just specify the name without that part and pkgsrc (in
 particular, mk/dirs.mk) will take care of it.
 Chapter 14. Buildlink methodology
 Table of Contents
 .1. Converting packages to use buildlink3
 .2. Writing buildlink3.mk files
 .2.1. Anatomy of a buildlink3.mk file
 .2.2. Updating BUILDLINK_API_DEPENDS.pkg in buildlink3.mk files
 .3. Writing builtin.mk files
 @@ -5770,26 +5751,29 @@ DISTFILES+=     foo-file.tar.gz
 SITES.foo-file.tar.gz= \
 http://www.somewhere.com/somehow/ \
 http://www.somewhereelse.com/mirror/somehow/
 When actually fetching the distfiles, each item from MASTER_SITES or SITES.*
 gets the name of each distfile appended to it, without an intermediate slash.
 Therefore, all site values have to end with a slash or other separator
 character. This allows for example to set MASTER_SITES to a URL of a CGI script
 that gets the name of the distfile as a parameter. In this case, the definition
 would look like:
 MASTER_SITES=   http://www.example.com/download.cgi?file=
 The exception to this rule are URLs starting with a dash. In that case the URL
 is taken as is, fetched and the result stored under the name of the distfile.
 There are some predefined values for MASTER_SITES, which can be used in
 packages. The names of the variables should speak for themselves.
 ${MASTER_SITE_APACHE}
 ${MASTER_SITE_BACKUP}
 ${MASTER_SITE_CYGWIN}
 ${MASTER_SITE_DEBIAN}
 ${MASTER_SITE_FREEBSD}
 ${MASTER_SITE_FREEBSD_LOCAL}
 ${MASTER_SITE_GENTOO}
 ${MASTER_SITE_GNOME}
 ${MASTER_SITE_GNU}
 ${MASTER_SITE_GNUSTEP}
 @@ -7746,41 +7730,41 @@ since it was released.
 If a package contains a rc.d script, it won't be copied into the startup
 directory by default, but you can enable it, by adding the option
 PKG_RCD_SCRIPTS=YES in mk.conf. This option will copy the scripts into /etc/
 rc.d when a package is installed, and it will automatically remove the scripts
 when the package is deinstalled.
 .6.17. Packages installing TeX modules
 If a package installs TeX packages into the texmf tree, the ls-R database of
 the tree needs to be updated.
 Note
-Except the main TeX packages such as teTeX-texmf, packages should install files
+Except the main TeX packages such as kpathsea, packages should install files
-into PKG_LOCALTEXMFPREFIX, not PKG_TEXMFPREFIX.
+into ${PREFIX}/share/texmf-dist, not ${PREFIX}/share/texmf.
-. Include ../../print/teTeX/module.mk instead of ../../mk/tex.buildlink3.mk.
+. Include ../../print/kpathsea/texmf.mk. This takes care of rebuilding the
-    This takes care of rebuilding the ls-R database at installation and
+    ls-R database at installation and deinstallation time.
     deinstallation time.
-. If your package installs files into a texmf tree other than the one at
+. If your package installs files into a texmf tree other than the one at $
-    PKG_LOCALTEXMFPREFIX, set TEXMFDIRS to the list of all texmf trees that
+    {PREFIX}/share/texmf-dist, set TEX_TEXMF_DIRS to the list of all texmf
-    need database update.
+    trees that need database update.
     If your package also installs font map files that need to be registered
-    using updmap, set TEX_FONTMAPS to the list of all such font map files. Then
+    using updmap, include ../../print/texlive-tetex/map.mk and set
-    updmap will be run automatically at installation/deinstallation to enable/
+    TEX_MAP_FILES and/or TEX_MIXEDMAP_FILES to the list of all such font map
-    disable font map files for TeX output drivers.
+    files. Then updmap will be run automatically at installation/deinstallation
     to enable/disable font map files for TeX output drivers.
 . Make sure that none of ls-R databases are included in PLIST, as they will
     be removed only by the teTeX-bin package.
 .6.18. Packages supporting running binaries in emulation
 There are some packages that provide libraries and executables for running
 binaries from a one operating system on a different one (if the latter supports
 it). One example is running Linux binaries on NetBSD.
 The pkgtools/rpm2pkg helps in extracting and packaging Linux rpm packages.
 The CHECK_SHLIBS can be set to no to avoid the check-shlibs target, which tests
 @@ -7812,43 +7796,33 @@ If a package installs .desktop files und
 MIME information, you need to take extra steps to ensure that they are
 registered into the MIME database:
 . Include ../../sysutils/desktop-file-utils/desktopdb.mk.
 . Check the PLIST and remove the entry that refers to the share/applications/
     mimeinfo.cache file. It will be handled automatically.
 The best way to verify that the PLIST is correct with respect to the last point
 is to regenerate it using make print-PLIST.
 .7. Marking packages as having problems
-In some cases one does not have the time to solve a problem immediately. There
+In some cases one does not have the time to solve a problem immediately. In
-are currently two ways to declare that one knows that a package has problems.
+this case, one can plainly mark a package as broken. For this, one just sets
 the variable BROKEN to the reason why the package is broken (similar to the
-  * The first way is to plainly mark it as broken. For this, one just sets the
+RESTRICTED variable). A user trying to build the package will immediately be
-    variable BROKEN to the reason why the package is broken (similar to the
+shown this message, and the build will not be even tried.
     RESTRICTED variable). A user trying to build the package will immediately
     be shown this message, and the build will not be even tried.
   * After each pkgsrc freeze period (a time when the tree is stabilized and a
     new pkgsrc branch is cut), the packages that were not building in the
     official branch build on the latest NetBSD release will be marked as broken
     on that branch. This is done by setting the BROKEN_IN variable to the
     branch name (or appending the branch name to it). If a user tries to build
     such a package and the build fails, the user gets a message that says that
     the package was broken on the respective branch(es).
-Both types of packages are removed from pkgsrc in irregular intervals.
+BROKEN packages are removed from pkgsrc in irregular intervals.
 Chapter 20. Debugging
 To check out all the gotchas when building a package, here are the steps that I
 do in order to get a package working. Please note this is basically the same as
 what was explained in the previous sections, only with some debugging aids.
   * Be sure to set PKG_DEVELOPER=yes in mk.conf.
   * Install pkgtools/url2pkg, create a directory for a new package, change into
     it, then run url2pkg:
     % mkdir /usr/pkgsrc/category/examplepkg
 @@ -7978,28 +7952,32 @@ case it was mentioned there.
 When the PKGREVISION of a package is bumped, the change should appear in pkgsrc
 /doc/CHANGES-YYYY if it is security related or otherwise relevant. Mass bumps
 that result from a dependency being updated should not be mentioned. In all
 other cases it's the developer's decision.
 There is a make target that helps in creating proper CHANGES-YYYY entries: make
 changes-entry. It uses the optional CTYPE and NETBSD_LOGIN_NAME variables. The
 general usage is to first make sure that your CHANGES-YYYY file is up-to-date
 (to avoid having to resolve conflicts later-on) and then to cd to the package
 directory. For package updates, make changes-entry is enough. For new packages,
 or package moves or removals, set the CTYPE variable on the command line to
 "Added", "Moved", or "Removed". You can set NETBSD_LOGIN_NAME in mk.conf if
-your local login name is not the same as your NetBSD login name. Don't forget
+your local login name is not the same as your NetBSD login name. The target
-to commit the changes to pkgsrc/doc/CHANGES-YYYY!
+also automatically removes possibly existing entries for the package in the
 TODO file. Don't forget to commit the changes, e.g. by using make
 changes-entry-commit! If you are not using a checkout directly from
 cvs.netbsd.org, but e.g. a local copy of the repository, you can set
 USE_NETBSD_REPO=yes. This makes the cvs commands use the main repository.
 .4. Committing: Importing a package into CVS
 This section is only of interest for pkgsrc developers with write access to the
 pkgsrc repository. Please remember that cvs imports files relative to the
 current working directory, and that the pathname that you give the cvs import
 command is so that it knows where to place the files in the repository. Newly
 created packages should be imported with a vendor tag of "TNF" and a release
 tag of "pkgsrc-base", e.g:
 $ cd .../pkgsrc/category/pkgname
 $ cvs import pkgsrc/category/pkgname TNF pkgsrc-base