 @@ -1651,61 +1651,54 @@ and you can still use binary packages fr
     operating system already provides those tools. Download the file and
     extract it in the <code class="filename">/</code> directory. It will create
     the directories <code class="filename">/usr/pkg</code> (containing the tools
     for managing binary packages) and <code class="filename">/var/db/pkg</code>
     (the database of installed packages).</p>
 </div>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
 <a name="installing-binary-packages"></a>4.1.2. Installing binary packages</h3></div></div></div>
 <p>In the directory from the last section, there is a
     subdirectory called <code class="filename">All</code>, which contains all the
     binary packages that are available for the platform, excluding those
     that may not be distributed via FTP or CDROM (depending on which
-    medium you are using), and the ones that have vulnerabilities and
+    medium you are using). There may be an extra directory for packages
-    therefore are considered insecure to install without thinking
+    that have vulnerabilities and therefore are considered insecure to install
-    before.</p>
+    without checking the implications first. This method has been replaced by
     setting CHECK_VULNERABILITIES=yes in pkg_install.conf so pkg_add will
     complain about vulnerabilities, instead.</p>
 <p>To install packages directly from an FTP or HTTP server, run
     the following commands in a Bourne-compatible shell (be sure to
     <span class="command"><strong>su</strong></span> to root first):</p>
 <pre class="screen">
 <code class="prompt">#</code> <strong class="userinput"><code>PATH="/usr/pkg/sbin:$PATH"</code></strong>
 <code class="prompt">#</code> <strong class="userinput"><code>PKG_PATH="ftp://ftp.NetBSD.org/pub/pkgsrc/packages/<em class="replaceable"><code>OPSYS</code></em>/<em class="replaceable"><code>ARCH</code></em>/<em class="replaceable"><code>VERSIONS</code></em>/All"</code></strong>
 <code class="prompt">#</code> <strong class="userinput"><code>export PATH PKG_PATH</code></strong>
 </pre>
 <p>Instead of URLs, you can also use local paths, for example if
     you are installing from a set of CDROMs, DVDs or an NFS-mounted
     repository. If you want to install packages from multiple sources,
     you can separate them by a semicolon in
     <code class="varname">PKG_PATH</code>.</p>
 <p>After these preparations, installing a package is very
     easy:</p>
 <pre class="screen">
 <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>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.
     To delete a package, you can just run <span class="command"><strong>pkg_delete
     <em class="replaceable"><code>package-name</code></em></strong></span>. The package
 @@ -2606,29 +2599,27 @@ SKIP_LICENSE_CHECK=    yes
 	  to the directory where all log files are created. Otherwise the
 	  log files are created in the pkgsrc directory.</p></li>
 <li><p>Another important variable is
 	  <code class="varname">BULK_PREREQ</code>, which is a list of packages that
 	  should be always available while building other
 	  packages.</p></li>
 </ul></div>
 <p>Some other options are scattered in the pkgsrc
 	infrastructure:</p>
 <div class="itemizedlist"><ul type="disc">
 <li><p><code class="varname">ALLOW_VULNERABLE_PACKAGES</code>
 	  should be set to <code class="literal">yes</code>. The purpose of the bulk
 	  builds is creating binary packages, no matter if they are
-	  vulnerable or not. When uploading the packages to a public
+	  vulnerable or not. Leaving this variable unset would prevent the bulk
 	  server, the vulnerable packages will be put into a directory of
 	  their own. Leaving this variable unset would prevent the bulk
 	  build system from even trying to build them, so possible
 	  building errors would not show up.</p></li>
 <li><p><code class="varname">CHECK_FILES</code>
 	  (<code class="filename">pkgsrc/mk/check/check-files.mk</code>) can be set to
 	  &#8220;<span class="quote">yes</span>&#8221; to check that the installed set of files
 	  matches the <code class="filename">PLIST</code>.</p></li>
 <li><p><code class="varname">CHECK_INTERPRETER</code>
 	  (<code class="filename">pkgsrc/mk/check/check-interpreter.mk</code>) can be set to
 	  &#8220;<span class="quote">yes</span>&#8221; to check that the installed
 	  &#8220;<span class="quote">#!</span>&#8221;-scripts will find their
 	  interpreter.</p></li>
 <li><p><code class="varname">PKGSRC_RUN_TEST</code> can be
 	  set to &#8220;<span class="quote"><code class="literal">yes</code></span>&#8221; to run each
 @@ -2922,29 +2913,27 @@ chroot-#
 <p>Next, test if your ssh connection really works:</p>
 <pre class="screen">chroot-<code class="prompt">#</code> <strong class="userinput"><code>ssh ftp.NetBSD.org date</code></strong> </pre>
 <p>Use "-l yourNetBSDlogin" here as appropriate!</p>
 <p>Now after all this works, you can exit the sandbox and start
       the upload:</p>
 <pre class="screen">
 chroot-<code class="prompt">#</code> <strong class="userinput"><code>exit</code></strong>
 <code class="prompt">#</code> <strong class="userinput"><code>cd /usr/sandbox/usr/pkgsrc</code></strong>
 <code class="prompt">#</code> <strong class="userinput"><code>sh mk/bulk/do-sandbox-upload</code></strong>
       </pre>
 <p>The upload process may take quite some time. Use <a class="citerefentry" href="http://netbsd.gw.com/cgi-bin/man-cgi?ls+1+NetBSD-current"><span class="citerefentry"><span class="refentrytitle">ls</span>(1)</span></a> or
       <a class="citerefentry" href="http://netbsd.gw.com/cgi-bin/man-cgi?du+1+NetBSD-current"><span class="citerefentry"><span class="refentrytitle">du</span>(1)</span></a> on the FTP server to monitor progress of the
       upload. The upload script will take care of not uploading
