Regenerate.

Various changes to pkgsrc guide since this was last generated
in early August.

1 files changed, 172 insertions, 154 deletions

diff --git a/doc/pkgsrc.txt b/doc/pkgsrc.txt
index 18d979b9921..b11e015ebc0 100644
--- a/doc/pkgsrc.txt
+++ b/doc/pkgsrc.txt
@@ -44,7 +44,7 @@ I. The pkgsrc user's guide
     3. Using pkgsrc on systems other than NetBSD
 
         3.1. Bootstrapping pkgsrc
-        3.2. Platform specific notes
+        3.2. Platform-specific notes
 
             3.2.1. Darwin (Mac OS X)
             3.2.2. FreeBSD
@@ -87,7 +87,7 @@ I. The pkgsrc user's guide
             6.3.3. Operation
             6.3.4. What it does
             6.3.5. Disk space requirements
-            6.3.6. Setting up a sandbox for chroot'ed builds
+            6.3.6. Setting up a sandbox for chrooted builds
             6.3.7. Building a partial set of packages
             6.3.8. Uploading results of a bulk build
 
@@ -146,9 +146,9 @@ II. The pkgsrc developer's guide
         10.2. Semi-automatic PLIST generation
         10.3. Tweaking output of make print-PLIST
         10.4. Variable substitution in PLIST
-        10.5. Manpage-compression
+        10.5. Man page-compression
         10.6. Changing PLIST source with PLIST_SRC
-        10.7. Platform specific and differing PLISTs
+        10.7. Platform-specific and differing PLISTs
         10.8. Sharing directories between packages
 
     11. Buildlink methodology
@@ -174,7 +174,7 @@ II. The pkgsrc developer's guide
         12.2. Configuration files
 
             12.2.1. How PKG_SYSCONFDIR is set
-            12.2.2. Telling the software were configuration files are
+            12.2.2. Telling the software where configuration files are
             12.2.3. Patching installations
             12.2.4. Disabling handling of configuration files
 
@@ -293,7 +293,7 @@ Table of Contents
 
 1.1. Introduction
 
-There is a lot of software freely available for Unix based systems, which
+There is a lot of software freely available for Unix-based systems, which
 usually runs on NetBSD and other Unix-flavoured systems, too, sometimes with
 some modifications. The NetBSD Packages Collection (pkgsrc) incorporates any
 such changes necessary to make that software run, and makes the installation
@@ -407,7 +407,7 @@ Precompiled/binary package
 Program
 
     The piece of software to be installed which will be constructed from all
-    the files in the Distfile by the actions defined in the corresponding
+    the files in the distfile by the actions defined in the corresponding
     package.
 
 1.4. Typography
@@ -430,7 +430,7 @@ Table of Contents
 3. Using pkgsrc on systems other than NetBSD
 
     3.1. Bootstrapping pkgsrc
-    3.2. Platform specific notes
+    3.2. Platform-specific notes
 
         3.2.1. Darwin (Mac OS X)
         3.2.2. FreeBSD
@@ -473,7 +473,7 @@ Table of Contents
         6.3.3. Operation
         6.3.4. What it does
         6.3.5. Disk space requirements
-        6.3.6. Setting up a sandbox for chroot'ed builds
+        6.3.6. Setting up a sandbox for chrooted builds
         6.3.7. Building a partial set of packages
         6.3.8. Uploading results of a bulk build
 
@@ -551,7 +551,7 @@ Chapter 3. Using pkgsrc on systems other than NetBSD
 Table of Contents
 
 3.1. Bootstrapping pkgsrc
-3.2. Platform specific notes
+3.2. Platform-specific notes
 
     3.2.1. Darwin (Mac OS X)
     3.2.2. FreeBSD
@@ -604,7 +604,12 @@ Binary packages for the pkgsrc tools and an initial set of packages is
 available for supported platforms. An up-to-date list of these can be found on
 www.pkgsrc.org.
 
-3.2. Platform specific notes
+Note
+
+The bootstrap installs a bmake tool. Use this bmake when building via pkgsrc.
+For examples in this guide, use bmake instead of "make".
+
+3.2. Platform-specific notes
 
 Here are some platform-specific notes you should be aware of.
 
@@ -627,7 +632,7 @@ manually mount a disk image.
 Note
 
 You cannot use a HFS+ file system for pkgsrc, because pkgsrc currently requires
-the filesystem to be case-sensitive, and HFS+ is not.
+the file system to be case-sensitive, and HFS+ is not.
 
 3.2.1.1. Using a disk image
 
@@ -698,7 +703,7 @@ with the FreeBSD userland tools. There are several steps:
 
 3.2.3. Interix
 
-Interix is a POSIX compatible subsystem for the Windows NT kernel, providing a
+Interix is a POSIX-compatible subsystem for the Windows NT kernel, providing a
 Unix-like environment with a tighter kernel integration than available with
 Cygwin. It is part of the Windows Services for Unix package, available for free
 for any licensed copy of Windows 2000, XP (not including XP Home), or 2003. SFU
@@ -744,7 +749,7 @@ pkgsrc, note the following things.
     Services for UNIX, then click Change. In the installer, choose Add or
     Remove, then uncheck Utilities->UNIX Perl.
 
-  * To enable case-sensitivity for the filesystem, run REGEDIT.EXE, and change
+  * To enable case-sensitivity for the file system, run REGEDIT.EXE, and change
     the following registry key:
 
     HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\kernel
@@ -805,8 +810,8 @@ compiler.defaults!
 
 If you have the actual pkgsrc tree mounted via NFS from a different host,
 please make sure to set WRKOBJDIR to a local directory, as it appears that IRIX
-linker occasionally runs into issues when trying to link over a network mounted
-filesystem.
+linker occasionally runs into issues when trying to link over a network-mounted
+file system.
 
 The bootstrapping process should set all the right options for programs such as
 imake(1), but you may want to set some options depending on your local setup.
@@ -892,7 +897,7 @@ with the OpenBSD userland tools. There are several steps:
 
  3. An example /etc/mk.conf file will be placed in /etc/mk.conf.example file
     when you use the bootstrap script. OpenBSD's make program uses /etc/mk.conf
