 @@ -3299,2047 +3299,2051 @@ anymore, you can remove that file and ru
 <dt><span class="sect2"><a href="#modified-distfiles-same-name">21.2.2. How to handle modified distfiles with the 'old' name</a></span></dt>
 <dt><span class="sect2"><a href="#build.fetch.github">21.2.3. Packages hosted on github.com</a></span></dt>
 </dl></dd>
 <dt><span class="sect1"><a href="#fixes.configure">21.3. The <span class="emphasis"><em>configure</em></span> phase</a></span></dt>
 <dd><dl>
 <dt><span class="sect2"><a href="#fixes.libtool">21.3.1. Shared libraries - libtool</a></span></dt>
 <dt><span class="sect2"><a href="#using-libtool">21.3.2. Using libtool on GNU packages that already support libtool</a></span></dt>
 <dt><span class="sect2"><a href="#autoconf-automake">21.3.3. GNU Autoconf/Automake</a></span></dt>
 <dt><span class="sect2"><a href="#meson">21.3.4. Meson / ninja</a></span></dt>
 </dl></dd>
 <dt><span class="sect1"><a href="#programming-languages">21.4. Programming languages</a></span></dt>
 <dd><dl>
 <dt><span class="sect2"><a href="#basic-programming-languages">21.4.1. C, C++, and Fortran</a></span></dt>
 <dt><span class="sect2"><a href="#java-programming-language">21.4.2. Java</a></span></dt>
 <dt><span class="sect2"><a href="#go-programming-language">21.4.3. Go</a></span></dt>
 <dt><span class="sect2"><a href="#rust-programming-language">21.4.4. Rust</a></span></dt>
 <dt><span class="sect2"><a href="#perl-scripts">21.4.5. Packages containing Perl scripts</a></span></dt>
 <dt><span class="sect2"><a href="#shell-scripts">21.4.6. Packages containing shell scripts</a></span></dt>
 <dt><span class="sect2"><a href="#other-programming-languages">21.4.7. Other programming languages</a></span></dt>
 </dl></dd>
 <dt><span class="sect1"><a href="#fixes.build">21.5. The <span class="emphasis"><em>build</em></span> phase</a></span></dt>
 <dd><dl>
 <dt><span class="sect2"><a href="#fixes.build.cpp">21.5.1. Compiling C and C++ code conditionally</a></span></dt>
 <dt><span class="sect2"><a href="#compiler-bugs">21.5.2. How to handle compiler bugs</a></span></dt>
 <dt><span class="sect2"><a href="#fixes.build.header">21.5.3. No such file or directory</a></span></dt>
 <dt><span class="sect2"><a href="#undefined-reference">21.5.4. Undefined reference to <span class="quote">&#8220;<span class="quote">...</span>&#8221;</span></a></span></dt>
 <dt><span class="sect2"><a href="#out-of-memory">21.5.5. Running out of memory</a></span></dt>
 </dl></dd>
 <dt><span class="sect1"><a href="#fixes.install">21.6. The <span class="emphasis"><em>install</em></span> phase</a></span></dt>
 <dd><dl>
 <dt><span class="sect2"><a href="#install-scripts">21.6.1. Creating needed directories</a></span></dt>
 <dt><span class="sect2"><a href="#where-to-install-documentation">21.6.2. Where to install documentation</a></span></dt>
 <dt><span class="sect2"><a href="#installing-score-files">21.6.3. Installing highscore files</a></span></dt>
 <dt><span class="sect2"><a href="#destdir-support">21.6.4. Adding DESTDIR support to packages</a></span></dt>
 <dt><span class="sect2"><a href="#hardcoded-paths">21.6.5. Packages with hardcoded paths to other interpreters</a></span></dt>
 <dt><span class="sect2"><a href="#perl-modules">21.6.6. Packages installing Perl modules</a></span></dt>
 <dt><span class="sect2"><a href="#faq.info-files">21.6.7. Packages installing info files</a></span></dt>
 <dt><span class="sect2"><a href="#manpages">21.6.8. Packages installing man pages</a></span></dt>
 <dt><span class="sect2"><a href="#x11-fonts">21.6.9. Packages installing X11 fonts</a></span></dt>
 <dt><span class="sect2"><a href="#sgml-xml-data">21.6.10. Packages installing SGML or XML data</a></span></dt>
 <dt><span class="sect2"><a href="#mime-database">21.6.11. Packages installing extensions to the MIME database</a></span></dt>
 <dt><span class="sect2"><a href="#intltool">21.6.12. Packages using intltool</a></span></dt>
 <dt><span class="sect2"><a href="#startup-scripts">21.6.13. Packages installing startup scripts</a></span></dt>
 <dt><span class="sect2"><a href="#tex-packages">21.6.14. Packages installing TeX modules</a></span></dt>
 <dt><span class="sect2"><a href="#emulation-packages">21.6.15. Packages supporting running binaries in
     emulation</a></span></dt>
 <dt><span class="sect2"><a href="#hicolor-theme">21.6.16. Packages installing hicolor icons</a></span></dt>
 <dt><span class="sect2"><a href="#desktop-files">21.6.17. Packages installing desktop files</a></span></dt>
 </dl></dd>
 <dt><span class="sect1"><a href="#punting">21.7. Marking packages as having problems</a></span></dt>
 </dl></dd>
 <dt><span class="chapter"><a href="#gnome">22. GNOME packaging and porting</a></span></dt>
 <dd><dl>
 <dt><span class="sect1"><a href="#meta-packages">22.1. Meta packages</a></span></dt>
 <dt><span class="sect1"><a href="#new-package">22.2. Packaging a GNOME application</a></span></dt>
 <dt><span class="sect1"><a href="#full-update">22.3. Updating GNOME to a newer version</a></span></dt>
 <dt><span class="sect1"><a href="#patching">22.4. Patching guidelines</a></span></dt>
 </dl></dd>
 <dt><span class="chapter"><a href="#submit">23. Submitting and Committing</a></span></dt>
 <dd><dl>
 <dt><span class="sect1"><a href="#submitting-binary-packages">23.1. Submitting binary packages</a></span></dt>
 <dt><span class="sect1"><a href="#submitting-your-package">23.2. Submitting source packages (for non-NetBSD-developers)</a></span></dt>
 <dt><span class="sect1"><a href="#general-notes-for-changes">23.3. General notes when adding, updating, or removing packages</a></span></dt>
 <dt><span class="sect1"><a href="#commit-messages">23.4. Commit Messages</a></span></dt>
 <dt><span class="sect1"><a href="#committing-importing">23.5. Committing: Adding a package to CVS</a></span></dt>
 <dt><span class="sect1"><a href="#updating-package">23.6. Updating a package to a newer version</a></span></dt>
 <dt><span class="sect1"><a href="#renaming-package">23.7. Renaming a package in pkgsrc</a></span></dt>
 <dt><span class="sect1"><a href="#moving-package">23.8. Moving a package in pkgsrc</a></span></dt>
 </dl></dd>
 <dt><span class="chapter"><a href="#devfaq">24. Frequently Asked Questions</a></span></dt>
 </dl>
 </div>
 </div>
 <div class="chapter">
 <div class="titlepage"><div><div><h2 class="title">
 <a name="help-devel"></a>Chapter�11.�Getting help</h2></div></div></div>
 <p>
 	To get help when developing pkgsrc, the definitive source is this
 	document, the pkgsrc guide. If you don't find anything here,
 	there are alternatives:
 </p>
 <div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; ">
 <li class="listitem">
 <p>
 	The built-in pkgsrc help, which is available after bootstrapping
 	pkgsrc. Run <span class="command"><strong>bmake help topic=&#8230;</strong></span> to get
 	help for any topic, such as a variable name like
 	<code class="varname">BUILD_DEFS</code>, a make target like
 	<span class="command"><strong>do-build</strong></span>, a missing C or C++ function like
 	<span class="command"><strong>strcasecmp</strong></span> or any other topic.</p>
 <p>The available help topics are listed in <a class="xref" href="#help-topics" title="Appendix�E.�Help topics">Appendix�E, <i>Help topics</i></a>.</p>
 </li>
 <li class="listitem"><p>
 	To see the value of a single variable, run <span class="command"><strong>bmake
 	show-var VARNAME=<em class="replaceable"><code>X</code></em></strong></span>.
 </p></li>
 <li class="listitem"><p>
 	To see the values of the most common variables, run
 	<span class="command"><strong>bmake show-all</strong></span>. These variables are grouped by
 	topic. To see the variables for a single topic, run
 	<span class="command"><strong>bmake
 	show-all-<em class="replaceable"><code>topic</code></em></strong></span>, for example
 	<span class="command"><strong>bmake show-all-fetch</strong></span>.
 </p></li>
 <li class="listitem"><p>
 	The tech-pkg mailing list, to which
 	<a class="ulink" href="https://www.NetBSD.org/mailinglists/#tech-pkg" target="_top">you
 	can subscribe</a> and then <a class="ulink" href="mailto:tech-pkg@NetBSD.org" target="_top">ask your
 	questions</a>.</p></li>
 <li class="listitem"><p>The #pkgsrc IRC channel, which is accessible
 	<a class="ulink" href="https://webchat.freenode.net/" target="_top">via a web browser</a>
 	or by using a specialized chat program such as
 	<a class="ulink" href="http://xchat.org/" target="_top">XChat</a>.
 	Pick any user name and join the channel #pkgsrc.</p></li>
 </ul></div>
 </div>
 <div class="chapter">
 <div class="titlepage"><div><div><h2 class="title">
 <a name="components"></a>Chapter�12.�Package components - files, directories and contents</h2></div></div></div>
 <div class="toc">
 <p><b>Table of Contents</b></p>
 <dl class="toc">
 <dt><span class="sect1"><a href="#components.Makefile">12.1. <code class="filename">Makefile</code></a></span></dt>
 <dt><span class="sect1"><a href="#components.distinfo">12.2. <code class="filename">distinfo</code></a></span></dt>
 <dt><span class="sect1"><a href="#components.patches">12.3. <code class="filename">patches/*</code></a></span></dt>
 <dd><dl>
 <dt><span class="sect2"><a href="#components.patch.structure">12.3.1. Structure of a single patch file</a></span></dt>
 <dt><span class="sect2"><a href="#components.patches.caveats">12.3.2. Creating patch files</a></span></dt>
 <dt><span class="sect2"><a href="#components.patches.sources">12.3.3. Sources where the patch files come from</a></span></dt>
 <dt><span class="sect2"><a href="#components.patches.guidelines">12.3.4. Patching guidelines</a></span></dt>
 <dt><span class="sect2"><a href="#components.patches.feedback">12.3.5. Feedback to the author</a></span></dt>
 </dl></dd>
 <dt><span class="sect1"><a href="#other-mandatory-files">12.4. Other mandatory files</a></span></dt>
 <dt><span class="sect1"><a href="#components.optional">12.5. Optional files</a></span></dt>
 <dd><dl>
 <dt><span class="sect2"><a href="#components.optional.bin">12.5.1. Files affecting the binary package</a></span></dt>
 <dt><span class="sect2"><a href="#components.optional.build">12.5.2. Files affecting the build process</a></span></dt>
 <dt><span class="sect2"><a href="#components.optional.none">12.5.3. Files affecting nothing at all</a></span></dt>
 </dl></dd>
 <dt><span class="sect1"><a href="#work-dir">12.6. <code class="filename">work*</code></a></span></dt>
 <dt><span class="sect1"><a href="#files-dir">12.7. <code class="filename">files/*</code></a></span></dt>
 </dl>
 </div>
 <p>Whenever you're preparing a package, there are a number of
 files involved which are described in the following
 sections.</p>
 <div class="sect1">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
 <a name="components.Makefile"></a>12.1.�<code class="filename">Makefile</code>
 </h2></div></div></div>
 <p>Building, installation and creation of a binary package are all
   controlled by the package's <code class="filename">Makefile</code>.
   The <code class="filename">Makefile</code> describes various things about
   a package, for example from where to get it, how to configure,
   build, and install it.</p>
 <p>A package <code class="filename">Makefile</code> contains several
   sections that describe the package.</p>
 <p>In the first section there are the following variables, which
   should appear exactly in the order given here.  The order and
   grouping of the variables is mostly historical and has no further
   meaning.</p>
 <div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; ">
 <li class="listitem"><p><code class="varname">DISTNAME</code> is the basename of the
     distribution file to be downloaded from the package's
     website.</p></li>
 <li class="listitem"><p><code class="varname">PKGNAME</code> is the name of the
     package, as used by pkgsrc. You need to provide it if
     <code class="varname">DISTNAME</code> (which is the default) is not a good
     name for the package in pkgsrc or <code class="varname">DISTNAME</code> is not
     provided (no distribution file is required).  Usually it is the pkgsrc
     directory name together with the version number. It must match the
     regular expression
     <code class="varname">^[A-Za-z0-9][A-Za-z0-9-_.+]*$</code>, that is, it
     starts with a letter or digit, and contains only letters, digits,
     dashes, underscores, dots and plus signs.
     New packages should have entirely lower-case names, with the exception
     of some that must follow pre-existing conventions
     (e.g. R packages begin with <code class="varname">R-</code>).
     You can use the <code class="code">:tl</code> variable modifier to lower-case
     the package name.</p></li>
 <li class="listitem">
 <p><code class="varname">CATEGORIES</code> is a list of categories
     which the package fits in. You can choose any of the top-level
     directories of pkgsrc for it.</p>
 <p>Currently the following values are available for
     <code class="varname">CATEGORIES</code>. If more than
     one is used, they need to be separated by spaces:</p>
 <pre class="programlisting">
 archivers     cross         geography     meta-pkgs     security
 audio         databases     graphics      misc          shells
 benchmarks    devel         ham           multimedia    sysutils
 biology       editors       inputmethod   net           textproc
 cad           emulators     lang          news          time
 chat          finance       mail          parallel      wm
 comms         fonts         math          pkgtools      www
 converters    games         mbone         print         x11
 </pre>
 </li>
 <li class="listitem"><p><code class="varname">MASTER_SITES</code>,
     <code class="varname">DYNAMIC_MASTER_SITES</code>,
     <code class="varname">DIST_SUBDIR</code>, <code class="varname">EXTRACT_SUFX</code>
     and <code class="varname">DISTFILES</code> are discussed in detail in
     <a class="xref" href="#build.fetch" title="13.5.�The fetch phase">Section�13.5, &#8220;The <span class="emphasis"><em>fetch</em></span> phase&#8221;</a>.</p></li>
 </ul></div>
 <p>The second section contains information about separately
   downloaded patches, if any.
   </p>
 <div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; ">
 <li class="listitem"><p><code class="varname">PATCHFILES</code>:
     Name(s) of additional files that contain distribution patches.
     There is no default. pkgsrc will look for them at
     <code class="varname">PATCH_SITES</code>.
     They will automatically be uncompressed before patching if
     the names end with <code class="filename">.gz</code> or
     <code class="filename">.Z</code>.</p></li>
 <li class="listitem"><p><code class="varname">PATCH_SITES</code>:
     Primary location(s) for distribution patch files (see
     <code class="varname">PATCHFILES</code> above) if not found locally.</p></li>
 <li class="listitem"><p><code class="varname">PATCH_DIST_STRIP</code>:
     an argument to <a class="citerefentry" href="https://man.NetBSD.org/NetBSD-9.2/i386/patch.1"><span class="citerefentry"><span class="refentrytitle">patch</span>(1)</span></a> that sets the pathname strip count to
     help find the correct files to patch. It defaults to
     <span class="command"><strong>-p0</strong></span>.</p></li>
 </ul></div>
 <p>The third section contains the following variables.
   </p>
 <div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; ">
 <li class="listitem"><p><code class="varname">MAINTAINER</code> is the email
     address of the person who feels responsible for this package,
     and who is most likely to look at problems or questions regarding
     this package which have been reported with <a class="citerefentry" href="https://man.NetBSD.org/NetBSD-9.2/i386/send-pr.1"><span class="citerefentry"><span class="refentrytitle">send-pr</span>(1)</span></a>.
     Other developers may contact the <code class="varname">MAINTAINER</code>
     before making changes to the package, but are not required to
     do so. When packaging a new program, set <code class="varname">MAINTAINER</code>
     to yourself. If you really can't maintain the package for future
     updates, set it to
     <code class="email">&lt;<a class="email" href="mailto:pkgsrc-users@NetBSD.org">pkgsrc-users@NetBSD.org</a>&gt;</code>.</p></li>
 <li class="listitem"><p><code class="varname">OWNER</code> should be used instead
     of <code class="varname">MAINTAINER</code> when you do not want other
     developers to update or change the package without contacting
     you first. A package Makefile should contain one of
     <code class="varname">MAINTAINER</code> or <code class="varname">OWNER</code>, but
     not both.  </p></li>
 <li class="listitem"><p><code class="varname">HOMEPAGE</code> is a URL where users can
     find more information about the package.</p></li>
 <li class="listitem"><p><code class="varname">COMMENT</code> is a one-line
     description of the package (should not include the package
     name).</p></li>
 <li class="listitem"><p><code class="varname">LICENSE</code> indicates the license(s)
     applicable for the package. See <a class="xref" href="#handling-licenses" title="21.1.3.�Handling licenses">Section�21.1.3, &#8220;Handling licenses&#8221;</a> for further details.</p></li>
 </ul></div>
 <p>Other variables that affect the build:
   </p>
 <div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; "><li class="listitem">
 <p><code class="varname">WRKSRC</code>: The directory where the
       interesting distribution files of the package are found. The
       default is <code class="filename">${WRKDIR}/${DISTNAME}</code>, which
       works for most packages.</p>
 <p>If a package doesn't create a subdirectory for itself
       (most GNU software does, for instance), but extracts itself in
       the current directory, you should set
       <code class="varname">WRKSRC=${WRKDIR}</code>.</p>
 <p>If a package doesn't create a subdirectory with the
       name of <code class="varname">DISTNAME</code> but some different name,
       set <code class="varname">WRKSRC</code> to point to the proper name in
       <code class="filename">${WRKDIR}</code>, for example
       <code class="varname">WRKSRC=${WRKDIR}/${DISTNAME}/unix</code>. See
       <a href="https://cdn.NetBSD.org/pub/pkgsrc/current/pkgsrc/lang/tcl/index.html" target="_top"><code class="filename">lang/tcl</code></a> and <a href="https://cdn.NetBSD.org/pub/pkgsrc/current/pkgsrc/x11/tk/index.html" target="_top"><code class="filename">x11/tk</code></a> for other examples.</p>
 <p>The name of the working directory created by pkgsrc is
       taken from the <code class="varname">WRKDIR_BASENAME</code>
       variable. By default, its value is
       <code class="filename">work</code>. If you want to use the same
       pkgsrc tree for building different kinds of binary packages,
       you can change the variable according to your needs. Two
       other variables handle common cases of setting
       <code class="varname">WRKDIR_BASENAME</code> individually. If
       <code class="varname">OBJHOSTNAME</code> is defined in
       <a class="link" href="#mk.conf"><code class="filename">mk.conf</code></a>, the first component of
       the host's name is attached to the directory name. If
       <code class="varname">OBJMACHINE</code> is defined, the platform name
       is attached, which might look like
       <code class="filename">work.i386</code> or
       <code class="filename">work.sparc</code>.</p>
 </li></ul></div>
 <p>Please pay attention to the following gotchas:</p>
 <div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; ">
 <li class="listitem"><p>Add <code class="varname">MANCOMPRESSED</code> if man pages are
       installed in compressed form by the package.  For packages using
       BSD-style makefiles which honor MANZ, there is
       <code class="varname">MANCOMPRESSED_IF_MANZ</code>.</p></li>
 <li class="listitem"><p>Replace <code class="filename">/usr/local</code> with
       <span class="quote">&#8220;<span class="quote">${PREFIX}</span>&#8221;</span> in all files (see patches,
       below).</p></li>
 <li class="listitem"><p>If the package installs any info files, see <a class="xref" href="#faq.info-files" title="21.6.7.�Packages installing info files">Section�21.6.7, &#8220;Packages installing info files&#8221;</a>.</p></li>
 </ul></div>
 </div>
 <div class="sect1">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
 <a name="components.distinfo"></a>12.2.�<code class="filename">distinfo</code>
 </h2></div></div></div>
 <p>The <code class="filename">distinfo</code> file contains the message
   digest, or checksum, of each distfile needed for the package. This
   ensures that the distfiles retrieved from the Internet have not been
   corrupted during transfer or altered by a malign force to introduce
   a security hole. To provide maximum security, all distfiles are
   protected using three different message digest algorithms (SHA1,
   RMD160, SHA512), as well as the file size.</p>
 <p>The <code class="filename">distinfo</code> file also contains the
   checksums for all the patches found in the
   <code class="filename">patches</code> directory (see <a class="xref" href="#components.patches" title="12.3.�patches/*">Section�12.3, &#8220;<code class="filename">patches/*</code>&#8221;</a>). These checksums ensure that patches
   are only applied intentionally and that they don't accidentally change,
   e.g. when merging different changes together. They also make sure that
   new patches are actually added to CVS and old ones are removed.
   Too see whether the patches and the <code class="filename">distinfo</code> file
   match, run <span class="command"><strong>pkglint</strong></span> after changing the patches.</p>
 <p>To regenerate the <code class="filename">distinfo</code> file, use the
   <span class="command"><strong>make distinfo</strong></span> command.</p>
 <p>Some packages have different sets of distfiles depending on
   the platform, for example <a href="https://cdn.NetBSD.org/pub/pkgsrc/current/pkgsrc/lang/openjdk8/index.html" target="_top"><code class="filename">lang/openjdk8</code></a>. These are kept in the same
   <code class="filename">distinfo</code> file and care should be taken when
   upgrading such a package to ensure distfile information is not
   lost.</p>
 </div>
 <div class="sect1">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
 <a name="components.patches"></a>12.3.�<code class="filename">patches/*</code>
 </h2></div></div></div>
 <p>Some packages don't work out-of-the box on the various
   platforms that are supported by pkgsrc. These packages need
   to be patched to make them work. The patch files can be
   found in the <code class="filename">patches/</code> directory.</p>
 <p>In the <span class="emphasis"><em>patch</em></span> phase, these patches are
   applied to the files in <code class="varname">WRKSRC</code> directory after
   extracting them, in alphabetic order.</p>
 <div class="sect2">
 <div class="titlepage"><div><div><h3 class="title">
 <a name="components.patch.structure"></a>12.3.1.�Structure of a single patch file</h3></div></div></div>
 <p>The <code class="filename">patch-*</code> files should be in
   <span class="command"><strong>diff -bu</strong></span> format, and apply without a fuzz to avoid
   problems. (To force patches to apply with fuzz you can set
   <code class="varname">PATCH_FUZZ_FACTOR=-F2</code>). Furthermore, each patch
   should contain only changes for a single file, and no file should be
   patched by more than one patch file. This helps to keep future
   modifications simple.</p>
 <p>Each patch file is structured as follows: In the first line,
   there is the RCS Id of the patch itself. The second line should be
   empty for aesthetic reasons. After that, there should be a comment for
   each change that the patch does. There are a number of standard
   cases:</p>
 <div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; ">
 <li class="listitem"><p>Patches for commonly known vulnerabilities should
   mention the vulnerability ID (CAN, CVE).</p></li>
 <li class="listitem"><p>Patches that change source code should mention the
   platform and other environment (for example, the compiler) that the
   patch is needed for.</p></li>
 </ul></div>
 <p>The patch should be commented so that any
   developer who knows the code of the application can make some use of
   the patch. Special care should be taken for the upstream developers,
   since we generally want that they accept our patches, so we have less
   work in the future.</p>
 </div>
 <div class="sect2">
 <div class="titlepage"><div><div><h3 class="title">
 <a name="components.patches.caveats"></a>12.3.2.�Creating patch files</h3></div></div></div>
 <p>One important thing to mention is to pay attention that no RCS
   IDs get stored in the patch files, as these will cause problems when
   later checked into the NetBSD CVS tree. Use the
   <span class="command"><strong>pkgdiff</strong></span> command from the <a href="https://cdn.NetBSD.org/pub/pkgsrc/current/pkgsrc/pkgtools/pkgdiff/index.html" target="_top"><code class="filename">pkgtools/pkgdiff</code></a> package to avoid these
   problems.</p>
 <p>For even more automation, we recommend using
   <span class="command"><strong>mkpatches</strong></span> from the same package to make a
   whole set of patches. You just have to back up files before you
   edit them to <code class="filename">filename.orig</code>, e.g., with
   <span class="command"><strong>cp -p filename filename.orig</strong></span> or, easier, by
   using <span class="command"><strong>pkgvi</strong></span> again from the same package. If
   you upgrade a package this way, you can easily compare the new
   set of patches with the previously existing one with
   <span class="command"><strong>patchdiff</strong></span>. The files in <code class="filename">patches</code>
   are replaced by new files, so carefully check if you want to take all
   the changes.</p>
 <p>When you have finished a package, remember to generate
   the checksums for the patch files by using the <span class="command"><strong>make
   makepatchsum</strong></span> command, see <a class="xref" href="#components.distinfo" title="12.2.�distinfo">Section�12.2, &#8220;<code class="filename">distinfo</code>&#8221;</a>.</p>
 <p>When adding a patch that corrects a problem in the
   distfile (rather than e.g. enforcing pkgsrc's view of where
   man pages should go), send the patch as a bug report to the
   maintainer.  This benefits non-pkgsrc users of the package,
   and usually makes it possible to remove the patch in future
   version.</p>
 <p>The file names of the patch files are usually of the form
   <code class="filename">patch-<em class="replaceable"><code>path_to_file__with__underscores.c</code></em></code>.
   Many packages still use the previous convention
   <code class="filename">patch-<em class="replaceable"><code>[a-z][a-z]</code></em></code>,
   but new patches should be of the form containing the filename.
   <span class="command"><strong>mkpatches</strong></span> included in <a href="https://cdn.NetBSD.org/pub/pkgsrc/current/pkgsrc/pkgtools/pkgdiff/index.html" target="_top"><code class="filename">pkgtools/pkgdiff</code></a> takes care of the name
   automatically.</p>
 <p>When updating pre-existing patch files, if a file uses the old
   <code class="filename">patch-<em class="replaceable"><code>[a-z][a-z]</code></em></code>
   convention, it's best not to change it to the new form, as that will
   just cause churn that makes it harder to track changes to patching
   over time. Similarly, if a patch now applies at different line offsets,
   but still applies cleanly as-is, there's no need to update it, as that
   also unnecessarily complicates the patch history.</p>
 </div>
 <div class="sect2">
 <div class="titlepage"><div><div><h3 class="title">
 <a name="components.patches.sources"></a>12.3.3.�Sources where the patch files come from</h3></div></div></div>
 <p>If you want to share patches between multiple packages
   in pkgsrc, e.g. because they use the same distfiles, set
   <code class="varname">PATCHDIR</code> to the path where the patch files
   can be found, e.g.:</p>
 <pre class="programlisting">
 PATCHDIR=       ../../editors/xemacs/patches
 </pre>
 <p>Patch files that are distributed by the author or other
     maintainers can be listed in
     <code class="varname">PATCHFILES</code>.</p>
 <p>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 <code class="filename">$LOCALPATCHES</code> directory. The
     directory tree there is expected to have the same
     <span class="quote">&#8220;<span class="quote">category/package</span>&#8221;</span> structure as pkgsrc, and
     patches are expected to be stored inside these dirs (also
     known as <code class="filename">$LOCALPATCHES/$PKGPATH</code>). For
     example, if you want to keep a private patch for
     <code class="filename">pkgsrc/graphics/png</code>, keep it in
     <code class="filename">$LOCALPATCHES/graphics/png/mypatch</code>. All
     files in the named directory are expected to be patch files,
     and <span class="emphasis"><em>they are applied after pkgsrc patches are
     applied</em></span>.</p>
 </div>
 <div class="sect2">
 <div class="titlepage"><div><div><h3 class="title">
 <a name="components.patches.guidelines"></a>12.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;
       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">
 <a name="patch-examples"></a><p class="title"><b>Table�12.1.�Patching examples</b></p>
 <div class="table-contents"><table class="table" summary="Patching examples" border="1">
 <colgroup>
 <col>
 <col>
 <col>
 </colgroup>
 <thead><tr>
 <th>Where</th>
 <th>Incorrect</th>
 <th>Correct</th>
 </tr></thead>
 <tbody>
 <tr>
 <td>configure script</td>
 <td>
 <pre class="programlisting">
 case ${target_os} in
 netbsd*) have_kvm=yes ;;
 *)       have_kvm=no  ;;
 esac
 </pre>
 	      </td>
 <td>
 <pre class="programlisting">
 AC_CHECK_LIB(kvm, kvm_open, have_kvm=yes, have_kvm=no)
 </pre>
 	      </td>
 </tr>
 <tr>
 <td>C source file</td>
 <td>
 <pre class="programlisting">
 #if defined(__NetBSD__)
 #  include &lt;sys/event.h&gt;
 #endif
 </pre>
 	      </td>
 <td>
 <pre class="programlisting">
 #if defined(HAVE_SYS_EVENT_H)
 #  include &lt;sys/event.h&gt;
 #endif
 </pre>
 	      </td>
 </tr>
 <tr>
 <td>C source file</td>
 <td>
 <pre class="programlisting">
 int
 monitor_file(...)
+{
 #if defined(__NetBSD__)
         int fd = kqueue();
         ...
 #else
         ...
 #endif
+}
 </pre>
 	      </td>
 <td>
 <pre class="programlisting">
 int
 monitor_file(...)
+{
 #if defined(HAVE_KQUEUE)
         int fd = kqueue();
         ...
 #else
         ...
 #endif
+}
 </pre>
 	      </td>
 </tr>
 </tbody>
 </table></div>
 </div>
 <br class="table-break">
 </div>
 <div class="sect2">
 <div class="titlepage"><div><div><h3 class="title">
 <a name="components.patches.feedback"></a>12.3.5.�Feedback to the author</h3></div></div></div>
 <p>Always, always, <span class="strong"><strong>always</strong></span>
       feed back any <span class="emphasis"><em>portability fixes</em></span> or
       improvements you do to a package to the mainstream developers.
       This is the only way to get their attention on portability issues
       and to ensure that future versions can be built out-of-the box on
       NetBSD.  Furthermore, any user that gets newer distfiles will get
       the fixes straight from the packaged code.</p>
 <p>This generally involves cleaning up the patches
       (because sometimes the patches that are
       added to pkgsrc are quick hacks), filing bug reports in the
       appropriate trackers for the projects and working with the
       mainstream authors to accept your changes.  It is
       <span class="emphasis"><em>extremely important</em></span> that you do it so that
       the packages in pkgsrc are kept simple and thus further changes
       can be done without much hassle.</p>
 <p>When you have done this, please add a URL to the upstream
       bug report to the patch comment.</p>
 <p>Support the idea of free software!</p>
 </div>
 </div>
 <div class="sect1">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
 <a name="other-mandatory-files"></a>12.4.�Other mandatory files</h2></div></div></div>
 <div class="variablelist"><dl class="variablelist">
 <dt><span class="term"><code class="filename">DESCR</code></span></dt>
 <dd><p>A multi-line description of the piece of software.  This should include
 	  any credits where they are due.  Please bear in mind that others do not
 	  share your sense of humour (or spelling idiosyncrasies), and that others
 	  will read everything that you write here.</p></dd>
 <dt><span class="term"><code class="filename">PLIST</code></span></dt>
 <dd><p>This file governs the files that are installed on your
 	  system: all the binaries, manual pages, etc. There are other
 	  directives which may be entered in this file, to control the
 	  creation and deletion of directories, and the location of
 	  inserted files.  See <a class="xref" href="#plist" title="Chapter�19.�PLIST issues">Chapter�19, <i>PLIST issues</i></a> for more
 	  information.</p></dd>
 </dl></div>
 </div>
 <div class="sect1">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
 <a name="components.optional"></a>12.5.�Optional files</h2></div></div></div>
 <div class="sect2">
 <div class="titlepage"><div><div><h3 class="title">
 <a name="components.optional.bin"></a>12.5.1.�Files affecting the binary package</h3></div></div></div>
 <div class="variablelist"><dl class="variablelist">
 <dt><span class="term"><code class="filename">INSTALL</code></span></dt>
 <dd>
 <p>This shell script is invoked twice by <a class="citerefentry" href="https://man.NetBSD.org/NetBSD-9.2/i386/pkg_add.1"><span class="citerefentry"><span class="refentrytitle">pkg_add</span>(1)</span></a>.
 	    First time after package extraction and before files are
 	    moved in place, the second time after the files to install
 	    are moved in place. This can be used to do any custom
 	    procedures not possible with @exec commands in
 	    <code class="filename">PLIST</code>. See <a class="citerefentry" href="https://man.NetBSD.org/NetBSD-9.2/i386/pkg_add.1"><span class="citerefentry"><span class="refentrytitle">pkg_add</span>(1)</span></a> and
 	    <a class="citerefentry" href="https://man.NetBSD.org/NetBSD-9.2/i386/pkg_create.1"><span class="citerefentry"><span class="refentrytitle">pkg_create</span>(1)</span></a> for more information.  See also <a class="xref" href="#files-and-dirs-outside-prefix" title="20.1.�Files and directories outside the installation prefix">Section�20.1, &#8220;Files and directories outside the installation prefix&#8221;</a>.
 	    Please note that you can modify variables in it easily by using
 	    <code class="varname">FILES_SUBST</code> in the package's
 	    <code class="filename">Makefile</code>:</p>
 <pre class="programlisting">
 FILES_SUBST+=  SOMEVAR="somevalue"
 </pre>
 <p>replaces "@SOMEVAR@" with <span class="quote">&#8220;<span class="quote">somevalue</span>&#8221;</span> in the
 	    <code class="filename">INSTALL</code>.  By default, substitution is
 	    performed for <code class="varname">PREFIX</code>,
 	    <code class="varname">LOCALBASE</code>, <code class="varname">X11BASE</code>,
 	    <code class="varname">VARBASE</code>, and a few others, type
 	    <span class="command"><strong>make help topic=FILES_SUBST</strong></span> for a
 	    complete list.</p>
 </dd>
 <dt><span class="term"><code class="filename">DEINSTALL</code></span></dt>
 <dd><p>This script is executed before and after any files are removed.  It is
 	    this script's responsibility to clean up any additional messy details
 	    around the package's installation, since all pkg_delete knows is how to
 	    delete the files created in the original distribution.
 	    See <a class="citerefentry" href="https://man.NetBSD.org/NetBSD-9.2/i386/pkg_delete.1"><span class="citerefentry"><span class="refentrytitle">pkg_delete</span>(1)</span></a>
 	    and <a class="citerefentry" href="https://man.NetBSD.org/NetBSD-9.2/i386/pkg_create.1"><span class="citerefentry"><span class="refentrytitle">pkg_create</span>(1)</span></a> for more information.
 	    The same methods to replace variables can be used as for
 	    the <code class="filename">INSTALL</code> file.</p></dd>
 <dt><span class="term"><code class="filename">MESSAGE</code></span></dt>
 <dd>
 <p>This file is displayed after installation of the package.
 	    While this was used often in the past, it has two
 	    problems: the display will be missed if many packages are
 	    intalled at once, and the person installing the package
 	    and the one using or configuring it may be different.  It
 	    should therefore be used only in exceptional circumstances
 	    where lasting negative consequences would result from
 	    someone not reading it.</p>
 <p>MESSAGE should not be used for:</p>
 <div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; ">
 <li class="listitem"><p>exhortations to read the documentation</p></li>
 <li class="listitem"><p>reminders to install rc.d files and set variables</p></li>
 <li class="listitem"><p>anything that should be explained in the
 	      installation/configuration documentation that should
 	      come with the package</p></li>
 </ul></div>
 <p>If the documentation provided by upstream needs
 	    enhancing, create e.g. files/README.pkgsrc and install it
 	    in the package's documentation directory.
 	    </p>
 <p>Note that MESSAGE is shown for all operating
 	    systems and all init systems.  If a MESSAGE is necessary,
 	    it should be narrowed to only those operating systems and
 	    init systems to which it applies.</p>
 <p>Note that you can modify variables in it easily by using
 	    <code class="varname">MESSAGE_SUBST</code> in the package's
 	    <code class="filename">Makefile</code>:</p>
 <pre class="programlisting">
 MESSAGE_SUBST+=  SOMEVAR="somevalue"
 </pre>
 <p>replaces "${SOMEVAR}" with <span class="quote">&#8220;<span class="quote">somevalue</span>&#8221;</span> in
 	    <code class="filename">MESSAGE</code>.  By default, substitution is
 	    performed for <code class="varname">PKGNAME</code>,
 	    <code class="varname">PKGBASE</code>, <code class="varname">PREFIX</code>,
 	    <code class="varname">LOCALBASE</code>, <code class="varname">X11BASE</code>,
 	    <code class="varname">PKG_SYSCONFDIR</code>,
 	    <code class="varname">ROOT_GROUP</code>, and
 	    <code class="varname">ROOT_USER</code>.</p>
 <p>You can display a different or additional files by
 	    setting the <code class="varname">MESSAGE_SRC</code> variable.  Its
 	    default is <code class="filename">MESSAGE</code>, if the file
 	    exists.</p>
 </dd>
 <dt><span class="term"><code class="filename">ALTERNATIVES</code></span></dt>
 <dd>
 <p>This file is used by the alternatives framework.
 	    It creates, configures, and destroys generic wrappers used to
 	    run programs with similar interfaces.
 	    See pkg_alternatives(8) from pkgtools/pkg_alternatives
             for more information.</p>
 <p>Each line of the file contains two filenames, first
 	    the wrapper and then the alternative provided by the package.
 	    Both paths are relative to <code class="varname">PREFIX</code>.</p>
 </dd>
 </dl></div>
 </div>
 <div class="sect2">
 <div class="titlepage"><div><div><h3 class="title">
 <a name="components.optional.build"></a>12.5.2.�Files affecting the build process</h3></div></div></div>
 <div class="variablelist"><dl class="variablelist">
 <dt><span class="term"><code class="filename">Makefile.common</code></span></dt>
 <dd><p>This file contains arbitrary things that could
 	also go into a <code class="filename">Makefile</code>, but its purpose is
 	to be used by more than one package. This file should only be
 	used when the packages that will use the file are known in
 	advance. For other purposes it is often better to write a
 	<code class="filename">*.mk</code> file and give it a good name that
 	describes what it does.</p></dd>
 <dt><span class="term"><code class="filename">buildlink3.mk</code></span></dt>
 <dd><p>This file contains the dependency information
 	for the buildlink3 framework (see <a class="xref" href="#buildlink" title="Chapter�18.�Buildlink methodology">Chapter�18, <i>Buildlink methodology</i></a>).</p></dd>
 <dt><span class="term"><code class="filename">hacks.mk</code></span></dt>
 <dd><p>This file contains workarounds for compiler bugs
 	and similar things. It is included automatically by the pkgsrc
 	infrastructure, so you don't need an extra
 	<code class="literal">.include</code> line for
 	it.</p></dd>
 <dt><span class="term"><code class="filename">options.mk</code></span></dt>
 <dd><p>This file contains the code for the
 	package-specific options (see <a class="xref" href="#options" title="Chapter�16.�Options handling">Chapter�16, <i>Options handling</i></a>) that can be
 	selected by the user. If a package has only one or two options,
 	it is equally acceptable to put the code directly into the
 	<code class="filename">Makefile</code>.</p></dd>
 </dl></div>
 </div>
 <div class="sect2">
 <div class="titlepage"><div><div><h3 class="title">
 <a name="components.optional.none"></a>12.5.3.�Files affecting nothing at all</h3></div></div></div>
 <div class="variablelist"><dl class="variablelist">
 <dt><span class="term"><code class="filename">README*</code></span></dt>
 <dd><p>These files do not take place in the creation of
 	a package and thus are purely informative to the package
 	developer.</p></dd>
 <dt><span class="term"><code class="filename">TODO</code></span></dt>
 <dd><p>This file contains things that need to be done
 	to make the package even
 	better.</p></dd>
 </dl></div>
 </div>
 </div>
 <div class="sect1">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
 <a name="work-dir"></a>12.6.�<code class="filename">work*</code>
 </h2></div></div></div>
 <p>When you type <span class="command"><strong>make</strong></span>, the distribution files are
     unpacked into the directory denoted by
     <code class="varname">WRKDIR</code>. It can be removed by running
     <span class="command"><strong>make clean</strong></span>. Besides the sources, this
     directory is also used to keep various timestamp files.
     The directory gets <span class="emphasis"><em>removed completely</em></span> on clean.
     The default is <code class="filename">${.CURDIR}/work</code>
     or <code class="filename">${.CURDIR}/work.${MACHINE_ARCH}</code>
     if <code class="varname">OBJMACHINE</code> is set.</p>
 </div>
 <div class="sect1">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
 <a name="files-dir"></a>12.7.�<code class="filename">files/*</code>
 </h2></div></div></div>
 <p>If you have any files that you wish to be placed in the package
     prior to configuration or building, you can place these files here
     and use a <span class="command"><strong>${CP}</strong></span> command in the
     <span class="quote">&#8220;<span class="quote">post-extract</span>&#8221;</span> target to achieve this.</p>
 <p>If you want to share files in this way with other
     packages, set the <code class="varname">FILESDIR</code> variable to point
     to the other package's <code class="filename">files</code> directory,
     e.g.:</p>
 <pre class="programlisting">
 FILESDIR=       ../../editors/xemacs/files
 </pre>
 </div>
 </div>
 <div class="chapter">
 <div class="titlepage"><div><div><h2 class="title">
 <a name="build"></a>Chapter�13.�The build process</h2></div></div></div>
 <div class="toc">
 <p><b>Table of Contents</b></p>
 <dl class="toc">
 <dt><span class="sect1"><a href="#build.intro">13.1. Introduction</a></span></dt>
 <dt><span class="sect1"><a href="#build.prefix">13.2. Program location</a></span></dt>
 <dt><span class="sect1"><a href="#build.builddirs">13.3. Directories used during the build process</a></span></dt>
 <dt><span class="sect1"><a href="#build.running">13.4. Running a phase</a></span></dt>
 <dt><span class="sect1"><a href="#build.fetch">13.5. The <span class="emphasis"><em>fetch</em></span> phase</a></span></dt>
 <dd><dl>
 <dt><span class="sect2"><a href="#build.fetch.what">13.5.1. What to fetch and where to get it from</a></span></dt>
 <dt><span class="sect2"><a href="#build.fetch.how">13.5.2. How are the files fetched?</a></span></dt>
 </dl></dd>
 <dt><span class="sect1"><a href="#build.checksum">13.6. The <span class="emphasis"><em>checksum</em></span> phase</a></span></dt>
 <dt><span class="sect1"><a href="#build.extract">13.7. The <span class="emphasis"><em>extract</em></span> phase</a></span></dt>
 <dt><span class="sect1"><a href="#build.patch">13.8. The <span class="emphasis"><em>patch</em></span> phase</a></span></dt>
 <dt><span class="sect1"><a href="#build.tools">13.9. The <span class="emphasis"><em>tools</em></span> phase</a></span></dt>
 <dt><span class="sect1"><a href="#build.wrapper">13.10. The <span class="emphasis"><em>wrapper</em></span> phase</a></span></dt>
 <dt><span class="sect1"><a href="#build.configure">13.11. The <span class="emphasis"><em>configure</em></span> phase</a></span></dt>
 <dt><span class="sect1"><a href="#build.build">13.12. The <span class="emphasis"><em>build</em></span> phase</a></span></dt>
 <dt><span class="sect1"><a href="#build.test">13.13. The <span class="emphasis"><em>test</em></span> phase</a></span></dt>
 <dt><span class="sect1"><a href="#build.install">13.14. The <span class="emphasis"><em>install</em></span> phase</a></span></dt>
 <dt><span class="sect1"><a href="#build.package">13.15. The <span class="emphasis"><em>package</em></span> phase</a></span></dt>
 <dt><span class="sect1"><a href="#build.clean">13.16. Cleaning up</a></span></dt>
 <dt><span class="sect1"><a href="#build.helpful-targets">13.17. Other helpful targets</a></span></dt>
 </dl>
 </div>
 <div class="sect1">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
 <a name="build.intro"></a>13.1.�Introduction</h2></div></div></div>
 <p>This chapter gives a detailed description on how a package is
     built. Building a package is separated into different
     <span class="emphasis"><em>phases</em></span> (for example <code class="varname">fetch</code>,
     <code class="varname">build</code>, <code class="varname">install</code>), all of which are
     described in the following sections. Each phase is split into
     so-called <span class="emphasis"><em>stages</em></span>, which take the name of the
     containing phase, prefixed by one of <code class="varname">pre-</code>,
     <code class="varname">do-</code> or <code class="varname">post-</code>. (Examples are
     <code class="varname">pre-configure</code>, <code class="varname">post-build</code>.) Most
     of the actual work is done in the <code class="varname">do-*</code> stages.</p>
 <p>Never override the regular targets (like
     <code class="varname">fetch</code>), if you have to, override the
     <code class="varname">do-*</code> ones instead.</p>
 <p>The basic steps for building a program are always the same.  First
     the program's source (<span class="emphasis"><em>distfile</em></span>) must be brought to
     the local system and then extracted. After any pkgsrc-specific patches
     to compile properly are applied, the software can be configured, then
     built (usually by compiling), and finally the generated binaries, etc.
     can be put into place on the system.</p>
 <p>To get more details about what is happening at each step,
     you can set the <code class="varname">PKG_VERBOSE</code> variable, or the
     <code class="varname">PATCH_DEBUG</code> variable if you are just interested
     in more details about the <span class="emphasis"><em>patch</em></span> step.</p>
 </div>
 <div class="sect1">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
 <a name="build.prefix"></a>13.2.�Program location</h2></div></div></div>
 <p>Before outlining the process performed by the NetBSD package system in
     the next section, here's a brief discussion on where programs are
     installed, and which variables influence this.</p>
 <p>The automatic variable <code class="varname">PREFIX</code> indicates
     where all files of the final program shall be installed. It is
     usually set to <code class="varname">LOCALBASE</code>
     (<code class="filename">/usr/pkg</code>), or <code class="varname">CROSSBASE</code>
     for pkgs in the <code class="filename">cross</code> category.  The value of
     <code class="varname">PREFIX</code> needs to be put
     into the various places in the program's source where paths to
     these files are encoded.  See <a class="xref" href="#components.patches" title="12.3.�patches/*">Section�12.3, &#8220;<code class="filename">patches/*</code>&#8221;</a> and <a class="xref" href="#fixes.libtool" title="21.3.1.�Shared libraries - libtool">Section�21.3.1, &#8220;Shared libraries - libtool&#8221;</a> for more details.</p>
 <p>When choosing which of these variables to use,
     follow the following rules:</p>
 <div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; ">
 <li class="listitem"><p><code class="varname">PREFIX</code> always points to the location
 	where the current pkg will be installed.  When referring to a
 	pkg's own installation path, use
 	<span class="quote">&#8220;<span class="quote">${PREFIX}</span>&#8221;</span>.</p></li>
 <li class="listitem"><p><code class="varname">LOCALBASE</code> is where all pkgs
 	are installed.  If you need to construct a -I or -L argument
 	to the compiler to find includes and libraries installed by
 	another pkg, use <span class="quote">&#8220;<span class="quote">${LOCALBASE}</span>&#8221;</span>. The name
 	<code class="varname">LOCALBASE</code> stems from FreeBSD, which
 	installed all packages in <code class="filename">/usr/local</code>. As
 	pkgsrc leaves <code class="filename">/usr/local</code> for the system
 	administrator, this variable is a misnomer.</p></li>
 <li class="listitem"><p><code class="varname">X11BASE</code> is where the actual X11
 	distribution (from xsrc, etc.) is installed. When looking for
 	<span class="emphasis"><em>standard</em></span> X11 includes (not those
 	installed by a package), use <span class="quote">&#8220;<span class="quote">${X11BASE}</span>&#8221;</span>.</p></li>
 <li class="listitem"><p>X11-based packages using imake must set
 	<code class="varname">USE_IMAKE</code> to be installed correctly under
 	<code class="varname">LOCALBASE</code>.</p></li>
 <li class="listitem"><p>Within <code class="filename">${PREFIX}</code>, packages should
 	install files according to <a class="citerefentry" href="https://man.NetBSD.org/NetBSD-9.2/i386/hier.7"><span class="citerefentry"><span class="refentrytitle">hier</span>(7)</span></a>, with the exception that
 	manual pages go into <code class="filename">${PREFIX}/man</code>, not
 	<code class="filename">${PREFIX}/share/man</code>.</p></li>
 </ul></div>
 </div>
 <div class="sect1">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
 <a name="build.builddirs"></a>13.3.�Directories used during the build process</h2></div></div></div>
 <p>When building a package, various directories are used to store
     source files, temporary files, pkgsrc-internal files, and so on. These
     directories are explained here.</p>
 <p>Some of the directory variables contain relative pathnames. There
     are two common base directories for these relative directories:
     <code class="varname">PKGSRCDIR/PKGPATH</code> is used for directories that are
     pkgsrc-specific. <code class="varname">WRKSRC</code> is used for directories
     inside the package itself.</p>
 <div class="variablelist"><dl class="variablelist">
 <dt><span class="term"><code class="varname">PKGSRCDIR</code></span></dt>
 <dd><p>This is an absolute pathname that points to the pkgsrc
       root directory. Generally, you don't need
       it.</p></dd>
 <dt><span class="term"><code class="varname">PKGDIR</code></span></dt>
 <dd><p>This is an absolute pathname that points to the
       current package.</p></dd>
 <dt><span class="term"><code class="varname">PKGPATH</code></span></dt>
 <dd><p>This is a pathname relative to
       <code class="varname">PKGSRCDIR</code> that points to the current
       package.</p></dd>
 <dt><span class="term"><code class="varname">WRKDIR</code></span></dt>
 <dd><p>This is an absolute pathname pointing to the directory
       where all work takes place. The distfiles are extracted to this
       directory. It also contains temporary directories and log files used by
       the various pkgsrc frameworks, like <span class="emphasis"><em>buildlink</em></span> or
       the <span class="emphasis"><em>wrappers</em></span>.</p></dd>
 <dt><span class="term"><code class="varname">WRKSRC</code></span></dt>
 <dd><p>This is an absolute pathname pointing to the directory
       where the distfiles are extracted. It is usually a direct subdirectory
       of <code class="varname">WRKDIR</code>, and often it's the only directory entry
       that isn't hidden. This variable may be changed by a package
       <code class="filename">Makefile</code>.</p></dd>
 </dl></div>
 <p>The <code class="varname">CREATE_WRKDIR_SYMLINK</code> definition takes either
     the value <span class="emphasis"><em>yes</em></span> or <span class="emphasis"><em>no</em></span> and defaults
     to <span class="emphasis"><em>no</em></span>. It indicates whether a symbolic link to the
     <code class="varname">WRKDIR</code> is to be created in the pkgsrc entry's directory.
     If users would like to have their pkgsrc trees behave in a
     read-only manner, then the value of
     <code class="varname">CREATE_WRKDIR_SYMLINK</code> should be set to
     <span class="emphasis"><em>no</em></span>.</p>
 </div>
 <div class="sect1">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
 <a name="build.running"></a>13.4.�Running a phase</h2></div></div></div>
 <p>You can run a particular phase by typing <span class="command"><strong>make
     phase</strong></span>, where <span class="emphasis"><em>phase</em></span> is the name of the
     phase. This will automatically run all phases that are required for this
     phase. The default phase is <code class="varname">build</code>, that is, when you
     run <span class="command"><strong>make</strong></span> without parameters in a package directory,
     the package will be built, but not installed.</p>
 </div>
 <div class="sect1">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
 <a name="build.fetch"></a>13.5.�The <span class="emphasis"><em>fetch</em></span> phase</h2></div></div></div>
 <p>The first step in building a package is to fetch the
     distribution files (distfiles) from the sites that are providing
     them. This is the task of the <span class="emphasis"><em>fetch</em></span>
     phase.</p>
 <div class="sect2">
 <div class="titlepage"><div><div><h3 class="title">
 <a name="build.fetch.what"></a>13.5.1.�What to fetch and where to get it from</h3></div></div></div>
 <p>In simple cases, <code class="varname">MASTER_SITES</code>
       defines all URLs from where the distfile, whose name is
       derived from the <code class="varname">DISTNAME</code> variable, is
       fetched. The more complicated cases are described
       below.</p>
 <p>The variable <code class="varname">DISTFILES</code> specifies
       the list of distfiles that have to be fetched. Its value
       defaults to <code class="literal">${DEFAULT_DISTFILES}</code> and
       its value is <code class="literal">${DISTNAME}${EXTRACT_SUFX}</code>,
       so that most packages don't need to define it at all.
       <code class="varname">EXTRACT_SUFX</code> is
       <code class="literal">.tar.gz</code> by default, but can be changed
       freely. Note that if your package requires additional
       distfiles to the default one, you cannot just append the
       additional filenames using the <code class="literal">+=</code>
       operator, but you have write for example:</p>
 <pre class="programlisting">
 DISTFILES=      ${DEFAULT_DISTFILES} additional-files.tar.gz
 </pre>
 <p>Each distfile is fetched from a list of sites, usually
       <code class="varname">MASTER_SITES</code>. If the package has multiple
       <code class="varname">DISTFILES</code> or multiple
       <code class="varname">PATCHFILES</code> from different sites, you can
       set
       <code class="varname">SITES.<em class="replaceable"><code>distfile</code></em></code>
       to the list of URLs where the file
       <code class="filename"><em class="replaceable"><code>distfile</code></em></code>
       (including the suffix) can be found.</p>
 <pre class="programlisting">
 DISTFILES=      ${DISTNAME}${EXTRACT_SUFX}
 DISTFILES+=     foo-file.tar.gz
 SITES.foo-file.tar.gz= \
 https://www.somewhere.com/somehow/ \
 https://www.somewhereelse.com/mirror/somehow/
 </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=   https://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. You can use this style
       for the case when the download URL style does not match the
       above common case. For example, if permanent download URL is a
       redirector to the real download URL, or the download file name
       is offered by an HTTP Content-Disposition header. In the
       following example, <code class="filename">foo-1.0.0.tar.gz</code> will be
       created instead of the default
       <code class="filename">v1.0.0.tar.gz</code>.</p>
 <pre class="programlisting">
 DISTNAME=       foo-1.0.0
 MASTER_SITES=   -https://www.example.com/archive/v1.0.0.tar.gz
 </pre>
 <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>
 <table border="0" summary="Simple list" class="simplelist">
 <tr>
 <td>MASTER_SITE_APACHE</td>
 <td>MASTER_SITE_BACKUP</td>
 </tr>
 <tr>
 <td>MASTER_SITE_CRATESIO</td>
 <td>MASTER_SITE_CYGWIN</td>
 </tr>
 <tr>
 <td>MASTER_SITE_DEBIAN</td>
 <td>MASTER_SITE_FREEBSD</td>
 </tr>
 <tr>
 <td>MASTER_SITE_FREEBSD_LOCAL</td>
 <td>MASTER_SITE_GENTOO</td>
 </tr>
 <tr>
 <td>MASTER_SITE_GITHUB</td>
-<td>MASTER_SITE_GNOME</td>
+<td>MASTER_SITE_GITLAB</td>
 </tr>
 <tr>
 <td>MASTER_SITE_GNOME</td>
 <td>MASTER_SITE_GNU</td>
 <td>MASTER_SITE_GNUSTEP</td>
 </tr>
 <tr>
 <td>MASTER_SITE_GNUSTEP</td>
 <td>MASTER_SITE_HASKELL_HACKAGE</td>
 <td>MASTER_SITE_IFARCHIVE</td>
 </tr>
 <tr>
 <td>MASTER_SITE_IFARCHIVE</td>
 <td>MASTER_SITE_KDE</td>
 <td>MASTER_SITE_MOZILLA</td>
 </tr>
 <tr>
 <td>MASTER_SITE_MOZILLA</td>
 <td>MASTER_SITE_MOZILLA_ALL</td>
 <td>MASTER_SITE_MYSQL</td>
 </tr>
 <tr>
 <td>MASTER_SITE_MYSQL</td>
 <td>MASTER_SITE_NETLIB</td>
 <td>MASTER_SITE_OPENBSD</td>
 </tr>
 <tr>
 <td>MASTER_SITE_OPENBSD</td>
 <td>MASTER_SITE_OPENOFFICE</td>
 <td>MASTER_SITE_OSDN</td>
 </tr>
 <tr>
 <td>MASTER_SITE_OSDN</td>
 <td>MASTER_SITE_PERL_CPAN</td>
 <td>MASTER_SITE_PGSQL</td>
 </tr>
 <tr>
 <td>MASTER_SITE_PGSQL</td>
 <td>MASTER_SITE_PYPI</td>
 <td>MASTER_SITE_RUBYGEMS</td>
 </tr>
 <tr>
 <td>MASTER_SITE_RUBYGEMS</td>
 <td>MASTER_SITE_R_CRAN</td>
 <td>MASTER_SITE_SOURCEFORGE</td>
 </tr>
 <tr>
 <td>MASTER_SITE_SOURCEFORGE</td>
 <td>MASTER_SITE_SUNSITE</td>
 <td>MASTER_SITE_SUSE</td>
 </tr>
 <tr>
 <td>MASTER_SITE_SUSE</td>
 <td>MASTER_SITE_TEX_CTAN</td>
 <td>MASTER_SITE_XCONTRIB</td>
 </tr>
 <tr>
 <td>MASTER_SITE_XCONTRIB</td>
 <td>MASTER_SITE_XEMACS</td>
 </tr>
 <tr>
 <td>MASTER_SITE_XORG</td>
 <td>�</td>
 </tr>
 </table>
 <p>Some explanations for the less self-explaining ones:
       <code class="varname">MASTER_SITE_BACKUP</code> contains backup sites
       for packages that are maintained in <a class="ulink" href="ftp://ftp.NetBSD.org/pub/pkgsrc/distfiles/%24%7BDIST_SUBDIR%7D" target="_top">ftp://ftp.NetBSD.org/pub/pkgsrc/distfiles/${DIST_SUBDIR}</a>.  <code class="varname">MASTER_SITE_LOCAL</code> contains local
       package source distributions that are maintained in <a class="ulink" href="ftp://ftp.NetBSD.org/pub/pkgsrc/distfiles/LOCAL_PORTS/" target="_top">ftp://ftp.NetBSD.org/pub/pkgsrc/distfiles/LOCAL_PORTS/</a>.</p>
 <p>If you choose one of these predefined sites, you may
       want to specify a subdirectory of that site. Since these
       macros may expand to more than one actual site, you
       <span class="emphasis"><em>must</em></span> use the following construct to
       specify a subdirectory:</p>
 <pre class="programlisting">
 MASTER_SITES=   ${MASTER_SITE_GNU:=subdirectory/name/}
 MASTER_SITES=   ${MASTER_SITE_SOURCEFORGE:=project_name/}
 </pre>
 <p>Note the trailing slash after the subdirectory
       name.</p>
 </div>
 <div class="sect2">
 <div class="titlepage"><div><div><h3 class="title">
 <a name="build.fetch.how"></a>13.5.2.�How are the files fetched?</h3></div></div></div>
 <p>The <span class="emphasis"><em>fetch</em></span> phase makes sure that
       all the distfiles exist in a local directory
       (<code class="varname">DISTDIR</code>, which can be set by the pkgsrc
       user). If the files do not exist, they are fetched using
       commands of the form</p>
 <pre class="programlisting">
 ${FETCH_CMD} ${FETCH_BEFORE_ARGS} ${site}${file} ${FETCH_AFTER_ARGS}
 </pre>
 <p>where <code class="literal">${site}</code> varies through
       several possibilities in turn: first,
       <code class="varname">MASTER_SITE_OVERRIDE</code> is tried, then the
       sites specified in either <code class="varname">SITES.file</code> if
       defined, else <code class="varname">MASTER_SITES</code> or
       <code class="varname">PATCH_SITES</code>, as applies, then finally the
       value of <code class="varname">MASTER_SITE_BACKUP</code>. The order of
       all except the first and the last can be optionally sorted
       by the user, via setting either
       <code class="varname">MASTER_SORT_RANDOM</code>, and
       <code class="varname">MASTER_SORT_AWK</code> or
       <code class="varname">MASTER_SORT_REGEX</code>.</p>
 <p> The specific command and arguments used depend on the
       <code class="varname">FETCH_USING</code> parameter. The example above is
       for <code class="literal">FETCH_USING=custom</code>.</p>
 <p>The distfiles mirror run by the NetBSD Foundation uses the
       <span class="emphasis"><em>mirror-distfiles</em></span> target to mirror the
       distfiles, if they are freely distributable.  Packages setting
       <code class="varname">NO_SRC_ON_FTP</code> (usually to
       <span class="quote">&#8220;<span class="quote">${RESTRICTED}</span>&#8221;</span>) will not have their distfiles
       mirrored.</p>
 </div>
 </div>
 <div class="sect1">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
 <a name="build.checksum"></a>13.6.�The <span class="emphasis"><em>checksum</em></span> phase</h2></div></div></div>
 <p>After the distfile(s) are fetched, their checksum is
     generated and compared with the checksums stored in the
     distinfo file. If the checksums don't match, the build is
     aborted. This is to ensure the same distfile is used for
     building, and that the distfile wasn't changed, e.g. by some
     malign force, deliberately changed distfiles on the master
     distribution site or network lossage.</p>
 </div>
 <div class="sect1">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
 <a name="build.extract"></a>13.7.�The <span class="emphasis"><em>extract</em></span> phase</h2></div></div></div>
 <p>When the distfiles are present on the local system, they
     need to be extracted, as they usually come in the form of some
     compressed archive format.</p>
 <p>By default, all <code class="varname">DISTFILES</code> are
     extracted. If you only need some of them, you can set the
     <code class="varname">EXTRACT_ONLY</code> variable to the list of those
     files.</p>
 <p>Extracting the files is usually done by a little
     program, <code class="filename">mk/extract/extract</code>, which
     already knows how to extract various archive formats, so most
     likely you will not need to change anything here. But if you
     need, the following variables may help you:</p>
 <div class="variablelist"><dl class="variablelist">
 <dt><span class="term"><code class="varname">EXTRACT_OPTS_{BIN,LHA,PAX,RAR,TAR,ZIP,ZOO}</code></span></dt>
 <dd><p>Use these variables to override the default
       options for an extract command, which are defined in
       <code class="filename">mk/extract/extract</code>.</p></dd>
 <dt><span class="term"><code class="varname">EXTRACT_USING</code></span></dt>
 <dd><p>This variable can be set to
       <code class="literal">bsdtar</code>, <code class="literal">gtar</code>, <code class="literal">nbtar</code>
       (which is the default value), <code class="literal">pax</code>, or an
       absolute pathname pointing to the command with which tar
       archives should be extracted.  It is preferred to choose bsdtar over gtar
       if NetBSD's pax-as-tar is not good enough.</p></dd>
 </dl></div>
 <p>If the <code class="filename">extract</code> program doesn't
     serve your needs, you can also override the
     <code class="varname">EXTRACT_CMD</code> variable, which holds the
     command used for extracting the files. This command is
     executed in the <code class="filename">${WRKSRC}</code>
     directory. During execution of this command, the shell
     variable <code class="varname">extract_file</code> holds the absolute
     pathname of the file that is going to be extracted.</p>
 <p>And if that still does not suffice, you can override the
     <code class="varname">do-extract</code> target in the package
     Makefile.</p>
 </div>
 <div class="sect1">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
 <a name="build.patch"></a>13.8.�The <span class="emphasis"><em>patch</em></span> phase</h2></div></div></div>
 <p>After extraction, all the patches named by the
     <code class="varname">PATCHFILES</code>, those present in the patches
     subdirectory of the package as well as in
     $LOCALPATCHES/$PKGPATH (e.g.
     <code class="filename">/usr/local/patches/graphics/png</code>) are
     applied.  Patchfiles ending in <code class="filename">.Z</code> or
     <code class="filename">.gz</code> are uncompressed before they are
     applied, files ending in <code class="filename">.orig</code> or
     <code class="filename">.rej</code> are ignored. Any special options to
     <a class="citerefentry" href="https://man.NetBSD.org/NetBSD-9.2/i386/patch.1"><span class="citerefentry"><span class="refentrytitle">patch</span>(1)</span></a> can be handed in
     <code class="varname">PATCH_DIST_ARGS</code>.  See <a class="xref" href="#components.patches" title="12.3.�patches/*">Section�12.3, &#8220;<code class="filename">patches/*</code>&#8221;</a> for more details.</p>
 <p>By default <a class="citerefentry" href="https://man.NetBSD.org/NetBSD-9.2/i386/patch.1"><span class="citerefentry"><span class="refentrytitle">patch</span>(1)</span></a> is given special arguments to make it
     fail if the expected text from the patch context is not found in the
     patched file. If that happens, fix the patch file by comparing it
     with the actual text in the file to be patched.</p>
 </div>
 <div class="sect1">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
 <a name="build.tools"></a>13.9.�The <span class="emphasis"><em>tools</em></span> phase</h2></div></div></div>
 <p>This is covered in <a class="xref" href="#tools" title="Chapter�17.�Tools needed for building or running">Chapter�17, <i>Tools needed for building or running</i></a>.
     </p>
 </div>
 <div class="sect1">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
 <a name="build.wrapper"></a>13.10.�The <span class="emphasis"><em>wrapper</em></span> phase</h2></div></div></div>
 <p>This phase creates wrapper programs for the compilers and
     linkers. The following variables can be used to tweak the
     wrappers.</p>
 <div class="variablelist"><dl class="variablelist">
 <dt><span class="term"><code class="varname">ECHO_WRAPPER_MSG</code></span></dt>
 <dd><p>The command used to print progress
       messages. Does nothing by default. Set to
       <code class="literal">${ECHO}</code> to see the progress
       messages.</p></dd>
 <dt><span class="term"><code class="varname">WRAPPER_DEBUG</code></span></dt>
 <dd><p>This variable can be set to
       <code class="literal">yes</code> (default) or <code class="literal">no</code>,
       depending on whether you want additional information in the
       wrapper log file.</p></dd>
 <dt><span class="term"><code class="varname">WRAPPER_UPDATE_CACHE</code></span></dt>
 <dd><p>This variable can be set to
       <code class="literal">yes</code> or <code class="literal">no</code>, depending
       on whether the wrapper should use its cache, which will
       improve the speed. The default value is
       <code class="literal">yes</code>, but is forced to
       <code class="literal">no</code> if the platform does not support
       it.</p></dd>
 <dt><span class="term"><code class="varname">WRAPPER_REORDER_CMDS</code></span></dt>
 <dd><p>A list of reordering commands. A reordering
       command has the form
       <code class="literal">reorder:l:<em class="replaceable"><code>lib1</code></em>:<em class="replaceable"><code>lib2</code></em></code>.
       It ensures that that
       <code class="literal">-l<em class="replaceable"><code>lib1</code></em></code> occurs
       before <code class="literal">-l<em class="replaceable"><code>lib2</code></em></code>.
       </p></dd>
 </dl></div>
 </div>
 <div class="sect1">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
 <a name="build.configure"></a>13.11.�The <span class="emphasis"><em>configure</em></span> phase</h2></div></div></div>
 <p>Most pieces of software need information on the header
     files, system calls, and library routines which are available
     on the platform they run on. The process of determining this
     information is known as configuration, and is usually
     automated. In most cases, a script is supplied with the
     distfiles, and its invocation results in generation of header
     files, Makefiles, etc.</p>
 <p>If the package contains a configure script, this can be
     invoked by setting <code class="varname">HAS_CONFIGURE</code> to
     <span class="quote">&#8220;<span class="quote">yes</span>&#8221;</span>. If the configure script is a GNU autoconf
     script, you should set <code class="varname">GNU_CONFIGURE</code> to
     <span class="quote">&#8220;<span class="quote">yes</span>&#8221;</span> instead.</p>
 <p>In the <code class="literal">do-configure</code> stage, a rough
     equivalent of the following command is run. See
     <code class="filename">mk/configure/configure.mk</code>, target
     <code class="literal">do-configure-script</code> for the exact
     definition.</p>
 <pre class="programlisting">
 .for dir in ${CONFIGURE_DIRS}
         cd ${WRKSRC} &amp;&amp; cd ${dir} \
         &amp;&amp; env ${CONFIGURE_ENV} \
             ${CONFIG_SHELL} ${CONFIGURE_SCRIPT} ${CONFIGURE_ARGS}
 .endfor
 </pre>
 <p><code class="varname">CONFIGURE_DIRS</code> (default:
     <span class="quote">&#8220;<span class="quote">.</span>&#8221;</span>) is a list of pathnames relative to
     <code class="varname">WRKSRC</code>. In each of these directories, the
     configure script is run with the environment
     <code class="varname">CONFIGURE_ENV</code> and arguments
     <code class="varname">CONFIGURE_ARGS</code>. The variables
     <code class="varname">CONFIGURE_ENV</code>,
     <code class="varname">CONFIGURE_SCRIPT</code> (default:
     <span class="quote">&#8220;<span class="quote">./configure</span>&#8221;</span>) and
     <code class="varname">CONFIGURE_ARGS</code> may all be changed by the
     package.</p>
 <p>If the program uses the Perl way of configuration (mainly Perl
     modules, but not only), i.e. a file called
     <code class="filename">Makefile.PL</code>, it should include
     <code class="filename">../../lang/perl5/module.mk</code>. To set any parameter for
     <code class="filename">Makefile.PL</code> use the <code class="varname">MAKE_PARAMS</code>
     variable (e.g., <code class="literal">MAKE_PARAMS+=foo=bar</code></p>
 <p>If the program uses an <code class="filename">Imakefile</code>
     for configuration, the appropriate steps can be invoked by
     setting <code class="varname">USE_IMAKE</code> to
     <span class="quote">&#8220;<span class="quote">yes</span>&#8221;</span>.  If you only need xmkmf, add it to <code class="varname">USE_TOOLS</code>.
     You can add variables to xmkmf's environment by adding them to the
     <code class="varname">SCRIPTS_ENV</code> variable.</p>
 <p>If the program uses <code class="filename">cmake</code>
     for configuration, the appropriate steps can be invoked by
     setting <code class="varname">USE_CMAKE</code> to <span class="quote">&#8220;<span class="quote">yes</span>&#8221;</span>.
     You can add variables to cmake's environment by adding them to the
     <code class="varname">CONFIGURE_ENV</code> variable and arguments to cmake
     by adding them to the <code class="varname">CMAKE_ARGS</code> variable.
     The top directory argument is given by the
     <code class="varname">CMAKE_ARG_PATH</code> variable, that defaults to
     <span class="quote">&#8220;<span class="quote">.</span>&#8221;</span> (relative to <code class="varname">CONFIGURE_DIRS</code>)</p>
 <p>If there is no configure step at all, set
     <code class="varname">NO_CONFIGURE</code> to <span class="quote">&#8220;<span class="quote">yes</span>&#8221;</span>.</p>
 </div>
 <div class="sect1">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
 <a name="build.build"></a>13.12.�The <span class="emphasis"><em>build</em></span> phase</h2></div></div></div>
 <p>For building a package, a rough equivalent of the following
     code is executed; see <code class="filename">mk/build/build.mk</code>, target
     <code class="literal">do-build</code> for the exact definition.</p>
 <pre class="programlisting">
 .for dir in ${BUILD_DIRS}
         cd ${WRKSRC} &amp;&amp; cd ${dir} \
         &amp;&amp; env ${MAKE_ENV} \
             ${MAKE_PROGRAM} ${MAKE_FLAGS} ${BUILD_MAKE_FLAGS} \
                 -f ${MAKE_FILE} \
                 ${BUILD_TARGET}
 .endfor
 </pre>
 <p><code class="varname">BUILD_DIRS</code> (default:
     <span class="quote">&#8220;<span class="quote">.</span>&#8221;</span>) is a list of pathnames relative to
     <code class="varname">WRKSRC</code>. In each of these directories,
     <code class="varname">MAKE_PROGRAM</code> is run with the environment
     <code class="varname">MAKE_ENV</code> and arguments
     <code class="varname">BUILD_MAKE_FLAGS</code>. The variables
     <code class="varname">MAKE_ENV</code>,
     <code class="varname">BUILD_MAKE_FLAGS</code>,
     <code class="varname">MAKE_FILE</code> and
     <code class="varname">BUILD_TARGET</code> may all be changed by the
     package.</p>
 <p>The default value of <code class="varname">MAKE_PROGRAM</code> is
     <span class="quote">&#8220;<span class="quote">gmake</span>&#8221;</span> if <code class="varname">USE_TOOLS</code> contains
     <span class="quote">&#8220;<span class="quote">gmake</span>&#8221;</span>, <span class="quote">&#8220;<span class="quote">make</span>&#8221;</span> otherwise. The
     default value of <code class="varname">MAKE_FILE</code> is
     <span class="quote">&#8220;<span class="quote">Makefile</span>&#8221;</span>, and <code class="varname">BUILD_TARGET</code>
     defaults to <span class="quote">&#8220;<span class="quote">all</span>&#8221;</span>.</p>
 <p>If there is no build step at all, set
     <code class="varname">NO_BUILD</code> to <span class="quote">&#8220;<span class="quote">yes</span>&#8221;</span>.</p>
 </div>
 <div class="sect1">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
 <a name="build.test"></a>13.13.�The <span class="emphasis"><em>test</em></span> phase</h2></div></div></div>
 <p>[TODO]</p>
 </div>
 <div class="sect1">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
 <a name="build.install"></a>13.14.�The <span class="emphasis"><em>install</em></span> phase</h2></div></div></div>
 <p>Once the build stage has completed, the final step is to
     install the software in public directories, so users can
     access the programs and files.</p>
 <p>In the <span class="emphasis"><em>install</em></span> phase, a rough equivalent
     of the following code is executed; see
     <code class="filename">mk/install/install.mk</code>, target
     <code class="literal">do-install</code> for the exact definition. Additionally,
     before and after this code, several consistency checks are run
     against the files-to-be-installed, see
     <code class="filename">mk/check/*.mk</code> for details.</p>
 <pre class="programlisting">
 .for dir in ${INSTALL_DIRS}
         cd ${WRKSRC} &amp;&amp; cd ${dir} \
         &amp;&amp; env ${INSTALL_ENV} ${MAKE_ENV} \
             ${MAKE_PROGRAM} ${MAKE_FLAGS} ${INSTALL_MAKE_FLAGS} \
                 -f ${MAKE_FILE} ${INSTALL_TARGET}
 .endfor
 </pre>
 <p>The variable's meanings are analogous to the ones in the
     <span class="emphasis"><em>build</em></span> phase.
     <code class="varname">INSTALL_DIRS</code> defaults to
     <code class="varname">BUILD_DIRS</code>. <code class="varname">INSTALL_TARGET</code>
     is <span class="quote">&#8220;<span class="quote">install</span>&#8221;</span> by default, plus
     <span class="quote">&#8220;<span class="quote">install.man</span>&#8221;</span> if <code class="varname">USE_IMAKE</code> is
     defined and <code class="varname">NO_INSTALL_MANPAGES</code> is not
     defined.</p>
 <p>In the <span class="emphasis"><em>install</em></span> phase, the following
     variables are useful. They are all variations of the
     <a class="citerefentry" href="https://man.NetBSD.org/NetBSD-9.2/i386/install.1"><span class="citerefentry"><span class="refentrytitle">install</span>(1)</span></a> command that have the owner, group and
     permissions preset. <code class="varname">INSTALL</code> is the plain
     install command. The specialized variants, together with their
     intended use, are:</p>
 <div class="variablelist"><dl class="variablelist">
 <dt><span class="term"><code class="varname">INSTALL_PROGRAM_DIR</code></span></dt>
 <dd><p>directories that contain
       binaries</p></dd>
 <dt><span class="term"><code class="varname">INSTALL_SCRIPT_DIR</code></span></dt>
 <dd><p>directories that contain
       scripts</p></dd>
 <dt><span class="term"><code class="varname">INSTALL_LIB_DIR</code></span></dt>
 <dd><p>directories that contain shared and static
       libraries</p></dd>
 <dt><span class="term"><code class="varname">INSTALL_DATA_DIR</code></span></dt>
 <dd><p>directories that contain data
       files</p></dd>
 <dt><span class="term"><code class="varname">INSTALL_MAN_DIR</code></span></dt>
 <dd><p>directories that contain man
       pages</p></dd>
 <dt><span class="term"><code class="varname">INSTALL_GAME_DIR</code></span></dt>
 <dd><p>directories that contain data files for games
       </p></dd>
 <dt><span class="term"><code class="varname">INSTALL_PROGRAM</code></span></dt>
 <dd><p>binaries that can be stripped from debugging
       symbols</p></dd>
 <dt><span class="term"><code class="varname">INSTALL_SCRIPT</code></span></dt>
 <dd><p>binaries that cannot be
       stripped</p></dd>
 <dt><span class="term"><code class="varname">INSTALL_GAME</code></span></dt>
 <dd><p>game
       binaries</p></dd>
 <dt><span class="term"><code class="varname">INSTALL_LIB</code></span></dt>
 <dd><p>shared and static
       libraries</p></dd>
 <dt><span class="term"><code class="varname">INSTALL_DATA</code></span></dt>
 <dd><p>data files</p></dd>
 <dt><span class="term"><code class="varname">INSTALL_GAME_DATA</code></span></dt>
 <dd><p>data files for
       games</p></dd>
 <dt><span class="term"><code class="varname">INSTALL_MAN</code></span></dt>
 <dd><p>man pages</p></dd>
 </dl></div>
 <p>Some other variables are:</p>
 <div class="variablelist"><dl class="variablelist">
 <dt><span class="term"><code class="varname">INSTALL_UNSTRIPPED</code></span></dt>
 <dd><p>If set to <code class="literal">yes</code>, do not run <a class="citerefentry" href="https://man.NetBSD.org/NetBSD-9.2/i386/strip.1"><span class="citerefentry"><span class="refentrytitle">strip</span>(1)</span></a>
       when installing binaries. Any debugging sections and symbols present in
       binaries will be preserved.
       </p></dd>
 <dt><span class="term"><code class="varname">INSTALLATION_DIRS</code></span></dt>
 <dd><p>A list of directories relative to
       <code class="varname">PREFIX</code> that are created by pkgsrc at the
       beginning of the <span class="emphasis"><em>install</em></span> phase.
       The package is supposed to create all needed directories itself
       before installing files to it and list all other directories here.
       </p></dd>
 </dl></div>
 <p>In the rare cases that a package shouldn't install anything,
     set <code class="varname">NO_INSTALL</code> to <span class="quote">&#8220;<span class="quote">yes</span>&#8221;</span>. This is
     mostly relevant for packages in the <code class="filename">regress</code>
     category.</p>
 </div>
 <div class="sect1">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
 <a name="build.package"></a>13.15.�The <span class="emphasis"><em>package</em></span> phase</h2></div></div></div>
 <p>Once the install stage has completed, a binary package of
     the installed files can be built.  These binary packages can be
     used for quick installation without previous compilation, e.g. by
     the <span class="command"><strong>make bin-install</strong></span> or by using
     <span class="command"><strong>pkg_add</strong></span>.</p>
 <p>By default, the binary packages are created in
     <code class="filename">${PACKAGES}/All</code> and symlinks are created in
     <code class="filename">${PACKAGES}/<em class="replaceable"><code>category</code></em></code>,
     one for each category in the <code class="varname">CATEGORIES</code>
     variable.  <code class="varname">PACKAGES</code> defaults to
     <code class="filename">pkgsrc/packages</code>.</p>
 </div>
 <div class="sect1">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
 <a name="build.clean"></a>13.16.�Cleaning up</h2></div></div></div>
 <p>Once you're finished with a package, you can clean the work
     directory by running <span class="command"><strong>make clean</strong></span>.  If you want
     to clean the work directories of all dependencies too, use
     <span class="command"><strong>make clean-depends</strong></span>.</p>
 </div>
 <div class="sect1">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
 <a name="build.helpful-targets"></a>13.17.�Other helpful targets</h2></div></div></div>
 <div class="variablelist"><dl class="variablelist">
 <dt><span class="term">pre/post-*</span></dt>
 <dd>
 <p>For any of the main targets described in the previous
 	  section (configure, build, install, etc.), two auxiliary
 	  targets exist with
 	  <span class="quote">&#8220;<span class="quote">pre-</span>&#8221;</span> and <span class="quote">&#8220;<span class="quote">post-</span>&#8221;</span> used as a
 	  prefix for the main target's name.  These targets are
 	  invoked before and after the main target is called,
 	  allowing extra configuration or installation steps be
 	  performed from a package's Makefile, for example, which
 	  a program's configure script or install target
 	  omitted.</p>
 <p>About 5% of the pkgsrc packages define their custom
 	  post-extract target, another 5% define pre-configure, and 10%
 	  define post-install. The other pre/post-* targets are defined
 	  even less often.</p>
 </dd>
 <dt><span class="term">do-*</span></dt>
 <dd>
 <p>Should one of the main targets do the wrong thing,
 	  and should there be no variable to fix this, you can
 	  redefine it with the do-* target.  (Note that redefining
 	  the target itself instead of the do-* target is a bad
 	  idea, as the pre-* and post-* targets won't be called
 	  anymore, etc.)</p>
 <p>About 15% of the pkgsrc packages override the default
 	  do-install, the other do-* targets are overridden even less
 	  often.</p>
 </dd>
 <dt><span class="term">reinstall</span></dt>
 <dd>
 <p>If you did a <span class="command"><strong>make install</strong></span> and
 	  you noticed some file was not installed properly, you
 	  can repeat the installation with this target, which will
 	  ignore the <span class="quote">&#8220;<span class="quote">already installed</span>&#8221;</span> flag.</p>
 <p>This is the default value of
 	  <code class="varname">DEPENDS_TARGET</code> except in the case of
 	  <span class="command"><strong>make update</strong></span> and <span class="command"><strong>make
 	  package</strong></span>, where the defaults are
 	  <span class="quote">&#8220;<span class="quote">package</span>&#8221;</span> and <span class="quote">&#8220;<span class="quote">update</span>&#8221;</span>,
 	  respectively.</p>
 </dd>
 <dt><span class="term">deinstall</span></dt>
 <dd>
 <p>This target does a <a class="citerefentry" href="https://man.NetBSD.org/NetBSD-9.2/i386/pkg_delete.1"><span class="citerefentry"><span class="refentrytitle">pkg_delete</span>(1)</span></a> in the
 	  current directory, effectively de-installing the
 	  package. The following variables can be used to tune the
 	  behaviour:</p>
 <div class="variablelist"><dl class="variablelist">
 <dt><span class="term"><code class="varname">PKG_VERBOSE</code></span></dt>
 <dd><p>Add a "-v" to the <a class="citerefentry" href="https://man.NetBSD.org/NetBSD-9.2/i386/pkg_delete.1"><span class="citerefentry"><span class="refentrytitle">pkg_delete</span>(1)</span></a> command.</p></dd>
 <dt><span class="term"><code class="varname">DEINSTALLDEPENDS</code></span></dt>
 <dd><p>Remove all packages that require (depend on)
 		the given package.  This can be used to remove any
 		packages that may have been pulled in by a given
 		package, e.g. if <span class="command"><strong>make deinstall
 		DEINSTALLDEPENDS=1</strong></span> is done in
 		<code class="filename">pkgsrc/x11/kde</code>, this is
 		likely to remove whole KDE. Works by adding
 		<span class="quote">&#8220;<span class="quote">-R</span>&#8221;</span> to the <a class="citerefentry" href="https://man.NetBSD.org/NetBSD-9.2/i386/pkg_delete.1"><span class="citerefentry"><span class="refentrytitle">pkg_delete</span>(1)</span></a>
 		command line.</p></dd>
 </dl></div>
 </dd>
 <dt><span class="term">bin-install</span></dt>
 <dd><p>Install a binary package from local disk and via FTP
 	  from a list of sites (see the
 	  <code class="varname">BINPKG_SITES</code> variable), and do a
 	  <span class="command"><strong>make package</strong></span> if no binary package is
 	  available anywhere.  The arguments given to
 	  <span class="command"><strong>pkg_add</strong></span> can be set via
 	  <code class="varname">BIN_INSTALL_FLAGS</code> e.g., to do verbose
 	  operation, etc.</p></dd>
 <dt><span class="term">install-clean</span></dt>
 <dd><p>This target removes the state files for the "install" and later
 	  phases so that the "install" target may be re-invoked. This can be
 	  used after editing the PLIST to install the package without
 	  rebuilding it.</p></dd>
 <dt><span class="term">build-clean</span></dt>
 <dd><p>This target removes the state files for the "build" and later
 	  phases so that the "build" target may be re-invoked.</p></dd>
 <dt><span class="term">update</span></dt>
 <dd>
 <p>This target causes the current package to be
 	  updated to the latest version.  The package and all
 	  depending packages first get de-installed, then current
 	  versions of the corresponding packages get compiled and
 	  installed.  This is similar to manually noting which
 	  packages are currently installed, then performing a
 	  series of <span class="command"><strong>make deinstall</strong></span> and
 	  <span class="command"><strong>make install</strong></span> (or whatever
 	  <code class="varname">UPDATE_TARGET</code> is set to) for these
 	  packages.</p>
 <p>You can use the <span class="quote">&#8220;<span class="quote">update</span>&#8221;</span> target to
 	  resume package updating in case a previous <span class="command"><strong>make
 	  update</strong></span> was interrupted for some reason.
 	  However, in this case, make sure you don't call
 	  <span class="command"><strong>make clean</strong></span> or otherwise remove the
 	  list of dependent packages in <code class="varname">WRKDIR</code>.
 	  Otherwise, you lose the ability to automatically update
 	  the current package along with the dependent packages
 	  you have installed.</p>
 <p>Resuming an interrupted <span class="command"><strong>make
 	  update</strong></span> will only work as long as the package
 	  tree remains unchanged.  If the source code for one of
 	  the packages to be updated has been changed, resuming
 	  <span class="command"><strong>make update</strong></span> will most certainly
 	  fail!</p>
 <p>The following variables can be used either on the
 	  command line or in <a class="link" href="#mk.conf"><code class="filename">mk.conf</code></a> to
 	  alter the behaviour of <span class="command"><strong>make
 	  update</strong></span>:</p>
 <div class="variablelist"><dl class="variablelist">
 <dt><span class="term"><code class="varname">UPDATE_TARGET</code></span></dt>
 <dd><p>Install target to recursively use for the
 		updated package and the dependent packages.
 		Defaults to <code class="varname">DEPENDS_TARGET</code> if
 		set, <span class="quote">&#8220;<span class="quote">install</span>&#8221;</span> otherwise for
 		<span class="command"><strong>make update</strong></span>.  Other good
 		targets are <span class="quote">&#8220;<span class="quote">package</span>&#8221;</span> or
 		<span class="quote">&#8220;<span class="quote">bin-install</span>&#8221;</span>.  Do not set this to
 		<span class="quote">&#8220;<span class="quote">update</span>&#8221;</span> or you will get stuck in an
 		endless loop!</p></dd>
 <dt><span class="term"><code class="varname">NOCLEAN</code></span></dt>
 <dd><p>Don't clean up after updating.  Useful if
 		you want to leave the work sources of the updated
 		packages around for inspection or other purposes.
 		Be sure you eventually clean up the source tree
 		(see the <span class="quote">&#8220;<span class="quote">clean-update</span>&#8221;</span> target below)
 		or you may run into troubles with old source code
 		still lying around on your next
 		<span class="command"><strong>make</strong></span> or <span class="command"><strong>make
 		update</strong></span>.</p></dd>
 <dt><span class="term"><code class="varname">REINSTALL</code></span></dt>
 <dd><p>Deinstall each package before installing
 		(making <code class="varname">DEPENDS_TARGET</code>). This
 		may be necessary if the
 		<span class="quote">&#8220;<span class="quote">clean-update</span>&#8221;</span> target (see below) was
 		called after interrupting a running <span class="command"><strong>make
 		update</strong></span>.</p></dd>
 <dt><span class="term"><code class="varname">DEPENDS_TARGET</code></span></dt>
 <dd><p>Allows you to disable recursion and hardcode
 		the target for packages.  The default is
 		<span class="quote">&#8220;<span class="quote">update</span>&#8221;</span> for the update target,
 		facilitating a recursive update of prerequisite
 		packages.  Only set
 		<code class="varname">DEPENDS_TARGET</code> if you want to
 		disable recursive updates. Use
 		<code class="varname">UPDATE_TARGET</code> instead to just
 		set a specific target for each package to be
 		installed during <span class="command"><strong>make update</strong></span>
 		(see above).</p></dd>
 </dl></div>
 </dd>
 <dt><span class="term">clean-update</span></dt>
 <dd>
 <p>Clean the source tree for all packages that would
 	  get updated if <span class="command"><strong>make update</strong></span> was called
 	  from the current directory.  This target should not be
 	  used if the current package (or any of its depending
 	  packages) have already been de-installed (e.g., after
 	  calling <span class="command"><strong>make update</strong></span>) or you may lose
 	  some packages you intended to update. As a rule of
 	  thumb: only use this target <span class="emphasis"><em>before</em></span>
 	  the first time you run <span class="command"><strong>make update</strong></span>
 	  and only if you have a dirty package tree (e.g., if you
 	  used <code class="varname">NOCLEAN</code>).</p>
 <p>If you are unsure about whether your tree is
 	  clean, you can either perform a <span class="command"><strong>make
 	  clean</strong></span> at the top of the tree, or use the
 	  following sequence of commands from the directory of the
 	  package you want to update (<span class="emphasis"><em>before</em></span>
 	  running <span class="command"><strong>make update</strong></span> for the first
 	  time, otherwise you lose all the packages you wanted to
 	  update!):</p>
 <pre class="screen">
 <code class="prompt">#</code> <strong class="userinput"><code>make clean-update</code></strong>
 <code class="prompt">#</code> <strong class="userinput"><code>make clean CLEANDEPENDS=YES</code></strong>
 <code class="prompt">#</code> <strong class="userinput"><code>make update</code></strong>
 	  </pre>
 <p>The following variables can be used either on the
 	  command line or in <a class="link" href="#mk.conf"><code class="filename">mk.conf</code></a> to alter the behaviour of
 	  <span class="command"><strong>make clean-update</strong></span>:</p>
 <div class="variablelist"><dl class="variablelist">
 <dt><span class="term"><code class="varname">CLEAR_DIRLIST</code></span></dt>
 <dd><p>After <span class="command"><strong>make clean</strong></span>, do not
 		reconstruct the list of directories to update for
 		this package.  Only use this if <span class="command"><strong>make
 		update</strong></span> successfully installed all
 		packages you wanted to update.  Normally, this is
 		done automatically on <span class="command"><strong>make
 		update</strong></span>, but may have been suppressed by
 		the <code class="varname">NOCLEAN</code> variable (see
 		above).</p></dd>
 </dl></div>
 </dd>
 <dt><span class="term">replace</span></dt>
 <dd>
 <p>Update the installation of the current package.  This
 	  differs from update in that it does not replace dependent
 	  packages.  You will need to install <a href="https://cdn.NetBSD.org/pub/pkgsrc/current/pkgsrc/pkgtools/pkg_tarup/index.html" target="_top"><code class="filename">pkgtools/pkg_tarup</code></a> for this
 	  target to work.</p>
 <p><span class="emphasis"><em>Be careful when using this
 	  target!</em></span> There are no guarantees that dependent
 	  packages will still work, in particular they will most
 	  certainly break if you <span class="command"><strong>make replace</strong></span> a
 	  library package whose shared library major version changed
 	  between your installed version and the new one.  For this
 	  reason, this target is not officially supported and only
 	  recommended for advanced users.</p>
 </dd>
 <dt><span class="term">info</span></dt>
 <dd><p>This target invokes <a class="citerefentry" href="https://man.NetBSD.org/NetBSD-9.2/i386/pkg_info.1"><span class="citerefentry"><span class="refentrytitle">pkg_info</span>(1)</span></a> for the current
 	  package. You can use this to check which version of a
 	  package is installed.</p></dd>
 <dt><span class="term">index</span></dt>
 <dd>
 <p>This is a top-level command, i.e. it should be used in
 	  the <code class="filename">pkgsrc</code> directory.  It creates a
 	  database of all packages in the local pkgsrc tree, including
 	  dependencies, comment, maintainer, and some other useful
 	  information.  Individual entries are created by running
 	  <span class="command"><strong>make describe</strong></span> in the packages'
 	  directories.  This index file is saved as
 	  <code class="filename">pkgsrc/INDEX</code>.  It can be displayed in
 	  verbose format by running <span class="command"><strong>make
 	  print-index</strong></span>.  You can search in it with
 	  <span class="command"><strong>make search
 	  key=<em class="replaceable"><code>something</code></em></strong></span>.  You can
 	  extract a list of all packages that depend on a particular
 	  one by running <span class="command"><strong>make show-deps
 	  PKG=<em class="replaceable"><code>somepackage</code></em></strong></span>.</p>
 <p>Running this command takes a very long time, some
 	  hours even on fast machines!</p>
 </dd>
 <dt><span class="term">readme</span></dt>
 <dd>
 <p>This target generates a
 	  <code class="filename">index.html</code> file, which can be
 	  viewed using a browser such as <a href="https://cdn.NetBSD.org/pub/pkgsrc/current/pkgsrc/www/firefox/index.html" target="_top"><code class="filename">www/firefox</code></a> or <a href="https://cdn.NetBSD.org/pub/pkgsrc/current/pkgsrc/www/links/index.html" target="_top"><code class="filename">www/links</code></a>.  The generated files
 	  contain references to any packages which are in the
 	  <code class="varname">PACKAGES</code> directory on the local
 	  host. The generated files can be made to refer to URLs
 	  based on <code class="varname">FTP_PKG_URL_HOST</code> and
 	  <code class="varname">FTP_PKG_URL_DIR</code>. For example, if I
 	  wanted to generate <code class="filename">index.html</code>
 	  files which pointed to binary packages on the local
 	  machine, in the directory
 	  <code class="filename">/usr/packages</code>, set
 	  <code class="varname">FTP_PKG_URL_HOST=file://localhost</code> and
 	  <code class="varname">FTP_PKG_URL_DIR=/usr/packages</code>. The
 	  <code class="varname">${PACKAGES}</code> directory and its
 	  subdirectories will be searched for all the binary
 	  packages.</p>
 <p>The target can be run at the toplevel or in category
 	  directories, in which case it descends recursively.</p>
 </dd>
 <dt><span class="term">readme-all</span></dt>
 <dd><p>This is a top-level command, run it in
 	  <code class="filename">pkgsrc</code>.  Use this target to create a
 	  file <code class="filename">README-all.html</code> which contains a
 	  list of all packages currently available in the NetBSD
 	  Packages Collection, together with the category they belong
 	  to and a short description. This file is compiled from the
 	  <code class="filename">pkgsrc/*/index.html</code> files, so be sure
 	  to run this <span class="emphasis"><em>after</em></span> a <span class="command"><strong>make
 	  readme</strong></span>.</p></dd>
 <dt><span class="term">cdrom-readme</span></dt>
 <dd><p>This is very much the same as the
 	  <span class="quote">&#8220;<span class="quote">readme</span>&#8221;</span> target (see above), but is to be
 	  used when generating a pkgsrc tree to be written to a
 	  CD-ROM.  This target also produces
 	  <code class="filename">index.html</code> files, and can be made
 	  to refer to URLs based on
 	  <code class="varname">CDROM_PKG_URL_HOST</code> and
 	  <code class="varname">CDROM_PKG_URL_DIR</code>.</p></dd>
 <dt><span class="term">show-distfiles</span></dt>
 <dd><p>This target shows which distfiles and patchfiles
 	  are needed to build the package
 	  (<code class="varname">ALLFILES</code>, which contains all
 	  <code class="varname">DISTFILES</code> and
 	  <code class="varname">PATCHFILES</code>, but not
 	  <code class="filename">patches/*</code>).</p></dd>
 <dt><span class="term">show-downlevel</span></dt>
 <dd><p>This target shows nothing if the package is not
 	  installed. If a version of this package is installed,
 	  but is not the version provided in this version of
 	  pkgsrc, then a warning message is displayed. This target
 	  can be used to show which of your installed packages are
 	  downlevel, and so the old versions can be deleted, and
 	  the current ones added.</p></dd>
 <dt><span class="term">show-pkgsrc-dir</span></dt>
 <dd><p>This target shows the directory in the pkgsrc
 	  hierarchy from which the package can be built and
 	  installed. This may not be the same directory as the one
 	  from which the package was installed. This target is
 	  intended to be used by people who may wish to upgrade
 	  many packages on a single host, and can be invoked from
 	  the top-level pkgsrc Makefile by using the
 	  <span class="quote">&#8220;<span class="quote">show-host-specific-pkgs</span>&#8221;</span> target.</p></dd>
 <dt><span class="term">show-installed-depends</span></dt>
 <dd><p>This target shows which installed packages match
 	  the current package's <code class="varname">DEPENDS</code>. Useful
 	  if out of date dependencies are causing build
 	  problems.</p></dd>
 <dt><span class="term">print-build-depends-list</span></dt>
 <dd><p>This target shows the list of packages that the current package
 	    depends on for building.</p></dd>
 <dt><span class="term">print-run-depends-list</span></dt>
 <dd><p>This target shows the list of packages that the current package
 	    depends on for running.</p></dd>
 <dt><span class="term">check-shlibs</span></dt>
 <dd><p>After a package is installed, check all its
 	  binaries and (on ELF platforms) shared libraries to see
 	  if they find the shared libs they need.  Run by default
 	  if <code class="varname">PKG_DEVELOPER</code> is set in <a class="link" href="#mk.conf"><code class="filename">mk.conf</code></a>.</p></dd>
 <dt><span class="term">print-PLIST</span></dt>
 <dd>
 <p>After a <span class="quote">&#8220;<span class="quote">make install</span>&#8221;</span> from a new or
 	  upgraded pkg, this prints out an attempt to generate a
 	  new <code class="filename">PLIST</code> from a <span class="command"><strong>find
 	  -newer work/.extract_done</strong></span>.  An attempt is made
 	  to care for shared libs etc., but it is
 	  <span class="emphasis"><em>strongly</em></span> recommended to review the
 	  result before putting it into
 	  <code class="filename">PLIST</code>. On upgrades, it's useful to
 	  diff the output of this command against an already
 	  existing <code class="filename">PLIST</code> file.</p>
 <p>If the package installs files via <a class="citerefentry" href="https://man.NetBSD.org/NetBSD-9.2/i386/tar.1"><span class="citerefentry"><span class="refentrytitle">tar</span>(1)</span></a> or
 	  other methods that don't update file access times, be
 	  sure to add these files manually to your
 	  <code class="filename">PLIST</code>, as the <span class="quote">&#8220;<span class="quote">find
 	  -newer</span>&#8221;</span> command used by this target won't catch
 	  them!</p>
 <p>See <a class="xref" href="#print-PLIST" title="19.3.�Tweaking output of make print-PLIST">Section�19.3, &#8220;Tweaking output of <span class="command"><strong>make print-PLIST</strong></span>&#8221;</a> for more
 	  information on this target.</p>
 </dd>
 </dl></div>
 </div>
 </div>
 <div class="chapter">
 <div class="titlepage"><div><div><h2 class="title">
 <a name="creating"></a>Chapter�14.�Creating a new pkgsrc package from scratch</h2></div></div></div>
 <div class="toc">
 <p><b>Table of Contents</b></p>
 <dl class="toc">
 <dt><span class="sect1"><a href="#creating.common">14.1. Common types of packages</a></span></dt>
 <dd><dl>
 <dt><span class="sect2"><a href="#creating.python-module">14.1.1. Python modules and programs</a></span></dt>
 <dt><span class="sect2"><a href="#creating.R-package">14.1.2. R packages</a></span></dt>
 <dt><span class="sect2"><a href="#creating.TeX-package">14.1.3. TeXlive packages</a></span></dt>
 </dl></dd>
 <dt><span class="sect1"><a href="#creating.examples">14.2. Examples</a></span></dt>
 <dd><dl><dt><span class="sect2"><a href="#creating.nvu">14.2.1. How the www/nvu package came into pkgsrc</a></span></dt></dl></dd>
 </dl>
 </div>
 <p>When you find a package that is not yet in pkgsrc, you
 most likely have a URL from where you can download the source
 code. Starting with this URL, creating a package involves only a
 few steps.</p>
 <div class="procedure"><ol class="procedure" type="1">
 <li class="step"><p>In your <a class="link" href="#mk.conf"><code class="filename">mk.conf</code></a>, set <code class="code">PKG_DEVELOPER=yes</code> to
 enable the basic quality checks.</p></li>
 <li class="step">
 <p>Install the package <a href="https://cdn.NetBSD.org/pub/pkgsrc/current/pkgsrc/meta-pkgs/pkg_developer/index.html" target="_top"><code class="filename">meta-pkgs/pkg_developer</code></a>, which among others will
 install the utilities <span class="command"><strong>url2pkg</strong></span>,
 <span class="command"><strong>pkglint</strong></span>, <span class="command"><strong>pkgvi</strong></span> and
 <span class="command"><strong>mkpatches</strong></span>:</p>
 <pre class="screen"><code class="prompt">$</code> <strong class="userinput"><code>cd /usr/pkgsrc</code></strong>
 <code class="prompt">$</code> <strong class="userinput"><code>(cd meta-pkgs/pkg_developer &amp;&amp; bmake update)</code></strong></pre>
 </li>
 <li class="step">
 <p>Choose one of the top-level directories as the category in
 which you want to place your package. You can also create a directory of
 your own (maybe called <code class="filename">local</code>). Change into that
 category directory:</p>
 <pre class="screen"><code class="prompt">$</code> <strong class="userinput"><code>cd <em class="replaceable"><code>category</code></em></code></strong></pre>
 </li>
 <li class="step">
 <p>Run the program <span class="command"><strong>url2pkg</strong></span>, passing as
 argument the URL of the distribution file (in most cases a
 <code class="filename">.tar.gz</code> file). This will download the distribution
 file and create the necessary files of the package, based on what's in
 the distribution file:</p>
 <pre class="screen"><code class="prompt">$</code> <strong class="userinput"><code>url2pkg <em class="replaceable"><code>https://www.example.org/packages/package-1.0.tar.gz</code></em></code></strong></pre>
 </li>
 <li class="step">
 <p>Examine the extracted files to determine the dependencies of
 your package. Ideally, this is mentioned in some
 <code class="filename">README</code> file, but things may differ. For each of
 these dependencies, look where it exists in pkgsrc, and if there is a
 file called <code class="filename">buildlink3.mk</code> in that directory, add a
 line to your package <code class="filename">Makefile</code> which includes that
 file just before the last line. If the
 <code class="filename">buildlink3.mk</code> file does not exist, it must be
 created first. The <code class="filename">buildlink3.mk</code> file makes sure
 that the package's include files and libraries are provided.</p>
 <p>If you just need binaries from a dependent package, add a
 <code class="varname">DEPENDS</code> line to the Makefile, which specifies the
 version of the dependency and where it can be found in pkgsrc. This line
 should be placed in the third paragraph. If the dependency is only
 needed for building the package, but not when using it, use
 <code class="varname">TOOL_DEPENDS</code> or <code class="varname">BUILD_DEPENDS</code>
 instead of <code class="varname">DEPENDS</code>.
 The difference between <code class="varname">TOOL_DEPENDS</code> and
 <code class="varname">BUILD_DEPENDS</code> occurs when cross-compiling:
 <code class="varname">TOOL_DEPENDS</code> are <span class="emphasis"><em>native</em></span>
 packages, i.e. packages for the platform where the package is built;
 <code class="varname">BUILD_DEPENDS</code> are <span class="emphasis"><em>target</em></span>
 packages, i.e. packages for the platform for which the package
 is built. There is also <code class="varname">TEST_DEPENDS</code>, which
 specifies a dependency used only for testing the resulting package
 built, using the upstream project's included test suite, on the native
 platform.
 Your package may then look like this:</p>
 <pre class="programlisting">
 [...]
 TOOL_DEPENDS+=  libxslt-[0-9]*:../../textproc/libxslt
 DEPENDS+=       screen-[0-9]*:../../misc/screen
 DEPENDS+=       screen&gt;=4.0:../../misc/screen
 [...]
 .include "../../<em class="replaceable"><code>category</code></em>/<em class="replaceable"><code>package</code></em>/buildlink3.mk"
 .include "../../devel/glib2/buildlink3.mk"
 .include "../../mk/bsd.pkg.mk"
 </pre>
 </li>
 <li class="step"><p>Run <span class="command"><strong>pkglint</strong></span> to see what things still need
 to be done to make your package a <span class="quote">&#8220;<span class="quote">good</span>&#8221;</span> one. If you don't
 know what pkglint's warnings want to tell you, try <span class="command"><strong>pkglint
 --explain</strong></span> or <span class="command"><strong>pkglint -e</strong></span>, which outputs
 additional explanations.</p></li>
 <li class="step"><p>In many cases the package is not yet ready to build. You can
 find instructions for the most common cases in the next section, <a class="xref" href="#creating.common" title="14.1.�Common types of packages">Section�14.1, &#8220;Common types of packages&#8221;</a>. After you have followed the instructions
 over there, you can hopefully continue here.</p></li>
 <li class="step"><p>Run <span class="command"><strong>bmake clean</strong></span> to clean the working
 directory from the extracted files. Besides these files, a lot of cache
 files and other system information have been saved in the working
 directory, which may have become outdated after you edited the
 <code class="filename">Makefile</code>.</p></li>
 <li class="step">
 <p>Now, run <span class="command"><strong>bmake</strong></span> to build the package. For
 the various things that can go wrong in this phase, consult <a class="xref" href="#fixes" title="Chapter�21.�Making your package work">Chapter�21, <i>Making your package work</i></a>.</p>
 <p>If the extracted files from the package need to be fixed, run
 multiple rounds of these commands:</p>
 <pre class="screen"><code class="prompt">$</code> <strong class="userinput"><code>bmake</code></strong>
 <code class="prompt">$</code> <strong class="userinput"><code>pkgvi ${WRKSRC}/some/file/that/does/not/compile</code></strong>
 <code class="prompt">$</code> <strong class="userinput"><code>mkpatches</code></strong>
 <code class="prompt">$</code> <strong class="userinput"><code>bmake mps</code></strong>
 <code class="prompt">$</code> <strong class="userinput"><code>bmake clean</code></strong></pre>
 </li>
 <li class="step"><p>When the package builds fine, the next step is to install
 the package. Run <span class="command"><strong>bmake install</strong></span> and hope that
 everything works.</p></li>
 <li class="step"><p>Up to now, the file <code class="filename">PLIST</code>, which
 contains a list of the files that are installed by the package, is
 nearly empty. Run <span class="command"><strong>bmake print-PLIST
 &gt;PLIST</strong></span> to generate a probably correct list. Check
 the file using your preferred text editor to see if the list of
 files looks plausible.</p></li>
 <li class="step"><p>Run <span class="command"><strong>pkglint</strong></span> again to see if the generated
 <code class="filename">PLIST</code> contains garbage or not.</p></li>
 <li class="step"><p>When you ran <span class="command"><strong>bmake install</strong></span>, the package
 had been registered in the database of installed files, but with an
 empty list of files. To fix this, run <span class="command"><strong>bmake deinstall</strong></span>
 and <span class="command"><strong>bmake install</strong></span> again. Now the package is
 registered with the list of files from
 <code class="filename">PLIST</code>.</p></li>
 <li class="step"><p>Run <span class="command"><strong>bmake clean update</strong></span> to run everything
 from above again in a single step, making sure that the PLIST is correct
 and the whole package is created as intended.</p></li>
 <li class="step"><p>Run <span class="command"><strong>pkglint</strong></span> to see if there's anything
 left to do.</p></li>
 <li class="step"><p>Commit the package to pkgsrc-wip or main pkgsrc; see <a class="xref" href="#submit" title="Chapter�23.�Submitting and Committing">Chapter�23, <i>Submitting and Committing</i></a>.</p></li>
 </ol></div>
 <div class="sect1">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
 <a name="creating.common"></a>14.1.�Common types of packages</h2></div></div></div>
 <div class="sect2">
 <div class="titlepage"><div><div><h3 class="title">
 <a name="creating.python-module"></a>14.1.1.�Python modules and programs</h3></div></div></div>
 <p>Python modules and programs packages are easily created using a
 set of predefined variables.</p>
 <p>
 If some Python versions are not supported by the software, set the
 <code class="varname">PYTHON_VERSIONS_INCOMPATIBLE</code> variable to the Python versions
 that are not supported, e.g.
 </p>
 <pre class="programlisting">
 PYTHON_VERSIONS_INCOMPATIBLE=       27
 </pre>
 <p>
 If the packaged software is a Python module, include one of
 <code class="filename">../../lang/python/egg.mk</code> or
 <code class="filename">../../lang/python/extension.mk</code>.</p>
 <p>Most Python packages use setuptools (<span class="quote">&#8220;<span class="quote">eggs</span>&#8221;</span>).
 If the packaged software is using setuptools, you only need
 to include <span class="quote">&#8220;<span class="quote"><code class="filename">../../lang/python/egg.mk</code></span>&#8221;</span>.
 </p>
 <p>Either way, the package directory should be called
 <span class="quote">&#8220;<span class="quote">py-software</span>&#8221;</span> and <code class="varname">PKGNAME</code> should be set to
 <span class="quote">&#8220;<span class="quote">${PYPKGPREFIX}-${DISTNAME}</span>&#8221;</span>, e.g.
 </p>
 <pre class="programlisting">
 DISTNAME=   foopymodule-1.2.10
 PKGNAME=    ${PYPKGPREFIX}-${DISTNAME}
 </pre>
 <p>If it is an application, include
 <span class="quote">&#8220;<span class="quote"><code class="filename">../../lang/python/application.mk</code></span>&#8221;</span>.
 In order to correctly set the path to the Python interpreter, use the
 <code class="varname">REPLACE_PYTHON</code> variable and set it to the list of files
 (paths relative to <code class="varname">WRKSRC</code>) that must be corrected.
 For example:
 </p>
 <pre class="programlisting">
 REPLACE_PYTHON=   *.py
 </pre>
 <p>Some Python modules have separate distributions for Python-2.x
 and Python-3.x support. In pkgsrc this is handled by the
 <code class="filename">versioned_dependencies.mk</code> file. Set
 <code class="varname">PYTHON_VERSIONED_DEPENDENCIES</code> to the list of
 packages that should be depended upon and include
 <span class="quote">&#8220;<span class="quote"><code class="filename">../../lang/python/versioned_dependencies.mk</code></span>&#8221;</span>,
 then the pkgsrc infrastructure will depend on the appropriate package
 version. For example:
 </p>
 <pre class="programlisting">
 PYTHON_VERSIONED_DEPENDENCIES=dialog
 </pre>
 <p>
 Look inside <code class="filename">versioned_dependencies.mk</code> for a list
 of supported packages.</p>
 </div>
 <div class="sect2">
 <div class="titlepage"><div><div><h3 class="title">
 <a name="creating.R-package"></a>14.1.2.�R packages</h3></div></div></div>
 <p>Simple R packages from <a class="ulink" href="https://cran.r-project.org/web/packages/available_packages_by_name.html" target="_top">CRAN</a>
 are handled automatically by <span class="command"><strong>R2pkg</strong></span>, which is
 available in <a href="https://cdn.NetBSD.org/pub/pkgsrc/current/pkgsrc/pkgtools/R2pkg/index.html" target="_top"><code class="filename">pkgtools/R2pkg</code></a>.
 Individual packages (and optionally their dependencies) may be created
 and updated.  R packages generally follow the same form, and most of
 the relevant information needed is contained in a
 <code class="filename">DESCRIPTION</code> file as part of each R package on
 <a class="ulink" href="https://cran.r-project.org/web/packages/available_packages_by_name.html" target="_top">CRAN</a>.
 Consequently, <span class="command"><strong>R2pkg</strong></span> downloads that information and
 creates or updates a package in the canonical form.  The resulting
 package should be reviewed for correctness.</p>
 </div>
 <div class="sect2">
 <div class="titlepage"><div><div><h3 class="title">
 <a name="creating.TeX-package"></a>14.1.3.�TeXlive packages</h3></div></div></div>
 <p>TeXlive packages from <a class="ulink" href="https://www.ctan.org/" target="_top">CTAN</a> are handled automatically by
 <span class="command"><strong>texlive2pkg</strong></span>, which is available in <a href="https://cdn.NetBSD.org/pub/pkgsrc/current/pkgsrc/pkgtools/texlive2pkg/index.html" target="_top"><code class="filename">pkgtools/texlive2pkg</code></a>.</p>
 <p>If the TeXlive package name is not known, it may be useful to
 search <a class="ulink" href="https://www.ctan.org/" target="_top">CTAN</a>.  A
 <span class="quote">&#8220;<span class="quote">Contained in</span>&#8221;</span> field on the package page typically
 identifies the basename of the package file in the <a class="ulink" href="https://www.ctan.org/tex-archive/systems/texlive/tlnet/archive" target="_top">TeXlive
 archive</a>.</p>
 <p>If the TeXlive package name is known, download the files from
 the <a class="ulink" href="https://www.ctan.org/tex-archive/systems/texlive/tlnet/archive" target="_top">TeXlive
 archive</a>.  For package <code class="filename">foo</code>, you will need
 to download <code class="filename">foo.tar.xz</code>.  Most TeXlive packages
 also have associated documentation packages, so download
 <code class="filename">foo.doc.tar.xz</code> at the same time.  These files
 should be placed in the appropriate category directory, which is often
 but not always <code class="filename">print</code>.  Then run the following
 command in the category directory.</p>
 <pre class="programlisting">
 texlive2pkg foo.tar.xz foo.doc.tar.xz
 </pre>
 <p>This will create two packages, <code class="filename">tex-foo</code> and
 <code class="filename">tex-foo-doc</code>.  Be sure to check that both packages
 are correct.</p>
 <p>Finally, <a class="ulink" href="https://www.ctan.org/" target="_top">CTAN</a>
 currently does not include version information in package filenames
 and changes their contents periodically when updates occur.
 Consequently, pkgsrc avoids downloading distfiles directly from <a class="ulink" href="https://www.ctan.org/" target="_top">CTAN</a> and instead relies on the
 pkgsrc archives.  For each new or updated TeXlive package, e.g., the
 main one and the corresponding documentation, upload the distfiles
 with the following command in each package directory.</p>
 <pre class="programlisting">
 make upload-distfiles
 </pre>
 </div>
 </div>
 <div class="sect1">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
 <a name="creating.examples"></a>14.2.�Examples</h2></div></div></div>
 <div class="sect2">
 <div class="titlepage"><div><div><h3 class="title">
 <a name="creating.nvu"></a>14.2.1.�How the www/nvu package came into pkgsrc</h3></div></div></div>
 <div class="sect3">
 <div class="titlepage"><div><div><h4 class="title">
 <a name="creating.nvu.init"></a>14.2.1.1.�The initial package</h4></div></div></div>
 <p>Looking at the file <code class="filename">pkgsrc/doc/TODO</code>, I saw
 that the <span class="quote">&#8220;<span class="quote">nvu</span>&#8221;</span> package has not yet been imported into
 pkgsrc. As the description says it has to do with the web, the obvious
 choice for the category is <span class="quote">&#8220;<span class="quote">www</span>&#8221;</span>.</p>
 <pre class="programlisting">
 <code class="prompt">$</code> mkdir www/nvu
 <code class="prompt">$</code> cd www/nvu
 </pre>
 <p>The web site says that the sources are available as a tar file, so
 I fed that URL to the <span class="command"><strong>url2pkg</strong></span> program:</p>
 <pre class="programlisting">
 <code class="prompt">$</code> url2pkg http://cvs.nvu.com/download/nvu-1.0-sources.tar.bz2
 </pre>
 <p>My editor popped up, and I added a <code class="varname">PKGNAME</code> line
 below the <code class="varname">DISTNAME</code> line, as the package name should
 not have the word <span class="quote">&#8220;<span class="quote">sources</span>&#8221;</span> in it. I also filled in the
 <code class="varname">MAINTAINER</code>, <code class="varname">HOMEPAGE</code> and
 <code class="varname">COMMENT</code> fields. Then the package
 @@ -7624,2000 +7628,2000 @@ ACCEPTABLE_LICENSES+=xv-license
 <li class="listitem">
 <p>If your package needs another package's binaries or
 	libraries only for building, and if that package has a
 	<code class="filename">buildlink3.mk</code> file available, use it:</p>
 <pre class="programlisting">
 .include "../../graphics/jpeg/buildlink3.mk"
 </pre>
 <p>but set
 	<code class="varname">BUILDLINK_DEPMETHOD.<em class="replaceable"><code>jpeg</code></em>?=build</code>
 	to make it a build dependency only. This case is rather
 	rare.</p>
 </li>
 <li class="listitem">
 <p>If your package needs binaries from another package to build,
 	use the <code class="varname">TOOL_DEPENDS</code> definition:</p>
 <pre class="programlisting">
 TOOL_DEPENDS+= itstool-[0-9]*:../../textproc/itstool
 </pre>
 </li>
 <li class="listitem"><p>If your package needs static libraries to link against, header
 	files to include, etc. from another package to build,
 	use the <code class="varname">BUILD_DEPENDS</code> definition.</p></li>
 <li class="listitem"><p>If your package needs a library with which to link and
 	there is no <code class="filename">buildlink3.mk</code> file
 	available, create one. Using
 	<code class="varname">DEPENDS</code> won't be sufficient because the
 	include files and libraries will be hidden from the compiler.</p></li>
 <li class="listitem">
 <p>If your package needs some executable to be able to run
 	correctly and if there's no
 	<code class="filename">buildlink3.mk</code> file, this is specified
 	using the <code class="varname">DEPENDS</code> variable. The
 	<a href="https://cdn.NetBSD.org/pub/pkgsrc/current/pkgsrc/print/lyx/index.html" target="_top"><code class="filename">print/lyx</code></a> package needs to
 	be able to execute the latex binary from the tex-latex-bin package
 	when it runs, and that is specified:</p>
 <pre class="programlisting">
 DEPENDS+=        tex-latex-bin-[0-9]*:../../print/tex-latex-bin
 </pre>
 </li>
 <li class="listitem"><p>If your package includes a test suite that has extra
         dependencies only required for this purpose (frequently this
         can be run as a <span class="quote">&#8220;<span class="quote">make test</span>&#8221;</span> target), use the
         <code class="varname">TEST_DEPENDS</code> variable.</p></li>
 <li class="listitem">
 <p>You can use wildcards in package dependencies. Note that
 	such wildcard dependencies are retained when creating binary
 	packages. The dependency is checked when installing the binary
 	package and any package which matches the pattern will be
 	used. Wildcard dependencies should be used with care.</p>
 <p>The <span class="quote">&#8220;<span class="quote">-[0-9]*</span>&#8221;</span> should be used instead of
 	<span class="quote">&#8220;<span class="quote">-*</span>&#8221;</span> to avoid potentially ambiguous matches
 	such as <span class="quote">&#8220;<span class="quote">tk-postgresql</span>&#8221;</span> matching a
 	<span class="quote">&#8220;<span class="quote">tk-*</span>&#8221;</span> <code class="varname">DEPENDS</code>.</p>
 <p>Wildcards can also be used to specify that a package
 	will only build against a certain minimum version of a
 	pre-requisite:</p>
 <pre class="programlisting">
 DEPENDS+=       ImageMagick&gt;=6.0:../../graphics/ImageMagick
 </pre>
 <p>This means that the package will build using version 6.0
 	of ImageMagick or newer. Such a dependency may be warranted
 	if, for example, the command line options of an executable
 	have changed.</p>
 <p>If you need to depend on minimum versions of libraries,
 	set
 	<code class="varname">BUILDLINK_API_DEPENDS.<em class="replaceable"><code>pkg</code></em></code>
 	to the appropriate pattern before including its
 	<code class="filename">buildlink3.mk</code> file, e.g.</p>
 <pre class="programlisting">
 BUILDLINK_API_DEPENDS.jpeg+=    jpeg&gt;=9.0
 .include "../../graphics/jpeg/buildlink3.mk"
 </pre>
 <p>For security fixes, please update the package
 	vulnerabilities file. See <a class="xref" href="#security-handling" title="21.1.9.�Handling packages with security problems">Section�21.1.9, &#8220;Handling packages with security problems&#8221;</a> for more
 	information.</p>
 </li>
 </ol></div>
 <p>If your package needs files from another package to build,
     add the relevant distribution files to
     <code class="varname">DISTFILES</code>, so they will be extracted
     automatically. See the <a href="https://cdn.NetBSD.org/pub/pkgsrc/current/pkgsrc/print/ghostscript/index.html" target="_top"><code class="filename">print/ghostscript</code></a> package for an example.
     (It relies on the jpeg sources being present in source form
     during the build.)</p>
 </div>
 <div class="sect2">
 <div class="titlepage"><div><div><h3 class="title">
 <a name="conflicts"></a>21.1.6.�Handling conflicts with other packages</h3></div></div></div>
 <p>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 as another package in the pkgsrc
     tree or has the same <code class="varname">PKGNAME</code>.</p>
 <p>For example, <a href="https://cdn.NetBSD.org/pub/pkgsrc/current/pkgsrc/x11/libXaw3d/index.html" target="_top"><code class="filename">x11/libXaw3d</code></a>
     and <a href="https://cdn.NetBSD.org/pub/pkgsrc/current/pkgsrc/x11/Xaw-Xpm/index.html" target="_top"><code class="filename">x11/Xaw-Xpm</code></a>
     install the same shared library, thus you set in
     <code class="filename">pkgsrc/x11/libXaw3d/Makefile</code>:</p>
 <pre class="programlisting">
 CONFLICTS=      Xaw-Xpm-[0-9]*
     </pre>
 <p>and in <code class="filename">pkgsrc/x11/Xaw-Xpm/Makefile</code>:</p>
 <pre class="programlisting">
 CONFLICTS=      libXaw3d-[0-9]*
     </pre>
 <p><a class="citerefentry" href="https://man.NetBSD.org/NetBSD-9.2/i386/pkg_add.1"><span class="citerefentry"><span class="refentrytitle">pkg_add</span>(1)</span></a> is able to detect attempts to install packages
     that conflict with existing packages and abort. However, in many
     situations this is too late in the process. Binary package managers
     will not know about the conflict until they attempt to install the
     package after already downloading it and all its dependencies.
     Users may also waste time building a package and its dependencies
     only to find out at the end that it conflicts with another package
     they have installed.</p>
 <p>To avoid these issues <code class="varname">CONFLICTS</code> entries
     should be added in all cases where it is known that packages conflict
     with each other.  These <code class="varname">CONFLICTS</code> entries are
     exported in <a class="citerefentry" href="https://man.NetBSD.org/NetBSD-9.2/i386/pkg_summary.5"><span class="citerefentry"><span class="refentrytitle">pkg_summary</span>(5)</span></a> files and consumed by binary package
     managers to inform users that packages cannot be installed onto
     the target system.</p>
 </div>
 <div class="sect2">
 <div class="titlepage"><div><div><h3 class="title">
 <a name="not-building-packages"></a>21.1.7.�Packages that cannot or should not be built</h3></div></div></div>
 <p>There are several reasons why a package might be
     instructed to not build under certain circumstances.  If the
     package builds and runs on most platforms, the exceptions
     should be noted with <code class="varname">BROKEN_ON_PLATFORM</code>.  If
     the package builds and runs on a small handful of platforms,
     set <code class="varname">BROKEN_EXCEPT_ON_PLATFORM</code> instead.
     Both <code class="varname">BROKEN_ON_PLATFORM</code> and
     <code class="varname">BROKEN_EXCEPT_ON_PLATFORM</code> are OS triples
     (OS-version-platform) that can use glob-style
     wildcards.</p>
 <p>If a package is not appropriate for some platforms (as
     opposed to merely broken), a different set of variables should be
     used as this affects failure reporting and statistics.
     If the package is appropriate for most platforms, the exceptions
     should be noted with <code class="varname">NOT_FOR_PLATFORM</code>.  If
     the package is appropriate for only a small handful of platforms
     (often exactly one), set <code class="varname">ONLY_FOR_PLATFORM</code> instead.
     Both <code class="varname">ONLY_FOR_PLATFORM</code> and
     <code class="varname">NOT_FOR_PLATFORM</code> are OS triples
     (OS-version-platform) that can use glob-style
     wildcards.</p>
 <p>Some packages are tightly bound to a specific version of an
     operating system, e.g. LKMs or <a href="https://cdn.NetBSD.org/pub/pkgsrc/current/pkgsrc/sysutils/lsof/index.html" target="_top"><code class="filename">sysutils/lsof</code></a>.  Such binary packages are not
     backwards compatible with other versions of the OS, and should be
     uploaded to a version specific directory on the FTP server.  Mark
     these packages by setting <code class="varname">OSVERSION_SPECIFIC</code> to
     <span class="quote">&#8220;<span class="quote">yes</span>&#8221;</span>.  This variable is not currently used by any of
     the package system internals, but may be used in the
     future.</p>
 <p>If the package should be skipped (for example, because it
     provides functionality already provided by the system), set
     <code class="varname">PKG_SKIP_REASON</code> to a descriptive message.  If
     the package should fail because some preconditions are not met,
     set <code class="varname">PKG_FAIL_REASON</code> to a descriptive
     message.</p>
 </div>
 <div class="sect2">
 <div class="titlepage"><div><div><h3 class="title">
 <a name="undeletable-packages"></a>21.1.8.�Packages which should not be deleted, once installed</h3></div></div></div>
 <p>To ensure that a package may not be deleted, once it has been
     installed, the <code class="varname">PKG_PRESERVE</code> definition should
     be set in the package Makefile. This will be carried into any
     binary package that is made from this pkgsrc entry. A
     <span class="quote">&#8220;<span class="quote">preserved</span>&#8221;</span> package will
     not be deleted using <a class="citerefentry" href="https://man.NetBSD.org/NetBSD-9.2/i386/pkg_delete.1"><span class="citerefentry"><span class="refentrytitle">pkg_delete</span>(1)</span></a> unless the
     <span class="quote">&#8220;<span class="quote">-f</span>&#8221;</span> option is used.</p>
 </div>
 <div class="sect2">
 <div class="titlepage"><div><div><h3 class="title">
 <a name="security-handling"></a>21.1.9.�Handling packages with security problems</h3></div></div></div>
 <p>When a vulnerability is found, this should be noted in
     <code class="filename">localsrc/security/advisories/pkg-vulnerabilities</code>.
     Entries in that file consist of three parts:</p>
 <div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; ">
 <li class="listitem"><p>package version pattern</p></li>
 <li class="listitem"><p>type of vulnerability (please cut'n'paste an existing one where possible)</p></li>
 <li class="listitem"><p>URL providing additional information about the issue</p></li>
 </ul></div>
 <p>For the package version pattern please always use `&lt;' to
     mark an upper bound (not `&lt;='!). This will avoid possible
     problems due unrelated <code class="varname">PKGREVISION</code> bumps not
     related to security fixes. Lower bounds can be added too, using
     '&gt;' or '&gt;='. For example,
     <span class="quote">&#8220;<span class="quote"><code class="literal">foo&gt;=1&lt;1.2</code></span>&#8221;</span> would mark
     versions 1.0 (included) to 1.2 (excluded) of
     <span class="quote">&#8220;<span class="quote"><code class="literal">foo</code></span>&#8221;</span> as affected by the security
     issue.</p>
 <p>Entries should always be added at the bottom of the file.</p>
 <p>When fixing packages, please modify the upper bound of the
     corresponding entry. To continue the previous example, if a fix
     was backported to version 1.1nb2, change the previous pattern to
     <span class="quote">&#8220;<span class="quote"><code class="literal">foo&gt;=1&lt;1.1nb2</code></span>&#8221;</span>.</p>
 <p>To locally test a package version pattern against a
     <code class="varname">PKGNAME</code> you can use the <span class="command"><strong>pkg_admin
     pmatch</strong></span> command.</p>
 <p>The URL should be as permanent as possible and provide as
     much information about the issue as possible.  CVE entries are
     preferred.</p>
 <p>After committing that file, ask pkgsrc-security@NetBSD.org to
     update the file on ftp.NetBSD.org.</p>
 <p>After fixing the vulnerability by a patch, its
     <code class="varname">PKGREVISION</code> should be increased (this is of
     course not necessary if the problem is fixed by using a newer
     release of the software), and the pattern in the
     pkg-vulnerabilities file must be updated.</p>
 <p>Also, if the fix should be applied to the stable pkgsrc
     branch, be sure to submit a pullup request!</p>
 <p>Binary packages already on ftp.NetBSD.org will be handled
     semi-automatically by a weekly cron job.</p>
 <p>In case a security issue is disputed, please contact
     pkgsrc-security@NetBSD.org.</p>
 </div>
 <div class="sect2">
 <div class="titlepage"><div><div><h3 class="title">
 <a name="bumping-pkgrevision"></a>21.1.10.�How to handle incrementing versions when fixing an existing package</h3></div></div></div>
 <p>When making fixes to an existing package it can be useful
     to change the version number in <code class="varname">PKGNAME</code>. To
     avoid conflicting with future versions by the original author, a
     <span class="quote">&#8220;<span class="quote">nb1</span>&#8221;</span>, <span class="quote">&#8220;<span class="quote">nb2</span>&#8221;</span>, ... suffix can be used
     on package versions by setting <code class="varname">PKGREVISION=1</code>
     (2, ...). The <span class="quote">&#8220;<span class="quote">nb</span>&#8221;</span> is treated like a
     <span class="quote">&#8220;<span class="quote">.</span>&#8221;</span> by the package tools. e.g.</p>
 <pre class="programlisting">
 DISTNAME=       foo-17.42
 PKGREVISION=    9
 </pre>
 <p>will result in a <code class="varname">PKGNAME</code> of
     <span class="quote">&#8220;<span class="quote">foo-17.42nb9</span>&#8221;</span>. If you want to use the original
     value of <code class="varname">PKGNAME</code> without the <span class="quote">&#8220;<span class="quote">nbX</span>&#8221;</span>
     suffix, e.g. for setting <code class="varname">DIST_SUBDIR</code>, use
     <code class="varname">PKGNAME_NOREV</code>.</p>
 <p>When a new release of the package is released, the
     <code class="varname">PKGREVISION</code> should be removed, e.g. on a new
     minor release of the above package, things should be like:</p>
 <pre class="programlisting">
 DISTNAME=       foo-17.43
 </pre>
 <p><code class="varname">PKGREVISION</code> should be incremented for any
     non-trivial change in the resulting binary package.  Without a
     <code class="varname">PKGREVISION</code> bump, someone with the previous
     version installed has no way of knowing that their package is out
     of date.  Thus, changes without increasing
     <code class="varname">PKGREVISION</code> are essentially labeled "this is so
     trivial that no reasonable person would want to upgrade", and this
     is the rough test for when increasing
     <code class="varname">PKGREVISION</code> is appropriate.  Examples of
     changes that do not merit increasing
     <code class="varname">PKGREVISION</code> are:</p>
 <div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; ">
 <li class="listitem"><p>Changing <code class="varname">HOMEPAGE</code>,
       <code class="varname">MAINTAINER</code>, <code class="varname">OWNER</code>, or
       comments in Makefile.</p></li>
 <li class="listitem"><p>Changing build variables if the resulting binary
       package is the same.</p></li>
 <li class="listitem"><p>Changing
       <code class="filename">DESCR</code>.</p></li>
 <li class="listitem"><p>Adding <code class="varname">PKG_OPTIONS</code> if the
       default options don't change.</p></li>
 </ul></div>
 <p>Examples of changes that do merit an increase to
     <code class="varname">PKGREVISION</code> include:</p>
 <div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; ">
 <li class="listitem"><p>Security fixes</p></li>
 <li class="listitem"><p>Changes or additions to a patch
       file</p></li>
 <li class="listitem"><p>Changes to the
       <code class="filename">PLIST</code></p></li>
 <li class="listitem"><p>A dependency is changed or
       renamed.</p></li>
 </ul></div>
 <p>PKGREVISION must also be incremented when dependencies have ABI
     changes.</p>
 </div>
 <div class="sect2">
 <div class="titlepage"><div><div><h3 class="title">
 <a name="fixes.subst"></a>21.1.11.�Substituting variable text in the package files (the SUBST framework)</h3></div></div></div>
 <p>When you want to replace the same text in multiple files, or
 multiple times in the same file, it is cumbersome to maintain a patch
 file for this. This is where the SUBST framework steps in. It provides an
 easy-to-use interface for replacing text in files. It just needs the
 following information:</p>
 <div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; ">
 <li class="listitem"><p>In which phase of the package build cycle should the
 replacement happen?</p></li>
 <li class="listitem"><p>In which files should the replacement
 happen?</p></li>
 <li class="listitem"><p>Which text should be replaced with
 what?</p></li>
 </ul></div>
 <p>This information is encoded in a block of <code class="varname">SUBST</code>
 variables. A minimal example is:</p>
 <pre class="programlisting">
 SUBST_CLASSES+=         paths
 SUBST_STAGE.paths=      pre-configure
 SUBST_FILES.paths=      src/*.c
 SUBST_SED.paths=        -e 's,/usr/local,${PREFIX},g'
 </pre>
 <p>Translated into English, it means: In the pre-configure stage (that
 is, after applying the patches from the patches/ directory and before
 running the configure script and the portability check), replace the text
 <code class="literal">/usr/local</code> with the content of the variable
 <code class="varname">PREFIX</code>.</p>
 <p>Each SUBST block starts by appending an identifier to
 <code class="varname">SUBST_CLASSES</code> (note the <code class="literal">+=</code>). This
 identifier can be chosen freely by the package. If there should ever be
 duplicate identifiers, the pkgsrc infrastructure will catch this and fail
 early, so don't worry about name collisions.</p>
 <p>Except for <code class="varname">SUBST_CLASSES</code>, all variables in a
 SUBST block are parameterized using this identifier. In the remainder of
 this section, these parameterized variables are written as
 <code class="varname">SUBST_STAGE.*</code>.</p>
 <pre class="programlisting">
 SUBST_CLASSES+=         paths
 SUBST_STAGE.paths=      pre-configure
 SUBST_MESSAGE.paths=    Fixing absolute paths.
 SUBST_FILES.paths=      src/*.c
 SUBST_FILES.paths+=     scripts/*.sh
 SUBST_SED.paths=        -e 's,"/usr/local,"${PREFIX},g'
 SUBST_SED.paths+=       -e 's,"/var/log,"${VARBASE}/log,g'
 SUBST_VARS.paths=       LOCALBASE PREFIX PKGVERSION
 </pre>
 <p>To get a complete picture about the SUBST substitutions, run
 <span class="command"><strong>bmake show-all-subst</strong></span>. If something doesn't work as
 expected, run pkglint on the package, which detects several typical
 mistakes surrounding the SUBST blocks. For any questions that might
 remain after this, have a look at
 <code class="filename">mk/subst.mk</code>.</p>
 <div class="sect3">
 <div class="titlepage"><div><div><h4 class="title">
 <a name="fixes.subst.when"></a>21.1.11.1.�Choosing the time where the substitutions happen</h4></div></div></div>
 <p>The <code class="varname">SUBST_STAGE.*</code> is one of
 {pre,do,post}-{extract,patch,configure,build,test,install}. Of these,
 <code class="literal">pre-configure</code> is used most often, by far. The most
 popular stages are, in chronological order:</p>
 <div class="variablelist"><dl class="variablelist">
 <dt><span class="term"><code class="literal">post-extract</code></span></dt>
 <dd>
 <p>The substitutions are applied immediately after the
 distfiles are extracted. Running <span class="command"><strong>bmake extract</strong></span> on the
 package will leave no traces of the original files.</p>
 <p>When the substitution applies to files for which there is also a
 patch in the <code class="filename">patches/</code> directory, this means that the
 patches will be computed based on the result of the substitution. When
 these patches are sent to the upstream maintainer later, to be fixed in
 the upstream package, these patches may no longer match what the upstream
 author is used to. Because of this, <code class="literal">pre-configure</code> is
 often a better choice.</p>
 </dd>
 <dt><span class="term"><code class="literal">pre-configure</code></span></dt>
 <dd>
 <p>The substitutions are applied after the patches from the
 <code class="filename">patches/</code> directory. This makes it possible to run
 <span class="command"><strong>bmake patch</strong></span> on the package, after which the patches
 can be edited using the tools pkgvi and mkpatches from the <a href="https://cdn.NetBSD.org/pub/pkgsrc/current/pkgsrc/pkgtools/pkgdiff/index.html" target="_top"><code class="filename">pkgtools/pkgdiff</code></a> package.</p>
 <p>When updating the patches, it is helpful to explicitly separate the
 <span class="command"><strong>bmake patch</strong></span> from the <span class="command"><strong>bmake
 configure</strong></span>, and to only edit the patches between these commands.
 Otherwise the substitutions from the SUBST block will end up in the patch
 file. When this happens in really obvious ways, pkglint will complain
 about patches that contain a hard-coded <code class="literal">/usr/pkg</code>
 instead of the correct and intended <code class="literal">@PREFIX@</code>, but it
 can only detect these really obvious
 cases.</p>
 </dd>
 <dt><span class="term"><code class="literal">do-configure</code></span></dt>
 <dd><p>This stage should only be used if the package defines a
 <code class="literal">pre-configure</code> action itself, and the substitution must
 happen after that. Typical examples are packages that use the
 <code class="literal">pre-configure</code> stage to regenerate the GNU configure
 script from
 <code class="filename">configure.ac</code>.</p></dd>
 <dt><span class="term"><code class="literal">post-configure</code></span></dt>
 <dd><p>This stage is used to fix up any mistakes by the
 configure stage.</p></dd>
 <dt><span class="term"><code class="literal">pre-build</code></span></dt>
 <dd><p>This stage should only be used for substitutions that are
 clearly related to building the package, not for fixing the
 configuration. Substitutions for pathnames (such as replacing
 <code class="filename">/usr/local</code> with <code class="literal">${PREFIX}</code>) or
 user names (such as replacing <code class="literal">@MY_USER@</code> with the
 actual username) belong in pre-configure or post-configure
 instead.</p></dd>
 <dt><span class="term"><code class="literal">post-build</code></span></dt>
 <dd>
 <p>Just as with pre-build, this stage should only be used
 for substitutions that are clearly related to building the package, not
 for fixing the configuration. Substitutions for pathnames (such as
 replacing <code class="filename">/usr/local</code> with
 <code class="literal">${PREFIX}</code>) or user names (such as replacing
 <code class="literal">@MY_USER@</code> with the actual username) belong in
 pre-configure or post-configure instead.</p>
 <p>A typical use is to update pkg-config files to include the rpath
 compiler options.</p>
 </dd>
 <dt><span class="term"><code class="literal">pre-install</code></span></dt>
 <dd><p>In general, the install phase should be as simple as
 possible. As with the pre-build and post-build stages, it should not be
 used to fix pathnames or user names, these belong in pre-configure
 instead. There are only few legitimate use cases for applying
 substitutions in this stage.</p></dd>
 </dl></div>
 </div>
 <div class="sect3">
 <div class="titlepage"><div><div><h4 class="title">
 <a name="fixes.subst.where"></a>21.1.11.2.�Choosing the files where the substitutions happen</h4></div></div></div>
 <p>The <code class="varname">SUBST_FILES.*</code> variable contains a list of
 filename patterns. These patterns are relative to
 <code class="varname">WRKSRC</code> since that is where most substitutions happen.
 A typical example is:</p>
 <pre class="programlisting">
 SUBST_FILES.path=       Makefile */Makefile */*/Makefile *.[ch]
 </pre>
 <p>The above patterns, especially the last, are quite broad. The SUBST
 implementation checks that each filename pattern that is mentioned here
 has an effect. For example, if none of the
 <code class="filename">*/*/Makefile</code> files contains the patterns to be found
 and substituted, that filename pattern is redundant and should be left
 out. By default, the SUBST framework will complain with an error message.
 If the text to be substituted occurs in some of the files from a single
 pattern, but not in all of them, that is totally ok, and the SUBST
 framework will only print an INFO message for those files.</p>
 <p>If there is a good reason for having redundant filename patterns,
 set <code class="varname">SUBST_NOOP_OK.*</code> to <code class="literal">yes</code>.</p>
 <p>Another popular way of choosing the files for the substitutions is
 via a shell command, like this:</p>
 <pre class="programlisting">
 C_FILES_CMD=            cd ${WRKSRC} &amp;&amp; ${FIND} . -name '*.c'
 SUBST_FILES.path=       ${C_FILES_CMD:sh}
 </pre>
 <p>The variable name <code class="varname">C_FILES_CMD</code> in this example is
 freely chosen and independent of the SUBST framework.</p>
 <p>In this variant, the <code class="varname">SUBST_FILES.*</code> variable
 lists each file individually. Thereby chances are higher that there are
 filename patterns in which no substitution happens. Since the SUBST
 framework cannot know whether the filename patterns in
 <code class="varname">SUBST_FILES.*</code> have been explicitly listed in the
 Makefile (where any redundant filename pattern would be suspicious) or
 been generated by a shell command (in which redundant filename patterns
 are more likely and to be expected), it will complain about these
 redundant filename patterns. Therefore, SUBST blocks that use a shell
 command to generate the list of filename patterns often need to set
 <code class="varname">SUBST_NOOP_OK.*</code> to <code class="literal">yes</code>.</p>
 </div>
 <div class="sect3">
 <div class="titlepage"><div><div><h4 class="title">
 <a name="fixes.subst.what"></a>21.1.11.3.�Choosing what to substitute</h4></div></div></div>
 <p>In most cases, the substitutions are given using one or more
 <a class="citerefentry" href="https://man.NetBSD.org/NetBSD-9.2/i386/sed.1"><span class="citerefentry"><span class="refentrytitle">sed</span>(1)</span></a> commands, like this:</p>
 <pre class="programlisting">
 SUBST_SED.path=         -e 's|/usr/local|${PREFIX}|g'
 </pre>
 <p>Each of the sed commands needs to be preceded by the
 <code class="literal">-e</code> option and should be specified on a line of its
 own, to avoid hiding short sed commands at the end of a line.</p>
 <p>Since the sed commands often contain shell metacharacters as the
 separator (the <code class="literal">|</code> in the above example), it is common
 to enclose them in single quotes.</p>
 <p>A common substitution is to replace placeholders of the form
 <code class="literal">@VARNAME@</code> with their pkgsrc counterpart variable
 <code class="literal">${VARNAME}</code>. A typical example is:</p>
 <pre class="programlisting">
 SUBST_VARS.path=        PREFIX
 </pre>
 <p>This type of substitutions is typically done by the GNU configure
 scripts during the do-configure stage, but in some cases these need to be
 overridden. The same pattern is also used when a package defines patches
 that replace previously hard-coded paths like
 <code class="literal">/usr/local</code> with a <code class="literal">@PREFIX@</code>
 placeholder first, which then gets substituted by the actual
 <code class="literal">${PREFIX}</code> in the pre-configure stage. In many of these
 cases, it works equally well to just use the SUBST framework to directly
 replace <code class="literal">/usr/local</code> with <code class="literal">${PREFIX}</code>,
 thereby omitting the intermediate patch file.</p>
 <p>If the above is not flexible enough, it is possible to not use sed
 at all for the substitution but to specify an entirely different command,
 like this:</p>
 <pre class="programlisting">
 SUBST_FILTER_CMD.path=  LC_ALL=C ${TR} -d '\r'
 </pre>
 <p>This is used for the few remaining packages in which the
 distributed files use Windows-style line endings that need to be
 converted to UNIX-style line endings.</p>
 </div>
 <div class="sect3">
 <div class="titlepage"><div><div><h4 class="title">
 <a name="fixes.subst.other"></a>21.1.11.4.�Other SUBST variables</h4></div></div></div>
 <p>When a SUBST block is applied during a package build, a message is
 logged. The default message is fine for most purposes but can be
 overridden by setting <code class="literal">SUBST_MESSAGE.*</code> to an individual
 message.</p>
 </div>
 </div>
 </div>
 <div class="sect1">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
 <a name="fixes.fetch"></a>21.2.�The <span class="emphasis"><em>fetch</em></span> phase</h2></div></div></div>
 <div class="sect2">
 <div class="titlepage"><div><div><h3 class="title">
 <a name="no-plain-download"></a>21.2.1.�Packages whose distfiles aren't available for plain downloading</h3></div></div></div>
 <p>If you need to download from a dynamic URL you can set
     <code class="varname">DYNAMIC_MASTER_SITES</code> and a <span class="command"><strong>make
     fetch</strong></span> will call <code class="filename">files/getsite.sh</code>
     with the name of each file to download as an argument, expecting
     it to output the URL of the directory from which to download
     it. <a href="https://cdn.NetBSD.org/pub/pkgsrc/current/pkgsrc/graphics/ns-cult3d/index.html" target="_top"><code class="filename">graphics/ns-cult3d</code></a> is an
     example of this usage.</p>
 <p>If the download can't be automated, because the user must
     submit personal information to apply for a password, or must pay
     for the source, or whatever, you can set
     <code class="varname">FETCH_MESSAGE</code> to a list of lines that are
     displayed to the user before aborting the build. Example:</p>
 <pre class="programlisting">
 FETCH_MESSAGE=  "Please download the files"
 FETCH_MESSAGE+= "    "${DISTFILES:Q}
 FETCH_MESSAGE+= "manually from "${MASTER_SITES:Q}"."
 </pre>
 </div>
 <div class="sect2">
 <div class="titlepage"><div><div><h3 class="title">
 <a name="modified-distfiles-same-name"></a>21.2.2.�How to handle modified distfiles with the 'old' name</h3></div></div></div>
 <p>Sometimes authors of a software package make some
     modifications after the software was released, and they put up a
     new distfile without changing the package's version number. If a
     package is already in pkgsrc at that time, the checksum will
     no longer match. The contents of the new distfile should be
     compared against the old one before changing anything, to make
     sure the distfile was really updated on purpose, and that
     no trojan horse or so crept in.
     Please mention that the distfiles were compared and what was found
     in your commit message.</p>
 <p>Then, the correct way to work around this is to set
     <code class="varname">DIST_SUBDIR</code> to a unique directory name, usually
     based on <code class="varname">PKGNAME_NOREV</code> (but take care with
     python or ruby packages, where <code class="varname">PKGNAME</code> includes
     a variable prefix). All <code class="varname">DISTFILES</code> and
     <code class="varname">PATCHFILES</code> for this package will be put in that
     subdirectory of the local distfiles directory. (See <a class="xref" href="#bumping-pkgrevision" title="21.1.10.�How to handle incrementing versions when fixing an existing package">Section�21.1.10, &#8220;How to handle incrementing versions when fixing an existing package&#8221;</a> for more details.) In case this
     happens more often, <code class="varname">PKGNAME</code> can be used (thus
     including the <code class="filename">nbX</code> suffix) or a date stamp can
     be appended, like
     <code class="varname">${PKGNAME_NOREV}-YYYYMMDD</code>.</p>
 <p><code class="varname">DIST_SUBDIR</code> is also used when a distfile's
     name does not contain a version and the distfile is apt to change. In
     cases where the likelihood of this is very small,
     <code class="varname">DIST_SUBDIR</code> might not be required. Additionally,
     <code class="varname">DIST_SUBDIR</code> must not be removed unless the
     distfile name changes, even if a package is being moved or
     renamed.</p>
 <p>Do not forget regenerating the <code class="filename">distinfo</code> file
     after that, since it contains the <code class="varname">DIST_SUBDIR</code>
     path in the filenames.
     Also, increase the PKGREVISION if the installed package is different.
     Furthermore, a mail to the package's authors seems appropriate
     telling them that changing distfiles after releases without
     changing the file names is not good practice.</p>
 </div>
 <div class="sect2">
 <div class="titlepage"><div><div><h3 class="title">
 <a name="build.fetch.github"></a>21.2.3.�Packages hosted on github.com</h3></div></div></div>
 <p>Helper methods exist for packages hosted on github.com which
     will often have distfile names that clash with other packages, for
     example <code class="filename">1.0.tar.gz</code>. Use one of the three recipes
     from below:</p>
 <div class="sect3">
 <div class="titlepage"><div><div><h4 class="title">
 <a name="build.fetch.github.tag"></a>21.2.3.1.�Fetch based on a tagged release</h4></div></div></div>
 <p>If your distfile URL looks similar to
       <code class="literal">https://github.com/username/example/archive/v1.0.zip</code>,
       then you are packaging a tagged release.</p>
 <pre class="programlisting">
 DISTNAME=       example-1.0
 MASTER_SITES=   ${MASTER_SITE_GITHUB:=username/}
 #GITHUB_PROJECT= example    # can be omitted if same as DISTNAME
 GITHUB_TAG=     v${PKGVERSION_NOREV}
 EXTRACT_SUFX=   .zip
 </pre>
 </div>
 <div class="sect3">
 <div class="titlepage"><div><div><h4 class="title">
 <a name="build.fetch.github.commit.prerelease"></a>21.2.3.2.�Fetch based on a specific commit before the first release</h4></div></div></div>
 <p>If your distfile looks similar to
       <code class="literal">https://github.com/username/example/archive/988881adc9fc3655077dc2d4d757d480b5ea0e11</code> and is from a commit before the first
       release, then set the package version to 0.0.0.N, where N is the number
       of commits to the repository, and set GITHUB_TAG to the commit hash.
       This will (almost) ensure that the first tagged release will have a
       version greater than this one so that package upgrades will function
       properly.</p>
 <pre class="programlisting">
 DISTNAME=       example-0.0.0.347
 MASTER_SITES=   ${MASTER_SITE_GITHUB:=username/}
 #GITHUB_PROJECT= example    # can be omitted if same as DISTNAME
 GITHUB_TAG=     988881adc9fc3655077dc2d4d757d480b5ea0e11
 </pre>
 </div>
 <div class="sect3">
 <div class="titlepage"><div><div><h4 class="title">
 <a name="build.fetch.github.commit.postrelease"></a>21.2.3.3.�Fetch based on a specific commit after a release</h4></div></div></div>
 <p>If your distfile looks similar to
       <code class="literal">https://github.com/username/example/archive/988881adc9fc3655077dc2d4d757d480b5ea0e11</code> and is from a commit after a release,
       then include the last release version and the commit count since that
       release in the package version and set GITHUB_TAG to the commit hash.
       The latest release and commit count are shown in the output of
       "git describe --tags":
       </p>
 <pre class="screen">
 # git clone https://github.com/username/example
 # cd example
 # git describe --tags
 .2.3-5-g988881a
 </pre>
 <pre class="programlisting">
 DISTNAME=       example-1.2.3.5
 MASTER_SITES=   ${MASTER_SITE_GITHUB:=username/}
 #GITHUB_PROJECT= example    # can be omitted if same as DISTNAME
 GITHUB_TAG=     988881adc9fc3655077dc2d4d757d480b5ea0e11
 </pre>
 </div>
 <div class="sect3">
 <div class="titlepage"><div><div><h4 class="title">
 <a name="build.fetch.github.release"></a>21.2.3.4.�Fetch based on release</h4></div></div></div>
 <p>If your distfile URL looks similar to
       <code class="literal">https://github.com/username/example/releases/download/rel-1.6/offensive-1.6.zip</code>,
       then you are packaging a release.</p>
 <pre class="programlisting">
 DISTNAME=       offensive-1.6
 PKGNAME=        ${DISTNAME:S/offensive/proper/}
 MASTER_SITES=   ${MASTER_SITE_GITHUB:=username/}
 GITHUB_PROJECT= example
 GITHUB_RELEASE= rel-${PKGVERSION_NOREV} # usually just set this to ${DISTNAME}
 EXTRACT_SUFX=   .zip
 </pre>
 </div>
 </div>
 </div>
 <div class="sect1">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
 <a name="fixes.configure"></a>21.3.�The <span class="emphasis"><em>configure</em></span> phase</h2></div></div></div>
 <div class="sect2">
 <div class="titlepage"><div><div><h3 class="title">
 <a name="fixes.libtool"></a>21.3.1.�Shared libraries - libtool</h3></div></div></div>
 <p>pkgsrc supports many different machines, with different
     object formats like a.out and ELF, and varying abilities to do
     shared library and dynamic loading 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
     <a href="https://cdn.NetBSD.org/pub/pkgsrc/current/pkgsrc/devel/libtool/index.html" target="_top"><code class="filename">devel/libtool</code></a> pkg
     can help here, as it just <span class="quote">&#8220;<span class="quote">knows</span>&#8221;</span> how to build
     both static and dynamic libraries from a set of source files,
     thus being platform-independent.</p>
 <p>Here's how to use libtool in a package in seven simple
     steps:</p>
 <div class="orderedlist"><ol class="orderedlist" type="1">
 <li class="listitem"><p>Add <code class="varname">USE_LIBTOOL=yes</code> to the package
 	Makefile.</p></li>
 <li class="listitem"><p>For library objects, use <span class="quote">&#8220;<span class="quote">${LIBTOOL} --mode=compile
 	${CC}</span>&#8221;</span> in place of <span class="quote">&#8220;<span class="quote">${CC}</span>&#8221;</span>. You could even
 	add it to the definition of <code class="varname">CC</code>, if only
 	libraries are being built in a given Makefile. This one command
 	will build both PIC and non-PIC library objects, so you need not
 	have separate shared and non-shared library rules.</p></li>
 <li class="listitem">
 <p>For the linking of the library, remove any
 	<span class="quote">&#8220;<span class="quote">ar</span>&#8221;</span>, <span class="quote">&#8220;<span class="quote">ranlib</span>&#8221;</span>, and <span class="quote">&#8220;<span class="quote">ld
 	-Bshareable</span>&#8221;</span> commands, and instead use:</p>
 <pre class="programlisting">
 ${LIBTOOL} --mode=link \
     ${CC} -o ${.TARGET:.a=.la} \
         ${OBJS:.o=.lo} \
         -rpath ${PREFIX}/lib \
         -version-info major:minor
 </pre>
 <p>Note that the library is changed to have a
 	<code class="filename">.la</code> extension, and the objects are
 	changed to have a <code class="filename">.lo</code>
 	extension. Change <code class="varname">OBJS</code> as
 	necessary. This automatically creates all of the
 	<code class="filename">.a</code>,
 	<code class="filename">.so.major.minor</code>, and ELF symlinks (if
 	necessary) in the build directory. Be sure to include
 	<span class="quote">&#8220;<span class="quote">-version-info</span>&#8221;</span>, especially when major and
 	minor are zero, as libtool will otherwise strip off the
 	shared library version.</p>
 <p>From the libtool manual:</p>
 <pre class="programlisting">
 So, libtool library versions are described by three integers:
 CURRENT
 The most recent interface number that this library implements.
 REVISION
 The implementation number of the CURRENT interface.
 AGE
 The difference between the newest and oldest interfaces that
 this library implements.  In other words, the library implements
 all the interface numbers in the range from number `CURRENT -
 AGE' to `CURRENT'.
 If two libraries have identical CURRENT and AGE numbers, then the
 dynamic linker chooses the library with the greater REVISION number.
 </pre>
 <p>The <span class="quote">&#8220;<span class="quote">-release</span>&#8221;</span> option will produce
 	different results for a.out and ELF (excluding symlinks)
 	in only one case. An ELF library of the form
 	<span class="quote">&#8220;<span class="quote">libfoo-release.so.<span class="emphasis"><em>x</em></span>.<span class="emphasis"><em>y</em></span></span>&#8221;</span>
 	will have a symlink of
 	<span class="quote">&#8220;<span class="quote">libfoo.so.<span class="emphasis"><em>x</em></span>.<span class="emphasis"><em>y</em></span></span>&#8221;</span>
 	on an a.out platform. This is handled
 	automatically.</p>
 <p>The <span class="quote">&#8220;<span class="quote">-rpath argument</span>&#8221;</span> is the install
 	directory of the library being built.</p>
 <p>In the <code class="filename">PLIST</code>, include only the
 	<code class="filename">.la</code> file, the other files will be
 	added automatically.</p>
 </li>
 <li class="listitem">
 <p>When linking shared object (<code class="filename">.so</code>)
 	files, i.e. files that are loaded via <a class="citerefentry" href="https://man.NetBSD.org/NetBSD-9.2/i386/dlopen.3"><span class="citerefentry"><span class="refentrytitle">dlopen</span>(3)</span></a>, NOT
 	shared libraries, use <span class="quote">&#8220;<span class="quote">-module
 	-avoid-version</span>&#8221;</span> to prevent them getting version
 	tacked on.</p>
 <p>The <code class="filename">PLIST</code> file gets the
 	<code class="filename">foo.so</code> entry.</p>
 </li>
 <li class="listitem">
 <p>When linking programs that depend on these libraries
 	<span class="emphasis"><em>before</em></span> they are installed, preface
 	the <a class="citerefentry" href="https://man.NetBSD.org/NetBSD-9.2/i386/cc.1"><span class="citerefentry"><span class="refentrytitle">cc</span>(1)</span></a> or <a class="citerefentry" href="https://man.NetBSD.org/NetBSD-9.2/i386/ld.1"><span class="citerefentry"><span class="refentrytitle">ld</span>(1)</span></a> line with <span class="quote">&#8220;<span class="quote">${LIBTOOL}
 	--mode=link</span>&#8221;</span>, and it will find the correct
 	libraries (static or shared), but please be aware that
 	libtool will not allow you to specify a relative path in
 	-L (such as <span class="quote">&#8220;<span class="quote">-L../somelib</span>&#8221;</span>), because it
 	expects you to change that argument to be the
 	<code class="filename">.la</code> file. e.g.</p>
 <pre class="programlisting">
 ${LIBTOOL} --mode=link ${CC} -o someprog -L../somelib -lsomelib
 </pre>
 <p>should be changed to:</p>
 <pre class="programlisting">
 ${LIBTOOL} --mode=link ${CC} -o <em class="replaceable"><code>someprog</code></em> <em class="replaceable"><code>../somelib/somelib.la</code></em>
 </pre>
 <p>and it will do the right thing with the libraries.</p>
 </li>
 <li class="listitem">
 <p>When installing libraries, preface the <a class="citerefentry" href="https://man.NetBSD.org/NetBSD-9.2/i386/install.1"><span class="citerefentry"><span class="refentrytitle">install</span>(1)</span></a>
 	or <a class="citerefentry" href="https://man.NetBSD.org/NetBSD-9.2/i386/cp.1"><span class="citerefentry"><span class="refentrytitle">cp</span>(1)</span></a> command with <span class="quote">&#8220;<span class="quote">${LIBTOOL}
 	--mode=install</span>&#8221;</span>, and change the library name to
 	<code class="filename">.la</code>. e.g.</p>
 <pre class="programlisting">
 ${LIBTOOL} --mode=install ${BSD_INSTALL_LIB} ${SOMELIB:.a=.la} ${PREFIX}/lib
 </pre>
 <p>This will install the static <code class="filename">.a</code>,
 	shared library, any needed symlinks, and run
 	<a class="citerefentry" href="https://man.NetBSD.org/NetBSD-9.2/i386/ldconfig.8"><span class="citerefentry"><span class="refentrytitle">ldconfig</span>(8)</span></a>.</p>
 </li>
 <li class="listitem"><p>In your <code class="filename">PLIST</code>, include only
 	the <code class="filename">.la</code>
 	file (this is a change from previous behaviour).</p></li>
 </ol></div>
 </div>
 <div class="sect2">
 <div class="titlepage"><div><div><h3 class="title">
 <a name="using-libtool"></a>21.3.2.�Using libtool on GNU packages that already support libtool</h3></div></div></div>
 <p>Add <code class="varname">USE_LIBTOOL=yes</code> to the
     package Makefile. This will override the package's own libtool
     in most cases.  For older libtool using packages,  libtool is
     made by ltconfig script during the do-configure step; you can
     check the libtool script location by doing <span class="command"><strong>make
     configure; find work*/ -name libtool</strong></span>.</p>
 <p><code class="varname">LIBTOOL_OVERRIDE</code> specifies which libtool
     scripts, relative to <code class="varname">WRKSRC</code>, to override.  By
     default, it is set to <span class="quote">&#8220;<span class="quote">libtool */libtool
     */*/libtool</span>&#8221;</span>.  If this does not match the location of the
     package's libtool script(s), set it as appropriate.</p>
 <p>If you do not need <code class="filename">*.a</code> static
     libraries built and installed, then use
     <code class="varname">SHLIBTOOL_OVERRIDE</code> instead.</p>
 <p>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.</p>
 <p>Some packages use libtool incorrectly so that the package
     may not work or build in some circumstances. Some of the more
     common errors are:</p>
 <div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; ">
 <li class="listitem">
 <p>The inclusion of a shared object (-module) as a dependent library in an
 	executable or library. This in itself isn't a problem if one of two things
 	has been done:</p>
 <div class="orderedlist"><ol class="orderedlist" type="1">
 <li class="listitem"><p>The shared object is named correctly, i.e.
 	    <code class="filename">libfoo.la</code>, not
 	    <code class="filename">foo.la</code></p></li>
 <li class="listitem"><p>The -dlopen option is used when linking an executable.</p></li>
 </ol></div>
 </li>
 <li class="listitem"><p>The use of libltdl without the correct calls to initialisation routines.
 	The function lt_dlinit() should be called and the macro
 	<code class="varname">LTDL_SET_PRELOADED_SYMBOLS</code> included in
 	executables.</p></li>
 </ul></div>
 </div>
 <div class="sect2">
 <div class="titlepage"><div><div><h3 class="title">
 <a name="autoconf-automake"></a>21.3.3.�GNU Autoconf/Automake</h3></div></div></div>
 <p>If a package needs GNU autoconf or automake to be executed
     to regenerate the
     <code class="filename">configure</code>
     script and <code class="filename">Makefile.in</code> makefile
     templates from <code class="filename">configure.ac</code> and
     <code class="filename">Makefile.am</code>,
     then they should be executed in a pre-configure target:</p>
 <pre class="programlisting">
 USE_TOOLS+=	autoconf automake autoreconf
 GNU_CONFIGURE=	yes
 ...
 pre-configure:
         set -e; cd ${WRKSRC} &amp;&amp; autoreconf -fi
 ...
 </pre>
 <p>Packages which use GNU Automake will sometimes
     require GNU Make (<code class="literal">gmake</code> in
     <code class="varname">USE_TOOLS</code>),
     but not always.  Note that autoreconf
     only needs to be executed if <code class="filename">configure.ac</code>
     or Makefiles are modified, or <code class="filename">configure</code>
     is not present.</p>
 <p>There are times when the configure process makes
     additional changes to the generated files, which then causes
     the build process to try to re-execute the automake sequence.
     This is prevented by touching various files in the configure
     stage. If this causes problems with your package you can set
     <code class="varname">AUTOMAKE_OVERRIDE=NO</code> in the package
     Makefile.</p>
 </div>
 <div class="sect2">
 <div class="titlepage"><div><div><h3 class="title">
 <a name="meson"></a>21.3.4.�Meson / ninja</h3></div></div></div>
 <p>Packages using Meson to configure need to include:
 </p>
 <pre class="programlisting">
 .include "../../devel/meson/build.mk"
 </pre>
 <p>In nearly all cases (any program with dependencies),
     pkg-config needs to be added to
     <code class="varname">USE_TOOLS</code>.  If the package installs
     translation files for non-English languages, also
     add msgfmt and xgettext:
 </p>
 <pre class="programlisting">
 USE_TOOLS+=	pkg-config msgfmt xgettext
 </pre>
 <p>If any options need to be passed to Meson, use
     <code class="varname">MESON_ARGS</code> instead of
     <code class="varname">CONFIGURE_ARGS</code>:
 </p>
 <pre class="programlisting">
 MESON_ARGS+=	-Dx11=false
 </pre>
 </div>
 </div>
 <div class="sect1">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
 <a name="programming-languages"></a>21.4.�Programming languages</h2></div></div></div>
 <div class="sect2">
 <div class="titlepage"><div><div><h3 class="title">
 <a name="basic-programming-languages"></a>21.4.1.�C, C++, and Fortran</h3></div></div></div>
 <p>Compilers for the C and C++ languages comes with
     the NetBSD base system.  By default, pkgsrc assumes that a package
     is written in C and will hide all other compilers (via the wrapper
     framework, see <a class="xref" href="#buildlink" title="Chapter�18.�Buildlink methodology">Chapter�18, <i>Buildlink methodology</i></a>).</p>
 <p>To declare which language's compiler a package needs, set
     the <code class="varname">USE_LANGUAGES</code> variable. Allowed values
     currently are:
     </p>
 <pre class="programlisting">
 	c99, c++, c++03, gnu++03, c++0x, gnu++0x, c++11, gnu++11,
 	c++14, gnu++14, c++17, gnu++17, c++20, gnu++20, fortran,
 	fortran77, java, objc, obj-c++, and ada.
     </pre>
 <p>
     (and any combination).  The default is
     <span class="quote">&#8220;<span class="quote">c</span>&#8221;</span>.  Packages using GNU configure scripts, even if
     written in C++, usually need a C compiler for the configure
     phase.</p>
 <p>To express a general requirement on a specific C or C++
     version, normally only <code class="varname">GCC_REQD</code> needs to be set.
     For example, GCC 7 includes support for C++17, so if the package uses
     C++17 it should specify:
     </p>
 <pre class="programlisting">
 	GCC_REQD+=	7
     </pre>
 <p>Language variants like <code class="literal">c++11</code> for
     <code class="varname">USE_LANGUAGES</code> should only be specified
     if the package does not explicitly set <code class="literal">-std=...</code>
     when compiling (i.e. the package assumes the compiler defaults to
     C++11 or some other standard).  This is usually a bug in the
     upstream build system.</p>
 <p>GCC version 5 includes support for C++14, while GCC 4.7 includes
     more-or-less complete support for C++11.  For more information, consult
     <a class="ulink" href="https://gcc.gnu.org/projects/cxx-status.html" target="_top">GCC's own documentation on programming language support.</a></p>
 </div>
 <div class="sect2">
 <div class="titlepage"><div><div><h3 class="title">
 <a name="java-programming-language"></a>21.4.2.�Java</h3></div></div></div>
 <p>If a program is written in Java, use the Java framework in
     pkgsrc.  The package must include
     <code class="filename">../../mk/java-vm.mk</code>.  This Makefile fragment
     provides the following variables:</p>
 <div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; ">
 <li class="listitem"><p><code class="varname">USE_JAVA</code> defines if a build
       dependency on the JDK is added.  If
       <code class="varname">USE_JAVA</code> is set to <span class="quote">&#8220;<span class="quote">run</span>&#8221;</span>, then
       there is only a runtime dependency on the JDK.  The default is
       <span class="quote">&#8220;<span class="quote">yes</span>&#8221;</span>, which also adds a build dependency on the
       JDK.</p></li>
 <li class="listitem"><p>Set <code class="varname">USE_JAVA2</code> to declare that
       a package needs a Java2 implementation.  The supported values
       are <span class="quote">&#8220;<span class="quote">yes</span>&#8221;</span>, <span class="quote">&#8220;<span class="quote">1.4</span>&#8221;</span>, and
       <span class="quote">&#8220;<span class="quote">1.5</span>&#8221;</span>.  <span class="quote">&#8220;<span class="quote">yes</span>&#8221;</span> accepts any Java2
       implementation, <span class="quote">&#8220;<span class="quote">1.4</span>&#8221;</span> insists on versions 1.4 or
       above, and <span class="quote">&#8220;<span class="quote">1.5</span>&#8221;</span> only accepts versions 1.5 or
       above. This variable is not set by default.</p></li>
 <li class="listitem"><p><code class="varname">PKG_JAVA_HOME</code> is
       automatically set to the runtime location of the used Java
       implementation dependency. It may be used to set
       <code class="varname">JAVA_HOME</code> to a good value if the program
       needs this variable to be defined.
       </p></li>
 </ul></div>
 </div>
 <div class="sect2">
 <div class="titlepage"><div><div><h3 class="title">
 <a name="go-programming-language"></a>21.4.3.�Go</h3></div></div></div>
 <p>If a program is written in Go and has any dependencies on
     other Go modules, have the package include
     <code class="filename">../../lang/go/go-module.mk</code>.</p>
 <div class="orderedlist"><ol class="orderedlist" type="1">
 <li class="listitem"><p>Generate a list of those dependencies with
       <span class="command"><strong>make clean &amp;&amp; make patch &amp;&amp; make show-go-modules &gt;
       go-modules.mk</strong></span>.</p></li>
 <li class="listitem"><p>Prepend
       <code class="literal">.include "go-modules.mk"</code> to any other
       <code class="literal">.include</code>s.</p></li>
 <li class="listitem"><p>Incorporate these modules in
       <code class="filename">distinfo</code> with <span class="command"><strong>make
       makesum</strong></span>.</p></li>
 </ol></div>
 </div>
 <div class="sect2">
 <div class="titlepage"><div><div><h3 class="title">
 <a name="rust-programming-language"></a>21.4.4.�Rust</h3></div></div></div>
 <p>If a program is written in Rust and uses Cargo to build,
     have the package include
     <code class="filename">../../lang/rust/cargo.mk</code>.</p>
 <div class="orderedlist"><ol class="orderedlist" type="1">
 <li class="listitem"><p>Generate a list of those dependencies with
       <span class="command"><strong>make CARGO_ARGS="build --release" build &amp;&amp;
       make print-cargo-depends &gt; cargo-depends.mk</strong></span>.</p></li>
 <li class="listitem"><p>Prepend
       <code class="literal">.include "cargo-depends.mk"</code> to any other
       <code class="literal">.include</code>s.</p></li>
 <li class="listitem"><p>Incorporate these modules in
       <code class="filename">distinfo</code> with <span class="command"><strong>make
       makesum</strong></span>.</p></li>
 </ol></div>
 </div>
 <div class="sect2">
 <div class="titlepage"><div><div><h3 class="title">
 <a name="perl-scripts"></a>21.4.5.�Packages containing Perl scripts</h3></div></div></div>
 <p>If your package contains interpreted Perl scripts, add
     <span class="quote">&#8220;<span class="quote">perl</span>&#8221;</span> to the <code class="varname">USE_TOOLS</code> variable
     and set <code class="varname">REPLACE_PERL</code> to ensure that the proper
     interpreter path is set. <code class="varname">REPLACE_PERL</code> should
     contain a list of scripts, relative to <code class="varname">WRKSRC</code>,
     that you want adjusted. Every occurrence of
     <code class="filename">*/bin/perl</code> in a she-bang line will be
     replaced with the full path to the Perl executable.</p>
 <p>If a particular version of Perl is needed, set the
     <code class="varname">PERL5_REQD</code> variable to the version number.  The
     default is <span class="quote">&#8220;<span class="quote">5.0</span>&#8221;</span>.</p>
 <p>See <a class="xref" href="#perl-modules" title="21.6.6.�Packages installing Perl modules">Section�21.6.6, &#8220;Packages installing Perl modules&#8221;</a> for information
     about handling Perl modules.</p>
 <p>There is also the <code class="varname">REPLACE_PERL6</code> variable
     for the language now known as Raku.</p>
 </div>
 <div class="sect2">
 <div class="titlepage"><div><div><h3 class="title">
 <a name="shell-scripts"></a>21.4.6.�Packages containing shell scripts</h3></div></div></div>
 <p><code class="varname">REPLACE_SH</code>,
     <code class="varname">REPLACE_BASH</code>, <code class="varname">REPLACE_CSH</code>,
     and <code class="varname">REPLACE_KSH</code> can be used to replace shell
-    hash bangs in files. Please use the appropriate one, preferring
+    she-bangs in files. Please use the appropriate one, preferring
-    <code class="varname">REPLACE_SH</code> in case this shell is sufficient.
+    <code class="varname">REPLACE_SH</code> when this shell is sufficient.
     Each should contain a list of scripts, relative to
     <code class="varname">WRKSRC</code>, that you want adjusted. Every
     occurrence of the matching shell in a she-bang line will be
     replaced with the full path to the shell executable.
     When using <code class="varname">REPLACE_BASH</code>, don't forget to add
     <code class="filename">bash</code> to <code class="varname">USE_TOOLS</code>.</p>
 </div>
 <div class="sect2">
 <div class="titlepage"><div><div><h3 class="title">
 <a name="other-programming-languages"></a>21.4.7.�Other programming languages</h3></div></div></div>
 <p>There are further similar REPLACE variables available, e.g.,
     <code class="varname">REPLACE_AWK</code> for packages containing awk scripts,
     and <code class="varname">REPLACE_R</code> for R. These two, like the others
     noted above, have their actions defined centrally in
     <code class="filename">mk/configure/replace-interpreter.mk</code>. Other
     languages define the actions of these variables within their own
     dedicated part of the tree, e.g., <code class="varname">REPLACE_PHP</code> is
     actioned in <code class="filename">lang/php/phpversion.mk</code>, and
     <code class="varname">REPLACE_PYTHON</code> is actioned in
     <code class="filename">lang/python/application.mk</code>. For other languages,
     consult the mk files found within their specific directories (the
     naming convention varies), or check the list found in
     <a class="xref" href="#help-topics" title="Appendix�E.�Help topics">Appendix�E, <i>Help topics</i></a>.</p>
 <p>Currently, special handling for other languages varies
     in pkgsrc.  If a compiler package provides a
     <code class="filename">buildlink3.mk</code> file, include that, otherwise
     just add a (build) dependency on the appropriate compiler
     package.</p>
 </div>
 </div>
 <div class="sect1">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
 <a name="fixes.build"></a>21.5.�The <span class="emphasis"><em>build</em></span> phase</h2></div></div></div>
 <p>The most common failures when building a package are that
 	some platforms do not provide certain header files, functions or
 	libraries, or they provide the functions in a library that the
 	original package author didn't know. To work around this, you
 	can rewrite the source code in most cases so that it does not
 	use the missing functions or provides a replacement function.</p>
 <div class="sect2">
 <div class="titlepage"><div><div><h3 class="title">
 <a name="fixes.build.cpp"></a>21.5.1.�Compiling C and C++ code conditionally</h3></div></div></div>
 <p>If a package already comes with a GNU configure script, the
 	preferred way to fix the build failure is to change the
 	configure script, not the code. In the other cases, you can
 	utilize the C preprocessor, which defines certain macros
 	depending on the operating system and hardware architecture it
 	compiles for. These macros can be queried using for example
 	<code class="varname">#if defined(__i386)</code>. Almost every operating
 	system, hardware architecture and compiler has its own macro.
 	For example, if the macros <code class="varname">__GNUC__</code>,
 	<code class="varname">__i386__</code> and <code class="varname">__NetBSD__</code>
 	are all defined, you know that you are using NetBSD on an i386
 	compatible CPU, and your compiler is GCC.</p>
 <p>The list of the following macros for hardware and
 	operating system depends on the compiler that is used. For
 	example, if you want to conditionally compile code on Solaris,
 	don't use <code class="varname">__sun__</code>, as the SunPro compiler
 	does not define it. Use <code class="varname">__sun</code> instead.</p>
 <div class="sect3">
 <div class="titlepage"><div><div><h4 class="title">
 <a name="fixes.build.cpp.os"></a>21.5.1.1.�C preprocessor macros to identify the operating system</h4></div></div></div>
 <p>To distinguish between specific NetBSD versions,
         you should use the following code.</p>
 <pre class="programlisting">
 #ifdef __NetBSD__
 #include &lt;sys/param.h&gt;
 #if __NetBSD_Prereq__(9,99,17)
 /* use a newer feature */
 #else
 /* older code */
 #endif
 #endif
 #ifndef _WIN32
 /* Unix-like specific code */
 #endif
 </pre>
 <p>To distinguish between 4.4 BSD-derived systems and the
         rest of the world, you should use the following code.</p>
 <pre class="programlisting">
 #include &lt;sys/param.h&gt;
 #if (defined(BSD) &amp;&amp; BSD &gt;= 199306)
 /* BSD-specific code goes here */
 #else
 /* non-BSD-specific code goes here */
 #endif
 </pre>
 <p>You can also test for the following macros:</p>
 <pre class="programlisting">
 Cygwin      __CYGWIN__
 DragonFly   __DragonFly__
 FreeBSD     __FreeBSD__
 Haiku       __HAIKU__
 Interix     __INTERIX
 IRIX        __sgi (TODO: get a definite source for this)
 Linux       __linux
 Mac OS X    __APPLE__
 MirBSD      __MirBSD__ (__OpenBSD__ is also defined)
 Minix3      __minix
 NetBSD      __NetBSD__
 OpenBSD     __OpenBSD__
 Solaris     sun, __sun
 </pre>
 </div>
 <div class="sect3">
 <div class="titlepage"><div><div><h4 class="title">
 <a name="fixes.build.cpp.arch"></a>21.5.1.2.�C preprocessor macros to identify the hardware architecture</h4></div></div></div>
 <pre class="programlisting">
 i386        i386, __i386, __i386__
 x86-64      __amd64__, __x86_64__
 ARM         __arm__
 MIPS        __mips
 SPARC       sparc, __sparc
 PowerPC     __powerpc
 </pre>
 </div>
 <div class="sect3">
 <div class="titlepage"><div><div><h4 class="title">
 <a name="fixes.build.cpp.compiler"></a>21.5.1.3.�C preprocessor macros to identify the compiler</h4></div></div></div>
 <pre class="programlisting">
 GCC         __GNUC__ (major version), __GNUC_MINOR__
 MIPSpro     _COMPILER_VERSION (0x741 for MIPSpro 7.41)
 SunPro      __SUNPRO_C (0x570 for Sun C 5.7)
 SunPro C++  __SUNPRO_CC (0x580 for Sun C++ 5.8)
 </pre>
 </div>
 </div>
 <div class="sect2">
 <div class="titlepage"><div><div><h3 class="title">
 <a name="compiler-bugs"></a>21.5.2.�How to handle compiler bugs</h3></div></div></div>
 <p>Some source files trigger bugs in the compiler, based on
         combinations of compiler version and architecture and almost
         always relation to optimisation being enabled.  Common symptoms
         are gcc internal errors or never finishing compiling a
 	file.</p>
 <p>Typically, a workaround involves testing the
         <code class="varname">MACHINE_ARCH</code> and compiler version, disabling
         optimisation for that combination of file,
 	<code class="varname">MACHINE_ARCH</code> and compiler.</p>
 <p>This used to be a big problem in the past, but is rarely
 	needed now as compiler technology has matured. If you still need
 	to add a compiler specific workaround, please do so in the file
 	<code class="filename">hacks.mk</code> and describe the symptom and
 	compiler version as detailed as possible.</p>
 </div>
 <div class="sect2">
 <div class="titlepage"><div><div><h3 class="title">
 <a name="fixes.build.header"></a>21.5.3.�No such file or directory</h3></div></div></div>
 <p>Compilation sometimes fails with an error message like this:</p>
 <pre class="programlisting">
 .../x11/gtk3/work/gtk+-3.24.12/gdk/gdktypes.h:35:10:
     fatal error: pango/pango.h: No such file or directory
 </pre>
 <p>The proper way to fix this problem depends on the type of the
 header, which is described in the following sections.</p>
 <div class="sect3">
 <div class="titlepage"><div><div><h4 class="title">
 <a name="fixes.build.header.bl3"></a>21.5.3.1.�Headers from other packages</h4></div></div></div>
 <p>If the header name looks like it comes from a different package,
 that other package should be included via the buildlink3
 framework.</p>
 <p>First, look whether the header is somewhere in the buildlink3
 directory below <code class="varname">WRKDIR</code>. In the above case of
 the missing Pango header:</p>
 <pre class="programlisting">
 <code class="prompt">$</code> find work/.buildlink/ -print | grep -F pango/pango.h
 </pre>
 <p>In the case of Pango, the output is:</p>
 <pre class="programlisting">
 work/.buildlink/include/pango-1.0/pango/pango.h
 </pre>
 <p>If the <code class="filename">pango/pango.h</code> file were placed directly
 in the <code class="filename">.buildlink</code> directory, it would have been
 found automatically. There is an extra <code class="filename">pango-1.0</code>
 path component though, which means that the compiler command line must
 contain an option of the form
 <code class="literal">-I${BUILDLINK3_PREFIX.pango}/include/pango-1.0</code>. In
 most cases this option is generated by the configure script, which can be examined using:</p>
 <pre class="programlisting">
 <code class="prompt">$</code> $ grep -o '[-]I[^[:space:]]*/pango[^[:space:]]*' work/*/Makefile
 -I/usr/pkg/include/pango-1.0
 -I/usr/pkg/include/pango-1.0
 -I/usr/pkg/include/pango-1.0
 -I/usr/pkg/include/pango-1.0
 -I/usr/pkg/include/pango-1.0
 </pre>
 <p>This looks good. These options are transformed by the buildlink
 wrapper to refer to the correct path inside
 <code class="filename">work/.buildlink</code>.</p>
 <p>Since the compilation fails though, examine the compiler command
 lines in <code class="filename">work/.work.log</code> to see whether the
 <code class="literal">-I</code> option is included in the particular command
 line.</p>
 <p>To further analyze the situation, run <span class="command"><strong>bmake
 build-env</strong></span>, which sets up an interactive, realistic environment
 including all the pkgsrc wrapper commands and environment variables. From
 there, try to compile some simple example programs that use the
 header.</p>
 </div>
 <div class="sect3">
 <div class="titlepage"><div><div><h4 class="title">
 <a name="fixes.build.header.gen"></a>21.5.3.2.�Headers generated during the build</h4></div></div></div>
 <p>If the name of the header seems to come from the package itself,
 and if the build is run with parallel jobs, the package may have some
 undeclared dependencies between the <code class="filename">.c</code> and the
 <code class="filename">.h</code> files, and a C file is compiled before its
 required header is generated.</p>
 <p>To see whether the build runs with parallel jobs, run
 <span class="command"><strong>bmake show-all-build | grep JOBS</strong></span>. Its output looks
 like this:</p>
 <pre class="programlisting">
   usr   MAKE_JOBS=              7
   pkg   MAKE_JOBS_SAFE          # undefined
   def   _MAKE_JOBS_N=           7
 </pre>
 <p>In this case the pkgsrc user has asked pkgsrc to build packages
 with 7 jobs in parallel (<code class="varname">MAKE_JOBS</code>). The
 package could have disabled parallel builds by setting
 <code class="varname">MAKE_JOBS_SAFE</code> to <code class="literal">no</code>, but
 in this case it hasn't.</p>
 <p>To see whether the build failure is caused by parallel builds,
 first save the exact error message and a bit of context, maybe you need
 it later for reporting a bug. Next, run:</p>
 <pre class="programlisting">
 MAKE_JOBS_SAFE=no bmake clean build
 </pre>
 <p>If that succeeds, <a class="ulink" href="https://www.NetBSD.org/cgi-bin/sendpr.cgi?gndb=netbsd" target="_top">file a bug
 report</a> against the pkgsrc package, including the exact error
 message and the contents of your <a class="link" href="#mk.conf"><code class="filename">mk.conf</code></a> file.</p>
 </div>
 <div class="sect3">
 <div class="titlepage"><div><div><h4 class="title">
 <a name="fixes.build.header.symlink"></a>21.5.3.3.�Symlinks</h4></div></div></div>
 <p>Pkgsrc does not work reliably if any of
 <code class="varname">LOCALBASE</code>, <code class="varname">VARBASE</code> or
 <code class="varname">WRKDIR</code> contains a symlink. Since 2019Q2, the pkgsrc
 bootstrap program prevents installing pkgsrc in symlink-based
 directories. Existing pkgsrc installations are not checked for symlinks
 though.</p>
 <p>The "No such file or directory" error messages are a typical
 symptom of symlinks, and it's quite difficult to find out that this is
 the actual cause.</p>
 </div>
 <div class="sect3">
 <div class="titlepage"><div><div><h4 class="title">
 <a name="fixes.build.header.stale"></a>21.5.3.4.�Stale working directories</h4></div></div></div>
 <p>When building a hierarchy of packages, it may happen that one
 package is built and then pkgsrc is updated. This situation can provoke
 various hard to diagnose build errors. To clean up the situation:</p>
 <pre class="programlisting">
 <code class="prompt">$</code> (cd ../../ &amp;&amp; cat mk/bsd.pkg.mk &gt;/dev/null &amp;&amp; rm -rf */*/work)
 </pre>
 <p>(The only purpose of the <code class="filename">bsd.pkg.mk</code> is to
 prevent running this command in the wrong directory.)</p>
 <p>If you have set <code class="varname">WRKOBJDIR</code> in <a class="link" href="#mk.conf"><code class="filename">mk.conf</code></a>, remove
 that directory as well.</p>
 </div>
 <div class="sect3">
 <div class="titlepage"><div><div><h4 class="title">
 <a name="fixes.build.header.misc"></a>21.5.3.5.�Other possible reasons</h4></div></div></div>
 <p>On platforms other than BSD, third-party packages are installed in
 <code class="filename">/usr/include</code>, together with the base system. This
 means that pkgsrc cannot distinguish between headers provided by the base
 system (which it needs) and headers from third-party packages (which are
 often included in pkgsrc as well). This can lead to subtle version
 mismatches.</p>
 <p>In pkgsrc installations that have been active for several years, it
 may happen that some files are manually deleted. To exclude this unlikely
 reason, run <span class="command"><strong>pkg_admin check</strong></span>.</p>
 <p>It may help to run <span class="command"><strong>pkg_admin rebuild-tree</strong></span> to
 check/fix dependencies.</p>
 <p>If all of the above doesn't help, see <a class="xref" href="#help-user" title="Chapter�2.�Getting help">Chapter�2, <i>Getting help</i></a>
 for contact information. Be prepared to describe what you have tried so
 far and what any error messages were.</p>
 </div>
 </div>
 <div class="sect2">
 <div class="titlepage"><div><div><h3 class="title">
 <a name="undefined-reference"></a>21.5.4.�Undefined reference to <span class="quote">&#8220;<span class="quote">...</span>&#8221;</span>
 </h3></div></div></div>
 <p>This error message often means that a package did not
 	link to a shared library it needs. The following functions are
 	known to cause this error message over and over.</p>
 <div class="informaltable">
 <a name="undefined-reference-functions"></a><table class="informaltable" border="1">
 <colgroup>
 <col>
 <col>
 <col>
 </colgroup>
 <thead><tr>
 <th>Function</th>
 <th>Library</th>
 <th>Affected platforms</th>
 </tr></thead>
 <tbody>
 <tr>
 <td>accept, bind, connect</td>
 <td>-lsocket</td>
 <td>Solaris</td>
 </tr>
 <tr>
 <td>crypt</td>
 <td>-lcrypt</td>
 <td>DragonFly, NetBSD</td>
 </tr>
 <tr>
 <td>dlopen, dlsym</td>
 <td>-ldl</td>
 <td>Linux</td>
 </tr>
 <tr>
 <td>gethost*</td>
 <td>-lnsl</td>
 <td>Solaris</td>
 </tr>
 <tr>
 <td>inet_aton</td>
 <td>-lresolv</td>
 <td>Solaris</td>
 </tr>
 <tr>
 <td>nanosleep, sem_*, timer_*</td>
 <td>-lrt</td>
 <td>Solaris</td>
 </tr>
 <tr>
 <td>openpty</td>
 <td>-lutil</td>
 <td>Linux</td>
 </tr>
 </tbody>
 </table>
 </div>
 <p>To fix these linker errors, it is often sufficient to add
     <code class="literal">LIBS.<em class="replaceable"><code>OperatingSystem</code></em>+=
     -l<em class="replaceable"><code>foo</code></em></code> to the package
     <code class="filename">Makefile</code> and then run <span class="command"><strong>bmake clean;
     bmake</strong></span>.</p>
 <div class="sect3">
 <div class="titlepage"><div><div><h4 class="title">
 <a name="undefined-reference-sunpro"></a>21.5.4.1.�The SunPro compiler and inline functions</h4></div></div></div>
 <p>When you are using the SunPro compiler, there is another
 possibility. That compiler cannot handle the following code:</p>
 <pre class="programlisting">
 extern int extern_func(int);
 static inline int
 inline_func(int x)
+{
         return extern_func(x);
+}
 int main(void)
+{
         return 0;
+}
 </pre>
 <p>It generates the code for <code class="function">inline_func</code> even if
 that function is never used. This code then refers to
 <code class="function">extern_func</code>, which can usually not be resolved. To
 solve this problem you can try to tell the package to disable inlining
 of functions.</p>
 </div>
 </div>
 <div class="sect2">
 <div class="titlepage"><div><div><h3 class="title">
 <a name="out-of-memory"></a>21.5.5.�Running out of memory</h3></div></div></div>
 <p>Sometimes packages fail to build because the compiler runs
     into an operating system specific soft limit.  With the
     <code class="varname">UNLIMIT_RESOURCES</code> variable pkgsrc can be told
     to unlimit the resources.  The allowed values are any combination of
     <span class="quote">&#8220;<span class="quote">cputime</span>&#8221;</span>,
     <span class="quote">&#8220;<span class="quote">datasize</span>&#8221;</span>,
     <span class="quote">&#8220;<span class="quote">memorysize</span>&#8221;</span>,
     <span class="quote">&#8220;<span class="quote">stacksize</span>&#8221;</span> and
     <span class="quote">&#8220;<span class="quote">virtualsize</span>&#8221;</span>.
     Setting this variable is similar to running the shell builtin
     <span class="command"><strong>ulimit</strong></span> command to raise the maximum data
     segment size or maximum stack size of a process, respectively, to
     their hard limits.</p>
 </div>
 </div>
 <div class="sect1">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
 <a name="fixes.install"></a>21.6.�The <span class="emphasis"><em>install</em></span> phase</h2></div></div></div>
 <div class="sect2">
 <div class="titlepage"><div><div><h3 class="title">
 <a name="install-scripts"></a>21.6.1.�Creating needed directories</h3></div></div></div>
 <p>The BSD-compatible <span class="command"><strong>install</strong></span> supplied
     with some operating systems cannot create more than one
     directory at a time. As such, you should call
     <code class="literal">${INSTALL_*_DIR}</code> like this:</p>
 <pre class="programlisting">
 ${INSTALL_DATA_DIR} ${PREFIX}/dir1
 ${INSTALL_DATA_DIR} ${PREFIX}/dir2
 </pre>
 <p>Instead of running the <span class="command"><strong>install</strong></span> commands
     directly, you can also append <span class="quote">&#8220;<span class="quote"><code class="literal">dir1
     dir2</code></span>&#8221;</span> to the <code class="varname">INSTALLATION_DIRS</code>
     variable, which will automatically do the right thing.</p>
 </div>
 <div class="sect2">
 <div class="titlepage"><div><div><h3 class="title">
 <a name="where-to-install-documentation"></a>21.6.2.�Where to install documentation</h3></div></div></div>
 <p>In general, documentation should be installed into
     <code class="filename">${PREFIX}/share/doc/${PKGBASE}</code> or
     <code class="filename">${PREFIX}/share/doc/${PKGNAME_NOREV}</code> (the latter
     includes the version number of the package).</p>
 <p>Many modern packages using GNU autoconf allow to set the
     directory where HTML documentation is installed with the
     <span class="quote">&#8220;<span class="quote">--with-html-dir</span>&#8221;</span> option. Sometimes using this flag is
     needed because otherwise the documentation ends up in
     <code class="filename">${PREFIX}/share/doc/html</code> or other places. In
     pkgsrc, the HTML documentation should go into the package-specific
     directory, just like any other documentation.</p>
 <p>An exception to the above is that library API documentation
     generated with the <a href="https://cdn.NetBSD.org/pub/pkgsrc/current/pkgsrc/textproc/gtk-doc/index.html" target="_top"><code class="filename">textproc/gtk-doc</code></a> tools, for use by special
     browsers (devhelp) should be left at their default location, which
     is <code class="filename">${PREFIX}/share/gtk-doc</code>.  Such
     documentation can be recognized from files ending in
     <code class="filename">.devhelp</code> or <code class="filename">.devhelp2</code>.
     (It is also acceptable to install such files in
     <code class="filename">${PREFIX}/share/doc/${PKGBASE}</code> or
     <code class="filename">${PREFIX}/share/doc/${PKGNAME}</code>; the
     <code class="filename">.devhelp*</code> file must be directly in that
     directory then, no additional subdirectory level is allowed in
     this case. This is usually achieved by using
     <span class="quote">&#8220;<span class="quote">--with-html-dir=${PREFIX}/share/doc</span>&#8221;</span>.
     <code class="filename">${PREFIX}/share/gtk-doc</code> is preferred
     though.)</p>
 </div>
 <div class="sect2">
 <div class="titlepage"><div><div><h3 class="title">
 <a name="installing-score-files"></a>21.6.3.�Installing highscore files</h3></div></div></div>
 <p>Certain packages, most of them in the games category, install
     a score file that allows all users on the system to record their
     highscores.  In order for this to work, the binaries need to be
     installed setgid and the score files owned by the appropriate
     group and/or owner (traditionally the "games" user/group).  Set
     <code class="varname">USE_GAMESGROUP</code> to yes to support this. The
     following variables, documented in more detail in
     <code class="filename">mk/defaults/mk.conf</code>, control this
     behaviour: <code class="varname">GAMEDATAMODE</code>,
     <code class="varname">GAMEDIRMODE</code>, <code class="varname">GAMES_GROUP</code>,
     <code class="varname">GAMEMODE</code>, <code class="varname">GAME_USER</code>.
     Other useful variables are: <code class="varname">GAMEDIR_PERMS</code>,
     <code class="varname">GAMEDATA_PERMS</code> and
     <code class="varname">SETGID_GAMES_PERMS</code>.</p>
 <p>An example that illustrates some of the variables described above is
     <code class="filename">games/moon-buggy</code>. <code class="varname">OWN_DIRS_PERMS</code> is
     used to properly set directory permissions of the directory where the
     scorefile is saved, <code class="varname">REQD_FILES_PERMS</code> is used to create a
     dummy scorefile (<code class="filename">mbscore</code>) with the proper permissions
     and <code class="varname">SPECIAL_PERMS</code> is used to install setgid the game
     binary:</p>
 <pre class="programlisting">
 USE_GAMESGROUP=         yes
 BUILD_DEFS+=            VARBASE
 OWN_DIRS_PERMS+=        ${VARBASE}/games/moon-buggy ${GAMEDIR_PERMS}
 REQD_FILES_PERMS+=      /dev/null ${VARBASE}/games/moon-buggy/mbscore ${GAMEDATA_PERMS}
 SPECIAL_PERMS+=         ${PREFIX}/bin/moon-buggy ${SETGID_GAMES_PERMS}
 </pre>
 <p>Various <code class="varname">INSTALL_*</code> variables are also available:
     <code class="varname">INSTALL_GAME</code> to install setgid game binaries,
     <code class="varname">INSTALL_GAME_DIR</code> to install game directories that are
     needed to be accessed by setgid games and
     <code class="varname">INSTALL_GAME_DATA</code> to install scorefiles.</p>
 <p>A package should therefore never hard code file ownership or
     access permissions but rely on <code class="varname">*_PERMS</code> as described above
     or alternatively on <code class="varname">INSTALL_GAME</code>,
     <code class="varname">INSTALL_GAME_DATA</code> and
     <code class="varname">INSTALL_GAME_DIR</code> to set these correctly.</p>
 </div>
 <div class="sect2">
 <div class="titlepage"><div><div><h3 class="title">
 <a name="destdir-support"></a>21.6.4.�Adding DESTDIR support to packages</h3></div></div></div>
 <p><code class="varname">DESTDIR</code> support means that a package
     installs into a staging directory, not the final location of the
     files. Then a binary package is created which can be used for
     installation as usual. There are two ways: Either the package must
     install as root (<span class="quote">&#8220;<span class="quote">destdir</span>&#8221;</span>) or the package can
     install as non-root user (<span class="quote">&#8220;<span class="quote">user-destdir</span>&#8221;</span>).</p>
 <div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; ">
 <li class="listitem"><p><code class="varname">PKG_DESTDIR_SUPPORT</code> has to be
       set to <span class="quote">&#8220;<span class="quote">destdir</span>&#8221;</span> or <span class="quote">&#8220;<span class="quote">user-destdir</span>&#8221;</span>.
       By default <code class="varname">PKG_DESTDIR_SUPPORT</code>
       is set to <span class="quote">&#8220;<span class="quote">user-destdir</span>&#8221;</span> to help catching more
       potential packaging problems. If bsd.prefs.mk is included in the Makefile,
       <code class="varname">PKG_DESTDIR_SUPPORT</code> needs to be set before
       the inclusion.</p></li>
 <li class="listitem"><p>All installation operations have to be prefixed with
       <code class="filename">${DESTDIR}</code>.</p></li>
 <li class="listitem"><p>automake gets this DESTDIR mostly right
       automatically. Many manual rules and pre/post-install often are
       incorrect; fix them.</p></li>
 <li class="listitem"><p>If files are installed with special owner/group
       use <code class="varname">SPECIAL_PERMS</code>.</p></li>
 <li class="listitem"><p>In general, packages should support
       <code class="varname">UNPRIVILEGED</code> to be able to use
       DESTDIR.</p></li>
 </ul></div>
 </div>
 <div class="sect2">
 <div class="titlepage"><div><div><h3 class="title">
 <a name="hardcoded-paths"></a>21.6.5.�Packages with hardcoded paths to other interpreters</h3></div></div></div>
 <p>Your package may also contain scripts with hardcoded paths to
       other interpreters besides (or as well as) Perl.  To correct the
       full pathname to the script interpreter, you need to set the
       following definitions in your <code class="filename">Makefile</code> (we
     shall use <span class="command"><strong>tclsh</strong></span> in this example):</p>
 <pre class="programlisting">
 REPLACE_INTERPRETER+=   tcl
 REPLACE.tcl.old=        .*/bin/tclsh
 REPLACE.tcl.new=        ${PREFIX}/bin/tclsh
 REPLACE_FILES.tcl=      # list of tcl scripts which need to be fixed,
 # relative to ${WRKSRC}, just as in REPLACE_PERL
 </pre>
 </div>
 <div class="sect2">
 <div class="titlepage"><div><div><h3 class="title">
 <a name="perl-modules"></a>21.6.6.�Packages installing Perl modules</h3></div></div></div>
 <p>Makefiles of packages providing perl5 modules should include
     the Makefile fragment
     <code class="filename">../../lang/perl5/module.mk</code>.  It provides a
     <span class="command"><strong>do-configure</strong></span> target for the standard perl
     configuration for such modules as well as various hooks to tune
     this configuration.  See comments in this file for
     details.</p>
 <p>Perl5 modules will install into different places depending
     on the version of perl used during the build process.  To
     address this, pkgsrc will append lines to the
     <code class="filename">PLIST</code> corresponding to the files listed in
     the installed <code class="filename">.packlist</code> file generated by
     most perl5 modules.  This is invoked by defining
     <code class="varname">PERL5_PACKLIST</code> to a space-separated list of
     packlist files relative to <code class="varname">PERL5_PACKLIST_DIR</code>
     (<code class="varname">PERL5_INSTALLVENDORARCH</code> by default),
     e.g.:</p>
 <pre class="programlisting">
 PERL5_PACKLIST= auto/Pg/.packlist
 </pre>
 <p>The perl5 config variables
     <code class="varname">installarchlib</code>,
     <code class="varname">installscript</code>,
     <code class="varname">installvendorbin</code>,
     <code class="varname">installvendorscript</code>,
     <code class="varname">installvendorarch</code>,
     <code class="varname">installvendorlib</code>,
     <code class="varname">installvendorman1dir</code>, and
     <code class="varname">installvendorman3dir</code> represent those
     locations in which components of perl5 modules may be installed,
     provided as variable with uppercase and prefixed with
     <code class="varname">PERL5_</code>, e.g. <code class="varname">PERL5_INSTALLARCHLIB</code>
     and may be used by perl5 packages that don't have a packlist.
     These variables are also substituted for in the
     <code class="filename">PLIST</code> as uppercase prefixed with
     <code class="varname">PERL5_SUB_</code>.</p>
 </div>
 <div class="sect2">
 <div class="titlepage"><div><div><h3 class="title">
 <a name="faq.info-files"></a>21.6.7.�Packages installing info files</h3></div></div></div>
 <p>Some packages install info files or use the
     <span class="quote">&#8220;<span class="quote">makeinfo</span>&#8221;</span>  or <span class="quote">&#8220;<span class="quote">install-info</span>&#8221;</span>
     commands.  <code class="varname">INFO_FILES</code> should be defined in
     the package Makefile so that <code class="filename">INSTALL</code> and
     <code class="filename">DEINSTALL</code> scripts will be generated to
     handle registration of the info files in the Info directory
     file. The <span class="quote">&#8220;<span class="quote">install-info</span>&#8221;</span> command used for the info
     files registration is either provided by the system, or by a
     special purpose package automatically added as dependency if
     needed.</p>
 <p><code class="varname">PKGINFODIR</code> is the directory under
     <code class="filename">${PREFIX}</code> where info files are primarily
     located. <code class="varname">PKGINFODIR</code> defaults to
     <span class="quote">&#8220;<span class="quote">info</span>&#8221;</span> and can be overridden by the user.</p>
 <p>The info files for the package should be listed in the
     package <code class="filename">PLIST</code>; however any split info files
     need not be listed.</p>
 <p>A package which needs the <span class="quote">&#8220;<span class="quote">makeinfo</span>&#8221;</span> command
     at build time must add <span class="quote">&#8220;<span class="quote">makeinfo</span>&#8221;</span> to
     <code class="varname">USE_TOOLS</code> in its Makefile. If a minimum
     version of the <span class="quote">&#8220;<span class="quote">makeinfo</span>&#8221;</span> command is needed it
     should be noted with the <code class="varname">TEXINFO_REQD</code>
     variable in the package <code class="filename">Makefile</code>. By
     default, a minimum version of 3.12 is required. If the system
     does not provide a <span class="command"><strong>makeinfo</strong></span> command or if it
     does not match the required minimum, a build dependency on the
     <a href="https://cdn.NetBSD.org/pub/pkgsrc/current/pkgsrc/devel/gtexinfo/index.html" target="_top"><code class="filename">devel/gtexinfo</code></a> package will
     be added automatically.</p>
 <p>The build and installation process of the software provided
     by the package should not use the
     <span class="command"><strong>install-info</strong></span> command as the registration of
     info files is the task of the package
     <code class="filename">INSTALL</code> script, and it must use the
     appropriate <span class="command"><strong>makeinfo</strong></span> command.</p>
 <p>To achieve this goal, the pkgsrc infrastructure creates
     overriding scripts for the <span class="command"><strong>install-info</strong></span> and
     <span class="command"><strong>makeinfo</strong></span> commands in a directory listed early
     in <code class="varname">PATH</code>.</p>
 <p>The script overriding <span class="command"><strong>install-info</strong></span> has
     no effect except the logging of a message. The script overriding
     <span class="command"><strong>makeinfo</strong></span> logs a message and according to the
     value of <code class="varname">TEXINFO_REQD</code> either runs the appropriate
     <span class="command"><strong>makeinfo</strong></span> command or exit on error.</p>
 </div>
 <div class="sect2">
 <div class="titlepage"><div><div><h3 class="title">
 <a name="manpages"></a>21.6.8.�Packages installing man pages</h3></div></div></div>
 <p>All packages that install manual pages should install them
     into the same directory, so that there is one common place to look
     for them. In pkgsrc, this place is
     <code class="literal">${PREFIX}/${PKGMANDIR}</code>, and this expression
     should be used in packages. The default for
     <code class="varname">PKGMANDIR</code> is
     <span class="quote">&#8220;<span class="quote"><code class="filename">man</code></span>&#8221;</span>. Another often-used value
     is <span class="quote">&#8220;<span class="quote"><code class="filename">share/man</code></span>&#8221;</span>.</p>
 <div class="note" style="margin-left: 0.5in; margin-right: 0.5in;">
 <h3 class="title">Note</h3>
 <p>The support for a custom <code class="varname">PKGMANDIR</code>
     is far from complete.</p>
 </div>
 <p>The <code class="filename">PLIST</code> files can just use
     <code class="filename">man/</code> as the top level directory for the man
     page file entries, and the pkgsrc framework will convert as
     needed. In all other places, the correct
     <code class="varname">PKGMANDIR</code> must be used.</p>
 <p>Packages that are
     configured with <code class="varname">GNU_CONFIGURE</code> set as
     <span class="quote">&#8220;<span class="quote">yes</span>&#8221;</span>, by default will use the
     <code class="filename">./configure</code>
     --mandir switch to set where the man pages should be installed.
     The path is <code class="varname">GNU_CONFIGURE_MANDIR</code> which defaults
     to <code class="varname">${PREFIX}/${PKGMANDIR}</code>.</p>
 <p>Packages that use <code class="varname">GNU_CONFIGURE</code> but do not
     use --mandir, can set <code class="varname">CONFIGURE_HAS_MANDIR</code>
     to <span class="quote">&#8220;<span class="quote">no</span>&#8221;</span>.
     Or if the <code class="filename">./configure</code> script uses
     a non-standard use of --mandir, you can set
     <code class="varname">GNU_CONFIGURE_MANDIR</code> as needed.</p>
 <p>See <a class="xref" href="#manpage-compression" title="19.5.�Man page compression">Section�19.5, &#8220;Man page compression&#8221;</a> for
     information on installation of compressed manual pages.</p>
 </div>
 <div class="sect2">
 <div class="titlepage"><div><div><h3 class="title">
 <a name="x11-fonts"></a>21.6.9.�Packages installing X11 fonts</h3></div></div></div>
 <p>If a package installs font files, you will need to rebuild
     the fonts database in the directory where they get installed at
     installation and deinstallation time.  This can be automatically
     done by using the pkginstall framework.</p>
 <p>You can list the directories where fonts are installed in the
     <code class="varname">FONTS_DIRS.<em class="replaceable"><code>type</code></em></code>
     variables, where <em class="replaceable"><code>type</code></em> can be one of
     <span class="quote">&#8220;<span class="quote">ttf</span>&#8221;</span>, <span class="quote">&#8220;<span class="quote">type1</span>&#8221;</span> or <span class="quote">&#8220;<span class="quote">x11</span>&#8221;</span>.
     Also make sure that the database file
     <code class="filename">fonts.dir</code> is not listed in the PLIST.</p>
 <p>Note that you should not create new directories for fonts;
     instead use the standard ones to avoid that the user needs to
     manually configure his X server to find them.</p>
 </div>
 <div class="sect2">
 <div class="titlepage"><div><div><h3 class="title">
 <a name="sgml-xml-data"></a>21.6.10.�Packages installing SGML or XML data</h3></div></div></div>
 <p>If a package installs SGML or XML data files that need to be
     registered in system-wide catalogs (like DTDs, sub-catalogs,
     etc.), you need to take some extra steps:</p>
 <div class="orderedlist"><ol class="orderedlist" type="1">
 <li class="listitem"><p>Include
 	<code class="filename">../../textproc/xmlcatmgr/catalogs.mk</code> in
 	your <code class="filename">Makefile</code>, which takes care of
 	registering those files in system-wide catalogs at
 	installation and deinstallation time.</p></li>
 <li class="listitem"><p>Set <code class="varname">SGML_CATALOGS</code> to the full path of
 	any SGML catalogs installed by the package.</p></li>
 <li class="listitem"><p>Set <code class="varname">XML_CATALOGS</code> to the full path of
 	any XML catalogs installed by the package.</p></li>
 <li class="listitem"><p>Set <code class="varname">SGML_ENTRIES</code> to individual entries
 	to be added to the SGML catalog.  These come in groups of
 	three strings; see xmlcatmgr(1) for more information
 	(specifically, arguments recognized by the 'add' action).
 	Note that you will normally not use this variable.</p></li>
 <li class="listitem"><p>Set <code class="varname">XML_ENTRIES</code> to individual entries
 	to be added to the XML catalog.  These come in groups of three
 	strings; see xmlcatmgr(1) for more information (specifically,
 	arguments recognized by the 'add' action).  Note that you will
 	normally not use this variable.</p></li>
 </ol></div>
 </div>
 <div class="sect2">
 <div class="titlepage"><div><div><h3 class="title">
 <a name="mime-database"></a>21.6.11.�Packages installing extensions to the MIME database</h3></div></div></div>
 <p>If a package provides extensions to the MIME database by
     installing <code class="filename">.xml</code> files inside
     <code class="filename">${PREFIX}/share/mime/packages</code>, you
     need to take some extra steps to ensure that the database is kept
     consistent with respect to these new files:</p>
 <div class="orderedlist"><ol class="orderedlist" type="1">
 <li class="listitem"><p>Include
 	<code class="filename">../../databases/shared-mime-info/mimedb.mk</code>
 	(avoid using the <code class="filename">buildlink3.mk</code> file from
 	this same directory, which is reserved for inclusion from
 	other <code class="filename">buildlink3.mk</code> files).  It takes
 	care of rebuilding the MIME database at installation and
 	deinstallation time, and disallows any access to it directly
 	from the package.</p></li>
 <li class="listitem"><p>Check the PLIST and remove any entries under the
 	<code class="filename">share/mime</code> directory,
 	<span class="emphasis"><em>except</em></span> for files saved under
 	<code class="filename">share/mime/packages</code>.  The former are
 	handled 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.</p></li>
 <li class="listitem"><p>Remove any <code class="filename">share/mime/*</code> directories
 	from the PLIST.  They will be handled by the shared-mime-info
 	package.</p></li>
 </ol></div>
 </div>
 <div class="sect2">
 <div class="titlepage"><div><div><h3 class="title">
 <a name="intltool"></a>21.6.12.�Packages using intltool</h3></div></div></div>
 <p>If a package uses intltool during its build, add
     <code class="literal">intltool</code> to the <code class="varname">USE_TOOLS</code>,
     which forces it to use the intltool package provided by pkgsrc,
     instead of the one bundled with the distribution file.</p>
 <p>This tracks intltool's build-time dependencies and uses the
     latest available version; this way, the package benefits of any
     bug fixes that may have appeared since it was released.</p>
 </div>
 <div class="sect2">
 <div class="titlepage"><div><div><h3 class="title">
 <a name="startup-scripts"></a>21.6.13.�Packages installing startup scripts</h3></div></div></div>
 <p>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 <code class="varname">PKG_RCD_SCRIPTS=YES</code> in
     <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">
 <div class="titlepage"><div><div><h3 class="title">
 <a name="tex-packages"></a>21.6.14.�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 kpathsea,
     packages should install files
     into <code class="filename">${PREFIX}/share/texmf-dist</code>,
     not <code class="filename">${PREFIX}/share/texmf</code>.</p>
 </div>
 <div class="orderedlist"><ol class="orderedlist" type="1">
 <li class="listitem"><p>Include
       <code class="filename">../../print/kpathsea/texmf.mk</code>.  This
       takes care of rebuilding the <code class="filename">ls-R</code>
       database at installation and deinstallation time.</p></li>
 <li class="listitem">
 <p>If your package installs files into a texmf
       tree other than the one
       at <code class="filename">${PREFIX}/share/texmf-dist</code>,
       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>,
       include <code class="filename">../../print/tex-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 class="listitem"><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 kpathsea package.</p></li>
 </ol></div>
 </div>
 <div class="sect2">
 <div class="titlepage"><div><div><h3 class="title">
 <a name="emulation-packages"></a>21.6.15.�Packages supporting running binaries in
     emulation</h3></div></div></div>
 <p>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.</p>
 <p>The <a href="https://cdn.NetBSD.org/pub/pkgsrc/current/pkgsrc/pkgtools/rpm2pkg/index.html" target="_top"><code class="filename">pkgtools/rpm2pkg</code></a>
     helps in extracting and packaging Linux rpm packages.</p>
 <p>The <code class="varname">CHECK_SHLIBS</code> can be set to no to
     avoid the <span class="command"><strong>check-shlibs</strong></span> target, which tests
     if all libraries for each installed executable can be found by
     the dynamic linker.  Since the standard dynamic linker is run,
     this fails for emulation packages, because the libraries used
     by the emulation are not in the standard directories.</p>
 </div>
 <div class="sect2">
 <div class="titlepage"><div><div><h3 class="title">
 <a name="hicolor-theme"></a>21.6.16.�Packages installing hicolor icons</h3></div></div></div>
 <p>If a package installs images under the
     <code class="filename">share/icons/hicolor</code> and/or updates the
     <code class="filename">share/icons/hicolor/icon-theme.cache</code>
     database, you need to take some extra steps to make sure that the
     shared theme directory is handled appropriately and that the cache
     database is rebuilt:</p>
 <div class="orderedlist"><ol class="orderedlist" type="1">
 <li class="listitem"><p>Include
 	<code class="filename">../../graphics/hicolor-icon-theme/buildlink3.mk</code>.</p></li>
 <li class="listitem"><p>Check the <code class="filename">PLIST</code> and remove the
 	entry that refers to the theme cache.</p></li>
 <li class="listitem"><p>Ensure that the PLIST does not remove the shared icon
 	  directories from the <code class="filename">share/icons/hicolor</code>
 	  hierarchy because they will be handled automatically.</p></li>
 </ol></div>
 <p>The best way to verify that the PLIST is correct with
       respect to the last two points is to regenerate it using
       <span class="command"><strong>make print-PLIST</strong></span>.</p>
 </div>
 <div class="sect2">
 <div class="titlepage"><div><div><h3 class="title">
 <a name="desktop-files"></a>21.6.17.�Packages installing desktop files</h3></div></div></div>
 <p>If a package installs <code class="filename">.desktop</code> files
       under <code class="filename">share/applications</code> and these include
       MIME information (MimeType key), you need to take extra steps to
       ensure that they are registered into the MIME database:</p>
 <div class="orderedlist"><ol class="orderedlist" type="1">
 <li class="listitem"><p>Include
 	  <code class="filename">../../sysutils/desktop-file-utils/desktopdb.mk</code>.</p></li>
 <li class="listitem"><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">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
 <a name="punting"></a>21.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. In this case, one can plainly mark a package as broken.  For
   this, one just sets the variable <code class="varname">BROKEN</code> to the
   reason why the package is broken (similar to the
   <code class="varname">PKG_FAIL_REASON</code> variable).  A user trying to build
   the package will immediately be shown this message, and the build
   will not be even tried.</p>
 <p><code class="varname">BROKEN</code> packages are removed from pkgsrc in irregular
   intervals.</p>
 </div>
 </div>
 <div class="chapter">
 <div class="titlepage"><div><div><h2 class="title">
 <a name="gnome"></a>Chapter�22.�GNOME packaging and porting</h2></div></div></div>
 <div class="toc">
 <p><b>Table of Contents</b></p>
 <dl class="toc">
 <dt><span class="sect1"><a href="#meta-packages">22.1. Meta packages</a></span></dt>
 <dt><span class="sect1"><a href="#new-package">22.2. Packaging a GNOME application</a></span></dt>
 <dt><span class="sect1"><a href="#full-update">22.3. Updating GNOME to a newer version</a></span></dt>
 <dt><span class="sect1"><a href="#patching">22.4. Patching guidelines</a></span></dt>
 </dl>
 </div>
 <p>Quoting <a class="ulink" href="https://www.gnome.org/" target="_top">GNOME's web
 site</a>:</p>
 <div class="blockquote"><blockquote class="blockquote"><p>The GNOME project provides two things: The GNOME desktop
   environment, an intuitive and attractive desktop for users, and the
   GNOME development platform, an extensive framework for building
   applications that integrate into the rest of the desktop.</p></blockquote></div>
 <p>pkgsrc provides a seamless way to automatically build and install
 a complete GNOME environment <span class="emphasis"><em>under many different
 platforms</em></span>.  We can say with confidence that pkgsrc is one of
 the most advanced build and packaging systems for GNOME due to its
 included technologies buildlink3, the wrappers and tools framework and
 automatic configuration file management.  Lots of efforts are put into
 achieving a completely clean deinstallation of installed software
 components.</p>
 <p>Given that pkgsrc is <a class="ulink" href="https://www.NetBSD.org/" target="_top">NetBSD</a>'s official packaging system,
 the above also means that great efforts are put into making GNOME work
 under this operating system.</p>
 <p>This chapter is aimed at pkgsrc developers and other people
 interested in helping our GNOME porting and packaging efforts.  It
 provides instructions on how to manage the existing packages and some
 important information regarding their internals.</p>
 <div class="sect1">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
 <a name="meta-packages"></a>22.1.�Meta packages</h2></div></div></div>
 <p>pkgsrc includes three GNOME-related meta packages:</p>
 <div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; ">
 <li class="listitem"><p><a href="https://cdn.NetBSD.org/pub/pkgsrc/current/pkgsrc/meta-pkgs/gnome-base/index.html" target="_top"><code class="filename">meta-pkgs/gnome-base</code></a>: Provides
     the core GNOME desktop environment.  It only includes the necessary
     bits to get it to boot correctly, although it may lack important
     functionality for daily operation.  The idea behind this package is
     to let end users build their own configurations on top of this one,
     first installing this meta package to achieve a functional setup and
     then adding individual applications.</p></li>
 <li class="listitem"><p><a href="https://cdn.NetBSD.org/pub/pkgsrc/current/pkgsrc/meta-pkgs/gnome/index.html" target="_top"><code class="filename">meta-pkgs/gnome</code></a>: Provides a
     complete installation of the GNOME platform and desktop as defined
     by the GNOME project; this is based on the components distributed in
     the <code class="filename">platform/x.y/x.y.z/sources</code> and
     <code class="filename">desktop/x.y/x.y.z/sources</code> directories of the
     official FTP server.  Developer-only tools found in those
     directories are not installed unless required by some other
     component to work properly.  Similarly, packages from the bindings
     set (<code class="filename">bindings/x.y/x.y.z/sources</code>) are not pulled
     in unless required as a dependency for an end-user component.  This
     package "extends" <a href="https://cdn.NetBSD.org/pub/pkgsrc/current/pkgsrc/meta-pkgs/gnome-base/index.html" target="_top"><code class="filename">meta-pkgs/gnome-base</code></a>.</p></li>
 <li class="listitem"><p><a href="https://cdn.NetBSD.org/pub/pkgsrc/current/pkgsrc/meta-pkgs/gnome-devel/index.html" target="_top"><code class="filename">meta-pkgs/gnome-devel</code></a>:
     Installs all the tools required to build a GNOME component when
     fetched from the CVS repository.  These are required to let the
     <span class="command"><strong>autogen.sh</strong></span> scripts work appropriately.</p></li>
 </ul></div>
 <p>In all these packages, the <code class="varname">DEPENDS</code> lines are
 sorted in a way that eases updates: a package may depend on other
 packages listed before it but not on any listed after it.  It is very
 important to keep this order to ease updates so... <span class="emphasis"><em>do not
 change it to alphabetical sorting!</em></span></p>
 </div>
 <div class="sect1">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
 <a name="new-package"></a>22.2.�Packaging a GNOME application</h2></div></div></div>
 <p>Almost all GNOME applications are written in C and use a common
 set of tools as their build system.  Things get different with the new
 bindings to other languages (such as Python), but the following will
 give you a general idea on the minimum required tools:</p>
 <div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; ">
 <li class="listitem">
 <p>Almost all GNOME applications use the GNU Autotools as their
     build system.  As a general rule you will need to tell this to your
     package:</p>
 <pre class="programlisting">
 GNU_CONFIGURE=  yes
 USE_LIBTOOL=    yes
 USE_TOOLS+=     gmake
 </pre>
 </li>
 <li class="listitem">
 <p>If the package uses pkg-config to detect dependencies, add this
     tool to the list of required utilities:</p>
 <pre class="programlisting">
 USE_TOOLS+=     pkg-config
 </pre>
 <p>Also use <a href="https://cdn.NetBSD.org/pub/pkgsrc/current/pkgsrc/pkgtools/verifypc/index.html" target="_top"><code class="filename">pkgtools/verifypc</code></a> at
     the end of the build process to ensure that you did not miss to
     specify any dependency in your package and that the version
     requirements are all correct.</p>
 </li>
 <li class="listitem"><p>If the package uses intltool, be sure to add
     <code class="literal">intltool</code> to the <code class="varname">USE_TOOLS</code>
     to handle dependencies and to force the package to use the latest
     available version.</p></li>
 <li class="listitem">
 <p>If the package uses gtk-doc (a documentation generation
     utility), do <span class="emphasis"><em>not</em></span> add a dependency on it.  The
     tool is rather big and the distfile should come with pregenerated
     documentation anyway; if it does not, it is a bug that you ought to
     report.  For such packages you should disable gtk-doc (unless it is
     the default):</p>
 <pre class="programlisting">
 CONFIGURE_ARGS+=        --disable-gtk-doc
 </pre>
 <p>The default location of installed HTML files
     (<code class="filename">share/gtk-doc/&lt;package-name&gt;</code>) is correct
     and should not be changed unless the package insists on installing
     them somewhere else.  Otherwise programs as
     <span class="command"><strong>devhelp</strong></span> will not be able to open them.  You can
     do that with an entry similar to:</p>
 <pre class="programlisting">
 CONFIGURE_ARGS+=        --with-html-dir=${PREFIX}/share/gtk-doc/...
 </pre>
 </li>
 </ul></div>
 <p>GNOME uses multiple <span class="emphasis"><em>shared</em></span> directories and
 files under the installation prefix to maintain databases.  In this
 context, shared means that those exact same directories and files are
 used among several different packages, leading to conflicts in the
 <code class="filename">PLIST</code>.  pkgsrc currently includes functionality to
 handle the most common cases, so you have to forget about using
 <code class="literal">@unexec ${RMDIR}</code> lines in your file lists and
 omitting shared files from them.  If you find yourself doing those,
 <span class="emphasis"><em>your package is most likely incorrect</em></span>.</p>
 <p>The following table lists the common situations that result in
 using shared directories or files.  For each of them, the appropriate
 solution is given.  After applying the solution be sure to
 <span class="emphasis"><em>regenerate the package's file list</em></span> with
 <span class="command"><strong>make print-PLIST</strong></span> and ensure it is correct.</p>
 <div class="table">
 <a name="plist-handling"></a><p class="title"><b>Table�22.1.�PLIST handling for GNOME packages</b></p>
 <div class="table-contents"><table class="table" summary="PLIST handling for GNOME packages" border="1">
 <colgroup>
 <col>
 <col>
 </colgroup>
 <thead><tr>
 <th>If the package...</th>
 <th>Then...</th>
 @@ -10796,4088 +10800,3956 @@ output_require "^[[:alpha:]+[[:space:]][
 DISTNAME=       bison-1.25
 CATEGORIES=     devel
 MASTER_SITES=   ${MASTER_SITE_GNU:=bison/}
 MAINTAINER=     pkgsrc-users@NetBSD.org
 HOMEPAGE=       https://www.gnu.org/software/bison/bison.html
 COMMENT=        GNU yacc clone
 GNU_CONFIGURE=  yes
 INFO_FILES=     yes
 .include "../../mk/bsd.pkg.mk"
 </pre>
 </div>
 <div class="sect2">
 <div class="titlepage"><div><div><h3 class="title">
 <a name="example-descr"></a>A.1.2.�DESCR</h3></div></div></div>
 <pre class="programlisting">
 GNU version of yacc.  Can make re-entrant parsers, and numerous other
 improvements.  Why you would want this when Berkeley <a class="citerefentry" href="https://man.NetBSD.org/NetBSD-9.2/i386/yacc.1"><span class="citerefentry"><span class="refentrytitle">yacc</span>(1)</span></a> is part
 of the NetBSD source tree is beyond me.
 </pre>
 </div>
 <div class="sect2">
 <div class="titlepage"><div><div><h3 class="title">
 <a name="example-plist"></a>A.1.3.�PLIST</h3></div></div></div>
 <pre class="programlisting">
 @comment $NetBSD$
 bin/bison
 man/man1/bison.1.gz
 share/bison.simple
 share/bison.hairy
 </pre>
 </div>
 <div class="sect2">
 <div class="titlepage"><div><div><h3 class="title">
 <a name="checking-package-with-pkglint"></a>A.1.4.�Checking a package with pkglint</h3></div></div></div>
 <p>The NetBSD package system comes with
         <a href="https://cdn.NetBSD.org/pub/pkgsrc/current/pkgsrc/pkgtools/pkglint/index.html" target="_top"><code class="filename">pkgtools/pkglint</code></a>
 	which helps to check the contents of these
 	files. After installation it is quite easy to use, just change to the
 	directory of the package you wish to examine and run
 	<span class="command"><strong>pkglint</strong></span>:</p>
 <pre class="screen"><code class="prompt">$</code> <strong class="userinput"><code>pkglint</code></strong>
 ERROR: Makefile: Each package must define its LICENSE.
 WARN: Makefile:9: HOMEPAGE should migrate from http to https.
 NOTE: PLIST:3: The .gz extension is unnecessary for manual pages.
 WARN: PLIST:5: "share/bison.hairy" should be sorted before "share/bison.simple".
 error, 2 warnings and 1 note found.
 (Run "pkglint -e" to show explanations.)
 (Run "pkglint -fs" to show what can be fixed automatically.)
 (Run "pkglint -F" to automatically fix some issues.)</pre>
 <p>Depending on the supplied command line arguments (see pkglint(1)),
 	more checks will be performed. Use e.g. <span class="command"><strong>pkglint
 	-Wall</strong></span> for a very thorough check.</p>
 </div>
 </div>
 <div class="sect1">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
 <a name="steps-for-b-i-p"></a>A.2.�Steps for building, installing, packaging</h2></div></div></div>
 <p>Create the directory where the package lives,
       plus any auxiliary directories:</p>
 <pre class="screen"><code class="prompt">#</code> <strong class="userinput"><code>cd /usr/pkgsrc/lang</code></strong>
 <code class="prompt">#</code> <strong class="userinput"><code>mkdir bison</code></strong>
 <code class="prompt">#</code> <strong class="userinput"><code>cd bison</code></strong>
 <code class="prompt">#</code> <strong class="userinput"><code>mkdir patches</code></strong></pre>
 <p>Create <code class="filename">Makefile</code>, <code class="filename">DESCR</code> and
       <code class="filename">PLIST</code> (see <a class="xref" href="#components" title="Chapter�12.�Package components - files, directories and contents">Chapter�12, <i>Package components - files, directories and contents</i></a>)
       then continue with fetching the distfile:</p>
 <pre class="screen"><code class="prompt">#</code> <strong class="userinput"><code>make fetch</code></strong>
 &gt;&gt; bison-1.25.tar.gz doesn't seem to exist on this system.
 &gt;&gt; Attempting to fetch from ftp://prep.ai.mit.edu/pub/gnu//.
 Requesting ftp://prep.ai.mit.edu/pub/gnu//bison-1.25.tar.gz (via ftp://orpheus.amdahl.com:80/)
 ftp: Error retrieving file: 500 Internal error
 &gt;&gt; Attempting to fetch from ftp://wuarchive.wustl.edu/systems/gnu//.
 Requesting ftp://wuarchive.wustl.edu/systems/gnu//bison-1.25.tar.gz (via ftp://orpheus.amdahl.com:80/)
 ftp: Error retrieving file: 500 Internal error
 &gt;&gt; Attempting to fetch from ftp://ftp.freebsd.org/pub/FreeBSD/distfiles//.
 Requesting ftp://ftp.freebsd.org/pub/FreeBSD/distfiles//bison-1.25.tar.gz (via ftp://orpheus.amdahl.com:80/)
 Successfully retrieved file.</pre>
 <p>Generate the checksum of the distfile into
       <code class="filename">distinfo</code>:</p>
 <pre class="screen"><code class="prompt">#</code> <strong class="userinput"><code>make makedistinfo</code></strong></pre>
 <p>Now compile:</p>
 <pre class="screen"><code class="prompt">#</code> <strong class="userinput"><code>make</code></strong>
 &gt;&gt; Checksum OK for bison-1.25.tar.gz.
 ===&gt;  Extracting for bison-1.25
 ===&gt;  Patching for bison-1.25
 ===&gt;   Ignoring empty patch directory
 ===&gt;  Configuring for bison-1.25
 creating cache ./config.cache
 checking for gcc... cc
 checking whether we are using GNU C... yes
 checking for a BSD compatible install... /usr/bin/install -c -o bin -g bin
 checking how to run the C preprocessor... cc -E
 checking for minix/config.h... no
 checking for POSIXized ISC... no
 checking whether cross-compiling... no
 checking for ANSI C header files... yes
 checking for string.h... yes
 checking for stdlib.h... yes
 checking for memory.h... yes
 checking for working const... yes
 checking for working alloca.h... no
 checking for alloca... yes
 checking for strerror... yes
 updating cache ./config.cache
 creating ./config.status
 creating Makefile
 ===&gt;  Building for bison-1.25
 cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include  -g LR0.c
 cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include  -g allocate.c
 cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include  -g closure.c
 cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include  -g conflicts.c
 cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include  -g derives.c
 cc -c -DXPFILE=\"/usr/pkg/share/bison.simple\"  -DXPFILE1=\"/usr/pkg/share/bison.hairy\" -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1  -g  ./files.c
 cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include  -g getargs.c
 cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include  -g gram.c
 cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include  -g lalr.c
 cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include  -g lex.c
 cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include  -g main.c
 cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include  -g nullable.c
 cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include  -g output.c
 cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include  -g print.c
 cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include  -g reader.c
 cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include  -g reduce.c
 cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include  -g symtab.c
 cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include  -g warshall.c
 cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include  -g version.c
 cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include  -g getopt.c
 cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include  -g getopt1.c
 cc  -g -o bison LR0.o allocate.o closure.o conflicts.o derives.o files.o         getargs.o gram.o lalr.o lex.o                                   main.o nullable.o output.o print.o reader.o reduce.o symtab.o   warshall.o version.o getopt.o getopt1.o
 ./files.c:240: warning: mktemp() possibly used unsafely, consider using mkstemp()
 rm -f bison.s1
 sed -e "/^#line/ s|bison|/usr/pkg/share/bison|" &lt; ./bison.simple &gt; bison.s1</pre>
 <p>Everything seems OK, so install the files:</p>
 <pre class="screen"><code class="prompt">#</code> <strong class="userinput"><code>make install</code></strong>
 &gt;&gt; Checksum OK for bison-1.25.tar.gz.
 ===&gt;  Installing for bison-1.25
 sh ./mkinstalldirs /usr/pkg/bin /usr/pkg/share  /usr/pkg/info /usr/pkg/man/man1
 rm -f /usr/pkg/bin/bison
 cd /usr/pkg/share; rm -f bison.simple bison.hairy
 rm -f /usr/pkg/man/man1/bison.1 /usr/pkg/info/bison.info*
 install -c  -o bin -g bin -m 555 bison /usr/pkg/bin/bison
 /usr/bin/install -c -o bin -g bin -m 644 bison.s1 /usr/pkg/share/bison.simple
 /usr/bin/install -c -o bin -g bin -m 644 ./bison.hairy /usr/pkg/share/bison.hairy
 cd .; for f in bison.info*;  do /usr/bin/install -c -o bin -g bin -m 644 $f /usr/pkg/info/$f; done
 /usr/bin/install -c -o bin -g bin -m 644 ./bison.1 /usr/pkg/man/man1/bison.1
 ===&gt;  Registering installation for bison-1.25</pre>
 <p>You can now use bison, and also - if you decide so - remove it with
       <span class="command"><strong>pkg_delete bison</strong></span>. Should you decide that you want a
       binary package, do this now:</p>
 <pre class="screen"><code class="prompt">#</code> <strong class="userinput"><code>make package</code></strong>
 &gt;&gt; Checksum OK for bison-1.25.tar.gz.
 ===&gt;  Building package for bison-1.25
 Creating package bison-1.25.tgz
 Registering depends:.
 Creating gzip'd tar ball in '/u/pkgsrc/lang/bison/bison-1.25.tgz'</pre>
 <p>Now that you don't need the source and object files
       any more, clean up:</p>
 <pre class="screen"><code class="prompt">#</code> <strong class="userinput"><code>make clean</code></strong>
 ===&gt;  Cleaning for bison-1.25</pre>
 </div>
 </div>
 <div class="appendix">
 <div class="titlepage"><div><div><h1 class="title">
 <a name="hardening"></a>Appendix�B.�Security hardening</h1></div></div></div>
 <div class="toc">
 <p><b>Table of Contents</b></p>
 <dl class="toc">
 <dt><span class="sect1"><a href="#hardening.mechanisms">B.1. Mechanisms</a></span></dt>
 <dd><dl>
 <dt><span class="sect2"><a href="#hardening.mechanisms.enabled">B.1.1. Enabled by default</a></span></dt>
 <dt><span class="sect2"><a href="#hardening.mechanisms.disabled">B.1.2. Not enabled by default</a></span></dt>
 </dl></dd>
 <dt><span class="sect1"><a href="#hardening.caveats">B.2. Caveats</a></span></dt>
 <dd><dl>
 <dt><span class="sect2"><a href="#hardening.caveats.pie">B.2.1. Problems with PKGSRC_MKPIE</a></span></dt>
 <dt><span class="sect2"><a href="#hardening.caveats.fortify">B.2.2. Problems with PKGSRC_USE_FORTIFY</a></span></dt>
 <dt><span class="sect2"><a href="#hardening.caveats.relro">B.2.3. Problems with PKGSRC_USE_RELRO</a></span></dt>
 <dt><span class="sect2"><a href="#hardening.caveats.ssp">B.2.4. Problems with PKGSRC_USE_SSP</a></span></dt>
 </dl></dd>
 <dt><span class="sect1"><a href="#hardening.audit">B.3. Auditing the system</a></span></dt>
 <dd><dl>
 <dt><span class="sect2"><a href="#hardening.audit.pie">B.3.1. Checking for PIE</a></span></dt>
 <dt><span class="sect2"><a href="#hardening.audit.relropartial">B.3.2. Checking for partial RELRO</a></span></dt>
 <dt><span class="sect2"><a href="#hardening.audit.relrofull">B.3.3. Checking for full RELRO</a></span></dt>
 <dt><span class="sect2"><a href="#hardening.audit.ssp">B.3.4. Checking for SSP</a></span></dt>
 </dl></dd>
 </dl>
 </div>
 <p>
 A number of mechanisms are available in pkgsrc to improve the security of the
 resulting system. This page describes the mechanisms, and gives hints
 about detecting and fixing problems.
 </p>
 <p>
 Mechanisms can be enabled individually in
 <code class="filename">mk.conf</code>, and are
 individually described below.
 </p>
 <p>
 Typically, a feature will cause some programs to fail to build or work
 when first enabled. This can be due to latent problems in the
 program, and can be due to other reasons. After enough testing to
 have confidence that user problems will be quite rare, individual
 mechanisms will be enabled by default.
 </p>
 <p>
 For each mechanism, see the Caveats section below for an explanation
 of what might go wrong at compile time and at run time, and how to
 notice and address these problems.
 </p>
 <div class="sect1">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
 <a name="hardening.mechanisms"></a>B.1.�Mechanisms</h2></div></div></div>
 <div class="sect2">
 <div class="titlepage"><div><div><h3 class="title">
 <a name="hardening.mechanisms.enabled"></a>B.1.1.�Enabled by default</h3></div></div></div>
 <div class="sect3">
 <div class="titlepage"><div><div><h4 class="title">
 <a name="hardening.mechanisms.enabled.fortify"></a>B.1.1.1.�PKGSRC_USE_FORTIFY</h4></div></div></div>
 <p>
 This allows substitute wrappers to be used for some commonly used
 library functions that do not have built-in bounds checking - but
 could in some cases.
 </p>
 <p>
 Two mitigation levels are available:
 </p>
 <div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; ">
 <li class="listitem"><p>"weak" only enables checks at compile-time.</p></li>
 <li class="listitem"><p>"strong" enables checks at compile-time and runtime.</p></li>
 </ul></div>
 <p>
 "strong" has been enabled by default since pkgsrc-2017Q3.
 </p>
 </div>
 <div class="sect3">
 <div class="titlepage"><div><div><h4 class="title">
 <a name="hardening.mechanisms.enabled.ssp"></a>B.1.1.2.�PKGSRC_USE_SSP</h4></div></div></div>
 <p>
 This enables a stack-smashing protection mitigation. It is done by adding a
 guard variable to functions with vulnerable objects. The guards are initialized
 when a function is entered and then checked when the function exits. The guard
 check will fail and the program forcibly exited if the variable was modified in
 the meantime. This can happen in case of buffer overflows or memory corruption,
 and therefore exposing these bugs.
 </p>
 <p>
 Different mitigation levels are available:
 </p>
 <div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; ">
 <li class="listitem"><p>"yes", which will only protect functions considered vulnerable
 by the compiler;</p></li>
 <li class="listitem"><p>"all", which will protect every function;</p></li>
 <li class="listitem"><p>"strong", the default, which will apply a better balance between the
 two settings above.</p></li>
 </ul></div>
 <p>
 This mitigation is supported by both GCC and clang. It may be supported in
 additional compilers, possibly under a different name. It is particularly useful
 for unsafe programming languages, such as C/C++.
 </p>
 <div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; ">
 <li class="listitem"><p>"yes" is enabled by default where known supported since pkgsrc-2017Q3.</p></li>
 <li class="listitem"><p>"strong" is enabled by default where known supported since pkgsrc-2021Q4.</p></li>
 </ul></div>
 <p>More details can be found here:</p>
 <div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; "><li class="listitem"><p>
 <a class="ulink" href="https://en.wikipedia.org/wiki/Buffer_overflow_protection" target="_top">Buffer overflow protection on Wikipedia</a>
 </p></li></ul></div>
 </div>
 <div class="sect3">
 <div class="titlepage"><div><div><h4 class="title">
 <a name="hardening.mechanisms.enabled.pie"></a>B.1.1.3.�PKGSRC_MKPIE</h4></div></div></div>
 <p>
 This requests the creation of PIE (Position Independent Executables) for all
 executables. The PIE mechanism is normally used for shared libraries, so that
 they can be loaded at differing addresses at runtime. PIE itself does not have
 useful security properties; however, it is necessary to fully leverage some,
 such as ASLR.  Some operating systems support Address Space Layout Randomization
 (ASLR), which causes different addresses to be used each time a program is run.
 This makes it more difficult for an attacker to guess addresses and thus makes
 exploits harder to construct. With PIE, ASLR can really be applied to the entire
 program, instead of the stack and heap only.
 </p>
 <p>
 PIE executables will only be built for toolchains that are known to support PIE.
 Currently, this means NetBSD on x86, ARM, SPARC64, m68k, and MIPS.
 </p>
 <p>
 <code class="varname">PKGSRC_MKPIE</code> was enabled by default after the pkgsrc-2021Q3 branch.
 </p>
 </div>
 <div class="sect3">
 <div class="titlepage"><div><div><h4 class="title">
 <a name="hardening.mechanisms.enabled.relro"></a>B.1.1.4.�PKGSRC_USE_RELRO</h4></div></div></div>
 <p>
 This also makes the exploitation of some security vulnerabilities more
 difficult in some cases.
 </p>
 <p>Two different mitigation levels are available:</p>
 <div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; ">
 <li class="listitem"><p>
 partial (the default): the ELF sections are reordered so that internal data sections
 precede the program's own data sections, and non-PLT GOT is read-only;
 </p></li>
 <li class="listitem"><p>
 full: in addition to partial RELRO, every relocation is performed immediately
 when starting the program, allowing the entire GOT to be read-only.  This
 can greatly slow down startup of large programs.
 </p></li>
 </ul></div>
 <p>
 This is currently supported by GCC. Many software distributions now enable this
 feature by default, at the "partial" level.
 </p>
 <p>
 More details can be found here:
 </p>
 <div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; "><li class="listitem"><p>
 <a class="ulink" href="https://www.redhat.com/en/blog/hardening-elf-binaries-using-relocation-read-only-relro" target="_top">Hardening ELF binaries using Relocation Read-Only (RELRO)</a>
 </p></li></ul></div>
 </div>
 </div>
 <div class="sect2">
 <div class="titlepage"><div><div><h3 class="title">
 <a name="hardening.mechanisms.disabled"></a>B.1.2.�Not enabled by default</h3></div></div></div>
 <div class="sect3">
 <div class="titlepage"><div><div><h4 class="title">
 <a name="hardening.mechanisms.disabled.repro"></a>B.1.2.1.�PKGSRC_MKREPRO</h4></div></div></div>
 <p>
 With this option, pkgsrc will try to build packages reproducibly. This allows
 packages built from the same tree and with the same options, to produce
 identical results bit by bit. This option should be combined with ASLR and
 <code class="varname">PKGSRC_MKPIE</code> to avoid predictable address offsets for
 attackers attempting to exploit security vulnerabilities.
 </p>
 <p>
 More details can be found here:
 </p>
 <div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; "><li class="listitem"><p>
 <a class="ulink" href="https://reproducible-builds.org/" target="_top">Reproducible Builds - a set of software development practices that create an independently-verifiable path from source to binary code</a>
 </p></li></ul></div>
 <p>
 More work likely needs to be done before pkgsrc is fully reproducible.
 </p>
 </div>
 <div class="sect3">
 <div class="titlepage"><div><div><h4 class="title">
 <a name="hardening.mechanisms.disabled.stackcheck"></a>B.1.2.2.�PKGSRC_USE_STACK_CHECK</h4></div></div></div>
 <p>
 This uses <code class="literal">-fstack-check</code> with GCC for
 another stack protection mitigation.
 </p>
 <p>
 It asks the compiler to generate code verifying that it does not corrupt the
 stack. According to GCC's manual page, this is really only useful for
 multi-threaded programs.
 </p>
 </div>
 </div>
 </div>
 <div class="sect1">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
 <a name="hardening.caveats"></a>B.2.�Caveats</h2></div></div></div>
 <div class="sect2">
 <div class="titlepage"><div><div><h3 class="title">
 <a name="hardening.caveats.pie"></a>B.2.1.�Problems with PKGSRC_MKPIE</h3></div></div></div>
 <div class="sect3">
 <div class="titlepage"><div><div><h4 class="title">
 <a name="hardening.caveats.pie.build"></a>B.2.1.1.�Packages failing to build</h4></div></div></div>
 <p>
 A number of packages may fail to build with this option enabled. The
 failures are often related to the absence of the <code class="literal">-fPIC</code>
 compilation flag when building libraries or executables (or ideally
 <code class="literal">-fPIE</code> in the latter case). This flag is added to the
 <code class="varname">CFLAGS</code> already, but requires the package to
 actually support it.
 </p>
 <div class="sect4">
 <div class="titlepage"><div><div><h5 class="title">
 <a name="hardening.caveats.pie.build.fix"></a>B.2.1.1.1.�How to fix</h5></div></div></div>
 <p>
 These instructions are meant as a reference only; they likely need to be adapted
 for many packages individually.
 </p>
 <p>
 For packages using <code class="filename">Makefiles</code>:
 </p>
 <pre class="programlisting">
 MAKE_FLAGS+=	CFLAGS=${CFLAGS:Q}
 MAKE_FLAGS+=	LDFLAGS=${LDFLAGS:Q}
 </pre>
 <p>
 For packages using <code class="filename">Imakefiles</code>:
 </p>
 <pre class="programlisting">
 MAKE_FLAGS+=	CCOPTIONS=${CFLAGS:Q}
 MAKE_FLAGS+=	LOCAL_LDFLAGS=${LDFLAGS:Q}
 </pre>
 </div>
 </div>
 <div class="sect3">
 <div class="titlepage"><div><div><h4 class="title">
 <a name="hardening.caveats.pie.crash"></a>B.2.1.2.�Run-time crashes</h4></div></div></div>
 <p>
 Some programs may fail to run, or crash at random times once built as PIE. Two
 scenarios are essentially possible. This is nearly always due to a bug in
 the program being exposed due to ASLR.
 </p>
 </div>
 <div class="sect3">
 <div class="titlepage"><div><div><h4 class="title">
 <a name="hardening.caveats.pie.disable"></a>B.2.1.3.�Disabling PKGSRC_MKPIE on a per-package basis</h4></div></div></div>
 <p>
 Ideally, packages should be fixed for compatibility with MKPIE.
 However, in some cases this is very difficult, due to complex build systems,
 packages using non-standard toolchains, or programming languages with odd
 bootstrapping mechanisms.
 </p>
 <p>
 To disable <code class="varname">PKGSRC_MKPIE</code> on a per-package basis, set
 <code class="varname">MKPIE_SUPPORTED= no</code> in the package's Makefile before
 <code class="filename">bsd.prefs.mk</code> is included.
 </p>
 </div>
 </div>
 <div class="sect2">
 <div class="titlepage"><div><div><h3 class="title">
 <a name="hardening.caveats.fortify"></a>B.2.2.�Problems with PKGSRC_USE_FORTIFY</h3></div></div></div>
 <div class="sect3">
 <div class="titlepage"><div><div><h4 class="title">
 <a name="hardening.caveats.fortify.build"></a>B.2.2.1.�Packages failing to build</h4></div></div></div>
 <p>
 This feature makes use of pre-processing directives to look for hardened,
 alternative implementations of essential library calls. Some programs may fail
 to build as a result; this usually happens for those trying too hard to be
 portable, or otherwise abusing definitions in the standard library.
 </p>
 </div>
 <div class="sect3">
 <div class="titlepage"><div><div><h4 class="title">
 <a name="hardening.caveats.fortify.crash"></a>B.2.2.2.�Run-time crashes</h4></div></div></div>
 <p>
 This feature may cause some programs to crash, usually indicating an
 actual bug in the program. The fix will typically involve patching the
 original program's source code.
 </p>
 </div>
 <div class="sect3">
 <div class="titlepage"><div><div><h4 class="title">
 <a name="hardening.caveats.fortify.opt"></a>B.2.2.3.�Optimization is required</h4></div></div></div>
 <p>
 At least in the case of GCC, FORTIFY will only be applied if optimization is
 applied while compiling. This means that the <code class="varname">CFLAGS</code> should
 also contain <code class="literal">-O</code>, <code class="literal">-O2</code> or another
 optimization level. This cannot easily be applied globally, as some packages
 may require specific optimization levels.
 </p>
 </div>
 <div class="sect3">
 <div class="titlepage"><div><div><h4 class="title">
 <a name="hardening.caveats.fortify.disable"></a>B.2.2.4.�Disabling FORTIFY on a per-package basis</h4></div></div></div>
 <div class="note" style="margin-left: 0.5in; margin-right: 0.5in;">
 <h3 class="title">Note</h3>
 <p>FORTIFY should not be disabled to work around runtime crashes in
 the program!  This is a very bad idea and will expose you to security
 vulnerabilities.
 </p>
 </div>
 <p>
 To disable FORTIFY on a per-package basis, set the following
 in the package's <code class="filename">Makefile</code>
 before <code class="filename">bsd.prefs.mk</code> is included:
 </p>
 <pre class="programlisting">
 FORTIFY_SUPPORTED=	no
 </pre>
 </div>
 </div>
 <div class="sect2">
 <div class="titlepage"><div><div><h3 class="title">
 <a name="hardening.caveats.relro"></a>B.2.3.�Problems with PKGSRC_USE_RELRO</h3></div></div></div>
 <div class="sect3">
 <div class="titlepage"><div><div><h4 class="title">
 <a name="hardening.caveats.relro.performance"></a>B.2.3.1.�Performance impact</h4></div></div></div>
 <p>
 For better protection, full RELRO requires every symbol to be resolved when the
 program starts, rather than simply when required at run-time. This will have
 more impact on programs using a lot of symbols, or linked to libraries exposing
 a lot of symbols. Therefore, daemons or programs otherwise running in
 background are affected only when started. Programs loading plug-ins at
 run-time are affected when loading the plug-ins.
 </p>
 <p>
 The impact is not expected to be noticeable on modern hardware, except in some
 cases for big programs.
 </p>
 </div>
 <div class="sect3">
 <div class="titlepage"><div><div><h4 class="title">
 <a name="hardening.caveats.relro.crash"></a>B.2.3.2.�Run-time crashes</h4></div></div></div>
 <p>
 Some programs handle plug-ins and dependencies in a way that conflicts with
 RELRO: for instance, with an initialization routine listing any other plug-in
 required. With full RELRO, the missing symbols are resolved before the
 initialization routine can run, and the dynamic loader will not be able to find
 them directly and abort as a result. Unfortunately, this is how Xorg loads its
 drivers. Partial RELRO can be applied instead in this case.
 </p>
 </div>
 <div class="sect3">
 <div class="titlepage"><div><div><h4 class="title">
 <a name="hardening.caveats.relro.disable"></a>B.2.3.3.�Disabling RELRO on a per-package basis</h4></div></div></div>
 <p>
 To disable RELRO on a per-package basis, set the following
 in the package's <code class="filename">Makefile</code>
 before <code class="filename">bsd.prefs.mk</code> is included:
 </p>
 <pre class="programlisting">
 RELRO_SUPPORTED=	no
 </pre>
 <p>
 It is also possible to at most enable partial RELRO, by
 setting <code class="varname">RELRO_SUPPORTED</code> to <code class="literal">partial</code>.
 </p>
 </div>
 </div>
 <div class="sect2">
 <div class="titlepage"><div><div><h3 class="title">
 <a name="hardening.caveats.ssp"></a>B.2.4.�Problems with PKGSRC_USE_SSP</h3></div></div></div>
 <div class="sect3">
 <div class="titlepage"><div><div><h4 class="title">
 <a name="hardening.caveats.ssp.build"></a>B.2.4.1.�Packages failing to build</h4></div></div></div>
 <p>
 The stack-smashing protection provided by this option does not work for some
 programs. The most common situation in which this happens is when the program
 allocates variables on the stack, with the size determined at run-time.
 </p>
 </div>
 <div class="sect3">
 <div class="titlepage"><div><div><h4 class="title">
 <a name="hardening.caveats.ssp.crash"></a>B.2.4.2.�Run-time crashes</h4></div></div></div>
 <p>
 Again, this feature may cause some programs to crash via a
 <code class="varname">SIGABRT</code>, usually indicating an actual bug in the program.
 </p>
 <p>
 On NetBSD <code class="varname">LOG_CRIT</code> level syslog
 messages are sent and - by default -
 appended to <code class="filename">/var/log/messages</code>, e.g.:
 </p>
 <pre class="programlisting">
 Jan  6 15:42:51 hostname -: hostname program - - - buffer overflow detected; terminated
 </pre>
 <p>
 (where <code class="literal">hostname</code> is the hostname(1) and
 <code class="literal">program</code> is the basename(1) of the program crashed).
 </p>
 <p>
 Patching the original program is then required.
 </p>
 <p>
 Rebuilding the package via:
 </p>
 <pre class="programlisting">
 <strong class="userinput"><code>% env CFLAGS=-g INSTALL_UNSTRIPPED=yes make replace</code></strong>
 </pre>
 <p>
 and inspecting the backtrace of the coredump via the debugger
 should point out the problematic call by inspecting the frame
 calling the _chk() (SSP) function.
 </p>
 </div>
 <div class="sect3">
 <div class="titlepage"><div><div><h4 class="title">
 <a name="hardening.caveats.ssp.performance"></a>B.2.4.3.�Performance impact</h4></div></div></div>
 <p>
 The compiler emits extra code when using this feature: a check for buffer
 overflows is performed when entering and exiting functions, requiring an extra
 variable on the stack. The level of protection can otherwise be adjusted to
 affect only those functions considered more sensitive by the compiler (with
 -fstack-protector instead of -fstack-protector-all).
 </p>
 <p>
 The impact is not expected to be noticeable on modern hardware. However,
 programs with a hard requirement to run at the fastest possible speed should
 avoid using this feature, or using libraries built with this feature.
 </p>
 </div>
 <div class="sect3">
 <div class="titlepage"><div><div><h4 class="title">
 <a name="hardening.caveats.ssp.disable"></a>B.2.4.4.�Disabling SSP on a per-package basis</h4></div></div></div>
 <div class="note" style="margin-left: 0.5in; margin-right: 0.5in;">
 <h3 class="title">Note</h3>
 <p>SSP should not be disabled to work around runtime crashes in
 the program!  This is a very bad idea and will expose you to security
 vulnerabilities.</p>
 </div>
 <p>
 To disable SSP on a per-package basis, set the following
 in the package's <code class="filename">Makefile</code>
 before <code class="filename">bsd.prefs.mk</code> is included:
 </p>
 <pre class="programlisting">
 SSP_SUPPORTED=	no
 </pre>
 </div>
 </div>
 </div>
 <div class="sect1">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
 <a name="hardening.audit"></a>B.3.�Auditing the system</h2></div></div></div>
 <p>
 The illusion of security is worse than having no security at all. This section
 lists a number of ways to ensure the security features requested are actually
 effective.
 </p>
 <p>
 These instructions were obtained and tested on a system derived from NetBSD 7
 (amd64). YMMV.
 </p>
 <div class="sect2">
 <div class="titlepage"><div><div><h3 class="title">
 <a name="hardening.audit.pie"></a>B.3.1.�Checking for PIE</h3></div></div></div>
 <p>
 The ELF executable type in use changes for binaries built as PIE; without:
 </p>
 <pre class="programlisting">
 <strong class="userinput"><code>$ file /path/to/bin/ary</code></strong>
 /path/to/bin/ary: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for NetBSD 7.0, not stripped
 </pre>
 <p>as opposed to the following binary, built as PIE:</p>
 <pre class="programlisting">
 <strong class="userinput"><code>$ file /path/to/pie/bin/ary</code></strong>
 /path/to/pie/bin/ary: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for NetBSD 7.0, not stripped
 </pre>
 <p>
 The latter result is then what is expected.
 </p>
 </div>
 <div class="sect2">
 <div class="titlepage"><div><div><h3 class="title">
 <a name="hardening.audit.relropartial"></a>B.3.2.�Checking for partial RELRO</h3></div></div></div>
 <p>
 The following command should list a section called RELRO:
 </p>
 <pre class="programlisting">
 <strong class="userinput"><code>$ objdump -p /path/to/bin/ary</code></strong>
 /path/to/bin/ary:     file format elf64-x86-64
 Program Header:
 [...]
    RELRO off    0x0000000000000d78 vaddr 0x0000000000600d78 paddr 0x0000000000600d78 align 2**0
 </pre>
 <p>
 This check is now performed automatically if
 <code class="varname">PKG_DEVELOPER</code> is set and RELRO is enabled.
 </p>
 </div>
 <div class="sect2">
 <div class="titlepage"><div><div><h3 class="title">
 <a name="hardening.audit.relrofull"></a>B.3.3.�Checking for full RELRO</h3></div></div></div>
 <p>
 The dynamic loader will apply RELRO immediately when detecting the presence of
 the <code class="varname">BIND_NOW</code> flag:
 </p>
 <pre class="programlisting">
 <strong class="userinput"><code>$ objdump -x /path/to/bin/ary</code></strong>
 /path/to/bin/ary:     file format elf64-x86-64
 Dynamic Section:
 [...]
   BIND_NOW             0x0000000000000000
 </pre>
 <p>
 This has to be combined with partial RELRO (see above) to be fully efficient.
 </p>
 <p>
 This check is now performed automatically (where supported) if
 <code class="varname">PKG_DEVELOPER</code> is set.
 </p>
 </div>
 <div class="sect2">
 <div class="titlepage"><div><div><h3 class="title">
 <a name="hardening.audit.ssp"></a>B.3.4.�Checking for SSP</h3></div></div></div>
 <div class="note" style="margin-left: 0.5in; margin-right: 0.5in;">
 <h3 class="title">Note</h3>
 <p>
 Checking for SSP using this method only works where the operating system
 uses <code class="literal">libssp</code>. <code class="literal">libssp</code> is not used
 on recent NetBSD/FreeBSD/Linux versions.
 </p>
 </div>
 <p>
 Building objects, binaries and libraries with SSP will affect the presence of
 additional symbols in the resulting file:
 </p>
 <pre class="programlisting">
 <strong class="userinput"><code>$ nm /path/to/bin/ary</code></strong>
 [...]
                  U __stack_chk_fail
 0000000000600ea0 B __stack_chk_guard
 </pre>
 <p>
 This is an indicator that the program was indeed built with support for SSP.
 </p>
 <p>
 This check is now performed automatically (where supported) if
 <code class="varname">PKG_DEVELOPER</code> is set and SSP is enabled.
 </p>
 </div>
 </div>
 </div>
 <div class="appendix">
 <div class="titlepage"><div><div><h1 class="title">
 <a name="logs"></a>Appendix�C.�Build logs</h1></div></div></div>
 <div class="toc">
 <p><b>Table of Contents</b></p>
 <dl class="toc">
 <dt><span class="sect1"><a href="#logs.building">C.1. Building figlet</a></span></dt>
 <dt><span class="sect1"><a href="#logs.package">C.2. Packaging figlet</a></span></dt>
 </dl>
 </div>
 <div class="sect1">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
 <a name="logs.building"></a>C.1.�Building figlet</h2></div></div></div>
 <pre class="screen"><code class="prompt">#</code> <strong class="userinput"><code>make</code></strong>
 ===&gt; Checking for vulnerabilities in figlet-2.2.1nb2
 =&gt; figlet221.tar.gz doesn't seem to exist on this system.
 =&gt; Attempting to fetch figlet221.tar.gz from ftp://ftp.figlet.org/pub/figlet/program/unix/.
 =&gt; [172219 bytes]
 Connected to ftp.plig.net.
 ftp.plig.org NcFTPd Server (licensed copy) ready.
 Guest login ok, send your complete e-mail address as password.
 -You are user #5 of 500 simultaneous users allowed.
 -
 -  ___ _             _ _
 - |  _| |_ ___   ___| |_|___   ___ ___ ___
 - |  _|  _| . |_| . | | | . |_| . |  _| . |
 - |_| |_| |  _|_|  _|_|_|_  |_|___|_| |_  |
 -         |_|   |_|     |___|         |___|
 -
 -** Welcome to ftp.plig.org **
 -
 -Please note that all transfers from this FTP site are logged. If you
 -do not like this, please disconnect now.
 -
 -This archive is available via
 -
 -HTTP:  http://ftp.plig.org/
 -FTP:   ftp://ftp.plig.org/     (max 500 connections)
 -RSYNC: rsync://ftp.plig.org/   (max  30 connections)
 -
 -Please email comments, bug reports and requests for packages to be
 -mirrored to ftp-admin@plig.org.
 -
 -
 Logged in anonymously.
 Remote system type is UNIX.
 Using binary mode to transfer files.
 Type okay.
 "/pub" is new cwd.
 -"/pub/figlet" is new cwd.
 -
 -Welcome to the figlet archive at ftp.figlet.org
 -
 -	ftp://ftp.figlet.org/pub/figlet/
 -
 -The official FIGlet web page is:
 -	http://www.figlet.org/
 -
 -If you have questions, please mailto:info@figlet.org. If you want to
 -contribute a font or something else, you can email us.
 "/pub/figlet/program" is new cwd.
 "/pub/figlet/program/unix" is new cwd.
 local: figlet221.tar.gz remote: figlet221.tar.gz
 Unimplemented command.
 Entering Passive Mode (195,40,6,41,246,104)
 Data connection accepted from 84.128.86.72:65131; transfer starting for figlet221.tar.gz (172219 bytes).
 % |**************                       | 65800      64.16 KB/s    00:01 ETA
 Transfer completed.
 bytes received in 00:02 (75.99 KB/s)
 Goodbye.
 =&gt; Checksum OK for figlet221.tar.gz.
 ===&gt; Extracting for figlet-2.2.1nb2
 ===&gt; Required installed package ccache-[0-9]*: ccache-2.3nb1 found
 ===&gt; Patching for figlet-2.2.1nb2
 ===&gt; Applying pkgsrc patches for figlet-2.2.1nb2
 ===&gt; Overriding tools for figlet-2.2.1nb2
 ===&gt; Creating toolchain wrappers for figlet-2.2.1nb2
 ===&gt; Configuring for figlet-2.2.1nb2
 ===&gt; Building for figlet-2.2.1nb2
 gcc -O2 -DDEFAULTFONTDIR=\"/usr/pkg/share/figlet\"  -DDEFAULTFONTFILE=\"standard.flf\"  figlet.c zipio.c crc.c inflate.c -o figlet
 chmod a+x figlet
 gcc -O2 -o chkfont chkfont.c
 =&gt; Unwrapping files-to-be-installed.
 <code class="prompt">#</code>
 <code class="prompt">#</code> <strong class="userinput"><code>make install</code></strong>
 ===&gt; Checking for vulnerabilities in figlet-2.2.1nb2
 ===&gt; Installing for figlet-2.2.1nb2
 install -d -o root -g wheel -m 755 /usr/pkg/bin
 install -d -o root -g wheel -m 755 /usr/pkg/man/man6
 mkdir -p /usr/pkg/share/figlet
 cp figlet /usr/pkg/bin
 cp chkfont /usr/pkg/bin
 chmod 555 figlist showfigfonts
 cp figlist /usr/pkg/bin
 cp showfigfonts /usr/pkg/bin
 cp fonts/*.flf /usr/pkg/share/figlet
 cp fonts/*.flc /usr/pkg/share/figlet
 cp figlet.6 /usr/pkg/man/man6
 ===&gt; Registering installation for figlet-2.2.1nb2
 <code class="prompt">#</code></pre>
 </div>
 <div class="sect1">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
 <a name="logs.package"></a>C.2.�Packaging figlet</h2></div></div></div>
 <pre class="screen"><code class="prompt">#</code> <strong class="userinput"><code>make package</code></strong>
 ===&gt; Checking for vulnerabilities in figlet-2.2.1nb2
 ===&gt; Packaging figlet-2.2.1nb2
 ===&gt; Building binary package for figlet-2.2.1nb2
 Creating package /home/cvs/pkgsrc/packages/i386/All/figlet-2.2.1nb2.tgz
 Using SrcDir value of /usr/pkg
 Registering depends:.
 <code class="prompt">#</code></pre>
 </div>
 </div>
 <div class="appendix">
 <div class="titlepage"><div><div><h1 class="title">
 <a name="ftp-layout"></a>Appendix�D.�Directory layout of the pkgsrc FTP server</h1></div></div></div>
 <div class="toc">
 <p><b>Table of Contents</b></p>
 <dl class="toc">
 <dt><span class="sect1"><a href="#ftp-distfiles">D.1. <code class="filename">distfiles</code>: The distributed source files</a></span></dt>
 <dt><span class="sect1"><a href="#ftp-misc">D.2. <code class="filename">misc</code>: Miscellaneous things</a></span></dt>
 <dt><span class="sect1"><a href="#ftp-packages">D.3. <code class="filename">packages</code>: Binary packages</a></span></dt>
 <dt><span class="sect1"><a href="#ftp-reports">D.4. <code class="filename">reports</code>: Bulk build reports</a></span></dt>
 <dt><span class="sect1"><a href="#ftp-source">D.5. <code class="filename">current</code>,
 <code class="filename">stable</code>,
 <code class="filename">pkgsrc-20<em class="replaceable"><code>xx</code></em>Q<em class="replaceable"><code>y</code></em></code>:
 source packages</a></span></dt>
 </dl>
 </div>
 <p>As in other big projects, the directory layout of pkgsrc
 	is quite complex for newbies. This chapter explains where you
 	find things on the FTP server. The base directory on
 	<code class="filename">ftp.NetBSD.org</code> is <a class="ulink" href="ftp://ftp.NetBSD.org/pub/pkgsrc/" target="_top"><code class="filename">/pub/pkgsrc/</code></a>.
 	On other servers it may be different, but inside this directory,
 	everything should look the same, no matter on which server you
 	are. This directory contains some subdirectories, which are
 	explained below.</p>
 <div class="sect1">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
 <a name="ftp-distfiles"></a>D.1.�<code class="filename">distfiles</code>: The distributed source files</h2></div></div></div>
 <p>The directory <code class="filename">distfiles</code> contains lots
 	of archive files from all pkgsrc packages, which are mirrored
 	here. The subdirectories are called after their package names
 	and are used when the distributed files have names that don't
 	explicitly contain a version number or are otherwise too generic
 	(for example <code class="filename">release.tar.gz</code>).</p>
 </div>
 <div class="sect1">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
 <a name="ftp-misc"></a>D.2.�<code class="filename">misc</code>: Miscellaneous things</h2></div></div></div>
 <p>This directory contains things that individual pkgsrc
 	developers find worth publishing.</p>
 </div>
 <div class="sect1">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
 <a name="ftp-packages"></a>D.3.�<code class="filename">packages</code>: Binary packages</h2></div></div></div>
 <p>This directory contains binary packages for the various
 	platforms that are supported by pkgsrc.
 	Each subdirectory is of the form <em class="replaceable"><code>OPSYS</code></em>/<em class="replaceable"><code>ARCH</code></em>/<em class="replaceable"><code>OSVERSION_TAG</code></em>. The meaning of these variables is:</p>
 <div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; ">
 <li class="listitem"><p><code class="varname">OPSYS</code> is the name of the
 	operating system for which the packages have been built. The
 	name is taken from the output of the <span class="command"><strong>uname</strong></span>
 	command, so it may differ from the one you are used to
 	hear.</p></li>
 <li class="listitem"><p><code class="varname">ARCH</code> is the hardware
 	architecture of the platform for which the packages have been
 	built. It also includes the <code class="varname">ABI</code> (Application
 	Binary Interface) for platforms that have several of
 	them.</p></li>
 <li class="listitem"><p><code class="varname">OSVERSION</code> is the version of
 	the operating system. For version numbers that change often (for
 	example NetBSD-current), the often-changing part should be
 	replaced with an <code class="literal">x</code>, for example
 	<code class="literal">4.99.x</code>.</p></li>
 <li class="listitem"><p><code class="varname">TAG</code> is either
 	<code class="literal">20<em class="replaceable"><code>xx</code></em>Q<em class="replaceable"><code>y</code></em></code>
 	for a stable branch, or <code class="literal">head</code> for packages
 	built from the HEAD branch. The latter should only be used when
 	the packages are updated on a regular basis. Otherwise the date
 	from checking out pkgsrc should be appended, for example
 	<code class="literal">head_20071015</code>.</p></li>
 </ul></div>
 <p>The rationale for exactly this scheme is that the pkgsrc users looking for binary packages
 	can quickly click through the directories on the
 	server and find the best binary packages for their machines. Since they
 	usually know the operating system and the hardware architecture, OPSYS
 	and ARCH are placed first. After these choices, they can select the
 	best combination of OSVERSION and TAG together, since it is usually the
 	case that packages stay compatible between different version of the
 	operating system.</p>
 <p>In each of these directories, there is a
 	whole binary packages collection for a specific platform. It has a directory called
 	<code class="filename">All</code> which contains all binary packages.
 	Besides that, there are various category directories that
 	contain symbolic links to the real binary packages.</p>
 </div>
 <div class="sect1">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
 <a name="ftp-reports"></a>D.4.�<code class="filename">reports</code>: Bulk build reports</h2></div></div></div>
 <p>Here are the reports from bulk builds, for those who want
 	to fix packages that didn't build on some of the platforms. The
 	structure of subdirectories should look like the one in <a class="xref" href="#ftp-packages" title="D.3.�packages: Binary packages">Section�D.3, &#8220;<code class="filename">packages</code>: Binary packages&#8221;</a>.</p>
 </div>
 <div class="sect1">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
 <a name="ftp-source"></a>D.5.�<code class="filename">current</code>,
 <code class="filename">stable</code>,
 <code class="filename">pkgsrc-20<em class="replaceable"><code>xx</code></em>Q<em class="replaceable"><code>y</code></em></code>:
 source packages</h2></div></div></div>
 <p>These directories contain the <span class="quote">&#8220;<span class="quote">real</span>&#8221;</span> pkgsrc,
 	that is the files that define how to create binary packages from
 	source archives.</p>
 <p>Each of the <code class="filename">current</code>,
 	<code class="filename">stable</code> and
 	<code class="filename">pkgsrc-20<em class="replaceable"><code>xx</code></em>Q<em class="replaceable"><code>y</code></em></code>
 	directories share the same structure.  They each contain a
 	<code class="filename">pkgsrc</code> directory and
 	<code class="filename">pkgsrc.tar.{bz,gz,xz}</code> file.</p>
 <p>The directory <code class="filename">pkgsrc</code> contains a
 	snapshot of the CVS repository, which is updated regularly. The
 	file <code class="filename">pkgsrc.tar.{bz,gz,xz}</code> contains the same
 	as the directory, ready to be downloaded as a whole.</p>
 <p>The <code class="filename">current</code> directory contains files
 	related to the HEAD branch of the CVS repository.
 	In this directory there is an additional file called
 	<code class="filename">pkgsrc-readmes.tar.{bz,gz,xz}</code> that contains
 	all pkgsrc <code class="filename">README</code>s with information about
 	categories and packages.
 	</p>
 <p>The <code class="filename">stable</code> directory is a symlink to
 	the latest
 	<code class="filename">pkgsrc-20<em class="replaceable"><code>xx</code></em>Q<em class="replaceable"><code>y</code></em></code>.
 	</p>
 <p>The
 	<code class="filename">pkgsrc-20<em class="replaceable"><code>xx</code></em>Q<em class="replaceable"><code>y</code></em></code>.
 	directories contain files related to the
 	<code class="filename">-20<em class="replaceable"><code>xx</code></em>Q<em class="replaceable"><code>y</code></em></code>
 	stable branch of the CVS repository. In these directories there is
 	an additional file called
 	<code class="filename">pkgsrc-20<em class="replaceable"><code>xx</code></em>Q<em class="replaceable"><code>y</code></em>.tar.{bz,gz,xz}</code>,
 	which contains the state of pkgsrc when it was branched.</p>
 </div>
 </div>
 <div class="appendix">
 <div class="titlepage"><div><div><h1 class="title">
 <a name="help-topics"></a>Appendix�E.�Help topics</h1></div></div></div>
 <p>
 	The following list contains all help topics that are available
 	when running <span class="command"><strong>bmake help topic=:index</strong></span>.
 </p>
 <table border="0" summary="Simple list" class="simplelist">
 <tr>
 <td>#!</td>
 <td>-lintl</td>
 </tr>
 <tr>
 <td>32bit</td>
 <td>64bit</td>
 </tr>
 <tr>
 <td>ABI</td>
 <td>ACCEPTABLE_LICENSES</td>
 </tr>
 <tr>
 <td>ACROREAD_FONTPATH</td>
 <td>ADDITIONAL</td>
 </tr>
 <tr>
 <td>AFAIK</td>
 <td>AIX</td>
 </tr>
 <tr>
 <td>ALLOW_VULNERABLE_PACKAGES</td>
 <td>ALL_ENV</td>
 </tr>
 <tr>
 <td>ALSA_PC</td>
 <td>ALTERNATIVES_SRC</td>
 </tr>
 <tr>
 <td>AMANDA_TMP</td>
 <td>AMANDA_USER</td>
 </tr>
 <tr>
 <td>AMANDA_USER</td>
 <td>AMANDA_VAR</td>
 <td>APACHE_GROUP</td>
 </tr>
 <tr>
 <td>APACHE_GROUP</td>
 <td>APACHE_MODULE_NAME</td>
 <td>APACHE_MODULE_SRC</td>
 </tr>
 <tr>
 <td>APACHE_MODULE_SRC</td>
 <td>APACHE_MODULE_SRCDIR</td>
 <td>APACHE_PKG_PREFIX</td>
 </tr>
 <tr>
 <td>APACHE_PKG_PREFIX</td>
 <td>APACHE_SUEXEC_CONFIGURE_ARGS</td>
 <td>APACHE_SUEXEC_DOCROOT</td>
 </tr>
 <tr>
 <td>APACHE_SUEXEC_DOCROOT</td>
 <td>APACHE_USER</td>
 <td>APPEND_ABI</td>
 </tr>
 <tr>
 <td>APPEND_ABI</td>
 <td>APPEND_ELF</td>
 <td>ARLA_CACHE</td>
 </tr>
 <tr>
 <td>ARLA_CACHE</td>
 <td>AUDIT_PACKAGES_FLAGS</td>
 <td>AUTOCONF_REQD</td>
 </tr>
 <tr>
 <td>AUTOCONF_REQD</td>
 <td>AUTOMAKE_OVERRIDE</td>
 <td>AUTOMAKE_REQD</td>
 </tr>
 <tr>
 <td>AUTOMAKE_REQD</td>
 <td>AUTO_MKDIRS</td>
 <td>BDB185_DEFAULT</td>
 </tr>
 <tr>
 <td>BDB185_DEFAULT</td>
 <td>BDBBASE</td>
 <td>BDB_ACCEPTED</td>
 </tr>
 <tr>
 <td>BDB_ACCEPTED</td>
 <td>BDB_DEFAULT</td>
 <td>BDB_LIBS</td>
 </tr>
 <tr>
 <td>BDB_LIBS</td>
 <td>BDB_TYPE</td>
 <td>BINCIMAP_GROUP</td>
 </tr>
 <tr>
 <td>BINCIMAP_GROUP</td>
 <td>BINCIMAP_USER</td>
 <td>BIND_DIR</td>
 </tr>
 <tr>
 <td>BIND_DIR</td>
 <td>BIND_GROUP</td>
 <td>BIND_USER</td>
 </tr>
 <tr>
 <td>BIND_USER</td>
 <td>BINOWN</td>
 <td>BINPKG_SITES</td>
 </tr>
 <tr>
 <td>BINPKG_SITES</td>
 <td>BIN_INSTALL_FLAGS</td>
 <td>BISON_PKGDATADIR</td>
 </tr>
 <tr>
 <td>BISON_PKGDATADIR</td>
 <td>BLAS</td>
 <td>BLAS_ACCEPTED</td>
 </tr>
 <tr>
 <td>BLAS_ACCEPTED</td>
 <td>BLAS_C_INTERFACE</td>
 <td>BLAS_INCLUDES</td>
 </tr>
 <tr>
 <td>BLAS_INCLUDES</td>
 <td>BLAS_INDEX64</td>
 <td>BLAS_LIBS</td>
 </tr>
 <tr>
 <td>BLAS_LIBS</td>
 <td>BLAS_TYPE</td>
 <td>BOOTSTRAP_DEPENDS</td>
 </tr>
 <tr>
 <td>BOOTSTRAP_DEPENDS</td>
 <td>BROKEN</td>
 <td>BROKEN_EXCEPT_ON_PLATFORM</td>
 </tr>
 <tr>
 <td>BROKEN_EXCEPT_ON_PLATFORM</td>
 <td>BROKEN_ON_PLATFORM</td>
 <td>BSDSRCDIR</td>
 </tr>
 <tr>
 <td>BSDSRCDIR</td>
 <td>BSDXSRCDIR</td>
 <td>BSD_MAKE_ENV</td>
 </tr>
 <tr>
 <td>BSD_MAKE_ENV</td>
 <td>BUILDLINK_AUTO_DIRS</td>
 <td>BUILDLINK_AUTO_VARS</td>
 </tr>
 <tr>
 <td>BUILDLINK_AUTO_VARS</td>
 <td>BUILDLINK_CFLAGS</td>
 <td>BUILDLINK_CONTENTS_FILTER</td>
 </tr>
 <tr>
 <td>BUILDLINK_CONTENTS_FILTER</td>
 <td>BUILDLINK_CPPFLAGS</td>
 <td>BUILDLINK_DEPMETHOD</td>
 </tr>
 <tr>
 <td>BUILDLINK_FILES</td>
 <td>BUILDLINK_FILES_CMD</td>
 </tr>
 <tr>
 <td>BUILDLINK_FNAME_TRANSFORM</td>
 <td>BUILDLINK_LDFLAGS</td>
 </tr>
 <tr>
 <td>BUILDLINK_LIBS</td>
 <td>BUILDLINK_OPSYS_SUPPORT_PTHREAD</td>
 </tr>
 <tr>
 <td>BUILDLINK_PKGNAME</td>
 <td>BUILDLINK_PREFIX</td>
 </tr>
 <tr>
 <td>BUILDLINK_RPATHDIRS</td>
 <td>BUILDLINK_TREE</td>
 </tr>
 <tr>
 <td>BUILD_DEFS</td>
 <td>BUILD_DEFS_EFFECTS</td>
 </tr>
 <tr>
 <td>BUILD_DEPENDS</td>
 <td>BUILD_DIRS</td>
 </tr>
 <tr>
 <td>BUILD_ENV_SHELL</td>
 <td>BUILD_MAKE_CMD</td>
 </tr>
 <tr>
 <td>BUILD_MAKE_FLAGS</td>
 <td>BUILD_TARGET</td>
 </tr>
 <tr>
 <td>BUILTIN_FIND_FILES</td>
 <td>BUILTIN_FIND_FILES_VAR</td>
 </tr>
 <tr>
 <td>BUILTIN_FIND_GREP</td>
 <td>BUILTIN_FIND_HEADERS</td>
 </tr>
 <tr>
 <td>BUILTIN_FIND_HEADERS_VAR</td>
 <td>BUILTIN_FIND_PKGCONFIG</td>
 </tr>
 <tr>
 <td>BUILTIN_FIND_PKGCONFIG_VAR</td>
 <td>BUILTIN_PKG</td>
 </tr>
 <tr>
 <td>BUILTIN_TEST_CURSES_DEFINES</td>
 <td>BUILTIN_TEST_CURSES_FUNCS</td>
 </tr>
 <tr>
 <td>BUILTIN_VERSION_SCRIPT</td>
 <td>BUILTIN_X11_TYPE</td>
 </tr>
 <tr>
 <td>BUILTIN_X11_VERSION</td>
 <td>CACTI_GROUP</td>
 </tr>
 <tr>
 <td>CACTI_USER</td>
 <td>CANNA_GROUP</td>
 </tr>
 <tr>
 <td>CANNA_USER</td>
 <td>CAT</td>
 </tr>
 <tr>
 <td>CBLAS_LIBS</td>
 <td>CCACHE_BASE</td>
 </tr>
 <tr>
 <td>CCACHE_DIR</td>
 <td>CCACHE_LOGFILE</td>
 </tr>
 <tr>
 <td>CC_VERSION</td>
 <td>CC_VERSION_STRING</td>
 </tr>
 <tr>
 <td>CDRECORD_CONF</td>
 <td>CDROM_PKG_URL_DIR</td>
 </tr>
 <tr>
 <td>CDROM_PKG_URL_HOST</td>
 <td>CHECKOUT_DATE</td>
 </tr>
 <tr>
 <td>CHECK_COMPILER</td>
 <td>CHECK_FAKEHOME</td>
 </tr>
 <tr>
 <td>CHECK_FAKEHOME</td>
 <td>CHECK_FILES</td>
 <td>CHECK_FILES_SKIP</td>
 </tr>
 <tr>
 <td>CHECK_FILES_SKIP</td>
 <td>CHECK_FILES_STRICT</td>
 <td>CHECK_HEADERS</td>
 </tr>
 <tr>
 <td>CHECK_HEADERS</td>
 <td>CHECK_HEADERS_SKIP</td>
 <td>CHECK_INTERPRETER</td>
 </tr>
 <tr>
 <td>CHECK_INTERPRETER</td>
 <td>CHECK_INTERPRETER_SKIP</td>
 <td>CHECK_PERMS</td>
 </tr>
 <tr>
 <td>CHECK_PERMS</td>
 <td>CHECK_PERMS_AUTOFIX</td>
 <td>CHECK_PERMS_SKIP</td>
 </tr>
 <tr>
 <td>CHECK_PERMS_SKIP</td>
 <td>CHECK_PIE</td>
 <td>CHECK_PIE_SKIP</td>
 </tr>
 <tr>
 <td>CHECK_PIE_SKIP</td>
 <td>CHECK_PIE_SUPPORTED</td>
 <td>CHECK_PORTABILITY</td>
 </tr>
 <tr>
 <td>CHECK_PORTABILITY</td>
 <td>CHECK_PORTABILITY_EXPERIMENTAL</td>
 <td>CHECK_PORTABILITY_SKIP</td>
 </tr>
 <tr>
 <td>CHECK_PORTABILITY_SKIP</td>
 <td>CHECK_RELRO</td>
 <td>CHECK_RELRO_SKIP</td>
 </tr>
 <tr>
 <td>CHECK_RELRO_SKIP</td>
 <td>CHECK_RELRO_SUPPORTED</td>
 <td>CHECK_SHLIBS</td>
 </tr>
 <tr>
 <td>CHECK_SHLIBS</td>
 <td>CHECK_SHLIBS_SKIP</td>
 <td>CHECK_SHLIBS_SUPPORTED</td>
 </tr>
 <tr>
 <td>CHECK_SHLIBS_SUPPORTED</td>
 <td>CHECK_SHLIBS_TOXIC</td>
 <td>CHECK_SSP</td>
 </tr>
 <tr>
 <td>CHECK_SSP</td>
 <td>CHECK_SSP_SKIP</td>
 <td>CHECK_SSP_SUPPORTED</td>
 </tr>
 <tr>
 <td>CHECK_SSP_SUPPORTED</td>
 <td>CHECK_STRIPPED</td>
 <td>CHECK_STRIPPED_SKIP</td>
 </tr>
 <tr>
 <td>CHECK_STRIPPED_SKIP</td>
 <td>CHECK_WRKREF</td>
 <td>CHECK_WRKREF_EXTRA_DIRS</td>
 </tr>
 <tr>
 <td>CHECK_WRKREF_EXTRA_DIRS</td>
 <td>CHECK_WRKREF_SKIP</td>
 <td>CLAMAV_DBDIR</td>
 </tr>
 <tr>
 <td>CLAMAV_DBDIR</td>
 <td>CLAMAV_GROUP</td>
 <td>CLAMAV_USER</td>
 </tr>
 <tr>
 <td>CLAMAV_USER</td>
 <td>CLANGBASE</td>
 <td>CLEANDEPENDS</td>
 </tr>
 <tr>
 <td>CLEANDEPENDS</td>
 <td>CMAKE_DEPENDENCIES_REWRITE</td>
 <td>CMAKE_INSTALL_NAME_DIR</td>
 </tr>
 <tr>
 <td>CMAKE_INSTALL_NAME_DIR</td>
 <td>CMAKE_INSTALL_PREFIX</td>
 <td>CMAKE_MODULE_PATH_OVERRIDE</td>
 </tr>
 <tr>
 <td>CMAKE_MODULE_PATH_OVERRIDE</td>
 <td>CMAKE_PKGSRC_BUILD_FLAGS</td>
 <td>CMAKE_PREFIX_PATH</td>
 </tr>
 <tr>
 <td>CMAKE_PREFIX_PATH</td>
 <td>CMAKE_USE_GNU_INSTALL_DIRS</td>
 <td>COMMON_LISP_DOCFILES</td>
 </tr>
 <tr>
 <td>COMMON_LISP_EXAMPLES</td>
 <td>COMMON_LISP_EXTRAFILES</td>
 </tr>
 <tr>
 <td>COMMON_LISP_PACKAGES</td>
 <td>COMMON_LISP_SYSTEM</td>
 </tr>
 <tr>
 <td>COMPILER_RPATH_FLAG</td>
 <td>COMPILER_USE_SYMLINKS</td>
 </tr>
 <tr>
 <td>CONFIGURE_ARGS</td>
 <td>CONFIGURE_DIRS</td>
 </tr>
 <tr>
 <td>CONFIGURE_ENV</td>
 <td>CONFIGURE_ENV_SHELL</td>
 </tr>
 <tr>
 <td>CONFIGURE_HAS_INFODIR</td>
 <td>CONFIGURE_HAS_MANDIR</td>
 </tr>
 <tr>
 <td>CONFIGURE_SCRIPT</td>
 <td>CONFIG_SHELL</td>
 </tr>
 <tr>
 <td>CONFIG_SHELL_FLAGS</td>
 <td>CONF_FILES</td>
 </tr>
 <tr>
 <td>CONF_FILES_MODE</td>
 <td>CONF_FILES_PERMS</td>
 </tr>
 <tr>
 <td>CONSERVER_DEFAULTHOST</td>
 <td>CONSERVER_DEFAULTPORT</td>
 </tr>
 <tr>
 <td>CP</td>
 <td>CPP</td>
 </tr>
 <tr>
 <td>CPP_PRECOMP_FLAGS</td>
 <td>CREATE_WRKDIR_SYMLINK</td>
 </tr>
 <tr>
 <td>CROSSBASE</td>
 <td>CTFCONVERT</td>
 </tr>
 <tr>
 <td>CTF_FILES_SKIP</td>
 <td>CTF_SUPPORTED</td>
 </tr>
 <tr>
 <td>CTYPE</td>
 <td>CUPS_GROUP</td>
 </tr>
 <tr>
 <td>CUPS_SYSTEM_GROUPS</td>
 <td>CUPS_USER</td>
 </tr>
 <tr>
 <td>CURSES_DEFAULT</td>
 <td>CURSES_TYPE</td>
 </tr>
 <tr>
 <td>CVS_EXTRACTDIR</td>
 <td>CVS_MODULE</td>
 </tr>
 <tr>
 <td>CVS_PROJECT</td>
 <td>CVS_REPOSITORIES</td>
 </tr>
 <tr>
 <td>CVS_ROOT</td>
 <td>CVS_ROOT_GNU</td>
 </tr>
 <tr>
 <td>CVS_ROOT_NONGNU</td>
 <td>CVS_ROOT_SOURCEFORGE</td>
 </tr>
 <tr>
 <td>CVS_TAG</td>
 <td>CXX</td>
 </tr>
 <tr>
 <td>CYRUS_GROUP</td>
 <td>CYRUS_IDLE</td>
 </tr>
 <tr>
 <td>CYRUS_IDLE</td>
 <td>CYRUS_USER</td>
 <td>DAEMONTOOLS_GROUP</td>
 </tr>
 <tr>
 <td>DAEMONTOOLS_GROUP</td>
 <td>DAEMONTOOLS_LOG_USER</td>
 <td>DARWIN_NO_SYSTEM_LIBS</td>
 </tr>
 <tr>
 <td>DARWIN_NO_SYSTEM_LIBS</td>
 <td>DARWIN_REQUIRES_FILTER</td>
 <td>DBUS_GROUP</td>
 </tr>
 <tr>
 <td>DBUS_GROUP</td>
 <td>DBUS_USER</td>
 <td>DEFANG_GROUP</td>
 </tr>
 <tr>
 <td>DEFANG_GROUP</td>
 <td>DEFANG_USER</td>
 <td>DEFAULT_ACCEPTABLE_LICENSES</td>
 </tr>
 <tr>
 <td>DEFAULT_ACCEPTABLE_LICENSES</td>
 <td>DEFAULT_DISTFILES</td>
 <td>DEFAULT_IRC_SERVER</td>
 </tr>
 <tr>
 <td>DEFAULT_IRC_SERVER</td>
 <td>DEFAULT_SERIAL_DEVICE</td>
 <td>DEF_UMASK</td>
 </tr>
 <tr>
 <td>DEF_UMASK</td>
 <td>DEINSTALLDEPENDS</td>
 <td>DEINSTALL_SRC</td>
 </tr>
 <tr>
 <td>DEINSTALL_SRC</td>
 <td>DEINSTALL_TEMPLATES</td>
 <td>DELAYED_ERROR_MSG</td>
 </tr>
 <tr>
 <td>DELAYED_ERROR_MSG</td>
 <td>DELAYED_WARNING_MSG</td>
 <td>DEPENDS</td>
 </tr>
 <tr>
 <td>DEPENDS</td>
 <td>DEPENDS_TARGET</td>
 <td>DEPENDS_TYPE</td>
 </tr>
 <tr>
 <td>DEPENDS_TYPE</td>
 <td>DESTDIR</td>
 <td>DESTDIR_VARNAME</td>
 </tr>
 <tr>
 <td>DESTDIR_VARNAME</td>
 <td>DIALER_GROUP</td>
 <td>DIGEST_REQD</td>
 </tr>
 <tr>
 <td>DIGEST_REQD</td>
 <td>DISTDIR</td>
 <td>DISTFILES</td>
 </tr>
 <tr>
 <td>DISTFILES</td>
 <td>DISTINFO_FILE</td>
 <td>DISTNAME</td>
 </tr>
 <tr>
 <td>DISTNAME</td>
 <td>DIST_PATH</td>
 <td>DIST_SUBDIR</td>
 </tr>
 <tr>
 <td>DIST_SUBDIR</td>
 <td>DJBDNS_AXFR_USER</td>
 <td>DJBDNS_CACHE_USER</td>
 </tr>
 <tr>
 <td>DJBDNS_CACHE_USER</td>
 <td>DJBDNS_DJBDNS_GROUP</td>
 <td>DJBDNS_LOG_USER</td>
 </tr>
 <tr>
 <td>DJBDNS_LOG_USER</td>
 <td>DJBDNS_RBL_USER</td>
 <td>DJBDNS_TINY_USER</td>
 </tr>
 <tr>
 <td>DJBDNS_TINY_USER</td>
 <td>DLOPEN_REQUIRE_PTHREADS</td>
 <td>DL_AUTO_VARS</td>
 </tr>
 <tr>
 <td>DL_AUTO_VARS</td>
 <td>DL_CFLAGS</td>
 <td>DL_LDFLAGS</td>
 </tr>
 <tr>
 <td>DL_LDFLAGS</td>
 <td>DL_LIBS</td>
 <td>DNS</td>
 </tr>
 <tr>
 <td>DNS</td>
 <td>DOCOWN</td>
 <td>DOWNLOADED_DISTFILE</td>
 </tr>
 <tr>
 <td>DOWNLOADED_DISTFILE</td>
 <td>DQCACHE_GROUP</td>
 <td>DQCACHE_USER</td>
 </tr>
 <tr>
 <td>DQCACHE_USER</td>
 <td>DT_LAYOUT</td>
 <td>DYNAMIC_SITES_CMD</td>
 </tr>
 <tr>
 <td>DYNAMIC_SITES_CMD</td>
 <td>DYNAMIC_SITES_SCRIPT</td>
 <td>ECHO</td>
 </tr>
 <tr>
 <td>ECHO</td>
 <td>ECHO_N</td>
 <td>ELK_GUI</td>
 </tr>
 <tr>
 <td>ELK_GUI</td>
 <td>EMACS_TYPE</td>
 <td>EMULDIR</td>
 </tr>
 <tr>
 <td>EMULDIR</td>
 <td>EMULSUBDIR</td>
 <td>EMULSUBDIRSLASH</td>
 </tr>
 <tr>
 <td>EMULSUBDIRSLASH</td>
 <td>EMUL_ARCH</td>
 <td>EMUL_DISTRO</td>
 </tr>
 <tr>
 <td>EMUL_DISTRO</td>
 <td>EMUL_EXEC_FMT</td>
 <td>EMUL_IS_NATIVE</td>
 </tr>
 <tr>
 <td>EMUL_IS_NATIVE</td>
 <td>EMUL_MODULES</td>
 <td>EMUL_OPSYS</td>
 </tr>
 <tr>
 <td>EMUL_OPSYS</td>
 <td>EMUL_PKG_FMT</td>
 <td>EMUL_PLATFORM</td>
 </tr>
 <tr>
 <td>EMUL_PLATFORM</td>
 <td>EMUL_PLATFORMS</td>
 <td>EMUL_PREFER</td>
 </tr>
 <tr>
 <td>EMUL_PREFER</td>
 <td>EMUL_REQD</td>
 <td>EMUL_TYPE</td>
 </tr>
 <tr>
 <td>EMUL_TYPE</td>
 <td>ERROR_MSG</td>
 <td>EXIM_GROUP</td>
 </tr>
 <tr>
 <td>EXIM_GROUP</td>
 <td>EXIM_USER</td>
 <td>EXPORT_SYMBOLS_LDFLAGS</td>
 </tr>
 <tr>
 <td>EXPORT_SYMBOLS_LDFLAGS</td>
 <td>EXTRACTOR</td>
 <td>EXTRACT_CMD</td>
 </tr>
 <tr>
 <td>EXTRACT_CMD</td>
 <td>EXTRACT_CMD_DEFAULT</td>
 <td>EXTRACT_DIR</td>
 </tr>
 <tr>
 <td>EXTRACT_DIR</td>
 <td>EXTRACT_ELEMENTS</td>
 <td>EXTRACT_ENV</td>
 </tr>
 <tr>
 <td>EXTRACT_ENV</td>
 <td>EXTRACT_ONLY</td>
 <td>EXTRACT_OPTS</td>
 </tr>
 <tr>
 <td>EXTRACT_OPTS</td>
 <td>EXTRACT_SUFX</td>
 <td>EXTRACT_USING</td>
 </tr>
 <tr>
 <td>EXTRACT_USING</td>
 <td>FAIL</td>
 <td>FAILOVER_FETCH</td>
 </tr>
 <tr>
 <td>FAILOVER_FETCH</td>
 <td>FAIL_MSG</td>
 <td>FAKE_NCURSES</td>
 </tr>
 <tr>
 <td>FAKE_NCURSES</td>
 <td>FAM</td>
 <td>FAM_ACCEPTED</td>
 </tr>
 <tr>
 <td>FAM_ACCEPTED</td>
 <td>FAM_DEFAULT</td>
 <td>FAM_SERVER</td>
 </tr>
 <tr>
 <td>FAM_SERVER</td>
 <td>FCPATH</td>
 <td>FEATURE_CPPFLAGS</td>
 </tr>
 <tr>
 <td>FEATURE_CPPFLAGS</td>
 <td>FEATURE_LDFLAGS</td>
 <td>FEATURE_LIBS</td>
 </tr>
 <tr>
 <td>FEATURE_LIBS</td>
 <td>FETCH_AFTER_ARGS</td>
 <td>FETCH_BEFORE_ARGS</td>
 </tr>
 <tr>
 <td>FETCH_BEFORE_ARGS</td>
 <td>FETCH_CMD</td>
 <td>FETCH_OUTPUT_ARGS</td>
 </tr>
 <tr>
 <td>FETCH_OUTPUT_ARGS</td>
 <td>FETCH_PROXY</td>
 <td>FETCH_RESUME_ARGS</td>
 </tr>
 <tr>
 <td>FETCH_RESUME_ARGS</td>
 <td>FETCH_TIMEOUT</td>
 <td>FETCH_USE_IPV4_ONLY</td>
 </tr>
 <tr>
 <td>FETCH_USE_IPV4_ONLY</td>
 <td>FETCH_USING</td>
 <td>FILES_SUBST</td>
 </tr>
 <tr>
 <td>FILES_SUBST</td>
 <td>FILES_SUBST_SED</td>
 <td>FIX_SYSTEM_HEADERS</td>
 </tr>
 <tr>
-<td>FONTDIR</td>
+<td>FIX_SYSTEM_HEADERS</td>
 <td>FONTS_DIRS</td>
 </tr>
 <tr>
 <td>FONTS_VERBOSE</td>
 <td>FOO_HACKS_MK</td>
 </tr>
 <tr>
 <td>FOSSIL_EXTRACTDIR</td>
 <td>FOSSIL_REPO</td>
 </tr>
 <tr>
 <td>FOSSIL_REPOSITORIES</td>
 <td>FOSSIL_VERSION</td>
 </tr>
 <tr>
 <td>FOX_USE_XUNICODE</td>
 <td>FREEWNN_GROUP</td>
 </tr>
 <tr>
 <td>FREEWNN_USER</td>
 <td>FTP_PKG_URL_DIR</td>
 </tr>
 <tr>
 <td>FTP_PKG_URL_HOST</td>
 <td>GAMEDATAMODE</td>
 </tr>
 <tr>
 <td>GAMEDATA_PERMS</td>
 <td>GAMEDIRMODE</td>
 </tr>
 <tr>
 <td>GAMEDIR_PERMS</td>
 <td>GAMEGRP</td>
 </tr>
 <tr>
 <td>GAMEMODE</td>
 <td>GAMEOWN</td>
 </tr>
 <tr>
 <td>GAMES_GROUP</td>
 <td>GAMES_USER</td>
 </tr>
 <tr>
 <td>GCC</td>
 <td>GCCBASE</td>
 </tr>
 <tr>
 <td>GCC_REQD</td>
 <td>GCC_VERSION_SUFFIX</td>
 </tr>
 <tr>
 <td>GEM_BUILD</td>
 <td>GEM_CLEANBUILD</td>
 </tr>
 <tr>
 <td>GEM_CLEANBUILD_EXTENSIONS</td>
 <td>GEM_DOCDIR</td>
 </tr>
 <tr>
 <td>GEM_EXTSDIR</td>
 <td>GEM_HOME</td>
 </tr>
 <tr>
 <td>GEM_KEEPBUILD</td>
 <td>GEM_LIBDIR</td>
 </tr>
 <tr>
 <td>GEM_NAME</td>
 <td>GEM_PATH</td>
 </tr>
 <tr>
 <td>GEM_PLUGINSDIR</td>
 <td>GEM_SPECFILE</td>
 </tr>
 <tr>
 <td>GENERATE_PLIST</td>
 <td>GHC</td>
 </tr>
 <tr>
 <td>GHOSTSCRIPT_REQD</td>
 <td>GITHUB_PROJECT</td>
 </tr>
 <tr>
 <td>GITHUB_RELEASE</td>
 <td>GITHUB_SUBMODULES</td>
 </tr>
 <tr>
 <td>GITHUB_TAG</td>
 <td>GITHUB_TYPE</td>
 </tr>
 <tr>
 <td>GITLAB_PROJECT</td>
-<td>GITLAB_TAG</td>
+<td>GITLAB_RELEASE</td>
 </tr>
 <tr>
-<td>GITLAB_TYPE</td>
+<td>GITLAB_SUBMODULES</td>
-<td>GIT_BRANCH</td>
+<td>GITLAB_TAG</td>
 </tr>
 <tr>
 <td>GIT_ENV</td>
 <td>GIT_EXTRACTDIR</td>
 </tr>
 <tr>
 <td>GIT_REPO</td>
 <td>GIT_REPOSITORIES</td>
 </tr>
 <tr>
 <td>GIT_REVISION</td>
 <td>GIT_TAG</td>
 </tr>
 <tr>
 <td>GITLAB_TYPE</td>
 <td>GNU</td>
 <td>GNU_CONFIGURE</td>
 </tr>
 <tr>
 <td>GNU_CONFIGURE</td>
 <td>GNU_CONFIGURE_INFODIR</td>
 <td>GNU_CONFIGURE_MANDIR</td>
 </tr>
 <tr>
 <td>GNU_CONFIGURE_MANDIR</td>
 <td>GNU_CONFIGURE_QUIET</td>
 <td>GNU_CONFIGURE_STRICT</td>
 </tr>
 <tr>
 <td>GNU_CONFIGURE_STRICT</td>
 <td>GODEP_REDIRECTS</td>
 <td>GO_BUILD_PATTERN</td>
 </tr>
 <tr>
 <td>GO_BUILD_PATTERN</td>
 <td>GO_DEPS</td>
 <td>GO_DIST_BASE</td>
 </tr>
 <tr>
 <td>GO_DIST_BASE</td>
 <td>GO_EXTRA_MOD_DIRS</td>
 <td>GO_MODULE_FILES</td>
 </tr>
 <tr>
 <td>GO_MODULE_FILES</td>
 <td>GO_SRCPATH</td>
 <td>GO_VERSION_DEFAULT</td>
 </tr>
 <tr>
 <td>GO_VERSION_DEFAULT</td>
 <td>GROUP_SPECIFIC_PKGS</td>
 <td>GRUB_NETWORK_CARDS</td>
 </tr>
 <tr>
 <td>GRUB_NETWORK_CARDS</td>
 <td>GRUB_PRESET_COMMAND</td>
 <td>GRUB_SCAN_ARGS</td>
 </tr>
 <tr>
 <td>GRUB_SCAN_ARGS</td>
 <td>GZIP</td>
 <td>HASKELL_COMPILER</td>
 </tr>
 <tr>
 <td>HASKELL_ENABLE_DYNAMIC_EXECUTABLE</td>
 <td>HASKELL_ENABLE_HADDOCK_DOCUMENTATION</td>
 </tr>
 <tr>
 <td>HASKELL_ENABLE_LIBRARY_PROFILING</td>
 <td>HASKELL_ENABLE_SHARED_LIBRARY</td>
 </tr>
 <tr>
 <td>HASKELL_OPTIMIZATION_LEVEL</td>
 <td>HAS_CONFIGURE</td>
 </tr>
 <tr>
 <td>HEADER_TEMPLATES</td>
 <td>HG_REPO</td>
 </tr>
 <tr>
 <td>HG_REPOSITORIES</td>
 <td>HG_TAG</td>
 </tr>
 <tr>
 <td>HOMEPAGE</td>
 <td>HOST_PKGTOOLS_ARGS</td>
 </tr>
 <tr>
 <td>HOST_PKGTOOLS_ARGS</td>
 <td>HOST_SPECIFIC_PKGS</td>
 <td>HOWL_GROUP</td>
 </tr>
 <tr>
 <td>HOWL_GROUP</td>
 <td>HOWL_USER</td>
 <td>ICCBASE</td>
 </tr>
 <tr>
 <td>ICCBASE</td>
 <td>ICECAST_CHROOTDIR</td>
 <td>ICON_THEMES</td>
 </tr>
 <tr>
 <td>ICON_THEMES</td>
 <td>IDOBASE</td>
 <td>IGNORE_CCACHE</td>
 </tr>
 <tr>
 <td>IGNORE_CCACHE</td>
 <td>IGNORE_INFO_DIRS</td>
 <td>IGNORE_INTERACTIVE_FETCH</td>
 </tr>
 <tr>
 <td>IGNORE_INTERACTIVE_FETCH</td>
 <td>IMAKE</td>
 <td>IMAKEOPTS</td>
 </tr>
 <tr>
 <td>IMAKEOPTS</td>
 <td>IMAKE_MAKE</td>
 <td>IMAKE_MANINSTALL</td>
 </tr>
 <tr>
 <td>IMAKE_MANINSTALL</td>
 <td>IMAP_UW_CCLIENT_MBOX_FMT</td>
 <td>IMDICTDIR</td>
 </tr>
 <tr>
 <td>IMDICTDIR</td>
 <td>INCOMPAT_CURSES</td>
 <td>INFO_DIR</td>
 </tr>
 <tr>
 <td>INFO_DIR</td>
 <td>INFO_FILES</td>
 <td>INFO_FILES_VERBOSE</td>
 </tr>
 <tr>
 <td>INFO_FILES_VERBOSE</td>
 <td>INFO_MSG</td>
 <td>INIT_SYSTEM</td>
 </tr>
 <tr>
 <td>INIT_SYSTEM</td>
 <td>INN_DATA_DIR</td>
 <td>INN_GROUP</td>
 </tr>
 <tr>
 <td>INN_GROUP</td>
 <td>INN_USER</td>
 <td>INSTALLATION_DIRS</td>
 </tr>
 <tr>
 <td>INSTALLATION_DIRS</td>
 <td>INSTALLATION_DIRS_FROM_PLIST</td>
 <td>INSTALL_ENV</td>
 </tr>
 <tr>
 <td>INSTALL_ENV</td>
 <td>INSTALL_SH_OVERRIDE</td>
 <td>INSTALL_SRC</td>
 </tr>
 <tr>
 <td>INSTALL_SRC</td>
 <td>INSTALL_TEMPLATES</td>
 <td>INSTALL_UNSTRIPPED</td>
 </tr>
 <tr>
 <td>INSTALL_UNSTRIPPED</td>
 <td>IRCD_HYBRID_IRC_GROUP</td>
 <td>IRCD_HYBRID_IRC_USER</td>
 </tr>
 <tr>
 <td>IRCD_HYBRID_IRC_USER</td>
 <td>IRCD_HYBRID_MAXCONN</td>
 <td>IRCD_HYBRID_NICLEN</td>
 </tr>
 <tr>
 <td>IRCD_HYBRID_NICLEN</td>
 <td>IRCD_HYBRID_SYSLOG_EVENTS</td>
 <td>IRCD_HYBRID_SYSLOG_FACILITY</td>
 </tr>
 <tr>
 <td>IRCD_HYBRID_SYSLOG_FACILITY</td>
 <td>IRCD_HYBRID_TOPICLEN</td>
 <td>IRIX</td>
 </tr>
 <tr>
 <td>IRIX</td>
 <td>IRRD_USE_PGP</td>
 <td>JABBERD_GROUP</td>
 </tr>
 <tr>
 <td>JABBERD_GROUP</td>
 <td>JABBERD_LOGDIR</td>
 <td>JABBERD_PIDDIR</td>
 </tr>
 <tr>
 <td>JABBERD_PIDDIR</td>
 <td>JABBERD_SPOOLDIR</td>
 <td>JABBERD_USER</td>
 </tr>
 <tr>
 <td>JAVA_APP_PATH</td>
 <td>JAVA_APP_TARGETS</td>
 </tr>
 <tr>
 <td>JABBERD_USER</td>
 <td>JAVA_BINPREFIX</td>
 <td>JAVA_CLASSPATH</td>
 </tr>
 <tr>
 <td>JAVA_CLASSPATH</td>
 <td>JAVA_HOME</td>
 <td>JAVA_LD_LIBRARY_PATH</td>
 </tr>
 <tr>
 <td>JAVA_LD_LIBRARY_PATH</td>
 <td>JAVA_NAME</td>
 <td>JAVA_UNLIMIT</td>
 </tr>
 <tr>
 <td>JAVA_UNLIMIT</td>
 <td>JAVA_WRAPPERS</td>
 <td>JPEG_ACCEPTED</td>
 </tr>
 <tr>
 <td>JPEG_ACCEPTED</td>
 <td>JPEG_DEFAULT</td>
 <td>KERBEROS</td>
 </tr>
 <tr>
 <td>KERBEROS</td>
 <td>KERMIT_SUID_UUCP</td>
 <td>KJS_USE_PCRE</td>
 </tr>
 <tr>
 <td>KJS_USE_PCRE</td>
 <td>KNEWS_DOMAIN_FILE</td>
 <td>KNEWS_DOMAIN_NAME</td>
 </tr>
 <tr>
 <td>KNEWS_DOMAIN_NAME</td>
 <td>KRB5_ACCEPTED</td>
 <td>KRB5_DEFAULT</td>
 </tr>
 <tr>
 <td>KRB5_DEFAULT</td>
 <td>LANGUAGES</td>
 <td>LAPACKE_LIBS</td>
 </tr>
 <tr>
 <td>LAPACKE_LIBS</td>
 <td>LAPACK_LIBS</td>
 <td>LATEX2HTML_ICONPATH</td>
 </tr>
 <tr>
 <td>LATEX2HTML_ICONPATH</td>
 <td>LDCONFIG_ADD_CMD</td>
 <td>LDCONFIG_REMOVE_CMD</td>
 </tr>
 <tr>
 <td>LDCONFIG_REMOVE_CMD</td>
 <td>LDD</td>
 <td>LEAFNODE_DATA_DIR</td>
 </tr>
 <tr>
 <td>LEAFNODE_DATA_DIR</td>
 <td>LEAFNODE_GROUP</td>
 <td>LEAFNODE_USER</td>
 </tr>
 <tr>
 <td>LEAFNODE_USER</td>
 <td>LIBDVDCSS_HOMEPAGE</td>
 <td>LIBDVDCSS_MASTER_SITES</td>
 </tr>
 <tr>
 <td>LIBDVDCSS_MASTER_SITES</td>
 <td>LIBRSVG_TYPE</td>
 <td>LIBTOOL</td>
 </tr>
 <tr>
 <td>LIBTOOL</td>
 <td>LIBTOOLIZE_PLIST</td>
 <td>LIBTOOL_M4_OVERRIDE</td>
 </tr>
 <tr>
 <td>LIBTOOL_M4_OVERRIDE</td>
 <td>LIBUSB_TYPE</td>
 <td>LICENSE</td>
 </tr>
 <tr>
 <td>LICENSE</td>
 <td>LINKER_RPATH_FLAG</td>
 <td>LINK_RPATH_FLAG</td>
 </tr>
 <tr>
 <td>LINUX_BASE_NODEPS</td>
 <td>LINUX_BASE_PREFERRED</td>
 </tr>
 <tr>
-<td>LINUX_BASE_REQUIRED</td>
+<td>LINK_RPATH_FLAG</td>
 <td>LINUX_LOCALES</td>
 </tr>
 <tr>
 <td>LOCALBASE</td>
 <td>LOCALBASE_LOCKTYPE</td>
 </tr>
 <tr>
 <td>LOCALPATCHES</td>
 <td>LOVE_DATA</td>
 </tr>
 <tr>
 <td>LOVE_GAME</td>
 <td>LOVE_VERSION</td>
 </tr>
 <tr>
 <td>LP32PLATFORMS</td>
 <td>LP64PLATFORMS</td>
 </tr>
 <tr>
 <td>LUA_BUSTED_ARGS</td>
 <td>LUA_CDIR</td>
 </tr>
 <tr>
 <td>LUA_COMPILER</td>
 <td>LUA_DOCDIR</td>
 </tr>
 <tr>
 <td>LUA_EXAMPLESDIR</td>
 <td>LUA_INCDIR</td>
 </tr>
 <tr>
 <td>LUA_INTERPRETER</td>
 <td>LUA_LDIR</td>
 </tr>
 <tr>
 <td>LUA_LINKER_MAGIC</td>
 <td>LUA_PKGPREFIX</td>
 </tr>
 <tr>
 <td>LUA_SELF_CONFLICT</td>
 <td>LUA_USE_BUSTED</td>
 </tr>
 <tr>
 <td>LUA_VERSIONS_ACCEPTED</td>
 <td>LUA_VERSIONS_INCOMPATIBLE</td>
 </tr>
 <tr>
 <td>LUA_VERSION_DEFAULT</td>
 <td>LUA_VERSION_REQD</td>
 </tr>
 <tr>
 <td>Lua</td>
 <td>MACHINE_PLATFORM</td>
 </tr>
 <tr>
 <td>MAILAGENT_DOMAIN</td>
 <td>MAILAGENT_EMAIL</td>
 </tr>
 <tr>
 <td>MAILAGENT_FQDN</td>
 <td>MAILAGENT_ORGANIZATION</td>
 </tr>
 <tr>
 <td>MAJORDOMO_HOMEDIR</td>
 <td>MAJOR_OS_VERSION</td>
 </tr>
 <tr>
 <td>MAKEINFO_ARGS</td>
 <td>MAKE_DIRS</td>
 </tr>
 <tr>
 <td>MAKE_DIRS</td>
 <td>MAKE_DIRS_PERMS</td>
 <td>MAKE_ENV</td>
 </tr>
 <tr>
 <td>MAKE_ENV</td>
 <td>MAKE_FILE</td>
 <td>MAKE_FLAGS</td>
 </tr>
 <tr>
 <td>MAKE_FLAGS</td>
 <td>MAKE_JOBS</td>
 <td>MAKE_JOBS_SAFE</td>
 </tr>
 <tr>
 <td>MAKE_JOBS_SAFE</td>
 <td>MAKE_PROGRAM</td>
 <td>MANCOMPRESSED_IF_MANZ</td>
 </tr>
 <tr>
 <td>MANCOMPRESSED_IF_MANZ</td>
 <td>MANINSTALL</td>
 <td>MANZ</td>
 </tr>
 <tr>
 <td>MANZ</td>
 <td>MASTER_SITES</td>
 <td>MASTER_SITE_BACKUP</td>
 </tr>
 <tr>
 <td>MASTER_SITE_BACKUP</td>
 <td>MASTER_SITE_LOCAL</td>
 <td>MASTER_SITE_MOZILLA</td>
 </tr>
 <tr>
 <td>MASTER_SITE_MOZILLA</td>
 <td>MASTER_SITE_OVERRIDE</td>
 <td>MASTER_SITE_PERL_CPAN</td>
 </tr>
 <tr>
 <td>MASTER_SITE_PERL_CPAN</td>
 <td>MASTER_SORT</td>
 <td>MASTER_SORT_RANDOM</td>
 </tr>
 <tr>
 <td>MASTER_SORT_RANDOM</td>
 <td>MASTER_SORT_REGEX</td>
 <td>MECAB_CHARSET</td>
 </tr>
 <tr>
 <td>MECAB_CHARSET</td>
 <td>MEDIATOMB_GROUP</td>
 <td>MEDIATOMB_USER</td>
 </tr>
 <tr>
 <td>MEDIATOMB_USER</td>
 <td>MIPSPROBASE</td>
 <td>MIREDO_GROUP</td>
 </tr>
 <tr>
 <td>MIREDO_GROUP</td>
 <td>MIREDO_USER</td>
 <td>MISSING_FEATURES</td>
 </tr>
 <tr>
 <td>MISSING_FEATURES</td>
 <td>MKDIR</td>
 <td>MKPIE_SUPPORTED</td>
 </tr>
 <tr>
 <td>MKPIE_SUPPORTED</td>
 <td>MLDONKEY_GROUP</td>
 <td>MLDONKEY_HOME</td>
 </tr>
 <tr>
 <td>MLDONKEY_HOME</td>
 <td>MLDONKEY_USER</td>
 <td>MONOTONE_GROUP</td>
 </tr>
 <tr>
 <td>MONOTONE_GROUP</td>
 <td>MONOTONE_USER</td>
 <td>MOTIFBASE</td>
 </tr>
 <tr>
 <td>MOTIFBASE</td>
 <td>MOTIF_TYPE</td>
 <td>MOTIF_TYPE_DEFAULT</td>
 </tr>
 <tr>
 <td>MOTIF_TYPE_DEFAULT</td>
 <td>MPI_TYPE</td>
 <td>MSGFMT_STRIP_MSGCTXT</td>
 </tr>
 <tr>
 <td>MSGFMT_STRIP_MSGCTXT</td>
 <td>MSGFMT_STRIP_MSGID_PLURAL</td>
 <td>MTOOLS_ENABLE_FLOPPYD</td>
 </tr>
 <tr>
-<td>MUST</td>
+<td>MTOOLS_ENABLE_FLOPPYD</td>
 <td>MV</td>
 </tr>
 <tr>
 <td>MYSQL_CHARSET</td>
 <td>MYSQL_DATADIR</td>
 </tr>
 <tr>
 <td>MYSQL_EXTRA_CHARSET</td>
 <td>MYSQL_GROUP</td>
 </tr>
 <tr>
 <td>MYSQL_USER</td>
 <td>MYSQL_VERSION</td>
 </tr>
 <tr>
 <td>MYSQL_VERSIONS_ACCEPTED</td>
 <td>MYSQL_VERSIONS_ALL</td>
 </tr>
 <tr>
 <td>MYSQL_VERSION_DEFAULT</td>
 <td>NAGIOSCMD_GROUP</td>
 </tr>
 <tr>
 <td>NAGIOSDIR</td>
 <td>NAGIOS_GROUP</td>
 </tr>
 <tr>
 <td>NAGIOS_USER</td>
 <td>NATIVE_APPEND_ABI</td>
 </tr>
 <tr>
 <td>NATIVE_APPEND_ELF</td>
 <td>NATIVE_EXEC_FMT</td>
 </tr>
 <tr>
 <td>NATIVE_MACHINE_PLATFORM</td>
 <td>NATIVE_OBJECT_FMT</td>
 </tr>
 <tr>
 <td>NBPAX_PROGRAM_PREFIX</td>
 <td>NETBSD_LOGIN_NAME</td>
 </tr>
 <tr>
 <td>NMH_EDITOR</td>
 <td>NMH_MTA</td>
 </tr>
 <tr>
 <td>NMH_PAGER</td>
 <td>NODE_VERSIONS_ACCEPTED</td>
 </tr>
 <tr>
 <td>NODE_VERSIONS_INCOMPATIBLE</td>
 <td>NODE_VERSION_DEFAULT</td>
 </tr>
 <tr>
 <td>NODE_VERSION_REQD</td>
 <td>NOLOGIN</td>
 </tr>
 <tr>
 <td>NOTE</td>
 <td>NOT_FOR_PLATFORM</td>
 </tr>
 <tr>
 <td>NOT_PAX_ASLR_SAFE</td>
 <td>NOT_PAX_MPROTECT_SAFE</td>
 </tr>
 <tr>
 <td>NO_BUILD</td>
 <td>NO_CHECKSUM</td>
 </tr>
 <tr>
 <td>NO_CONFIGURE</td>
 <td>NO_SKIP</td>
 </tr>
 <tr>
 <td>NS_PREFERRED</td>
 <td>NULLMAILER_GROUP</td>
 </tr>
 <tr>
 <td>NULLMAILER_USER</td>
 <td>OASIS</td>
 </tr>
 <tr>
 <td>OASIS_BUILD_ARGS</td>
 <td>OBJHOSTNAME</td>
 </tr>
 <tr>
 <td>OBJMACHINE</td>
 <td>OCAML_FINDLIB_DIRS</td>
 </tr>
 <tr>
 <td>OCAML_FINDLIB_REGISTER</td>
 <td>OCAML_FINDLIB_REGISTER_VERBOSE</td>
 </tr>
 <tr>
 <td>OCAML_SITELIBDIR</td>
 <td>OCAML_TOPKG_DOCDIR</td>
 </tr>
 <tr>
 <td>OCAML_USE_DUNE</td>
 <td>OCAML_USE_FINDLIB</td>
 </tr>
 <tr>
 <td>OCAML_USE_OASIS</td>
 <td>OCAML_USE_OASIS_DYNRUN</td>
 </tr>
 <tr>
 <td>OCAML_USE_OPAM</td>
 <td>OCAML_USE_OPT_COMPILER</td>
 </tr>
 <tr>
 <td>OCAML_USE_TOPKG</td>
 <td>OMF</td>
 </tr>
 <tr>
 <td>OMF</td>
 <td>ONLY_FOR_COMPILER</td>
 <td>ONLY_FOR_PLATFORM</td>
 </tr>
 <tr>
 <td>ONLY_FOR_PLATFORM</td>
 <td>OPENSSH_CHROOT</td>
 <td>OPENSSH_GROUP</td>
 </tr>
 <tr>
 <td>OPENSSH_GROUP</td>
 <td>OPENSSH_USER</td>
 <td>OPSYS</td>
 </tr>
 <tr>
 <td>OPSYS</td>
 <td>OPSYS_EMULDIR</td>
 <td>OPSYS_VERSION</td>
 </tr>
 <tr>
 <td>OPSYS_VERSION</td>
 <td>OS</td>
 <td>OSS_TYPE</td>
 </tr>
 <tr>
 <td>OSS_TYPE</td>
 <td>OSX</td>
 <td>OSX_TOLERATE_SDK_SKEW</td>
 </tr>
 <tr>
 <td>OS_HAVE_ALSA</td>
 <td>OS_HAVE_RCD</td>
 </tr>
 <tr>
 <td>OSX_TOLERATE_SDK_SKEW</td>
 <td>OS_VARIANT</td>
 <td>OS_VERSION</td>
 </tr>
 <tr>
 <td>OS_VERSION</td>
 <td>OTF_FONTS_DIR</td>
 <td>OVERRIDE_DIRDEPTH</td>
 </tr>
 <tr>
 <td>OVERRIDE_DIRDEPTH</td>
 <td>OVERRIDE_GEMSPEC</td>
 <td>OVERRIDE_GNU_CONFIG_SCRIPTS</td>
 </tr>
 <tr>
-<td>OVERRIDE_ROCKSPEC</td>
+<td>OVERRIDE_GNU_CONFIG_SCRIPTS</td>
 <td>OWN_DIRS</td>
 </tr>
 <tr>
 <td>OWN_DIRS_PERMS</td>
 <td>P4GROUP</td>
 </tr>
 <tr>
 <td>P4PORT</td>
 <td>P4ROOT</td>
 </tr>
 <tr>
 <td>P4USER</td>
 <td>PACKAGES</td>
 </tr>
 <tr>
 <td>PALMOS_DEFAULT_SDK</td>
 <td>PAMBASE</td>
 </tr>
 <tr>
 <td>PAM_DEFAULT</td>
 <td>PAPERSIZE</td>
 </tr>
 <tr>
 <td>PASSIVE_FETCH</td>
 <td>PATCHDIR</td>
 </tr>
 <tr>
 <td>PATCHFILES</td>
 <td>PATCH_ARGS</td>
 </tr>
 <tr>
 <td>PATCH_DEBUG</td>
 <td>PATCH_DIST_ARGS</td>
 </tr>
 <tr>
 <td>PATCH_DIST_CAT</td>
 <td>PATCH_DIST_STRIP</td>
 </tr>
 <tr>
 <td>PATCH_FUZZ_FACTOR</td>
 <td>PATCH_STRIP</td>
 </tr>
 <tr>
 <td>PATH</td>
 <td>PCCBASE</td>
 </tr>
 <tr>
 <td>PEAR</td>
 <td>PEAR_CHANNEL</td>
 </tr>
 <tr>
 <td>PEAR_CHANNEL_ALIAS</td>
 <td>PEAR_CHANNEL_VERSION</td>
 </tr>
 <tr>
 <td>PEAR_CMD</td>
 <td>PEAR_LIB</td>
 </tr>
 <tr>
 <td>PEAR_PACKAGE_XML</td>
 <td>PERL5</td>
 </tr>
 <tr>
 <td>PERL5_CONFIGURE</td>
 <td>PERL5_CONFIGURE_DIRS</td>
 </tr>
 <tr>
 <td>PERL5_LDFLAGS</td>
 <td>PERL5_LICENSE</td>
 </tr>
 <tr>
 <td>PERL5_MODULE_TYPE</td>
 <td>PERL5_PACKLIST</td>
 </tr>
 <tr>
 <td>PERL5_PACKLIST_DIR</td>
 <td>PERL5_PERLBASE</td>
 </tr>
 <tr>
 <td>PERL5_SITEBASE</td>
 <td>PERL5_USE_PACKLIST</td>
 </tr>
 <tr>
 <td>PERL5_VENDORBASE</td>
 <td>PFCTL</td>
 </tr>
 <tr>
 <td>PFVAR_H</td>
 <td>PF_VERSION</td>
 </tr>
 <tr>
 <td>PGGROUP</td>
 <td>PGHOME</td>
 </tr>
 <tr>
 <td>PGPKGSRCDIR</td>
 <td>PGSQL_TYPE</td>
 </tr>
 <tr>
 <td>PGSQL_VERSION</td>
 <td>PGSQL_VERSIONS_ACCEPTED</td>
 </tr>
 <tr>
 <td>PGSQL_VERSION_DEFAULT</td>
 <td>PGUSER</td>
 </tr>
 <tr>
 <td>PG_LIB_EXT</td>
 <td>PHP</td>
 </tr>
 <tr>
 <td>PHPCOMMON_MK</td>
 <td>PHPPKGSRCDIR</td>
 </tr>
 <tr>
 <td>PHP_BASE_VERS</td>
 <td>PHP_CHECK_INSTALLED</td>
 </tr>
 <tr>
 <td>PHP_EXTENSION_DIR</td>
 <td>PHP_INITIAL_TEENY</td>
 </tr>
 <tr>
 <td>PHP_PKG_PREFIX</td>
 <td>PHP_VERSION</td>
 </tr>
 <tr>
 <td>PHP_VERSIONS_ACCEPTED</td>
 <td>PHP_VERSIONS_INCOMPATIBLE</td>
 </tr>
 <tr>
 <td>PHP_VERSION_DEFAULT</td>
 <td>PHP_VERSION_REQD</td>
 </tr>
 <tr>
 <td>PILRC_USE_GTK</td>
 <td>PKGCONFIG_BASE</td>
 </tr>
 <tr>
 <td>PKGCONFIG_FILE</td>
 <td>PKGCONFIG_OVERRIDE</td>
 </tr>
 <tr>
 <td>PKGCONFIG_OVERRIDE_STAGE</td>
 <td>PKGDIR</td>
 </tr>
 <tr>
 <td>PKGGNUDIR</td>
 <td>PKGINFODIR</td>
 </tr>
 <tr>
 <td>PKGLOCALEDIR</td>
 <td>PKGMANDIR</td>
 </tr>
 <tr>
 <td>PKGNAME</td>
 <td>PKGNAME_REQD</td>
 </tr>
 <tr>
 <td>PKGPATH</td>
 <td>PKGREVISION</td>
 </tr>
 <tr>
 <td>PKGSRC_BLAS_TYPES</td>
 <td>PKGSRC_CHANGES</td>
 </tr>
 <tr>
 <td>PKGSRC_COMPILER</td>
 <td>PKGSRC_KEEP_BIN_PKGS</td>
 </tr>
 <tr>
 <td>PKGSRC_LOCKTYPE</td>
 <td>PKGSRC_MAKE_ENV</td>
 </tr>
 <tr>
 <td>PKGSRC_MESSAGE_RECIPIENTS</td>
 <td>PKGSRC_MKPIE</td>
 </tr>
 <tr>
 <td>PKGSRC_MKREPRO</td>
 <td>PKGSRC_OVERRIDE_MKPIE</td>
 </tr>
 <tr>
 <td>PKGSRC_RUN_TEST</td>
 <td>PKGSRC_SETENV</td>
 </tr>
 <tr>
 <td>PKGSRC_SLEEPSECS</td>
 <td>PKGSRC_TODO</td>
 </tr>
 <tr>
 <td>PKGSRC_USE_CTF</td>
 <td>PKGSRC_USE_FORTIFY</td>
 </tr>
 <tr>
 <td>PKGSRC_USE_RELRO</td>
 <td>PKGSRC_USE_SSP</td>
 </tr>
 <tr>
 <td>PKGSRC_USE_STACK_CHECK</td>
 <td>PKGTASKS_DATAFILE</td>
 </tr>
 <tr>
 <td>PKGTOOLS_ARGS</td>
 <td>PKGTOOLS_ENV</td>
 </tr>
 <tr>
 <td>PKG_ALTERNATIVES</td>
 <td>PKG_APACHE</td>
 </tr>
 <tr>
 <td>PKG_APACHE_ACCEPTED</td>
 <td>PKG_APACHE_DEFAULT</td>
 </tr>
 <tr>
 <td>PKG_BEST_EXISTS</td>
 <td>PKG_BUILD_OPTIONS</td>
 </tr>
 <tr>
 <td>PKG_COMPRESSION</td>
 <td>PKG_CONFIG</td>
 </tr>
 <tr>
 <td>PKG_CONFIG_PERMS</td>
 <td>PKG_CREATE_USERGROUP</td>
 </tr>
 <tr>
 <td>PKG_DB_TMPDIR</td>
 <td>PKG_DEBUG_LEVEL</td>
 </tr>
 <tr>
 <td>PKG_DEFAULT_OPTIONS</td>
 <td>PKG_DESTDIR_SUPPORT</td>
 </tr>
 <tr>
 <td>PKG_DEVELOPER</td>
 <td>PKG_DISABLED_OPTIONS</td>
 </tr>
 <tr>
 <td>PKG_FATAL_ERRORS</td>
 <td>PKG_FC</td>
 </tr>
 <tr>
 <td>PKG_FILELIST_CMD</td>
 <td>PKG_GECOS</td>
 </tr>
 <tr>
 <td>PKG_GID</td>
 <td>PKG_GROUPS</td>
 </tr>
 <tr>
 <td>PKG_GROUPS_VARS</td>
 <td>PKG_HOME</td>
 </tr>
 <tr>
 <td>PKG_INIT_SCRIPTS</td>
 <td>PKG_JAVA_HOME</td>
 </tr>
 <tr>
 <td>PKG_JVM</td>
 <td>PKG_JVMS_ACCEPTED</td>
 </tr>
 <tr>
 <td>PKG_JVM_DEFAULT</td>
 <td>PKG_LEGACY_OPTIONS</td>
 </tr>
 <tr>
 <td>PKG_LIBTOOL</td>
 <td>PKG_OPTIONS</td>
 </tr>
 <tr>
 <td>PKG_OPTIONS_DEPRECATED_WARNINGS</td>
 <td>PKG_OPTIONS_LEGACY_OPTS</td>
 </tr>
 <tr>
 <td>PKG_OPTIONS_LEGACY_VARS</td>
 <td>PKG_OPTIONS_NONEMPTY_SETS</td>
 </tr>
 <tr>
 <td>PKG_OPTIONS_OPTIONAL_GROUPS</td>
 <td>PKG_OPTIONS_REQUIRED_GROUPS</td>
 </tr>
 <tr>
 <td>PKG_OPTIONS_VAR</td>
 <td>PKG_PHP</td>
 </tr>
 <tr>
 <td>PKG_PHP_MAJOR_VERS</td>
 <td>PKG_PHP_VERSION</td>
 </tr>
 <tr>
 <td>PKG_RCD_SCRIPTS</td>
 <td>PKG_REFCOUNT_DBDIR</td>
 </tr>
 <tr>
 <td>PKG_REGISTER_SHELLS</td>
 <td>PKG_RESUME_TRANSFERS</td>
 </tr>
 <tr>
 <td>PKG_SHELL</td>
 <td>PKG_SUGGESTED_OPTIONS</td>
 </tr>
 <tr>
 <td>PKG_SUPPORTED_OPTIONS</td>
 <td>PKG_SYSCONFBASE</td>
 </tr>
 <tr>
 <td>PKG_SYSCONFBASEDIR</td>
 <td>PKG_SYSCONFDIR</td>
 </tr>
 <tr>
 <td>PKG_SYSCONFDIR_PERMS</td>
 <td>PKG_SYSCONFSUBDIR</td>
 </tr>
 <tr>
 <td>PKG_SYSCONFVAR</td>
 <td>PKG_TOOLS_BIN</td>
 </tr>
 <tr>
 <td>PKG_UID</td>
 <td>PKG_UPDATE_FONTS_DB</td>
 </tr>
 <tr>
 <td>PKG_USERS</td>
 <td>PKG_USERS_VARS</td>
 </tr>
 <tr>
 <td>PKG_VERBOSE</td>
 <td>PLEASE</td>
 </tr>
 <tr>
 <td>PLIST</td>
 <td>PLIST_AWK</td>
 </tr>
 <tr>
 <td>PLIST_AWK_ENV</td>
 <td>PLIST_SRC</td>
 </tr>
 <tr>
 <td>PLIST_SUBST</td>
 <td>PLIST_TYPE</td>
 </tr>
 <tr>
 <td>PLIST_VARS</td>
 <td>POPTOP_USE_MPPE</td>
 </tr>
 <tr>
 <td>POSSIBLE_GFORTRAN_VERSION</td>
 <td>POST_FETCH_HOOK</td>
 </tr>
 <tr>
 <td>PREFER</td>
 <td>PREFER_NATIVE</td>
 </tr>
 <tr>
 <td>PREFER_NATIVE_PTHREADS</td>
 <td>PREFER_PKGSRC</td>
 </tr>
 <tr>
 <td>PREFIX</td>
 <td>PREPEND_PATH</td>
 </tr>
 <tr>
 <td>PRE_ROOT_CMD</td>
 <td>PRIVILEGED_STAGES</td>
 </tr>
 <tr>
 <td>PS</td>
 <td>PTHREAD_AUTO_VARS</td>
 </tr>
 <tr>
 <td>PTHREAD_CFLAGS</td>
 <td>PTHREAD_LDFLAGS</td>
 </tr>
 <tr>
 <td>PTHREAD_LIBS</td>
 <td>PTHREAD_OPTS</td>
 </tr>
 <tr>
 <td>PTHREAD_TYPE</td>
 <td>PVM_SSH</td>
 </tr>
 <tr>
 <td>PYPKGPREFIX</td>
 <td>PYTHON_FOR_BUILD_ONLY</td>
 </tr>
 <tr>
 <td>PYTHON_SELF_CONFLICT</td>
 <td>PYTHON_VERSIONED_DEPENDENCIES</td>
 </tr>
 <tr>
 <td>PYTHON_VERSIONS_ACCEPTED</td>
 <td>PYTHON_VERSIONS_INCOMPATIBLE</td>
 </tr>
 <tr>
 <td>PYTHON_VERSION_DEFAULT</td>
 <td>PYTHON_VERSION_REQD</td>
 </tr>
 <tr>
 <td>PYVERSSUFFIX</td>
 <td>QMAILDIR</td>
 </tr>
 <tr>
 <td>QMAIL_ALIAS_USER</td>
 <td>QMAIL_DAEMON_USER</td>
 </tr>
 <tr>
 <td>QMAIL_LOG_USER</td>
 <td>QMAIL_NOFILES_GROUP</td>
 </tr>
 <tr>
 <td>QMAIL_PASSWD_USER</td>
 <td>QMAIL_QMAIL_GROUP</td>
 </tr>
 <tr>
 <td>QMAIL_QUEUE_DIR</td>
 <td>QMAIL_QUEUE_EXTRA</td>
 </tr>
 <tr>
 <td>QMAIL_QUEUE_USER</td>
 <td>QMAIL_REMOTE_USER</td>
 </tr>
 <tr>
 <td>QMAIL_ROOT_USER</td>
 <td>QMAIL_SEND_USER</td>
 </tr>
 <tr>
 <td>QORE_LATEST_MODULE_API</td>
 <td>QORE_MODULE_API</td>
 </tr>
 <tr>
 <td>QORE_MODULE_DIR</td>
 <td>QORE_USER_MODULE_DIR</td>
 </tr>
 <tr>
 <td>QORE_VERSION</td>
 <td>QPOPPER_FAC</td>
 </tr>
 <tr>
 <td>QPOPPER_SPOOL_DIR</td>
 <td>QPOPPER_USER</td>
 </tr>
 <tr>
 <td>RAKE_NAME</td>
 <td>RASMOL_DEPTH</td>
 </tr>
 <tr>
 <td>RCD_DIR</td>
 <td>RCD_ORDER</td>
 </tr>
 <tr>
 <td>RCD_SCRIPTS</td>
 <td>RCD_SCRIPTS_DIR</td>
 </tr>
 <tr>
 <td>RCD_SCRIPTS_EXAMPLEDIR</td>
 <td>RCD_SCRIPTS_MODE</td>
 </tr>
 <tr>
 <td>RCD_SCRIPTS_SHELL</td>
 <td>RCD_SCRIPT_SRC</td>
 </tr>
 <tr>
 <td>RCD_SUBR</td>
 <td>RDOC</td>
 </tr>
 <tr>
 <td>READLINE_DEFAULT</td>
 <td>READLINE_TYPE</td>
 </tr>
 <tr>
 <td>READLINE_TYPE</td>
 <td>REAL_ROOT_GROUP</td>
 <td>REAL_ROOT_USER</td>
 </tr>
 <tr>
 <td>REAL_ROOT_USER</td>
 <td>RECURSIVE_MAKE</td>
 <td>RELAY_CTRL_DIR</td>
 </tr>
 <tr>
 <td>RELAY_CTRL_DIR</td>
 <td>RELRO_SUPPORTED</td>
 <td>REPLACE_AWK</td>
 </tr>
 <tr>
 <td>REPLACE_AWK</td>
 <td>REPLACE_BASH</td>
 <td>REPLACE_CSH</td>
 </tr>
 <tr>
 <td>REPLACE_CSH</td>
 <td>REPLACE_KSH</td>
 <td>REPLACE_LUA</td>
 </tr>
 <tr>
 <td>REPLACE_LUA</td>
 <td>REPLACE_NODEJS</td>
 <td>REPLACE_OCTAVE</td>
 </tr>
 <tr>
 <td>REPLACE_OCTAVE</td>
 <td>REPLACE_PERL</td>
 <td>REPLACE_PERL6</td>
 </tr>
 <tr>
 <td>REPLACE_PERL6</td>
 <td>REPLACE_PHP</td>
 <td>REPLACE_PYTHON</td>
 </tr>
 <tr>
 <td>REPLACE_PYTHON</td>
 <td>REPLACE_QORE</td>
 <td>REPLACE_R</td>
 </tr>
 <tr>
 <td>REPLACE_R</td>
 <td>REPLACE_RUBY</td>
 <td>REPLACE_RUBY_DIRS</td>
 </tr>
 <tr>
 <td>REPLACE_RUBY_DIRS</td>
 <td>REPLACE_RUBY_PAT</td>
 <td>REPLACE_SH</td>
 </tr>
 <tr>
 <td>REPLACE_SH</td>
 <td>REPLACE_TEXLUA</td>
 <td>REPLACE_WISH</td>
 </tr>
 <tr>
 <td>REPLACE_WISH</td>
 <td>REQD_DIRS</td>
 <td>REQD_DIRS_PERMS</td>
 </tr>
 <tr>
 <td>REQD_DIRS_PERMS</td>
 <td>REQD_FILES</td>
 <td>REQD_FILES_MODE</td>
 </tr>
 <tr>
 <td>REQD_FILES_MODE</td>
 <td>REQD_FILES_PERMS</td>
 <td>RESOLV_AUTO_VARS</td>
 </tr>
 <tr>
 <td>RESOLV_AUTO_VARS</td>
 <td>RESOLV_LDFLAGS</td>
 <td>RESOLV_LIBS</td>
 </tr>
 <tr>
 <td>RESOLV_LIBS</td>
 <td>RM</td>
 <td>ROCKSPEC_NAME</td>
 </tr>
 <tr>
 <td>ROCKSPEC_SPECFILE</td>
 <td>ROOT_CMD</td>
 </tr>
 <tr>
 <td>ROOT_GROUP</td>
 <td>ROOT_USER</td>
 </tr>
 <tr>
 <td>ROOT_USER</td>
 <td>RPCGEN</td>
 <td>RPM</td>
 </tr>
 <tr>
 <td>RPM</td>
 <td>RPM2PKG_PLIST</td>
 <td>RPM2PKG_PREFIX</td>
 </tr>
 <tr>
 <td>RPM2PKG_PREFIX</td>
 <td>RPM2PKG_STAGE</td>
 <td>RPM2PKG_STRIP</td>
 </tr>
 <tr>
 <td>RPM2PKG_STRIP</td>
 <td>RPM2PKG_SUBPREFIX</td>
 <td>RPMFILES</td>
 </tr>
 <tr>
 <td>RPMFILES</td>
 <td>RPMIGNOREPATH</td>
 <td>RPM_DB_PREFIX</td>
 </tr>
 <tr>
 <td>RPM_DB_PREFIX</td>
 <td>RSSH_CVS_PATH</td>
 <td>RSSH_RDIST_PATH</td>
 </tr>
 <tr>
 <td>RSSH_RDIST_PATH</td>
 <td>RSSH_RSYNC_PATH</td>
 <td>RSSH_SCP_PATH</td>
 </tr>
 <tr>
 <td>RSSH_SCP_PATH</td>
 <td>RSSH_SFTP_SERVER_PATH</td>
 <td>RUBY</td>
 </tr>
 <tr>
 <td>RUBY</td>
 <td>RUBYGEM</td>
 <td>RUBYGEM_NAME</td>
 </tr>
 <tr>
 <td>RUBYGEM_NAME</td>
 <td>RUBYGEM_OPTIONS</td>
 <td>RUBYGEM_VERBOSE</td>
 </tr>
 <tr>
 <td>RUBYGEM_VERBOSE</td>
 <td>RUBY_ABI_VERSION</td>
 <td>RUBY_ARCH</td>
 </tr>
 <tr>
 <td>RUBY_ARCH</td>
 <td>RUBY_ARCHINC</td>
 <td>RUBY_ARCHLIB</td>
 </tr>
 <tr>
 <td>RUBY_ARCHLIB</td>
 <td>RUBY_BASE</td>
 <td>RUBY_BASERIDIR</td>
 </tr>
 <tr>
 <td>RUBY_BASERIDIR</td>
 <td>RUBY_BUILD_DOCUMENT</td>
 <td>RUBY_DLEXT</td>
 </tr>
 <tr>
 <td>RUBY_DLEXT</td>
 <td>RUBY_DOC</td>
 <td>RUBY_DYNAMIC_DIRS</td>
 </tr>
 <tr>
 <td>RUBY_DYNAMIC_DIRS</td>
 <td>RUBY_EG</td>
 <td>RUBY_ENCODING_ARG</td>
 </tr>
 <tr>
 <td>RUBY_ENCODING_ARG</td>
 <td>RUBY_EXTCONF</td>
 <td>RUBY_EXTCONF_CHECK</td>
 </tr>
 <tr>
 <td>RUBY_EXTCONF_CHECK</td>
 <td>RUBY_EXTCONF_DEBUG</td>
 <td>RUBY_EXTCONF_MAKEFILE</td>
 </tr>
 <tr>
 <td>RUBY_EXTCONF_MAKEFILE</td>
 <td>RUBY_GEM_ARCH</td>
 <td>RUBY_GEM_BASE</td>
 </tr>
 <tr>
 <td>RUBY_GEM_BASE</td>
 <td>RUBY_INC</td>
 <td>RUBY_LIB</td>
 </tr>
 <tr>
 <td>RUBY_LIB</td>
 <td>RUBY_LIB_BASE</td>
 <td>RUBY_NAME</td>
 </tr>
 <tr>
 <td>RUBY_NAME</td>
 <td>RUBY_NOVERSION</td>
 <td>RUBY_PKGPREFIX</td>
 </tr>
 <tr>
 <td>RUBY_PKGPREFIX</td>
 <td>RUBY_RAILS</td>
 <td>RUBY_RAILS52_VERSION</td>
 </tr>
 <tr>
 <td>RUBY_RAILS52_VERSION</td>
 <td>RUBY_RAILS60_VERSION</td>
 <td>RUBY_RAILS61_VERSION</td>
 </tr>
 <tr>
 <td>RUBY_RAILS61_VERSION</td>
 <td>RUBY_RAILS70_VERSION</td>
 <td>RUBY_RAILS_ACCEPTED</td>
 </tr>
 <tr>
 <td>RUBY_RAILS_ACCEPTED</td>
 <td>RUBY_RAILS_DEFAULT</td>
 <td>RUBY_RAILS_REQD</td>
 </tr>
 <tr>
 <td>RUBY_RAILS_REQD</td>
 <td>RUBY_RAILS_STRICT_DEP</td>
 <td>RUBY_RIDIR</td>
 </tr>
 <tr>
 <td>RUBY_RIDIR</td>
 <td>RUBY_SETUP</td>
 <td>RUBY_SHLIB</td>
 </tr>
 <tr>
 <td>RUBY_SHLIB</td>
 <td>RUBY_SHLIBALIAS</td>
 <td>RUBY_SHLIBVER</td>
 </tr>
 <tr>
 <td>RUBY_SHLIBVER</td>
 <td>RUBY_SIMPLE_INSTALL</td>
 <td>RUBY_SITEARCHLIB</td>
 </tr>
 <tr>
 <td>RUBY_SITEARCHLIB</td>
 <td>RUBY_SITELIB</td>
 <td>RUBY_SITELIB_BASE</td>
 </tr>
 <tr>
 <td>RUBY_SITELIB_BASE</td>
 <td>RUBY_SITERIDIR</td>
 <td>RUBY_SLEXT</td>
 </tr>
 <tr>
 <td>RUBY_SLEXT</td>
 <td>RUBY_SRCDIR</td>
 <td>RUBY_STATICLIB</td>
 </tr>
 <tr>
 <td>RUBY_STATICLIB</td>
 <td>RUBY_SUFFIX</td>
 <td>RUBY_SYSRIDIR</td>
 </tr>
 <tr>
 <td>RUBY_SYSRIDIR</td>
 <td>RUBY_USE_PTHREAD</td>
 <td>RUBY_VENDORARCHLIB</td>
 </tr>
 <tr>
 <td>RUBY_VENDORARCHLIB</td>
 <td>RUBY_VENDORLIB</td>
 <td>RUBY_VENDORLIB_BASE</td>
 </tr>
 <tr>
 <td>RUBY_VENDORLIB_BASE</td>
 <td>RUBY_VER</td>
 <td>RUBY_VERSION</td>
 </tr>
 <tr>
 <td>RUBY_VERSION</td>
 <td>RUBY_VERSIONS_ACCEPTED</td>
 <td>RUBY_VERSIONS_INCOMPATIBLE</td>
 </tr>
 <tr>
 <td>RUBY_VERSIONS_INCOMPATIBLE</td>
 <td>RUBY_VERSION_DEFAULT</td>
 <td>RUBY_VERSION_REQD</td>
 </tr>
 <tr>
 <td>RUBY_VERSION_REQD</td>
 <td>RUBY_VER_DIR</td>
 <td>RUN</td>
 </tr>
 <tr>
 <td>RUN</td>
 <td>RUN_LDCONFIG</td>
 <td>RUST_TYPE</td>
 </tr>
 <tr>
 <td>RUST_TYPE</td>
 <td>SCO</td>
 <td>SCREWS_GROUP</td>
 </tr>
 <tr>
 <td>SCREWS_GROUP</td>
 <td>SCREWS_USER</td>
 <td>SCRIPTS_ENV</td>
 </tr>
 <tr>
 <td>SCRIPTS_ENV</td>
 <td>SCROLLKEEPER_DATADIR</td>
 <td>SCROLLKEEPER_REBUILDDB</td>
 </tr>
 <tr>
 <td>SCROLLKEEPER_REBUILDDB</td>
 <td>SCROLLKEEPER_UPDATEDB</td>
 <td>SDIST_PAWD</td>
 </tr>
 <tr>
 <td>SDIST_PAWD</td>
 <td>SDL12_TYPE</td>
 <td>SERIAL_DEVICES</td>
 </tr>
 <tr>
 <td>SERIAL_DEVICES</td>
 <td>SETGIDGAME</td>
 <td>SETGID_GAMES_PERMS</td>
 </tr>
 <tr>
 <td>SETGID_GAMES_PERMS</td>
 <td>SETUID_ROOT_PERMS</td>
 <td>SH</td>
 </tr>
 <tr>
 <td>SH</td>
 <td>SHLIB</td>
 <td>SHORTNAME</td>
 </tr>
 <tr>
 <td>SIGN_PACKAGES</td>
 <td>SILC_CLIENT_WITH_PERL</td>
 </tr>
 <tr>
 <td>SITE_SPECIFIC_PKGS</td>
 <td>SKIP_DEPENDS</td>
 </tr>
 <tr>
 <td>SMF_INSTANCES</td>
 <td>SMF_MANIFEST</td>
 </tr>
 <tr>
 <td>SMF_METHODS</td>
 <td>SMF_METHOD_SHELL</td>
 </tr>
 <tr>
 <td>SMF_METHOD_SRC</td>
 <td>SMF_NAME</td>
 </tr>
 <tr>
 <td>SMF_PREFIX</td>
 <td>SMF_SRCDIR</td>
 </tr>
 <tr>
 <td>SNIPROXY_GROUP</td>
 <td>SNIPROXY_USER</td>
 </tr>
 <tr>
 <td>SOURCE_BUFFSIZE</td>
 <td>SPECIAL_PERMS</td>
 </tr>
 <tr>
 <td>SPECIFIC_PKGS</td>
 <td>SSH_SUID</td>
 </tr>
 <tr>
 <td>SSP_SUPPORTED</td>
 <td>SSYNC_PAWD</td>
 </tr>
 <tr>
 <td>STEP_MSG</td>
 <td>STRIP</td>
 </tr>
 <tr>
 <td>STRIP_DBG</td>
 <td>STRIP_DEBUG</td>
 </tr>
 <tr>
 <td>STRIP_DEBUG_SUPPORTED</td>
 <td>STRIP_FILES_SKIP</td>
 </tr>
 <tr>
 <td>SU</td>
 <td>SUBDIR</td>
 </tr>
 <tr>
 <td>SUBST</td>
 <td>SUBST_CLASSES</td>
 </tr>
 <tr>
 <td>SUBST_FILES</td>
 <td>SUBST_FILTER_CMD</td>
 </tr>
 <tr>
 <td>SUBST_MESSAGE</td>
 <td>SUBST_NOOP_OK</td>
 </tr>
 <tr>
 <td>SUBST_SED</td>
 <td>SUBST_SHOW_DIFF</td>
 </tr>
 <tr>
 <td>SUBST_SKIP_TEXT_CHECK</td>
 <td>SUBST_STAGE</td>
 </tr>
 <tr>
 <td>SUBST_VARS</td>
 <td>SUNWSPROBASE</td>
 </tr>
 <tr>
 <td>SUSE_PREFER</td>
 <td>SU_CMD</td>
 </tr>
 <tr>
 <td>SVN_EXTRACTDIR</td>
 <td>SVN_REPO</td>
 </tr>
 <tr>
 <td>SVN_REPOSITORIES</td>
 <td>SVN_REVISION</td>
 </tr>
 <tr>
 <td>SYSCONFBASE</td>
 <td>TARGET_ARCH</td>
 </tr>
 <tr>
 <td>TBL</td>
 <td>TERMCAP_TYPE</td>
 </tr>
 <tr>
 <td>TERMINFO_DEFAULT</td>
 <td>TERMINFO_TYPE</td>
 </tr>
 <tr>
 <td>TEST</td>
 <td>TEST_DEPENDS</td>
 </tr>
 <tr>
 <td>TEST_DIRS</td>
 <td>TEST_ENV</td>
 </tr>
 <tr>
 <td>TEST_ENV_SHELL</td>
 <td>TEST_MAKE_CMD</td>
 </tr>
 <tr>
 <td>TEST_MAKE_FLAGS</td>
 <td>TEST_TARGET</td>
 </tr>
 <tr>
 <td>TEXLIVE_IGNORE_PATTERNS</td>
 <td>TEXLIVE_REV</td>
 </tr>
 <tr>
 <td>TEXLIVE_UNVERSIONED</td>
 <td>TEXMFSITE</td>
 </tr>
 <tr>
 <td>TEX_FORMATS</td>
 <td>TEX_HYPHEN_DAT</td>
 </tr>
 <tr>
 <td>TEX_HYPHEN_DEF</td>
 <td>TEX_TEXMF_DIRS</td>
 </tr>
 <tr>
 <td>THTTPD_LOG_FACILITY</td>
 <td>TINYDYN_USER</td>
 </tr>
 <tr>
 <td>TLSWRAPPER_CHROOT</td>
 <td>TO</td>
 </tr>
 <tr>
 <td>TOOLS_ALIASES</td>
 <td>TOOLS_ALWAYS_WRAP</td>
 </tr>
 <tr>
 <td>TOOLS_ARGS</td>
 <td>TOOLS_BROKEN</td>
 </tr>
 <tr>
 <td>TOOLS_CMD</td>
 <td>TOOLS_CMDLINE_SED</td>
 </tr>
 <tr>
 <td>TOOLS_CREATE</td>
 <td>TOOLS_CROSS_DESTDIR</td>
 </tr>
 <tr>
 <td>TOOLS_DIR</td>
 <td>TOOLS_FAIL</td>
 </tr>
 <tr>
 <td>TOOLS_GNU_MISSING</td>
 <td>TOOLS_LDCONFIG</td>
 </tr>
 <tr>
 <td>TOOLS_NOOP</td>
 <td>TOOLS_PATH</td>
 </tr>
 <tr>
 <td>TOOLS_SCRIPT</td>
 <td>TOOLS_USE_CROSS_COMPILE</td>
 </tr>
 <tr>
 <td>TOOL_DEPENDS</td>
 <td>TTF_FONTDIR</td>
 </tr>
 <tr>
 <td>TTF_FONTS_DIR</td>
 <td>TYPE</td>
 </tr>
 <tr>
 <td>TYPE</td>
 <td>UAC_REQD_EXECS</td>
 <td>UCSPI_SSL_GROUP</td>
 </tr>
 <tr>
 <td>UCSPI_SSL_GROUP</td>
 <td>UCSPI_SSL_USER</td>
 <td>UNLIMIT_RESOURCES</td>
 </tr>
 <tr>
 <td>UNLIMIT_RESOURCES</td>
 <td>UNPRIVILEGED</td>
 <td>UNPRIVILEGED_GROUP</td>
 </tr>
 <tr>
 <td>UNPRIVILEGED_GROUP</td>
 <td>UNPRIVILEGED_GROUPS</td>
 <td>UNPRIVILEGED_USER</td>
 </tr>
 <tr>
 <td>UNPRIVILEGED_USER</td>
 <td>UNWRAP_FILES</td>
 <td>UNWRAP_PATTERNS</td>
 </tr>
 <tr>
 <td>UNWRAP_PATTERNS</td>
 <td>UPDATE_GEMSPEC</td>
 <td>UPDATE_TARGET</td>
 </tr>
 <tr>
 <td>UPDATE_TARGET</td>
 <td>URI</td>
 <td>USERGROUP_PHASE</td>
 </tr>
 <tr>
 <td>USERGROUP_PHASE</td>
 <td>USERPPP_GROUP</td>
 <td>USER_SPECIFIC_PKGS</td>
 </tr>
 <tr>
 <td>USER_SPECIFIC_PKGS</td>
 <td>USE_ABI_DEPENDS</td>
 <td>USE_APR</td>
 </tr>
 <tr>
 <td>USE_APR</td>
 <td>USE_BSD_MAKEFILE</td>
 <td>USE_BUILTIN</td>
 </tr>
 <tr>
 <td>USE_BUILTIN</td>
 <td>USE_CROSS_COMPILE</td>
 <td>USE_CURSES</td>
 </tr>
 <tr>
 <td>USE_CURSES</td>
 <td>USE_CWRAPPERS</td>
 <td>USE_DB185</td>
 </tr>
 <tr>
 <td>USE_DB185</td>
 <td>USE_FEATURES</td>
 <td>USE_GAMESGROUP</td>
 </tr>
 <tr>
 <td>USE_GAMESGROUP</td>
 <td>USE_GCC_RUNTIME</td>
 <td>USE_IMAKE</td>
 </tr>
 <tr>
 <td>USE_IMAKE</td>
 <td>USE_JAVA</td>
 <td>USE_JAVA2</td>
 </tr>
 <tr>
 <td>USE_JAVA2</td>
 <td>USE_LANGUAGES</td>
 <td>USE_LIBTOOL</td>
 </tr>
 <tr>
 <td>USE_LIBTOOL</td>
 <td>USE_NATIVE_GCC</td>
 <td>USE_NETBSD_REPO</td>
 </tr>
 <tr>
 <td>USE_NETBSD_REPO</td>
 <td>USE_PKGSRC_GCC</td>
 <td>USE_PKGSRC_GCC_RUNTIME</td>
 </tr>
 <tr>
 <td>USE_PKGSRC_GCC_RUNTIME</td>
 <td>USE_PKGTASKS</td>
 <td>USE_PKG_ADMIN_DIGEST</td>
 </tr>
 <tr>
 <td>USE_PKG_ADMIN_DIGEST</td>
 <td>USE_RUBY_EXTCONF</td>
 <td>USE_RUBY_INSTALL</td>
 </tr>
 <tr>
 <td>USE_RUBY_INSTALL</td>
 <td>USE_RUBY_SETUP</td>
 <td>USE_RUBY_SETUP_PKG</td>
 </tr>
 <tr>
 <td>USE_RUBY_SETUP_PKG</td>
 <td>USE_TOOLS</td>
 <td>UUCP_GROUP</td>
 </tr>
 <tr>
 <td>UUCP_GROUP</td>
 <td>UUCP_USER</td>
 <td>VARBASE</td>
 </tr>
 <tr>
 <td>VARBASE</td>
 <td>VARNAME</td>
 <td>VIM_EXTRA_OPTS</td>
 </tr>
 <tr>
 <td>VIM_EXTRA_OPTS</td>
 <td>WARNING_MSG</td>
 <td>WCALC_CGIDIR</td>
 </tr>
 <tr>
 <td>WCALC_CGIDIR</td>
 <td>WCALC_CGIPATH</td>
 <td>WCALC_HTMLDIR</td>
 </tr>
 <tr>
 <td>WCALC_HTMLDIR</td>
 <td>WCALC_HTMLPATH</td>
 <td>WDM_MANAGERS</td>
 </tr>
 <tr>
 <td>WDM_MANAGERS</td>
 <td>WRAPPER_CC</td>
 <td>WRAPPER_REORDER_CMDS</td>
 </tr>
 <tr>
 <td>WRAPPER_REORDER_CMDS</td>
 <td>WRKDIR</td>
 <td>WRKDIR_BASENAME</td>
 </tr>
 <tr>
 <td>WRKDIR_BASENAME</td>
 <td>WRKDIR_LOCKTYPE</td>
 <td>WRKLOG</td>
 </tr>
 <tr>
 <td>WRKLOG</td>
 <td>WRKOBJDIR</td>
 <td>WRKSRC</td>
 </tr>
 <tr>
 <td>WRKSRC</td>
 <td>X10_PORT</td>
 <td>X11</td>
 </tr>
 <tr>
 <td>X11</td>
 <td>X11BASE</td>
 <td>X11_PKGSRCDIR</td>
 </tr>
 <tr>
 <td>X11_PKGSRCDIR</td>
 <td>X11_TYPE</td>
 <td>X509_CERTIFICATE</td>
 </tr>
 <tr>
 <td>X509_CERTIFICATE</td>
 <td>X509_KEY</td>
 <td>XAW_TYPE</td>
 </tr>
 <tr>
 <td>XAW_TYPE</td>
 <td>XLOCK_DEFAULT_MODE</td>
 <td>XMKMF</td>
 </tr>
 <tr>
 <td>XMKMF</td>
 <td>XMKMF_FLAGS</td>
 <td>XXX</td>
 </tr>
 <tr>
-<td>XXXX</td>
+<td>XXX</td>
 <td>YES</td>
 </tr>
 <tr>
 <td>ZSH_STATIC</td>
 <td>__stdc__</td>
 </tr>
 <tr>
 <td>_vargroups</td>
 <td>accept</td>
 </tr>
 <tr>
 <td>acquire-localbase-lock</td>
 <td>acquire-lock</td>
 </tr>
 <tr>
 <td>add</td>
 <td>administrator</td>
 </tr>
 <tr>
 <td>alloca</td>
 <td>alternatives</td>
 </tr>
 <tr>
 <td>aslr</td>
 <td>asprintf</td>
 </tr>
 <tr>
 <td>atlas</td>
 <td>autoconf</td>
 </tr>
 <tr>
 <td>automake</td>
 <td>autoreconf</td>
 </tr>
 <tr>
 <td>awk</td>
 <td>bash</td>
 </tr>
 <tr>
 <td>big-endian</td>
 <td>bin-install</td>
 </tr>
 <tr>
 <td>bind</td>
 <td>binpkg-list</td>
 </tr>
 <tr>
 <td>blas</td>
 <td>bootstrap-depends</td>
 </tr>
 <tr>
 <td>broken</td>
 <td>broken_on_platform</td>
 </tr>
 <tr>
 <td>bsd</td>
 <td>bsd.prog.mk</td>
 </tr>
 <tr>
 <td>build</td>
 <td>build-env</td>
 </tr>
 <tr>
 <td>buildlink-directories</td>
 <td>buildlink-oss-soundcard-h</td>
 </tr>
 <tr>
 <td>c</td>
 <td>c++</td>
 </tr>
 <tr>
 <td>ccache</td>
 <td>cce</td>
 </tr>
 <tr>
 <td>cdefs</td>
 <td>ceil</td>
 </tr>
 <tr>
 <td>changes</td>
 <td>changes-entry</td>
 </tr>
 <tr>
 <td>changes-entry-noupdate</td>
 <td>check</td>
 </tr>
 <tr>
 <td>check-clean</td>
 <td>check-files</td>
 </tr>
 <tr>
 <td>check-files-clean</td>
 <td>check-vulnerable</td>
 </tr>
 <tr>
 <td>checksum</td>
 <td>checksum-phase</td>
 </tr>
 <tr>
 <td>clean</td>
 <td>clean-depends</td>
 </tr>
 <tr>
 <td>cleandir</td>
 <td>commit</td>
 </tr>
 <tr>
 <td>commit-changes-entry</td>
 <td>compact</td>
 </tr>
 <tr>
 <td>compiler</td>
 <td>conf</td>
 </tr>
 <tr>
 <td>config.guess</td>
 <td>config.sub</td>
 </tr>
 <tr>
 <td>configuration</td>
 <td>configure</td>
 </tr>
 <tr>
 <td>configure-env</td>
 <td>configure-help</td>
 </tr>
 <tr>
 <td>configure_args</td>
 <td>connect</td>
 </tr>
 <tr>
 <td>cos</td>
 <td>cputime</td>
 </tr>
 <tr>
 <td>create-usergroup</td>
 <td>csh</td>
 </tr>
 <tr>
 <td>ctf</td>
 <td>cvs</td>
 </tr>
 <tr>
 <td>debug</td>
 <td>declaration</td>
 </tr>
 <tr>
 <td>declaration</td>
 <td>declare</td>
 <td>defined</td>
 </tr>
 <tr>
 <td>defined</td>
 <td>depend</td>
 <td>dependencies</td>
 </tr>
 <tr>
 <td>dependencies</td>
 <td>depends</td>
 <td>depends-checksum</td>
 </tr>
 <tr>
 <td>depends-checksum</td>
 <td>depends-fetch</td>
 <td>deps</td>
 </tr>
 <tr>
 <td>deps</td>
 <td>describe</td>
 <td>destdir</td>
 </tr>
 <tr>
 <td>destdir</td>
 <td>disable</td>
 <td>distclean</td>
 </tr>
 <tr>
 <td>distclean</td>
 <td>distinfo</td>
 <td>dl</td>
 </tr>
 <tr>
 <td>dl</td>
 <td>dlopen</td>
 <td>do-buildlink</td>
 </tr>
 <tr>
 <td>do-buildlink</td>
 <td>do-clean</td>
 <td>do-configure</td>
 </tr>
 <tr>
 <td>do-configure</td>
 <td>do-configure-post-hook</td>
 <td>do-extract</td>
 </tr>
 <tr>
 <td>do-extract</td>
 <td>do-fetch</td>
 <td>do-install</td>
 </tr>
 <tr>
 <td>do-install</td>
 <td>emul</td>
 <td>emul-distinfo</td>
 </tr>
 <tr>
 <td>emul-distinfo</td>
 <td>emul-fetch</td>
 <td>emulation</td>
 </tr>
 <tr>
 <td>emulation</td>
 <td>emulator</td>
 <td>enable</td>
 </tr>
 <tr>
 <td>enable</td>
 <td>endian</td>
 <td>endif</td>
 </tr>
 <tr>
 <td>enomem</td>
 <td>ensurepip</td>
 </tr>
 <tr>
 <td>err</td>
 <td>errx</td>
 </tr>
 <tr>
 <td>etc</td>
 <td>exp</td>
 </tr>
 <tr>
 <td>extract-rpm</td>
 <td>fabs</td>
 </tr>
 <tr>
 <td>feature</td>
 <td>features</td>
 </tr>
 <tr>
 <td>fetch</td>
 <td>fetch-list</td>
 </tr>
 <tr>
 <td>follows</td>
 <td>forbids</td>
 </tr>
 <tr>
 <td>form</td>
 <td>format</td>
 </tr>
 <tr>
 <td>fortify</td>
 <td>fortify_source</td>
 </tr>
 <tr>
 <td>fossil</td>
 <td>friend</td>
 </tr>
 <tr>
 <td>fts</td>
 <td>fts_close</td>
 </tr>
 <tr>
 <td>fts_close</td>
 <td>fts_open</td>
 <td>fts_read</td>
 </tr>
 <tr>
 <td>fts_read</td>
 <td>fts_set</td>
 <td>gcc</td>
 </tr>
 <tr>
 <td>gcc</td>
 <td>gethostbyaddr</td>
 <td>gethostbyname</td>
 </tr>
 <tr>
 <td>gethostbyname</td>
 <td>gethostbyname2</td>
 <td>getopt_long</td>
 </tr>
 <tr>
 <td>getopt_long</td>
 <td>getprogname</td>
 <td>getservbyname</td>
 </tr>
 <tr>
 <td>getservbyname</td>
 <td>getservbyport</td>
 <td>getservent</td>
 </tr>
 <tr>
 <td>getservent</td>
 <td>gettext</td>
 <td>git</td>
 </tr>
 <tr>
 <td>github</td>
 <td>gitlab</td>
 </tr>
 <tr>
 <td>glob</td>
 <td>gnu</td>
 </tr>
 <tr>
 <td>gnu_configure_strict</td>
 <td>go</td>
 </tr>
 <tr>
 <td>go-deps</td>
 <td>golang</td>
 </tr>
 <tr>
 <td>guess-license</td>
 <td>hashbang</td>
 </tr>
 <tr>
 <td>heimdal</td>
 <td>help</td>
 </tr>
 <tr>
 <td>hg</td>
 <td>imake</td>
 </tr>
 <tr>
 <td>increment</td>
 <td>indirect</td>
 </tr>
 <tr>
 <td>indirect</td>
 <td>inet_aton</td>
 <td>interp</td>
 </tr>
 <tr>
 <td>interp</td>
 <td>interpreter</td>
 <td>intl</td>
 </tr>
 <tr>
 <td>intl</td>
 <td>ip4</td>
 <td>ip6</td>
 </tr>
 <tr>
 <td>ip6</td>
 <td>ipv4</td>
 <td>ipv6</td>
 </tr>
 <tr>
 <td>ipv6</td>
 <td>iso</td>
 <td>kerberos</td>
 </tr>
 <tr>
 <td>kerberos</td>
 <td>krb</td>
 <td>krb5</td>
 </tr>
 <tr>
 <td>krb5</td>
 <td>ksh</td>
 <td>lapack</td>
 </tr>
 <tr>
 <td>lapack</td>
 <td>latex</td>
 <td>libintl_bindtextdomain</td>
 </tr>
 <tr>
 <td>libintl_bindtextdomain</td>
 <td>libintl_gettext</td>
 <td>libintl_textdomain</td>
 </tr>
 <tr>
 <td>libintl_textdomain</td>
 <td>libnbcompat</td>
 <td>libs</td>
 </tr>
 <tr>
 <td>libs</td>
 <td>libtool</td>
 <td>licence</td>
 </tr>
 <tr>
 <td>licence</td>
 <td>license</td>
 <td>lintl</td>
 </tr>
 <tr>
 <td>lintl</td>
 <td>little-endian</td>
 <td>lock</td>
 </tr>
 <tr>
 <td>lock</td>
 <td>locking</td>
 <td>lua</td>
 </tr>
 <tr>
 <td>lua</td>
 <td>lvalue</td>
 <td>make</td>
 </tr>
 <tr>
 <td>make</td>
 <td>makesum</td>
 <td>memory</td>
 </tr>
 <tr>
-<td>mercurial</td>
+<td>memory</td>
 <td>meta</td>
 </tr>
 <tr>
 <td>meta-package</td>
 <td>meta_package</td>
 </tr>
 <tr>
 <td>mit-krb5</td>
 <td>mk.conf</td>
 </tr>
 <tr>
 <td>mkl</td>
 <td>mount</td>
 </tr>
 <tr>
 <td>mprotect</td>
 <td>mremap</td>
 </tr>
 <tr>
 <td>nb</td>
 <td>nbcompat</td>
 </tr>
 <tr>
 <td>netlib</td>
 <td>node</td>
 </tr>
 <tr>
 <td>node.js</td>
 <td>nodejs</td>
 </tr>
 <tr>
 <td>obstack</td>
 <td>obstack_ptr_grow</td>
 </tr>
 <tr>
 <td>occurs</td>
 <td>only</td>
 </tr>
 <tr>
 <td>openblas</td>
 <td>options</td>
 </tr>
 <tr>
 <td>options.mk</td>
 <td>order</td>
 </tr>
 <tr>
 <td>override</td>
 <td>override-intltool</td>
 </tr>
 <tr>
 <td>override-message-intltool</td>
 <td>package</td>
 </tr>
 <tr>
 <td>parallel</td>
 <td>path</td>
 </tr>
 <tr>
 <td>pax</td>
 <td>paxctl</td>
 </tr>
 <tr>
 <td>pbulk-index</td>
 <td>pc</td>
 </tr>
 <tr>
 <td>perl</td>
 <td>perl5</td>
 </tr>
 <tr>
 <td>perms</td>
 <td>php</td>
 </tr>
 <tr>
 <td>pkg-build-options</td>
 <td>pkg-config</td>
 </tr>
 <tr>
 <td>pkg_build_options</td>
 <td>platform</td>
 </tr>
 <tr>
 <td>plist</td>
 <td>post-extract</td>
 </tr>
 <tr>
 <td>post-fetch</td>
 <td>post-wrapper</td>
 </tr>
 <tr>
 <td>pre-build-checks-hook</td>
 <td>pre-configure</td>
 </tr>
 <tr>
 <td>pre-configure-checks-hook</td>
 <td>pre-extract</td>
 </tr>
 <tr>
 <td>pre-fetch</td>
 <td>print-go-deps</td>
 </tr>
 <tr>
 <td>print-plist</td>
 <td>print-summary-data</td>
 </tr>
 <tr>
 <td>privileged-install-hook</td>
 <td>pypi</td>
 </tr>
 <tr>
 <td>python</td>
 <td>r</td>
 </tr>
 <tr>
 <td>readme-all</td>
 <td>recursive</td>
 </tr>
 <tr>
 <td>recv</td>
 <td>recvfrom</td>
 </tr>
 <tr>
 <td>regcomp</td>
 <td>release-localbase-lock</td>
 </tr>
 <tr>
 <td>release-lock</td>
 <td>relro</td>
 </tr>
 <tr>
 <td>rename</td>
 <td>reorder</td>
 </tr>
 <tr>
 <td>replace</td>
 <td>replace_interpreter</td>
 </tr>
 <tr>
 <td>reproducible</td>
 <td>resolv</td>
 </tr>
 <tr>
 <td>root</td>
 <td>ruby</td>
 </tr>
 <tr>
 <td>send</td>
 <td>sendfile</td>
 </tr>
 <tr>
 <td>sendto</td>
 <td>setenv</td>
 </tr>
 <tr>
 <td>setgid</td>
 <td>setprogname</td>
 </tr>
 <tr>
 <td>setuid</td>
 <td>sh</td>
 </tr>
 <tr>
 <td>shebang</td>
 <td>show</td>
 </tr>
 <tr>
 <td>show-all</td>
 <td>show-build-defs</td>
 </tr>
 <tr>
 <td>show-depends</td>
 <td>show-depends-dirs</td>
 </tr>
 <tr>
 <td>show-depends-pkgpaths</td>
 <td>show-depends-recursive</td>
 </tr>
 <tr>
 <td>show-deps</td>
 <td>show-distfiles</td>
 </tr>
 <tr>
 <td>show-downlevel</td>
 <td>show-subdir-var</td>
 </tr>
 <tr>
 <td>show-tools</td>
 <td>show-var</td>
 </tr>
 <tr>
 <td>show-vars</td>
 <td>snprintf</td>
 </tr>
 <tr>
 <td>socket</td>
 <td>ssp</td>
 </tr>
 <tr>
 <td>st_mode</td>
 <td>stage-install</td>
 </tr>
 <tr>
 <td>strcasestr</td>
 <td>strict</td>
 </tr>
 <tr>
 <td>strip</td>
 <td>strndup</td>
 </tr>
 <tr>
 <td>strnlen</td>
 <td>strsep</td>
 </tr>
 <tr>
 <td>subst</td>
 <td>substitutions</td>
 </tr>
 <tr>
 <td>subversion</td>
 <td>sun</td>
 </tr>
 <tr>
 <td>sunpro</td>
 <td>sunwspro</td>
 </tr>
 <tr>
-<td>svn</td>
+<td>sunwspro</td>
 <td>symlink</td>
 </tr>
 <tr>
 <td>test</td>
 <td>test-env</td>
 </tr>
 <tr>
 <td>tex</td>
 <td>texlive</td>
 </tr>
 <tr>
 <td>tmp</td>
 <td>tool</td>
 </tr>
 <tr>
 <td>tools</td>
 <td>tools-libtool-m4-override</td>
 </tr>
 <tr>
 <td>transitive</td>
 <td>type</td>
 </tr>
 <tr>
 <td>ulimit</td>
 <td>undefined</td>
 </tr>
 <tr>
 <td>undo-replace</td>
 <td>unlimit</td>
 </tr>
 <tr>
 <td>unprivileged</td>
 <td>unprivileged-install-hook</td>
 </tr>
 <tr>
 <td>unstripped</td>
 <td>update</td>
 </tr>
 <tr>
 <td>upload</td>
 <td>upload-distfiles</td>
 </tr>
 <tr>
 <td>use_tools</td>
 <td>user</td>
 </tr>
 <tr>
 <td>utimes</td>
 <td>vasprintf</td>
 </tr>
 <tr>
 <td>verbose</td>
 <td>vsnprintf</td>
 </tr>
 <tr>
 <td>warn</td>
 <td>warning</td>
 </tr>
 <tr>
 <td>warnings</td>
 <td>warnx</td>
 </tr>
 <tr>
 <td>wattr_off</td>
 <td>wattr_on</td>
 </tr>
 <tr>
 <td>work</td>
 <td>wrapper</td>
 </tr>
 <tr>
 <td>wrkdir</td>
 <td>�</td>
 </tr>
 </table>
 </div>
 <div class="appendix">
 <div class="titlepage"><div><div><h1 class="title">
 <a name="editing"></a>Appendix�F.�Editing guidelines for the pkgsrc guide</h1></div></div></div>
 <div class="toc">
 <p><b>Table of Contents</b></p>
 <dl class="toc">
 <dt><span class="sect1"><a href="#targets">F.1. Make targets</a></span></dt>
 <dt><span class="sect1"><a href="#procedure">F.2. Procedure</a></span></dt>
 </dl>
 </div>
 <p>This section contains information on editing the pkgsrc
 	guide itself.</p>
 <div class="sect1">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
 <a name="targets"></a>F.1.�Make targets</h2></div></div></div>
 <p>The pkgsrc guide's source code is stored in
 	<code class="filename">pkgsrc/doc/guide/files</code>, and several files
 	are created from it:</p>
 <div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; ">
 <li class="listitem"><p><code class="filename">pkgsrc/doc/pkgsrc.txt</code></p></li>
 <li class="listitem"><p><code class="filename">pkgsrc/doc/pkgsrc.html</code></p></li>
 <li class="listitem"><p><a class="ulink" href="https://www.NetBSD.org/docs/pkgsrc/" target="_top">https://www.NetBSD.org/docs/pkgsrc/</a></p></li>
 <li class="listitem"><p><a class="ulink" href="https://www.NetBSD.org/docs/pkgsrc/pkgsrc.pdf" target="_top">https://www.NetBSD.org/docs/pkgsrc/pkgsrc.pdf</a>:
 	The PDF version of the pkgsrc guide.</p></li>
 <li class="listitem"><p><a class="ulink" href="https://www.NetBSD.org/docs/pkgsrc/pkgsrc.ps" target="_top">https://www.NetBSD.org/docs/pkgsrc/pkgsrc.ps</a>:
 	PostScript version of the pkgsrc guide.</p></li>
 </ul></div>
 </div>
 <div class="sect1">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
 <a name="procedure"></a>F.2.�Procedure</h2></div></div></div>
 <p>The procedure to edit the pkgsrc guide is:</p>
 <div class="procedure"><ol class="procedure" type="1">
 <li class="step"><p>Make sure you have checked out the htdocs repository
 	into a sibling directory of your pkgsrc directory.  You will need
 	the ability to commit from both pkgsrc and htdocs.</p></li>
 <li class="step"><p>Make sure you have the packages needed to
 	regenerate the pkgsrc guide (and other XML-based NetBSD
 	documentation) installed. These are automatically installed when
 	you install the <a href="https://cdn.NetBSD.org/pub/pkgsrc/current/pkgsrc/meta-pkgs/pkgsrc-guide-tools/index.html" target="_top"><code class="filename">meta-pkgs/pkgsrc-guide-tools</code></a> package.</p></li>
 <li class="step"><p>Run <span class="command"><strong>cd doc/guide</strong></span> to get to the
 	right directory. All further steps will take place
 	here.</p></li>
 <li class="step"><p>Edit the XML file(s) in
 	<code class="filename">files/</code>.</p></li>
 <li class="step"><p>Run <span class="command"><strong>bmake</strong></span> to check the pkgsrc
 	guide for valid XML and to build the final output files. If you
 	get any errors at this stage, you can just edit the files, as
 	there are only symbolic links in the working directory, pointing
 	to the files in <code class="filename">files/</code>.</p></li>
 <li class="step"><p><span class="command"><strong>(cd files &amp;&amp; cvs
 	commit)</strong></span></p></li>
 <li class="step"><p>Run <span class="command"><strong>bmake clean &amp;&amp; bmake</strong></span> to
 	regenerate the output files with the proper RCS
 	Ids.</p></li>
 <li class="step">
 <p>Run <span class="command"><strong>bmake regen</strong></span> to install and
 	commit the files in both <code class="filename">pkgsrc/doc</code> and
 	<code class="filename">htdocs</code>.</p>
 <div class="note" style="margin-left: 0.5in; margin-right: 0.5in;">
 <h3 class="title">Note</h3>
 <p>If you have added, removed or renamed some chapters,
 	you need to synchronize them using <span class="command"><strong>cvs add</strong></span> or
 	<span class="command"><strong>cvs delete</strong></span> in the htdocs
 	directory.</p>
 </div>
 </li>
 </ol></div>
 </div>
 </div>
 </div></body>
 </html>

 @@ -2614,2015 +2614,2016 @@ If this database is installed, pkgsrc bu
 check before building any package.
 .15. Why do some packages ignore my CFLAGS?
 When you add your own preferences to the CFLAGS variable in your mk.conf, these
 flags are passed in environment variables to the ./configure scripts and to
 make(1). Some package authors ignore the CFLAGS from the environment variable
 by overriding them in the Makefiles of their package.
 Currently there is no solution to this problem. If you really need the package
 to use your CFLAGS you should run make patch in the package directory and then
 inspect any Makefile and Makefile.in for whether they define CFLAGS explicitly.
 Usually you can remove these lines. But be aware that some "smart" programmers
 write so bad code that it only works for the specific combination of CFLAGS
 they have chosen.
 To find out where the CFLAGS are ignored, add the following lines to mk.conf:
 CPPFLAGS+=              -Dpkgsrc___CPPFLAGS
 CFLAGS+=                -Dpkgsrc___CFLAGS
 CXXFLAGS+=              -Dpkgsrc___CXXFLAGS
 Then run bmake show-all-configure show-all-build to see whether the above flags
 are passed to the actual build commands in general.
 To find out whether the flags are passed to individual compiler commands, have
 a look at the file work/.work.log. In most cases, the flags from the original
 command lines (the lines starting with [*]) are passed unmodified to the actual
 compiler (the lines starting with <.>). If the flag is missing from the actual
 compiler command, it must have been removed by the pkgsrc compiler wrappers.
 .16. A package does not build. What shall I do?
 . Make sure that your copy of pkgsrc is consistent. A case that occurs often
     is that people only update pkgsrc in parts, because of performance reasons.
     Since pkgsrc is one large system, not a collection of many small systems,
     there are sometimes changes that only work when the whole pkgsrc tree is
     updated.
 . Make sure that you don't have any CVS conflicts. Search for "<<<<<<" or "
     >>>>>>" in all your pkgsrc files.
 . Make sure that you don't have old copies of the packages extracted. Run
     make clean clean-depends to verify this.
 . If you are a package developer who wants to invest some work, have a look
     at Chapter 21, Making your package work.
 . If the problem still exists, write a mail to the pkgsrc-users mailing list.
 .17. What does "Makefile appears to contain unresolved cvs/rcs/??? merge
 conflicts" mean?
 You have modified a file from pkgsrc, and someone else has modified that same
 file afterwards in the CVS repository. Both changes are in the same region of
 the file, so when you updated pkgsrc, the cvs command marked the conflicting
 changes in the file. Because of these markers, the file is no longer a valid
 Makefile.
 Have a look at that file, and if you don't need your local changes anymore, you
 can remove that file and run cvs -q update -dP in that directory to download
 the current version.
 Part II. The pkgsrc developer's guide
 This part of the book deals with creating and modifying packages. It starts
 with a "HOWTO"-like guide on creating a new package. The remaining chapters are
 more like a reference manual for pkgsrc.
 Table of Contents
 . Getting help
 . Package components - files, directories and contents
 .1. Makefile
 .2. distinfo
 .3. patches/*
 .3.1. Structure of a single patch file
 .3.2. Creating patch files
 .3.3. Sources where the patch files come from
 .3.4. Patching guidelines
 .3.5. Feedback to the author
 .4. Other mandatory files
 .5. Optional files
 .5.1. Files affecting the binary package
 .5.2. Files affecting the build process
 .5.3. Files affecting nothing at all
 .6. work*
 .7. files/*
 . The build process
 .1. Introduction
 .2. Program location
 .3. Directories used during the build process
 .4. Running a phase
 .5. The fetch phase
 .5.1. What to fetch and where to get it from
 .5.2. How are the files fetched?
 .6. The checksum phase
 .7. The extract phase
 .8. The patch phase
 .9. The tools phase
 .10. The wrapper phase
 .11. The configure phase
 .12. The build phase
 .13. The test phase
 .14. The install phase
 .15. The package phase
 .16. Cleaning up
 .17. Other helpful targets
 . Creating a new pkgsrc package from scratch
 .1. Common types of packages
 .1.1. Python modules and programs
 .1.2. R packages
 .1.3. TeXlive packages
 .2. Examples
 .2.1. How the www/nvu package came into pkgsrc
 . Programming in Makefiles
 .1. Caveats
 .2. Makefile variables
 .2.1. Naming conventions
 .3. Code snippets
 .3.1. Adding things to a list
 .3.2. Echoing a string exactly as-is
 .3.3. Passing CFLAGS to GNU configure scripts
 .3.4. Handling possibly empty variables
 . Options handling
 .1. Global default options
 .2. Converting packages to use bsd.options.mk
 .3. Option Names
 .4. Determining the options of dependencies
 . Tools needed for building or running
 .1. Tools for pkgsrc builds
 .2. Tools needed by packages
 .3. Tools provided by platforms
 . Buildlink methodology
 .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 and BUILDLINK_ABI_DEPENDS.
             pkg in buildlink3.mk files
 .3. Writing builtin.mk files
 .3.1. Anatomy of a builtin.mk file
 .3.2. Global preferences for native or pkgsrc software
 . PLIST issues
 .1. RCS ID
 .2. Semi-automatic PLIST generation
 .3. Tweaking output of make print-PLIST
 .4. Variable substitution in PLIST
 .5. Man page compression
 .6. Changing PLIST source with PLIST_SRC
 .7. Platform-specific and differing PLISTs
 .8. Build-specific PLISTs
 .9. Sharing directories between packages
 . The pkginstall framework
 .1. Files and directories outside the installation prefix
 .1.1. Directory manipulation
 .1.2. File manipulation
 .2. Configuration files
 .2.1. How PKG_SYSCONFDIR is set
 .2.2. Telling the software where configuration files are
 .2.3. Patching installations
 .2.4. Disabling handling of configuration files
 .3. System startup scripts
 .3.1. Disabling handling of system startup scripts
 .4. System users and groups
 .5. System shells
 .5.1. Disabling shell registration
 .6. Fonts
 .6.1. Disabling automatic update of the fonts databases
 . Making your package work
 .1. General operation
 .1.1. How to pull in user-settable variables from mk.conf
 .1.2. User interaction
 .1.3. Handling licenses
 .1.4. Restricted packages
 .1.5. Handling dependencies
 .1.6. Handling conflicts with other packages
 .1.7. Packages that cannot or should not be built
 .1.8. Packages which should not be deleted, once installed
 .1.9. Handling packages with security problems
 .1.10. How to handle incrementing versions when fixing an existing
             package
 .1.11. Substituting variable text in the package files (the SUBST
             framework)
 .2. The fetch phase
 .2.1. Packages whose distfiles aren't available for plain downloading
 .2.2. How to handle modified distfiles with the 'old' name
 .2.3. Packages hosted on github.com
 .3. The configure phase
 .3.1. Shared libraries - libtool
 .3.2. Using libtool on GNU packages that already support libtool
 .3.3. GNU Autoconf/Automake
 .3.4. Meson / ninja
 .4. Programming languages
 .4.1. C, C++, and Fortran
 .4.2. Java
 .4.3. Go
 .4.4. Rust
 .4.5. Packages containing Perl scripts
 .4.6. Packages containing shell scripts
 .4.7. Other programming languages
 .5. The build phase
 .5.1. Compiling C and C++ code conditionally
 .5.2. How to handle compiler bugs
 .5.3. No such file or directory
 .5.4. Undefined reference to "..."
 .5.5. Running out of memory
 .6. The install phase
 .6.1. Creating needed directories
 .6.2. Where to install documentation
 .6.3. Installing highscore files
 .6.4. Adding DESTDIR support to packages
 .6.5. Packages with hardcoded paths to other interpreters
 .6.6. Packages installing Perl modules
 .6.7. Packages installing info files
 .6.8. Packages installing man pages
 .6.9. Packages installing X11 fonts
 .6.10. Packages installing SGML or XML data
 .6.11. Packages installing extensions to the MIME database
 .6.12. Packages using intltool
 .6.13. Packages installing startup scripts
 .6.14. Packages installing TeX modules
 .6.15. Packages supporting running binaries in emulation
 .6.16. Packages installing hicolor icons
 .6.17. Packages installing desktop files
 .7. Marking packages as having problems
 . GNOME packaging and porting
 .1. Meta packages
 .2. Packaging a GNOME application
 .3. Updating GNOME to a newer version
 .4. Patching guidelines
 . Submitting and Committing
 .1. Submitting binary packages
 .2. Submitting source packages (for non-NetBSD-developers)
 .3. General notes when adding, updating, or removing packages
 .4. Commit Messages
 .5. Committing: Adding a package to CVS
 .6. Updating a package to a newer version
 .7. Renaming a package in pkgsrc
 .8. Moving a package in pkgsrc
 . Frequently Asked Questions
 Chapter 11. Getting help
 To get help when developing pkgsrc, the definitive source is this document, the
 pkgsrc guide. If you don't find anything here, there are alternatives:
   * The built-in pkgsrc help, which is available after bootstrapping pkgsrc.
     Run bmake help topic=? to get help for any topic, such as a variable name
     like BUILD_DEFS, a make target like do-build, a missing C or C++ function
     like strcasecmp or any other topic.
     The available help topics are listed in Appendix E, Help topics.
   * To see the value of a single variable, run bmake show-var VARNAME=X.
   * To see the values of the most common variables, run bmake show-all. These
     variables are grouped by topic. To see the variables for a single topic,
     run bmake show-all-topic, for example bmake show-all-fetch.
   * The tech-pkg mailing list, to which you can subscribe and then ask your
     questions.
   * The #pkgsrc IRC channel, which is accessible via a web browser or by using
     a specialized chat program such as XChat. Pick any user name and join the
     channel #pkgsrc.
 Chapter 12. Package components - files, directories and contents
 Table of Contents
 .1. Makefile
 .2. distinfo
 .3. patches/*
 .3.1. Structure of a single patch file
 .3.2. Creating patch files
 .3.3. Sources where the patch files come from
 .3.4. Patching guidelines
 .3.5. Feedback to the author
 .4. Other mandatory files
 .5. Optional files
 .5.1. Files affecting the binary package
 .5.2. Files affecting the build process
 .5.3. Files affecting nothing at all
 .6. work*
 .7. files/*
 Whenever you're preparing a package, there are a number of files involved which
 are described in the following sections.
 .1. Makefile
 Building, installation and creation of a binary package are all controlled by
 the package's Makefile. The Makefile describes various things about a package,
 for example from where to get it, how to configure, build, and install it.
 A package Makefile contains several sections that describe the package.
 In the first section there are the following variables, which should appear
 exactly in the order given here. The order and grouping of the variables is
 mostly historical and has no further meaning.
   * DISTNAME is the basename of the distribution file to be downloaded from the
     package's website.
   * PKGNAME is the name of the package, as used by pkgsrc. You need to provide
     it if DISTNAME (which is the default) is not a good name for the package in
     pkgsrc or DISTNAME is not provided (no distribution file is required).
     Usually it is the pkgsrc directory name together with the version number.
     It must match the regular expression ^[A-Za-z0-9][A-Za-z0-9-_.+]*$, that
     is, it starts with a letter or digit, and contains only letters, digits,
     dashes, underscores, dots and plus signs. New packages should have entirely
     lower-case names, with the exception of some that must follow pre-existing
     conventions (e.g. R packages begin with R-). You can use the :tl variable
     modifier to lower-case the package name.
   * CATEGORIES is a list of categories which the package fits in. You can
     choose any of the top-level directories of pkgsrc for it.
     Currently the following values are available for CATEGORIES. If more than
     one is used, they need to be separated by spaces:
     archivers     cross         geography     meta-pkgs     security
     audio         databases     graphics      misc          shells
     benchmarks    devel         ham           multimedia    sysutils
     biology       editors       inputmethod   net           textproc
     cad           emulators     lang          news          time
     chat          finance       mail          parallel      wm
     comms         fonts         math          pkgtools      www
     converters    games         mbone         print         x11
   * MASTER_SITES, DYNAMIC_MASTER_SITES, DIST_SUBDIR, EXTRACT_SUFX and DISTFILES
     are discussed in detail in Section 13.5, "The fetch phase".
 The second section contains information about separately downloaded patches, if
 any.
   * 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.
   * PATCH_SITES: Primary location(s) for distribution patch files (see
     PATCHFILES above) if not found locally.
   * PATCH_DIST_STRIP: an argument to patch(1) that sets the pathname strip
     count to help find the correct files to patch. It defaults to -p0.
 The third section contains the following variables.
   * MAINTAINER is the email address of the person who feels responsible for
     this package, and who is most likely to look at problems or questions
     regarding this package which have been reported with send-pr(1). Other
     developers may contact the MAINTAINER before making changes to the package,
     but are not required to do so. When packaging a new program, set MAINTAINER
     to yourself. If you really can't maintain the package for future updates,
     set it to <pkgsrc-users@NetBSD.org>.
   * OWNER should be used instead of MAINTAINER when you do not want other
     developers to update or change the package without contacting you first. A
     package Makefile should contain one of MAINTAINER or OWNER, but not both.
   * HOMEPAGE is a URL where users can find more information about the package.
   * COMMENT is a one-line description of the package (should not include the
     package name).
   * LICENSE indicates the license(s) applicable for the package. See
     Section 21.1.3, "Handling licenses" for further details.
 Other variables that affect the build:
   * WRKSRC: The directory where the interesting distribution files of the
     package are found. The default is ${WRKDIR}/${DISTNAME}, which works for
     most packages.
     If a package doesn't create a subdirectory for itself (most GNU software
     does, for instance), but extracts itself in the current directory, you
     should set WRKSRC=${WRKDIR}.
     If a package doesn't create a subdirectory with the name of DISTNAME but
     some different name, set WRKSRC to point to the proper name in ${WRKDIR},
     for example WRKSRC=${WRKDIR}/${DISTNAME}/unix. See lang/tcl and x11/tk for
     other examples.
     The name of the working directory created by pkgsrc is taken from the
     WRKDIR_BASENAME variable. By default, its value is work. If you want to use
     the same pkgsrc tree for building different kinds of binary packages, you
     can change the variable according to your needs. Two other variables handle
     common cases of setting WRKDIR_BASENAME individually. If OBJHOSTNAME is
     defined in mk.conf, the first component of the host's name is attached to
     the directory name. If OBJMACHINE is defined, the platform name is
     attached, which might look like work.i386 or work.sparc.
 Please pay attention to the following gotchas:
   * Add MANCOMPRESSED if man pages are installed in compressed form by the
     package. For packages using BSD-style makefiles which honor MANZ, there is
     MANCOMPRESSED_IF_MANZ.
   * Replace /usr/local with "${PREFIX}" in all files (see patches, below).
   * If the package installs any info files, see Section 21.6.7, "Packages
     installing info files".
 .2. distinfo
 The distinfo file contains the message digest, or checksum, of each distfile
 needed for the package. This ensures that the distfiles retrieved from the
 Internet have not been corrupted during transfer or altered by a malign force
 to introduce a security hole. To provide maximum security, all distfiles are
 protected using three different message digest algorithms (SHA1, RMD160,
 SHA512), as well as the file size.
 The distinfo file also contains the checksums for all the patches found in the
 patches directory (see Section 12.3, "patches/*"). These checksums ensure that
 patches are only applied intentionally and that they don't accidentally change,
 e.g. when merging different changes together. They also make sure that new
 patches are actually added to CVS and old ones are removed. Too see whether the
 patches and the distinfo file match, run pkglint after changing the patches.
 To regenerate the distinfo file, use the make distinfo command.
 Some packages have different sets of distfiles depending on the platform, for
 example lang/openjdk8. These are kept in the same distinfo file and care should
 be taken when upgrading such a package to ensure distfile information is not
 lost.
 .3. patches/*
 Some packages don't work out-of-the box on the various platforms that are
 supported by pkgsrc. These packages need to be patched to make them work. The
 patch files can be found in the patches/ directory.
 In the patch phase, these patches are applied to the files in WRKSRC directory
 after extracting them, in alphabetic order.
 .3.1. Structure of a single patch file
 The patch-* files should be in diff -bu format, and apply without a fuzz to
 avoid problems. (To force patches to apply with fuzz you can set
 PATCH_FUZZ_FACTOR=-F2). Furthermore, each patch should contain only changes for
 a single file, and no file should be patched by more than one patch file. This
 helps to keep future modifications simple.
 Each patch file is structured as follows: In the first line, there is the RCS
 Id of the patch itself. The second line should be empty for aesthetic reasons.
 After that, there should be a comment for each change that the patch does.
 There are a number of standard cases:
   * Patches for commonly known vulnerabilities should mention the vulnerability
     ID (CAN, CVE).
   * Patches that change source code should mention the platform and other
     environment (for example, the compiler) that the patch is needed for.
 The patch should be commented so that any developer who knows the code of the
 application can make some use of the patch. Special care should be taken for
 the upstream developers, since we generally want that they accept our patches,
 so we have less work in the future.
 .3.2. Creating patch files
 One important thing to mention is to pay attention that no RCS IDs get stored
 in the patch files, as these will cause problems when later checked into the
 NetBSD CVS tree. Use the pkgdiff command from the pkgtools/pkgdiff package to
 avoid these problems.
 For even more automation, we recommend using mkpatches from the same package to
 make a whole set of patches. You just have to back up files before you edit
 them to filename.orig, e.g., with cp -p filename filename.orig or, easier, by
 using pkgvi again from the same package. If you upgrade a package this way, you
 can easily compare the new set of patches with the previously existing one with
 patchdiff. The files in patches are replaced by new files, so carefully check
 if you want to take all the changes.
 When you have finished a package, remember to generate the checksums for the
 patch files by using the make makepatchsum command, see Section 12.2,
 "distinfo".
 When adding a patch that corrects a problem in the distfile (rather than e.g.
 enforcing pkgsrc's view of where man pages should go), send the patch as a bug
 report to the maintainer. This benefits non-pkgsrc users of the package, and
 usually makes it possible to remove the patch in future version.
 The file names of the patch files are usually of the form patch-
 path_to_file__with__underscores.c. Many packages still use the previous
 convention patch-[a-z][a-z], but new patches should be of the form containing
 the filename. mkpatches included in pkgtools/pkgdiff takes care of the name
 automatically.
 When updating pre-existing patch files, if a file uses the old patch-[a-z][a-z]
 convention, it's best not to change it to the new form, as that will just cause
 churn that makes it harder to track changes to patching over time. Similarly,
 if a patch now applies at different line offsets, but still applies cleanly
 as-is, there's no need to update it, as that also unnecessarily complicates the
 patch history.
 .3.3. Sources where the patch files come from
 If you want to share patches between multiple packages in pkgsrc, e.g. because
 they use the same distfiles, set PATCHDIR to the path where the patch files can
 be found, e.g.:
 PATCHDIR=       ../../editors/xemacs/patches
 Patch files that are distributed by the author or other maintainers can be
 listed in PATCHFILES.
 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.
 .3.4. Patching guidelines
 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.
 The general rule to follow is: instead of checking for the operating system the
 application is being built on, check for the specific features you need. For
 example, instead of assuming that kqueue is available under NetBSD and using
 the __NetBSD__ macro to conditionalize kqueue support, add a check that detects
 kqueue itself -- yes, this generally involves patching the configure 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.
 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: It
 doesn't work unless it is right!
 Some typical examples:
 Table 12.1. Patching examples
 +-------------------------------------------------------------------------------------------+
 |  Where  |        Incorrect         |                       Correct                        |
 |---------+--------------------------+------------------------------------------------------|
 |         |case ${target_os} in      |                                                      |
 |configure|netbsd*) have_kvm=yes ;;  |AC_CHECK_LIB(kvm, kvm_open, have_kvm=yes, have_kvm=no)|
 |script   |*)       have_kvm=no  ;;  |                                                      |
 |         |esac                      |                                                      |
 |---------+--------------------------+------------------------------------------------------|
 |C source |#if defined(__NetBSD__)   |#if defined(HAVE_SYS_EVENT_H)                         |
 |file     |#  include <sys/event.h>  |#  include <sys/event.h>                              |
 |         |#endif                    |#endif                                                |
 |---------+--------------------------+------------------------------------------------------|
 |         |int                       |int                                                   |
 |         |monitor_file(...)         |monitor_file(...)                                     |
 |         |{                         |{                                                     |
 |         |#if defined(__NetBSD__)   |#if defined(HAVE_KQUEUE)                              |
 |C source |        int fd = kqueue();|        int fd = kqueue();                            |
 |file     |        ...               |        ...                                           |
 |         |#else                     |#else                                                 |
 |         |        ...               |        ...                                           |
 |         |#endif                    |#endif                                                |
 |         |}                         |}                                                     |
 +-------------------------------------------------------------------------------------------+
 .3.5. Feedback to the author
 Always, always, always feed back any portability fixes or improvements you do
 to a package to the mainstream developers. This is the only way to get their
 attention on portability issues and to ensure that future versions can be built
 out-of-the box on NetBSD. Furthermore, any user that gets newer distfiles will
 get the fixes straight from the packaged code.
 This generally involves cleaning up the patches (because sometimes the patches
 that are added to pkgsrc are quick hacks), filing bug reports in the
 appropriate trackers for the projects and working with the mainstream authors
 to accept your changes. It is extremely important that you do it so that the
 packages in pkgsrc are kept simple and thus further changes can be done without
 much hassle.
 When you have done this, please add a URL to the upstream bug report to the
 patch comment.
 Support the idea of free software!
 .4. Other mandatory files
 DESCR
     A multi-line description of the piece of software. This should include any
     credits where they are due. Please bear in mind that others do not share
     your sense of humour (or spelling idiosyncrasies), and that others will
     read everything that you write here.
 PLIST
     This file governs the files that are installed on your system: all the
     binaries, manual pages, etc. There are other directives which may be
     entered in this file, to control the creation and deletion of directories,
     and the location of inserted files. See Chapter 19, PLIST issues for more
     information.
 .5. Optional files
 .5.1. Files affecting the binary package
 INSTALL
     This shell script is invoked twice by pkg_add(1). First time after package
     extraction and before files are moved in place, the second time after the
     files to install are moved in place. This can be used to do any custom
     procedures not possible with @exec commands in PLIST. See pkg_add(1) and
     pkg_create(1) for more information. See also Section 20.1, "Files and
     directories outside the installation prefix". Please note that you can
     modify variables in it easily by using FILES_SUBST in the package's
     Makefile:
     FILES_SUBST+=  SOMEVAR="somevalue"
     replaces "@SOMEVAR@" with "somevalue" in the INSTALL. By default,
     substitution is performed for PREFIX, LOCALBASE, X11BASE, VARBASE, and a
     few others, type make help topic=FILES_SUBST for a complete list.
 DEINSTALL
     This script is executed before and after any files are removed. It is this
     script's responsibility to clean up any additional messy details around the
     package's installation, since all pkg_delete knows is how to delete the
     files created in the original distribution. See pkg_delete(1) and
     pkg_create(1) for more information. The same methods to replace variables
     can be used as for the INSTALL file.
 MESSAGE
     This file is displayed after installation of the package. While this was
     used often in the past, it has two problems: the display will be missed if
     many packages are intalled at once, and the person installing the package
     and the one using or configuring it may be different. It should therefore
     be used only in exceptional circumstances where lasting negative
     consequences would result from someone not reading it.
     MESSAGE should not be used for:
       + exhortations to read the documentation
       + reminders to install rc.d files and set variables
       + anything that should be explained in the installation/configuration
         documentation that should come with the package
     If the documentation provided by upstream needs enhancing, create e.g.
     files/README.pkgsrc and install it in the package's documentation
     directory.
     Note that MESSAGE is shown for all operating systems and all init systems.
     If a MESSAGE is necessary, it should be narrowed to only those operating
     systems and init systems to which it applies.
     Note that you can modify variables in it easily by using MESSAGE_SUBST in
     the package's Makefile:
     MESSAGE_SUBST+=  SOMEVAR="somevalue"
     replaces "${SOMEVAR}" with "somevalue" in MESSAGE. By default, substitution
     is performed for PKGNAME, PKGBASE, PREFIX, LOCALBASE, X11BASE,
     PKG_SYSCONFDIR, ROOT_GROUP, and ROOT_USER.
     You can display a different or additional files by setting the MESSAGE_SRC
     variable. Its default is MESSAGE, if the file exists.
 ALTERNATIVES
     This file is used by the alternatives framework. It creates, configures,
     and destroys generic wrappers used to run programs with similar interfaces.
     See pkg_alternatives(8) from pkgtools/pkg_alternatives for more
     information.
     Each line of the file contains two filenames, first the wrapper and then
     the alternative provided by the package. Both paths are relative to PREFIX.
 .5.2. Files affecting the build process
 Makefile.common
     This file contains arbitrary things that could also go into a Makefile, but
     its purpose is to be used by more than one package. This file should only
     be used when the packages that will use the file are known in advance. For
     other purposes it is often better to write a *.mk file and give it a good
     name that describes what it does.
 buildlink3.mk
     This file contains the dependency information for the buildlink3 framework
     (see Chapter 18, Buildlink methodology).
 hacks.mk
     This file contains workarounds for compiler bugs and similar things. It is
     included automatically by the pkgsrc infrastructure, so you don't need an
     extra .include line for it.
 options.mk
     This file contains the code for the package-specific options (see
     Chapter 16, Options handling) that can be selected by the user. If a
     package has only one or two options, it is equally acceptable to put the
     code directly into the Makefile.
 .5.3. Files affecting nothing at all
 README*
     These files do not take place in the creation of a package and thus are
     purely informative to the package developer.
 TODO
     This file contains things that need to be done to make the package even
     better.
 .6. work*
 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 $
 {.CURDIR}/work.${MACHINE_ARCH} if OBJMACHINE is set.
 .7. files/*
 If you have any files that you wish to be placed in the package prior to
 configuration or building, you can place these files here and use a ${CP}
 command in the "post-extract" target to achieve this.
 If you want to share files in this way with other packages, set the FILESDIR
 variable to point to the other package's files directory, e.g.:
 FILESDIR=       ../../editors/xemacs/files
 Chapter 13. The build process
 Table of Contents
 .1. Introduction
 .2. Program location
 .3. Directories used during the build process
 .4. Running a phase
 .5. The fetch phase
 .5.1. What to fetch and where to get it from
 .5.2. How are the files fetched?
 .6. The checksum phase
 .7. The extract phase
 .8. The patch phase
 .9. The tools phase
 .10. The wrapper phase
 .11. The configure phase
 .12. The build phase
 .13. The test phase
 .14. The install phase
 .15. The package phase
 .16. Cleaning up
 .17. Other helpful targets
 .1. Introduction
 This chapter gives a detailed description on how a package is built. Building a
 package is separated into different phases (for example fetch, build, install),
 all of which are described in the following sections. Each phase is split into
 so-called stages, which take the name of the containing phase, prefixed by one
 of pre-, do- or post-. (Examples are pre-configure, post-build.) Most of the
 actual work is done in the do-* stages.
 Never override the regular targets (like fetch), if you have to, override the
 do-* ones instead.
 The basic steps for building a program are always the same. First the program's
 source (distfile) must be brought to the local system and then extracted. After
 any pkgsrc-specific patches to compile properly are applied, the software can
 be configured, then built (usually by compiling), and finally the generated
 binaries, etc. can be put into place on the system.
 To get more details about what is happening at each step, you can set the
 PKG_VERBOSE variable, or the PATCH_DEBUG variable if you are just interested in
 more details about the patch step.
 .2. Program location
 Before outlining the process performed by the NetBSD package system in the next
 section, here's a brief discussion on where programs are installed, and which
 variables influence this.
 The automatic variable PREFIX indicates where all files of the final program
 shall be installed. It is usually set to LOCALBASE (/usr/pkg), or CROSSBASE for
 pkgs in the cross category. The value of PREFIX needs to be put into the
 various places in the program's source where paths to these files are encoded.
 See Section 12.3, "patches/*" and Section 21.3.1, "Shared libraries - libtool"
 for more details.
 When choosing which of these variables to use, follow the following rules:
   * PREFIX always points to the location where the current pkg will be
     installed. When referring to a pkg's own installation path, use "${PREFIX}"
+    .
   * LOCALBASE is where all pkgs are installed. If you need to construct a -I or
     -L argument to the compiler to find includes and libraries installed by
     another pkg, use "${LOCALBASE}". The name LOCALBASE stems from FreeBSD,
     which installed all packages in /usr/local. As pkgsrc leaves /usr/local for
     the system administrator, this variable is a misnomer.
   * X11BASE is where the actual X11 distribution (from xsrc, etc.) is
     installed. When looking for standard X11 includes (not those installed by a
     package), use "${X11BASE}".
   * X11-based packages using imake must set USE_IMAKE to be installed correctly
     under LOCALBASE.
   * Within ${PREFIX}, packages should install files according to hier(7), with
     the exception that manual pages go into ${PREFIX}/man, not ${PREFIX}/share/
     man.
 .3. Directories used during the build process
 When building a package, various directories are used to store source files,
 temporary files, pkgsrc-internal files, and so on. These directories are
 explained here.
 Some of the directory variables contain relative pathnames. There are two
 common base directories for these relative directories: PKGSRCDIR/PKGPATH is
 used for directories that are pkgsrc-specific. WRKSRC is used for directories
 inside the package itself.
 PKGSRCDIR
     This is an absolute pathname that points to the pkgsrc root directory.
     Generally, you don't need it.
 PKGDIR
     This is an absolute pathname that points to the current package.
 PKGPATH
     This is a pathname relative to PKGSRCDIR that points to the current
     package.
 WRKDIR
     This is an absolute pathname pointing to the directory where all work takes
     place. The distfiles are extracted to this directory. It also contains
     temporary directories and log files used by the various pkgsrc frameworks,
     like buildlink or the wrappers.
 WRKSRC
     This is an absolute pathname pointing to the directory where the distfiles
     are extracted. It is usually a direct subdirectory of WRKDIR, and often
     it's the only directory entry that isn't hidden. This variable may be
     changed by a package Makefile.
 The CREATE_WRKDIR_SYMLINK definition takes either the value yes or no and
 defaults to no. It indicates whether a symbolic link to the WRKDIR is to be
 created in the pkgsrc entry's directory. If users would like to have their
 pkgsrc trees behave in a read-only manner, then the value of
 CREATE_WRKDIR_SYMLINK should be set to no.
 .4. Running a phase
 You can run a particular phase by typing make phase, where phase is the name of
 the phase. This will automatically run all phases that are required for this
 phase. The default phase is build, that is, when you run make without
 parameters in a package directory, the package will be built, but not
 installed.
 .5. The fetch phase
 The first step in building a package is to fetch the distribution files
 (distfiles) from the sites that are providing them. This is the task of the
 fetch phase.
 .5.1. What to fetch and where to get it from
 In simple cases, MASTER_SITES defines all URLs from where the distfile, whose
 name is derived from the DISTNAME variable, is fetched. The more complicated
 cases are described below.
 The variable DISTFILES specifies the list of distfiles that have to be fetched.
 Its value defaults to ${DEFAULT_DISTFILES} and its value is ${DISTNAME}$
 {EXTRACT_SUFX}, so that most packages don't need to define it at all.
 EXTRACT_SUFX is .tar.gz by default, but can be changed freely. Note that if
 your package requires additional distfiles to the default one, you cannot just
 append the additional filenames using the += operator, but you have write for
 example:
 DISTFILES=      ${DEFAULT_DISTFILES} additional-files.tar.gz
 Each distfile is fetched from a list of sites, usually MASTER_SITES. If the
 package has multiple DISTFILES or multiple PATCHFILES from different sites, you
 can set SITES.distfile to the list of URLs where the file distfile (including
 the suffix) can be found.
 DISTFILES=      ${DISTNAME}${EXTRACT_SUFX}
 DISTFILES+=     foo-file.tar.gz
 SITES.foo-file.tar.gz= \
 https://www.somewhere.com/somehow/ \
 https://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=   https://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.
 You can use this style for the case when the download URL style does not match
 the above common case. For example, if permanent download URL is a redirector
 to the real download URL, or the download file name is offered by an HTTP
 Content-Disposition header. In the following example, foo-1.0.0.tar.gz will be
 created instead of the default v1.0.0.tar.gz.
 DISTNAME=       foo-1.0.0
 MASTER_SITES=   -https://www.example.com/archive/v1.0.0.tar.gz
 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_APACHE        MASTER_SITE_BACKUP
-MASTER_SITE_CRATESIO        MASTER_SITE_CYGWIN
+MASTER_SITE_CRATESIO      MASTER_SITE_CYGWIN
-MASTER_SITE_DEBIAN          MASTER_SITE_FREEBSD
+MASTER_SITE_DEBIAN        MASTER_SITE_FREEBSD
-MASTER_SITE_FREEBSD_LOCAL   MASTER_SITE_GENTOO
+MASTER_SITE_FREEBSD_LOCAL MASTER_SITE_GENTOO
-MASTER_SITE_GITHUB          MASTER_SITE_GNOME
+MASTER_SITE_GITHUB        MASTER_SITE_GITLAB
-MASTER_SITE_GNU             MASTER_SITE_GNUSTEP
+MASTER_SITE_GNOME         MASTER_SITE_GNU
-MASTER_SITE_HASKELL_HACKAGE MASTER_SITE_IFARCHIVE
+MASTER_SITE_GNUSTEP       MASTER_SITE_HASKELL_HACKAGE
-MASTER_SITE_KDE             MASTER_SITE_MOZILLA
+MASTER_SITE_IFARCHIVE     MASTER_SITE_KDE
-MASTER_SITE_MOZILLA_ALL     MASTER_SITE_MYSQL
+MASTER_SITE_MOZILLA       MASTER_SITE_MOZILLA_ALL
-MASTER_SITE_NETLIB          MASTER_SITE_OPENBSD
+MASTER_SITE_MYSQL         MASTER_SITE_NETLIB
-MASTER_SITE_OPENOFFICE      MASTER_SITE_OSDN
+MASTER_SITE_OPENBSD       MASTER_SITE_OPENOFFICE
-MASTER_SITE_PERL_CPAN       MASTER_SITE_PGSQL
+MASTER_SITE_OSDN          MASTER_SITE_PERL_CPAN
-MASTER_SITE_PYPI            MASTER_SITE_RUBYGEMS
+MASTER_SITE_PGSQL         MASTER_SITE_PYPI
-MASTER_SITE_R_CRAN          MASTER_SITE_SOURCEFORGE
+MASTER_SITE_RUBYGEMS      MASTER_SITE_R_CRAN
-MASTER_SITE_SUNSITE         MASTER_SITE_SUSE
+MASTER_SITE_SOURCEFORGE   MASTER_SITE_SUNSITE
-MASTER_SITE_TEX_CTAN        MASTER_SITE_XCONTRIB
+MASTER_SITE_SUSE          MASTER_SITE_TEX_CTAN
-MASTER_SITE_XEMACS          MASTER_SITE_XORG
+MASTER_SITE_XCONTRIB      MASTER_SITE_XEMACS
 MASTER_SITE_XORG
 Some explanations for the less self-explaining ones: MASTER_SITE_BACKUP
 contains backup sites for packages that are maintained in ftp://ftp.NetBSD.org/
 pub/pkgsrc/distfiles/${DIST_SUBDIR}. MASTER_SITE_LOCAL contains local package
 source distributions that are maintained in ftp://ftp.NetBSD.org/pub/pkgsrc/
 distfiles/LOCAL_PORTS/.
 If you choose one of these predefined sites, you may want to specify a
 subdirectory of that site. Since these macros may expand to more than one
 actual site, you must use the following construct to specify a subdirectory:
 MASTER_SITES=   ${MASTER_SITE_GNU:=subdirectory/name/}
 MASTER_SITES=   ${MASTER_SITE_SOURCEFORGE:=project_name/}
 Note the trailing slash after the subdirectory name.
 .5.2. How are the files fetched?
 The fetch phase makes sure that all the distfiles exist in a local directory
 (DISTDIR, which can be set by the pkgsrc user). If the files do not exist, they
 are fetched using commands of the form
 ${FETCH_CMD} ${FETCH_BEFORE_ARGS} ${site}${file} ${FETCH_AFTER_ARGS}
 where ${site} varies through several possibilities in turn: first,
 MASTER_SITE_OVERRIDE is tried, then the sites specified in either SITES.file if
 defined, else MASTER_SITES or PATCH_SITES, as applies, then finally the value
 of MASTER_SITE_BACKUP. The order of all except the first and the last can be
 optionally sorted by the user, via setting either MASTER_SORT_RANDOM, and
 MASTER_SORT_AWK or MASTER_SORT_REGEX.
 The specific command and arguments used depend on the FETCH_USING parameter.
 The example above is for FETCH_USING=custom.
 The distfiles mirror run by the NetBSD Foundation uses the mirror-distfiles
 target to mirror the distfiles, if they are freely distributable. Packages
 setting NO_SRC_ON_FTP (usually to "${RESTRICTED}") will not have their
 distfiles mirrored.
 .6. The checksum phase
 After the distfile(s) are fetched, their checksum is generated and compared
 with the checksums stored in the distinfo file. If the checksums don't match,
 the build is aborted. This is to ensure the same distfile is used for building,
 and that the distfile wasn't changed, e.g. by some malign force, deliberately
 changed distfiles on the master distribution site or network lossage.
 .7. The extract phase
 When the distfiles are present on the local system, they need to be extracted,
 as they usually come in the form of some compressed archive format.
 By default, all DISTFILES are extracted. If you only need some of them, you can
 set the EXTRACT_ONLY variable to the list of those files.
 Extracting the files is usually done by a little program, mk/extract/extract,
 which already knows how to extract various archive formats, so most likely you
 will not need to change anything here. But if you need, the following variables
 may help you:
 EXTRACT_OPTS_{BIN,LHA,PAX,RAR,TAR,ZIP,ZOO}
     Use these variables to override the default options for an extract command,
     which are defined in mk/extract/extract.
 EXTRACT_USING
     This variable can be set to bsdtar, gtar, nbtar (which is the default
     value), pax, or an absolute pathname pointing to the command with which tar
     archives should be extracted. It is preferred to choose bsdtar over gtar if
     NetBSD's pax-as-tar is not good enough.
 If the extract program doesn't serve your needs, you can also override the
 EXTRACT_CMD variable, which holds the command used for extracting the files.
 This command is executed in the ${WRKSRC} directory. During execution of this
 command, the shell variable extract_file holds the absolute pathname of the
 file that is going to be extracted.
 And if that still does not suffice, you can override the do-extract target in
 the package Makefile.
 .8. The patch phase
 After extraction, all the patches named by the PATCHFILES, those present in the
 patches subdirectory of the package as well as in $LOCALPATCHES/$PKGPATH (e.g.
 /usr/local/patches/graphics/png) are applied. Patchfiles ending in .Z or .gz
 are uncompressed before they are applied, files ending in .orig or .rej are
 ignored. Any special options to patch(1) can be handed in PATCH_DIST_ARGS. See
 Section 12.3, "patches/*" for more details.
 By default patch(1) is given special arguments to make it fail if the expected
 text from the patch context is not found in the patched file. If that happens,
 fix the patch file by comparing it with the actual text in the file to be
 patched.
 .9. The tools phase
 This is covered in Chapter 17, Tools needed for building or running.
 .10. The wrapper phase
 This phase creates wrapper programs for the compilers and linkers. The
 following variables can be used to tweak the wrappers.
 ECHO_WRAPPER_MSG
     The command used to print progress messages. Does nothing by default. Set
     to ${ECHO} to see the progress messages.
 WRAPPER_DEBUG
     This variable can be set to yes (default) or no, depending on whether you
     want additional information in the wrapper log file.
 WRAPPER_UPDATE_CACHE
     This variable can be set to yes or no, depending on whether the wrapper
     should use its cache, which will improve the speed. The default value is
     yes, but is forced to no if the platform does not support it.
 WRAPPER_REORDER_CMDS
     A list of reordering commands. A reordering command has the form reorder:l:
     lib1:lib2. It ensures that that -llib1 occurs before -llib2.
 .11. The configure phase
 Most pieces of software need information on the header files, system calls, and
 library routines which are available on the platform they run on. The process
 of determining this information is known as configuration, and is usually
 automated. In most cases, a script is supplied with the distfiles, and its
 invocation results in generation of header files, Makefiles, etc.
 If the package contains a configure script, this can be invoked by setting
 HAS_CONFIGURE to "yes". If the configure script is a GNU autoconf script, you
 should set GNU_CONFIGURE to "yes" instead.
 In the do-configure stage, a rough equivalent of the following command is run.
 See mk/configure/configure.mk, target do-configure-script for the exact
 definition.
 .for dir in ${CONFIGURE_DIRS}
         cd ${WRKSRC} && cd ${dir} \
         && env ${CONFIGURE_ENV} \
             ${CONFIG_SHELL} ${CONFIGURE_SCRIPT} ${CONFIGURE_ARGS}
 .endfor
 CONFIGURE_DIRS (default: ".") is a list of pathnames relative to WRKSRC. In
 each of these directories, the configure script is run with the environment
 CONFIGURE_ENV and arguments CONFIGURE_ARGS. The variables CONFIGURE_ENV,
 CONFIGURE_SCRIPT (default: "./configure") and CONFIGURE_ARGS may all be changed
 by the package.
 If the program uses the Perl way of configuration (mainly Perl modules, but not
 only), i.e. a file called Makefile.PL, it should include ../../lang/perl5/
 module.mk. To set any parameter for Makefile.PL use the MAKE_PARAMS variable
 (e.g., MAKE_PARAMS+=foo=bar
 If the program uses an Imakefile for configuration, the appropriate steps can
 be invoked by setting USE_IMAKE to "yes". If you only need xmkmf, add it to
 USE_TOOLS. You can add variables to xmkmf's environment by adding them to the
 SCRIPTS_ENV variable.
 If the program uses cmake for configuration, the appropriate steps can be
 invoked by setting USE_CMAKE to "yes". You can add variables to cmake's
 environment by adding them to the CONFIGURE_ENV variable and arguments to cmake
 by adding them to the CMAKE_ARGS variable. The top directory argument is given
 by the CMAKE_ARG_PATH variable, that defaults to "." (relative to
 CONFIGURE_DIRS)
 If there is no configure step at all, set NO_CONFIGURE to "yes".
 .12. The build phase
 For building a package, a rough equivalent of the following code is executed;
 see mk/build/build.mk, target do-build for the exact definition.
 .for dir in ${BUILD_DIRS}
         cd ${WRKSRC} && cd ${dir} \
         && env ${MAKE_ENV} \
             ${MAKE_PROGRAM} ${MAKE_FLAGS} ${BUILD_MAKE_FLAGS} \
                 -f ${MAKE_FILE} \
                 ${BUILD_TARGET}
 .endfor
 BUILD_DIRS (default: ".") is a list of pathnames relative to WRKSRC. In each of
 these directories, MAKE_PROGRAM is run with the environment MAKE_ENV and
 arguments BUILD_MAKE_FLAGS. The variables MAKE_ENV, BUILD_MAKE_FLAGS, MAKE_FILE
 and BUILD_TARGET may all be changed by the package.
 The default value of MAKE_PROGRAM is "gmake" if USE_TOOLS contains "gmake", "
 make" otherwise. The default value of MAKE_FILE is "Makefile", and BUILD_TARGET
 defaults to "all".
 If there is no build step at all, set NO_BUILD to "yes".
 .13. The test phase
 [TODO]
 .14. The install phase
 Once the build stage has completed, the final step is to install the software
 in public directories, so users can access the programs and files.
 In the install phase, a rough equivalent of the following code is executed; see
 mk/install/install.mk, target do-install for the exact definition.
 Additionally, before and after this code, several consistency checks are run
 against the files-to-be-installed, see mk/check/*.mk for details.
 .for dir in ${INSTALL_DIRS}
         cd ${WRKSRC} && cd ${dir} \
         && env ${INSTALL_ENV} ${MAKE_ENV} \
             ${MAKE_PROGRAM} ${MAKE_FLAGS} ${INSTALL_MAKE_FLAGS} \
                 -f ${MAKE_FILE} ${INSTALL_TARGET}
 .endfor
 The variable's meanings are analogous to the ones in the build phase.
 INSTALL_DIRS defaults to BUILD_DIRS. INSTALL_TARGET is "install" by default,
 plus "install.man" if USE_IMAKE is defined and NO_INSTALL_MANPAGES is not
 defined.
 In the install phase, the following variables are useful. They are all
 variations of the install(1) command that have the owner, group and permissions
 preset. INSTALL is the plain install command. The specialized variants,
 together with their intended use, are:
 INSTALL_PROGRAM_DIR
     directories that contain binaries
 INSTALL_SCRIPT_DIR
     directories that contain scripts
 INSTALL_LIB_DIR
     directories that contain shared and static libraries
 INSTALL_DATA_DIR
     directories that contain data files
 INSTALL_MAN_DIR
     directories that contain man pages
 INSTALL_GAME_DIR
     directories that contain data files for games
 INSTALL_PROGRAM
     binaries that can be stripped from debugging symbols
 INSTALL_SCRIPT
     binaries that cannot be stripped
 INSTALL_GAME
     game binaries
 INSTALL_LIB
     shared and static libraries
 INSTALL_DATA
     data files
 INSTALL_GAME_DATA
     data files for games
 INSTALL_MAN
     man pages
 Some other variables are:
 INSTALL_UNSTRIPPED
     If set to yes, do not run strip(1) when installing binaries. Any debugging
     sections and symbols present in binaries will be preserved.
 INSTALLATION_DIRS
     A list of directories relative to PREFIX that are created by pkgsrc at the
     beginning of the install phase. The package is supposed to create all
     needed directories itself before installing files to it and list all other
     directories here.
 In the rare cases that a package shouldn't install anything, set NO_INSTALL to
 "yes". This is mostly relevant for packages in the regress category.
 .15. The package phase
 Once the install stage has completed, a binary package of the installed files
 can be built. These binary packages can be used for quick installation without
 previous compilation, e.g. by the make bin-install or by using pkg_add.
 By default, the binary packages are created in ${PACKAGES}/All and symlinks are
 created in ${PACKAGES}/category, one for each category in the CATEGORIES
 variable. PACKAGES defaults to pkgsrc/packages.
 .16. Cleaning up
 Once you're finished with a package, you can clean the work directory by
 running make clean. If you want to clean the work directories of all
 dependencies too, use make clean-depends.
 .17. Other helpful targets
 pre/post-*
     For any of the main targets described in the previous section (configure,
     build, install, etc.), two auxiliary targets exist with "pre-" and "post-"
     used as a prefix for the main target's name. These targets are invoked
     before and after the main target is called, allowing extra configuration or
     installation steps be performed from a package's Makefile, for example,
     which a program's configure script or install target omitted.
     About 5% of the pkgsrc packages define their custom post-extract target,
     another 5% define pre-configure, and 10% define post-install. The other pre
     /post-* targets are defined even less often.
 do-*
     Should one of the main targets do the wrong thing, and should there be no
     variable to fix this, you can redefine it with the do-* target. (Note that
     redefining the target itself instead of the do-* target is a bad idea, as
     the pre-* and post-* targets won't be called anymore, etc.)
     About 15% of the pkgsrc packages override the default do-install, the other
     do-* targets are overridden even less often.
 reinstall
     If you did a make install and you noticed some file was not installed
     properly, you can repeat the installation with this target, which will
     ignore the "already installed" flag.
     This is the default value of DEPENDS_TARGET except in the case of make
     update and make package, where the defaults are "package" and "update",
     respectively.
 deinstall
     This target does a pkg_delete(1) in the current directory, effectively
     de-installing the package. The following variables can be used to tune the
     behaviour:
     PKG_VERBOSE
         Add a "-v" to the pkg_delete(1) command.
     DEINSTALLDEPENDS
         Remove all packages that require (depend on) the given package. This
         can be used to remove any packages that may have been pulled in by a
         given package, e.g. if make deinstall DEINSTALLDEPENDS=1 is done in
         pkgsrc/x11/kde, this is likely to remove whole KDE. Works by adding "-R
         " to the pkg_delete(1) command line.
 bin-install
     Install a binary package from local disk and via FTP from a list of sites
     (see the BINPKG_SITES variable), and do a make package if no binary package
     is available anywhere. The arguments given to pkg_add can be set via
     BIN_INSTALL_FLAGS e.g., to do verbose operation, etc.
 install-clean
     This target removes the state files for the "install" and later phases so
     that the "install" target may be re-invoked. This can be used after editing
     the PLIST to install the package without rebuilding it.
 build-clean
     This target removes the state files for the "build" and later phases so
     that the "build" target may be re-invoked.
 update
     This target causes the current package to be updated to the latest version.
     The package and all depending packages first get de-installed, then current
     versions of the corresponding packages get compiled and installed. This is
     similar to manually noting which packages are currently installed, then
     performing a series of make deinstall and make install (or whatever
     UPDATE_TARGET is set to) for these packages.
     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
     automatically update the current package along with the dependent packages
     you have installed.
     Resuming an interrupted make update will only work as long as the package
     tree remains unchanged. If the source code for one of the packages to be
     updated has been changed, resuming make update will most certainly fail!
     The following variables can be used either on the command line or in
     mk.conf to alter the behaviour of make update:
     UPDATE_TARGET
         Install target to recursively use for the updated package and the
         dependent packages. Defaults to DEPENDS_TARGET if set, "install"
         otherwise for make update. Other good targets are "package" or "
         bin-install". Do not set this to "update" or you will get stuck in an
         endless loop!
     NOCLEAN
         Don't clean up after updating. Useful if you want to leave the work
         sources of the updated packages around for inspection or other
         purposes. Be sure you eventually clean up the source tree (see the "
         clean-update" target below) or you may run into troubles with old
         source code still lying around on your next make or make update.
     REINSTALL
         Deinstall each package before installing (making DEPENDS_TARGET). This
         may be necessary if the "clean-update" target (see below) was called
         after interrupting a running make update.
     DEPENDS_TARGET
         Allows you to disable recursion and hardcode the target for packages.
         The default is "update" for the update target, facilitating a recursive
         update of prerequisite packages. Only set DEPENDS_TARGET if you want to
         disable recursive updates. Use UPDATE_TARGET instead to just set a
         specific target for each package to be installed during make update
         (see above).
 clean-update
     Clean the source tree for all packages that would get updated if make
     update was called from the current directory. This target should not be
     used if the current package (or any of its depending packages) have already
     been de-installed (e.g., after calling make update) or you may lose some
     packages you intended to update. As a rule of thumb: only use this target
     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 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!):
     # make clean-update
     # make clean CLEANDEPENDS=YES
     # make update
     The following variables can be used either on the command line or in
     mk.conf to alter the behaviour of make clean-update:
     CLEAR_DIRLIST
         After make clean, do not reconstruct the list of directories to update
         for this package. Only use this if make update successfully installed
         all packages you wanted to update. Normally, this is done automatically
         on make update, but may have been suppressed by the NOCLEAN variable
         (see above).
 replace
     Update the installation of the current package. This differs from update in
     that it does not replace dependent packages. You will need to install
     pkgtools/pkg_tarup for this target to work.
     Be careful when using this target! There are no guarantees that dependent
     packages will still work, in particular they will most certainly break if
     you make replace a library package whose shared library major version
     changed between your installed version and the new one. For this reason,
     this target is not officially supported and only recommended for advanced
     users.
 info
     This target invokes pkg_info(1) for the current package. You can use this
     to check which version of a package is installed.
 index
     This is a top-level command, i.e. it should be used in the pkgsrc
     directory. It creates a database of all packages in the local pkgsrc tree,
     including dependencies, comment, maintainer, and some other useful
     information. Individual entries are created by running make describe in the
     packages' directories. This index file is saved as pkgsrc/INDEX. It can be
     displayed in verbose format by running make print-index. You can search in
     it with make search key=something. You can extract a list of all packages
     that depend on a particular one by running make show-deps PKG=somepackage.
     Running this command takes a very long time, some hours even on fast
     machines!
 readme
     This target generates a index.html file, which can be viewed using a
     browser such as www/firefox or www/links. The generated files contain
     references to any packages which are in the PACKAGES directory on the local
     host. The generated files can be made to refer to URLs based on
     FTP_PKG_URL_HOST and FTP_PKG_URL_DIR. For example, if I wanted to generate
     index.html files which pointed to binary packages on the local machine, in
     the directory /usr/packages, set FTP_PKG_URL_HOST=file://localhost and
     FTP_PKG_URL_DIR=/usr/packages. The ${PACKAGES} directory and its
     subdirectories will be searched for all the binary packages.
     The target can be run at the toplevel or in category directories, in which
     case it descends recursively.
 readme-all
     This is a top-level command, run it in pkgsrc. Use this target to create a
     file README-all.html which contains a list of all packages currently
     available in the NetBSD Packages Collection, together with the category
     they belong to and a short description. This file is compiled from the
     pkgsrc/*/index.html files, so be sure to run this after a make readme.
 cdrom-readme
     This is very much the same as the "readme" target (see above), but is to be
     used when generating a pkgsrc tree to be written to a CD-ROM. This target
     also produces index.html files, and can be made to refer to URLs based on
     CDROM_PKG_URL_HOST and CDROM_PKG_URL_DIR.
 show-distfiles
     This target shows which distfiles and patchfiles are needed to build the
     package (ALLFILES, which contains all DISTFILES and PATCHFILES, but not
     patches/*).
 show-downlevel
     This target shows nothing if the package is not installed. If a version of
     this package is installed, but is not the version provided in this version
     of pkgsrc, then a warning message is displayed. This target can be used to
     show which of your installed packages are downlevel, and so the old
     versions can be deleted, and the current ones added.
 show-pkgsrc-dir
     This target shows the directory in the pkgsrc hierarchy from which the
     package can be built and installed. This may not be the same directory as
     the one from which the package was installed. This target is intended to be
     used by people who may wish to upgrade many packages on a single host, and
     can be invoked from the top-level pkgsrc Makefile by using the "
     show-host-specific-pkgs" target.
 show-installed-depends
     This target shows which installed packages match the current package's
     DEPENDS. Useful if out of date dependencies are causing build problems.
 print-build-depends-list
     This target shows the list of packages that the current package depends on
     for building.
 print-run-depends-list
     This target shows the list of packages that the current package depends on
     for running.
 check-shlibs
     After a package is installed, check all its binaries and (on ELF platforms)
     shared libraries to see if they find the shared libs they need. Run by
     default if PKG_DEVELOPER is set in mk.conf.
 print-PLIST
     After a "make install" from a new or upgraded pkg, this prints out an
     attempt to generate a new PLIST from a find -newer work/.extract_done. An
     attempt is made to care for shared libs etc., but it is strongly
     recommended to review the result before putting it into PLIST. On upgrades,
     it's useful to diff the output of this command against an already existing
     PLIST file.
     If the package installs files via tar(1) or other methods that don't update
     file access times, be sure to add these files manually to your PLIST, as
     the "find -newer" command used by this target won't catch them!
     See Section 19.3, "Tweaking output of make print-PLIST" for more
     information on this target.
 Chapter 14. Creating a new pkgsrc package from scratch
 Table of Contents
 .1. Common types of packages
 .1.1. Python modules and programs
 .1.2. R packages
 .1.3. TeXlive packages
 .2. Examples
 .2.1. How the www/nvu package came into pkgsrc
 When you find a package that is not yet in pkgsrc, you most likely have a URL
 from where you can download the source code. Starting with this URL, creating a
 package involves only a few steps.
 . In your mk.conf, set PKG_DEVELOPER=yes to enable the basic quality checks.
 . Install the package meta-pkgs/pkg_developer, which among others will
     install the utilities url2pkg, pkglint, pkgvi and mkpatches:
     $ cd /usr/pkgsrc
     $ (cd meta-pkgs/pkg_developer && bmake update)
 . Choose one of the top-level directories as the category in which you want
     to place your package. You can also create a directory of your own (maybe
     called local). Change into that category directory:
     $ cd category
 . Run the program url2pkg, passing as argument the URL of the distribution
     file (in most cases a .tar.gz file). This will download the distribution
     file and create the necessary files of the package, based on what's in the
     distribution file:
     $ url2pkg https://www.example.org/packages/package-1.0.tar.gz
 . Examine the extracted files to determine the dependencies of your package.
     Ideally, this is mentioned in some README file, but things may differ. For
     each of these dependencies, look where it exists in pkgsrc, and if there is
     a file called buildlink3.mk in that directory, add a line to your package
     Makefile which includes that file just before the last line. If the
     buildlink3.mk file does not exist, it must be created first. The
     buildlink3.mk file makes sure that the package's include files and
     libraries are provided.
     If you just need binaries from a dependent package, add a DEPENDS line to
     the Makefile, which specifies the version of the dependency and where it
     can be found in pkgsrc. This line should be placed in the third paragraph.
     If the dependency is only needed for building the package, but not when
     using it, use TOOL_DEPENDS or BUILD_DEPENDS instead of DEPENDS. The
     difference between TOOL_DEPENDS and BUILD_DEPENDS occurs when
     cross-compiling: TOOL_DEPENDS are native packages, i.e. packages for the
     platform where the package is built; BUILD_DEPENDS are target packages,
     i.e. packages for the platform for which the package is built. There is
     also TEST_DEPENDS, which specifies a dependency used only for testing the
     resulting package built, using the upstream project's included test suite,
     on the native platform. Your package may then look like this:
     [...]
     TOOL_DEPENDS+=  libxslt-[0-9]*:../../textproc/libxslt
     DEPENDS+=       screen-[0-9]*:../../misc/screen
     DEPENDS+=       screen>=4.0:../../misc/screen
     [...]
     .include "../../category/package/buildlink3.mk"
     .include "../../devel/glib2/buildlink3.mk"
     .include "../../mk/bsd.pkg.mk"
 . Run pkglint to see what things still need to be done to make your package a
     "good" one. If you don't know what pkglint's warnings want to tell you, try
     pkglint --explain or pkglint -e, which outputs additional explanations.
 . In many cases the package is not yet ready to build. You can find
     instructions for the most common cases in the next section, Section 14.1,
     "Common types of packages". After you have followed the instructions over
     there, you can hopefully continue here.
 . Run bmake clean to clean the working directory from the extracted files.
     Besides these files, a lot of cache files and other system information have
     been saved in the working directory, which may have become outdated after
     you edited the Makefile.
 . Now, run bmake to build the package. For the various things that can go
     wrong in this phase, consult Chapter 21, Making your package work.
     If the extracted files from the package need to be fixed, run multiple
     rounds of these commands:
     $ bmake
     $ pkgvi ${WRKSRC}/some/file/that/does/not/compile
     $ mkpatches
     $ bmake mps
     $ bmake clean
 . When the package builds fine, the next step is to install the package. Run
     bmake install and hope that everything works.
 . Up to now, the file PLIST, which contains a list of the files that are
     installed by the package, is nearly empty. Run bmake print-PLIST >PLIST to
     generate a probably correct list. Check the file using your preferred text
     editor to see if the list of files looks plausible.
 . Run pkglint again to see if the generated PLIST contains garbage or not.
 . When you ran bmake install, the package had been registered in the database
     of installed files, but with an empty list of files. To fix this, run bmake
     deinstall and bmake install again. Now the package is registered with the
     list of files from PLIST.
 . Run bmake clean update to run everything from above again in a single step,
     making sure that the PLIST is correct and the whole package is created as
     intended.
 . Run pkglint to see if there's anything left to do.
 . Commit the package to pkgsrc-wip or main pkgsrc; see Chapter 23, Submitting
     and Committing.
 .1. Common types of packages
 .1.1. Python modules and programs
 Python modules and programs packages are easily created using a set of
 predefined variables.
 If some Python versions are not supported by the software, set the
 PYTHON_VERSIONS_INCOMPATIBLE variable to the Python versions that are not
 supported, e.g.
 PYTHON_VERSIONS_INCOMPATIBLE=       27
 If the packaged software is a Python module, include one of ../../lang/python/
 egg.mk or ../../lang/python/extension.mk.
 Most Python packages use setuptools ("eggs"). If the packaged software is using
 setuptools, you only need to include "../../lang/python/egg.mk".
 Either way, the package directory should be called "py-software" and PKGNAME
 should be set to "${PYPKGPREFIX}-${DISTNAME}", e.g.
 DISTNAME=   foopymodule-1.2.10
 PKGNAME=    ${PYPKGPREFIX}-${DISTNAME}
 If it is an application, include "../../lang/python/application.mk". In order
 to correctly set the path to the Python interpreter, use the REPLACE_PYTHON
 variable and set it to the list of files (paths relative to WRKSRC) that must
 be corrected. For example:
 REPLACE_PYTHON=   *.py
 Some Python modules have separate distributions for Python-2.x and Python-3.x
 support. In pkgsrc this is handled by the versioned_dependencies.mk file. Set
 PYTHON_VERSIONED_DEPENDENCIES to the list of packages that should be depended
 upon and include "../../lang/python/versioned_dependencies.mk", then the pkgsrc
 infrastructure will depend on the appropriate package version. For example:
 PYTHON_VERSIONED_DEPENDENCIES=dialog
 Look inside versioned_dependencies.mk for a list of supported packages.
 .1.2. R packages
 Simple R packages from CRAN are handled automatically by R2pkg, which is
 available in pkgtools/R2pkg. Individual packages (and optionally their
 dependencies) may be created and updated. R packages generally follow the same
 form, and most of the relevant information needed is contained in a DESCRIPTION
 file as part of each R package on CRAN. Consequently, R2pkg downloads that
 information and creates or updates a package in the canonical form. The
 resulting package should be reviewed for correctness.
 .1.3. TeXlive packages
 TeXlive packages from CTAN are handled automatically by texlive2pkg, which is
 available in pkgtools/texlive2pkg.
 If the TeXlive package name is not known, it may be useful to search CTAN. A "
 Contained in" field on the package page typically identifies the basename of
 the package file in the TeXlive archive.
 If the TeXlive package name is known, download the files from the TeXlive
 archive. For package foo, you will need to download foo.tar.xz. Most TeXlive
 packages also have associated documentation packages, so download
 foo.doc.tar.xz at the same time. These files should be placed in the
 appropriate category directory, which is often but not always print. Then run
 the following command in the category directory.
 texlive2pkg foo.tar.xz foo.doc.tar.xz
 This will create two packages, tex-foo and tex-foo-doc. Be sure to check that
 both packages are correct.
 Finally, CTAN currently does not include version information in package
 filenames and changes their contents periodically when updates occur.
 Consequently, pkgsrc avoids downloading distfiles directly from CTAN and
 instead relies on the pkgsrc archives. For each new or updated TeXlive package,
 e.g., the main one and the corresponding documentation, upload the distfiles
 with the following command in each package directory.
 make upload-distfiles
 .2. Examples
 .2.1. How the www/nvu package came into pkgsrc
 .2.1.1. The initial package
 Looking at the file pkgsrc/doc/TODO, I saw that the "nvu" package has not yet
 been imported into pkgsrc. As the description says it has to do with the web,
 the obvious choice for the category is "www".
 $ mkdir www/nvu
 $ cd www/nvu
 The web site says that the sources are available as a tar file, so I fed that
 URL to the url2pkg program:
 $ url2pkg http://cvs.nvu.com/download/nvu-1.0-sources.tar.bz2
 My editor popped up, and I added a PKGNAME line below the DISTNAME line, as the
 package name should not have the word "sources" in it. I also filled in the
 MAINTAINER, HOMEPAGE and COMMENT fields. Then the package Makefile looked like
 that:
 # $NetBSD $
+#
 DISTNAME=       nvu-1.0-sources
 PKGNAME=        nvu-1.0
 CATEGORIES=     www
 MASTER_SITES=   http://cvs.nvu.com/download/
 EXTRACT_SUFX=   .tar.bz2
 MAINTAINER=     rillig@NetBSD.org
 HOMEPAGE=       http://cvs.nvu.com/
 COMMENT=        Web Authoring System
 # url2pkg-marker (please do not remove this line.)
 .include "../../mk/bsd.pkg.mk"
 On the first line of output above, an artificial space has been added between
 NetBSD and $, this is a workaround to prevent CVS expanding to the filename of
 the guide.
 Then, I quit the editor and watched pkgsrc downloading a large source archive:
 url2pkg> Running "make makesum" ...
 => Required installed package digest>=20010302: digest-20060826 found
 => Fetching nvu-1.0-sources.tar.bz2
 Requesting http://cvs.nvu.com/download/nvu-1.0-sources.tar.bz2
 % |*************************************| 28992 KB  150.77 KB/s00:00 ETA
 29687976 bytes retrieved in 03:12 (150.77 KB/s)
 url2pkg> Running "make extract" ...
 => Required installed package digest>=20010302: digest-20060826 found
 => Checksum SHA1 OK for nvu-1.0-sources.tar.bz2
 => Checksum RMD160 OK for nvu-1.0-sources.tar.bz2
 work.bacc -> /tmp/roland/pkgsrc/www/nvu/work.bacc
 ===> Installing dependencies for nvu-1.0
 ===> Overriding tools for nvu-1.0
 ===> Extracting for nvu-1.0
 url2pkg> Adjusting the Makefile.
 Remember to correct CATEGORIES, HOMEPAGE, COMMENT, and DESCR when you're done!
 Good luck! (See pkgsrc/doc/pkgsrc.txt for some more help :-)
 .2.1.2. Fixing all kinds of problems to make the package work
 Now that the package has been extracted, let's see what's inside it. The
 package has a README.txt, but that only says something about mozilla, so it's
 probably useless for seeing what dependencies this package has. But since there
 is a GNU configure script in the package, let's hope that it will complain
 about everything it needs.
 $ bmake
 => Required installed package digest>=20010302: digest-20060826 found
 => Checksum SHA1 OK for nvu-1.0-sources.tar.bz2
 => Checksum RMD160 OK for nvu-1.0-sources.tar.bz2
 ===> Patching for nvu-1.0
 ===> Creating toolchain wrappers for nvu-1.0
 ===> Configuring for nvu-1.0
 [...]
 configure: error: Perl 5.004 or higher is required.
 [...]
 WARNING: Please add USE_TOOLS+=perl to the package Makefile.
 [...]
 That worked quite well. So I opened the package Makefile in my editor, and
 since it already has a USE_TOOLS line, I just appended "perl" to it. Since the
 dependencies of the package have changed now, and since a perl wrapper is
 automatically installed in the "tools" phase, I need to build the package from
 scratch.
 $ bmake clean
 ===> Cleaning for nvu-1.0
 $ bmake
 [...]
 *** /tmp/roland/pkgsrc/www/nvu/work.bacc/.tools/bin/make is not \
 GNU Make.  You will not be able to build Mozilla without GNU Make.
 [...]
 So I added "gmake" to the USE_TOOLS line and tried again (from scratch).
 [...]
 checking for GTK - version >= 1.2.0... no
 *** Could not run GTK test program, checking why...
 [...]
 Now to the other dependencies. The first question is: Where is the GTK package
 hidden in pkgsrc?
 $ echo ../../*/gtk*
 [many packages ...]
 $ echo ../../*/gtk
 ../../x11/gtk
 $ echo ../../*/gtk2
 ../../x11/gtk2
 $ echo ../../*/gtk2/bui*
 ../../x11/gtk2/buildlink3.mk
 The first try was definitely too broad. The second one had exactly one result,
 which is very good. But there is one pitfall with GNOME packages. Before GNOME
 had been released, there were already many GNOME 1 packages in pkgsrc. To be
 able to continue to use these packages, the GNOME 2 packages were imported as
 separate packages, and their names usually have a "2" appended. So I checked
 whether this was the case here, and indeed it was.
 Since the GTK2 package has a buildlink3.mk file, adding the dependency is very
 easy. I just inserted an .include line before the last line of the package
 Makefile, so that it now looks like this:
 [...]
 .include "../../x11/gtk2/buildlink3.mk"
 .include "../../mk/bsd.pkg.mk
 After another bmake clean && bmake, the answer was:
 [...]
 checking for gtk-config... /home/roland/pkg/bin/gtk-config
 checking for GTK - version >= 1.2.0... no
 *** Could not run GTK test program, checking why...
 *** The test program failed to compile or link. See the file config.log for the
 *** exact error that occured. This usually means GTK was incorrectly installed
 *** or that you have moved GTK since it was installed. In the latter case, you
 *** may want to edit the gtk-config script: /home/roland/pkg/bin/gtk-config
 configure: error: Test for GTK failed.
 [...]
 In this particular case, the assumption that "every package prefers GNOME 2"
 had been wrong. The first of the lines above told me that this package really
 wanted to have the GNOME 1 version of GTK. If the package had looked for GTK2,
 it would have looked for pkg-config instead of gtk-config. So I changed the x11
 /gtk2 to x11/gtk in the package Makefile, and tried again.
 [...]
 cc -o xpidl.o -c -DOSTYPE=\"NetBSD3\" -DOSARCH=\"NetBSD\"  [...]
 In file included from xpidl.c:42:
 xpidl.h:53:24: libIDL/IDL.h: No such file or directory
 In file included from xpidl.c:42:
 xpidl.h:132: error: parse error before "IDL_ns"
 [...]
 The package still does not find all of its dependencies. Now the question is:
 Which package provides the libIDL/IDL.h header file?
 $ echo ../../*/*idl*
 ../../devel/py-idle ../../wip/idled ../../x11/acidlaunch
 $ echo ../../*/*IDL*
 ../../net/libIDL
 Let's take the one from the second try. So I included the ../../net/libIDL/
 buildlink3.mk file and tried again. But the error didn't change. After digging
 through some of the code, I concluded that the build process of the package was
 broken and couldn't have ever worked, but since the Mozilla source tree is
 quite large, I didn't want to fix it. So I added the following to the package
 Makefile and tried again:
 CPPFLAGS+=              -I${BUILDLINK_PREFIX.libIDL}/include/libIDL-2.0
 BUILDLINK_TRANSFORM+=   l:IDL:IDL-2
 The latter line is needed because the package expects the library libIDL.so,
 but only libIDL-2.so is available. So I told the compiler wrapper to rewrite
 that on the fly.
 The next problem was related to a recent change of the FreeType interface. I
 looked up in www/seamonkey which patch files were relevant for this issue and
 copied them to the patches directory. Then I retried, fixed the patches so that
 they applied cleanly and retried again. This time, everything worked.
 .2.1.3. Installing the package
 $ bmake CHECK_FILES=no install
 [...]
 $ bmake print-PLIST >PLIST
 $ bmake deinstall
 $ bmake install
 Chapter 15. Programming in Makefiles
 Table of Contents
 .1. Caveats
 .2. Makefile variables
 @@ -6136,2004 +6137,2003 @@ number of ways:
   * When extracting the distfiles, some packages may ask for passwords.
   * help to configure the package before it is built
   * help during the build process
   * help during the installation of a package
 A package can set the INTERACTIVE_STAGE variable to define which stages need
 interaction. This should be done in the package's Makefile, e.g.:
 INTERACTIVE_STAGE=      configure install
 The user can then decide to skip this package by setting the BATCH variable.
 Packages that require interaction are also excluded from bulk builds.
 .1.3. Handling licenses
 Authors of software can choose the licence under which software can be copied.
 The Free Software Foundation has declared some licenses "Free", and the Open
 Source Initiative has a definition of "Open Source".
 By default, pkgsrc allows packages with Free or Open Source licenses to be
 built. To allow packages with other licenses to be built as well, the pkgsrc
 user needs to add these licenses to the ACCEPTABLE_LICENSES variable in mk.conf
 . Note that this variable only affects which packages may be built, while the
 license terms often also restrict the actual use of the package and its
 redistribution.
 One might want to only install packages with a BSD license, or the GPL, and not
 the other. The free licenses are added to the default ACCEPTABLE_LICENSES
 variable. The pkgsrc user can override the default by setting the
 ACCEPTABLE_LICENSES variable with "=" instead of "+=". The licenses accepted by
 default are defined in the DEFAULT_ACCEPTABLE_LICENSES variable in the file
 pkgsrc/mk/license.mk.
 The license tag mechanism is intended to address copyright-related issues
 surrounding building, installing and using a package, and not to address
 redistribution issues (see RESTRICTED and NO_SRC_ON_FTP, etc.). Packages with
 redistribution restrictions should set these tags.
 Denoting that a package may be copied according to a particular license is done
 by placing the license in pkgsrc/licenses and setting the LICENSE variable to a
 string identifying the license, e.g. in graphics/xv:
 LICENSE=        xv-license
 When trying to build, the user will get a notice that the package is covered by
 a license which has not been placed in the ACCEPTABLE_LICENSES variable:
 % make
 ===> xv-3.10anb9 has an unacceptable license: xv-license.
 ===>     To view the license, enter "/usr/bin/make show-license".
 ===>     To indicate acceptance, add this line to your /etc/mk.conf:
 ===>     ACCEPTABLE_LICENSES+=xv-license
 *** Error code 1
 The license can be viewed with make show-license, and if the user so chooses,
 the line printed above can be added to mk.conf to convey to pkgsrc that it
 should not in the future fail because of that license:
 ACCEPTABLE_LICENSES+=xv-license
 The use of LICENSE=shareware, LICENSE=no-commercial-use, and similar language
 is deprecated because it does not crisply refer to a particular license text.
 Another problem with such usage is that it does not enable a user to tell
 pkgsrc to proceed for a single package without also telling pkgsrc to proceed
 for all packages with that tag.
 .1.3.1. Adding a package with a new license
 When adding a package with a new license, the following steps are required:
 . Check whether the license qualifies as Free or Open Source by referencing
     Various Licenses and Comments about Them and Licenses by Name | Open Source
     Initiative. If this is the case, the filename in pkgsrc/licenses/ does not
     need the -license suffix, and the license name should be added to:
       + DEFAULT_ACCEPTABLE_LICENSES in pkgsrc/mk/license.mk
       + default_acceptable_licenses in pkgsrc/pkgtools/pkg_install/files/lib/
         license.c
 . The license text should be added to pkgsrc/licenses for displaying. A list
     of known licenses can be seen in this directory.
 .1.3.2. Change to the license
 When the license changes (in a way other than formatting), make sure that the
 new license has a different name (e.g., append the version number if it exists,
 or the date). Just because a user told pkgsrc to build programs under a
 previous version of a license does not mean that pkgsrc should build programs
 under the new licenses. The higher-level point is that pkgsrc does not evaluate
 licenses for reasonableness; the only test is a mechanistic test of whether a
 particular text has been approved by either of two bodies (FSF or OSI).
 .1.4. Restricted packages
 Some licenses restrict how software may be re-distributed. By declaring the
 restrictions, package tools can automatically refrain from e.g. placing binary
 packages on FTP sites.
 There are four possible restrictions, which are the cross product of sources
 (distfiles) and binaries not being placed on FTP sites and CD-ROMs. Because
 this is rarely the exact language in any license, and because non-Free licenses
 tend to be different from each other, pkgsrc adopts a definition of FTP and
 CD-ROM. "FTP" means making the source or binary file available over the
 Internet at no charge. "CD-ROM" means making the source or binary available on
 some kind of media, together with other source and binary packages, which is
 sold for a distribution charge.
 In order to encode these restrictions, the package system defines five make
 variables that can be set to note these restrictions:
   * RESTRICTED
     This variable should be set whenever a restriction exists (regardless of
     its kind). Set this variable to a string containing the reason for the
     restriction. It should be understood that those wanting to understand the
     restriction will have to read the license, and perhaps seek advice of
     counsel.
   * NO_BIN_ON_CDROM
     Binaries may not be placed on CD-ROM containing other binary packages, for
     which a distribution charge may be made. In this case, set this variable to
     ${RESTRICTED}.
   * NO_BIN_ON_FTP
     Binaries may not made available on the Internet without charge. In this
     case, set this variable to ${RESTRICTED}. If this variable is set, binary
     packages will not be included on ftp.NetBSD.org.
   * NO_SRC_ON_CDROM
     Distfiles may not be placed on CD-ROM, together with other distfiles, for
     which a fee may be charged. In this case, set this variable to $
     {RESTRICTED}.
   * NO_SRC_ON_FTP
     Distfiles may not made available via FTP at no charge. In this case, set
     this variable to ${RESTRICTED}. If this variable is set, the distfile(s)
     will not be mirrored on ftp.NetBSD.org.
 Please note that packages will be removed from pkgsrc when the distfiles are
 not distributable and cannot be obtained for a period of one full quarter
 branch. Packages with manual/interactive fetch must have a maintainer and it is
 his/her responsibility to ensure this.
 .1.5. Handling dependencies
 Your package may depend on some other package being present, and there are
 various ways of expressing this dependency. pkgsrc supports the DEPENDS,
 BUILD_DEPENDS, TOOL_DEPENDS, and TEST_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 18, Buildlink methodology for more information.
 The basic difference is that the DEPENDS definition registers that
 pre-requisite in the binary package so it will be pulled in when the binary
 package is later installed, whilst the BUILD_DEPENDS, TOOL_DEPENDS, and
 TEST_DEPENDS definitions do not, marking a dependency that is only needed for
 building or testing the resulting package. See also Chapter 14, Creating a new
 pkgsrc package from scratch for more information.
 This means that if you only need a package present whilst you are building or
 testing, it should be noted as a TOOL_DEPENDS, BUILD_DEPENDS, or TEST_DEPENDS.
 When cross-compiling, TOOL_DEPENDS are native packages, i.e. packages for the
 architecture where the package is built; BUILD_DEPENDS are target packages,
 i.e., packages for the architecture for which the package is built.
 The format for a DEPENDS, BUILD_DEPENDS, TOOL_DEPENDS, and TEST_DEPENDS
 definition is:
 <pre-req-package-name>:../../<category>/<pre-req-package>
 Please note that the "pre-req-package-name" may include any of the wildcard
 version numbers recognized by pkg_info(1).
 . If your package needs another package's binaries or libraries to build and
     run, and if that package has a buildlink3.mk file available, use it:
     .include "../../graphics/jpeg/buildlink3.mk"
 . If your package needs another package's binaries or libraries only for
     building, and if that package has a buildlink3.mk file available, use it:
     .include "../../graphics/jpeg/buildlink3.mk"
     but set BUILDLINK_DEPMETHOD.jpeg?=build to make it a build dependency only.
     This case is rather rare.
 . If your package needs binaries from another package to build, use the
     TOOL_DEPENDS definition:
     TOOL_DEPENDS+= itstool-[0-9]*:../../textproc/itstool
 . If your package needs static libraries to link against, header files to
     include, etc. from another package to build, use the BUILD_DEPENDS
     definition.
 . If your package needs a library with which to link and there is no
     buildlink3.mk file available, create one. Using DEPENDS won't be sufficient
     because the include files and libraries will be hidden from the compiler.
 . If your package needs some executable to be able to run correctly and if
     there's no buildlink3.mk file, this is specified using the DEPENDS
     variable. The print/lyx package needs to be able to execute the latex
     binary from the tex-latex-bin package when it runs, and that is specified:
     DEPENDS+=        tex-latex-bin-[0-9]*:../../print/tex-latex-bin
 . If your package includes a test suite that has extra dependencies only
     required for this purpose (frequently this can be run as a "make test"
     target), use the TEST_DEPENDS variable.
 . You can use wildcards in package dependencies. Note that such wildcard
     dependencies are retained when creating binary packages. The dependency is
     checked when installing the binary package and any package which matches
     the pattern will be used. Wildcard dependencies should be used with care.
     The "-[0-9]*" should be used instead of "-*" to avoid potentially ambiguous
     matches such as "tk-postgresql" matching a "tk-*" DEPENDS.
     Wildcards can also be used to specify that a package will only build
     against a certain minimum version of a pre-requisite:
     DEPENDS+=       ImageMagick>=6.0:../../graphics/ImageMagick
     This means that the package will build using version 6.0 of ImageMagick or
     newer. Such a dependency may be warranted if, for example, the command line
     options of an executable have changed.
     If you need to depend on minimum versions of libraries, set
     BUILDLINK_API_DEPENDS.pkg to the appropriate pattern before including its
     buildlink3.mk file, e.g.
     BUILDLINK_API_DEPENDS.jpeg+=    jpeg>=9.0
     .include "../../graphics/jpeg/buildlink3.mk"
     For security fixes, please update the package vulnerabilities file. See
     Section 21.1.9, "Handling packages with security problems" for more
     information.
 If your package needs files from another package to build, add the relevant
 distribution files to DISTFILES, so they will be extracted automatically. See
 the print/ghostscript package for an example. (It relies on the jpeg sources
 being present in source form during the build.)
 .1.6. Handling conflicts with other packages
 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 as
 another package in the pkgsrc tree or has the same PKGNAME.
 For example, x11/libXaw3d and x11/Xaw-Xpm install the same shared library, thus
 you set in pkgsrc/x11/libXaw3d/Makefile:
 CONFLICTS=      Xaw-Xpm-[0-9]*
 and in pkgsrc/x11/Xaw-Xpm/Makefile:
 CONFLICTS=      libXaw3d-[0-9]*
 pkg_add(1) is able to detect attempts to install packages that conflict with
 existing packages and abort. However, in many situations this is too late in
 the process. Binary package managers will not know about the conflict until
 they attempt to install the package after already downloading it and all its
 dependencies. Users may also waste time building a package and its dependencies
 only to find out at the end that it conflicts with another package they have
 installed.
 To avoid these issues CONFLICTS entries should be added in all cases where it
 is known that packages conflict with each other. These CONFLICTS entries are
 exported in pkg_summary(5) files and consumed by binary package managers to
 inform users that packages cannot be installed onto the target system.
 .1.7. Packages that cannot or should not be built
 There are several reasons why a package might be instructed to not build under
 certain circumstances. If the package builds and runs on most platforms, the
 exceptions should be noted with BROKEN_ON_PLATFORM. If the package builds and
 runs on a small handful of platforms, set BROKEN_EXCEPT_ON_PLATFORM instead.
 Both BROKEN_ON_PLATFORM and BROKEN_EXCEPT_ON_PLATFORM are OS triples
 (OS-version-platform) that can use glob-style wildcards.
 If a package is not appropriate for some platforms (as opposed to merely
 broken), a different set of variables should be used as this affects failure
 reporting and statistics. If the package is appropriate for most platforms, the
 exceptions should be noted with NOT_FOR_PLATFORM. If the package is appropriate
 for only a small handful of platforms (often exactly one), set
 ONLY_FOR_PLATFORM instead. Both ONLY_FOR_PLATFORM and NOT_FOR_PLATFORM are OS
 triples (OS-version-platform) that can use glob-style wildcards.
 Some packages are tightly bound to a specific version of an operating system,
 e.g. LKMs or sysutils/lsof. Such binary packages are not backwards compatible
 with other versions of the OS, and should be uploaded to a version specific
 directory on the FTP server. Mark these packages by setting OSVERSION_SPECIFIC
 to "yes". This variable is not currently used by any of the package system
 internals, but may be used in the future.
 If the package should be skipped (for example, because it provides
 functionality already provided by the system), set PKG_SKIP_REASON to a
 descriptive message. If the package should fail because some preconditions are
 not met, set PKG_FAIL_REASON to a descriptive message.
 .1.8. Packages which should not be deleted, once installed
 To ensure that a package may not be deleted, once it has been installed, the
 PKG_PRESERVE definition should be set in the package Makefile. This will be
 carried into any binary package that is made from this pkgsrc entry. A "
 preserved" package will not be deleted using pkg_delete(1) unless the "-f"
 option is used.
 .1.9. Handling packages with security problems
 When a vulnerability is found, this should be noted in localsrc/security/
 advisories/pkg-vulnerabilities. Entries in that file consist of three parts:
   * package version pattern
   * type of vulnerability (please cut'n'paste an existing one where possible)
   * URL providing additional information about the issue
 For the package version pattern please always use `<' to mark an upper bound
 (not `<='!). This will avoid possible problems due unrelated PKGREVISION bumps
 not related to security fixes. Lower bounds can be added too, using '>' or '>=
 '. For example, "foo>=1<1.2" would mark versions 1.0 (included) to 1.2
 (excluded) of "foo" as affected by the security issue.
 Entries should always be added at the bottom of the file.
 When fixing packages, please modify the upper bound of the corresponding entry.
 To continue the previous example, if a fix was backported to version 1.1nb2,
 change the previous pattern to "foo>=1<1.1nb2".
 To locally test a package version pattern against a PKGNAME you can use the
 pkg_admin pmatch command.
 The URL should be as permanent as possible and provide as much information
 about the issue as possible. CVE entries are preferred.
 After committing that file, ask pkgsrc-security@NetBSD.org to update the file
 on ftp.NetBSD.org.
 After fixing the vulnerability by a patch, its PKGREVISION should be increased
 (this is of course not necessary if the problem is fixed by using a newer
 release of the software), and the pattern in the pkg-vulnerabilities file must
 be updated.
 Also, if the fix should be applied to the stable pkgsrc branch, be sure to
 submit a pullup request!
 Binary packages already on ftp.NetBSD.org will be handled semi-automatically by
 a weekly cron job.
 In case a security issue is disputed, please contact
 pkgsrc-security@NetBSD.org.
 .1.10. How to handle incrementing versions when fixing an existing package
 When making fixes to an existing package it can be useful to change the version
 number in PKGNAME. To avoid conflicting with future versions by the original
 author, a "nb1", "nb2", ... suffix can be used on package versions by setting
 PKGREVISION=1 (2, ...). The "nb" is treated like a "." by the package tools.
 e.g.
 DISTNAME=       foo-17.42
 PKGREVISION=    9
 will result in a PKGNAME of "foo-17.42nb9". If you want to use the original
 value of PKGNAME without the "nbX" suffix, e.g. for setting DIST_SUBDIR, use
 PKGNAME_NOREV.
 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
 like:
 DISTNAME=       foo-17.43
 PKGREVISION should be incremented for any non-trivial change in the resulting
 binary package. Without a PKGREVISION bump, someone with the previous version
 installed has no way of knowing that their package is out of date. Thus,
 changes without increasing PKGREVISION are essentially labeled "this is so
 trivial that no reasonable person would want to upgrade", and this is the rough
 test for when increasing PKGREVISION is appropriate. Examples of changes that
 do not merit increasing PKGREVISION are:
   * Changing HOMEPAGE, MAINTAINER, OWNER, or comments in Makefile.
   * Changing build variables if the resulting binary package is the same.
   * Changing DESCR.
   * Adding PKG_OPTIONS if the default options don't change.
 Examples of changes that do merit an increase to PKGREVISION include:
   * Security fixes
   * Changes or additions to a patch file
   * Changes to the PLIST
   * A dependency is changed or renamed.
 PKGREVISION must also be incremented when dependencies have ABI changes.
 .1.11. Substituting variable text in the package files (the SUBST framework)
 When you want to replace the same text in multiple files, or multiple times in
 the same file, it is cumbersome to maintain a patch file for this. This is
 where the SUBST framework steps in. It provides an easy-to-use interface for
 replacing text in files. It just needs the following information:
   * In which phase of the package build cycle should the replacement happen?
   * In which files should the replacement happen?
   * Which text should be replaced with what?
 This information is encoded in a block of SUBST variables. A minimal example
 is:
 SUBST_CLASSES+=         paths
 SUBST_STAGE.paths=      pre-configure
 SUBST_FILES.paths=      src/*.c
 SUBST_SED.paths=        -e 's,/usr/local,${PREFIX},g'
 Translated into English, it means: In the pre-configure stage (that is, after
 applying the patches from the patches/ directory and before running the
 configure script and the portability check), replace the text /usr/local with
 the content of the variable PREFIX.
 Each SUBST block starts by appending an identifier to SUBST_CLASSES (note the +
 =). This identifier can be chosen freely by the package. If there should ever
 be duplicate identifiers, the pkgsrc infrastructure will catch this and fail
 early, so don't worry about name collisions.
 Except for SUBST_CLASSES, all variables in a SUBST block are parameterized
 using this identifier. In the remainder of this section, these parameterized
 variables are written as SUBST_STAGE.*.
 SUBST_CLASSES+=         paths
 SUBST_STAGE.paths=      pre-configure
 SUBST_MESSAGE.paths=    Fixing absolute paths.
 SUBST_FILES.paths=      src/*.c
 SUBST_FILES.paths+=     scripts/*.sh
 SUBST_SED.paths=        -e 's,"/usr/local,"${PREFIX},g'
 SUBST_SED.paths+=       -e 's,"/var/log,"${VARBASE}/log,g'
 SUBST_VARS.paths=       LOCALBASE PREFIX PKGVERSION
 To get a complete picture about the SUBST substitutions, run bmake
 show-all-subst. If something doesn't work as expected, run pkglint on the
 package, which detects several typical mistakes surrounding the SUBST blocks.
 For any questions that might remain after this, have a look at mk/subst.mk.
 .1.11.1. Choosing the time where the substitutions happen
 The SUBST_STAGE.* is one of {pre,do,post}-
 {extract,patch,configure,build,test,install}. Of these, pre-configure is used
 most often, by far. The most popular stages are, in chronological order:
 post-extract
     The substitutions are applied immediately after the distfiles are
     extracted. Running bmake extract on the package will leave no traces of the
     original files.
     When the substitution applies to files for which there is also a patch in
     the patches/ directory, this means that the patches will be computed based
     on the result of the substitution. When these patches are sent to the
     upstream maintainer later, to be fixed in the upstream package, these
     patches may no longer match what the upstream author is used to. Because of
     this, pre-configure is often a better choice.
 pre-configure
     The substitutions are applied after the patches from the patches/
     directory. This makes it possible to run bmake patch on the package, after
     which the patches can be edited using the tools pkgvi and mkpatches from
     the pkgtools/pkgdiff package.
     When updating the patches, it is helpful to explicitly separate the bmake
     patch from the bmake configure, and to only edit the patches between these
     commands. Otherwise the substitutions from the SUBST block will end up in
     the patch file. When this happens in really obvious ways, pkglint will
     complain about patches that contain a hard-coded /usr/pkg instead of the
     correct and intended @PREFIX@, but it can only detect these really obvious
     cases.
 do-configure
     This stage should only be used if the package defines a pre-configure
     action itself, and the substitution must happen after that. Typical
     examples are packages that use the pre-configure stage to regenerate the
     GNU configure script from configure.ac.
 post-configure
     This stage is used to fix up any mistakes by the configure stage.
 pre-build
     This stage should only be used for substitutions that are clearly related
     to building the package, not for fixing the configuration. Substitutions
     for pathnames (such as replacing /usr/local with ${PREFIX}) or user names
     (such as replacing @MY_USER@ with the actual username) belong in
     pre-configure or post-configure instead.
 post-build
     Just as with pre-build, this stage should only be used for substitutions
     that are clearly related to building the package, not for fixing the
     configuration. Substitutions for pathnames (such as replacing /usr/local
     with ${PREFIX}) or user names (such as replacing @MY_USER@ with the actual
     username) belong in pre-configure or post-configure instead.
     A typical use is to update pkg-config files to include the rpath compiler
     options.
 pre-install
     In general, the install phase should be as simple as possible. As with the
     pre-build and post-build stages, it should not be used to fix pathnames or
     user names, these belong in pre-configure instead. There are only few
     legitimate use cases for applying substitutions in this stage.
 .1.11.2. Choosing the files where the substitutions happen
 The SUBST_FILES.* variable contains a list of filename patterns. These patterns
 are relative to WRKSRC since that is where most substitutions happen. A typical
 example is:
 SUBST_FILES.path=       Makefile */Makefile */*/Makefile *.[ch]
 The above patterns, especially the last, are quite broad. The SUBST
 implementation checks that each filename pattern that is mentioned here has an
 effect. For example, if none of the */*/Makefile files contains the patterns to
 be found and substituted, that filename pattern is redundant and should be left
 out. By default, the SUBST framework will complain with an error message. If
 the text to be substituted occurs in some of the files from a single pattern,
 but not in all of them, that is totally ok, and the SUBST framework will only
 print an INFO message for those files.
 If there is a good reason for having redundant filename patterns, set
 SUBST_NOOP_OK.* to yes.
 Another popular way of choosing the files for the substitutions is via a shell
 command, like this:
 C_FILES_CMD=            cd ${WRKSRC} && ${FIND} . -name '*.c'
 SUBST_FILES.path=       ${C_FILES_CMD:sh}
 The variable name C_FILES_CMD in this example is freely chosen and independent
 of the SUBST framework.
 In this variant, the SUBST_FILES.* variable lists each file individually.
 Thereby chances are higher that there are filename patterns in which no
 substitution happens. Since the SUBST framework cannot know whether the
 filename patterns in SUBST_FILES.* have been explicitly listed in the Makefile
 (where any redundant filename pattern would be suspicious) or been generated by
 a shell command (in which redundant filename patterns are more likely and to be
 expected), it will complain about these redundant filename patterns. Therefore,
 SUBST blocks that use a shell command to generate the list of filename patterns
 often need to set SUBST_NOOP_OK.* to yes.
 .1.11.3. Choosing what to substitute
 In most cases, the substitutions are given using one or more sed(1) commands,
 like this:
 SUBST_SED.path=         -e 's|/usr/local|${PREFIX}|g'
 Each of the sed commands needs to be preceded by the -e option and should be
 specified on a line of its own, to avoid hiding short sed commands at the end
 of a line.
 Since the sed commands often contain shell metacharacters as the separator (the
 | in the above example), it is common to enclose them in single quotes.
 A common substitution is to replace placeholders of the form @VARNAME@ with
 their pkgsrc counterpart variable ${VARNAME}. A typical example is:
 SUBST_VARS.path=        PREFIX
 This type of substitutions is typically done by the GNU configure scripts
 during the do-configure stage, but in some cases these need to be overridden.
 The same pattern is also used when a package defines patches that replace
 previously hard-coded paths like /usr/local with a @PREFIX@ placeholder first,
 which then gets substituted by the actual ${PREFIX} in the pre-configure stage.
 In many of these cases, it works equally well to just use the SUBST framework
 to directly replace /usr/local with ${PREFIX}, thereby omitting the
 intermediate patch file.
 If the above is not flexible enough, it is possible to not use sed at all for
 the substitution but to specify an entirely different command, like this:
 SUBST_FILTER_CMD.path=  LC_ALL=C ${TR} -d '\r'
 This is used for the few remaining packages in which the distributed files use
 Windows-style line endings that need to be converted to UNIX-style line
 endings.
 .1.11.4. Other SUBST variables
 When a SUBST block is applied during a package build, a message is logged. The
 default message is fine for most purposes but can be overridden by setting
 SUBST_MESSAGE.* to an individual message.
 .2. The fetch phase
 .2.1. Packages whose distfiles aren't available for plain downloading
 If you need to download from a dynamic URL you can set DYNAMIC_MASTER_SITES and
 a make fetch will call files/getsite.sh with the name of each file to download
 as an argument, expecting it to output the URL of the directory from which to
 download it. graphics/ns-cult3d is an example of this usage.
 If the download can't be automated, because the user must submit personal
 information to apply for a password, or must pay for the source, or whatever,
 you can set FETCH_MESSAGE to a list of lines that are displayed to the user
 before aborting the build. Example:
 FETCH_MESSAGE=  "Please download the files"
 FETCH_MESSAGE+= "    "${DISTFILES:Q}
 FETCH_MESSAGE+= "manually from "${MASTER_SITES:Q}"."
 .2.2. How to handle modified distfiles with the 'old' name
 Sometimes authors of a software package make some modifications after the
 software was released, and they put up a new distfile without changing the
 package's version number. If a package is already in pkgsrc at that time, the
 checksum will no longer match. The contents of the new distfile should be
 compared against the old one before changing anything, to make sure the
 distfile was really updated on purpose, and that no trojan horse or so crept
 in. Please mention that the distfiles were compared and what was found in your
 commit message.
 Then, the correct way to work around this is to set DIST_SUBDIR to a unique
 directory name, usually based on PKGNAME_NOREV (but take care with python or
 ruby packages, where PKGNAME includes a variable prefix). All DISTFILES and
 PATCHFILES for this package will be put in that subdirectory of the local
 distfiles directory. (See Section 21.1.10, "How to handle incrementing versions
 when fixing an existing package" for more details.) In case this happens more
 often, PKGNAME can be used (thus including the nbX suffix) or a date stamp can
 be appended, like ${PKGNAME_NOREV}-YYYYMMDD.
 DIST_SUBDIR is also used when a distfile's name does not contain a version and
 the distfile is apt to change. In cases where the likelihood of this is very
 small, DIST_SUBDIR might not be required. Additionally, DIST_SUBDIR must not be
 removed unless the distfile name changes, even if a package is being moved or
 renamed.
 Do not forget regenerating the distinfo file after that, since it contains the
 DIST_SUBDIR path in the filenames. Also, increase the PKGREVISION if the
 installed package is different. Furthermore, a mail to the package's authors
 seems appropriate telling them that changing distfiles after releases without
 changing the file names is not good practice.
 .2.3. Packages hosted on github.com
 Helper methods exist for packages hosted on github.com which will often have
 distfile names that clash with other packages, for example 1.0.tar.gz. Use one
 of the three recipes from below:
 .2.3.1. Fetch based on a tagged release
 If your distfile URL looks similar to https://github.com/username/example/
 archive/v1.0.zip, then you are packaging a tagged release.
 DISTNAME=       example-1.0
 MASTER_SITES=   ${MASTER_SITE_GITHUB:=username/}
 #GITHUB_PROJECT= example    # can be omitted if same as DISTNAME
 GITHUB_TAG=     v${PKGVERSION_NOREV}
 EXTRACT_SUFX=   .zip
 .2.3.2. Fetch based on a specific commit before the first release
 If your distfile looks similar to https://github.com/username/example/archive/
 adc9fc3655077dc2d4d757d480b5ea0e11 and is from a commit before the first
 release, then set the package version to 0.0.0.N, where N is the number of
 commits to the repository, and set GITHUB_TAG to the commit hash. This will
 (almost) ensure that the first tagged release will have a version greater than
 this one so that package upgrades will function properly.
 DISTNAME=       example-0.0.0.347
 MASTER_SITES=   ${MASTER_SITE_GITHUB:=username/}
 #GITHUB_PROJECT= example    # can be omitted if same as DISTNAME
 GITHUB_TAG=     988881adc9fc3655077dc2d4d757d480b5ea0e11
 .2.3.3. Fetch based on a specific commit after a release
 If your distfile looks similar to https://github.com/username/example/archive/
 adc9fc3655077dc2d4d757d480b5ea0e11 and is from a commit after a release,
 then include the last release version and the commit count since that release
 in the package version and set GITHUB_TAG to the commit hash. The latest
 release and commit count are shown in the output of "git describe --tags":
 # git clone https://github.com/username/example
 # cd example
 # git describe --tags
 .2.3-5-g988881a
 DISTNAME=       example-1.2.3.5
 MASTER_SITES=   ${MASTER_SITE_GITHUB:=username/}
 #GITHUB_PROJECT= example    # can be omitted if same as DISTNAME
 GITHUB_TAG=     988881adc9fc3655077dc2d4d757d480b5ea0e11
 .2.3.4. Fetch based on release
 If your distfile URL looks similar to https://github.com/username/example/
 releases/download/rel-1.6/offensive-1.6.zip, then you are packaging a release.
 DISTNAME=       offensive-1.6
 PKGNAME=        ${DISTNAME:S/offensive/proper/}
 MASTER_SITES=   ${MASTER_SITE_GITHUB:=username/}
 GITHUB_PROJECT= example
 GITHUB_RELEASE= rel-${PKGVERSION_NOREV} # usually just set this to ${DISTNAME}
 EXTRACT_SUFX=   .zip
 .3. The configure phase
 .3.1. Shared libraries - libtool
 pkgsrc supports many different machines, with different object formats like
 a.out and ELF, and varying abilities to do shared library and dynamic loading
 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.
 Here's how to use libtool in a package in seven simple steps:
 . Add USE_LIBTOOL=yes to the package Makefile.
 . For library objects, use "${LIBTOOL} --mode=compile ${CC}" in place of "$
     {CC}". You could even add it to the definition of CC, if only libraries are
     being built in a given Makefile. This one command will build both PIC and
     non-PIC library objects, so you need not have separate shared and
     non-shared library rules.
 . For the linking of the library, remove any "ar", "ranlib", and "ld
     -Bshareable" commands, and instead use:
     ${LIBTOOL} --mode=link \
         ${CC} -o ${.TARGET:.a=.la} \
             ${OBJS:.o=.lo} \
             -rpath ${PREFIX}/lib \
             -version-info major:minor
     Note that the library is changed to have a .la extension, and the objects
     are changed to have a .lo extension. Change OBJS as necessary. This
     automatically creates all of the .a, .so.major.minor, and ELF symlinks (if
     necessary) in the build directory. Be sure to include "-version-info",
     especially when major and minor are zero, as libtool will otherwise strip
     off the shared library version.
     From the libtool manual:
     So, libtool library versions are described by three integers:
     CURRENT
     The most recent interface number that this library implements.
     REVISION
     The implementation number of the CURRENT interface.
     AGE
     The difference between the newest and oldest interfaces that
     this library implements.  In other words, the library implements
     all the interface numbers in the range from number `CURRENT -
     AGE' to `CURRENT'.
     If two libraries have identical CURRENT and AGE numbers, then the
     dynamic linker chooses the library with the greater REVISION number.
     The "-release" option will produce different results for a.out and ELF
     (excluding symlinks) in only one case. An ELF library of the form "
     libfoo-release.so.x.y" will have a symlink of "libfoo.so.x.y" on an a.out
     platform. This is handled automatically.
     The "-rpath argument" is the install directory of the library being built.
     In the PLIST, include only the .la file, the other files will be added
     automatically.
 . When linking shared object (.so) files, i.e. files that are loaded via
     dlopen(3), NOT shared libraries, use "-module -avoid-version" to prevent
     them getting version tacked on.
     The PLIST file gets the foo.so entry.
 . When linking programs that depend on these libraries before they are
     installed, preface the cc(1) or ld(1) line with "${LIBTOOL} --mode=link",
     and it will find the correct libraries (static or shared), but please be
     aware that libtool will not allow you to specify a relative path in -L
     (such as "-L../somelib"), because it expects you to change that argument to
     be the .la file. e.g.
     ${LIBTOOL} --mode=link ${CC} -o someprog -L../somelib -lsomelib
     should be changed to:
     ${LIBTOOL} --mode=link ${CC} -o someprog ../somelib/somelib.la
     and it will do the right thing with the libraries.
 . When installing libraries, preface the install(1) or cp(1) command with "$
     {LIBTOOL} --mode=install", and change the library name to .la. e.g.
     ${LIBTOOL} --mode=install ${BSD_INSTALL_LIB} ${SOMELIB:.a=.la} ${PREFIX}/lib
     This will install the static .a, shared library, any needed symlinks, and
     run ldconfig(8).
 . In your PLIST, include only the .la file (this is a change from previous
     behaviour).
 .3.2. Using libtool on GNU packages that already support libtool
 Add USE_LIBTOOL=yes to the package Makefile. This will override the package's
 own libtool in most cases. For older libtool using packages, libtool is made by
 ltconfig script during the do-configure step; you can check the libtool script
 location by doing make configure; find work*/ -name libtool.
 LIBTOOL_OVERRIDE specifies which libtool scripts, relative to WRKSRC, to
 override. By default, it is set to "libtool */libtool */*/libtool". If this
 does not match the location of the package's libtool script(s), set it as
 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
 dynamic shared objects, that comes with libtool (libltdl), you should include
 devel/libltdl/buildlink3.mk.
 Some packages use libtool incorrectly so that the package may not work or build
 in some circumstances. Some of the more common errors are:
   * The inclusion of a shared object (-module) as a dependent library in an
     executable or library. This in itself isn't a problem if one of two things
     has been done:
 . The shared object is named correctly, i.e. libfoo.la, not foo.la
 . The -dlopen option is used when linking an executable.
   * The use of libltdl without the correct calls to initialisation routines.
     The function lt_dlinit() should be called and the macro
     LTDL_SET_PRELOADED_SYMBOLS included in executables.
 .3.3. GNU Autoconf/Automake
 If a package needs GNU autoconf or automake to be executed to regenerate the
 configure script and Makefile.in makefile templates from configure.ac and
 Makefile.am, then they should be executed in a pre-configure target:
 USE_TOOLS+=     autoconf automake autoreconf
 GNU_CONFIGURE=  yes
 ...
 pre-configure:
         set -e; cd ${WRKSRC} && autoreconf -fi
 ...
 Packages which use GNU Automake will sometimes require GNU Make (gmake in
 USE_TOOLS), but not always. Note that autoreconf only needs to be executed if
 configure.ac or Makefiles are modified, or configure is not present.
 There are times when the configure process makes additional changes to the
 generated files, which then causes the build process to try to re-execute the
 automake sequence. This is prevented by touching various files in the configure
 stage. If this causes problems with your package you can set AUTOMAKE_OVERRIDE=
 NO in the package Makefile.
 .3.4. Meson / ninja
 Packages using Meson to configure need to include:
 .include "../../devel/meson/build.mk"
 In nearly all cases (any program with dependencies), pkg-config needs to be
 added to USE_TOOLS. If the package installs translation files for non-English
 languages, also add msgfmt and xgettext:
 USE_TOOLS+=     pkg-config msgfmt xgettext
 If any options need to be passed to Meson, use MESON_ARGS instead of
 CONFIGURE_ARGS:
 MESON_ARGS+=    -Dx11=false
 .4. Programming languages
 .4.1. C, C++, and Fortran
 Compilers for the C and C++ languages comes with the NetBSD base system. By
 default, pkgsrc assumes that a package is written in C and will hide all other
 compilers (via the wrapper framework, see Chapter 18, Buildlink methodology).
 To declare which language's compiler a package needs, set the USE_LANGUAGES
 variable. Allowed values currently are:
         c99, c++, c++03, gnu++03, c++0x, gnu++0x, c++11, gnu++11,
         c++14, gnu++14, c++17, gnu++17, c++20, gnu++20, fortran,
         fortran77, java, objc, obj-c++, and ada.
 (and any combination). The default is "c". Packages using GNU configure
 scripts, even if written in C++, usually need a C compiler for the configure
 phase.
 To express a general requirement on a specific C or C++ version, normally only
 GCC_REQD needs to be set. For example, GCC 7 includes support for C++17, so if
 the package uses C++17 it should specify:
         GCC_REQD+=      7
 Language variants like c++11 for USE_LANGUAGES should only be specified if the
 package does not explicitly set -std=... when compiling (i.e. the package
 assumes the compiler defaults to C++11 or some other standard). This is usually
 a bug in the upstream build system.
 GCC version 5 includes support for C++14, while GCC 4.7 includes more-or-less
 complete support for C++11. For more information, consult GCC's own
 documentation on programming language support.
 .4.2. Java
 If a program is written in Java, use the Java framework in pkgsrc. The package
 must include ../../mk/java-vm.mk. This Makefile fragment provides the following
 variables:
   * USE_JAVA defines if a build dependency on the JDK is added. If USE_JAVA is
     set to "run", then there is only a runtime dependency on the JDK. The
     default is "yes", which also adds a build dependency on the JDK.
   * Set USE_JAVA2 to declare that a package needs a Java2 implementation. The
     supported values are "yes", "1.4", and "1.5". "yes" accepts any Java2
     implementation, "1.4" insists on versions 1.4 or above, and "1.5" only
     accepts versions 1.5 or above. This variable is not set by default.
   * PKG_JAVA_HOME is automatically set to the runtime location of the used Java
     implementation dependency. It may be used to set JAVA_HOME to a good value
     if the program needs this variable to be defined.
 .4.3. Go
 If a program is written in Go and has any dependencies on other Go modules,
 have the package include ../../lang/go/go-module.mk.
 . Generate a list of those dependencies with make clean && make patch && make
     show-go-modules > go-modules.mk.
 . Prepend .include "go-modules.mk" to any other .includes.
 . Incorporate these modules in distinfo with make makesum.
 .4.4. Rust
 If a program is written in Rust and uses Cargo to build, have the package
 include ../../lang/rust/cargo.mk.
 . Generate a list of those dependencies with make CARGO_ARGS="build
     --release" build && make print-cargo-depends > cargo-depends.mk.
 . Prepend .include "cargo-depends.mk" to any other .includes.
 . Incorporate these modules in distinfo with make makesum.
 .4.5. Packages containing Perl scripts
 If your package contains interpreted Perl scripts, add "perl" to the USE_TOOLS
 variable and set REPLACE_PERL to ensure that the proper interpreter path is
 set. REPLACE_PERL should contain a list of scripts, relative to WRKSRC, that
 you want adjusted. Every occurrence of */bin/perl in a she-bang line will be
 replaced with the full path to the Perl executable.
 If a particular version of Perl is needed, set the PERL5_REQD variable to the
 version number. The default is "5.0".
 See Section 21.6.6, "Packages installing Perl modules" for information about
 handling Perl modules.
 There is also the REPLACE_PERL6 variable for the language now known as Raku.
 .4.6. Packages containing shell scripts
 REPLACE_SH, REPLACE_BASH, REPLACE_CSH, and REPLACE_KSH can be used to replace
-shell hash bangs in files. Please use the appropriate one, preferring
+shell she-bangs in files. Please use the appropriate one, preferring REPLACE_SH
-REPLACE_SH in case this shell is sufficient. Each should contain a list of
+when this shell is sufficient. Each should contain a list of scripts, relative
-scripts, relative to WRKSRC, that you want adjusted. Every occurrence of the
+to WRKSRC, that you want adjusted. Every occurrence of the matching shell in a
-matching shell in a she-bang line will be replaced with the full path to the
+she-bang line will be replaced with the full path to the shell executable. When
-shell executable. When using REPLACE_BASH, don't forget to add bash to
+using REPLACE_BASH, don't forget to add bash to USE_TOOLS.
 USE_TOOLS.
 .4.7. Other programming languages
 There are further similar REPLACE variables available, e.g., REPLACE_AWK for
 packages containing awk scripts, and REPLACE_R for R. These two, like the
 others noted above, have their actions defined centrally in mk/configure/
 replace-interpreter.mk. Other languages define the actions of these variables
 within their own dedicated part of the tree, e.g., REPLACE_PHP is actioned in
 lang/php/phpversion.mk, and REPLACE_PYTHON is actioned in lang/python/
 application.mk. For other languages, consult the mk files found within their
 specific directories (the naming convention varies), or check the list found in
 Appendix E, Help topics.
 Currently, special handling for other languages varies in pkgsrc. If a compiler
 package provides a buildlink3.mk file, include that, otherwise just add a
 (build) dependency on the appropriate compiler package.
 .5. The build phase
 The most common failures when building a package are that some platforms do not
 provide certain header files, functions or libraries, or they provide the
 functions in a library that the original package author didn't know. To work
 around this, you can rewrite the source code in most cases so that it does not
 use the missing functions or provides a replacement function.
 .5.1. Compiling C and C++ code conditionally
 If a package already comes with a GNU configure script, the preferred way to
 fix the build failure is to change the configure script, not the code. In the
 other cases, you can utilize the C preprocessor, which defines certain macros
 depending on the operating system and hardware architecture it compiles for.
 These macros can be queried using for example #if defined(__i386). Almost every
 operating system, hardware architecture and compiler has its own macro. For
 example, if the macros __GNUC__, __i386__ and __NetBSD__ are all defined, you
 know that you are using NetBSD on an i386 compatible CPU, and your compiler is
 GCC.
 The list of the following macros for hardware and operating system depends on
 the compiler that is used. For example, if you want to conditionally compile
 code on Solaris, don't use __sun__, as the SunPro compiler does not define it.
 Use __sun instead.
 .5.1.1. C preprocessor macros to identify the operating system
 To distinguish between specific NetBSD versions, you should use the following
 code.
 #ifdef __NetBSD__
 #include <sys/param.h>
 #if __NetBSD_Prereq__(9,99,17)
 /* use a newer feature */
 #else
 /* older code */
 #endif
 #endif
 #ifndef _WIN32
 /* Unix-like specific code */
 #endif
 To distinguish between 4.4 BSD-derived systems and the rest of the world, you
 should use the following code.
 #include <sys/param.h>
 #if (defined(BSD) && BSD >= 199306)
 /* BSD-specific code goes here */
 #else
 /* non-BSD-specific code goes here */
 #endif
 You can also test for the following macros:
 Cygwin      __CYGWIN__
 DragonFly   __DragonFly__
 FreeBSD     __FreeBSD__
 Haiku       __HAIKU__
 Interix     __INTERIX
 IRIX        __sgi (TODO: get a definite source for this)
 Linux       __linux
 Mac OS X    __APPLE__
 MirBSD      __MirBSD__ (__OpenBSD__ is also defined)
 Minix3      __minix
 NetBSD      __NetBSD__
 OpenBSD     __OpenBSD__
 Solaris     sun, __sun
 .5.1.2. C preprocessor macros to identify the hardware architecture
 i386        i386, __i386, __i386__
 x86-64      __amd64__, __x86_64__
 ARM         __arm__
 MIPS        __mips
 SPARC       sparc, __sparc
 PowerPC     __powerpc
 .5.1.3. C preprocessor macros to identify the compiler
 GCC         __GNUC__ (major version), __GNUC_MINOR__
 MIPSpro     _COMPILER_VERSION (0x741 for MIPSpro 7.41)
 SunPro      __SUNPRO_C (0x570 for Sun C 5.7)
 SunPro C++  __SUNPRO_CC (0x580 for Sun C++ 5.8)
 .5.2. How to handle compiler bugs
 Some source files trigger bugs in the compiler, based on combinations of
 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,
 disabling optimisation for that combination of file, MACHINE_ARCH and compiler.
 This used to be a big problem in the past, but is rarely needed now as compiler
 technology has matured. If you still need to add a compiler specific
 workaround, please do so in the file hacks.mk and describe the symptom and
 compiler version as detailed as possible.
 .5.3. No such file or directory
 Compilation sometimes fails with an error message like this:
 .../x11/gtk3/work/gtk+-3.24.12/gdk/gdktypes.h:35:10:
     fatal error: pango/pango.h: No such file or directory
 The proper way to fix this problem depends on the type of the header, which is
 described in the following sections.
 .5.3.1. Headers from other packages
 If the header name looks like it comes from a different package, that other
 package should be included via the buildlink3 framework.
 First, look whether the header is somewhere in the buildlink3 directory below
 WRKDIR. In the above case of the missing Pango header:
 $ find work/.buildlink/ -print | grep -F pango/pango.h
 In the case of Pango, the output is:
 work/.buildlink/include/pango-1.0/pango/pango.h
 If the pango/pango.h file were placed directly in the .buildlink directory, it
 would have been found automatically. There is an extra pango-1.0 path component
 though, which means that the compiler command line must contain an option of
 the form -I${BUILDLINK3_PREFIX.pango}/include/pango-1.0. In most cases this
 option is generated by the configure script, which can be examined using:
 $ $ grep -o '[-]I[^[:space:]]*/pango[^[:space:]]*' work/*/Makefile
 -I/usr/pkg/include/pango-1.0
 -I/usr/pkg/include/pango-1.0
 -I/usr/pkg/include/pango-1.0
 -I/usr/pkg/include/pango-1.0
 -I/usr/pkg/include/pango-1.0
 This looks good. These options are transformed by the buildlink wrapper to
 refer to the correct path inside work/.buildlink.
 Since the compilation fails though, examine the compiler command lines in work
 /.work.log to see whether the -I option is included in the particular command
 line.
 To further analyze the situation, run bmake build-env, which sets up an
 interactive, realistic environment including all the pkgsrc wrapper commands
 and environment variables. From there, try to compile some simple example
 programs that use the header.
 .5.3.2. Headers generated during the build
 If the name of the header seems to come from the package itself, and if the
 build is run with parallel jobs, the package may have some undeclared
 dependencies between the .c and the .h files, and a C file is compiled before
 its required header is generated.
 To see whether the build runs with parallel jobs, run bmake show-all-build |
 grep JOBS. Its output looks like this:
   usr   MAKE_JOBS=              7
   pkg   MAKE_JOBS_SAFE          # undefined
   def   _MAKE_JOBS_N=           7
 In this case the pkgsrc user has asked pkgsrc to build packages with 7 jobs in
 parallel (MAKE_JOBS). The package could have disabled parallel builds by
 setting MAKE_JOBS_SAFE to no, but in this case it hasn't.
 To see whether the build failure is caused by parallel builds, first save the
 exact error message and a bit of context, maybe you need it later for reporting
 a bug. Next, run:
 MAKE_JOBS_SAFE=no bmake clean build
 If that succeeds, file a bug report against the pkgsrc package, including the
 exact error message and the contents of your mk.conf file.
 .5.3.3. Symlinks
 Pkgsrc does not work reliably if any of LOCALBASE, VARBASE or WRKDIR contains a
 symlink. Since 2019Q2, the pkgsrc bootstrap program prevents installing pkgsrc
 in symlink-based directories. Existing pkgsrc installations are not checked for
 symlinks though.
 The "No such file or directory" error messages are a typical symptom of
 symlinks, and it's quite difficult to find out that this is the actual cause.
 .5.3.4. Stale working directories
 When building a hierarchy of packages, it may happen that one package is built
 and then pkgsrc is updated. This situation can provoke various hard to diagnose
 build errors. To clean up the situation:
 $ (cd ../../ && cat mk/bsd.pkg.mk >/dev/null && rm -rf */*/work)
 (The only purpose of the bsd.pkg.mk is to prevent running this command in the
 wrong directory.)
 If you have set WRKOBJDIR in mk.conf, remove that directory as well.
 .5.3.5. Other possible reasons
 On platforms other than BSD, third-party packages are installed in /usr/
 include, together with the base system. This means that pkgsrc cannot
 distinguish between headers provided by the base system (which it needs) and
 headers from third-party packages (which are often included in pkgsrc as well).
 This can lead to subtle version mismatches.
 In pkgsrc installations that have been active for several years, it may happen
 that some files are manually deleted. To exclude this unlikely reason, run
 pkg_admin check.
 It may help to run pkg_admin rebuild-tree to check/fix dependencies.
 If all of the above doesn't help, see Chapter 2, Getting help for contact
 information. Be prepared to describe what you have tried so far and what any
 error messages were.
 .5.4. Undefined reference to "..."
 This error message often means that a package did not link to a shared library
 it needs. The following functions are known to cause this error message over
 and over.
 +-----------------------------------------------------+
 |        Function         |Library |Affected platforms|
 |-------------------------+--------+------------------|
 |accept, bind, connect    |-lsocket|Solaris           |
 |-------------------------+--------+------------------|
 |crypt                    |-lcrypt |DragonFly, NetBSD |
 |-------------------------+--------+------------------|
 |dlopen, dlsym            |-ldl    |Linux             |
 |-------------------------+--------+------------------|
 |gethost*                 |-lnsl   |Solaris           |
 |-------------------------+--------+------------------|
 |inet_aton                |-lresolv|Solaris           |
 |-------------------------+--------+------------------|
 |nanosleep, sem_*, timer_*|-lrt    |Solaris           |
 |-------------------------+--------+------------------|
 |openpty                  |-lutil  |Linux             |
 +-----------------------------------------------------+
 To fix these linker errors, it is often sufficient to add LIBS.OperatingSystem+
 = -lfoo to the package Makefile and then run bmake clean; bmake.
 .5.4.1. The SunPro compiler and inline functions
 When you are using the SunPro compiler, there is another possibility. That
 compiler cannot handle the following code:
 extern int extern_func(int);
 static inline int
 inline_func(int x)
+{
         return extern_func(x);
+}
 int main(void)
+{
         return 0;
+}
 It generates the code for inline_func even if that function is never used. This
 code then refers to extern_func, which can usually not be resolved. To solve
 this problem you can try to tell the package to disable inlining of functions.
 .5.5. Running out of memory
 Sometimes packages fail to build because the compiler runs into an operating
 system specific soft limit. With the UNLIMIT_RESOURCES variable pkgsrc can be
 told to unlimit the resources. The allowed values are any combination of "
 cputime", "datasize", "memorysize", "stacksize" and "virtualsize". Setting this
 variable is similar to running the shell builtin ulimit command to raise the
 maximum data segment size or maximum stack size of a process, respectively, to
 their hard limits.
 .6. The install phase
 .6.1. Creating needed directories
 The BSD-compatible install supplied with some operating systems cannot create
 more than one directory at a time. As such, you should call ${INSTALL_*_DIR}
 like this:
 ${INSTALL_DATA_DIR} ${PREFIX}/dir1
 ${INSTALL_DATA_DIR} ${PREFIX}/dir2
 Instead of running the install commands directly, you can also append "dir1
 dir2" to the INSTALLATION_DIRS variable, which will automatically do the right
 thing.
 .6.2. Where to install documentation
 In general, documentation should be installed into ${PREFIX}/share/doc/$
 {PKGBASE} or ${PREFIX}/share/doc/${PKGNAME_NOREV} (the latter includes the
 version number of the package).
 Many modern packages using GNU autoconf allow to set the directory where HTML
 documentation is installed with the "--with-html-dir" option. Sometimes using
 this flag is needed because otherwise the documentation ends up in ${PREFIX}/
 share/doc/html or other places. In pkgsrc, the HTML documentation should go
 into the package-specific directory, just like any other documentation.
 An exception to the above is that library API documentation generated with the
 textproc/gtk-doc tools, for use by special browsers (devhelp) should be left at
 their default location, which is ${PREFIX}/share/gtk-doc. Such documentation
 can be recognized from files ending in .devhelp or .devhelp2. (It is also
 acceptable to install such files in ${PREFIX}/share/doc/${PKGBASE} or ${PREFIX}
 /share/doc/${PKGNAME}; the .devhelp* file must be directly in that directory
 then, no additional subdirectory level is allowed in this case. This is usually
 achieved by using "--with-html-dir=${PREFIX}/share/doc". ${PREFIX}/share/
 gtk-doc is preferred though.)
 .6.3. Installing highscore files
 Certain packages, most of them in the games category, install a score file that
 allows all users on the system to record their highscores. In order for this to
 work, the binaries need to be installed setgid and the score files owned by the
 appropriate group and/or owner (traditionally the "games" user/group). Set
 USE_GAMESGROUP to yes to support this. The following variables, documented in
 more detail in mk/defaults/mk.conf, control this behaviour: GAMEDATAMODE,
 GAMEDIRMODE, GAMES_GROUP, GAMEMODE, GAME_USER. Other useful variables are:
 GAMEDIR_PERMS, GAMEDATA_PERMS and SETGID_GAMES_PERMS.
 An example that illustrates some of the variables described above is games/
 moon-buggy. OWN_DIRS_PERMS is used to properly set directory permissions of the
 directory where the scorefile is saved, REQD_FILES_PERMS is used to create a
 dummy scorefile (mbscore) with the proper permissions and SPECIAL_PERMS is used
 to install setgid the game binary:
 USE_GAMESGROUP=         yes
 BUILD_DEFS+=            VARBASE
 OWN_DIRS_PERMS+=        ${VARBASE}/games/moon-buggy ${GAMEDIR_PERMS}
 REQD_FILES_PERMS+=      /dev/null ${VARBASE}/games/moon-buggy/mbscore ${GAMEDATA_PERMS}
 SPECIAL_PERMS+=         ${PREFIX}/bin/moon-buggy ${SETGID_GAMES_PERMS}
 Various INSTALL_* variables are also available: INSTALL_GAME to install setgid
 game binaries, INSTALL_GAME_DIR to install game directories that are needed to
 be accessed by setgid games and INSTALL_GAME_DATA to install scorefiles.
 A package should therefore never hard code file ownership or access permissions
 but rely on *_PERMS as described above or alternatively on INSTALL_GAME,
 INSTALL_GAME_DATA and INSTALL_GAME_DIR to set these correctly.
 .6.4. Adding DESTDIR support to packages
 DESTDIR support means that a package installs into a staging directory, not the
 final location of the files. Then a binary package is created which can be used
 for installation as usual. There are two ways: Either the package must install
 as root ("destdir") or the package can install as non-root user ("user-destdir"
 ).
   * PKG_DESTDIR_SUPPORT has to be set to "destdir" or "user-destdir". By
     default PKG_DESTDIR_SUPPORT is set to "user-destdir" to help catching more
     potential packaging problems. If bsd.prefs.mk is included in the Makefile,
     PKG_DESTDIR_SUPPORT needs to be set before the inclusion.
   * All installation operations have to be prefixed with ${DESTDIR}.
   * automake gets this DESTDIR mostly right automatically. Many manual rules
     and pre/post-install often are incorrect; fix them.
   * If files are installed with special owner/group use SPECIAL_PERMS.
   * In general, packages should support UNPRIVILEGED to be able to use DESTDIR.
 .6.5. Packages with hardcoded paths to other interpreters
 Your package may also contain scripts with hardcoded paths to other
 interpreters besides (or as well as) Perl. To correct the full pathname to the
 script interpreter, you need to set the following definitions in your Makefile
 (we shall use tclsh in this example):
 REPLACE_INTERPRETER+=   tcl
 REPLACE.tcl.old=        .*/bin/tclsh
 REPLACE.tcl.new=        ${PREFIX}/bin/tclsh
 REPLACE_FILES.tcl=      # list of tcl scripts which need to be fixed,
 # relative to ${WRKSRC}, just as in REPLACE_PERL
 .6.6. Packages installing Perl modules
 Makefiles of packages providing perl5 modules should include the Makefile
 fragment ../../lang/perl5/module.mk. It provides a do-configure target for the
 standard perl configuration for such modules as well as various hooks to tune
 this configuration. See comments in this file for details.
 Perl5 modules will install into different places depending on the version of
 perl used during the build process. To address this, pkgsrc will append lines
 to the PLIST corresponding to the files listed in the installed .packlist file
 generated by most perl5 modules. This is invoked by defining PERL5_PACKLIST to
 a space-separated list of packlist files relative to PERL5_PACKLIST_DIR
 (PERL5_INSTALLVENDORARCH by default), e.g.:
 PERL5_PACKLIST= auto/Pg/.packlist
 The perl5 config variables installarchlib, installscript, installvendorbin,
 installvendorscript, installvendorarch, installvendorlib, installvendorman1dir,
 and installvendorman3dir represent those locations in which components of perl5
 modules may be installed, provided as variable with uppercase and prefixed with
 PERL5_, e.g. PERL5_INSTALLARCHLIB and may be used by perl5 packages that don't
 have a packlist. These variables are also substituted for in the PLIST as
 uppercase prefixed with PERL5_SUB_.
 .6.7. Packages installing info files
 Some packages install info files or use the "makeinfo" or "install-info"
 commands. INFO_FILES should be defined in the package Makefile so that INSTALL
 and DEINSTALL scripts will be generated to handle registration of the info
 files in the Info directory file. The "install-info" command used for the info
 files registration is either provided by the system, or by a special purpose
 package automatically added as dependency if needed.
 PKGINFODIR is the directory under ${PREFIX} where info files are primarily
 located. PKGINFODIR defaults to "info" and can be overridden by the user.
 The info files for the package should be listed in the package PLIST; however
 any split info files need not be listed.
 A package which needs the "makeinfo" command at build time must add "makeinfo"
 to USE_TOOLS in its Makefile. If a minimum version of the "makeinfo" command is
 needed it should be noted with the TEXINFO_REQD variable in the package
 Makefile. By default, a minimum version of 3.12 is required. If the system does
 not provide a makeinfo command or if it does not match the required minimum, a
 build dependency on the devel/gtexinfo package will be added automatically.
 The build and installation process of the software provided by the package
 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
 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
 message. The script overriding makeinfo logs a message and according to the
 value of TEXINFO_REQD either runs the appropriate makeinfo command or exit on
 error.
 .6.8. Packages installing man pages
 All packages that install manual pages should install them into the same
 directory, so that there is one common place to look for them. In pkgsrc, this
 place is ${PREFIX}/${PKGMANDIR}, and this expression should be used in
 packages. The default for PKGMANDIR is "man". Another often-used value is "
 share/man".
 Note
 The support for a custom PKGMANDIR is far from complete.
 The PLIST files can just use man/ as the top level directory for the man page
 file entries, and the pkgsrc framework will convert as needed. In all other
 places, the correct PKGMANDIR must be used.
 Packages that are configured with GNU_CONFIGURE set as "yes", by default will
 use the ./configure --mandir switch to set where the man pages should be
 installed. The path is GNU_CONFIGURE_MANDIR which defaults to ${PREFIX}/$
 {PKGMANDIR}.
 Packages that use GNU_CONFIGURE but do not use --mandir, can set
 CONFIGURE_HAS_MANDIR to "no". Or if the ./configure script uses a non-standard
 use of --mandir, you can set GNU_CONFIGURE_MANDIR as needed.
 See Section 19.5, "Man page compression" for information on installation of
 compressed manual pages.
 .6.9. Packages installing X11 fonts
 If a package installs font files, you will need to rebuild the fonts database
 in the directory where they get installed at installation and deinstallation
 time. This can be automatically done by using the pkginstall framework.
 You can list the directories where fonts are installed in the FONTS_DIRS.type
 variables, where type can be one of "ttf", "type1" or "x11". Also make sure
 that the database file fonts.dir is not listed in the PLIST.
 Note that you should not create new directories for fonts; instead use the
 standard ones to avoid that the user needs to manually configure his X server
 to find them.
 .6.10. Packages installing SGML or XML data
 If a package installs SGML or XML data files that need to be registered in
 system-wide catalogs (like DTDs, sub-catalogs, etc.), you need to take some
 extra steps:
 . Include ../../textproc/xmlcatmgr/catalogs.mk in your Makefile, which takes
     care of registering those files in system-wide catalogs at installation and
     deinstallation time.
 . Set SGML_CATALOGS to the full path of any SGML catalogs installed by the
     package.
 . Set XML_CATALOGS to the full path of any XML catalogs installed by the
     package.
 . Set SGML_ENTRIES to individual entries to be added to the SGML catalog.
     These come in groups of three strings; see xmlcatmgr(1) for more
     information (specifically, arguments recognized by the 'add' action). Note
     that you will normally not use this variable.
 . Set XML_ENTRIES to individual entries to be added to the XML catalog. These
     come in groups of three strings; see xmlcatmgr(1) for more information
     (specifically, arguments recognized by the 'add' action). Note that you
     will normally not use this variable.
 .6.11. Packages installing extensions to the MIME database
 If a package provides extensions to the MIME database by installing .xml files
 inside ${PREFIX}/share/mime/packages, you need to take some extra steps to
 ensure that the database is kept consistent with respect to these new files:
 . Include ../../databases/shared-mime-info/mimedb.mk (avoid using the
     buildlink3.mk file from this same directory, which is reserved for
     inclusion from other buildlink3.mk files). It takes care of rebuilding the
     MIME database at installation and deinstallation time, and disallows any
     access to it directly from the package.
 . 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 latter are
     package-dependent and must be removed by the package that installed them in
     the first place.
 . Remove any share/mime/* directories from the PLIST. They will be handled by
     the shared-mime-info package.
 .6.12. Packages using intltool
 If a package uses intltool during its build, add intltool to the USE_TOOLS,
 which forces it to use the intltool package provided by pkgsrc, instead of the
 one bundled with the distribution file.
 This tracks intltool's build-time dependencies and uses the latest available
 version; this way, the package benefits of any bug fixes that may have appeared
 since it was released.
 .6.13. Packages installing startup scripts
 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.14. 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 kpathsea, packages should install files
 into ${PREFIX}/share/texmf-dist, not ${PREFIX}/share/texmf.
 . Include ../../print/kpathsea/texmf.mk. This takes care of rebuilding the
     ls-R database at installation and deinstallation time.
 . If your package installs files into a texmf tree other than the one at $
     {PREFIX}/share/texmf-dist, set TEX_TEXMF_DIRS to the list of all texmf
     trees that need database update.
     If your package also installs font map files that need to be registered
     using updmap, include ../../print/tex-tetex/map.mk and set TEX_MAP_FILES
     and/or TEX_MIXEDMAP_FILES to the list of all such font map 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 kpathsea package.
 .6.15. 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
 if all libraries for each installed executable can be found by the dynamic
 linker. Since the standard dynamic linker is run, this fails for emulation
 packages, because the libraries used by the emulation are not in the standard
 directories.
 .6.16. Packages installing hicolor icons
 If a package installs images under the share/icons/hicolor and/or updates the
 share/icons/hicolor/icon-theme.cache database, you need to take some extra
 steps to make sure that the shared theme directory is handled appropriately and
 that the cache database is rebuilt:
 . Include ../../graphics/hicolor-icon-theme/buildlink3.mk.
 . Check the PLIST and remove the entry that refers to the theme cache.
 . Ensure that the PLIST does not remove the shared icon directories from the
     share/icons/hicolor hierarchy because they will be handled automatically.
 The best way to verify that the PLIST is correct with respect to the last two
 points is to regenerate it using make print-PLIST.
 .6.17. Packages installing desktop files
 If a package installs .desktop files under share/applications and these include
 MIME information (MimeType key), 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. In
 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
 PKG_FAIL_REASON variable). A user trying to build the package will immediately
 be shown this message, and the build will not be even tried.
 BROKEN packages are removed from pkgsrc in irregular intervals.
 Chapter 22. GNOME packaging and porting
 Table of Contents
 .1. Meta packages
 .2. Packaging a GNOME application
 .3. Updating GNOME to a newer version
 .4. Patching guidelines
 Quoting GNOME's web site:
     The GNOME project provides two things: The GNOME desktop environment, an
     intuitive and attractive desktop for users, and the GNOME development
     platform, an extensive framework for building applications that integrate
     into the rest of the desktop.
 pkgsrc provides a seamless way to automatically build and install a complete
 GNOME environment under many different platforms. We can say with confidence
 that pkgsrc is one of the most advanced build and packaging systems for GNOME
 due to its included technologies buildlink3, the wrappers and tools framework
 and automatic configuration file management. Lots of efforts are put into
 achieving a completely clean deinstallation of installed software components.
 Given that pkgsrc is NetBSD's official packaging system, the above also means
 that great efforts are put into making GNOME work under this operating system.
 This chapter is aimed at pkgsrc developers and other people interested in
 helping our GNOME porting and packaging efforts. It provides instructions on
 how to manage the existing packages and some important information regarding
 their internals.
 .1. Meta packages
 pkgsrc includes three GNOME-related meta packages:
   * meta-pkgs/gnome-base: Provides the core GNOME desktop environment. It only
     includes the necessary bits to get it to boot correctly, although it may
     lack important functionality for daily operation. The idea behind this
     package is to let end users build their own configurations on top of this
     one, first installing this meta package to achieve a functional setup and
     then adding individual applications.
   * meta-pkgs/gnome: Provides a complete installation of the GNOME platform and
     desktop as defined by the GNOME project; this is based on the components
     distributed in the platform/x.y/x.y.z/sources and desktop/x.y/x.y.z/sources
     directories of the official FTP server. Developer-only tools found in those
     directories are not installed unless required by some other component to
     work properly. Similarly, packages from the bindings set (bindings/x.y/
     x.y.z/sources) are not pulled in unless required as a dependency for an
     end-user component. This package "extends" meta-pkgs/gnome-base.
   * meta-pkgs/gnome-devel: Installs all the tools required to build a GNOME
     component when fetched from the CVS repository. These are required to let
     the autogen.sh scripts work appropriately.
 In all these packages, the DEPENDS lines are sorted in a way that eases
 updates: a package may depend on other packages listed before it but not on any
 listed after it. It is very important to keep this order to ease updates so...
 do not change it to alphabetical sorting!
 .2. Packaging a GNOME application
 Almost all GNOME applications are written in C and use a common set of tools as
 their build system. Things get different with the new bindings to other
 languages (such as Python), but the following will give you a general idea on
 the minimum required tools:
   * Almost all GNOME applications use the GNU Autotools as their build system.
     As a general rule you will need to tell this to your package:
     GNU_CONFIGURE=  yes
     USE_LIBTOOL=    yes
     USE_TOOLS+=     gmake
   * If the package uses pkg-config to detect dependencies, add this tool to the
     list of required utilities:
     USE_TOOLS+=     pkg-config
     Also use pkgtools/verifypc at the end of the build process to ensure that
     you did not miss to specify any dependency in your package and that the
     version requirements are all correct.
   * If the package uses intltool, be sure to add intltool to the USE_TOOLS to
     handle dependencies and to force the package to use the latest available
     version.
   * If the package uses gtk-doc (a documentation generation utility), do not
     add a dependency on it. The tool is rather big and the distfile should come
     with pregenerated documentation anyway; if it does not, it is a bug that
     you ought to report. For such packages you should disable gtk-doc (unless
     it is the default):
     CONFIGURE_ARGS+=        --disable-gtk-doc
     The default location of installed HTML files (share/gtk-doc/<package-name>)
     is correct and should not be changed unless the package insists on
     installing them somewhere else. Otherwise programs as devhelp will not be
     able to open them. You can do that with an entry similar to:
     CONFIGURE_ARGS+=        --with-html-dir=${PREFIX}/share/gtk-doc/...
 GNOME uses multiple shared directories and files under the installation prefix
 to maintain databases. In this context, shared means that those exact same
 directories and files are used among several different packages, leading to
 conflicts in the PLIST. pkgsrc currently includes functionality to handle the
 most common cases, so you have to forget about using @unexec ${RMDIR} lines in
 your file lists and omitting shared files from them. If you find yourself doing
 those, your package is most likely incorrect.
 The following table lists the common situations that result in using shared
 directories or files. For each of them, the appropriate solution is given.
 After applying the solution be sure to regenerate the package's file list with
 make print-PLIST and ensure it is correct.
 Table 22.1. PLIST handling for GNOME packages
 +-----------------------------------------------------------------------------+
 |             If the package...             |             Then...             |
 |-------------------------------------------+---------------------------------|
 |Installs icons under the share/icons/      |See Section 21.6.16, "Packages   |
 |hicolor hierarchy or updates share/icons/  |installing hicolor icons".       |
 |hicolor/icon-theme.cache.                  |                                 |
 |-------------------------------------------+---------------------------------|
 |                                           |See Section 21.6.11, "Packages   |
 |Installs files under share/mime/packages.  |installing extensions to the MIME|
 |                                           |database".                       |
 |-------------------------------------------+---------------------------------|
 |Installs .desktop files under share/       |See Section 21.6.17, "Packages   |
 |applications and these include MIME        |installing desktop files".       |
 |information.                               |                                 |
 +-----------------------------------------------------------------------------+
 .3. Updating GNOME to a newer version
 When seeing GNOME as a whole, there are two kinds of updates:
 Major update
     Given that there is still a very long way for GNOME 3 (if it ever appears),
     we consider a major update one that goes from a 2.X version to a 2.Y one,
     where Y is even and greater than X. These are hard to achieve because they
     introduce lots of changes in the components' code and almost all GNOME
     distfiles are updated to newer versions. Some of them can even break API
     and ABI compatibility with the previous major version series. As a result,
     the update needs to be done all at once to minimize breakage.
     A major update typically consists of around 80 package updates and the
     addition of some new ones.
 Minor update
     We consider a minor update one that goes from a 2.A.X version to a 2.A.Y
     one where Y is greater than X. These are easy to achieve because they do
     not update all GNOME components, can be done in an incremental way and do
     not break API nor ABI compatibility.
     A minor update typically consists of around 50 package updates, although
     the numbers here may vary a lot.
 In order to update the GNOME components in pkgsrc to a new stable release
 (either major or minor), the following steps should be followed:
 . Get a list of all the tarballs that form the new release by using the
     following commands. These will leave the full list of the components'
     distfiles into the list.txt file:
     % echo ls "*.tar.bz2" | \
         ftp -V ftp://ftp.gnome.org/pub/gnome/platform/x.y/x.y.z/sources/ | \
         awk '{ print $9 }' >list.txt
     % echo ls "*.tar.bz2" | \
         ftp -V ftp://ftp.gnome.org/pub/gnome/desktop/x.y/x.y.z/sources/ | \
         awk '{ print $9 }' >>list.txt
 . Open each meta package's Makefile and bump their version to the release you
     are updating them to. The three meta packages should be always consistent
     with versioning. Obviously remove any PKGREVISIONs that might be in them.
 . For each meta package, update all its DEPENDS lines to match the latest
     versions as shown by the above commands. Do not list any newer version
     (even if found in the FTP) because the meta packages are supposed to list
     the exact versions that form a specific GNOME release. Exceptions are
     permitted here if a newer version solves a serious issue in the overall
     desktop experience; these typically come in the form of a revision bump in
     pkgsrc, not in newer versions from the developers.
     Packages not listed in the list.txt file should be updated to the latest
     version available (if found in pkgsrc). This is the case, for example, of
     the dependencies on the GNU Autotools in the meta-pkgs/gnome-devel meta
     package.
 . Generate a patch from the modified meta packages and extract the list of
     "new" lines. This will provide you an outline on what packages need to be
     updated in pkgsrc and in what order:
     % cvs diff -u gnome-devel gnome-base gnome | grep '^+D' >todo.txt
 . For major desktop updates it is recommended to zap all your installed
     packages and start over from scratch at this point.
 . Now comes the longest step by far: iterate over the contents of todo.txt
     and update the packages listed in it in order. For major desktop updates
     none of these should be committed until the entire set is completed because
     there are chances of breaking not-yet-updated packages.
 . Once the packages are up to date and working, commit them to the tree one
     by one with appropriate log messages. At the end, commit the three meta
     package updates and all the corresponding changes to the doc/CHANGES-<YEAR>
     and pkgsrc/doc/TODO files.
 .4. Patching guidelines
 GNOME is a very big component in pkgsrc which approaches 100 packages. Please,
 it is very important that you always, always, always feed back any portability
 fixes you do to a GNOME package to the mainstream developers (see
 Section 12.3.5, "Feedback to the author"). This is the only way to get their
 attention on portability issues and to ensure that future versions can be built
 out-of-the box on NetBSD. The less custom patches in pkgsrc, the easier further
 updates are. Those developers in charge of issuing major GNOME updates will be
 grateful if you do that.
 The most common places to report bugs are the GNOME's GitLab and the
 freedesktop.org's GitLab. Not all components use these to track bugs, but most
 of them do. Do not be short on your reports: always provide detailed
 explanations of the current failure, how it can be improved to achieve maximum
 portability and, if at all possible, provide a patch against the main Git
 branch. The more verbose you are, the higher chances of your patch being
 accepted.
 Also, please avoid using preprocessor magic to fix portability issues. While
 the FreeBSD GNOME people are doing a great job in porting GNOME to their
 operating system, the official GNOME sources are now plagued by conditionals
 that check for __FreeBSD__ and similar macros. This hurts portability. Please
 see our patching guidelines (Section 12.3.4, "Patching guidelines") for more
 details.
 Chapter 23. Submitting and Committing
 Table of Contents
 .1. Submitting binary packages
 .2. Submitting source packages (for non-NetBSD-developers)
 .3. General notes when adding, updating, or removing packages
 .4. Commit Messages
 .5. Committing: Adding a package to CVS
 .6. Updating a package to a newer version
 .7. Renaming a package in pkgsrc
 .8. Moving a package in pkgsrc
 .1. Submitting binary packages
 Our policy is that we accept binaries only from pkgsrc developers to guarantee
 that the packages don't contain any trojan horses etc. This is not to annoy
 anyone but rather to protect our users! You're still free to put up your
 home-made binary packages and tell the world where to get them. NetBSD
 developers doing bulk builds and wanting to upload them please see Chapter 8,
 Creating binary packages for everything in pkgsrc (bulk builds).
 .2. Submitting source packages (for non-NetBSD-developers)
 Firstly, you can import new packages into pkgsrc-wip ("pkgsrc work-in-progress"
 ); see the homepage at https://pkgsrc.org/wip/ for details.
 Next, check that your package is complete, compiles and runs well; see
 Chapter 14, Creating a new pkgsrc package from scratch and the rest of this
 document. Run the pkgtools/pkglint tool and fix any errors that appear.
 Finally, send a report to the pkgsrc bug tracking system, either with the
 send-pr(1) command, or if you don't have that, go to the web page https://
 www.NetBSD.org/support/send-pr.html, which contains some instructions and a
 link to a form where you can submit packages. The sysutils/gtk-send-pr package
 is also available as a substitute for either of the above two tools.
 In the form of the problem report, the category should be "pkg", the synopsis
 should include the package name and version number, and the description field
 should contain a short description of your package (contents of the COMMENT
 variable or DESCR file are OK).
 .3. General notes when adding, updating, or removing packages
 Please note all package additions, updates, moves, and removals in pkgsrc/doc/
 CHANGES-YYYY. It's very important to keep this file up to date and conforming
 to the existing format, because it will be used by scripts to automatically
 update pages on www.NetBSD.org and other sites. Additionally, check the pkgsrc/
 doc/TODO file and remove the entry for the package you updated or removed, in
 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. The target
 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
 commit-changes-entry! 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. Commit Messages
 For several years, there have been mirrors of pkgsrc in fossil, git, and hg.
 Standard practise when using these tools is to make the first line of a commit
 message function as a summary that can be read without the rest, such as is
 commonly done with "git log --oneline". For this reason, we have the following
 guidelines for pkgsrc commit messages:
   * Start the commit message with a line that explains the big picture in 65
     characters or less. When a commit is for one package, include the name of
     the package. For updates, include the version to which it is updated.
   * Leave the next line empty.
   * Then come the details for the commit (changes in that package, reason for a
     change) and any relevant PRs. Wrap this section.
 Here is an example:
   libxslt: update to 1.0.30
   Changes since 1.0.29:
   ...
 Here is another example:
   mk/bsd.pkg.mk: enable SSP by default on NetBSD
   (rationale)
 Commit messages are final: no "cvs admin" is allowed on the pkgsrc repository
 to change commit messages.
 .5. Committing: Adding a package to CVS
 This section is only of interest for pkgsrc developers with write access to the
 pkgsrc repository.
 When the package is finished, "cvs add" the files. Start by adding the
 directory and then files in the directory. Don't forget to add the new package
 to the category's Makefile. Make sure you don't forget any files; you can check
 by running "cvs status". An example:
 $ cd .../pkgsrc/category
 $ cvs add pkgname
 @@ -8576,1815 +8576,1782 @@ assigned using the := operator, which sh
 .5.2. Actions taken on behalf of parameters
 Action files take some input parameters and may define runtime variables. They
 shall not define loadtime variables. There are action files that are included
 implicitly by the pkgsrc infrastructure, while other must be included
 explicitly.
 An example for action files is mk/subst.mk.
 .6. The order in which files are loaded
 Package Makefiles usually consist of a set of variable definitions, and include
 the file ../../mk/bsd.pkg.mk in the very last line. Before that, they may also
 include various other *.mk files if they need to query the availability of
 certain features like the type of compiler or the X11 implementation. Due to
 the heavy use of preprocessor directives like .if and .for, the order in which
 the files are loaded matters.
 This section describes at which point the various files are loaded and gives
 reasons for that order.
 .6.1. The order in bsd.prefs.mk
 The very first action in bsd.prefs.mk is to define some essential variables
 like OPSYS, OS_VERSION and MACHINE_ARCH.
 Then, the user settings are loaded from the file specified in MAKECONF, which
 is usually mk.conf. After that, those variables that have not been overridden
 by the user are loaded from mk/defaults/mk.conf.
 After the user settings, the system settings and platform settings are loaded,
 which may override the user settings.
 Then, the tool definitions are loaded. The tool wrappers are not yet in effect.
 This only happens when building a package, so the proper variables must be used
 instead of the direct tool names.
 As the last steps, some essential variables from the wrapper and the package
 system flavor are loaded, as well as the variables that have been cached in
 earlier phases of a package build.
 .6.2. The order in bsd.pkg.mk
 First, bsd.prefs.mk is loaded.
 Then, the various *-vars.mk files are loaded, which fill default values for
 those variables that have not been defined by the package. These variables may
 later be used even in unrelated files.
 Then, the file bsd.pkg.error.mk provides the target error-check that is added
 as a special dependency to all other targets that use DELAYED_ERROR_MSG or
 DELAYED_WARNING_MSG.
 Then, the package-specific hacks from hacks.mk are included.
 Then, various other files follow. Most of them don't have any dependencies on
 what they need to have included before or after them, though some do.
 The code to check PKG_FAIL_REASON and PKG_SKIP_REASON is then executed, which
 restricts the use of these variables to all the files that have been included
 before. Appearances in later files will be silently ignored.
 Then, the files for the main targets are included, in the order of later
 execution, though the actual order should not matter.
 At last, some more files are included that don't set any interesting variables
 but rather just define make targets to be executed.
 Chapter 26. Regression tests
 Table of Contents
 .1. Running the regression tests
 .2. Adding a new regression test
 .2.1. Overridable functions
 .2.2. Helper functions
 The pkgsrc infrastructure consists of a large codebase, and there are many
 corners where every little bit of a file is well thought out, making pkgsrc
 likely to fail as soon as anything is changed near those parts. To prevent most
 changes from breaking anything, a suite of regression tests should go along
 with every important part of the pkgsrc infrastructure. This chapter describes
 how regression tests work in pkgsrc and how you can add new tests.
 .1. Running the regression tests
 You first need to install the pkgtools/pkg_regress package, which provides the
 pkg_regress command. Then you can simply run that command, which will run all
 tests in the regress/ directory.
 .2. Adding a new regression test
 Every directory in the regress/ directory that contains a file called spec is
 considered a regression test. This file is a shell program that is included by
 the pkg_regress command. The following functions can be overridden to suit your
 needs.
 .2.1. Overridable functions
 These functions do not take any parameters. Although they are called in "set -e
 " mode, they don't stop at the first failing command. See this Stack Overflow
 question for details.
 do_setup
     This function prepares the environment for the test. By default it does
     nothing.
 do_test
     This function runs the actual test. By default, it calls TEST_MAKE with the
     arguments MAKEARGS_TEST and writes its output including error messages into
     the file TEST_OUTFILE.
     When defining this function, make sure that all output that needs to be
     checked is written to the correct output file. Example:
     do_test() {
             echo "Example output"
     } 1>$TEST_OUTFILE 2>&1
 check_result
     This function is run after the test and is typically used to compare the
     actual output from the one that is expected. It can make use of the various
     helper functions from the next section. Example:
     check_result() {
             exit_status 0
             output_require "Example"
             output_require "^[[:alpha:]+[[:space:]][[:alpha:]]{6}$"
             output_prohibit "no such file or directory"
             regress_fail "expected $expected but got $actual for input $input"
+    }
 do_cleanup
     This function cleans everything up after the test has been run. By default
     it does nothing.
 .2.2. Helper functions
 regress_fail message...
     This function makes the test fail with the given error message.
 exit_status expected
     This function compares the exitcode of the do_test function with its first
     parameter. If they differ, the test will fail.
 output_require regex...
     This function checks for each of its parameters if the output from do_test
     matches the extended regular expression. If it does not, the test will
     fail. Example:
     output_require "looks fine"
     output_require "^[[:alpha:]+[[:space:]][[:alpha:]]{6}$"
 output_prohibit regex...
     This function checks for each of its parameters if the output from do_test
     () does not match the extended regular expression. If any of the regular
     expressions matches, the test will fail.
 Chapter 27. Porting pkgsrc
 Table of Contents
 .1. Porting pkgsrc to a new operating system
 The pkgsrc system has already been ported to many operating systems, hardware
 architectures and compilers. This chapter explains the necessary steps to make
 pkgsrc even more portable.
 .1. Porting pkgsrc to a new operating system
 To port pkgsrc to a new operating system (called MyOS in this example), you
 need to touch the following files:
 pkgtools/bootstrap-mk-files/files/mods/MyOS.sys.mk
     This file contains some basic definitions, for example the name of the C
     compiler.
 mk/bsd.prefs.mk
     Insert code that defines the variables OPSYS, OS_VERSION, OPSYS_VERSION,
     LOWER_VENDOR, MACHINE_ARCH, OBJECT_FMT, APPEND_ELF, and the other variables
     that appear in this file.
 mk/platform/MyOS.mk
     This file contains the platform-specific definitions that are used by
     pkgsrc. Start by copying one of the other files and edit it to your needs.
 mk/tools/tools.MyOS.mk
     This file defines the paths to all the tools that are needed by one or the
     other package in pkgsrc, as well as by pkgsrc itself. Find out where these
     tools are on your platform and add them.
 Now, you should be able to build some basic packages, like lang/perl5, shells/
 bash.
 Appendix A. A simple example package: bison
 Table of Contents
 A.1. files
     A.1.1. Makefile
     A.1.2. DESCR
     A.1.3. PLIST
     A.1.4. Checking a package with pkglint
 A.2. Steps for building, installing, packaging
 We checked to find a piece of software that wasn't in the packages collection,
 and picked GNU bison. Quite why someone would want to have bison when Berkeley
 yacc is already present in the tree is beyond us, but it's useful for the
 purposes of this exercise.
 A.1. files
 A.1.1. Makefile
 # $NetBSD$
+#
 DISTNAME=       bison-1.25
 CATEGORIES=     devel
 MASTER_SITES=   ${MASTER_SITE_GNU:=bison/}
 MAINTAINER=     pkgsrc-users@NetBSD.org
 HOMEPAGE=       https://www.gnu.org/software/bison/bison.html
 COMMENT=        GNU yacc clone
 GNU_CONFIGURE=  yes
 INFO_FILES=     yes
 .include "../../mk/bsd.pkg.mk"
 A.1.2. DESCR
 GNU version of yacc.  Can make re-entrant parsers, and numerous other
 improvements.  Why you would want this when Berkeley yacc(1) is part
 of the NetBSD source tree is beyond me.
 A.1.3. PLIST
 @comment $NetBSD$
 bin/bison
 man/man1/bison.1.gz
 share/bison.simple
 share/bison.hairy
 A.1.4. Checking a package with pkglint
 The NetBSD package system comes with pkgtools/pkglint which helps to check the
 contents of these files. After installation it is quite easy to use, just
 change to the directory of the package you wish to examine and run pkglint:
 $ pkglint
 ERROR: Makefile: Each package must define its LICENSE.
 WARN: Makefile:9: HOMEPAGE should migrate from http to https.
 NOTE: PLIST:3: The .gz extension is unnecessary for manual pages.
 WARN: PLIST:5: "share/bison.hairy" should be sorted before "share/bison.simple".
 error, 2 warnings and 1 note found.
 (Run "pkglint -e" to show explanations.)
 (Run "pkglint -fs" to show what can be fixed automatically.)
 (Run "pkglint -F" to automatically fix some issues.)
 Depending on the supplied command line arguments (see pkglint(1)), more checks
 will be performed. Use e.g. pkglint -Wall for a very thorough check.
 A.2. Steps for building, installing, packaging
 Create the directory where the package lives, plus any auxiliary directories:
 # cd /usr/pkgsrc/lang
 # mkdir bison
 # cd bison
 # mkdir patches
 Create Makefile, DESCR and PLIST (see Chapter 12, Package components - files,
 directories and contents) then continue with fetching the distfile:
 # make fetch
 >> bison-1.25.tar.gz doesn't seem to exist on this system.
 >> Attempting to fetch from ftp://prep.ai.mit.edu/pub/gnu//.
 Requesting ftp://prep.ai.mit.edu/pub/gnu//bison-1.25.tar.gz (via ftp://orpheus.amdahl.com:80/)
 ftp: Error retrieving file: 500 Internal error
 >> Attempting to fetch from ftp://wuarchive.wustl.edu/systems/gnu//.
 Requesting ftp://wuarchive.wustl.edu/systems/gnu//bison-1.25.tar.gz (via ftp://orpheus.amdahl.com:80/)
 ftp: Error retrieving file: 500 Internal error
 >> Attempting to fetch from ftp://ftp.freebsd.org/pub/FreeBSD/distfiles//.
 Requesting ftp://ftp.freebsd.org/pub/FreeBSD/distfiles//bison-1.25.tar.gz (via ftp://orpheus.amdahl.com:80/)
 Successfully retrieved file.
 Generate the checksum of the distfile into distinfo:
 # make makedistinfo
 Now compile:
 # make
 >> Checksum OK for bison-1.25.tar.gz.
 ===>  Extracting for bison-1.25
 ===>  Patching for bison-1.25
 ===>   Ignoring empty patch directory
 ===>  Configuring for bison-1.25
 creating cache ./config.cache
 checking for gcc... cc
 checking whether we are using GNU C... yes
 checking for a BSD compatible install... /usr/bin/install -c -o bin -g bin
 checking how to run the C preprocessor... cc -E
 checking for minix/config.h... no
 checking for POSIXized ISC... no
 checking whether cross-compiling... no
 checking for ANSI C header files... yes
 checking for string.h... yes
 checking for stdlib.h... yes
 checking for memory.h... yes
 checking for working const... yes
 checking for working alloca.h... no
 checking for alloca... yes
 checking for strerror... yes
 updating cache ./config.cache
 creating ./config.status
 creating Makefile
 ===>  Building for bison-1.25
 cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include  -g LR0.c
 cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include  -g allocate.c
 cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include  -g closure.c
 cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include  -g conflicts.c
 cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include  -g derives.c
 cc -c -DXPFILE=\"/usr/pkg/share/bison.simple\"  -DXPFILE1=\"/usr/pkg/share/bison.hairy\" -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1  -g  ./files.c
 cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include  -g getargs.c
 cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include  -g gram.c
 cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include  -g lalr.c
 cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include  -g lex.c
 cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include  -g main.c
 cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include  -g nullable.c
 cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include  -g output.c
 cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include  -g print.c
 cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include  -g reader.c
 cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include  -g reduce.c
 cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include  -g symtab.c
 cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include  -g warshall.c
 cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include  -g version.c
 cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include  -g getopt.c
 cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include  -g getopt1.c
 cc  -g -o bison LR0.o allocate.o closure.o conflicts.o derives.o files.o         getargs.o gram.o lalr.o lex.o                                   main.o nullable.o output.o print.o reader.o reduce.o symtab.o   warshall.o version.o getopt.o getopt1.o
 ./files.c:240: warning: mktemp() possibly used unsafely, consider using mkstemp()
 rm -f bison.s1
 sed -e "/^#line/ s|bison|/usr/pkg/share/bison|" < ./bison.simple > bison.s1
 Everything seems OK, so install the files:
 # make install
 >> Checksum OK for bison-1.25.tar.gz.
 ===>  Installing for bison-1.25
 sh ./mkinstalldirs /usr/pkg/bin /usr/pkg/share  /usr/pkg/info /usr/pkg/man/man1
 rm -f /usr/pkg/bin/bison
 cd /usr/pkg/share; rm -f bison.simple bison.hairy
 rm -f /usr/pkg/man/man1/bison.1 /usr/pkg/info/bison.info*
 install -c  -o bin -g bin -m 555 bison /usr/pkg/bin/bison
 /usr/bin/install -c -o bin -g bin -m 644 bison.s1 /usr/pkg/share/bison.simple
 /usr/bin/install -c -o bin -g bin -m 644 ./bison.hairy /usr/pkg/share/bison.hairy
 cd .; for f in bison.info*;  do /usr/bin/install -c -o bin -g bin -m 644 $f /usr/pkg/info/$f; done
 /usr/bin/install -c -o bin -g bin -m 644 ./bison.1 /usr/pkg/man/man1/bison.1
 ===>  Registering installation for bison-1.25
 You can now use bison, and also - if you decide so - remove it with pkg_delete
 bison. Should you decide that you want a binary package, do this now:
 # make package
 >> Checksum OK for bison-1.25.tar.gz.
 ===>  Building package for bison-1.25
 Creating package bison-1.25.tgz
 Registering depends:.
 Creating gzip'd tar ball in '/u/pkgsrc/lang/bison/bison-1.25.tgz'
 Now that you don't need the source and object files any more, clean up:
 # make clean
 ===>  Cleaning for bison-1.25
 Appendix B. Security hardening
 Table of Contents
 B.1. Mechanisms
     B.1.1. Enabled by default
     B.1.2. Not enabled by default
 B.2. Caveats
     B.2.1. Problems with PKGSRC_MKPIE
     B.2.2. Problems with PKGSRC_USE_FORTIFY
     B.2.3. Problems with PKGSRC_USE_RELRO
     B.2.4. Problems with PKGSRC_USE_SSP
 B.3. Auditing the system
     B.3.1. Checking for PIE
     B.3.2. Checking for partial RELRO
     B.3.3. Checking for full RELRO
     B.3.4. Checking for SSP
 A number of mechanisms are available in pkgsrc to improve the security of the
 resulting system. This page describes the mechanisms, and gives hints about
 detecting and fixing problems.
 Mechanisms can be enabled individually in mk.conf, and are individually
 described below.
 Typically, a feature will cause some programs to fail to build or work when
 first enabled. This can be due to latent problems in the program, and can be
 due to other reasons. After enough testing to have confidence that user
 problems will be quite rare, individual mechanisms will be enabled by default.
 For each mechanism, see the Caveats section below for an explanation of what
 might go wrong at compile time and at run time, and how to notice and address
 these problems.
 B.1. Mechanisms
 B.1.1. Enabled by default
 B.1.1.1. PKGSRC_USE_FORTIFY
 This allows substitute wrappers to be used for some commonly used library
 functions that do not have built-in bounds checking - but could in some cases.
 Two mitigation levels are available:
   * "weak" only enables checks at compile-time.
   * "strong" enables checks at compile-time and runtime.
 "strong" has been enabled by default since pkgsrc-2017Q3.
 B.1.1.2. PKGSRC_USE_SSP
 This enables a stack-smashing protection mitigation. It is done by adding a
 guard variable to functions with vulnerable objects. The guards are initialized
 when a function is entered and then checked when the function exits. The guard
 check will fail and the program forcibly exited if the variable was modified in
 the meantime. This can happen in case of buffer overflows or memory corruption,
 and therefore exposing these bugs.
 Different mitigation levels are available:
   * "yes", which will only protect functions considered vulnerable by the
     compiler;
   * "all", which will protect every function;
   * "strong", the default, which will apply a better balance between the two
     settings above.
 This mitigation is supported by both GCC and clang. It may be supported in
 additional compilers, possibly under a different name. It is particularly
 useful for unsafe programming languages, such as C/C++.
   * "yes" is enabled by default where known supported since pkgsrc-2017Q3.
   * "strong" is enabled by default where known supported since pkgsrc-2021Q4.
 More details can be found here:
   * Buffer overflow protection on Wikipedia
 B.1.1.3. PKGSRC_MKPIE
 This requests the creation of PIE (Position Independent Executables) for all
 executables. The PIE mechanism is normally used for shared libraries, so that
 they can be loaded at differing addresses at runtime. PIE itself does not have
 useful security properties; however, it is necessary to fully leverage some,
 such as ASLR. Some operating systems support Address Space Layout Randomization
 (ASLR), which causes different addresses to be used each time a program is run.
 This makes it more difficult for an attacker to guess addresses and thus makes
 exploits harder to construct. With PIE, ASLR can really be applied to the
 entire program, instead of the stack and heap only.
 PIE executables will only be built for toolchains that are known to support
 PIE. Currently, this means NetBSD on x86, ARM, SPARC64, m68k, and MIPS.
 PKGSRC_MKPIE was enabled by default after the pkgsrc-2021Q3 branch.
 B.1.1.4. PKGSRC_USE_RELRO
 This also makes the exploitation of some security vulnerabilities more
 difficult in some cases.
 Two different mitigation levels are available:
   * partial (the default): the ELF sections are reordered so that internal data
     sections precede the program's own data sections, and non-PLT GOT is
     read-only;
   * full: in addition to partial RELRO, every relocation is performed
     immediately when starting the program, allowing the entire GOT to be
     read-only. This can greatly slow down startup of large programs.
 This is currently supported by GCC. Many software distributions now enable this
 feature by default, at the "partial" level.
 More details can be found here:
   * Hardening ELF binaries using Relocation Read-Only (RELRO)
 B.1.2. Not enabled by default
 B.1.2.1. PKGSRC_MKREPRO
 With this option, pkgsrc will try to build packages reproducibly. This allows
 packages built from the same tree and with the same options, to produce
 identical results bit by bit. This option should be combined with ASLR and
 PKGSRC_MKPIE to avoid predictable address offsets for attackers attempting to
 exploit security vulnerabilities.
 More details can be found here:
   * Reproducible Builds - a set of software development practices that create
     an independently-verifiable path from source to binary code
 More work likely needs to be done before pkgsrc is fully reproducible.
 B.1.2.2. PKGSRC_USE_STACK_CHECK
 This uses -fstack-check with GCC for another stack protection mitigation.
 It asks the compiler to generate code verifying that it does not corrupt the
 stack. According to GCC's manual page, this is really only useful for
 multi-threaded programs.
 B.2. Caveats
 B.2.1. Problems with PKGSRC_MKPIE
 B.2.1.1. Packages failing to build
 A number of packages may fail to build with this option enabled. The failures
 are often related to the absence of the -fPIC compilation flag when building
 libraries or executables (or ideally -fPIE in the latter case). This flag is
 added to the CFLAGS already, but requires the package to actually support it.
 B.2.1.1.1. How to fix
 These instructions are meant as a reference only; they likely need to be
 adapted for many packages individually.
 For packages using Makefiles:
 MAKE_FLAGS+=    CFLAGS=${CFLAGS:Q}
 MAKE_FLAGS+=    LDFLAGS=${LDFLAGS:Q}
 For packages using Imakefiles:
 MAKE_FLAGS+=    CCOPTIONS=${CFLAGS:Q}
 MAKE_FLAGS+=    LOCAL_LDFLAGS=${LDFLAGS:Q}
 B.2.1.2. Run-time crashes
 Some programs may fail to run, or crash at random times once built as PIE. Two
 scenarios are essentially possible. This is nearly always due to a bug in the
 program being exposed due to ASLR.
 B.2.1.3. Disabling PKGSRC_MKPIE on a per-package basis
 Ideally, packages should be fixed for compatibility with MKPIE. However, in
 some cases this is very difficult, due to complex build systems, packages using
 non-standard toolchains, or programming languages with odd bootstrapping
 mechanisms.
 To disable PKGSRC_MKPIE on a per-package basis, set MKPIE_SUPPORTED= no in the
 package's Makefile before bsd.prefs.mk is included.
 B.2.2. Problems with PKGSRC_USE_FORTIFY
 B.2.2.1. Packages failing to build
 This feature makes use of pre-processing directives to look for hardened,
 alternative implementations of essential library calls. Some programs may fail
 to build as a result; this usually happens for those trying too hard to be
 portable, or otherwise abusing definitions in the standard library.
 B.2.2.2. Run-time crashes
 This feature may cause some programs to crash, usually indicating an actual bug
 in the program. The fix will typically involve patching the original program's
 source code.
 B.2.2.3. Optimization is required
 At least in the case of GCC, FORTIFY will only be applied if optimization is
 applied while compiling. This means that the CFLAGS should also contain -O, -O2
 or another optimization level. This cannot easily be applied globally, as some
 packages may require specific optimization levels.
 B.2.2.4. Disabling FORTIFY on a per-package basis
 Note
 FORTIFY should not be disabled to work around runtime crashes in the program!
 This is a very bad idea and will expose you to security vulnerabilities.
 To disable FORTIFY on a per-package basis, set the following in the package's
 Makefile before bsd.prefs.mk is included:
 FORTIFY_SUPPORTED=      no
 B.2.3. Problems with PKGSRC_USE_RELRO
 B.2.3.1. Performance impact
 For better protection, full RELRO requires every symbol to be resolved when the
 program starts, rather than simply when required at run-time. This will have
 more impact on programs using a lot of symbols, or linked to libraries exposing
 a lot of symbols. Therefore, daemons or programs otherwise running in
 background are affected only when started. Programs loading plug-ins at
 run-time are affected when loading the plug-ins.
 The impact is not expected to be noticeable on modern hardware, except in some
 cases for big programs.
 B.2.3.2. Run-time crashes
 Some programs handle plug-ins and dependencies in a way that conflicts with
 RELRO: for instance, with an initialization routine listing any other plug-in
 required. With full RELRO, the missing symbols are resolved before the
 initialization routine can run, and the dynamic loader will not be able to find
 them directly and abort as a result. Unfortunately, this is how Xorg loads its
 drivers. Partial RELRO can be applied instead in this case.
 B.2.3.3. Disabling RELRO on a per-package basis
 To disable RELRO on a per-package basis, set the following in the package's
 Makefile before bsd.prefs.mk is included:
 RELRO_SUPPORTED=        no
 It is also possible to at most enable partial RELRO, by setting RELRO_SUPPORTED
 to partial.
 B.2.4. Problems with PKGSRC_USE_SSP
 B.2.4.1. Packages failing to build
 The stack-smashing protection provided by this option does not work for some
 programs. The most common situation in which this happens is when the program
 allocates variables on the stack, with the size determined at run-time.
 B.2.4.2. Run-time crashes
 Again, this feature may cause some programs to crash via a SIGABRT, usually
 indicating an actual bug in the program.
 On NetBSD LOG_CRIT level syslog messages are sent and - by default - appended
 to /var/log/messages, e.g.:
 Jan  6 15:42:51 hostname -: hostname program - - - buffer overflow detected; terminated
 (where hostname is the hostname(1) and program is the basename(1) of the
 program crashed).
 Patching the original program is then required.
 Rebuilding the package via:
 % env CFLAGS=-g INSTALL_UNSTRIPPED=yes make replace
 and inspecting the backtrace of the coredump via the debugger should point out
 the problematic call by inspecting the frame calling the _chk() (SSP) function.
 B.2.4.3. Performance impact
 The compiler emits extra code when using this feature: a check for buffer
 overflows is performed when entering and exiting functions, requiring an extra
 variable on the stack. The level of protection can otherwise be adjusted to
 affect only those functions considered more sensitive by the compiler (with
 -fstack-protector instead of -fstack-protector-all).
 The impact is not expected to be noticeable on modern hardware. However,
 programs with a hard requirement to run at the fastest possible speed should
 avoid using this feature, or using libraries built with this feature.
 B.2.4.4. Disabling SSP on a per-package basis
 Note
 SSP should not be disabled to work around runtime crashes in the program! This
 is a very bad idea and will expose you to security vulnerabilities.
 To disable SSP on a per-package basis, set the following in the package's
 Makefile before bsd.prefs.mk is included:
 SSP_SUPPORTED=  no
 B.3. Auditing the system
 The illusion of security is worse than having no security at all. This section
 lists a number of ways to ensure the security features requested are actually
 effective.
 These instructions were obtained and tested on a system derived from NetBSD 7
 (amd64). YMMV.
 B.3.1. Checking for PIE
 The ELF executable type in use changes for binaries built as PIE; without:
 $ file /path/to/bin/ary
 /path/to/bin/ary: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for NetBSD 7.0, not stripped
 as opposed to the following binary, built as PIE:
 $ file /path/to/pie/bin/ary
 /path/to/pie/bin/ary: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for NetBSD 7.0, not stripped
 The latter result is then what is expected.
 B.3.2. Checking for partial RELRO
 The following command should list a section called RELRO:
 $ objdump -p /path/to/bin/ary
 /path/to/bin/ary:     file format elf64-x86-64
 Program Header:
 [...]
    RELRO off    0x0000000000000d78 vaddr 0x0000000000600d78 paddr 0x0000000000600d78 align 2**0
 This check is now performed automatically if PKG_DEVELOPER is set and RELRO is
 enabled.
 B.3.3. Checking for full RELRO
 The dynamic loader will apply RELRO immediately when detecting the presence of
 the BIND_NOW flag:
 $ objdump -x /path/to/bin/ary
 /path/to/bin/ary:     file format elf64-x86-64
 Dynamic Section:
 [...]
   BIND_NOW             0x0000000000000000
 This has to be combined with partial RELRO (see above) to be fully efficient.
 This check is now performed automatically (where supported) if PKG_DEVELOPER is
 set.
 B.3.4. Checking for SSP
 Note
 Checking for SSP using this method only works where the operating system uses
 libssp. libssp is not used on recent NetBSD/FreeBSD/Linux versions.
 Building objects, binaries and libraries with SSP will affect the presence of
 additional symbols in the resulting file:
 $ nm /path/to/bin/ary
 [...]
                  U __stack_chk_fail
 0000000000600ea0 B __stack_chk_guard
 This is an indicator that the program was indeed built with support for SSP.
 This check is now performed automatically (where supported) if PKG_DEVELOPER is
 set and SSP is enabled.
 Appendix C. Build logs
 Table of Contents
 C.1. Building figlet
 C.2. Packaging figlet
 C.1. Building figlet
 # make
 ===> Checking for vulnerabilities in figlet-2.2.1nb2
 => figlet221.tar.gz doesn't seem to exist on this system.
 => Attempting to fetch figlet221.tar.gz from ftp://ftp.figlet.org/pub/figlet/program/unix/.
 => [172219 bytes]
 Connected to ftp.plig.net.
 ftp.plig.org NcFTPd Server (licensed copy) ready.
 Guest login ok, send your complete e-mail address as password.
 -You are user #5 of 500 simultaneous users allowed.
 -
 -  ___ _             _ _
 - |  _| |_ ___   ___| |_|___   ___ ___ ___
 - |  _|  _| . |_| . | | | . |_| . |  _| . |
 - |_| |_| |  _|_|  _|_|_|_  |_|___|_| |_  |
 -         |_|   |_|     |___|         |___|
 -
 -** Welcome to ftp.plig.org **
 -
 -Please note that all transfers from this FTP site are logged. If you
 -do not like this, please disconnect now.
 -
 -This archive is available via
 -
 -HTTP:  http://ftp.plig.org/
 -FTP:   ftp://ftp.plig.org/     (max 500 connections)
 -RSYNC: rsync://ftp.plig.org/   (max  30 connections)
 -
 -Please email comments, bug reports and requests for packages to be
 -mirrored to ftp-admin@plig.org.
 -
 -
 Logged in anonymously.
 Remote system type is UNIX.
 Using binary mode to transfer files.
 Type okay.
 "/pub" is new cwd.
 -"/pub/figlet" is new cwd.
 -
 -Welcome to the figlet archive at ftp.figlet.org
 -
 -    ftp://ftp.figlet.org/pub/figlet/
 -
 -The official FIGlet web page is:
 -    http://www.figlet.org/
 -
 -If you have questions, please mailto:info@figlet.org. If you want to
 -contribute a font or something else, you can email us.
 "/pub/figlet/program" is new cwd.
 "/pub/figlet/program/unix" is new cwd.
 local: figlet221.tar.gz remote: figlet221.tar.gz
 Unimplemented command.
 Entering Passive Mode (195,40,6,41,246,104)
 Data connection accepted from 84.128.86.72:65131; transfer starting for figlet221.tar.gz (172219 bytes).
 % |**************                       | 65800      64.16 KB/s    00:01 ETA
 Transfer completed.
 bytes received in 00:02 (75.99 KB/s)
 Goodbye.
 => Checksum OK for figlet221.tar.gz.
 ===> Extracting for figlet-2.2.1nb2
 ===> Required installed package ccache-[0-9]*: ccache-2.3nb1 found
 ===> Patching for figlet-2.2.1nb2
 ===> Applying pkgsrc patches for figlet-2.2.1nb2
 ===> Overriding tools for figlet-2.2.1nb2
 ===> Creating toolchain wrappers for figlet-2.2.1nb2
 ===> Configuring for figlet-2.2.1nb2
 ===> Building for figlet-2.2.1nb2
 gcc -O2 -DDEFAULTFONTDIR=\"/usr/pkg/share/figlet\"  -DDEFAULTFONTFILE=\"standard.flf\"  figlet.c zipio.c crc.c inflate.c -o figlet
 chmod a+x figlet
 gcc -O2 -o chkfont chkfont.c
 => Unwrapping files-to-be-installed.
+#
 # make install
 ===> Checking for vulnerabilities in figlet-2.2.1nb2
 ===> Installing for figlet-2.2.1nb2
 install -d -o root -g wheel -m 755 /usr/pkg/bin
 install -d -o root -g wheel -m 755 /usr/pkg/man/man6
 mkdir -p /usr/pkg/share/figlet
 cp figlet /usr/pkg/bin
 cp chkfont /usr/pkg/bin
 chmod 555 figlist showfigfonts
 cp figlist /usr/pkg/bin
 cp showfigfonts /usr/pkg/bin
 cp fonts/*.flf /usr/pkg/share/figlet
 cp fonts/*.flc /usr/pkg/share/figlet
 cp figlet.6 /usr/pkg/man/man6
 ===> Registering installation for figlet-2.2.1nb2
+#
 C.2. Packaging figlet
 # make package
 ===> Checking for vulnerabilities in figlet-2.2.1nb2
 ===> Packaging figlet-2.2.1nb2
 ===> Building binary package for figlet-2.2.1nb2
 Creating package /home/cvs/pkgsrc/packages/i386/All/figlet-2.2.1nb2.tgz
 Using SrcDir value of /usr/pkg
 Registering depends:.
+#
 Appendix D. Directory layout of the pkgsrc FTP server
 Table of Contents
 D.1. distfiles: The distributed source files
 D.2. misc: Miscellaneous things
 D.3. packages: Binary packages
 D.4. reports: Bulk build reports
 D.5. current, stable, pkgsrc-20xxQy: source packages
 As in other big projects, the directory layout of pkgsrc is quite complex for
 newbies. This chapter explains where you find things on the FTP server. The
 base directory on ftp.NetBSD.org is /pub/pkgsrc/. On other servers it may be
 different, but inside this directory, everything should look the same, no
 matter on which server you are. This directory contains some subdirectories,
 which are explained below.
 D.1. distfiles: The distributed source files
 The directory distfiles contains lots of archive files from all pkgsrc
 packages, which are mirrored here. The subdirectories are called after their
 package names and are used when the distributed files have names that don't
 explicitly contain a version number or are otherwise too generic (for example
 release.tar.gz).
 D.2. misc: Miscellaneous things
 This directory contains things that individual pkgsrc developers find worth
 publishing.
 D.3. packages: Binary packages
 This directory contains binary packages for the various platforms that are
 supported by pkgsrc. Each subdirectory is of the form OPSYS/ARCH/OSVERSION_TAG.
 The meaning of these variables is:
   * OPSYS is the name of the operating system for which the packages have been
     built. The name is taken from the output of the uname command, so it may
     differ from the one you are used to hear.
   * ARCH is the hardware architecture of the platform for which the packages
     have been built. It also includes the ABI (Application Binary Interface)
     for platforms that have several of them.
   * OSVERSION is the version of the operating system. For version numbers that
     change often (for example NetBSD-current), the often-changing part should
     be replaced with an x, for example 4.99.x.
   * TAG is either 20xxQy for a stable branch, or head for packages built from
     the HEAD branch. The latter should only be used when the packages are
     updated on a regular basis. Otherwise the date from checking out pkgsrc
     should be appended, for example head_20071015.
 The rationale for exactly this scheme is that the pkgsrc users looking for
 binary packages can quickly click through the directories on the server and
 find the best binary packages for their machines. Since they usually know the
 operating system and the hardware architecture, OPSYS and ARCH are placed
 first. After these choices, they can select the best combination of OSVERSION
 and TAG together, since it is usually the case that packages stay compatible
 between different version of the operating system.
 In each of these directories, there is a whole binary packages collection for a
 specific platform. It has a directory called All which contains all binary
 packages. Besides that, there are various category directories that contain
 symbolic links to the real binary packages.
 D.4. reports: Bulk build reports
 Here are the reports from bulk builds, for those who want to fix packages that
 didn't build on some of the platforms. The structure of subdirectories should
 look like the one in Section D.3, "packages: Binary packages".
 D.5. current, stable, pkgsrc-20xxQy: source packages
 These directories contain the "real" pkgsrc, that is the files that define how
 to create binary packages from source archives.
 Each of the current, stable and pkgsrc-20xxQy directories share the same
 structure. They each contain a pkgsrc directory and pkgsrc.tar.{bz,gz,xz} file.
 The directory pkgsrc contains a snapshot of the CVS repository, which is
 updated regularly. The file pkgsrc.tar.{bz,gz,xz} contains the same as the
 directory, ready to be downloaded as a whole.
 The current directory contains files related to the HEAD branch of the CVS
 repository. In this directory there is an additional file called
 pkgsrc-readmes.tar.{bz,gz,xz} that contains all pkgsrc READMEs with information
 about categories and packages.
 The stable directory is a symlink to the latest pkgsrc-20xxQy.
 The pkgsrc-20xxQy. directories contain files related to the -20xxQy stable
 branch of the CVS repository. In these directories there is an additional file
 called pkgsrc-20xxQy.tar.{bz,gz,xz}, which contains the state of pkgsrc when it
 was branched.
 Appendix E. Help topics
 The following list contains all help topics that are available when running
 bmake help topic=:index.
 #!                                -lintl
 bit                             64bit
 ABI                               ACCEPTABLE_LICENSES
 ACROREAD_FONTPATH                 ADDITIONAL
 AFAIK                             AIX
 ALLOW_VULNERABLE_PACKAGES         ALL_ENV
-ALSA_PC                           ALTERNATIVES_SRC
+ALTERNATIVES_SRC                  AMANDA_TMP
-AMANDA_TMP                        AMANDA_USER
+AMANDA_USER                       AMANDA_VAR
-AMANDA_VAR                        APACHE_GROUP
+APACHE_GROUP                      APACHE_MODULE_NAME
-APACHE_MODULE_NAME                APACHE_MODULE_SRC
+APACHE_MODULE_SRC                 APACHE_MODULE_SRCDIR
-APACHE_MODULE_SRCDIR              APACHE_PKG_PREFIX
+APACHE_PKG_PREFIX                 APACHE_SUEXEC_CONFIGURE_ARGS
-APACHE_SUEXEC_CONFIGURE_ARGS      APACHE_SUEXEC_DOCROOT
+APACHE_SUEXEC_DOCROOT             APACHE_USER
-APACHE_USER                       APPEND_ABI
+APPEND_ABI                        APPEND_ELF
-APPEND_ELF                        ARLA_CACHE
+ARLA_CACHE                        AUDIT_PACKAGES_FLAGS
-AUDIT_PACKAGES_FLAGS              AUTOCONF_REQD
+AUTOCONF_REQD                     AUTOMAKE_OVERRIDE
-AUTOMAKE_OVERRIDE                 AUTOMAKE_REQD
+AUTOMAKE_REQD                     AUTO_MKDIRS
-AUTO_MKDIRS                       BDB185_DEFAULT
+BDB185_DEFAULT                    BDBBASE
-BDBBASE                           BDB_ACCEPTED
+BDB_ACCEPTED                      BDB_DEFAULT
-BDB_DEFAULT                       BDB_LIBS
+BDB_LIBS                          BDB_TYPE
-BDB_TYPE                          BINCIMAP_GROUP
+BINCIMAP_GROUP                    BINCIMAP_USER
-BINCIMAP_USER                     BIND_DIR
+BIND_DIR                          BIND_GROUP
-BIND_GROUP                        BIND_USER
+BIND_USER                         BINOWN
-BINOWN                            BINPKG_SITES
+BINPKG_SITES                      BIN_INSTALL_FLAGS
-BIN_INSTALL_FLAGS                 BISON_PKGDATADIR
+BISON_PKGDATADIR                  BLAS
-BLAS                              BLAS_ACCEPTED
+BLAS_ACCEPTED                     BLAS_C_INTERFACE
-BLAS_C_INTERFACE                  BLAS_INCLUDES
+BLAS_INCLUDES                     BLAS_INDEX64
-BLAS_INDEX64                      BLAS_LIBS
+BLAS_LIBS                         BLAS_TYPE
-BLAS_TYPE                         BOOTSTRAP_DEPENDS
+BOOTSTRAP_DEPENDS                 BROKEN
-BROKEN                            BROKEN_EXCEPT_ON_PLATFORM
+BROKEN_EXCEPT_ON_PLATFORM         BROKEN_ON_PLATFORM
-BROKEN_ON_PLATFORM                BSDSRCDIR
+BSDSRCDIR                         BSDXSRCDIR
-BSDXSRCDIR                        BSD_MAKE_ENV
+BSD_MAKE_ENV                      BUILDLINK_AUTO_DIRS
-BUILDLINK_AUTO_DIRS               BUILDLINK_AUTO_VARS
+BUILDLINK_AUTO_VARS               BUILDLINK_CFLAGS
-BUILDLINK_CFLAGS                  BUILDLINK_CONTENTS_FILTER
+BUILDLINK_CONTENTS_FILTER         BUILDLINK_CPPFLAGS
 BUILDLINK_CPPFLAGS                BUILDLINK_DEPMETHOD
 BUILDLINK_FILES                   BUILDLINK_FILES_CMD
 BUILDLINK_FNAME_TRANSFORM         BUILDLINK_LDFLAGS
 BUILDLINK_LIBS                    BUILDLINK_OPSYS_SUPPORT_PTHREAD
 BUILDLINK_PKGNAME                 BUILDLINK_PREFIX
 BUILDLINK_RPATHDIRS               BUILDLINK_TREE
 BUILD_DEFS                        BUILD_DEFS_EFFECTS
 BUILD_DEPENDS                     BUILD_DIRS
 BUILD_ENV_SHELL                   BUILD_MAKE_CMD
 BUILD_MAKE_FLAGS                  BUILD_TARGET
 BUILTIN_FIND_FILES                BUILTIN_FIND_FILES_VAR
 BUILTIN_FIND_GREP                 BUILTIN_FIND_HEADERS
 BUILTIN_FIND_HEADERS_VAR          BUILTIN_FIND_PKGCONFIG
 BUILTIN_FIND_PKGCONFIG_VAR        BUILTIN_PKG
 BUILTIN_TEST_CURSES_DEFINES       BUILTIN_TEST_CURSES_FUNCS
 BUILTIN_VERSION_SCRIPT            BUILTIN_X11_TYPE
 BUILTIN_X11_VERSION               CACTI_GROUP
 CACTI_USER                        CANNA_GROUP
 CANNA_USER                        CAT
 CBLAS_LIBS                        CCACHE_BASE
 CCACHE_DIR                        CCACHE_LOGFILE
 CC_VERSION                        CC_VERSION_STRING
 CDRECORD_CONF                     CDROM_PKG_URL_DIR
-CDROM_PKG_URL_HOST                CHECKOUT_DATE
+CDROM_PKG_URL_HOST                CHECK_COMPILER
-CHECK_COMPILER                    CHECK_FAKEHOME
+CHECK_FAKEHOME                    CHECK_FILES
-CHECK_FILES                       CHECK_FILES_SKIP
+CHECK_FILES_SKIP                  CHECK_FILES_STRICT
-CHECK_FILES_STRICT                CHECK_HEADERS
+CHECK_HEADERS                     CHECK_HEADERS_SKIP
-CHECK_HEADERS_SKIP                CHECK_INTERPRETER
+CHECK_INTERPRETER                 CHECK_INTERPRETER_SKIP
-CHECK_INTERPRETER_SKIP            CHECK_PERMS
+CHECK_PERMS                       CHECK_PERMS_AUTOFIX
-CHECK_PERMS_AUTOFIX               CHECK_PERMS_SKIP
+CHECK_PERMS_SKIP                  CHECK_PIE
-CHECK_PIE                         CHECK_PIE_SKIP
+CHECK_PIE_SKIP                    CHECK_PIE_SUPPORTED
-CHECK_PIE_SUPPORTED               CHECK_PORTABILITY
+CHECK_PORTABILITY                 CHECK_PORTABILITY_EXPERIMENTAL
-CHECK_PORTABILITY_EXPERIMENTAL    CHECK_PORTABILITY_SKIP
+CHECK_PORTABILITY_SKIP            CHECK_RELRO
-CHECK_RELRO                       CHECK_RELRO_SKIP
+CHECK_RELRO_SKIP                  CHECK_RELRO_SUPPORTED
-CHECK_RELRO_SUPPORTED             CHECK_SHLIBS
+CHECK_SHLIBS                      CHECK_SHLIBS_SKIP
-CHECK_SHLIBS_SKIP                 CHECK_SHLIBS_SUPPORTED
+CHECK_SHLIBS_SUPPORTED            CHECK_SHLIBS_TOXIC
-CHECK_SHLIBS_TOXIC                CHECK_SSP
+CHECK_SSP                         CHECK_SSP_SKIP
-CHECK_SSP_SKIP                    CHECK_SSP_SUPPORTED
+CHECK_SSP_SUPPORTED               CHECK_STRIPPED
-CHECK_STRIPPED                    CHECK_STRIPPED_SKIP
+CHECK_STRIPPED_SKIP               CHECK_WRKREF
-CHECK_WRKREF                      CHECK_WRKREF_EXTRA_DIRS
+CHECK_WRKREF_EXTRA_DIRS           CHECK_WRKREF_SKIP
-CHECK_WRKREF_SKIP                 CLAMAV_DBDIR
+CLAMAV_DBDIR                      CLAMAV_GROUP
-CLAMAV_GROUP                      CLAMAV_USER
+CLAMAV_USER                       CLANGBASE
-CLANGBASE                         CLEANDEPENDS
+CLEANDEPENDS                      CMAKE_DEPENDENCIES_REWRITE
-CMAKE_DEPENDENCIES_REWRITE        CMAKE_INSTALL_NAME_DIR
+CMAKE_INSTALL_NAME_DIR            CMAKE_INSTALL_PREFIX
-CMAKE_INSTALL_PREFIX              CMAKE_MODULE_PATH_OVERRIDE
+CMAKE_MODULE_PATH_OVERRIDE        CMAKE_PKGSRC_BUILD_FLAGS
-CMAKE_PKGSRC_BUILD_FLAGS          CMAKE_PREFIX_PATH
+CMAKE_PREFIX_PATH                 CMAKE_USE_GNU_INSTALL_DIRS
 CMAKE_USE_GNU_INSTALL_DIRS        COMMON_LISP_DOCFILES
 COMMON_LISP_EXAMPLES              COMMON_LISP_EXTRAFILES
 COMMON_LISP_PACKAGES              COMMON_LISP_SYSTEM
 COMPILER_RPATH_FLAG               COMPILER_USE_SYMLINKS
 CONFIGURE_ARGS                    CONFIGURE_DIRS
 CONFIGURE_ENV                     CONFIGURE_ENV_SHELL
 CONFIGURE_HAS_INFODIR             CONFIGURE_HAS_MANDIR
 CONFIGURE_SCRIPT                  CONFIG_SHELL
 CONFIG_SHELL_FLAGS                CONF_FILES
 CONF_FILES_MODE                   CONF_FILES_PERMS
 CONSERVER_DEFAULTHOST             CONSERVER_DEFAULTPORT
 CP                                CPP
 CPP_PRECOMP_FLAGS                 CREATE_WRKDIR_SYMLINK
 CROSSBASE                         CTFCONVERT
 CTF_FILES_SKIP                    CTF_SUPPORTED
 CTYPE                             CUPS_GROUP
 CUPS_SYSTEM_GROUPS                CUPS_USER
 CURSES_DEFAULT                    CURSES_TYPE
-CVS_EXTRACTDIR                    CVS_MODULE
+CXX                               CYRUS_GROUP
-CVS_PROJECT                       CVS_REPOSITORIES
+CYRUS_IDLE                        CYRUS_USER
-CVS_ROOT                          CVS_ROOT_GNU
+DAEMONTOOLS_GROUP                 DAEMONTOOLS_LOG_USER
-CVS_ROOT_NONGNU                   CVS_ROOT_SOURCEFORGE
+DARWIN_NO_SYSTEM_LIBS             DARWIN_REQUIRES_FILTER
-CVS_TAG                           CXX
+DBUS_GROUP                        DBUS_USER
-CYRUS_GROUP                       CYRUS_IDLE
+DEFANG_GROUP                      DEFANG_USER
-CYRUS_USER                        DAEMONTOOLS_GROUP
+DEFAULT_ACCEPTABLE_LICENSES       DEFAULT_DISTFILES
-DAEMONTOOLS_LOG_USER              DARWIN_NO_SYSTEM_LIBS
+DEFAULT_IRC_SERVER                DEFAULT_SERIAL_DEVICE
-DARWIN_REQUIRES_FILTER            DBUS_GROUP
+DEF_UMASK                         DEINSTALLDEPENDS
-DBUS_USER                         DEFANG_GROUP
+DEINSTALL_SRC                     DEINSTALL_TEMPLATES
-DEFANG_USER                       DEFAULT_ACCEPTABLE_LICENSES
+DELAYED_ERROR_MSG                 DELAYED_WARNING_MSG
-DEFAULT_DISTFILES                 DEFAULT_IRC_SERVER
+DEPENDS                           DEPENDS_TARGET
-DEFAULT_SERIAL_DEVICE             DEF_UMASK
+DEPENDS_TYPE                      DESTDIR
-DEINSTALLDEPENDS                  DEINSTALL_SRC
+DESTDIR_VARNAME                   DIALER_GROUP
-DEINSTALL_TEMPLATES               DELAYED_ERROR_MSG
+DIGEST_REQD                       DISTDIR
-DELAYED_WARNING_MSG               DEPENDS
+DISTFILES                         DISTINFO_FILE
-DEPENDS_TARGET                    DEPENDS_TYPE
+DISTNAME                          DIST_PATH
-DESTDIR                           DESTDIR_VARNAME
+DIST_SUBDIR                       DJBDNS_AXFR_USER
-DIALER_GROUP                      DIGEST_REQD
+DJBDNS_CACHE_USER                 DJBDNS_DJBDNS_GROUP
-DISTDIR                           DISTFILES
+DJBDNS_LOG_USER                   DJBDNS_RBL_USER
-DISTINFO_FILE                     DISTNAME
+DJBDNS_TINY_USER                  DLOPEN_REQUIRE_PTHREADS
-DIST_PATH                         DIST_SUBDIR
+DL_AUTO_VARS                      DL_CFLAGS
-DJBDNS_AXFR_USER                  DJBDNS_CACHE_USER
+DL_LDFLAGS                        DL_LIBS
-DJBDNS_DJBDNS_GROUP               DJBDNS_LOG_USER
+DNS                               DOCOWN
-DJBDNS_RBL_USER                   DJBDNS_TINY_USER
+DOWNLOADED_DISTFILE               DQCACHE_GROUP
-DLOPEN_REQUIRE_PTHREADS           DL_AUTO_VARS
+DQCACHE_USER                      DT_LAYOUT
-DL_CFLAGS                         DL_LDFLAGS
+DYNAMIC_SITES_CMD                 DYNAMIC_SITES_SCRIPT
-DL_LIBS                           DNS
+ECHO                              ECHO_N
-DOCOWN                            DOWNLOADED_DISTFILE
+ELK_GUI                           EMACS_TYPE
-DQCACHE_GROUP                     DQCACHE_USER
+EMULDIR                           EMULSUBDIR
-DT_LAYOUT                         DYNAMIC_SITES_CMD
+EMULSUBDIRSLASH                   EMUL_ARCH
-DYNAMIC_SITES_SCRIPT              ECHO
+EMUL_DISTRO                       EMUL_EXEC_FMT
-ECHO_N                            ELK_GUI
+EMUL_IS_NATIVE                    EMUL_MODULES
-EMACS_TYPE                        EMULDIR
+EMUL_OPSYS                        EMUL_PKG_FMT
-EMULSUBDIR                        EMULSUBDIRSLASH
+EMUL_PLATFORM                     EMUL_PLATFORMS
-EMUL_ARCH                         EMUL_DISTRO
+EMUL_PREFER                       EMUL_REQD
-EMUL_EXEC_FMT                     EMUL_IS_NATIVE
+EMUL_TYPE                         ERROR_MSG
-EMUL_MODULES                      EMUL_OPSYS
+EXIM_GROUP                        EXIM_USER
-EMUL_PKG_FMT                      EMUL_PLATFORM
+EXPORT_SYMBOLS_LDFLAGS            EXTRACTOR
-EMUL_PLATFORMS                    EMUL_PREFER
+EXTRACT_CMD                       EXTRACT_CMD_DEFAULT
-EMUL_REQD                         EMUL_TYPE
+EXTRACT_DIR                       EXTRACT_ELEMENTS
-ERROR_MSG                         EXIM_GROUP
+EXTRACT_ENV                       EXTRACT_ONLY
-EXIM_USER                         EXPORT_SYMBOLS_LDFLAGS
+EXTRACT_OPTS                      EXTRACT_SUFX
-EXTRACTOR                         EXTRACT_CMD
+EXTRACT_USING                     FAIL
-EXTRACT_CMD_DEFAULT               EXTRACT_DIR
+FAILOVER_FETCH                    FAIL_MSG
-EXTRACT_ELEMENTS                  EXTRACT_ENV
+FAKE_NCURSES                      FAM
-EXTRACT_ONLY                      EXTRACT_OPTS
+FAM_ACCEPTED                      FAM_DEFAULT
-EXTRACT_SUFX                      EXTRACT_USING
+FAM_SERVER                        FCPATH
-FAIL                              FAILOVER_FETCH
+FEATURE_CPPFLAGS                  FEATURE_LDFLAGS
-FAIL_MSG                          FAKE_NCURSES
+FEATURE_LIBS                      FETCH_AFTER_ARGS
-FAM                               FAM_ACCEPTED
+FETCH_BEFORE_ARGS                 FETCH_CMD
-FAM_DEFAULT                       FAM_SERVER
+FETCH_OUTPUT_ARGS                 FETCH_PROXY
-FCPATH                            FEATURE_CPPFLAGS
+FETCH_RESUME_ARGS                 FETCH_TIMEOUT
-FEATURE_LDFLAGS                   FEATURE_LIBS
+FETCH_USE_IPV4_ONLY               FETCH_USING
-FETCH_AFTER_ARGS                  FETCH_BEFORE_ARGS
+FILES_SUBST                       FILES_SUBST_SED
-FETCH_CMD                         FETCH_OUTPUT_ARGS
+FIX_SYSTEM_HEADERS                FONTS_DIRS
 FETCH_PROXY                       FETCH_RESUME_ARGS
 FETCH_TIMEOUT                     FETCH_USE_IPV4_ONLY
 FETCH_USING                       FILES_SUBST
 FILES_SUBST_SED                   FIX_SYSTEM_HEADERS
 FONTDIR                           FONTS_DIRS
 FONTS_VERBOSE                     FOO_HACKS_MK
 FOSSIL_EXTRACTDIR                 FOSSIL_REPO
 FOSSIL_REPOSITORIES               FOSSIL_VERSION
 FOX_USE_XUNICODE                  FREEWNN_GROUP
 FREEWNN_USER                      FTP_PKG_URL_DIR
 FTP_PKG_URL_HOST                  GAMEDATAMODE
 GAMEDATA_PERMS                    GAMEDIRMODE
 GAMEDIR_PERMS                     GAMEGRP
 GAMEMODE                          GAMEOWN
 GAMES_GROUP                       GAMES_USER
 GCC                               GCCBASE
 GCC_REQD                          GCC_VERSION_SUFFIX
 GEM_BUILD                         GEM_CLEANBUILD
 GEM_CLEANBUILD_EXTENSIONS         GEM_DOCDIR
 GEM_EXTSDIR                       GEM_HOME
 GEM_KEEPBUILD                     GEM_LIBDIR
 GEM_NAME                          GEM_PATH
 GEM_PLUGINSDIR                    GEM_SPECFILE
 GENERATE_PLIST                    GHC
 GHOSTSCRIPT_REQD                  GITHUB_PROJECT
 GITHUB_RELEASE                    GITHUB_SUBMODULES
 GITHUB_TAG                        GITHUB_TYPE
-GITLAB_PROJECT                    GITLAB_TAG
+GITLAB_PROJECT                    GITLAB_RELEASE
-GITLAB_TYPE                       GIT_BRANCH
+GITLAB_SUBMODULES                 GITLAB_TAG
-GIT_ENV                           GIT_EXTRACTDIR
+GITLAB_TYPE                       GNU
-GIT_REPO                          GIT_REPOSITORIES
+GNU_CONFIGURE                     GNU_CONFIGURE_INFODIR
-GIT_REVISION                      GIT_TAG
+GNU_CONFIGURE_MANDIR              GNU_CONFIGURE_QUIET
-GNU                               GNU_CONFIGURE
+GNU_CONFIGURE_STRICT              GODEP_REDIRECTS
-GNU_CONFIGURE_INFODIR             GNU_CONFIGURE_MANDIR
+GO_BUILD_PATTERN                  GO_DEPS
-GNU_CONFIGURE_QUIET               GNU_CONFIGURE_STRICT
+GO_DIST_BASE                      GO_EXTRA_MOD_DIRS
-GODEP_REDIRECTS                   GO_BUILD_PATTERN
+GO_MODULE_FILES                   GO_SRCPATH
-GO_DEPS                           GO_DIST_BASE
+GO_VERSION_DEFAULT                GROUP_SPECIFIC_PKGS
-GO_EXTRA_MOD_DIRS                 GO_MODULE_FILES
+GRUB_NETWORK_CARDS                GRUB_PRESET_COMMAND
-GO_SRCPATH                        GO_VERSION_DEFAULT
+GRUB_SCAN_ARGS                    GZIP
 GROUP_SPECIFIC_PKGS               GRUB_NETWORK_CARDS
 GRUB_PRESET_COMMAND               GRUB_SCAN_ARGS
 GZIP                              HASKELL_COMPILER
 HASKELL_ENABLE_DYNAMIC_EXECUTABLE HASKELL_ENABLE_HADDOCK_DOCUMENTATION
 HASKELL_ENABLE_LIBRARY_PROFILING  HASKELL_ENABLE_SHARED_LIBRARY
 HASKELL_OPTIMIZATION_LEVEL        HAS_CONFIGURE
-HEADER_TEMPLATES                  HG_REPO
+HEADER_TEMPLATES                  HOMEPAGE
-HG_REPOSITORIES                   HG_TAG
+HOST_PKGTOOLS_ARGS                HOST_SPECIFIC_PKGS
-HOMEPAGE                          HOST_PKGTOOLS_ARGS
+HOWL_GROUP                        HOWL_USER
-HOST_SPECIFIC_PKGS                HOWL_GROUP
+ICCBASE                           ICECAST_CHROOTDIR
-HOWL_USER                         ICCBASE
+ICON_THEMES                       IDOBASE
-ICECAST_CHROOTDIR                 ICON_THEMES
+IGNORE_CCACHE                     IGNORE_INFO_DIRS
-IDOBASE                           IGNORE_CCACHE
+IGNORE_INTERACTIVE_FETCH          IMAKE
-IGNORE_INFO_DIRS                  IGNORE_INTERACTIVE_FETCH
+IMAKEOPTS                         IMAKE_MAKE
-IMAKE                             IMAKEOPTS
+IMAKE_MANINSTALL                  IMAP_UW_CCLIENT_MBOX_FMT
-IMAKE_MAKE                        IMAKE_MANINSTALL
+IMDICTDIR                         INCOMPAT_CURSES
-IMAP_UW_CCLIENT_MBOX_FMT          IMDICTDIR
+INFO_DIR                          INFO_FILES
-INCOMPAT_CURSES                   INFO_DIR
+INFO_FILES_VERBOSE                INFO_MSG
-INFO_FILES                        INFO_FILES_VERBOSE
+INIT_SYSTEM                       INN_DATA_DIR
-INFO_MSG                          INIT_SYSTEM
+INN_GROUP                         INN_USER
-INN_DATA_DIR                      INN_GROUP
+INSTALLATION_DIRS                 INSTALLATION_DIRS_FROM_PLIST
-INN_USER                          INSTALLATION_DIRS
+INSTALL_ENV                       INSTALL_SH_OVERRIDE
-INSTALLATION_DIRS_FROM_PLIST      INSTALL_ENV
+INSTALL_SRC                       INSTALL_TEMPLATES
-INSTALL_SH_OVERRIDE               INSTALL_SRC
+INSTALL_UNSTRIPPED                IRCD_HYBRID_IRC_GROUP
-INSTALL_TEMPLATES                 INSTALL_UNSTRIPPED
+IRCD_HYBRID_IRC_USER              IRCD_HYBRID_MAXCONN
-IRCD_HYBRID_IRC_GROUP             IRCD_HYBRID_IRC_USER
+IRCD_HYBRID_NICLEN                IRCD_HYBRID_SYSLOG_EVENTS
-IRCD_HYBRID_MAXCONN               IRCD_HYBRID_NICLEN
+IRCD_HYBRID_SYSLOG_FACILITY       IRCD_HYBRID_TOPICLEN
-IRCD_HYBRID_SYSLOG_EVENTS         IRCD_HYBRID_SYSLOG_FACILITY
+IRIX                              IRRD_USE_PGP
-IRCD_HYBRID_TOPICLEN              IRIX
+JABBERD_GROUP                     JABBERD_LOGDIR
-IRRD_USE_PGP                      JABBERD_GROUP
+JABBERD_PIDDIR                    JABBERD_SPOOLDIR
-JABBERD_LOGDIR                    JABBERD_PIDDIR
+JABBERD_USER                      JAVA_BINPREFIX
-JABBERD_SPOOLDIR                  JABBERD_USER
+JAVA_CLASSPATH                    JAVA_HOME
-JAVA_APP_PATH                     JAVA_APP_TARGETS
+JAVA_LD_LIBRARY_PATH              JAVA_NAME
-JAVA_BINPREFIX                    JAVA_CLASSPATH
+JAVA_UNLIMIT                      JAVA_WRAPPERS
-JAVA_HOME                         JAVA_LD_LIBRARY_PATH
+JPEG_ACCEPTED                     JPEG_DEFAULT
-JAVA_NAME                         JAVA_UNLIMIT
+KERBEROS                          KERMIT_SUID_UUCP
-JAVA_WRAPPERS                     JPEG_ACCEPTED
+KJS_USE_PCRE                      KNEWS_DOMAIN_FILE
-JPEG_DEFAULT                      KERBEROS
+KNEWS_DOMAIN_NAME                 KRB5_ACCEPTED
-KERMIT_SUID_UUCP                  KJS_USE_PCRE
+KRB5_DEFAULT                      LANGUAGES
-KNEWS_DOMAIN_FILE                 KNEWS_DOMAIN_NAME
+LAPACKE_LIBS                      LAPACK_LIBS
-KRB5_ACCEPTED                     KRB5_DEFAULT
+LATEX2HTML_ICONPATH               LDCONFIG_ADD_CMD
-LANGUAGES                         LAPACKE_LIBS
+LDCONFIG_REMOVE_CMD               LDD
-LAPACK_LIBS                       LATEX2HTML_ICONPATH
+LEAFNODE_DATA_DIR                 LEAFNODE_GROUP
-LDCONFIG_ADD_CMD                  LDCONFIG_REMOVE_CMD
+LEAFNODE_USER                     LIBDVDCSS_HOMEPAGE
-LDD                               LEAFNODE_DATA_DIR
+LIBDVDCSS_MASTER_SITES            LIBRSVG_TYPE
-LEAFNODE_GROUP                    LEAFNODE_USER
+LIBTOOL                           LIBTOOLIZE_PLIST
-LIBDVDCSS_HOMEPAGE                LIBDVDCSS_MASTER_SITES
+LIBTOOL_M4_OVERRIDE               LIBUSB_TYPE
-LIBRSVG_TYPE                      LIBTOOL
+LICENSE                           LINKER_RPATH_FLAG
-LIBTOOLIZE_PLIST                  LIBTOOL_M4_OVERRIDE
+LINK_RPATH_FLAG                   LINUX_LOCALES
 LIBUSB_TYPE                       LICENSE
 LINKER_RPATH_FLAG                 LINK_RPATH_FLAG
 LINUX_BASE_NODEPS                 LINUX_BASE_PREFERRED
 LINUX_BASE_REQUIRED               LINUX_LOCALES
 LOCALBASE                         LOCALBASE_LOCKTYPE
 LOCALPATCHES                      LOVE_DATA
 LOVE_GAME                         LOVE_VERSION
 LP32PLATFORMS                     LP64PLATFORMS
 LUA_BUSTED_ARGS                   LUA_CDIR
 LUA_COMPILER                      LUA_DOCDIR
 LUA_EXAMPLESDIR                   LUA_INCDIR
 LUA_INTERPRETER                   LUA_LDIR
 LUA_LINKER_MAGIC                  LUA_PKGPREFIX
 LUA_SELF_CONFLICT                 LUA_USE_BUSTED
 LUA_VERSIONS_ACCEPTED             LUA_VERSIONS_INCOMPATIBLE
 LUA_VERSION_DEFAULT               LUA_VERSION_REQD
 Lua                               MACHINE_PLATFORM
 MAILAGENT_DOMAIN                  MAILAGENT_EMAIL
 MAILAGENT_FQDN                    MAILAGENT_ORGANIZATION
-MAJORDOMO_HOMEDIR                 MAJOR_OS_VERSION
+MAJORDOMO_HOMEDIR                 MAKEINFO_ARGS
-MAKEINFO_ARGS                     MAKE_DIRS
+MAKE_DIRS                         MAKE_DIRS_PERMS
-MAKE_DIRS_PERMS                   MAKE_ENV
+MAKE_ENV                          MAKE_FILE
-MAKE_FILE                         MAKE_FLAGS
+MAKE_FLAGS                        MAKE_JOBS
-MAKE_JOBS                         MAKE_JOBS_SAFE
+MAKE_JOBS_SAFE                    MAKE_PROGRAM
-MAKE_PROGRAM                      MANCOMPRESSED_IF_MANZ
+MANCOMPRESSED_IF_MANZ             MANINSTALL
-MANINSTALL                        MANZ
+MANZ                              MASTER_SITES
-MASTER_SITES                      MASTER_SITE_BACKUP
+MASTER_SITE_BACKUP                MASTER_SITE_LOCAL
-MASTER_SITE_LOCAL                 MASTER_SITE_MOZILLA
+MASTER_SITE_MOZILLA               MASTER_SITE_OVERRIDE
-MASTER_SITE_OVERRIDE              MASTER_SITE_PERL_CPAN
+MASTER_SITE_PERL_CPAN             MASTER_SORT
-MASTER_SORT                       MASTER_SORT_RANDOM
+MASTER_SORT_RANDOM                MASTER_SORT_REGEX
-MASTER_SORT_REGEX                 MECAB_CHARSET
+MECAB_CHARSET                     MEDIATOMB_GROUP
-MEDIATOMB_GROUP                   MEDIATOMB_USER
+MEDIATOMB_USER                    MIPSPROBASE
-MIPSPROBASE                       MIREDO_GROUP
+MIREDO_GROUP                      MIREDO_USER
-MIREDO_USER                       MISSING_FEATURES
+MISSING_FEATURES                  MKDIR
-MKDIR                             MKPIE_SUPPORTED
+MKPIE_SUPPORTED                   MLDONKEY_GROUP
-MLDONKEY_GROUP                    MLDONKEY_HOME
+MLDONKEY_HOME                     MLDONKEY_USER
-MLDONKEY_USER                     MONOTONE_GROUP
+MONOTONE_GROUP                    MONOTONE_USER
-MONOTONE_USER                     MOTIFBASE
+MOTIFBASE                         MOTIF_TYPE
-MOTIF_TYPE                        MOTIF_TYPE_DEFAULT
+MOTIF_TYPE_DEFAULT                MPI_TYPE
-MPI_TYPE                          MSGFMT_STRIP_MSGCTXT
+MSGFMT_STRIP_MSGCTXT              MSGFMT_STRIP_MSGID_PLURAL
-MSGFMT_STRIP_MSGID_PLURAL         MTOOLS_ENABLE_FLOPPYD
+MTOOLS_ENABLE_FLOPPYD             MV
 MUST                              MV
 MYSQL_CHARSET                     MYSQL_DATADIR
 MYSQL_EXTRA_CHARSET               MYSQL_GROUP
 MYSQL_USER                        MYSQL_VERSION
 MYSQL_VERSIONS_ACCEPTED           MYSQL_VERSIONS_ALL
 MYSQL_VERSION_DEFAULT             NAGIOSCMD_GROUP
 NAGIOSDIR                         NAGIOS_GROUP
 NAGIOS_USER                       NATIVE_APPEND_ABI
 NATIVE_APPEND_ELF                 NATIVE_EXEC_FMT
 NATIVE_MACHINE_PLATFORM           NATIVE_OBJECT_FMT
 NBPAX_PROGRAM_PREFIX              NETBSD_LOGIN_NAME
 NMH_EDITOR                        NMH_MTA
 NMH_PAGER                         NODE_VERSIONS_ACCEPTED
 NODE_VERSIONS_INCOMPATIBLE        NODE_VERSION_DEFAULT
 NODE_VERSION_REQD                 NOLOGIN
 NOTE                              NOT_FOR_PLATFORM
 NOT_PAX_ASLR_SAFE                 NOT_PAX_MPROTECT_SAFE
 NO_BUILD                          NO_CHECKSUM
 NO_CONFIGURE                      NO_SKIP
 NS_PREFERRED                      NULLMAILER_GROUP
 NULLMAILER_USER                   OASIS
 OASIS_BUILD_ARGS                  OBJHOSTNAME
 OBJMACHINE                        OCAML_FINDLIB_DIRS
 OCAML_FINDLIB_REGISTER            OCAML_FINDLIB_REGISTER_VERBOSE
 OCAML_SITELIBDIR                  OCAML_TOPKG_DOCDIR
 OCAML_USE_DUNE                    OCAML_USE_FINDLIB
 OCAML_USE_OASIS                   OCAML_USE_OASIS_DYNRUN
-OCAML_USE_OPAM                    OCAML_USE_OPT_COMPILER
+OCAML_USE_OPAM                    OCAML_USE_TOPKG
-OCAML_USE_TOPKG                   OMF
+OMF                               ONLY_FOR_COMPILER
-ONLY_FOR_COMPILER                 ONLY_FOR_PLATFORM
+ONLY_FOR_PLATFORM                 OPENSSH_CHROOT
-OPENSSH_CHROOT                    OPENSSH_GROUP
+OPENSSH_GROUP                     OPENSSH_USER
-OPENSSH_USER                      OPSYS
+OPSYS                             OPSYS_EMULDIR
-OPSYS_EMULDIR                     OPSYS_VERSION
+OPSYS_VERSION                     OS
-OS                                OSS_TYPE
+OSS_TYPE                          OSX
-OSX                               OSX_TOLERATE_SDK_SKEW
+OSX_TOLERATE_SDK_SKEW             OS_VARIANT
-OS_HAVE_ALSA                      OS_HAVE_RCD
+OS_VERSION                        OTF_FONTS_DIR
-OS_VARIANT                        OS_VERSION
+OVERRIDE_DIRDEPTH                 OVERRIDE_GEMSPEC
-OTF_FONTS_DIR                     OVERRIDE_DIRDEPTH
+OVERRIDE_GNU_CONFIG_SCRIPTS       OWN_DIRS
 OVERRIDE_GEMSPEC                  OVERRIDE_GNU_CONFIG_SCRIPTS
 OVERRIDE_ROCKSPEC                 OWN_DIRS
 OWN_DIRS_PERMS                    P4GROUP
 P4PORT                            P4ROOT
 P4USER                            PACKAGES
 PALMOS_DEFAULT_SDK                PAMBASE
 PAM_DEFAULT                       PAPERSIZE
 PASSIVE_FETCH                     PATCHDIR
 PATCHFILES                        PATCH_ARGS
 PATCH_DEBUG                       PATCH_DIST_ARGS
 PATCH_DIST_CAT                    PATCH_DIST_STRIP
 PATCH_FUZZ_FACTOR                 PATCH_STRIP
 PATH                              PCCBASE
 PEAR                              PEAR_CHANNEL
 PEAR_CHANNEL_ALIAS                PEAR_CHANNEL_VERSION
 PEAR_CMD                          PEAR_LIB
 PEAR_PACKAGE_XML                  PERL5
 PERL5_CONFIGURE                   PERL5_CONFIGURE_DIRS
 PERL5_LDFLAGS                     PERL5_LICENSE
 PERL5_MODULE_TYPE                 PERL5_PACKLIST
 PERL5_PACKLIST_DIR                PERL5_PERLBASE
 PERL5_SITEBASE                    PERL5_USE_PACKLIST
 PERL5_VENDORBASE                  PFCTL
 PFVAR_H                           PF_VERSION
 PGGROUP                           PGHOME
 PGPKGSRCDIR                       PGSQL_TYPE
 PGSQL_VERSION                     PGSQL_VERSIONS_ACCEPTED
 PGSQL_VERSION_DEFAULT             PGUSER
 PG_LIB_EXT                        PHP
 PHPCOMMON_MK                      PHPPKGSRCDIR
 PHP_BASE_VERS                     PHP_CHECK_INSTALLED
 PHP_EXTENSION_DIR                 PHP_INITIAL_TEENY
 PHP_PKG_PREFIX                    PHP_VERSION
 PHP_VERSIONS_ACCEPTED             PHP_VERSIONS_INCOMPATIBLE
 PHP_VERSION_DEFAULT               PHP_VERSION_REQD
 PILRC_USE_GTK                     PKGCONFIG_BASE
 PKGCONFIG_FILE                    PKGCONFIG_OVERRIDE
 PKGCONFIG_OVERRIDE_STAGE          PKGDIR
 PKGGNUDIR                         PKGINFODIR
 PKGLOCALEDIR                      PKGMANDIR
 PKGNAME                           PKGNAME_REQD
 PKGPATH                           PKGREVISION
 PKGSRC_BLAS_TYPES                 PKGSRC_CHANGES
 PKGSRC_COMPILER                   PKGSRC_KEEP_BIN_PKGS
 PKGSRC_LOCKTYPE                   PKGSRC_MAKE_ENV
 PKGSRC_MESSAGE_RECIPIENTS         PKGSRC_MKPIE
 PKGSRC_MKREPRO                    PKGSRC_OVERRIDE_MKPIE
 PKGSRC_RUN_TEST                   PKGSRC_SETENV
 PKGSRC_SLEEPSECS                  PKGSRC_TODO
 PKGSRC_USE_CTF                    PKGSRC_USE_FORTIFY
 PKGSRC_USE_RELRO                  PKGSRC_USE_SSP
 PKGSRC_USE_STACK_CHECK            PKGTASKS_DATAFILE
 PKGTOOLS_ARGS                     PKGTOOLS_ENV
 PKG_ALTERNATIVES                  PKG_APACHE
 PKG_APACHE_ACCEPTED               PKG_APACHE_DEFAULT
 PKG_BEST_EXISTS                   PKG_BUILD_OPTIONS
 PKG_COMPRESSION                   PKG_CONFIG
 PKG_CONFIG_PERMS                  PKG_CREATE_USERGROUP
 PKG_DB_TMPDIR                     PKG_DEBUG_LEVEL
 PKG_DEFAULT_OPTIONS               PKG_DESTDIR_SUPPORT
 PKG_DEVELOPER                     PKG_DISABLED_OPTIONS
 PKG_FATAL_ERRORS                  PKG_FC
 PKG_FILELIST_CMD                  PKG_GECOS
 PKG_GID                           PKG_GROUPS
 PKG_GROUPS_VARS                   PKG_HOME
 PKG_INIT_SCRIPTS                  PKG_JAVA_HOME
 PKG_JVM                           PKG_JVMS_ACCEPTED
 PKG_JVM_DEFAULT                   PKG_LEGACY_OPTIONS
 PKG_LIBTOOL                       PKG_OPTIONS
 PKG_OPTIONS_DEPRECATED_WARNINGS   PKG_OPTIONS_LEGACY_OPTS
 PKG_OPTIONS_LEGACY_VARS           PKG_OPTIONS_NONEMPTY_SETS
 PKG_OPTIONS_OPTIONAL_GROUPS       PKG_OPTIONS_REQUIRED_GROUPS
 PKG_OPTIONS_VAR                   PKG_PHP
 PKG_PHP_MAJOR_VERS                PKG_PHP_VERSION
 PKG_RCD_SCRIPTS                   PKG_REFCOUNT_DBDIR
 PKG_REGISTER_SHELLS               PKG_RESUME_TRANSFERS
 PKG_SHELL                         PKG_SUGGESTED_OPTIONS
 PKG_SUPPORTED_OPTIONS             PKG_SYSCONFBASE
 PKG_SYSCONFBASEDIR                PKG_SYSCONFDIR
 PKG_SYSCONFDIR_PERMS              PKG_SYSCONFSUBDIR
 PKG_SYSCONFVAR                    PKG_TOOLS_BIN
 PKG_UID                           PKG_UPDATE_FONTS_DB
 PKG_USERS                         PKG_USERS_VARS
 PKG_VERBOSE                       PLEASE
 PLIST                             PLIST_AWK
 PLIST_AWK_ENV                     PLIST_SRC
 PLIST_SUBST                       PLIST_TYPE
 PLIST_VARS                        POPTOP_USE_MPPE
 POSSIBLE_GFORTRAN_VERSION         POST_FETCH_HOOK
 PREFER                            PREFER_NATIVE
 PREFER_NATIVE_PTHREADS            PREFER_PKGSRC
 PREFIX                            PREPEND_PATH
 PRE_ROOT_CMD                      PRIVILEGED_STAGES
 PS                                PTHREAD_AUTO_VARS
 PTHREAD_CFLAGS                    PTHREAD_LDFLAGS
 PTHREAD_LIBS                      PTHREAD_OPTS
 PTHREAD_TYPE                      PVM_SSH
 PYPKGPREFIX                       PYTHON_FOR_BUILD_ONLY
 PYTHON_SELF_CONFLICT              PYTHON_VERSIONED_DEPENDENCIES
 PYTHON_VERSIONS_ACCEPTED          PYTHON_VERSIONS_INCOMPATIBLE
 PYTHON_VERSION_DEFAULT            PYTHON_VERSION_REQD
 PYVERSSUFFIX                      QMAILDIR
 QMAIL_ALIAS_USER                  QMAIL_DAEMON_USER
 QMAIL_LOG_USER                    QMAIL_NOFILES_GROUP
 QMAIL_PASSWD_USER                 QMAIL_QMAIL_GROUP
 QMAIL_QUEUE_DIR                   QMAIL_QUEUE_EXTRA
 QMAIL_QUEUE_USER                  QMAIL_REMOTE_USER
 QMAIL_ROOT_USER                   QMAIL_SEND_USER
 QORE_LATEST_MODULE_API            QORE_MODULE_API
 QORE_MODULE_DIR                   QORE_USER_MODULE_DIR
 QORE_VERSION                      QPOPPER_FAC
 QPOPPER_SPOOL_DIR                 QPOPPER_USER
 RAKE_NAME                         RASMOL_DEPTH
 RCD_DIR                           RCD_ORDER
 RCD_SCRIPTS                       RCD_SCRIPTS_DIR
 RCD_SCRIPTS_EXAMPLEDIR            RCD_SCRIPTS_MODE
 RCD_SCRIPTS_SHELL                 RCD_SCRIPT_SRC
-RCD_SUBR                          RDOC
+RDOC                              READLINE_DEFAULT
-READLINE_DEFAULT                  READLINE_TYPE
+READLINE_TYPE                     REAL_ROOT_GROUP
-REAL_ROOT_GROUP                   REAL_ROOT_USER
+REAL_ROOT_USER                    RECURSIVE_MAKE
-RECURSIVE_MAKE                    RELAY_CTRL_DIR
+RELAY_CTRL_DIR                    RELRO_SUPPORTED
-RELRO_SUPPORTED                   REPLACE_AWK
+REPLACE_AWK                       REPLACE_BASH
-REPLACE_BASH                      REPLACE_CSH
+REPLACE_CSH                       REPLACE_KSH
-REPLACE_KSH                       REPLACE_LUA
+REPLACE_LUA                       REPLACE_NODEJS
-REPLACE_NODEJS                    REPLACE_OCTAVE
+REPLACE_OCTAVE                    REPLACE_PERL
-REPLACE_PERL                      REPLACE_PERL6
+REPLACE_PERL6                     REPLACE_PHP
-REPLACE_PHP                       REPLACE_PYTHON
+REPLACE_PYTHON                    REPLACE_QORE
-REPLACE_QORE                      REPLACE_R
+REPLACE_R                         REPLACE_RUBY
-REPLACE_RUBY                      REPLACE_RUBY_DIRS
+REPLACE_RUBY_DIRS                 REPLACE_RUBY_PAT
-REPLACE_RUBY_PAT                  REPLACE_SH
+REPLACE_SH                        REPLACE_TEXLUA
-REPLACE_TEXLUA                    REPLACE_WISH
+REPLACE_WISH                      REQD_DIRS
-REQD_DIRS                         REQD_DIRS_PERMS
+REQD_DIRS_PERMS                   REQD_FILES
-REQD_FILES                        REQD_FILES_MODE
+REQD_FILES_MODE                   REQD_FILES_PERMS
-REQD_FILES_PERMS                  RESOLV_AUTO_VARS
+RESOLV_AUTO_VARS                  RESOLV_LDFLAGS
-RESOLV_LDFLAGS                    RESOLV_LIBS
+RESOLV_LIBS                       RM
-RM                                ROCKSPEC_NAME
+ROOT_CMD                          ROOT_GROUP
-ROCKSPEC_SPECFILE                 ROOT_CMD
+ROOT_USER                         RPCGEN
-ROOT_GROUP                        ROOT_USER
+RPM                               RPM2PKG_PLIST
-RPCGEN                            RPM
+RPM2PKG_PREFIX                    RPM2PKG_STAGE
-RPM2PKG_PLIST                     RPM2PKG_PREFIX
+RPM2PKG_STRIP                     RPM2PKG_SUBPREFIX
-RPM2PKG_STAGE                     RPM2PKG_STRIP
+RPMFILES                          RPMIGNOREPATH
-RPM2PKG_SUBPREFIX                 RPMFILES
+RPM_DB_PREFIX                     RSSH_CVS_PATH
-RPMIGNOREPATH                     RPM_DB_PREFIX
+RSSH_RDIST_PATH                   RSSH_RSYNC_PATH
-RSSH_CVS_PATH                     RSSH_RDIST_PATH
+RSSH_SCP_PATH                     RSSH_SFTP_SERVER_PATH
-RSSH_RSYNC_PATH                   RSSH_SCP_PATH
+RUBY                              RUBYGEM
-RSSH_SFTP_SERVER_PATH             RUBY
+RUBYGEM_NAME                      RUBYGEM_OPTIONS
-RUBYGEM                           RUBYGEM_NAME
+RUBYGEM_VERBOSE                   RUBY_ABI_VERSION
-RUBYGEM_OPTIONS                   RUBYGEM_VERBOSE
+RUBY_ARCH                         RUBY_ARCHINC
-RUBY_ABI_VERSION                  RUBY_ARCH
+RUBY_ARCHLIB                      RUBY_BASE
-RUBY_ARCHINC                      RUBY_ARCHLIB
+RUBY_BASERIDIR                    RUBY_BUILD_DOCUMENT
-RUBY_BASE                         RUBY_BASERIDIR
+RUBY_DLEXT                        RUBY_DOC
-RUBY_BUILD_DOCUMENT               RUBY_DLEXT
+RUBY_DYNAMIC_DIRS                 RUBY_EG
-RUBY_DOC                          RUBY_DYNAMIC_DIRS
+RUBY_ENCODING_ARG                 RUBY_EXTCONF
-RUBY_EG                           RUBY_ENCODING_ARG
+RUBY_EXTCONF_CHECK                RUBY_EXTCONF_DEBUG
-RUBY_EXTCONF                      RUBY_EXTCONF_CHECK
+RUBY_EXTCONF_MAKEFILE             RUBY_GEM_ARCH
-RUBY_EXTCONF_DEBUG                RUBY_EXTCONF_MAKEFILE
+RUBY_GEM_BASE                     RUBY_INC
-RUBY_GEM_ARCH                     RUBY_GEM_BASE
+RUBY_LIB                          RUBY_LIB_BASE
-RUBY_INC                          RUBY_LIB
+RUBY_NAME                         RUBY_NOVERSION
-RUBY_LIB_BASE                     RUBY_NAME
+RUBY_PKGPREFIX                    RUBY_RAILS
-RUBY_NOVERSION                    RUBY_PKGPREFIX
+RUBY_RAILS52_VERSION              RUBY_RAILS60_VERSION
-RUBY_RAILS                        RUBY_RAILS52_VERSION
+RUBY_RAILS61_VERSION              RUBY_RAILS70_VERSION
-RUBY_RAILS60_VERSION              RUBY_RAILS61_VERSION
+RUBY_RAILS_ACCEPTED               RUBY_RAILS_DEFAULT
-RUBY_RAILS70_VERSION              RUBY_RAILS_ACCEPTED
+RUBY_RAILS_REQD                   RUBY_RAILS_STRICT_DEP
-RUBY_RAILS_DEFAULT                RUBY_RAILS_REQD
+RUBY_RIDIR                        RUBY_SETUP
-RUBY_RAILS_STRICT_DEP             RUBY_RIDIR
+RUBY_SHLIB                        RUBY_SHLIBALIAS
-RUBY_SETUP                        RUBY_SHLIB
+RUBY_SHLIBVER                     RUBY_SIMPLE_INSTALL
-RUBY_SHLIBALIAS                   RUBY_SHLIBVER
+RUBY_SITEARCHLIB                  RUBY_SITELIB
-RUBY_SIMPLE_INSTALL               RUBY_SITEARCHLIB
+RUBY_SITELIB_BASE                 RUBY_SITERIDIR
-RUBY_SITELIB                      RUBY_SITELIB_BASE
+RUBY_SLEXT                        RUBY_SRCDIR
-RUBY_SITERIDIR                    RUBY_SLEXT
+RUBY_STATICLIB                    RUBY_SUFFIX
-RUBY_SRCDIR                       RUBY_STATICLIB
+RUBY_SYSRIDIR                     RUBY_USE_PTHREAD
-RUBY_SUFFIX                       RUBY_SYSRIDIR
+RUBY_VENDORARCHLIB                RUBY_VENDORLIB
-RUBY_USE_PTHREAD                  RUBY_VENDORARCHLIB
+RUBY_VENDORLIB_BASE               RUBY_VER
-RUBY_VENDORLIB                    RUBY_VENDORLIB_BASE
+RUBY_VERSION                      RUBY_VERSIONS_ACCEPTED
-RUBY_VER                          RUBY_VERSION
+RUBY_VERSIONS_INCOMPATIBLE        RUBY_VERSION_DEFAULT
-RUBY_VERSIONS_ACCEPTED            RUBY_VERSIONS_INCOMPATIBLE
+RUBY_VERSION_REQD                 RUBY_VER_DIR
-RUBY_VERSION_DEFAULT              RUBY_VERSION_REQD
+RUN                               RUN_LDCONFIG
-RUBY_VER_DIR                      RUN
+RUST_TYPE                         SCO
-RUN_LDCONFIG                      RUST_TYPE
+SCREWS_GROUP                      SCREWS_USER
-SCO                               SCREWS_GROUP
+SCRIPTS_ENV                       SCROLLKEEPER_DATADIR
-SCREWS_USER                       SCRIPTS_ENV
+SCROLLKEEPER_REBUILDDB            SCROLLKEEPER_UPDATEDB
-SCROLLKEEPER_DATADIR              SCROLLKEEPER_REBUILDDB
+SDIST_PAWD                        SDL12_TYPE
-SCROLLKEEPER_UPDATEDB             SDIST_PAWD
+SERIAL_DEVICES                    SETGIDGAME
-SDL12_TYPE                        SERIAL_DEVICES
+SETGID_GAMES_PERMS                SETUID_ROOT_PERMS
-SETGIDGAME                        SETGID_GAMES_PERMS
+SH                                SHLIB
 SETUID_ROOT_PERMS                 SH
 SHLIB                             SHORTNAME
 SIGN_PACKAGES                     SILC_CLIENT_WITH_PERL
 SITE_SPECIFIC_PKGS                SKIP_DEPENDS
 SMF_INSTANCES                     SMF_MANIFEST
 SMF_METHODS                       SMF_METHOD_SHELL
 SMF_METHOD_SRC                    SMF_NAME
 SMF_PREFIX                        SMF_SRCDIR
 SNIPROXY_GROUP                    SNIPROXY_USER
 SOURCE_BUFFSIZE                   SPECIAL_PERMS
 SPECIFIC_PKGS                     SSH_SUID
 SSP_SUPPORTED                     SSYNC_PAWD
 STEP_MSG                          STRIP
 STRIP_DBG                         STRIP_DEBUG
 STRIP_DEBUG_SUPPORTED             STRIP_FILES_SKIP
 SU                                SUBDIR
 SUBST                             SUBST_CLASSES
 SUBST_FILES                       SUBST_FILTER_CMD
 SUBST_MESSAGE                     SUBST_NOOP_OK
 SUBST_SED                         SUBST_SHOW_DIFF
 SUBST_SKIP_TEXT_CHECK             SUBST_STAGE
 SUBST_VARS                        SUNWSPROBASE
 SUSE_PREFER                       SU_CMD
 SVN_EXTRACTDIR                    SVN_REPO
 SVN_REPOSITORIES                  SVN_REVISION
 SYSCONFBASE                       TARGET_ARCH
 TBL                               TERMCAP_TYPE
 TERMINFO_DEFAULT                  TERMINFO_TYPE
 TEST                              TEST_DEPENDS
 TEST_DIRS                         TEST_ENV
 TEST_ENV_SHELL                    TEST_MAKE_CMD
 TEST_MAKE_FLAGS                   TEST_TARGET
 TEXLIVE_IGNORE_PATTERNS           TEXLIVE_REV
 TEXLIVE_UNVERSIONED               TEXMFSITE
 TEX_FORMATS                       TEX_HYPHEN_DAT
 TEX_HYPHEN_DEF                    TEX_TEXMF_DIRS
 THTTPD_LOG_FACILITY               TINYDYN_USER
 TLSWRAPPER_CHROOT                 TO
 TOOLS_ALIASES                     TOOLS_ALWAYS_WRAP
 TOOLS_ARGS                        TOOLS_BROKEN
 TOOLS_CMD                         TOOLS_CMDLINE_SED
 TOOLS_CREATE                      TOOLS_CROSS_DESTDIR
 TOOLS_DIR                         TOOLS_FAIL
 TOOLS_GNU_MISSING                 TOOLS_LDCONFIG
 TOOLS_NOOP                        TOOLS_PATH
 TOOLS_SCRIPT                      TOOLS_USE_CROSS_COMPILE
-TOOL_DEPENDS                      TTF_FONTDIR
+TOOL_DEPENDS                      TTF_FONTS_DIR
-TTF_FONTS_DIR                     TYPE
+TYPE                              UAC_REQD_EXECS
-UAC_REQD_EXECS                    UCSPI_SSL_GROUP
+UCSPI_SSL_GROUP                   UCSPI_SSL_USER
-UCSPI_SSL_USER                    UNLIMIT_RESOURCES
+UNLIMIT_RESOURCES                 UNPRIVILEGED
-UNPRIVILEGED                      UNPRIVILEGED_GROUP
+UNPRIVILEGED_GROUP                UNPRIVILEGED_GROUPS
-UNPRIVILEGED_GROUPS               UNPRIVILEGED_USER
+UNPRIVILEGED_USER                 UNWRAP_FILES
-UNWRAP_FILES                      UNWRAP_PATTERNS
+UNWRAP_PATTERNS                   UPDATE_GEMSPEC
-UPDATE_GEMSPEC                    UPDATE_TARGET
+UPDATE_TARGET                     URI
-URI                               USERGROUP_PHASE
+USERGROUP_PHASE                   USERPPP_GROUP
-USERPPP_GROUP                     USER_SPECIFIC_PKGS
+USER_SPECIFIC_PKGS                USE_ABI_DEPENDS
-USE_ABI_DEPENDS                   USE_APR
+USE_APR                           USE_BSD_MAKEFILE
-USE_BSD_MAKEFILE                  USE_BUILTIN
+USE_BUILTIN                       USE_CROSS_COMPILE
-USE_CROSS_COMPILE                 USE_CURSES
+USE_CURSES                        USE_CWRAPPERS
-USE_CWRAPPERS                     USE_DB185
+USE_DB185                         USE_FEATURES
-USE_FEATURES                      USE_GAMESGROUP
+USE_GAMESGROUP                    USE_GCC_RUNTIME
-USE_GCC_RUNTIME                   USE_IMAKE
+USE_IMAKE                         USE_JAVA
-USE_JAVA                          USE_JAVA2
+USE_JAVA2                         USE_LANGUAGES
-USE_LANGUAGES                     USE_LIBTOOL
+USE_LIBTOOL                       USE_NATIVE_GCC
-USE_NATIVE_GCC                    USE_NETBSD_REPO
+USE_NETBSD_REPO                   USE_PKGSRC_GCC
-USE_PKGSRC_GCC                    USE_PKGSRC_GCC_RUNTIME
+USE_PKGSRC_GCC_RUNTIME            USE_PKGTASKS
-USE_PKGTASKS                      USE_PKG_ADMIN_DIGEST
+USE_PKG_ADMIN_DIGEST              USE_RUBY_EXTCONF
-USE_RUBY_EXTCONF                  USE_RUBY_INSTALL
+USE_RUBY_INSTALL                  USE_RUBY_SETUP
-USE_RUBY_SETUP                    USE_RUBY_SETUP_PKG
+USE_RUBY_SETUP_PKG                USE_TOOLS
-USE_TOOLS                         UUCP_GROUP
+UUCP_GROUP                        UUCP_USER
-UUCP_USER                         VARBASE
+VARBASE                           VARNAME
-VARNAME                           VIM_EXTRA_OPTS
+VIM_EXTRA_OPTS                    WARNING_MSG
-WARNING_MSG                       WCALC_CGIDIR
+WCALC_CGIDIR                      WCALC_CGIPATH
-WCALC_CGIPATH                     WCALC_HTMLDIR
+WCALC_HTMLDIR                     WCALC_HTMLPATH
-WCALC_HTMLPATH                    WDM_MANAGERS
+WDM_MANAGERS                      WRAPPER_CC
-WRAPPER_CC                        WRAPPER_REORDER_CMDS
+WRAPPER_REORDER_CMDS              WRKDIR
-WRKDIR                            WRKDIR_BASENAME
+WRKDIR_BASENAME                   WRKDIR_LOCKTYPE
-WRKDIR_LOCKTYPE                   WRKLOG
+WRKLOG                            WRKOBJDIR
-WRKOBJDIR                         WRKSRC
+WRKSRC                            X10_PORT
-X10_PORT                          X11
+X11                               X11BASE
-X11BASE                           X11_PKGSRCDIR
+X11_PKGSRCDIR                     X11_TYPE
-X11_TYPE                          X509_CERTIFICATE
+X509_CERTIFICATE                  X509_KEY
-X509_KEY                          XAW_TYPE
+XAW_TYPE                          XLOCK_DEFAULT_MODE
-XLOCK_DEFAULT_MODE                XMKMF
+XMKMF                             XMKMF_FLAGS
-XMKMF_FLAGS                       XXX
+XXX                               YES
 XXXX                              YES
 ZSH_STATIC                        __stdc__
 _vargroups                        accept
 acquire-localbase-lock            acquire-lock
 add                               administrator
 alloca                            alternatives
 aslr                              asprintf
 atlas                             autoconf
 automake                          autoreconf
 awk                               bash
 big-endian                        bin-install
 bind                              binpkg-list
 blas                              bootstrap-depends
 broken                            broken_on_platform
 bsd                               bsd.prog.mk
 build                             build-env
 buildlink-directories             buildlink-oss-soundcard-h
 c                                 c++
 ccache                            cce
 cdefs                             ceil
 changes                           changes-entry
 changes-entry-noupdate            check
 check-clean                       check-files
 check-files-clean                 check-vulnerable
 checksum                          checksum-phase
 clean                             clean-depends
 cleandir                          commit
 commit-changes-entry              compact
 compiler                          conf
 config.guess                      config.sub
 configuration                     configure
 configure-env                     configure-help
 configure_args                    connect
 cos                               cputime
 create-usergroup                  csh
-ctf                               cvs
+ctf                               debug
-debug                             declaration
+declaration                       declare
-declare                           defined
+defined                           depend
-depend                            dependencies
+dependencies                      depends
-depends                           depends-checksum
+depends-checksum                  depends-fetch
-depends-fetch                     deps
+deps                              describe
-describe                          destdir
+destdir                           disable
-disable                           distclean
+distclean                         distinfo
-distinfo                          dl
+dl                                dlopen
-dlopen                            do-buildlink
+do-buildlink                      do-clean
-do-clean                          do-configure
+do-configure                      do-configure-post-hook
-do-configure-post-hook            do-extract
+do-extract                        do-fetch
-do-fetch                          do-install
+do-install                        emul
-emul                              emul-distinfo
+emul-distinfo                     emul-fetch
-emul-fetch                        emulation
+emulation                         emulator
-emulator                          enable
+enable                            endian
 endian                            endif
 enomem                            ensurepip
 err                               errx
 etc                               exp
 extract-rpm                       fabs
 feature                           features
 fetch                             fetch-list
 follows                           forbids
 form                              format
 fortify                           fortify_source
-fossil                            friend
+friend                            fts
-fts                               fts_close
+fts_close                         fts_open
-fts_open                          fts_read
+fts_read                          fts_set
-fts_set                           gcc
+gcc                               gethostbyaddr
-gethostbyaddr                     gethostbyname
+gethostbyname                     gethostbyname2
-gethostbyname2                    getopt_long
+getopt_long                       getprogname
-getprogname                       getservbyname
+getservbyname                     getservbyport
-getservbyport                     getservent
+getservent                        gettext
 gettext                           git
 github                            gitlab
 glob                              gnu
 gnu_configure_strict              go
 go-deps                           golang
 guess-license                     hashbang
 heimdal                           help
-hg                                imake
+imake                             increment
-increment                         indirect
+indirect                          inet_aton
-inet_aton                         interp
+interp                            interpreter
-interpreter                       intl
+intl                              ip4
-ip4                               ip6
+ip6                               ipv4
-ipv4                              ipv6
+ipv6                              iso
-iso                               kerberos
+kerberos                          krb
-krb                               krb5
+krb5                              ksh
-ksh                               lapack
+lapack                            latex
-latex                             libintl_bindtextdomain
+libintl_bindtextdomain            libintl_gettext
-libintl_gettext                   libintl_textdomain
+libintl_textdomain                libnbcompat
-libnbcompat                       libs
+libs                              libtool
-libtool                           licence
+licence                           license
-license                           lintl
+lintl                             little-endian
-little-endian                     lock
+lock                              locking
-locking                           lua
+lua                               lvalue
-lvalue                            make
+make                              makesum
-makesum                           memory
+memory                            meta
 mercurial                         meta
 meta-package                      meta_package
 mit-krb5                          mk.conf
 mkl                               mount
 mprotect                          mremap
 nb                                nbcompat
 netlib                            node
 node.js                           nodejs
 obstack                           obstack_ptr_grow
 occurs                            only
 openblas                          options
 options.mk                        order
 override                          override-intltool
 override-message-intltool         package
 parallel                          path
 pax                               paxctl
 pbulk-index                       pc
 perl                              perl5
 perms                             php
 pkg-build-options                 pkg-config
 pkg_build_options                 platform
 plist                             post-extract
 post-fetch                        post-wrapper
 pre-build-checks-hook             pre-configure
 pre-configure-checks-hook         pre-extract
 pre-fetch                         print-go-deps
 print-plist                       print-summary-data
 privileged-install-hook           pypi
 python                            r
 readme-all                        recursive
 recv                              recvfrom
 regcomp                           release-localbase-lock
 release-lock                      relro
 rename                            reorder
 replace                           replace_interpreter
 reproducible                      resolv
 root                              ruby
 send                              sendfile
 sendto                            setenv
 setgid                            setprogname
 setuid                            sh
 shebang                           show
 show-all                          show-build-defs
 show-depends                      show-depends-dirs
 show-depends-pkgpaths             show-depends-recursive
 show-deps                         show-distfiles
 show-downlevel                    show-subdir-var
 show-tools                        show-var
 show-vars                         snprintf
 socket                            ssp
 st_mode                           stage-install
 strcasestr                        strict
 strip                             strndup
 strnlen                           strsep
 subst                             substitutions
-subversion                        sun
+sun                               sunpro
-sunpro                            sunwspro
+sunwspro                          symlink
 svn                               symlink
 test                              test-env
 tex                               texlive
 tmp                               tool
 tools                             tools-libtool-m4-override
 transitive                        type
 ulimit                            undefined
 undo-replace                      unlimit
 unprivileged                      unprivileged-install-hook
 unstripped                        update
 upload                            upload-distfiles
 use_tools                         user
 utimes                            vasprintf
 verbose                           vsnprintf
 warn                              warning
 warnings                          warnx
 wattr_off                         wattr_on
 work                              wrapper
 wrkdir
 Appendix F. Editing guidelines for the pkgsrc guide
 Table of Contents
 F.1. Make targets
 F.2. Procedure
 This section contains information on editing the pkgsrc guide itself.
 F.1. Make targets
 The pkgsrc guide's source code is stored in pkgsrc/doc/guide/files, and several
 files are created from it:
   * pkgsrc/doc/pkgsrc.txt
   * pkgsrc/doc/pkgsrc.html
   * https://www.NetBSD.org/docs/pkgsrc/
   * https://www.NetBSD.org/docs/pkgsrc/pkgsrc.pdf: The PDF version of the
     pkgsrc guide.
   * https://www.NetBSD.org/docs/pkgsrc/pkgsrc.ps: PostScript version of the
     pkgsrc guide.
 F.2. Procedure
 The procedure to edit the pkgsrc guide is:
 . Make sure you have checked out the htdocs repository into a sibling
     directory of your pkgsrc directory. You will need the ability to commit
     from both pkgsrc and htdocs.
 . Make sure you have the packages needed to regenerate the pkgsrc guide (and
     other XML-based NetBSD documentation) installed. These are automatically
     installed when you install the meta-pkgs/pkgsrc-guide-tools package.
 . Run cd doc/guide to get to the right directory. All further steps will take
     place here.
 . Edit the XML file(s) in files/.
 . Run bmake to check the pkgsrc guide for valid XML and to build the final
     output files. If you get any errors at this stage, you can just edit the
     files, as there are only symbolic links in the working directory, pointing
     to the files in files/.
 . (cd files && cvs commit)
 . Run bmake clean && bmake to regenerate the output files with the proper RCS
     Ids.
 . Run bmake regen to install and commit the files in both pkgsrc/doc and
     htdocs.
     Note
     If you have added, removed or renamed some chapters, you need to
     synchronize them using cvs add or cvs delete in the htdocs directory.