-      restricted packages and putting vulnerable packages into the
+      restricted packages.</p>
       <code class="filename">vulnerable</code> subdirectory.</p>
 <p>After the upload has ended, first thing is to revoke ssh access:</p>
 <pre class="screen">nbftp% <strong class="userinput"><code>vi ~/.ssh/authorized_keys</code></strong>
       Gdd:x! </pre>
 <p>Use whatever is needed to remove the key you've entered
       before! Last, move the uploaded packages out of the
       <code class="filename">upload</code> directory to have them accessible
       to everyone:</p>
 <pre class="screen">
 nbftp% <strong class="userinput"><code>cd /pub/NetBSD/packages/packages-20xxQy/NetBSD-a.b.c/arch</code></strong>
 nbftp% <strong class="userinput"><code>mv upload/* .</code></strong>
 nbftp% <strong class="userinput"><code>rmdir upload</code></strong>
 nbftp% <strong class="userinput"><code>chmod 755 .</code></strong>
       </pre>
 </div>

 @@ -1482,58 +1482,53 @@ pkgsrc.
 In this directory, you often find a file called bootstrap.tar.gz which contains
 the package management tools. If the file is missing, it is likely that your
 operating system already provides those tools. Download the file and extract it
 in the / directory. It will create the directories /usr/pkg (containing the
 tools for managing binary packages) and /var/db/pkg (the database of installed
 packages).
 .1.2. Installing binary packages
 In the directory from the last section, there is a subdirectory called All,
 which contains all the binary packages that are available for the platform,
 excluding those that may not be distributed via FTP or CDROM (depending on
-which medium you are using), and the ones that have vulnerabilities and
+which medium you are using). There may be an extra directory for packages
-therefore are considered insecure to install without thinking before.
+that have vulnerabilities and therefore are considered insecure to install
 without checking the implications first. This method has been replaced by
 setting CHECK_VULNERABILITIES=yes in pkg_install.conf so pkg_add will
 complain about vulnerabilities, instead.
 To install packages directly from an FTP or HTTP server, run the following
 commands in a Bourne-compatible shell (be sure to su to root first):
 # PATH="/usr/pkg/sbin:$PATH"
 # PKG_PATH="ftp://ftp.NetBSD.org/pub/pkgsrc/packages/OPSYS/ARCH/VERSIONS/All"
 # export PATH PKG_PATH
 Instead of URLs, you can also use local paths, for example if you are
 installing from a set of CDROMs, DVDs or an NFS-mounted repository. If you want
 to install packages from multiple sources, you can separate them by a semicolon
 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 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
 quotes, so that the shell does not expand them before pkg_delete sees them.
 The -r option is very powerful: it removes all the packages that require the
 @@ -2227,30 +2222,29 @@ briefly described here.
     "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
     should be always available while building other packages.
 Some other options are scattered in the pkgsrc infrastructure:
   * ALLOW_VULNERABLE_PACKAGES should be set to yes. The purpose of the bulk
     builds is creating binary packages, no matter if they are vulnerable or
-    not. When uploading the packages to a public server, the vulnerable
+    not. Leaving this variable unset would prevent the bulk build system
-    packages will be put into a directory of their own. Leaving this variable
+    from even trying to build them, so possible building errors would not
-    unset would prevent the bulk build system from even trying to build them,
+    show up.
     so possible building errors would not show up.
   * CHECK_FILES (pkgsrc/mk/check/check-files.mk) can be set to "yes" to check
     that the installed set of files matches the PLIST.
   * CHECK_INTERPRETER (pkgsrc/mk/check/check-interpreter.mk) can be set to
     "yes" to check that the installed "#!"-scripts will find their interpreter.
   * PKGSRC_RUN_TEST can be set to "yes" to run each package's self-test before
     installing it. Note that some packages make heavy use of "good" random
     numbers, so you need to assure that the machine on which you are doing the
     bulk builds is not completely idle. Otherwise some test programs will seem
     to hang, while they are just waiting for new random data to be available.
 @@ -2510,28 +2504,27 @@ Next, test if your ssh connection really
 chroot-# ssh ftp.NetBSD.org date
 Use "-l yourNetBSDlogin" here as appropriate!
 Now after all this works, you can exit the sandbox and start the upload:
 chroot-# exit
 # cd /usr/sandbox/usr/pkgsrc
 # sh mk/bulk/do-sandbox-upload
 The upload process may take quite some time. Use ls(1) or du(1) on the FTP
 server to monitor progress of the upload. The upload script will take care of
-not uploading restricted packages and putting vulnerable packages into the
+not uploading restricted packages.
 vulnerable subdirectory.
 After the upload has ended, first thing is to revoke ssh access:
 nbftp% vi ~/.ssh/authorized_keys
       Gdd:x!
 Use whatever is needed to remove the key you've entered before! Last, move the
 uploaded packages out of the upload directory to have them accessible to
 everyone:
 nbftp% cd /pub/NetBSD/packages/packages-20xxQy/NetBSD-a.b.c/arch
 nbftp% mv upload/* .
 nbftp% rmdir upload