-    as well. You can work around this by enclosing all the pkgsrc specific
+    as well. You can work around this by enclosing all the pkgsrc-specific
     parts of the file with:
 
     .ifdef BSD_PKG_MK
@@ -946,18 +951,19 @@ You will need at least the following packages installed (from WorkShop 5.0)
 
   * SPROlang - Sun WorkShop Compilers common components
 
-You should set CC, CXX and optionally, CPP in /etc/mk.conf, eg.
+You should set CC, CXX and optionally, CPP in /etc/mk.conf, e.g.:
 
 CC=     cc
 CXX=    CC
 CPP=    /usr/ccs/lib/cpp
 
-You may also want to build 64-bit binaries, eg.
+You may also want to build 64-bit binaries, e.g.:
 
 CFLAGS= -xtarget=ultra -xarch=v9
 
 Whichever compiler you use, please ensure the compiler tools and your $prefix
-are in your PATH. This includes /usr/ccs/{bin,lib} and eg. /usr/pkg/{bin,sbin}.
+are in your PATH. This includes /usr/ccs/{bin,lib} and e.g. /usr/pkg/
+{bin,sbin}.
 
 Chapter 4. Using pkgsrc
 
@@ -991,13 +997,13 @@ subdirectory All which includes the actual binaries in .tgz files. The category
 subdirectories use symbolic links to those files (this is the same directory
 layout as in /usr/pkgsrc/packages).
 
-This same directory layout applies for CDROM distributions, only that the
+This same directory layout applies for CD-ROM distributions, only that the
 directory may be rooted somewhere else, probably somewhere below /cdrom. Please
-consult your CDROMs documentation for the exact location.
+consult your CD-ROMs documentation for the exact location.
 
 4.1.2. How to use binary packages
 
-If you have the files on a CDROM or downloaded them to your hard disk, you can
+If you have the files on a CD-ROM or downloaded them to your hard disk, you can
 install them with the following command (be sure to su to root first):
 
 # pkg_add /path/to/package.tgz
@@ -1012,19 +1018,18 @@ Note that any prerequisite packages needed to run the package in question will
 be installed, too, assuming they are present where you install from.
 
 To save some typing, you can set the PKG_PATH environment variable to a
-semicolon separated list of paths (including remote URLs); trailing slashes are
+semicolon-separated list of paths (including remote URLs); trailing slashes are
 not allowed.
 
 Additionally to the All directory there exists a vulnerable directory to which
 binary packages with known vulnerabilities are moved, since removing them could
 cause missing dependencies. To use these packages, add the vulnerable directory
 to your PKG_PATH. However, you should run security/audit-packages regularly,
-and especially after installing new packages, and verify that the
-vulnerabilities are acceptable for your configuration. An example PKG_PATH
-would be: ftp://ftp.NetBSD.org/pub/NetBSD/packages/<OSVERSION>/<ARCH>/All;ftp:/
-/ftp.NetBSD.org/pub/NetBSD/packages/<OSVERSION>/<ARCH>/vulnerable Please note
-that semicolon (';') is a shell meta-character, so you'll probably have to
-quote it.
+especially after installing new packages, and verify that the vulnerabilities
+are acceptable for your configuration. An example PKG_PATH would be: ftp://
+ftp.NetBSD.org/pub/NetBSD/packages/<OSVERSION>/<ARCH>/All;ftp://ftp.NetBSD.org/
+pub/NetBSD/packages/<OSVERSION>/<ARCH>/vulnerable Please note that semicolon
+(';') is a shell meta-character, so you'll probably have to quote it.
 
 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.
@@ -1045,7 +1050,7 @@ packages.
 4.2.1. Requirements
 
 To build packages from source on a NetBSD system the "comp" and the "text"
-distribution sets must be installed. If you want to build X11 related packages
+distribution sets must be installed. If you want to build X11-related packages
 the "xbase" and "xcomp" distribution sets are required, too.
 
 4.2.2. Fetching distfiles
@@ -1070,7 +1075,14 @@ distfiles into /usr/pkgsrc/distfiles.
 4.2.3. How to build and install
 
 Assuming that the distfile has been fetched (see previous section), become root
-and change into the relevant directory and running make. For example, type
+and change into the relevant directory and run make.
+
+Note
+
+If using bootstrap or pkgsrc on a non-NetBSD system, use the pkgsrc bmake
+command instead of "make" in the examples in this guide.
+
+For example, type
 
 % cd misc/figlet
 % make
@@ -1092,7 +1104,7 @@ pkg. Should this not conform to your tastes, set the LOCALBASE variable in your
 environment, and it will use that value as the root of your packages tree. So,
 to use /usr/local, set LOCALBASE=/usr/local in your environment. Please note
 that you should use a directory which is dedicated to packages and not shared
-with other programs (ie, do not try and use LOCALBASE=/usr). Also, you should
+with other programs (i.e., do not try and use LOCALBASE=/usr). Also, you should
 not try to add any of your own files or directories (such as src/, obj/, or
 pkgsrc/) below the LOCALBASE tree. This is to prevent possible conflicts
 between programs and other files installed by the package system and whatever
@@ -1136,7 +1148,7 @@ BINPKG_SITES, which defaults to ftp.NetBSD.org. Any flags that should be added
 to pkg_add(1) can be put into BIN_INSTALL_FLAGS. See pkgsrc/mk/defaults/mk.conf
 for more details.
 
-A final word of warning: If you setup a system that has a non-standard setting
+A final word of warning: If you set up a system that has a non-standard setting
 for LOCALBASE, be sure to set that before any packages are installed, as you
 can not use several directories for the same purpose. Doing so will result in
 pkgsrc not being able to properly detect your installed packages, and fail
@@ -1187,8 +1199,9 @@ Table of Contents
 
 5.1. General configuration
 
-In this section you can find some variables that apply all pkgsrc packages. The
-preferred method of setting them is by setting them in /etc/mk.conf.
+In this section, you can find some variables that apply to all pkgsrc packages.
+The preferred method of setting these variables is by setting them in /etc/
+mk.conf.
 
   * LOCALBASE: Where packages will be installed. The default is /usr/pkg. Do
     not mix binary packages with different LOCALBASEs!
@@ -1320,7 +1333,7 @@ Table of Contents
     6.3.3. Operation
     6.3.4. What it does
     6.3.5. Disk space requirements
-    6.3.6. Setting up a sandbox for chroot'ed builds
+    6.3.6. Setting up a sandbox for chrooted builds
     6.3.7. Building a partial set of packages
     6.3.8. Uploading results of a bulk build
 
@@ -1331,7 +1344,7 @@ Table of Contents
 6.1. Building a single binary package
 
 Once you have built and installed a package, you can create a binary package
-which can be installed on another system with pkg_add(1) This saves having to
+which can be installed on another system with pkg_add(1). This saves having to
 build the same package on a group of hosts and wasting CPU time. It also
 provides a simple means for others to install your package, should you
 distribute it.
@@ -1393,7 +1406,7 @@ update.
 
 6.3.1.3. pre-build.local
 
-It is possible to configure the bulk build to perform certain site specific
+It is possible to configure the bulk build to perform certain site-specific
 tasks at the end of the pre-build stage. If the file pre-build.local exists in
 /usr/pkgsrc/mk/bulk, it will be executed (as a sh(1) script) at the end of the
 usual pre-build stage. An example use of pre-build.local is to have the line:
@@ -1489,7 +1502,7 @@ demand to disk space. Afterwards, if the package is needed again, it will be
 installed via pkg_add(1) instead of building again, so there are no cycles
 wasted by recompiling.
 
-6.3.6. Setting up a sandbox for chroot'ed builds
+6.3.6. Setting up a sandbox for chrooted builds
 
 If you don't want all the packages nuked from a machine (rendering it useless
 for anything but pkg compiling), there is the possibility of doing the package
@@ -1559,7 +1572,7 @@ src/etc, be sure the following items are present and properly configured:
 13. If you have set CVS_USER in build.conf, make sure that account exists and
     can do a cvs ${CVS_FLAGS} update properly!
 
-When the chroot sandbox is setup, you can start the build with the following
+When the chroot sandbox is set up, you can start the build with the following
 steps:
 
 # cd /usr/sandbox/usr/pkgsrc
@@ -1574,7 +1587,7 @@ from).
 
 In addition to building a complete set of all packages in pkgsrc, the pkgsrc/mk
 /bulk/build script may be used to build a subset of the packages contained in
-pkgsrc. By setting defining SPECIFIC_PKGS in /etc/mk.conf, the variables
+pkgsrc. By setting SPECIFIC_PKGS in /etc/mk.conf, the variables
 
   * SITE_SPECIFIC_PKGS
 
@@ -1611,7 +1624,7 @@ file, i.e. adjust it to something like one of the following:
 
 RSYNC_DST=$CVS_USER@ftp.NetBSD.org:/pub/NetBSD/packages/pkgsrc-200xQy/NetBSD-a.b.c/arch/upload
 
-Please use appropviate values for "pkgsrc-200xQy", "NetBSD-a.b.c" and "arch"
+Please use appropriate values for "pkgsrc-200xQy", "NetBSD-a.b.c" and "arch"
 here. If your login on ftp.NetBSD.org is different from CVS_USER, write your
 login directly into the variable, e.g. my local account is "feyrer", but for my
 login "hubertf", I use:
@@ -1628,7 +1641,7 @@ NetBSD operating system. Binary packages for other operating systems should go
 into /pub/pkgsrc.
 
 Before uploading the binary pkgs, ssh authentication needs to be set up. This
-example shows how to setup temporary keys for the root account inside the
+example shows how to set up temporary keys for the root account inside the
 sandbox (assuming that no keys should be present there usually):
 
 # chroot /usr/sandbox
@@ -1676,11 +1689,11 @@ After your pkgsrc bulk-build has completed, you may wish to create a CD-ROM set
 of the resulting binary packages to assist in installing packages on other
 machines. The pkgtools/cdpack package provides a simple tool for creating the
 ISO 9660 images. cdpack arranges the packages on the CD-ROMs in a way that
-keeps all the dependencies for given package on the same CD as that package.
+keeps all the dependencies for a given package on the same CD as that package.
 
 6.4.1. Example of cdpack
 
-Complete documentation for cdpack is found in the cdpack(1) manpage. The
+Complete documentation for cdpack is found in the cdpack(1) man page. The
 following short example assumes that the binary packages are left in /usr/
 pkgsrc/packages/All and that sufficient disk space exists in /u2 to hold the
 ISO 9660 images.
@@ -1819,10 +1832,7 @@ Utilities for people maintaining or creating individual packages:
 
   * pkgtools/gensolpkg: Convert pkgsrc to a Solaris package.
 
-Utilities for people maintaining pkgsrc (or more obscure pkg utilities)
-
-  * pkgtools/pkgconflict: Find packages that conflict but aren't marked as
-    such.
+Utilities for people maintaining pkgsrc (or: more obscure pkg utilities)
 
   * pkgtools/pkg_comp: Build packages in a chrooted area.
 
@@ -1848,7 +1858,7 @@ the script, as well as some others that allow finer tuning of the tree layout.
 
 7.5. How to resume transfers when fetching distfiles?
 
-By default resuming transfers in pkgsrc is disabled, but you can enable this
+By default, resuming transfers in pkgsrc is disabled, but you can enable this
 feature by adding the option PKG_RESUME_TRANSFERS=YES into /etc/mk.conf. If,
 during a fetch step, an incomplete distfile is found, pkgsrc will try to resume
 it.
@@ -1885,7 +1895,7 @@ X11_TYPE=xorg
 
 If you are sitting behind a firewall which does not allow direct connections to
 Internet hosts (i.e. non-NAT), you may specify the relevant proxy hosts. This
-is done using an environment variable in the form of a URL e.g. in Amdahl, the
+is done using an environment variable in the form of a URL, e.g. in Amdahl, the
 machine "orpheus.amdahl.com" is one of the firewalls, and it uses port 80 as
 the proxy port number. So the proxy environment variables are:
 
@@ -1915,7 +1925,7 @@ You would like to download all the distfiles in a single batch from work or
 university, where you can't run a make fetch. There is an archive of distfiles
 on ftp.NetBSD.org, but downloading the entire directory may not be appropriate.
 
-The answer here is to do a make fetch-list in /usr/pkgsrc or one of it's
+The answer here is to do a make fetch-list in /usr/pkgsrc or one of its
 subdirectories, carry the resulting list to your machine at work/school and use
 it there. If you don't have a NetBSD-compatible ftp(1) (like lukemftp) at work,
 don't forget to set FETCH_CMD to something that fetches a URL:
@@ -1949,7 +1959,7 @@ everything by running:
 When compiling the pkgtools/pkg_install package, you get the error from make
 that it doesn't know how to make /usr/share/tmac/tmac.andoc? This indicates
 that you don't have installed the "text" set (nroff, ...) from the NetBSD base
-distribution on your machine. It is recommended to do that to format manpages.
+distribution on your machine. It is recommended to do that to format man pages.
 
 In the case of the pkgtools/pkg_install package, you can get away with setting
 NOMAN=YES either in the environment or in /etc/mk.conf.
@@ -1957,7 +1967,7 @@ NOMAN=YES either in the environment or in /etc/mk.conf.
 7.12. What does "Could not find bsd.own.mk" mean?
 
 You didn't install the compiler set, comp.tgz, when you installed your NetBSD
-machine. Please get it and install it, by extracting it in /:
+machine. Please get and install it, by extracting it in /:
 
 # cd /
 # tar --unlink -zxvpf .../comp.tgz
@@ -1995,7 +2005,7 @@ PKG_SYSCONFDIR.${PKG_SYSCONFVAR} variable. PKG_SYSCONFVAR's value usually
 matches the name of the package you would like to modify, that is, the contents
 of PKGBASE.
 
-Note that, after changing these settings, you must rebuild and reinstall any
+Note that after changing these settings, you must rebuild and reinstall any
 affected packages.
 
 7.15. Automated security checks
@@ -2058,9 +2068,9 @@ Table of Contents
     10.2. Semi-automatic PLIST generation
     10.3. Tweaking output of make print-PLIST
     10.4. Variable substitution in PLIST
-    10.5. Manpage-compression
+    10.5. Man page-compression
     10.6. Changing PLIST source with PLIST_SRC
-    10.7. Platform specific and differing PLISTs
+    10.7. Platform-specific and differing PLISTs
     10.8. Sharing directories between packages
 
 11. Buildlink methodology
@@ -2086,7 +2096,7 @@ Table of Contents
     12.2. Configuration files
 
         12.2.1. How PKG_SYSCONFDIR is set
-        12.2.2. Telling the software were configuration files are
+        12.2.2. Telling the software where configuration files are
         12.2.3. Patching installations
         12.2.4. Disabling handling of configuration files
 
@@ -2260,8 +2270,8 @@ exactly in the order given here.
     Note the trailing slash after the subdirectory name.
 
     If the package has multiple DISTFILES or multiple PATCHFILES from different
-    sites, set SITES_foo to a list of URI's where file "foo" may be found.
-    "foo" includes the suffix, e.g.
+    sites, set SITES_foo to a list of URIs where file "foo" may be found. "foo"
+    includes the suffix, e.g.:
 
     DISTFILES=      ${DISTNAME}${EXTRACT_SUFX}
     DISTFILES+=     foo-file.tar.gz
@@ -2281,7 +2291,7 @@ exactly in the order given here.
 The second section contains information about separately downloaded patches, if
 any.
 
-  * PATCHFILES Name(s) of additional files that contain distribution patches.
+  * PATCHFILES: Name(s) of additional files that contain distribution patches.
     There is no default. pkgsrc will look for them at PATCH_SITES. They will
     automatically be uncompressed before patching if the names end with .gz or
     .Z.
@@ -2313,7 +2323,7 @@ Other variables that affect the build:
 
 Please pay attention to the following gotchas:
 
-  * Add MANCOMPRESSED if manpages are installed in compressed form by the
+  * Add MANCOMPRESSED if man pages are installed in compressed form by the
     package; see comment in bsd.pkg.mk.
 
   * Replace /usr/local with "${PREFIX}" in all files (see patches, below).
@@ -2357,7 +2367,7 @@ patch-aa is applied before patch-ab, etc.
 The patch-* files should be in diff -bu format, and apply without a fuzz to
 avoid problems. (To force patches to apply with fuzz you can set
 PATCH_FUZZ_FACTOR=-F2). Furthermore, do not put changes for more than one file
-into a single patch-file, as this will make future modifications more
+into a single patch file, as this will make future modifications more
 difficult.
 
 Similar, a file should be patched at most once, not several times by several
@@ -2392,10 +2402,10 @@ If it is desired to store any patches that should not be committed into pkgsrc,
 they can be kept outside the pkgsrc tree in the $LOCALPATCHES directory. The
 directory tree there is expected to have the same "category/package" structure
 as pkgsrc, and patches are expected to be stored inside these dirs (also known
-as $LOCALPATCHES/$PKGPATH). For example if you want to keep a private patch for
-pkgsrc/graphics/png, keep it in $LOCALPATCHES/graphics/png/mypatch. All files
-in the named directory are expected to be patch files, and they are applied
-after pkgsrc patches are applied.
+as $LOCALPATCHES/$PKGPATH). For example, if you want to keep a private patch
+for pkgsrc/graphics/png, keep it in $LOCALPATCHES/graphics/png/mypatch. All
+files in the named directory are expected to be patch files, and they are
+applied after pkgsrc patches are applied.
 
 8.4. Other mandatory files
 
@@ -2446,7 +2456,7 @@ MESSAGE
 
 8.6. work*
 
-When you type make the distribution files are unpacked into the directory
+When you type make, the distribution files are unpacked into the directory
 denoted by WRKDIR. It can be removed by running make clean. Besides the
 sources, this directory is also used to keep various timestamp files. The
 directory gets removed completely on clean. The default is ${.CURDIR}/work or $
@@ -2518,7 +2528,7 @@ the backslash character ``\'' are handled specially. If a backslash is followed
 by a newline, any whitespace immediately in front of the backslash, the
 backslash, the newline, and any whitespace immediately behind the newline are
 replaced with a single space. A backspace character and an immediately
-following hash character are replaced with a single hash character. Otherwise
+following hash character are replaced with a single hash character. Otherwise,
 the backslash is passed as is. In a variable assignment, any hash character
 that is not preceded by a backslash starts a comment that continues upto the
 end of the logical line.
@@ -2530,13 +2540,13 @@ BACKSLASH!=echo "\\".
 So far for defining variables. The other thing you can do with variables is
 evaluating them. A variable is evaluated when it is part of the right side of
 the ``:='' or the ``!='' operator, or directly before executing a shell command
-which the variable is part of. In all other cases make(1) performs lazy
+which the variable is part of. In all other cases, make(1) performs lazy
 evaluation, that is, variables are not evaluated until there's no other way.
 The ``modifiers'' mentioned in the man page also evaluate the variable.
 
 Some of the modifiers split the string into words and then operate on the
-words, others operate on the string as a whole. When a string is splitted into
-words, it is splitted as you would expect it from sh(1).
+words, others operate on the string as a whole. When a string is split into
+words, it is split as you would expect it from sh(1).
 
 No rule without exception?the .for loop does not follow the shell quoting rules
 but splits at sequences of whitespace.
@@ -2544,12 +2554,12 @@ but splits at sequences of whitespace.
 There are several types of variables that should be handled differently.
 Strings and two types of lists.
 
-  * Strings can contain arbitrary characters. Nevertheless you should restrict
+  * Strings can contain arbitrary characters. Nevertheless, you should restrict
     yourself to only using printable characters. Examples are PREFIX and
     COMMENT.
 
   * Internal lists are lists that are never exported to any shell command.
-    Their elements are separated by whitespace. Therefore the elements
+    Their elements are separated by whitespace. Therefore, the elements
     themselves cannot have embedded whitespace. Any other characters are
     allowed. Internal lists can be used in .for loops. Examples are DEPENDS and
     BUILD_DEPENDS.
@@ -2632,13 +2642,13 @@ depending on the implementation of the echo(1) command.
 
 Example 4 handles correctly every string that does not start with a dash. In
 that case, the result depends on the implementation of the echo(1) command. As
-long as you can guarantee that your input does not start with a dash this form
+long as you can guarantee that your input does not start with a dash, this form
 is appropriate.
 
 Example 5 handles even the case of a leading dash correctly.
 
-The EXT_LIST does not need to be quoted because the quoting has already be done
-when adding elements to the list.
+The EXT_LIST does not need to be quoted because the quoting has already been
+done when adding elements to the list.
 
 As internal lists shall not be passed to the shell, there is no example for it.
 
@@ -2648,13 +2658,13 @@ There are many possible sources of wrongly quoted variables. This section lists
 some of the commonly known ones.
 
   * Whenever you use the value of a list, think about what happens to leading
-    or trailing whitespace. If the list is a well-formed shell expression you
+    or trailing whitespace. If the list is a well-formed shell expression, you
     can apply the :M* modifier to strip leading and trailing whitespace from
     each word. The :M operator first splits its argument according to the rules
     of the shell, and then creates a new list consisting of all words that
     match the shell glob expression *, that is: all. One class of situations
     where this is needed is when adding a variable like CPPFLAGS to
-    CONFIGURE_ARGS. If the configure script invokes other configure scripts it
+    CONFIGURE_ARGS. If the configure script invokes other configure scripts, it
     strips the leading and trailing whitespace from the variable and then
     passes it to the other configure scripts. But these configure scripts
     expect the (child) CPPFLAGS variable to be the same as the parent CPPFLAGS.
@@ -2680,7 +2690,7 @@ some of the commonly known ones.
     quoting to each variable that is used as a C string literal. You cannot use
     the :Q operator for it, as this operator only works for the shell.
 
-  * Whenever a variable can be empty the :Q operator can have surprising
+  * Whenever a variable can be empty, the :Q operator can have surprising
     results. Here are two completely different cases which can be solved with
     the same trick.
 
@@ -2729,14 +2739,14 @@ Table of Contents
 10.2. Semi-automatic PLIST generation
 10.3. Tweaking output of make print-PLIST
 10.4. Variable substitution in PLIST
-10.5. Manpage-compression
+10.5. Man page-compression
 10.6. Changing PLIST source with PLIST_SRC
-10.7. Platform specific and differing PLISTs
+10.7. Platform-specific and differing PLISTs
 10.8. Sharing directories between packages
 
 The PLIST file contains a package's "packing list", i.e. a list of files that
 belong to the package (relative to the ${PREFIX} directory it's been installed
-in) plus some additional statements - see the pkg_create(1) manpage for a full
+in) plus some additional statements - see the pkg_create(1) man page for a full
 list. This chapter addresses some issues that need attention when dealing with
 the PLIST file (or files, see below!).
 
@@ -2786,11 +2796,11 @@ ${MACHINE_ARCH}, ${MACHINE_GNU_ARCH}
 
     Some packages like emacs and perl embed information about which
     architecture they were built on into the pathnames where they install their
-    file. To handle this case, PLIST will be preprocessed before actually used,
-    and the symbol "${MACHINE_ARCH}" will be replaced by what uname -p gives.
-    The same is done if the string ${MACHINE_GNU_ARCH} is embedded in PLIST
-    somewhere - use this on packages that have GNU autoconf created configure
-    scripts.
+    files. To handle this case, PLIST will be preprocessed before actually
+    used, and the symbol "${MACHINE_ARCH}" will be replaced by what uname -p
+    gives. The same is done if the string ${MACHINE_GNU_ARCH} is embedded in
+    PLIST somewhere - use this on packages that have GNU autoconf-created
+    configure scripts.
 
     Legacy note
 
@@ -2826,13 +2836,13 @@ PLIST_SUBST+=    SOMEVAR="somevalue"
 
 This replaces all occurrences of "${SOMEVAR}" in the PLIST with "somevalue".
 
-10.5. Manpage-compression
+10.5. Man page-compression
 
-Manpages should be installed in compressed form if MANZ is set (in bsd.own.mk),
-and uncompressed otherwise. To handle this in the PLIST file, the suffix ".gz"
-is appended/removed automatically for manpages according to MANZ and
-MANCOMPRESSED being set or not, see above for details. This modification of the
-PLIST file is done on a copy of it, not PLIST itself.
+Man pages should be installed in compressed form if MANZ is set (in
+bsd.own.mk), and uncompressed otherwise. To handle this in the PLIST file, the
+suffix ".gz" is appended/removed automatically for man pages according to MANZ
+and MANCOMPRESSED being set or not, see above for details. This modification of
+the PLIST file is done on a copy of it, not PLIST itself.
 
 10.6. Changing PLIST source with PLIST_SRC
 
@@ -2840,7 +2850,7 @@ To use one or more files as source for the PLIST used in generating the binary
 package, set the variable PLIST_SRC to the names of that file(s). The files are
 later concatenated using cat(1), and order of things is important.
 
-10.7. Platform specific and differing PLISTs
+10.7. Platform-specific and differing PLISTs
 
 Some packages decide to install a different set of files based on the operating
 system being used. These differences can be automatically handled by using the
@@ -2902,7 +2912,7 @@ have the following line in it:
 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
+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.
 
@@ -2966,13 +2976,20 @@ with
 
 .include "../../category/foo/buildlink3.mk"
 
+The buildlink3.mk files usually define the required dependencies. If you need a
+newer version of the dependency when using buildlink3.mk files, then you can
+define it in your Makefile; for example:
+
+BUILDLINK_DEPENDS.foo+=   foo>=1.1.0
+.include "../../category/foo/buildlink3.mk"
+
 There are several buildlink3.mk files in pkgsrc/mk that handle special package
 issues:
 
   * bdb.buildlink3.mk chooses either the native or a pkgsrc Berkeley DB
     implementation based on the values of BDB_ACCEPTED and BDB_DEFAULT.
 
-  * curses.buildlink3.mk If the system comes with neither Curses nor NCurses,
+  * curses.buildlink3.mk: If the system comes with neither Curses nor NCurses,
     this will take care to install the devel/ncurses package.
 
   * krb5.buildlink3.mk uses the value of KRB5_ACCEPTED to choose between adding
@@ -2980,16 +2997,16 @@ issues:
     implementation.
 
   * motif.buildlink3.mk checks for a system-provided Motif installation or adds
-    a dependency on x11/lesstif or x11/openmotif;
+    a dependency on x11/lesstif or x11/openmotif.
 
   * ossaudio.buildlink3.mk defines several variables that may be used by
-    packages that use the Open Sound System (OSS) API;
+    packages that use the Open Sound System (OSS) API.
 
   * pgsql.buildlink3.mk will accept either Postgres 7.3 or 7.4, whichever is
     found installed. See the file for more information.
 
   * pthread.buildlink3.mk uses the value of PTHREAD_OPTS and checks for native
-    pthreads or adds a dependency on devel/pth as needed;
+    pthreads or adds a dependency on devel/pth as needed.
 
   * xaw.buildlink3.mk uses the value of XAW_TYPE to choose a particular Athena
     widgets library.
@@ -3060,7 +3077,7 @@ dependency on pkg is added. Several important variables are set in the section:
     first version of the package that had the last change in the major number
     of a shared library or that had a major API change.
 
-  * BUILDLINK_PKGSRCDIR.pkg is the location of the pkg pkgsrc directory;
+  * BUILDLINK_PKGSRCDIR.pkg is the location of the pkg pkgsrc directory.
 
   * BUILDLINK_DEPMETHOD.pkg (not shown above) controls whether we use
     BUILD_DEPENDS or DEPENDS to add the dependency on pkg. The build dependency
@@ -3113,7 +3130,7 @@ There are two situations that require increasing the dependency listed in
 BUILDLINK_DEPENDS.pkg after a package update:
 
  1. if the sonames (major number of the library version) of any installed
-    shared libraries change;
+    shared libraries change.
 
  2. if the API or interface to the header files change.
 
@@ -3251,7 +3268,7 @@ Table of Contents
 12.2. Configuration files
 
     12.2.1. How PKG_SYSCONFDIR is set
-    12.2.2. Telling the software were configuration files are
+    12.2.2. Telling the software where configuration files are
     12.2.3. Patching installations
     12.2.4. Disabling handling of configuration files
 
@@ -3279,9 +3296,9 @@ are:
 
   * Registration of system shells.
 
-The following sections inspect each of the above points in detail. Note that,
-in order to use any of the described functionalities, you must add the
-following to your package's Makefile:
+The following sections inspect each of the above points in detail. Note that in
+order to use any of the described functionalities, you must add the following
+to your package's Makefile:
 
 USE_PKGINSTALL=YES
 
@@ -3304,16 +3321,15 @@ ${PKG_SYSCONFDIR}.
 
 The only way to achieve this is to create such files during installation time
 by using the installation scripts. These scripts can run arbitrary commands, so
-they have the potential to create and manage files anywhere in the filesystem.
+they have the potential to create and manage files anywhere in the file system.
 Here is where pkginstall comes into play: it provides generic scripts to
 abstract the manipulation of such files and directories based on variables set
-in the package's Makefile. The rest of this section describes which these
-variables are.
+in the package's Makefile. The rest of this section describes these variables.
 
 12.1.1. Directory manipulation
 
 The following variables can be set to request the creation of directories
-anywhere in the filesystem:
+anywhere in the file system:
 
   * MAKE_DIRS and OWN_DIRS contain a list of directories that should be created
     and should attempt to be destroyed by the installation scripts. The
@@ -3385,7 +3401,7 @@ shall be installed. Its contents are set based upon the following variables:
   * PKG_SYSCONFSUBDIR: A subdirectory of PKG_SYSCONFBASE under which the
     configuration files for the package being built shall be installed. The
     definition of this variable only makes sense in the package's Makefile
-    (i.e., it is not user customizable).
+    (i.e., it is not user-customizable).
 
     As an example, consider the Apache package, www/apache2, which places its
     configuration files under the httpd/ subdirectory of PKG_SYSCONFBASE. This
@@ -3415,13 +3431,13 @@ basically the following:
 It is worth mentioning that ${PKG_SYSCONFDIR} is automatically added to
 OWN_DIRS. See Section 12.1.1, "Directory manipulation" what this means.
 
-12.2.2. Telling the software were configuration files are
+12.2.2. Telling the software where configuration files are
 
 Given that pkgsrc (and users!) expect configuration files to be in a known
 place, you need to teach each package where it shall install its files. In some
 cases you will have to patch the package Makefiles to achieve it. If you are
 lucky, though, it may be as easy as passing an extra flag to the configuration
-script; this is the case of GNU Autoconf generated files:
+script; this is the case of GNU Autoconf- generated files:
 
 CONFIGURE_ARGS+= --sysconfdir=${PKG_SYSCONFDIR}
 
@@ -3574,8 +3590,8 @@ e.g. options.mk, that is included by the main package Makefile.
 
 PKG_OPTIONS_VAR=                PKG_OPTIONS.wibble
 PKG_SUPPORTED_OPTIONS=          wibble-foo ldap
-PKG_OPTIONAL_GROUPS=            database
-PKG_GROUP.database=             mysql pgsql
+PKG_OPTIONS_OPTIONAL_GROUPS=    database
+PKG_OPTIONS_GROUP.database=     mysql pgsql
 PKG_SUGGESTED_OPTIONS=          wibble-foo
 PKG_OPTIONS_LEGACY_VARS+=       WIBBLE_USE_OPENLDAP:ldap
 PKG_OPTIONS_LEGACY_OPTS+=       foo:wibble-foo
@@ -3666,7 +3682,7 @@ options, use PKG_SUGGESTED_OPTIONS.
 
 PKG_OPTIONS_VAR must be defined before including bsd.options.mk. If none of
 PKG_SUPPORTED_OPTIONS, PKG_OPTIONS_OPTIONAL_GROUPS, and
-PKG_OPTIONS_REQUIRED_GROUPS are defined (as can happen with platform specific
+PKG_OPTIONS_REQUIRED_GROUPS are defined (as can happen with platform-specific
 options if none of them is supported on the current platform), PKG_OPTIONS is
 set to the empty list and the package is otherwise treated as not using the
 options framework.
@@ -3730,8 +3746,8 @@ When choosing which of these variables to use, follow the following rules:
     installed. When looking for standard X11 includes (not those installed by a
     pkg), use "${X11BASE}".
 
-  * X11 based are special in that they may be installed in either X11BASE or
-    LOCALBASE.
+  * X11-based packages are special in that they may be installed in either
+    X11BASE or LOCALBASE.
 
     Usually, X11 packages should be installed under LOCALBASE whenever
     possible. Note that you will need to include ../../mk/x11.buildlink3.mk in
@@ -3821,9 +3837,9 @@ extract
     EXTRACT_AFTER_ARGS. In the former case, pkgsrc knows how to extract a
     number of suffixes (.tar.gz, .tgz, .tar.gz2, .tbz, .tar.Z, .tar, .shar.gz,
     .shar.bz2, .shar.Z, .shar, .Z, .bz2 and .gz; see the definition of the
-    various DECOMPRESS_CMD variables bsd.pkg.mk for a complete list). Here's an
-    example on how to use the other variables for a program that comes with a
-    compressed shell archive whose name ends in .msg.gz:
+    various DECOMPRESS_CMD variables in bsd.pkg.extract.mk for a complete
+    list). Here's an example on how to use the other variables for a program
+    that comes with a compressed shell archive whose name ends in .msg.gz:
 
          EXTRACT_SUFX=   .msg.gz
          EXTRACT_CMD=            zcat
@@ -3952,7 +3968,7 @@ update
     You can use the "update" target to resume package updating in case a
     previous make update was interrupted for some reason. However, in this
     case, make sure you don't call make clean or otherwise remove the list of
-    dependent packages in WRKDIR. Otherwise you lose the ability to
+    dependent packages in WRKDIR. Otherwise, you lose the ability to
     automatically update the current package along with the dependent packages
     you have installed.
 
@@ -4002,8 +4018,8 @@ clean-update
     before the first time you run make update and only if you have a dirty
     package tree (e.g., if you used NOCLEAN).
 
-    If you unsure about whether your tree is clean you can either perform a
-    make clean at the top of the tree, or use the following sequence of
+    If you are unsure about whether your tree is clean, you can either perform
+    a make clean at the top of the tree, or use the following sequence of
     commands from the directory of the package you want to update (before
     running make update for the first time, otherwise you lose all the packages
     you wanted to update!):
@@ -4108,21 +4124,21 @@ 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 it's depends, if PKG_DEPENDS is set properly. See Section 6.3.1,
-    "Configuration". After creating the binary package, the sources, the
-    just-installed package and it's required packages are removed, preserving
+    (and its depends, if PKG_DEPENDS is set properly. See Section 6.3.1,
+    "Configuration"). 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 upto-date
+    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 not be
+    make bulk-package will be executed, but the installed binary won't be
     removed.
 
-    A binary package is considered "upto-date" to be installed via pkg_add(1)
+    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
@@ -4193,11 +4209,11 @@ Table of Contents
 
 The problem with package-defined variables that can be overridden via MAKECONF
 or /etc/mk.conf is that make(1) expands a variable as it is used, but evaluates
-preprocessor like statements (.if, .ifdef and .ifndef) as they are read. So, to
+preprocessor-like statements (.if, .ifdef and .ifndef) as they are read. So, to
 use any variable (which may be set in /etc/mk.conf) in one of the .if*
 statements, the file /etc/mk.conf must be included before that .if* statement.
 
-Rather than have a number of ad-hoc ways of including /etc/mk.conf, should it
+Rather than having a number of ad-hoc ways of including /etc/mk.conf, should it
 exist, or MAKECONF, should it exist, include the pkgsrc/mk/bsd.prefs.mk file in
 the package Makefile before any preprocessor-like .if, .ifdef, or .ifndef
 statements:
@@ -4208,7 +4224,8 @@ statements:
       ...
     .endif
 
-If you wish to set the CFLAGS variable in /etc/mk.conf please make sure to use:
+If you wish to set the CFLAGS variable in /etc/mk.conf, please make sure to
+use:
 
 CFLAGS+=  -your -flags
 
@@ -4265,9 +4282,10 @@ prevent users from generating binary packages!
 
 Your package may depend on some other package being present - and there are
 various ways of expressing this dependency. pkgsrc supports the BUILD_DEPENDS
-and DEPENDS definitions, as well as dependencies via buildlink3.mk, which is
-the preferred way to handle dependencies, and which uses the variables named
-above. See Chapter 11, Buildlink methodology for more information.
+and DEPENDS definitions, the USE_TOOLS definition, as well as dependencies via
+buildlink3.mk, which is the preferred way to handle dependencies, and which
+uses the variables named above. See Chapter 11, Buildlink methodology for more
+information.
 
 The basic difference between the two variables is as follows: The DEPENDS
 definition registers that pre-requisite in the binary package so it will be
@@ -4391,11 +4409,11 @@ Your package may conflict with other packages a user might already have
 installed on his system, e.g. if your package installs the same set of files
 like another package in our pkgsrc tree.
 
-In this case you can set CONFLICTS to a space separated list of packages
+In this case you can set CONFLICTS to a space-separated list of packages
 (including version string) your package conflicts with.
 
-For example x11/Xaw3d and x11/Xaw-Xpm install provide the same shared library,
-thus you set in pkgsrc/x11/Xaw3d/Makefile:
+For example, x11/Xaw3d and x11/Xaw-Xpm install the same shared library, thus
+you set in pkgsrc/x11/Xaw3d/Makefile:
 
 CONFLICTS=      Xaw-Xpm-[0-9]*
 
@@ -4454,7 +4472,7 @@ compiler version and architecture and almost always relation to optimisation
 being enabled. Common symptoms are gcc internal errors or never finishing
 compiling a file.
 
-Typically a workaround involves testing the MACHINE_ARCH and compiler version,
+Typically, a workaround involves testing the MACHINE_ARCH and compiler version,
 disabling optimisation for that file/MACHINE_ARCH/compiler combination, and
 documenting it in pkgsrc/doc/HACKS. See that file for a number of examples!
 
@@ -4471,7 +4489,7 @@ PKGREVISION=1 (2, ...). The "nb" is treated like a "." by the pkg tools. e.g.
 will result in a PKGNAME of "foo-17.42nb9".
 
 When a new release of the package is released, the PKGREVISION should be
-removed. e.g. on a new minor release of the above package, things should be
+removed, e.g. on a new minor release of the above package, things should be
 like:
 
 DISTNAME=   foo-17.43
@@ -4537,8 +4555,8 @@ at all. To accompany this, varying commands and options have to be passed to
 the compiler, linker, etc. to get the Right Thing, which can be pretty annoying
 especially if you don't have all the machines at your hand to test things. The
 devel/libtool pkg can help here, as it just "knows" how to build both static
-and dynamic libraries from a set of source files, thus being platform
-independent.
+and dynamic libraries from a set of source files, thus being
+platform-independent.
 
 Here's how to use libtool in a pkg in seven simple steps:
 
@@ -4638,7 +4656,7 @@ appropriate.
 If you do not need *.a static libraries built and installed, then use
 SHLIBTOOL_OVERRIDE instead.
 
-If your package makes use of the platform independent library for loading
+If your package makes use of the platform-independent library for loading
 dynamic shared objects, that comes with libtool (libltdl), you should include
 devel/libltdl/buildlink3.mk.
 
@@ -4716,7 +4734,7 @@ using this conditional:
 #endif
 
 Please use the "__NetBSD__" definition sparingly - it should only apply to
-features of NetBSD that are not present in other 4.4-lite derived BSDs.
+features of NetBSD that are not present in other 4.4-lite-derived BSDs.
 
 15.5. Package specific actions
 
@@ -4735,7 +4753,7 @@ number of ways:
 
 The INTERACTIVE_STAGE definition is provided to notify the pkgsrc mechanism of
 an interactive stage which will be needed, and this should be set in the
-package's Makefile. e.g.
+package's Makefile, e.g.:
 
 INTERACTIVE_STAGE= build
 
@@ -4883,7 +4901,7 @@ should not use the install-info command as the registration of info files is
 the task of the package INSTALL script, and it must use the appropriate
 makeinfo command.
 
-To achieve this goal the pkgsrc infrastructure creates overriding scripts for
+To achieve this goal, the pkgsrc infrastructure creates overriding scripts for
 the install-info and makeinfo commands in a directory listed early in PATH.
 
 The script overriding install-info has no effect except the logging of a
@@ -4952,7 +4970,7 @@ to find them.
 
 15.5.11. Packages installing GTK2 modules
 
-If a package installs gtk2 immodules or loaders, you need to take some extra
+If a package installs GTK2 immodules or loaders, you need to take some extra
 steps to get them registered in the GTK2 database properly:
 
  1. Include ../../x11/gtk2/modules.mk instead of its buildlink3.mk file. This
@@ -4963,7 +4981,7 @@ steps to get them registered in the GTK2 database properly:
 
  3. Set GTK2_LOADERS=YES if your package installs GTK2 loaders.
 
- 4. Patch the package to not touch any of the gtk2 databases directly. These
+ 4. Patch the package to not touch any of the GTK2 databases directly. These
     are:
 
       * libdata/gtk-2.0/gdk-pixbuf.loaders
@@ -5013,7 +5031,7 @@ ensure that the database is kept consistent with respect to these new files:
 
  2. Check the PLIST and remove any entries under the share/mime directory,
     except for files saved under share/mime/packages. The former are handled
-    automatically by the update-mime-database program, but the later are
+    automatically by the update-mime-database program, but the latter are
     package-dependent and must be removed by the package that installed them in
     the first place.
 
@@ -5334,7 +5352,7 @@ change to the directory of the package you wish to examine and execute pkglint:
 $ pkglint
 looks fine.
 
-Depending on the supplied command line arguments (see pkglint(1)) more verbose
+Depending on the supplied command line arguments (see pkglint(1)), more verbose
 checks will be performed. Use e.g. pkglint -v for a very verbose check.
 
 A.2. Steps for building, installing, packaging
@@ -5674,8 +5692,8 @@ The procedure to edit the pkgsrc guide is:
 
   * Make sure you have the packages needed to re-generate the pkgsrc guide (and
     other XML-based NetBSD documentation) installed. These are "netbsd-doc" for
-    creating the ASCII- and HTML-version, and "netbsd-doc-print"for the
-    PostScript- and PDF version. You will need both packages installed, to make
+    creating the ASCII and HTML versions, and "netbsd-doc-print" for the
+    PostScript and PDF versions. You will need both packages installed, to make
     sure documentation is consistent across all formats. The packages can be
     found in pkgsrc/meta-pkgs/netbsd-doc and pkgsrc/meta-pkgs/netbsd-doc-print.