 @@ -3169,2031 +3169,2044 @@ anymore, you can remove that file and ru
 <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></dd>
 <dt><span class="chapter"><a href="#creating">14. Creating a new pkgsrc package from scratch</a></span></dt>
 <dd><dl>
 <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></dd>
 <dt><span class="chapter"><a href="#makefile">15. Programming in <code class="filename">Makefile</code>s</a></span></dt>
 <dd><dl>
 <dt><span class="sect1"><a href="#makefile.style">15.1. Caveats</a></span></dt>
 <dt><span class="sect1"><a href="#makefile.variables">15.2. <code class="filename">Makefile</code> variables</a></span></dt>
 <dd><dl><dt><span class="sect2"><a href="#makefile.variables.names">15.2.1. Naming conventions</a></span></dt></dl></dd>
 <dt><span class="sect1"><a href="#makefile.code">15.3. Code snippets</a></span></dt>
 <dd><dl>
 <dt><span class="sect2"><a href="#adding-to-list">15.3.1. Adding things to a list</a></span></dt>
 <dt><span class="sect2"><a href="#echo-literal">15.3.2. Echoing a string exactly as-is</a></span></dt>
 <dt><span class="sect2"><a href="#cflags-gnu-configure">15.3.3. Passing <code class="varname">CFLAGS</code> to GNU configure scripts</a></span></dt>
 <dt><span class="sect2"><a href="#empty-variables">15.3.4. Handling possibly empty variables</a></span></dt>
 </dl></dd>
 </dl></dd>
 <dt><span class="chapter"><a href="#options">16. Options handling</a></span></dt>
 <dd><dl>
 <dt><span class="sect1"><a href="#global-default-options">16.1. Global default options</a></span></dt>
 <dt><span class="sect1"><a href="#converting-to-options">16.2. Converting packages to use <code class="filename">bsd.options.mk</code></a></span></dt>
 <dt><span class="sect1"><a href="#option-names">16.3. Option Names</a></span></dt>
 <dt><span class="sect1"><a href="#option-build">16.4. Determining the options of dependencies</a></span></dt>
 </dl></dd>
 <dt><span class="chapter"><a href="#tools">17. Tools needed for building or running</a></span></dt>
 <dd><dl>
 <dt><span class="sect1"><a href="#pkgsrc-tools">17.1. Tools for pkgsrc builds</a></span></dt>
 <dt><span class="sect1"><a href="#package-tools">17.2. Tools needed by packages</a></span></dt>
 <dt><span class="sect1"><a href="#platform-tools">17.3. Tools provided by platforms</a></span></dt>
 </dl></dd>
 <dt><span class="chapter"><a href="#buildlink">18. Buildlink methodology</a></span></dt>
 <dd><dl>
 <dt><span class="sect1"><a href="#converting-to-buildlink3">18.1. Converting packages to use buildlink3</a></span></dt>
 <dt><span class="sect1"><a href="#creating-buildlink3.mk">18.2. Writing <code class="filename">buildlink3.mk</code> files</a></span></dt>
 <dd><dl>
 <dt><span class="sect2"><a href="#anatomy-of-bl3">18.2.1. Anatomy of a buildlink3.mk file</a></span></dt>
 <dt><span class="sect2"><a href="#updating-buildlink-depends">18.2.2. Updating
       <code class="varname">BUILDLINK_API_DEPENDS.<em class="replaceable"><code>pkg</code></em></code>
       and
       <code class="varname">BUILDLINK_ABI_DEPENDS.<em class="replaceable"><code>pkg</code></em></code>
       in <code class="filename">buildlink3.mk</code> files</a></span></dt>
 </dl></dd>
 <dt><span class="sect1"><a href="#writing-builtin.mk">18.3. Writing <code class="filename">builtin.mk</code> files</a></span></dt>
 <dd><dl>
 <dt><span class="sect2"><a href="#anatomy-of-builtin.mk">18.3.1. Anatomy of a <code class="filename">builtin.mk</code> file</a></span></dt>
 <dt><span class="sect2"><a href="#native-or-pkgsrc-preference">18.3.2. Global preferences for native or pkgsrc software</a></span></dt>
 </dl></dd>
 </dl></dd>
 <dt><span class="chapter"><a href="#plist">19. PLIST issues</a></span></dt>
 <dd><dl>
 <dt><span class="sect1"><a href="#rcs-id">19.1. RCS ID</a></span></dt>
 <dt><span class="sect1"><a href="#automatic-plist-generation">19.2. Semi-automatic <code class="filename">PLIST</code> generation</a></span></dt>
 <dt><span class="sect1"><a href="#print-PLIST">19.3. Tweaking output of <span class="command"><strong>make print-PLIST</strong></span></a></span></dt>
 <dt><span class="sect1"><a href="#plist.misc">19.4. Variable substitution in PLIST</a></span></dt>
 <dt><span class="sect1"><a href="#manpage-compression">19.5. Man page compression</a></span></dt>
 <dt><span class="sect1"><a href="#using-PLIST_SRC">19.6. Changing PLIST source with <code class="varname">PLIST_SRC</code></a></span></dt>
 <dt><span class="sect1"><a href="#platform-specific-plist">19.7. Platform-specific and differing PLISTs</a></span></dt>
 <dt><span class="sect1"><a href="#build-plist">19.8. Build-specific PLISTs</a></span></dt>
 <dt><span class="sect1"><a href="#faq.common-dirs">19.9. Sharing directories between packages</a></span></dt>
 </dl></dd>
 <dt><span class="chapter"><a href="#pkginstall">20. The pkginstall framework</a></span></dt>
 <dd><dl>
 <dt><span class="sect1"><a href="#files-and-dirs-outside-prefix">20.1. Files and directories outside the installation prefix</a></span></dt>
 <dd><dl>
 <dt><span class="sect2"><a href="#dirs-outside-prefix">20.1.1. Directory manipulation</a></span></dt>
 <dt><span class="sect2"><a href="#files-outside-prefix">20.1.2. File manipulation</a></span></dt>
 </dl></dd>
 <dt><span class="sect1"><a href="#conf-files">20.2. Configuration files</a></span></dt>
 <dd><dl>
 <dt><span class="sect2"><a href="#conf-files-sysconfdir">20.2.1. How <code class="varname">PKG_SYSCONFDIR</code> is set</a></span></dt>
 <dt><span class="sect2"><a href="#conf-files-configure">20.2.2. Telling the software where configuration files are</a></span></dt>
 <dt><span class="sect2"><a href="#conf-files-patching">20.2.3. Patching installations</a></span></dt>
 <dt><span class="sect2"><a href="#conf-files-disable">20.2.4. Disabling handling of configuration files</a></span></dt>
 </dl></dd>
 <dt><span class="sect1"><a href="#rcd-scripts">20.3. System startup scripts</a></span></dt>
 <dd><dl><dt><span class="sect2"><a href="#rcd-scripts-disable">20.3.1. Disabling handling of system startup scripts</a></span></dt></dl></dd>
 <dt><span class="sect1"><a href="#users-and-groups">20.4. System users and groups</a></span></dt>
 <dt><span class="sect1"><a href="#shells">20.5. System shells</a></span></dt>
 <dd><dl><dt><span class="sect2"><a href="#shells-disable">20.5.1. Disabling shell registration</a></span></dt></dl></dd>
 <dt><span class="sect1"><a href="#fonts">20.6. Fonts</a></span></dt>
 <dd><dl><dt><span class="sect2"><a href="#fonts-disable">20.6.1. Disabling automatic update of the fonts databases</a></span></dt></dl></dd>
 </dl></dd>
 <dt><span class="chapter"><a href="#fixes">21. Making your package work</a></span></dt>
 <dd><dl>
 <dt><span class="sect1"><a href="#general-operation">21.1. General operation</a></span></dt>
 <dd><dl>
 <dt><span class="sect2"><a href="#pulling-vars-from-etc-mk.conf">21.1.1. How to pull in user-settable variables from <code class="filename">mk.conf</code></a></span></dt>
 <dt><span class="sect2"><a href="#user-interaction">21.1.2. User interaction</a></span></dt>
 <dt><span class="sect2"><a href="#handling-licenses">21.1.3. Handling licenses</a></span></dt>
 <dt><span class="sect2"><a href="#restricted-packages">21.1.4. Restricted packages</a></span></dt>
 <dt><span class="sect2"><a href="#dependencies">21.1.5. Handling dependencies</a></span></dt>
 <dt><span class="sect2"><a href="#conflicts">21.1.6. Handling conflicts with other packages</a></span></dt>
 <dt><span class="sect2"><a href="#not-building-packages">21.1.7. Packages that cannot or should not be built</a></span></dt>
 <dt><span class="sect2"><a href="#undeletable-packages">21.1.8. Packages which should not be deleted, once installed</a></span></dt>
 <dt><span class="sect2"><a href="#security-handling">21.1.9. Handling packages with security problems</a></span></dt>
 <dt><span class="sect2"><a href="#bumping-pkgrevision">21.1.10. How to handle incrementing versions when fixing an existing package</a></span></dt>
 <dt><span class="sect2"><a href="#fixes.subst">21.1.11. Substituting variable text in the package files (the SUBST framework)</a></span></dt>
 </dl></dd>
 <dt><span class="sect1"><a href="#fixes.fetch">21.2. The <span class="emphasis"><em>fetch</em></span> phase</a></span></dt>
 <dd><dl>
 <dt><span class="sect2"><a href="#no-plain-download">21.2.1. Packages whose distfiles aren't available for plain downloading</a></span></dt>
 <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
+<dd>
-      <code class="varname">PKGSRCDIR</code> that points to the current
+<p>This is a pathname relative to
-      package.</p></dd>
+      <code class="varname">PKGSRCDIR</code> that points to the current package.
       It is defined after including <code class="filename">bsd.prefs.mk</code>
       and can be used in makefile fragments that are used by several
       packages to distinguish between these packages. Other variables
       that would serve the same purpose are <code class="varname">PKGBASE</code>
       and <code class="varname">PKGNAME</code>, but these are only defined after
       including <code class="filename">bsd.pkg.mk</code>, which is too
       late.</p>
 <p>In <a class="link" href="#mk.conf"><code class="filename">mk.conf</code></a>, the pkgsrc user can use
       <code class="varname">PKGPATH</code> to tweak variables like
       <code class="varname">MAKE_JOBS</code> and
       <code class="varname">CFLAGS</code>.</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
+    <em class="replaceable"><code>phase</code></em></strong></span>, where
-    phase. This will automatically run all phases that are required for this
+    <em class="replaceable"><code>phase</code></em> is the name of the phase. This will
-    phase. The default phase is <code class="varname">build</code>, that is, when you
+    automatically run all phases that are required for this phase. The
-    run <span class="command"><strong>make</strong></span> without parameters in a package directory,
+    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_GITLAB</td>
 </tr>
 <tr>
 <td>MASTER_SITE_GNOME</td>
 <td>MASTER_SITE_GNU</td>
 </tr>
 <tr>
 <td>MASTER_SITE_GNUSTEP</td>
 <td>MASTER_SITE_HASKELL_HACKAGE</td>
 </tr>
 <tr>
 <td>MASTER_SITE_IFARCHIVE</td>
 <td>MASTER_SITE_KDE</td>
 </tr>
 <tr>
 <td>MASTER_SITE_MOZILLA</td>
 <td>MASTER_SITE_MOZILLA_ALL</td>
 </tr>
 <tr>
 <td>MASTER_SITE_MYSQL</td>
 <td>MASTER_SITE_NETLIB</td>
 </tr>
 <tr>
 <td>MASTER_SITE_OPENBSD</td>
 <td>MASTER_SITE_OPENOFFICE</td>
 </tr>
 <tr>
 <td>MASTER_SITE_OSDN</td>
 <td>MASTER_SITE_PERL_CPAN</td>
 </tr>
 <tr>
 <td>MASTER_SITE_PGSQL</td>
 <td>MASTER_SITE_PYPI</td>
 </tr>
 <tr>
 <td>MASTER_SITE_RUBYGEMS</td>
 <td>MASTER_SITE_R_CRAN</td>
 </tr>
 <tr>
 <td>MASTER_SITE_SOURCEFORGE</td>
 <td>MASTER_SITE_SUNSITE</td>
 </tr>
 <tr>
 <td>MASTER_SITE_SUSE</td>
 <td>MASTER_SITE_TEX_CTAN</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
 @@ -7998,1998 +8011,2007 @@ cases.
 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
     she-bangs in files. Please use the appropriate one, preferring
     <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 class="sect3">
 <div class="titlepage"><div><div><h4 class="title">
 <a name="undefined-reference-atomic"></a>21.5.4.2.�Missing atomic functions</h4></div></div></div>
 <p>When building for older machine architectures (e.g., i386, PowerPC),
   builds may fail because the package expects modern 64-bit atomic functions
   which the underlying hardware either doesn't support, or will only support
   with specific compiler flags. This is generally handled via inclusion of
   mk/atomic64.mk.</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>
 </tr></thead>
 <tbody>
 <tr>
 <td>Installs icons under the
         <code class="filename">share/icons/hicolor</code> hierarchy or updates
         <code class="filename">share/icons/hicolor/icon-theme.cache</code>.</td>
 <td>See <a class="xref" href="#hicolor-theme" title="21.6.16.�Packages installing hicolor icons">Section�21.6.16, &#8220;Packages installing hicolor icons&#8221;</a>.</td>
 </tr>
 <tr>
 <td>Installs files under
         <code class="filename">share/mime/packages</code>.</td>
 <td>See <a class="xref" href="#mime-database" title="21.6.11.�Packages installing extensions to the MIME database">Section�21.6.11, &#8220;Packages installing extensions to the MIME database&#8221;</a>.</td>
 </tr>
 <tr>
 <td>Installs <code class="filename">.desktop</code> files under
         <code class="filename">share/applications</code> and these include MIME
         information.</td>
 <td>See <a class="xref" href="#desktop-files" title="21.6.17.�Packages installing desktop files">Section�21.6.17, &#8220;Packages installing desktop files&#8221;</a>.</td>
 </tr>
 </tbody>
 </table></div>
 </div>
 <br class="table-break">
 </div>
 <div class="sect1">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
 <a name="full-update"></a>22.3.�Updating GNOME to a newer version</h2></div></div></div>
 <p>When seeing GNOME as a whole, there are two kinds of
 updates:</p>
 <div class="variablelist"><dl class="variablelist">
 <dt><span class="term">Major update</span></dt>
 <dd>
 <p>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
       <code class="literal">2.X</code> version to a <code class="literal">2.Y</code> one,
       where <code class="literal">Y</code> is even and greater than
       <code class="literal">X</code>.  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.</p>
 <p>A major update typically consists of around 80 package
       updates and the addition of some new ones.</p>
 </dd>
 <dt><span class="term">Minor update</span></dt>
 <dd>
 <p>We consider a minor update one that goes from a
       <code class="literal">2.A.X</code> version to a <code class="literal">2.A.Y</code>
       one where <code class="literal">Y</code> is greater than
       <code class="literal">X</code>.  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.</p>
 <p>A minor update typically consists of around 50 package
       updates, although the numbers here may vary a lot.</p>
 </dd>
 </dl></div>
 <p>In order to update the GNOME components in pkgsrc to a new stable
 release (either major or minor), the following steps should be
 followed:</p>
 <div class="orderedlist"><ol class="orderedlist" type="1">
 <li class="listitem">
 <p>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 <code class="filename">list.txt</code>
     file:</p>
 <pre class="screen"><code class="prompt">%</code> <strong class="userinput"><code>echo ls "*.tar.bz2" | \
     ftp -V ftp://ftp.gnome.org/pub/gnome/platform/x.y/x.y.z/sources/ | \
     awk '{ print $9 }' &gt;list.txt</code></strong>
 <code class="prompt">%</code> <strong class="userinput"><code>echo ls "*.tar.bz2" | \
     ftp -V ftp://ftp.gnome.org/pub/gnome/desktop/x.y/x.y.z/sources/ | \
     awk '{ print $9 }' &gt;&gt;list.txt</code></strong></pre>
 </li>
 <li class="listitem"><p>Open each meta package's <code class="filename">Makefile</code> 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 <code class="varname">PKGREVISION</code>s that might be
     in them.</p></li>
 <li class="listitem">
 <p>For each meta package, update all its
     <code class="varname">DEPENDS</code> lines to match the latest versions as
     shown by the above commands.  Do <span class="emphasis"><em>not</em></span> 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.</p>
 <p>Packages not listed in the <code class="filename">list.txt</code> 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 <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> meta package.</p>
 </li>
 <li class="listitem">
 <p>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:</p>
 <pre class="screen"><code class="prompt">%</code> <strong class="userinput"><code>cvs diff -u gnome-devel gnome-base gnome | grep '^+D' &gt;todo.txt</code></strong></pre>
 </li>
 <li class="listitem"><p>For major desktop updates it is recommended to zap all your
     installed packages and start over from scratch at this point.</p></li>
 <li class="listitem"><p>Now comes the longest step by far: iterate over the contents
     of <code class="filename">todo.txt</code> 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.</p></li>
 <li class="listitem"><p>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 <code class="filename">doc/CHANGES-&lt;YEAR&gt;</code> and
     <a href="http://cvsweb.NetBSD.org/bsdweb.cgi/pkgsrc/doc/TODO?rev=HEAD&amp;content-type=text/x-cvsweb-markup" target="_top"><code class="filename">pkgsrc/doc/TODO</code></a> files.</p></li>
 </ol></div>
 </div>
 <div class="sect1">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
 <a name="patching"></a>22.4.�Patching guidelines</h2></div></div></div>
 <p>GNOME is a very big component in pkgsrc which approaches 100
 packages.  Please, it is very important that you always, always,
 <span class="strong"><strong>always</strong></span> feed back any portability
 fixes you do to a GNOME package to the mainstream developers (see <a class="xref" href="#components.patches.feedback" title="12.3.5.�Feedback to the author">Section�12.3.5, &#8220;Feedback to the author&#8221;</a>).  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.</p>
 <p>The most common places to report bugs are the <a class="ulink" href="https://gitlab.gnome.org/GNOME" target="_top">GNOME's GitLab</a> and the <a class="ulink" href="https://gitlab.freedesktop.org/explore/groups" target="_top">freedesktop.org's
 GitLab</a>.  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.</p>
 <p>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 <code class="varname">__FreeBSD__</code>
 and similar macros.  This hurts portability.  Please see our patching
 guidelines (<a class="xref" href="#components.patches.guidelines" title="12.3.4.�Patching guidelines">Section�12.3.4, &#8220;Patching guidelines&#8221;</a>) for more
 details.</p>
 </div>
 </div>
 <div class="chapter">
 <div class="titlepage"><div><div><h2 class="title">
 <a name="submit"></a>Chapter�23.�Submitting and Committing</h2></div></div></div>
 <div class="toc">
 <p><b>Table of Contents</b></p>
 <dl class="toc">
 <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>
 </div>
 <div class="sect1">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
 <a name="submitting-binary-packages"></a>23.1.�Submitting binary packages</h2></div></div></div>
 <p>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 <a class="xref" href="#bulk" title="Chapter�8.�Creating binary packages for everything in pkgsrc (bulk builds)">Chapter�8, <i>Creating binary packages for everything in pkgsrc (bulk
 builds)</i></a>.</p>
 </div>
 <div class="sect1">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
 <a name="submitting-your-package"></a>23.2.�Submitting source packages (for non-NetBSD-developers)</h2></div></div></div>
 <p>Firstly, you can import new packages into
 	pkgsrc-wip (<span class="quote">&#8220;<span class="quote">pkgsrc work-in-progress</span>&#8221;</span>); see the
 	homepage at <a class="ulink" href="https://pkgsrc.org/wip/" target="_top">https://pkgsrc.org/wip/</a>
 	for details.</p>
 <p>Next, check that your package is complete, compiles and
 	runs well; see <a class="xref" href="#creating" title="Chapter�14.�Creating a new pkgsrc package from scratch">Chapter�14, <i>Creating a new pkgsrc package from scratch</i></a> and the rest of this
 	document. Run the <a href="https://cdn.NetBSD.org/pub/pkgsrc/current/pkgsrc/pkgtools/pkglint/index.html" target="_top"><code class="filename">pkgtools/pkglint</code></a>
 	tool and fix any errors that appear.</p>
 <p>Finally, send a report to the pkgsrc bug tracking system,
 	either with the <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> command, or if you don't have
 	that, go to the web page
 	<a class="ulink" href="https://www.NetBSD.org/support/send-pr.html" target="_top">https://www.NetBSD.org/support/send-pr.html</a>,
 	which contains some instructions and a link to a form where you
 	can submit packages.  The
 	<a href="https://cdn.NetBSD.org/pub/pkgsrc/current/pkgsrc/sysutils/gtk-send-pr/index.html" target="_top"><code class="filename">sysutils/gtk-send-pr</code></a> package is
 	also available as a substitute for either of the above two tools.
 	</p>
 <p>In the form of the problem report, the category should be
 	<span class="quote">&#8220;<span class="quote">pkg</span>&#8221;</span>, 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).</p>
 </div>
 <div class="sect1">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
 <a name="general-notes-for-changes"></a>23.3.�General notes when adding, updating, or removing packages</h2></div></div></div>
 <p>Please note all package additions, updates, moves, and
 	removals in <code class="filename">pkgsrc/doc/CHANGES-<em class="replaceable"><code>YYYY</code></em></code>. 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 <a class="ulink" href="https://www.NetBSD.org/" target="_top">www.NetBSD.org</a> and other
 	sites. Additionally, check the
 	<code class="filename">pkgsrc/doc/TODO</code> file and remove the entry
 	for the package you updated or removed, in case it was mentioned
 	there.</p>
 <p>When the <code class="varname">PKGREVISION</code> of a package is
 	bumped, the change should appear in
 	<code class="filename">pkgsrc/doc/CHANGES-<em class="replaceable"><code>YYYY</code></em></code> 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.</p>
 <p>There is a make target that helps in creating proper
   <code class="filename">CHANGES-<em class="replaceable"><code>YYYY</code></em></code> entries:  <span class="command"><strong>make
   changes-entry</strong></span>. It uses the optional <code class="varname">CTYPE</code>
   and <code class="varname">NETBSD_LOGIN_NAME</code> variables. The general
   usage is to first make sure that your <code class="filename">CHANGES-<em class="replaceable"><code>YYYY</code></em></code>
   file is up-to-date (to avoid having to resolve conflicts later-on)
   and then to <span class="command"><strong>cd</strong></span> to the package directory.  For
   package updates, <span class="command"><strong>make changes-entry</strong></span> is enough.
   For new packages, or package moves or removals, set the
   <code class="varname">CTYPE</code> variable on the command line to "Added",
   "Moved", or "Removed".  You can set <code class="varname">NETBSD_LOGIN_NAME</code>
   in <a class="link" href="#mk.conf"><code class="filename">mk.conf</code></a> if your local login name is
   not the same as your NetBSD login name. The target also automatically
   removes possibly existing entries for the package in the
   <code class="filename">TODO</code> file. Don't forget to commit
   the changes, e.g. by using <span class="command"><strong>make commit-changes-entry</strong></span>!
   If you are not using a checkout directly from cvs.NetBSD.org, but e.g.
   a local copy of the repository, you can set USE_NETBSD_REPO=yes. This
   makes the cvs commands use the main repository.
   </p>
 </div>
 <div class="sect1">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
 <a name="commit-messages"></a>23.4.�Commit Messages</h2></div></div></div>
 <p>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:</p>
 <div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; ">
 <li class="listitem"><p>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.</p></li>
 <li class="listitem"><p>Leave the next line empty.</p></li>
 <li class="listitem"><p>Then come the details for the commit (changes in that
     package, reason for a change) and any relevant PRs. Wrap this
     section.</p></li>
 </ul></div>
 <p>Here is an example:
   </p>
 <pre class="programlisting">
   libxslt: update to 1.0.30
   Changes since 1.0.29:
   ...
   </pre>
 <p>
   </p>
 <p>Here is another example:
   </p>
 <pre class="programlisting">
   mk/bsd.pkg.mk: enable SSP by default on NetBSD
   (rationale)
   </pre>
 <p>
   </p>
 <p>Commit messages are final: no <span class="quote">&#8220;<span class="quote">cvs admin</span>&#8221;</span> is
   allowed on the pkgsrc repository to change commit messages.</p>
 </div>
 <div class="sect1">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
 <a name="committing-importing"></a>23.5.�Committing: Adding a package to CVS</h2></div></div></div>
 <p>This section is only of interest for pkgsrc developers with write
   access to the pkgsrc repository.</p>
 <p>When the package is finished, <span class="quote">&#8220;<span class="quote">cvs add</span>&#8221;</span> 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
 <code class="filename">Makefile</code>. Make sure you don't forget any files;
 you can check by running <span class="quote">&#8220;<span class="quote">cvs status</span>&#8221;</span>. An example:</p>
 <pre class="programlisting">
 <code class="prompt">$</code> cd .../pkgsrc/category
 <code class="prompt">$</code> cvs add pkgname
 <code class="prompt">$</code> cd pkgname
 <code class="prompt">$</code> cvs add DESCR Makefile PLIST distinfo buildlink3.mk patches
 <code class="prompt">$</code> cvs add patches/p*
 <code class="prompt">$</code> cvs status | less
 <code class="prompt">$</code> cvs commit
 <code class="prompt">$</code> cd ..
 <code class="prompt">$</code> vi Makefile # add SUBDIRS+=pkgname line
 <code class="prompt">$</code> cvs commit Makefile
 <code class="prompt">$</code> cd pkgname
 <code class="prompt">$</code> make CTYPE=Added commit-changes-entry
 </pre>
 <p>The commit message of the initial import should include part of the
   <code class="filename">DESCR</code> file, so people reading the mailing lists know
   what the package is/does.</p>
 <p>Also mention the new package in
 <code class="filename">pkgsrc/doc/CHANGES-20xx</code>.</p>
 <p>Previously, <span class="quote">&#8220;<span class="quote">cvs import</span>&#8221;</span> was suggested, but it was
 much easier to get wrong than <span class="quote">&#8220;<span class="quote">cvs add</span>&#8221;</span>.</p>
 </div>
 <div class="sect1">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
 <a name="updating-package"></a>23.6.�Updating a package to a newer version</h2></div></div></div>
 <p>Please always put a concise, appropriate and relevant summary of the
   changes between old and new versions into the commit log when updating
   a package. There are various reasons for this:</p>
 <div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; ">
 <li class="listitem"><p>A URL is volatile, and can change over time. It may go away completely
   or its information may be overwritten by newer information.</p></li>
 <li class="listitem"><p>Having the change information between old and new versions in our CVS
   repository is very useful for people who use either cvs or anoncvs.</p></li>
 <li class="listitem"><p>Having the change information between old and new versions in our CVS
   repository is very useful for people who read the pkgsrc-changes mailing
   list, so that they can make tactical decisions about when to upgrade
   the package.</p></li>
 </ul></div>
 <p>Please also recognize that, just because a new version of a package
   has been released, it should not automatically be upgraded in the CVS
   repository.  We prefer to be conservative in the packages that are
   included in pkgsrc - development or beta packages are not really the
   best thing for most places in which pkgsrc is used. Please use your
   judgement about what should go into pkgsrc, and bear in mind that
   stability is to be preferred above new and possibly untested features.</p>
 </div>
 <div class="sect1">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
 <a name="renaming-package"></a>23.7.�Renaming a package in pkgsrc</h2></div></div></div>
 <p>Renaming packages is not recommended.</p>
 <p>When renaming packages, be sure to fix any references to the old name
   in other Makefiles, options, buildlink files, etc.</p>
 <p>
   Also, when renaming a package, please add
   the package name and version pattern(s) of the previous package
   to <code class="varname">SUPERSEDES</code>.
   This may be repeated for multiple renames.
   The new package would be an exact replacement.
   Example:
 </p>
 <pre class="programlisting">
 SUPERSEDES+=    p5-IO-Compress-Zlib&lt;2.017
 SUPERSEDES+=    optcomp-[0-9]*
 </pre>
 <p>Note that <span class="quote">&#8220;<span class="quote">successor</span>&#8221;</span> in the
   CHANGES-<em class="replaceable"><code>YYYY</code></em> file doesn't necessarily
   mean that it <span class="emphasis"><em>supersedes</em></span>, as that successor may
   not be an exact replacement but is a suggestion for the replaced
   functionality.</p>
 </div>
 <div class="sect1">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
 <a name="moving-package"></a>23.8.�Moving a package in pkgsrc</h2></div></div></div>
 <p>It is preferred that packages are not renamed or moved, but if needed
   please follow these steps.
 </p>
 <div class="orderedlist"><ol class="orderedlist" type="1">
 <li class="listitem"><p>Make a copy of the directory somewhere else.</p></li>
 <li class="listitem">
 <p>Remove all CVS dirs.</p>
 <p>Alternatively to the first two steps you can also do:</p>
 @@ -10803,4112 +10825,3976 @@ 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>CHANGES</td>
 </tr>
 <tr>
 <td>CHECKOUT_DATE</td>
 <td>CHECK_COMPILER</td>
 </tr>
 <tr>
 <td>CHECK_FAKEHOME</td>
 <td>CHECK_FILES</td>
 </tr>
 <tr>
 <td>CHECK_FILES</td>
 <td>CHECK_FILES_SKIP</td>
 <td>CHECK_FILES_STRICT</td>
 </tr>
 <tr>
 <td>CHECK_FILES_STRICT</td>
 <td>CHECK_HEADERS</td>
 <td>CHECK_HEADERS_SKIP</td>
 </tr>
 <tr>
 <td>CHECK_HEADERS_SKIP</td>
 <td>CHECK_INTERPRETER</td>
 <td>CHECK_INTERPRETER_SKIP</td>
 </tr>
 <tr>
 <td>CHECK_INTERPRETER_SKIP</td>
 <td>CHECK_PERMS</td>
 <td>CHECK_PERMS_AUTOFIX</td>
 </tr>
 <tr>
 <td>CHECK_PERMS_AUTOFIX</td>
 <td>CHECK_PERMS_SKIP</td>
 <td>CHECK_PIE</td>
 </tr>
 <tr>
 <td>CHECK_PIE</td>
 <td>CHECK_PIE_SKIP</td>
 <td>CHECK_PIE_SUPPORTED</td>
 </tr>
 <tr>
 <td>CHECK_PIE_SUPPORTED</td>
 <td>CHECK_PORTABILITY</td>
 <td>CHECK_PORTABILITY_EXPERIMENTAL</td>
 </tr>
 <tr>
 <td>CHECK_PORTABILITY_EXPERIMENTAL</td>
 <td>CHECK_PORTABILITY_SKIP</td>
 <td>CHECK_RELRO</td>
 </tr>
 <tr>
 <td>CHECK_RELRO</td>
 <td>CHECK_RELRO_SKIP</td>
 <td>CHECK_RELRO_SUPPORTED</td>
 </tr>
 <tr>
 <td>CHECK_RELRO_SUPPORTED</td>
 <td>CHECK_SHLIBS</td>
 <td>CHECK_SHLIBS_SKIP</td>
 </tr>
 <tr>
 <td>CHECK_SHLIBS_SKIP</td>
 <td>CHECK_SHLIBS_SUPPORTED</td>
 <td>CHECK_SHLIBS_TOXIC</td>
 </tr>
 <tr>
 <td>CHECK_SHLIBS_TOXIC</td>
 <td>CHECK_SSP</td>
 <td>CHECK_SSP_SKIP</td>
 </tr>
 <tr>
 <td>CHECK_SSP_SKIP</td>
 <td>CHECK_SSP_SUPPORTED</td>
 <td>CHECK_STRIPPED</td>
 </tr>
 <tr>
 <td>CHECK_STRIPPED</td>
 <td>CHECK_STRIPPED_SKIP</td>
 <td>CHECK_WRKREF</td>
 </tr>
 <tr>
 <td>CHECK_WRKREF</td>
 <td>CHECK_WRKREF_EXTRA_DIRS</td>
 <td>CHECK_WRKREF_SKIP</td>
 </tr>
 <tr>
 <td>CHECK_WRKREF_SKIP</td>
 <td>CLAMAV_DBDIR</td>
 <td>CLAMAV_GROUP</td>
 </tr>
 <tr>
 <td>CLAMAV_GROUP</td>
 <td>CLAMAV_USER</td>
 <td>CLANGBASE</td>
 </tr>
 <tr>
 <td>CLANGBASE</td>
 <td>CLEANDEPENDS</td>
 <td>CMAKE_DEPENDENCIES_REWRITE</td>
 </tr>
 <tr>
 <td>CMAKE_DEPENDENCIES_REWRITE</td>
 <td>CMAKE_INSTALL_NAME_DIR</td>
 <td>CMAKE_INSTALL_PREFIX</td>
 </tr>
 <tr>
 <td>CMAKE_INSTALL_PREFIX</td>
 <td>CMAKE_MODULE_PATH_OVERRIDE</td>
 <td>CMAKE_PKGSRC_BUILD_FLAGS</td>
 </tr>
 <tr>
 <td>CMAKE_PKGSRC_BUILD_FLAGS</td>
 <td>CMAKE_PREFIX_PATH</td>
 <td>CMAKE_USE_GNU_INSTALL_DIRS</td>
 </tr>
 <tr>
-<td>COMMON_LISP_DOCFILES</td>
+<td>CMAKE_USE_GNU_INSTALL_DIRS</td>
 <td>COMMON_LISP_EXAMPLES</td>
 </tr>
 <tr>
 <td>COMMON_LISP_EXTRAFILES</td>
 <td>COMMON_LISP_PACKAGES</td>
 </tr>
 <tr>
 <td>COMMON_LISP_SYSTEM</td>
 <td>COMPILER_RPATH_FLAG</td>
 </tr>
 <tr>
 <td>COMPILER_USE_SYMLINKS</td>
 <td>CONFIGURE_ARGS</td>
 </tr>
 <tr>
 <td>CONFIGURE_DIRS</td>
 <td>CONFIGURE_ENV</td>
 </tr>
 <tr>
 <td>CONFIGURE_ENV_SHELL</td>
 <td>CONFIGURE_HAS_INFODIR</td>
 </tr>
 <tr>
 <td>CONFIGURE_HAS_MANDIR</td>
 <td>CONFIGURE_SCRIPT</td>
 </tr>
 <tr>
 <td>CONFIG_SHELL</td>
 <td>CONFIG_SHELL_FLAGS</td>
 </tr>
 <tr>
 <td>CONF_FILES</td>
 <td>CONF_FILES_MODE</td>
 </tr>
 <tr>
 <td>CONF_FILES_PERMS</td>
 <td>CONSERVER_DEFAULTHOST</td>
 </tr>
 <tr>
 <td>CONSERVER_DEFAULTPORT</td>
 <td>CP</td>
 </tr>
 <tr>
 <td>CPP</td>
 <td>CPP_PRECOMP_FLAGS</td>
 </tr>
 <tr>
 <td>CREATE_WRKDIR_SYMLINK</td>
 <td>CROSSBASE</td>
 </tr>
 <tr>
 <td>CTFCONVERT</td>
 <td>CTF_FILES_SKIP</td>
 </tr>
 <tr>
 <td>CTF_SUPPORTED</td>
 <td>CTYPE</td>
 </tr>
 <tr>
 <td>CUPS_GROUP</td>
 <td>CUPS_SYSTEM_GROUPS</td>
 </tr>
 <tr>
 <td>CUPS_USER</td>
 <td>CURSES_DEFAULT</td>
 </tr>
 <tr>
 <td>CURSES_TYPE</td>
 <td>CVS_EXTRACTDIR</td>
 </tr>
 <tr>
 <td>CVS_MODULE</td>
 <td>CVS_PROJECT</td>
 </tr>
 <tr>
 <td>CVS_REPOSITORIES</td>
 <td>CVS_ROOT</td>
 </tr>
 <tr>
 <td>CVS_ROOT_GNU</td>
 <td>CVS_ROOT_NONGNU</td>
 </tr>
 <tr>
 <td>CVS_ROOT_SOURCEFORGE</td>
 <td>CVS_TAG</td>
 </tr>
 <tr>
 <td>CXX</td>
 <td>CYRUS_GROUP</td>
 </tr>
 <tr>
 <td>CYRUS_GROUP</td>
 <td>CYRUS_IDLE</td>
 <td>CYRUS_USER</td>
 </tr>
 <tr>
 <td>CYRUS_USER</td>
 <td>DAEMONTOOLS_GROUP</td>
 <td>DAEMONTOOLS_LOG_USER</td>
 </tr>
 <tr>
 <td>DAEMONTOOLS_LOG_USER</td>
 <td>DARWIN_NO_SYSTEM_LIBS</td>
 <td>DARWIN_REQUIRES_FILTER</td>
 </tr>
 <tr>
 <td>DARWIN_REQUIRES_FILTER</td>
 <td>DBUS_GROUP</td>
 <td>DBUS_USER</td>
 </tr>
 <tr>
 <td>DBUS_USER</td>
 <td>DEFANG_GROUP</td>
 <td>DEFANG_USER</td>
 </tr>
 <tr>
 <td>DEFANG_USER</td>
 <td>DEFAULT_ACCEPTABLE_LICENSES</td>
 <td>DEFAULT_DISTFILES</td>
 </tr>
 <tr>
 <td>DEFAULT_DISTFILES</td>
 <td>DEFAULT_IRC_SERVER</td>
 <td>DEFAULT_SERIAL_DEVICE</td>
 </tr>
 <tr>
 <td>DEFAULT_SERIAL_DEVICE</td>
 <td>DEF_UMASK</td>
 <td>DEINSTALLDEPENDS</td>
 </tr>
 <tr>
 <td>DEINSTALLDEPENDS</td>
 <td>DEINSTALL_SRC</td>
 <td>DEINSTALL_TEMPLATES</td>
 </tr>
 <tr>
 <td>DEINSTALL_TEMPLATES</td>
 <td>DELAYED_ERROR_MSG</td>
 <td>DELAYED_WARNING_MSG</td>
 </tr>
 <tr>
 <td>DELAYED_WARNING_MSG</td>
 <td>DEPENDS</td>
 <td>DEPENDS_TARGET</td>
 </tr>
 <tr>
 <td>DEPENDS_TARGET</td>
 <td>DEPENDS_TYPE</td>
 <td>DESTDIR</td>
 </tr>
 <tr>
 <td>DESTDIR</td>
 <td>DESTDIR_VARNAME</td>
 <td>DIALER_GROUP</td>
 </tr>
 <tr>
 <td>DIALER_GROUP</td>
 <td>DIGEST_REQD</td>
 <td>DISTDIR</td>
 </tr>
 <tr>
 <td>DISTDIR</td>
 <td>DISTFILES</td>
 <td>DISTINFO_FILE</td>
 </tr>
 <tr>
 <td>DISTINFO_FILE</td>
 <td>DISTNAME</td>
 <td>DIST_PATH</td>
 </tr>
 <tr>
 <td>DIST_PATH</td>
 <td>DIST_SUBDIR</td>
 <td>DJBDNS_AXFR_USER</td>
 </tr>
 <tr>
 <td>DJBDNS_AXFR_USER</td>
 <td>DJBDNS_CACHE_USER</td>
 <td>DJBDNS_DJBDNS_GROUP</td>
 </tr>
 <tr>
 <td>DJBDNS_DJBDNS_GROUP</td>
 <td>DJBDNS_LOG_USER</td>
 <td>DJBDNS_RBL_USER</td>
 </tr>
 <tr>
 <td>DJBDNS_RBL_USER</td>
 <td>DJBDNS_TINY_USER</td>
 <td>DLOPEN_REQUIRE_PTHREADS</td>
 </tr>
 <tr>
 <td>DLOPEN_REQUIRE_PTHREADS</td>
 <td>DL_AUTO_VARS</td>
 <td>DL_CFLAGS</td>
 </tr>
 <tr>
 <td>DL_CFLAGS</td>
 <td>DL_LDFLAGS</td>
 <td>DL_LIBS</td>
 </tr>
 <tr>
 <td>DL_LIBS</td>
 <td>DNS</td>
 <td>DOCOWN</td>
 </tr>
 <tr>
 <td>DOCOWN</td>
 <td>DOWNLOADED_DISTFILE</td>
 <td>DQCACHE_GROUP</td>
 </tr>
 <tr>
 <td>DQCACHE_GROUP</td>
 <td>DQCACHE_USER</td>
 <td>DT_LAYOUT</td>
 </tr>
 <tr>
 <td>DT_LAYOUT</td>
 <td>DYNAMIC_SITES_CMD</td>
 <td>DYNAMIC_SITES_SCRIPT</td>
 </tr>
 <tr>
 <td>DYNAMIC_SITES_SCRIPT</td>
 <td>ECHO</td>
 <td>ECHO_N</td>
 </tr>
 <tr>
 <td>ECHO_N</td>
 <td>ELK_GUI</td>
 <td>EMACS_TYPE</td>
 </tr>
 <tr>
 <td>EMACS_TYPE</td>
 <td>EMULDIR</td>
 <td>EMULSUBDIR</td>
 </tr>
 <tr>
 <td>EMULSUBDIR</td>
 <td>EMULSUBDIRSLASH</td>
 <td>EMUL_ARCH</td>
 </tr>
 <tr>
 <td>EMUL_ARCH</td>
 <td>EMUL_DISTRO</td>
 <td>EMUL_EXEC_FMT</td>
 </tr>
 <tr>
 <td>EMUL_EXEC_FMT</td>
 <td>EMUL_IS_NATIVE</td>
 <td>EMUL_MODULES</td>
 </tr>
 <tr>
 <td>EMUL_MODULES</td>
 <td>EMUL_OPSYS</td>
 <td>EMUL_PKG_FMT</td>
 </tr>
 <tr>
 <td>EMUL_PKG_FMT</td>
 <td>EMUL_PLATFORM</td>
 <td>EMUL_PLATFORMS</td>
 </tr>
 <tr>
 <td>EMUL_PLATFORMS</td>
 <td>EMUL_PREFER</td>
 <td>EMUL_REQD</td>
 </tr>
 <tr>
 <td>EMUL_REQD</td>
 <td>EMUL_TYPE</td>
 <td>ERROR_MSG</td>
 </tr>
 <tr>
 <td>ERROR_MSG</td>
 <td>EXIM_GROUP</td>
 <td>EXIM_USER</td>
 </tr>
 <tr>
 <td>EXIM_USER</td>
 <td>EXPORT_SYMBOLS_LDFLAGS</td>
 <td>EXTRACTOR</td>
 </tr>
 <tr>
 <td>EXTRACTOR</td>
 <td>EXTRACT_CMD</td>
 <td>EXTRACT_CMD_DEFAULT</td>
 </tr>
 <tr>
 <td>EXTRACT_CMD_DEFAULT</td>
 <td>EXTRACT_DIR</td>
 <td>EXTRACT_ELEMENTS</td>
 </tr>
 <tr>
 <td>EXTRACT_ELEMENTS</td>
 <td>EXTRACT_ENV</td>
 <td>EXTRACT_ONLY</td>
 </tr>
 <tr>
 <td>EXTRACT_ONLY</td>
 <td>EXTRACT_OPTS</td>
 <td>EXTRACT_SUFX</td>
 </tr>
 <tr>
 <td>EXTRACT_SUFX</td>
 <td>EXTRACT_USING</td>
 <td>FAIL</td>
 </tr>
 <tr>
 <td>FAIL</td>
 <td>FAILOVER_FETCH</td>
 <td>FAIL_MSG</td>
 </tr>
 <tr>
 <td>FAIL_MSG</td>
 <td>FAKE_NCURSES</td>
 <td>FAM</td>
 </tr>
 <tr>
 <td>FAM</td>
 <td>FAM_ACCEPTED</td>
 <td>FAM_DEFAULT</td>
 </tr>
 <tr>
 <td>FAM_DEFAULT</td>
 <td>FAM_SERVER</td>
 <td>FCPATH</td>
 </tr>
 <tr>
 <td>FCPATH</td>
 <td>FEATURE_CPPFLAGS</td>
 <td>FEATURE_LDFLAGS</td>
 </tr>
 <tr>
 <td>FEATURE_LDFLAGS</td>
 <td>FEATURE_LIBS</td>
 <td>FETCH_AFTER_ARGS</td>
 </tr>
 <tr>
 <td>FETCH_AFTER_ARGS</td>
 <td>FETCH_BEFORE_ARGS</td>
 <td>FETCH_CMD</td>
 </tr>
 <tr>
 <td>FETCH_CMD</td>
 <td>FETCH_OUTPUT_ARGS</td>
 <td>FETCH_PROXY</td>
 </tr>
 <tr>
 <td>FETCH_PROXY</td>
 <td>FETCH_RESUME_ARGS</td>
 <td>FETCH_TIMEOUT</td>
 </tr>
 <tr>
 <td>FETCH_TIMEOUT</td>
 <td>FETCH_USE_IPV4_ONLY</td>
 <td>FETCH_USING</td>
 </tr>
 <tr>
 <td>FETCH_USING</td>
 <td>FILES_SUBST</td>
 <td>FILES_SUBST_SED</td>
 </tr>
 <tr>
 <td>FILES_SUBST_SED</td>
 <td>FIX_SYSTEM_HEADERS</td>
 <td>FONTDIR</td>
 </tr>
 <tr>
 <td>FONTS_DIRS</td>
 <td>FONTS_VERBOSE</td>
 </tr>
 <tr>
 <td>FOO_HACKS_MK</td>
 <td>FOSSIL_EXTRACTDIR</td>
 </tr>
 <tr>
 <td>FOSSIL_REPO</td>
 <td>FOSSIL_REPOSITORIES</td>
 </tr>
 <tr>
 <td>FOSSIL_VERSION</td>
 <td>FOX_USE_XUNICODE</td>
 </tr>
 <tr>
 <td>FREEWNN_GROUP</td>
 <td>FREEWNN_USER</td>
 </tr>
 <tr>
 <td>FTP_PKG_URL_DIR</td>
 <td>FTP_PKG_URL_HOST</td>
 </tr>
 <tr>
 <td>GAMEDATAMODE</td>
 <td>GAMEDATA_PERMS</td>
 </tr>
 <tr>
 <td>GAMEDIRMODE</td>
 <td>GAMEDIR_PERMS</td>
 </tr>
 <tr>
 <td>GAMEGRP</td>
 <td>GAMEMODE</td>
 </tr>
 <tr>
 <td>GAMEOWN</td>
 <td>GAMES_GROUP</td>
 </tr>
 <tr>
 <td>GAMES_USER</td>
 <td>GCC</td>
 </tr>
 <tr>
 <td>GCCBASE</td>
 <td>GCC_REQD</td>
 </tr>
 <tr>
 <td>GCC_VERSION_SUFFIX</td>
 <td>GEM_BUILD</td>
 </tr>
 <tr>
 <td>GEM_CLEANBUILD</td>
 <td>GEM_CLEANBUILD_EXTENSIONS</td>
 </tr>
 <tr>
 <td>GEM_DOCDIR</td>
 <td>GEM_EXTSDIR</td>
 </tr>
 <tr>
 <td>GEM_HOME</td>
 <td>GEM_KEEPBUILD</td>
 </tr>
 <tr>
 <td>GEM_LIBDIR</td>
 <td>GEM_NAME</td>
 </tr>
 <tr>
 <td>GEM_PATH</td>
 <td>GEM_PLUGINSDIR</td>
 </tr>
 <tr>
 <td>GEM_SPECFILE</td>
 <td>GENERATE_PLIST</td>
 </tr>
 <tr>
 <td>GHC</td>
 <td>GHOSTSCRIPT_REQD</td>
 </tr>
 <tr>
 <td>GITHUB_PROJECT</td>
 <td>GITHUB_RELEASE</td>
 </tr>
 <tr>
 <td>GITHUB_SUBMODULES</td>
 <td>GITHUB_TAG</td>
 </tr>
 <tr>
 <td>GITHUB_TYPE</td>
 <td>GITLAB_PROJECT</td>
 </tr>
 <tr>
 <td>GITLAB_RELEASE</td>
 <td>GITLAB_SUBMODULES</td>
 </tr>
 <tr>
 <td>GITLAB_TAG</td>
 <td>GITLAB_TYPE</td>
 </tr>
 <tr>
 <td>GIT_BRANCH</td>
 <td>GIT_ENV</td>
 </tr>
 <tr>
 <td>GIT_EXTRACTDIR</td>
 <td>GIT_REPO</td>
 </tr>
 <tr>
 <td>GIT_REPOSITORIES</td>
 <td>GIT_REVISION</td>
 </tr>
 <tr>
 <td>GIT_TAG</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>
 </tr>
 <tr>
 <td>HASKELL_COMPILER</td>
 <td>HASKELL_ENABLE_DYNAMIC_EXECUTABLE</td>
 </tr>
 <tr>
 <td>HASKELL_ENABLE_HADDOCK_DOCUMENTATION</td>
 <td>HASKELL_ENABLE_LIBRARY_PROFILING</td>
 </tr>
 <tr>
 <td>HASKELL_ENABLE_SHARED_LIBRARY</td>
 <td>HASKELL_OPTIMIZATION_LEVEL</td>
 </tr>
 <tr>
 <td>HAS_CONFIGURE</td>
 <td>HEADER_TEMPLATES</td>
 </tr>
 <tr>
 <td>HG_REPO</td>
 <td>HG_REPOSITORIES</td>
 </tr>
 <tr>
 <td>HG_TAG</td>
 <td>HOMEPAGE</td>
 </tr>
 <tr>
 <td>HOST_PKGTOOLS_ARGS</td>
 <td>HOST_SPECIFIC_PKGS</td>
 </tr>
 <tr>
 <td>HOST_SPECIFIC_PKGS</td>
 <td>HOWL_GROUP</td>
 <td>HOWL_USER</td>
 </tr>
 <tr>
 <td>HOWL_USER</td>
 <td>ICCBASE</td>
 <td>ICECAST_CHROOTDIR</td>
 </tr>
 <tr>
 <td>ICECAST_CHROOTDIR</td>
 <td>ICON_THEMES</td>
 <td>IDOBASE</td>
 </tr>
 <tr>
 <td>IDOBASE</td>
 <td>IGNORE_CCACHE</td>
 <td>IGNORE_INFO_DIRS</td>
 </tr>
 <tr>
 <td>IGNORE_INFO_DIRS</td>
 <td>IGNORE_INTERACTIVE_FETCH</td>
 <td>IMAKE</td>
 </tr>
 <tr>
 <td>IMAKE</td>
 <td>IMAKEOPTS</td>
 <td>IMAKE_MAKE</td>
 </tr>
 <tr>
 <td>IMAKE_MAKE</td>
 <td>IMAKE_MANINSTALL</td>
 <td>IMAP_UW_CCLIENT_MBOX_FMT</td>
 </tr>
 <tr>
 <td>IMAP_UW_CCLIENT_MBOX_FMT</td>
 <td>IMDICTDIR</td>
 <td>INCOMPAT_CURSES</td>
 </tr>
 <tr>
 <td>INCOMPAT_CURSES</td>
 <td>INFO_DIR</td>
 <td>INFO_FILES</td>
 </tr>
 <tr>
 <td>INFO_FILES</td>
 <td>INFO_FILES_VERBOSE</td>
 <td>INFO_MSG</td>
 </tr>
 <tr>
 <td>INFO_MSG</td>
 <td>INIT_SYSTEM</td>
 <td>INN_DATA_DIR</td>
 </tr>
 <tr>
 <td>INN_DATA_DIR</td>
 <td>INN_GROUP</td>
 <td>INN_USER</td>
 </tr>
 <tr>
 <td>INN_USER</td>
 <td>INSTALLATION_DIRS</td>
 <td>INSTALLATION_DIRS_FROM_PLIST</td>
 </tr>
 <tr>
 <td>INSTALLATION_DIRS_FROM_PLIST</td>
 <td>INSTALL_ENV</td>
 <td>INSTALL_SH_OVERRIDE</td>
 </tr>
 <tr>
 <td>INSTALL_SH_OVERRIDE</td>
 <td>INSTALL_SRC</td>
 <td>INSTALL_TEMPLATES</td>
 </tr>
 <tr>
 <td>INSTALL_TEMPLATES</td>
 <td>INSTALL_UNSTRIPPED</td>
 <td>IRCD_HYBRID_IRC_GROUP</td>
 </tr>
 <tr>
 <td>IRCD_HYBRID_IRC_GROUP</td>
 <td>IRCD_HYBRID_IRC_USER</td>
 <td>IRCD_HYBRID_MAXCONN</td>
 </tr>
 <tr>
 <td>IRCD_HYBRID_MAXCONN</td>
 <td>IRCD_HYBRID_NICLEN</td>
 <td>IRCD_HYBRID_SYSLOG_EVENTS</td>
 </tr>
 <tr>
 <td>IRCD_HYBRID_SYSLOG_EVENTS</td>
 <td>IRCD_HYBRID_SYSLOG_FACILITY</td>
 <td>IRCD_HYBRID_TOPICLEN</td>
 </tr>
 <tr>
 <td>IRCD_HYBRID_TOPICLEN</td>
 <td>IRIX</td>
 <td>IRRD_USE_PGP</td>
 </tr>
 <tr>
 <td>IRRD_USE_PGP</td>
 <td>JABBERD_GROUP</td>
 <td>JABBERD_LOGDIR</td>
 </tr>
 <tr>
 <td>JABBERD_LOGDIR</td>
 <td>JABBERD_PIDDIR</td>
 <td>JABBERD_SPOOLDIR</td>
 </tr>
 <tr>
 <td>JABBERD_SPOOLDIR</td>
 <td>JABBERD_USER</td>
 <td>JAVA_APP_PATH</td>
 </tr>
 <tr>
 <td>JAVA_APP_TARGETS</td>
 <td>JAVA_BINPREFIX</td>
 </tr>
 <tr>
 <td>JAVA_CLASSPATH</td>
 <td>JAVA_HOME</td>
 </tr>
 <tr>
 <td>JAVA_HOME</td>
 <td>JAVA_LD_LIBRARY_PATH</td>
 <td>JAVA_NAME</td>
 </tr>
 <tr>
 <td>JAVA_NAME</td>
 <td>JAVA_UNLIMIT</td>
 <td>JAVA_WRAPPERS</td>
 </tr>
 <tr>
 <td>JAVA_WRAPPERS</td>
 <td>JPEG_ACCEPTED</td>
 <td>JPEG_DEFAULT</td>
 </tr>
 <tr>
 <td>JPEG_DEFAULT</td>
 <td>KERBEROS</td>
 <td>KERMIT_SUID_UUCP</td>
 </tr>
 <tr>
 <td>KERMIT_SUID_UUCP</td>
 <td>KJS_USE_PCRE</td>
 <td>KNEWS_DOMAIN_FILE</td>
 </tr>
 <tr>
 <td>KNEWS_DOMAIN_FILE</td>
 <td>KNEWS_DOMAIN_NAME</td>
 <td>KRB5_ACCEPTED</td>
 </tr>
 <tr>
 <td>KRB5_ACCEPTED</td>
 <td>KRB5_DEFAULT</td>
 <td>LANGUAGES</td>
 </tr>
 <tr>
 <td>LANGUAGES</td>
 <td>LAPACKE_LIBS</td>
 <td>LAPACK_LIBS</td>
 </tr>
 <tr>
 <td>LAPACK_LIBS</td>
 <td>LATEX2HTML_ICONPATH</td>
 <td>LDCONFIG_ADD_CMD</td>
 </tr>
 <tr>
 <td>LDCONFIG_ADD_CMD</td>
 <td>LDCONFIG_REMOVE_CMD</td>
 <td>LDD</td>
 </tr>
 <tr>
 <td>LDD</td>
 <td>LEAFNODE_DATA_DIR</td>
 <td>LEAFNODE_GROUP</td>
 </tr>
 <tr>
 <td>LEAFNODE_GROUP</td>
 <td>LEAFNODE_USER</td>
 <td>LIBDVDCSS_HOMEPAGE</td>
 </tr>
 <tr>
 <td>LIBDVDCSS_HOMEPAGE</td>
 <td>LIBDVDCSS_MASTER_SITES</td>
 <td>LIBRSVG_TYPE</td>
 </tr>
 <tr>
 <td>LIBRSVG_TYPE</td>
 <td>LIBTOOL</td>
 <td>LIBTOOLIZE_PLIST</td>
 </tr>
 <tr>
 <td>LIBTOOLIZE_PLIST</td>
 <td>LIBTOOL_M4_OVERRIDE</td>
 <td>LIBUSB_TYPE</td>
 </tr>
 <tr>
 <td>LIBUSB_TYPE</td>
 <td>LICENSE</td>
 <td>LINKER_RPATH_FLAG</td>
 </tr>
 <tr>
 <td>LINKER_RPATH_FLAG</td>
 <td>LINK_RPATH_FLAG</td>
 <td>LINUX_BASE_NODEPS</td>
 </tr>
 <tr>
 <td>LINUX_BASE_PREFERRED</td>
 <td>LINUX_BASE_REQUIRED</td>
 </tr>
 <tr>
 <td>LINUX_LOCALES</td>
 <td>LOCALBASE</td>
 </tr>
 <tr>
 <td>LOCALBASE_LOCKTYPE</td>
 <td>LOCALPATCHES</td>
 </tr>
 <tr>
 <td>LOVE_DATA</td>
 <td>LOVE_GAME</td>
 </tr>
 <tr>
 <td>LOVE_VERSION</td>
 <td>LP32PLATFORMS</td>
 </tr>
 <tr>
 <td>LP64PLATFORMS</td>
 <td>LUA_BUSTED_ARGS</td>
 </tr>
 <tr>
 <td>LUA_CDIR</td>
 <td>LUA_COMPILER</td>
 </tr>
 <tr>
 <td>LUA_DOCDIR</td>
 <td>LUA_EXAMPLESDIR</td>
 </tr>
 <tr>
 <td>LUA_INCDIR</td>
 <td>LUA_INTERPRETER</td>
 </tr>
 <tr>
 <td>LUA_LDIR</td>
 <td>LUA_LINKER_MAGIC</td>
 </tr>
 <tr>
 <td>LUA_PKGPREFIX</td>
 <td>LUA_SELF_CONFLICT</td>
 </tr>
 <tr>
 <td>LUA_USE_BUSTED</td>
 <td>LUA_VERSIONS_ACCEPTED</td>
 </tr>
 <tr>
 <td>LUA_VERSIONS_INCOMPATIBLE</td>
 <td>LUA_VERSION_DEFAULT</td>
 </tr>
 <tr>
 <td>LUA_VERSION_REQD</td>
 <td>Lua</td>
 </tr>
 <tr>
 <td>MACHINE_PLATFORM</td>
 <td>MAILAGENT_DOMAIN</td>
 </tr>
 <tr>
 <td>MAILAGENT_EMAIL</td>
 <td>MAILAGENT_FQDN</td>
 </tr>
 <tr>
 <td>MAILAGENT_ORGANIZATION</td>
 <td>MAJORDOMO_HOMEDIR</td>
 </tr>
 <tr>
 <td>MAJOR_OS_VERSION</td>
 <td>MAKEINFO_ARGS</td>
 </tr>
 <tr>
 <td>MAKE_DIRS</td>
 <td>MAKE_DIRS_PERMS</td>
 </tr>
 <tr>
 <td>MAKE_DIRS_PERMS</td>
 <td>MAKE_ENV</td>
 <td>MAKE_FILE</td>
 </tr>
 <tr>
 <td>MAKE_FILE</td>
 <td>MAKE_FLAGS</td>
 <td>MAKE_JOBS</td>
 </tr>
 <tr>
 <td>MAKE_JOBS</td>
 <td>MAKE_JOBS_SAFE</td>
 <td>MAKE_PROGRAM</td>
 </tr>
 <tr>
 <td>MAKE_PROGRAM</td>
 <td>MANCOMPRESSED_IF_MANZ</td>
 <td>MANINSTALL</td>
 </tr>
 <tr>
 <td>MANINSTALL</td>
 <td>MANZ</td>
 <td>MASTER_SITES</td>
 </tr>
 <tr>
 <td>MASTER_SITES</td>
 <td>MASTER_SITE_BACKUP</td>
 <td>MASTER_SITE_LOCAL</td>
 </tr>
 <tr>
 <td>MASTER_SITE_LOCAL</td>
 <td>MASTER_SITE_MOZILLA</td>
 <td>MASTER_SITE_OVERRIDE</td>
 </tr>
 <tr>
 <td>MASTER_SITE_OVERRIDE</td>
 <td>MASTER_SITE_PERL_CPAN</td>
 <td>MASTER_SORT</td>
 </tr>
 <tr>
 <td>MASTER_SORT</td>
 <td>MASTER_SORT_RANDOM</td>
 <td>MASTER_SORT_REGEX</td>
 </tr>
 <tr>
 <td>MASTER_SORT_REGEX</td>
 <td>MECAB_CHARSET</td>
 <td>MEDIATOMB_GROUP</td>
 </tr>
 <tr>
 <td>MEDIATOMB_GROUP</td>
 <td>MEDIATOMB_USER</td>
 <td>MIPSPROBASE</td>
 </tr>
 <tr>
 <td>MIPSPROBASE</td>
 <td>MIREDO_GROUP</td>
 <td>MIREDO_USER</td>
 </tr>
 <tr>
 <td>MIREDO_USER</td>
 <td>MISSING_FEATURES</td>
 <td>MKDIR</td>
 </tr>
 <tr>
 <td>MKDIR</td>
 <td>MKPIE_SUPPORTED</td>
 <td>MLDONKEY_GROUP</td>
 </tr>
 <tr>
 <td>MLDONKEY_GROUP</td>
 <td>MLDONKEY_HOME</td>
 <td>MLDONKEY_USER</td>
 </tr>
 <tr>
 <td>MLDONKEY_USER</td>
 <td>MONOTONE_GROUP</td>
 <td>MONOTONE_USER</td>
 </tr>
 <tr>
 <td>MONOTONE_USER</td>
 <td>MOTIFBASE</td>
 <td>MOTIF_TYPE</td>
 </tr>
 <tr>
 <td>MOTIF_TYPE</td>
 <td>MOTIF_TYPE_DEFAULT</td>
 <td>MPI_TYPE</td>
 </tr>
 <tr>
 <td>MPI_TYPE</td>
 <td>MSGFMT_STRIP_MSGCTXT</td>
 <td>MSGFMT_STRIP_MSGID_PLURAL</td>
 </tr>
 <tr>
 <td>MSGFMT_STRIP_MSGID_PLURAL</td>
 <td>MTOOLS_ENABLE_FLOPPYD</td>
 <td>MUST</td>
 </tr>
 <tr>
 <td>MV</td>
 <td>MYSQL_CHARSET</td>
 </tr>
 <tr>
 <td>MYSQL_DATADIR</td>
 <td>MYSQL_EXTRA_CHARSET</td>
 </tr>
 <tr>
 <td>MYSQL_GROUP</td>
 <td>MYSQL_USER</td>
 </tr>
 <tr>
 <td>MYSQL_VERSION</td>
 <td>MYSQL_VERSIONS_ACCEPTED</td>
 </tr>
 <tr>
 <td>MYSQL_VERSIONS_ALL</td>
 <td>MYSQL_VERSION_DEFAULT</td>
 </tr>
 <tr>
 <td>NAGIOSCMD_GROUP</td>
 <td>NAGIOSDIR</td>
 </tr>
 <tr>
 <td>NAGIOS_GROUP</td>
 <td>NAGIOS_USER</td>
 </tr>
 <tr>
 <td>NATIVE_APPEND_ABI</td>
 <td>NATIVE_APPEND_ELF</td>
 </tr>
 <tr>
 <td>NATIVE_EXEC_FMT</td>
 <td>NATIVE_MACHINE_PLATFORM</td>
 </tr>
 <tr>
 <td>NATIVE_OBJECT_FMT</td>
 <td>NBPAX_PROGRAM_PREFIX</td>
 </tr>
 <tr>
 <td>NETBSD_LOGIN_NAME</td>
 <td>NMH_EDITOR</td>
 </tr>
 <tr>
 <td>NMH_MTA</td>
 <td>NMH_PAGER</td>
 </tr>
 <tr>
 <td>NODE_VERSIONS_ACCEPTED</td>
 <td>NODE_VERSIONS_INCOMPATIBLE</td>
 </tr>
 <tr>
 <td>NODE_VERSION_DEFAULT</td>
 <td>NODE_VERSION_REQD</td>
 </tr>
 <tr>
 <td>NOLOGIN</td>
 <td>NOTE</td>
 </tr>
 <tr>
 <td>NOT_FOR_PLATFORM</td>
 <td>NOT_PAX_ASLR_SAFE</td>
 </tr>
 <tr>
 <td>NOT_PAX_MPROTECT_SAFE</td>
 <td>NO_BUILD</td>
 </tr>
 <tr>
 <td>NO_CHECKSUM</td>
 <td>NO_CONFIGURE</td>
 </tr>
 <tr>
 <td>NO_SKIP</td>
 <td>NS_PREFERRED</td>
 </tr>
 <tr>
 <td>NULLMAILER_GROUP</td>
 <td>NULLMAILER_USER</td>
 </tr>
 <tr>
 <td>OASIS</td>
 <td>OASIS_BUILD_ARGS</td>
 </tr>
 <tr>
 <td>OBJHOSTNAME</td>
 <td>OBJMACHINE</td>
 </tr>
 <tr>
 <td>OCAML_FINDLIB_DIRS</td>
 <td>OCAML_FINDLIB_REGISTER</td>
 </tr>
 <tr>
 <td>OCAML_FINDLIB_REGISTER_VERBOSE</td>
 <td>OCAML_SITELIBDIR</td>
 </tr>
 <tr>
 <td>OCAML_TOPKG_DOCDIR</td>
 <td>OCAML_USE_DUNE</td>
 </tr>
 <tr>
 <td>OCAML_USE_FINDLIB</td>
 <td>OCAML_USE_OASIS</td>
 </tr>
 <tr>
 <td>OCAML_USE_OASIS_DYNRUN</td>
 <td>OCAML_USE_OPAM</td>
 </tr>
 <tr>
 <td>OCAML_USE_TOPKG</td>
 <td>OMF</td>
 </tr>
 <tr>
 <td>ONLY_FOR_COMPILER</td>
 <td>ONLY_FOR_PLATFORM</td>
 </tr>
 <tr>
 <td>OPENSSH_CHROOT</td>
 <td>OPENSSH_GROUP</td>
 </tr>
 <tr>
 <td>OPENSSH_USER</td>
 <td>OPSYS</td>
 </tr>
 <tr>
 <td>OPSYS_EMULDIR</td>
 <td>OPSYS_VERSION</td>
 </tr>
 <tr>
 <td>OS</td>
 <td>OSS_TYPE</td>
 </tr>
 <tr>
 <td>OSX</td>
 <td>OSX_TOLERATE_SDK_SKEW</td>
 </tr>
 <tr>
 <td>OS_HAVE_ALSA</td>
 <td>OS_HAVE_RCD</td>
 </tr>
 <tr>
 <td>OS_VARIANT</td>
 <td>OS_VERSION</td>
 </tr>
 <tr>
 <td>OTF_FONTS_DIR</td>
 <td>OVERRIDE_DIRDEPTH</td>
 </tr>
 <tr>
 <td>OVERRIDE_GEMSPEC</td>
 <td>OVERRIDE_GNU_CONFIG_SCRIPTS</td>
 </tr>
 <tr>
 <td>OVERRIDE_ROCKSPEC</td>
 <td>OWN_DIRS</td>
 </tr>
 <tr>
 <td>OWN_DIRS_PERMS</td>
 <td>P4GROUP</td>
 </tr>
 <tr>
 <td>P4GROUP</td>
 <td>P4PORT</td>
 <td>P4ROOT</td>
 </tr>
 <tr>
 <td>P4ROOT</td>
 <td>P4USER</td>
 <td>PACKAGES</td>
 </tr>
 <tr>
 <td>PACKAGES</td>
 <td>PALMOS_DEFAULT_SDK</td>
 <td>PAMBASE</td>
 </tr>
 <tr>
 <td>PAMBASE</td>
 <td>PAM_DEFAULT</td>
 <td>PAPERSIZE</td>
 </tr>
 <tr>
 <td>PAPERSIZE</td>
 <td>PASSIVE_FETCH</td>
 <td>PATCHDIR</td>
 </tr>
 <tr>
 <td>PATCHDIR</td>
 <td>PATCHFILES</td>
 <td>PATCH_ARGS</td>
 </tr>
 <tr>
 <td>PATCH_ARGS</td>
 <td>PATCH_DEBUG</td>
 <td>PATCH_DIST_ARGS</td>
 </tr>
 <tr>
 <td>PATCH_DIST_ARGS</td>
 <td>PATCH_DIST_CAT</td>
 <td>PATCH_DIST_STRIP</td>
 </tr>
 <tr>
 <td>PATCH_DIST_STRIP</td>
 <td>PATCH_FUZZ_FACTOR</td>
 <td>PATCH_STRIP</td>
 </tr>
 <tr>
 <td>PATCH_STRIP</td>
 <td>PATH</td>
 <td>PCCBASE</td>
 </tr>
 <tr>
 <td>PEAR</td>
 <td>PEAR_CHANNEL</td>
 </tr>
 <tr>
-<td>PEAR_CHANNEL_ALIAS</td>
+<td>PCCBASE</td>
-<td>PEAR_CHANNEL_VERSION</td>
+<td>PEAR_CMD</td>
 </tr>
 <tr>
 <td>PEAR_CMD</td>
 <td>PEAR_LIB</td>
 <td>PEAR_PACKAGE_XML</td>
 </tr>
 <tr>
 <td>PEAR_PACKAGE_XML</td>
 <td>PERL5</td>
 <td>PERL5_CONFIGURE</td>
 </tr>
 <tr>
 <td>PERL5_CONFIGURE</td>
 <td>PERL5_CONFIGURE_DIRS</td>
 <td>PERL5_LDFLAGS</td>
 </tr>
 <tr>
 <td>PERL5_LDFLAGS</td>
 <td>PERL5_LICENSE</td>
 <td>PERL5_MODULE_TYPE</td>
 </tr>
 <tr>
 <td>PERL5_MODULE_TYPE</td>
 <td>PERL5_PACKLIST</td>
 <td>PERL5_PACKLIST_DIR</td>
 </tr>
 <tr>
 <td>PERL5_PACKLIST_DIR</td>
 <td>PERL5_PERLBASE</td>
 <td>PERL5_SITEBASE</td>
 </tr>
 <tr>
 <td>PERL5_SITEBASE</td>
 <td>PERL5_USE_PACKLIST</td>
 <td>PERL5_VENDORBASE</td>
 </tr>
 <tr>
 <td>PERL5_VENDORBASE</td>
 <td>PFCTL</td>
 <td>PFVAR_H</td>
 </tr>
 <tr>
 <td>PFVAR_H</td>
 <td>PF_VERSION</td>
 <td>PGGROUP</td>
 </tr>
 <tr>
 <td>PGGROUP</td>
 <td>PGHOME</td>
 <td>PGPKGSRCDIR</td>
 </tr>
 <tr>
 <td>PGPKGSRCDIR</td>
 <td>PGSQL_TYPE</td>
 <td>PGSQL_VERSION</td>
 </tr>
 <tr>
 <td>PGSQL_VERSION</td>
 <td>PGSQL_VERSIONS_ACCEPTED</td>
 <td>PGSQL_VERSION_DEFAULT</td>
 </tr>
 <tr>
 <td>PGSQL_VERSION_DEFAULT</td>
 <td>PGUSER</td>
 <td>PG_LIB_EXT</td>
 </tr>
 <tr>
 <td>PG_LIB_EXT</td>
 <td>PHP</td>
 <td>PHPCOMMON_MK</td>
 </tr>
 <tr>
 <td>PHPCOMMON_MK</td>
 <td>PHPPKGSRCDIR</td>
 <td>PHP_BASE_VERS</td>
 </tr>
 <tr>
 <td>PHP_BASE_VERS</td>
 <td>PHP_CHECK_INSTALLED</td>
 <td>PHP_EXTENSION_DIR</td>
 </tr>
 <tr>
 <td>PHP_EXTENSION_DIR</td>
 <td>PHP_INITIAL_TEENY</td>
 <td>PHP_PKG_PREFIX</td>
 </tr>
 <tr>
 <td>PHP_PKG_PREFIX</td>
 <td>PHP_VERSION</td>
 <td>PHP_VERSIONS_ACCEPTED</td>
 </tr>
 <tr>
 <td>PHP_VERSIONS_ACCEPTED</td>
 <td>PHP_VERSIONS_INCOMPATIBLE</td>
 <td>PHP_VERSION_DEFAULT</td>
 </tr>
 <tr>
 <td>PHP_VERSION_DEFAULT</td>
 <td>PHP_VERSION_REQD</td>
 <td>PILRC_USE_GTK</td>
 </tr>
 <tr>
 <td>PILRC_USE_GTK</td>
 <td>PKGCONFIG_BASE</td>
 <td>PKGCONFIG_FILE</td>
 </tr>
 <tr>
 <td>PKGCONFIG_FILE</td>
 <td>PKGCONFIG_OVERRIDE</td>
 <td>PKGCONFIG_OVERRIDE_STAGE</td>
 </tr>
 <tr>
 <td>PKGCONFIG_OVERRIDE_STAGE</td>
 <td>PKGDIR</td>
 <td>PKGGNUDIR</td>
 </tr>
 <tr>
 <td>PKGGNUDIR</td>
 <td>PKGINFODIR</td>
 <td>PKGLOCALEDIR</td>
 </tr>
 <tr>
 <td>PKGLOCALEDIR</td>
 <td>PKGMANDIR</td>
 <td>PKGNAME</td>
 </tr>
 <tr>
 <td>PKGNAME</td>
 <td>PKGNAME_REQD</td>
 <td>PKGPATH</td>
 </tr>
 <tr>
 <td>PKGPATH</td>
 <td>PKGREVISION</td>
 <td>PKGSRC_BLAS_TYPES</td>
 </tr>
 <tr>
 <td>PKGSRC_BLAS_TYPES</td>
 <td>PKGSRC_CHANGES</td>
 <td>PKGSRC_COMPILER</td>
 </tr>
 <tr>
 <td>PKGSRC_COMPILER</td>
 <td>PKGSRC_KEEP_BIN_PKGS</td>
 <td>PKGSRC_LOCKTYPE</td>
 </tr>
 <tr>
 <td>PKGSRC_LOCKTYPE</td>
 <td>PKGSRC_MAKE_ENV</td>
 <td>PKGSRC_MESSAGE_RECIPIENTS</td>
 </tr>
 <tr>
 <td>PKGSRC_MESSAGE_RECIPIENTS</td>
 <td>PKGSRC_MKPIE</td>
 <td>PKGSRC_MKREPRO</td>
 </tr>
 <tr>
 <td>PKGSRC_MKREPRO</td>
 <td>PKGSRC_OVERRIDE_MKPIE</td>
 <td>PKGSRC_RUN_TEST</td>
 </tr>
 <tr>
 <td>PKGSRC_RUN_TEST</td>
 <td>PKGSRC_SETENV</td>
 <td>PKGSRC_SLEEPSECS</td>
 </tr>
 <tr>
 <td>PKGSRC_SLEEPSECS</td>
 <td>PKGSRC_TODO</td>
 <td>PKGSRC_USE_CTF</td>
 </tr>
 <tr>
 <td>PKGSRC_USE_CTF</td>
 <td>PKGSRC_USE_FORTIFY</td>
 <td>PKGSRC_USE_MKTOOLS</td>
 </tr>
 <tr>
 <td>PKGSRC_USE_MKTOOLS</td>
 <td>PKGSRC_USE_RELRO</td>
 <td>PKGSRC_USE_SSP</td>
 </tr>
 <tr>
 <td>PKGSRC_USE_SSP</td>
 <td>PKGSRC_USE_STACK_CHECK</td>
 <td>PKGTASKS_DATAFILE</td>
 </tr>
 <tr>
 <td>PKGTASKS_DATAFILE</td>
 <td>PKGTOOLS_ARGS</td>
 <td>PKGTOOLS_ENV</td>
 </tr>
 <tr>
 <td>PKGTOOLS_ENV</td>
 <td>PKG_ALTERNATIVES</td>
 <td>PKG_APACHE</td>
 </tr>
 <tr>
 <td>PKG_APACHE</td>
 <td>PKG_APACHE_ACCEPTED</td>
 <td>PKG_APACHE_DEFAULT</td>
 </tr>
 <tr>
 <td>PKG_APACHE_DEFAULT</td>
 <td>PKG_BEST_EXISTS</td>
 <td>PKG_BUILD_OPTIONS</td>
 </tr>
 <tr>
 <td>PKG_BUILD_OPTIONS</td>
 <td>PKG_COMPRESSION</td>
 <td>PKG_CONFIG</td>
 </tr>
 <tr>
 <td>PKG_CONFIG</td>
 <td>PKG_CONFIG_PERMS</td>
 <td>PKG_CREATE_USERGROUP</td>
 </tr>
 <tr>
 <td>PKG_CREATE_USERGROUP</td>
 <td>PKG_DB_TMPDIR</td>
 <td>PKG_DEBUG_LEVEL</td>
 </tr>
 <tr>
 <td>PKG_DEBUG_LEVEL</td>
 <td>PKG_DEFAULT_OPTIONS</td>
 <td>PKG_DESTDIR_SUPPORT</td>
 </tr>
 <tr>
 <td>PKG_DESTDIR_SUPPORT</td>
 <td>PKG_DEVELOPER</td>
 <td>PKG_DISABLED_OPTIONS</td>
 </tr>
 <tr>
 <td>PKG_DISABLED_OPTIONS</td>
 <td>PKG_FATAL_ERRORS</td>
 <td>PKG_FC</td>
 </tr>
 <tr>
 <td>PKG_FC</td>
 <td>PKG_FILELIST_CMD</td>
 </tr>
 <tr>
 <td>PKG_GECOS</td>
 <td>PKG_GID</td>
 </tr>
 <tr>
 <td>PKG_GID</td>
 <td>PKG_GROUPS</td>
 <td>PKG_GROUPS_VARS</td>
 </tr>
 <tr>
 <td>PKG_GROUPS_VARS</td>
 <td>PKG_HOME</td>
 <td>PKG_INIT_SCRIPTS</td>
 </tr>
 <tr>
 <td>PKG_INIT_SCRIPTS</td>
 <td>PKG_JAVA_HOME</td>
 <td>PKG_JVM</td>
 </tr>
 <tr>
 <td>PKG_JVM</td>
 <td>PKG_JVMS_ACCEPTED</td>
 <td>PKG_JVM_DEFAULT</td>
 </tr>
 <tr>
 <td>PKG_JVM_DEFAULT</td>
 <td>PKG_LEGACY_OPTIONS</td>
 <td>PKG_LIBTOOL</td>
 </tr>
 <tr>
 <td>PKG_LIBTOOL</td>
 <td>PKG_MKSYMLINKS</td>
 <td>PKG_OPTIONS</td>
 </tr>
 <tr>
 <td>PKG_OPTIONS</td>
 <td>PKG_OPTIONS_DEPRECATED_WARNINGS</td>
 <td>PKG_OPTIONS_LEGACY_OPTS</td>
 </tr>
 <tr>
 <td>PKG_OPTIONS_LEGACY_OPTS</td>
 <td>PKG_OPTIONS_LEGACY_VARS</td>
 <td>PKG_OPTIONS_NONEMPTY_SETS</td>
 </tr>
 <tr>
 <td>PKG_OPTIONS_NONEMPTY_SETS</td>
 <td>PKG_OPTIONS_OPTIONAL_GROUPS</td>
 <td>PKG_OPTIONS_REQUIRED_GROUPS</td>
 </tr>
 <tr>
 <td>PKG_OPTIONS_REQUIRED_GROUPS</td>
 <td>PKG_OPTIONS_VAR</td>
 <td>PKG_PHP</td>
 </tr>
 <tr>
 <td>PKG_PHP</td>
 <td>PKG_PHP_MAJOR_VERS</td>
 <td>PKG_PHP_VERSION</td>
 </tr>
 <tr>
 <td>PKG_PHP_VERSION</td>
 <td>PKG_RCD_SCRIPTS</td>
 <td>PKG_REFCOUNT_DBDIR</td>
 </tr>
 <tr>
 <td>PKG_REFCOUNT_DBDIR</td>
 <td>PKG_REGISTER_SHELLS</td>
 <td>PKG_RESUME_TRANSFERS</td>
 </tr>
 <tr>
 <td>PKG_RESUME_TRANSFERS</td>
 <td>PKG_SHELL</td>
 <td>PKG_SUGGESTED_OPTIONS</td>
 </tr>
 <tr>
 <td>PKG_SUGGESTED_OPTIONS</td>
 <td>PKG_SUPPORTED_OPTIONS</td>
 <td>PKG_SYSCONFBASE</td>
 </tr>
 <tr>
 <td>PKG_SYSCONFBASE</td>
 <td>PKG_SYSCONFBASEDIR</td>
 <td>PKG_SYSCONFDIR</td>
 </tr>
 <tr>
 <td>PKG_SYSCONFDIR</td>
 <td>PKG_SYSCONFDIR_PERMS</td>
 <td>PKG_SYSCONFSUBDIR</td>
 </tr>
 <tr>
 <td>PKG_SYSCONFSUBDIR</td>
 <td>PKG_SYSCONFVAR</td>
 <td>PKG_TOOLS_BIN</td>
 </tr>
 <tr>
 <td>PKG_TOOLS_BIN</td>
 <td>PKG_UID</td>
 <td>PKG_UPDATE_FONTS_DB</td>
 </tr>
 <tr>
 <td>PKG_UPDATE_FONTS_DB</td>
 <td>PKG_USERS</td>
 <td>PKG_USERS_VARS</td>
 </tr>
 <tr>
 <td>PKG_USERS_VARS</td>
 <td>PKG_VERBOSE</td>
 <td>PLEASE</td>
 </tr>
 <tr>
 <td>PLEASE</td>
 <td>PLIST</td>
 <td>PLIST_AWK</td>
 </tr>
 <tr>
 <td>PLIST_AWK</td>
 <td>PLIST_AWK_ENV</td>
 <td>PLIST_SRC</td>
 </tr>
 <tr>
 <td>PLIST_SRC</td>
 <td>PLIST_SUBST</td>
 <td>PLIST_TYPE</td>
 </tr>
 <tr>
 <td>PLIST_TYPE</td>
 <td>PLIST_VARS</td>
 <td>POPTOP_USE_MPPE</td>
 </tr>
 <tr>
 <td>POPTOP_USE_MPPE</td>
 <td>POSSIBLE_GFORTRAN_VERSION</td>
 <td>POST_FETCH_HOOK</td>
 </tr>
 <tr>
 <td>POST_FETCH_HOOK</td>
 <td>PREFER</td>
 <td>PREFER_NATIVE</td>
 </tr>
 <tr>
 <td>PREFER_NATIVE</td>
 <td>PREFER_NATIVE_PTHREADS</td>
 <td>PREFER_PKGSRC</td>
 </tr>
 <tr>
 <td>PREFER_PKGSRC</td>
 <td>PREFIX</td>
 <td>PREPEND_PATH</td>
 </tr>
 <tr>
 <td>PREPEND_PATH</td>
 <td>PRE_ROOT_CMD</td>
 <td>PRIVILEGED_STAGES</td>
 </tr>
 <tr>
 <td>PRIVILEGED_STAGES</td>
 <td>PS</td>
 <td>PTHREAD_AUTO_VARS</td>
 </tr>
 <tr>
 <td>PTHREAD_AUTO_VARS</td>
 <td>PTHREAD_CFLAGS</td>
 <td>PTHREAD_LDFLAGS</td>
 </tr>
 <tr>
 <td>PTHREAD_LDFLAGS</td>
 <td>PTHREAD_LIBS</td>
 <td>PTHREAD_OPTS</td>
 </tr>
 <tr>
 <td>PTHREAD_OPTS</td>
 <td>PTHREAD_TYPE</td>
 <td>PVM_SSH</td>
 </tr>
 <tr>
 <td>PVM_SSH</td>
 <td>PYPKGPREFIX</td>
 <td>PYTHON_FOR_BUILD_ONLY</td>
 </tr>
 <tr>
 <td>PYTHON_FOR_BUILD_ONLY</td>
 <td>PYTHON_SELF_CONFLICT</td>
 <td>PYTHON_VERSIONED_DEPENDENCIES</td>
 </tr>
 <tr>
 <td>PYTHON_VERSIONED_DEPENDENCIES</td>
 <td>PYTHON_VERSIONS_ACCEPTED</td>
 <td>PYTHON_VERSIONS_INCOMPATIBLE</td>
 </tr>
 <tr>
 <td>PYTHON_VERSIONS_INCOMPATIBLE</td>
 <td>PYTHON_VERSION_DEFAULT</td>
 <td>PYTHON_VERSION_REQD</td>
 </tr>
 <tr>
 <td>PYTHON_VERSION_REQD</td>
 <td>PYVERSSUFFIX</td>
 <td>QMAILDIR</td>
 </tr>
 <tr>
 <td>QMAILDIR</td>
 <td>QMAIL_ALIAS_USER</td>
 <td>QMAIL_DAEMON_USER</td>
 </tr>
 <tr>
 <td>QMAIL_DAEMON_USER</td>
 <td>QMAIL_LOG_USER</td>
 <td>QMAIL_NOFILES_GROUP</td>
 </tr>
 <tr>
 <td>QMAIL_NOFILES_GROUP</td>
 <td>QMAIL_PASSWD_USER</td>
 <td>QMAIL_QMAIL_GROUP</td>
 </tr>
 <tr>
 <td>QMAIL_QMAIL_GROUP</td>
 <td>QMAIL_QUEUE_DIR</td>
 <td>QMAIL_QUEUE_EXTRA</td>
 </tr>
 <tr>
 <td>QMAIL_QUEUE_EXTRA</td>
 <td>QMAIL_QUEUE_USER</td>
 <td>QMAIL_REMOTE_USER</td>
 </tr>
 <tr>
 <td>QMAIL_REMOTE_USER</td>
 <td>QMAIL_ROOT_USER</td>
 <td>QMAIL_SEND_USER</td>
 </tr>
 <tr>
 <td>QMAIL_SEND_USER</td>
 <td>QORE_LATEST_MODULE_API</td>
 <td>QORE_MODULE_API</td>
 </tr>
 <tr>
 <td>QORE_MODULE_API</td>
 <td>QORE_MODULE_DIR</td>
 <td>QORE_USER_MODULE_DIR</td>
 </tr>
 <tr>
 <td>QORE_USER_MODULE_DIR</td>
 <td>QORE_VERSION</td>
 <td>QPOPPER_FAC</td>
 </tr>
 <tr>
 <td>QPOPPER_FAC</td>
 <td>QPOPPER_SPOOL_DIR</td>
 <td>QPOPPER_USER</td>
 </tr>
 <tr>
 <td>QPOPPER_USER</td>
 <td>RAKE_NAME</td>
 <td>RASMOL_DEPTH</td>
 </tr>
 <tr>
 <td>RCD_DIR</td>
 <td>RCD_ORDER</td>
 </tr>
 <tr>
 <td>RASMOL_DEPTH</td>
 <td>RCD_SCRIPTS</td>
 <td>RCD_SCRIPTS_DIR</td>
 </tr>
 <tr>
 <td>RCD_SCRIPTS_DIR</td>
 <td>RCD_SCRIPTS_EXAMPLEDIR</td>
 <td>RCD_SCRIPTS_MODE</td>
 </tr>
 <tr>
 <td>RCD_SCRIPTS_MODE</td>
 <td>RCD_SCRIPTS_SHELL</td>
 <td>RCD_SCRIPT_SRC</td>
 </tr>
 <tr>
-<td>RCD_SUBR</td>
+<td>RCD_SCRIPT_SRC</td>
 <td>RDOC</td>
 </tr>
 <tr>
 <td>READLINE_DEFAULT</td>
 <td>READLINE_TYPE</td>
 </tr>
 <tr>
 <td>REAL_ROOT_GROUP</td>
 <td>REAL_ROOT_USER</td>
 </tr>
 <tr>
 <td>RECURSIVE_MAKE</td>
 <td>RELAY_CTRL_DIR</td>
 </tr>
 <tr>
 <td>RELRO_SUPPORTED</td>
 <td>REPLACE_AWK</td>
 </tr>
 <tr>
 <td>REPLACE_BASH</td>
 <td>REPLACE_CSH</td>
 </tr>
 <tr>
 <td>REPLACE_KSH</td>
 <td>REPLACE_LUA</td>
 </tr>
 <tr>
 <td>REPLACE_NODEJS</td>
 <td>REPLACE_OCTAVE</td>
 </tr>
 <tr>
 <td>REPLACE_PERL</td>
 <td>REPLACE_PERL6</td>
 </tr>
 <tr>
 <td>REPLACE_PHP</td>
 <td>REPLACE_PYTHON</td>
 </tr>
 <tr>
 <td>REPLACE_QORE</td>
 <td>REPLACE_R</td>
 </tr>
 <tr>
 <td>REPLACE_RUBY</td>
 <td>REPLACE_RUBY_DIRS</td>
 </tr>
 <tr>
 <td>REPLACE_RUBY_PAT</td>
 <td>REPLACE_SH</td>
 </tr>
 <tr>
 <td>REPLACE_TEXLUA</td>
 <td>REPLACE_WISH</td>
 </tr>
 <tr>
 <td>REQD_DIRS</td>
 <td>REQD_DIRS_PERMS</td>
 </tr>
 <tr>
 <td>REQD_FILES</td>
 <td>REQD_FILES_MODE</td>
 </tr>
 <tr>
 <td>REQD_FILES_PERMS</td>
 <td>RESOLV_AUTO_VARS</td>
 </tr>
 <tr>
 <td>RESOLV_LDFLAGS</td>
 <td>RESOLV_LIBS</td>
 </tr>
 <tr>
 <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>RPCGEN</td>
 <td>RPM</td>
 </tr>
 <tr>
 <td>RPM2PKG_PLIST</td>
 <td>RPM2PKG_PREFIX</td>
 </tr>
 <tr>
 <td>RPM2PKG_STAGE</td>
 <td>RPM2PKG_STRIP</td>
 </tr>
 <tr>
 <td>RPM2PKG_SUBPREFIX</td>
 <td>RPMFILES</td>
 </tr>
 <tr>
 <td>RPMIGNOREPATH</td>
 <td>RPM_DB_PREFIX</td>
 </tr>
 <tr>
 <td>RSSH_CVS_PATH</td>
 <td>RSSH_RDIST_PATH</td>
 </tr>
 <tr>
 <td>RSSH_RSYNC_PATH</td>
 <td>RSSH_SCP_PATH</td>
 </tr>
 <tr>
 <td>RSSH_SFTP_SERVER_PATH</td>
 <td>RUBY</td>
 </tr>
 <tr>
 <td>RUBYGEM</td>
 <td>RUBYGEM_NAME</td>
 </tr>
 <tr>
 <td>RUBYGEM_OPTIONS</td>
 <td>RUBYGEM_VERBOSE</td>
 </tr>
 <tr>
 <td>RUBY_ABI_VERSION</td>
 <td>RUBY_ARCH</td>
 </tr>
 <tr>
 <td>RUBY_ARCHINC</td>
 <td>RUBY_ARCHLIB</td>
 </tr>
 <tr>
 <td>RUBY_BASE</td>
 <td>RUBY_BASERIDIR</td>
 </tr>
 <tr>
 <td>RUBY_BUILD_DOCUMENT</td>
 <td>RUBY_DLEXT</td>
 </tr>
 <tr>
 <td>RUBY_DOC</td>
 <td>RUBY_DYNAMIC_DIRS</td>
 </tr>
 <tr>
 <td>RUBY_EG</td>
 <td>RUBY_ENCODING_ARG</td>
 </tr>
 <tr>
 <td>RUBY_EXTCONF</td>
 <td>RUBY_EXTCONF_CHECK</td>
 </tr>
 <tr>
 <td>RUBY_EXTCONF_DEBUG</td>
 <td>RUBY_EXTCONF_MAKEFILE</td>
 </tr>
 <tr>
 <td>RUBY_GEM_ARCH</td>
 <td>RUBY_GEM_BASE</td>
 </tr>
 <tr>
 <td>RUBY_INC</td>
 <td>RUBY_LIB</td>
 </tr>
 <tr>
 <td>RUBY_LIB_BASE</td>
 <td>RUBY_NAME</td>
 </tr>
 <tr>
 <td>RUBY_NOVERSION</td>
 <td>RUBY_PKGPREFIX</td>
 </tr>
 <tr>
 <td>RUBY_RAILS</td>
 <td>RUBY_RAILS52_VERSION</td>
 </tr>
 <tr>
 <td>RUBY_RAILS60_VERSION</td>
 <td>RUBY_RAILS61_VERSION</td>
 </tr>
 <tr>
 <td>RUBY_RAILS70_VERSION</td>
 <td>RUBY_RAILS_ACCEPTED</td>
 </tr>
 <tr>
 <td>RUBY_RAILS_DEFAULT</td>
 <td>RUBY_RAILS_REQD</td>
 </tr>
 <tr>
 <td>RUBY_RAILS_STRICT_DEP</td>
 <td>RUBY_RIDIR</td>
 </tr>
 <tr>
 <td>RUBY_SETUP</td>
 <td>RUBY_SHLIB</td>
 </tr>
 <tr>
 <td>RUBY_SHLIBALIAS</td>
 <td>RUBY_SHLIBVER</td>
 </tr>
 <tr>
 <td>RUBY_SIMPLE_INSTALL</td>
 <td>RUBY_SITEARCHLIB</td>
 </tr>
 <tr>
 <td>RUBY_SITELIB</td>
 <td>RUBY_SITELIB_BASE</td>
 </tr>
 <tr>
 <td>RUBY_SITERIDIR</td>
 <td>RUBY_SLEXT</td>
 </tr>
 <tr>
 <td>RUBY_SRCDIR</td>
 <td>RUBY_STATICLIB</td>
 </tr>
 <tr>
 <td>RUBY_SUFFIX</td>
 <td>RUBY_SYSRIDIR</td>
 </tr>
 <tr>
 <td>RUBY_USE_PTHREAD</td>
 <td>RUBY_VENDORARCHLIB</td>
 </tr>
 <tr>
 <td>RUBY_VENDORLIB</td>
 <td>RUBY_VENDORLIB_BASE</td>
 </tr>
 <tr>
 <td>RUBY_VER</td>
 <td>RUBY_VERSION</td>
 </tr>
 <tr>
 <td>RUBY_VERSIONS_ACCEPTED</td>
 <td>RUBY_VERSIONS_INCOMPATIBLE</td>
 </tr>
 <tr>
 <td>RUBY_VERSION_DEFAULT</td>
 <td>RUBY_VERSION_REQD</td>
 </tr>
 <tr>
 <td>RUBY_VER_DIR</td>
 <td>RUN</td>
 </tr>
 <tr>
 <td>RUN_LDCONFIG</td>
 <td>RUST_TYPE</td>
 </tr>
 <tr>
 <td>SCO</td>
 <td>SCREWS_GROUP</td>
 </tr>
 <tr>
 <td>SCREWS_USER</td>
 <td>SCRIPTS_ENV</td>
 </tr>
 <tr>
 <td>SCROLLKEEPER_DATADIR</td>
 <td>SCROLLKEEPER_REBUILDDB</td>
 </tr>
 <tr>
 <td>SCROLLKEEPER_UPDATEDB</td>
 <td>SDIST_PAWD</td>
 </tr>
 <tr>
 <td>SDL12_TYPE</td>
 <td>SERIAL_DEVICES</td>
 </tr>
 <tr>
 <td>SETGIDGAME</td>
 <td>SETGID_GAMES_PERMS</td>
 </tr>
 <tr>
 <td>SETUID_ROOT_PERMS</td>
 <td>SH</td>
 </tr>
 <tr>
 <td>SHLIB</td>
 <td>SHORTNAME</td>
 </tr>
 <tr>
 <td>SIGN_PACKAGES</td>
 <td>SILC_CLIENT_WITH_PERL</td>
 </tr>
 <tr>
 <td>SILC_CLIENT_WITH_PERL</td>
 <td>SITE_SPECIFIC_PKGS</td>
 <td>SKIP_DEPENDS</td>
 </tr>
 <tr>
 <td>SKIP_DEPENDS</td>
 <td>SMF_INSTANCES</td>
 <td>SMF_MANIFEST</td>
 </tr>
 <tr>
 <td>SMF_MANIFEST</td>
 <td>SMF_METHODS</td>
 <td>SMF_METHOD_SHELL</td>
 </tr>
 <tr>
 <td>SMF_METHOD_SHELL</td>
 <td>SMF_METHOD_SRC</td>
 <td>SMF_NAME</td>
 </tr>
 <tr>
 <td>SMF_NAME</td>
 <td>SMF_PREFIX</td>
 <td>SMF_SRCDIR</td>
 </tr>
 <tr>
 <td>SMF_SRCDIR</td>
 <td>SNIPROXY_GROUP</td>
 <td>SNIPROXY_USER</td>
 </tr>
 <tr>
 <td>SNIPROXY_USER</td>
 <td>SOURCE_BUFFSIZE</td>
 <td>SPECIAL_PERMS</td>
 </tr>
 <tr>
 <td>SPECIAL_PERMS</td>
 <td>SPECIFIC_PKGS</td>
 <td>SSH_SUID</td>
 </tr>
 <tr>
 <td>SSH_SUID</td>
 <td>SSP_SUPPORTED</td>
 <td>SSYNC_PAWD</td>
 </tr>
 <tr>
 <td>SSYNC_PAWD</td>
 <td>STEP_MSG</td>
 <td>STRIP</td>
 </tr>
 <tr>
 <td>STRIP</td>
 <td>STRIP_DBG</td>
 <td>STRIP_DEBUG</td>
 </tr>
 <tr>
 <td>STRIP_DEBUG</td>
 <td>STRIP_DEBUG_SUPPORTED</td>
 <td>STRIP_FILES_SKIP</td>
 </tr>
 <tr>
 <td>STRIP_FILES_SKIP</td>
 <td>SU</td>
 <td>SUBDIR</td>
 </tr>
 <tr>
 <td>SUBDIR</td>
 <td>SUBST</td>
 <td>SUBST_CLASSES</td>
 </tr>
 <tr>
 <td>SUBST_CLASSES</td>
 <td>SUBST_FILES</td>
 <td>SUBST_FILTER_CMD</td>
 </tr>
 <tr>
 <td>SUBST_FILTER_CMD</td>
 <td>SUBST_MESSAGE</td>
 <td>SUBST_NOOP_OK</td>
 </tr>
 <tr>
 <td>SUBST_NOOP_OK</td>
 <td>SUBST_SED</td>
 <td>SUBST_SHOW_DIFF</td>
 </tr>
 <tr>
 <td>SUBST_SHOW_DIFF</td>
 <td>SUBST_SKIP_TEXT_CHECK</td>
 <td>SUBST_STAGE</td>
 </tr>
 <tr>
 <td>SUBST_STAGE</td>
 <td>SUBST_VARS</td>
 <td>SUNWSPROBASE</td>
 </tr>
 <tr>
 <td>SUNWSPROBASE</td>
 <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>SU_CMD</td>
 <td>SYSCONFBASE</td>
 <td>TARGET_ARCH</td>
 </tr>
 <tr>
 <td>TARGET_ARCH</td>
 <td>TBL</td>
 <td>TERMCAP_TYPE</td>
 </tr>
 <tr>
 <td>TERMCAP_TYPE</td>
 <td>TERMINFO_DEFAULT</td>
 <td>TERMINFO_TYPE</td>
 </tr>
 <tr>
 <td>TERMINFO_TYPE</td>
 <td>TEST</td>
 <td>TEST_DEPENDS</td>
 </tr>
 <tr>
 <td>TEST_DEPENDS</td>
 <td>TEST_DIRS</td>
 <td>TEST_ENV</td>
 </tr>
 <tr>
 <td>TEST_ENV</td>
 <td>TEST_ENV_SHELL</td>
 <td>TEST_MAKE_CMD</td>
 </tr>
 <tr>
 <td>TEST_MAKE_CMD</td>
 <td>TEST_MAKE_FLAGS</td>
 <td>TEST_TARGET</td>
 </tr>
 <tr>
 <td>TEST_TARGET</td>
 <td>TEXLIVE_IGNORE_PATTERNS</td>
 <td>TEXLIVE_REV</td>
 </tr>
 <tr>
 <td>TEXLIVE_REV</td>
 <td>TEXLIVE_UNVERSIONED</td>
 <td>TEXMFSITE</td>
 </tr>
 <tr>
 <td>TEXMFSITE</td>
 <td>TEX_FORMATS</td>
 <td>TEX_HYPHEN_DAT</td>
 </tr>
 <tr>
 <td>TEX_HYPHEN_DAT</td>
 <td>TEX_HYPHEN_DEF</td>
 <td>TEX_TEXMF_DIRS</td>
 </tr>
 <tr>
 <td>TEX_TEXMF_DIRS</td>
 <td>THTTPD_LOG_FACILITY</td>
 <td>TINYDYN_USER</td>
 </tr>
 <tr>
 <td>TINYDYN_USER</td>
 <td>TLSWRAPPER_CHROOT</td>
 <td>TO</td>
 </tr>
 <tr>
 <td>TO</td>
 <td>TOOLS_ALIASES</td>
 <td>TOOLS_ALWAYS_WRAP</td>
 </tr>
 <tr>
 <td>TOOLS_ALWAYS_WRAP</td>
 <td>TOOLS_ARGS</td>
 <td>TOOLS_BROKEN</td>
 </tr>
 <tr>
 <td>TOOLS_BROKEN</td>
 <td>TOOLS_CMD</td>
 <td>TOOLS_CMDLINE_SED</td>
 </tr>
 <tr>
 <td>TOOLS_CMDLINE_SED</td>
 <td>TOOLS_CREATE</td>
 <td>TOOLS_CROSS_DESTDIR</td>
 </tr>
 <tr>
 <td>TOOLS_CROSS_DESTDIR</td>
 <td>TOOLS_DIR</td>
 <td>TOOLS_FAIL</td>
 </tr>
 <tr>
 <td>TOOLS_FAIL</td>
 <td>TOOLS_GNU_MISSING</td>
 <td>TOOLS_LDCONFIG</td>
 </tr>
 <tr>
 <td>TOOLS_LDCONFIG</td>
 <td>TOOLS_NOOP</td>
 <td>TOOLS_PATH</td>
 </tr>
 <tr>
 <td>TOOLS_PATH</td>
 <td>TOOLS_SCRIPT</td>
 <td>TOOLS_USE_CROSS_COMPILE</td>
 </tr>
 <tr>
 <td>TOOLS_USE_CROSS_COMPILE</td>
 <td>TOOL_DEPENDS</td>
 <td>TTF_FONTDIR</td>
 </tr>
 <tr>
 <td>TTF_FONTS_DIR</td>
 <td>TYPE</td>
 </tr>
 <tr>
 <td>UAC_REQD_EXECS</td>
 <td>UCSPI_SSL_GROUP</td>
 </tr>
 <tr>
 <td>UCSPI_SSL_USER</td>
 <td>UNLIMIT_RESOURCES</td>
 </tr>
 <tr>
 <td>UNPRIVILEGED</td>
 <td>UNPRIVILEGED_GROUP</td>
 </tr>
 <tr>
 <td>UNPRIVILEGED_GROUPS</td>
 <td>UNPRIVILEGED_USER</td>
 </tr>
 <tr>
 <td>UNWRAP_FILES</td>
 <td>UNWRAP_PATTERNS</td>
 </tr>
 <tr>
 <td>UPDATE_GEMSPEC</td>
 <td>UPDATE_TARGET</td>
 </tr>
 <tr>
 <td>URI</td>
 <td>USERGROUP_PHASE</td>
 </tr>
 <tr>
 <td>USERPPP_GROUP</td>
 <td>USER_SPECIFIC_PKGS</td>
 </tr>
 <tr>
 <td>USE_ABI_DEPENDS</td>
 <td>USE_APR</td>
 </tr>
 <tr>
 <td>USE_BSD_MAKEFILE</td>
 <td>USE_BUILTIN</td>
 </tr>
 <tr>
 <td>USE_CROSS_COMPILE</td>
 <td>USE_CURSES</td>
 </tr>
 <tr>
 <td>USE_CWRAPPERS</td>
 <td>USE_DB185</td>
 </tr>
 <tr>
 <td>USE_FEATURES</td>
 <td>USE_GAMESGROUP</td>
 </tr>
 <tr>
 <td>USE_GCC_RUNTIME</td>
 <td>USE_IMAKE</td>
 </tr>
 <tr>
 <td>USE_JAVA</td>
 <td>USE_JAVA2</td>
 </tr>
 <tr>
 <td>USE_LANGUAGES</td>
 <td>USE_LIBTOOL</td>
 </tr>
 <tr>
 <td>USE_NATIVE_GCC</td>
 <td>USE_NETBSD_REPO</td>
 </tr>
 <tr>
 <td>USE_PKGSRC_GCC</td>
 <td>USE_PKGSRC_GCC_RUNTIME</td>
 </tr>
 <tr>
 <td>USE_PKGTASKS</td>
 <td>USE_PKG_ADMIN_DIGEST</td>
 </tr>
 <tr>
 <td>USE_RUBY_EXTCONF</td>
 <td>USE_RUBY_INSTALL</td>
 </tr>
 <tr>
 <td>USE_RUBY_SETUP</td>
 <td>USE_RUBY_SETUP_PKG</td>
 </tr>
 <tr>
 <td>USE_TOOLS</td>
 <td>UUCP_GROUP</td>
 </tr>
 <tr>
 <td>UUCP_USER</td>
 <td>VARBASE</td>
 </tr>
 <tr>
 <td>VARNAME</td>
 <td>VIM_EXTRA_OPTS</td>
 </tr>
 <tr>
 <td>WARNING_MSG</td>
 <td>WCALC_CGIDIR</td>
 </tr>
 <tr>
 <td>WCALC_CGIPATH</td>
 <td>WCALC_HTMLDIR</td>
 </tr>
 <tr>
 <td>WCALC_HTMLPATH</td>
 <td>WDM_MANAGERS</td>
 </tr>
 <tr>
 <td>WRAPPER_CC</td>
 <td>WRAPPER_REORDER_CMDS</td>
 </tr>
 <tr>
 <td>WRKDIR</td>
 <td>WRKDIR_BASENAME</td>
 </tr>
 <tr>
 <td>WRKDIR_LOCKTYPE</td>
 <td>WRKLOG</td>
 </tr>
 <tr>
 <td>WRKOBJDIR</td>
 <td>WRKSRC</td>
 </tr>
 <tr>
 <td>X10_PORT</td>
 <td>X11</td>
 </tr>
 <tr>
 <td>X11BASE</td>
 <td>X11_PKGSRCDIR</td>
 </tr>
 <tr>
 <td>X11_TYPE</td>
 <td>X509_CERTIFICATE</td>
 </tr>
 <tr>
 <td>X509_KEY</td>
 <td>XAW_TYPE</td>
 </tr>
 <tr>
 <td>XLOCK_DEFAULT_MODE</td>
 <td>XMKMF</td>
 </tr>
 <tr>
 <td>XMKMF_FLAGS</td>
 <td>XXX</td>
 </tr>
 <tr>
 <td>XXXX</td>
 <td>YES</td>
 </tr>
 <tr>
 <td>ZSH_STATIC</td>
 <td>__stdc__</td>
 </tr>
 <tr>
 <td>__stdc__</td>
 <td>_vargroups</td>
 <td>accept</td>
 </tr>
 <tr>
 <td>accept</td>
 <td>acquire-localbase-lock</td>
 <td>acquire-lock</td>
 </tr>
 <tr>
 <td>acquire-lock</td>
 <td>add</td>
 <td>added</td>
 </tr>
 <tr>
 <td>added</td>
 <td>administrator</td>
 <td>alloca</td>
 </tr>
 <tr>
 <td>alloca</td>
 <td>alternatives</td>
 <td>aslr</td>
 </tr>
 <tr>
 <td>aslr</td>
 <td>asprintf</td>
 <td>atlas</td>
 </tr>
 <tr>
 <td>atlas</td>
 <td>autoconf</td>
 <td>automake</td>
 </tr>
 <tr>
 <td>automake</td>
 <td>autoreconf</td>
 <td>awk</td>
 </tr>
 <tr>
 <td>awk</td>
 <td>bash</td>
 <td>big-endian</td>
 </tr>
 <tr>
 <td>big-endian</td>
 <td>bin-install</td>
 <td>bind</td>
 </tr>
 <tr>
 <td>bind</td>
 <td>binpkg-list</td>
 <td>blas</td>
 </tr>
 <tr>
 <td>blas</td>
 <td>bootstrap-depends</td>
 <td>broken</td>
 </tr>
 <tr>
 <td>broken</td>
 <td>broken_on_platform</td>
 <td>bsd</td>
 </tr>
 <tr>
 <td>bsd</td>
 <td>bsd.prog.mk</td>
 <td>build</td>
 </tr>
 <tr>
 <td>build</td>
 <td>build-env</td>
 <td>buildlink-directories</td>
 </tr>
 <tr>
 <td>buildlink-directories</td>
 <td>buildlink-oss-soundcard-h</td>
 <td>c</td>
 </tr>
 <tr>
 <td>c</td>
 <td>c++</td>
 <td>ccache</td>
 </tr>
 <tr>
 <td>ccache</td>
 <td>cce</td>
 <td>cdefs</td>
 </tr>
 <tr>
 <td>cdefs</td>
 <td>ceil</td>
 <td>changes</td>
 </tr>
 <tr>
 <td>changes</td>
 <td>changes-entry</td>
 <td>changes-entry-noupdate</td>
 </tr>
 <tr>
 <td>changes-entry-noupdate</td>
 <td>check</td>
 <td>check-clean</td>
 </tr>
 <tr>
 <td>check-clean</td>
 <td>check-files</td>
 <td>check-files-clean</td>
 </tr>
 <tr>
 <td>check-files-clean</td>
 <td>check-vulnerable</td>
 <td>checksum</td>
 </tr>
 <tr>
 <td>checksum</td>
 <td>checksum-phase</td>
 <td>clean</td>
 </tr>
 <tr>
 <td>clean</td>
 <td>clean-depends</td>
 <td>cleandir</td>
 </tr>
 <tr>
 <td>cleandir</td>
 <td>commit</td>
 <td>commit-changes-entry</td>
 </tr>
 <tr>
 <td>commit-changes-entry</td>
 <td>compact</td>
 <td>compiler</td>
 </tr>
 <tr>
 <td>compiler</td>
 <td>conf</td>
 <td>config.guess</td>
 </tr>
 <tr>
 <td>config.guess</td>
 <td>config.sub</td>
 <td>configuration</td>
 </tr>
 <tr>
 <td>configuration</td>
 <td>configure</td>
 <td>configure-env</td>
 </tr>
 <tr>
 <td>configure-env</td>
 <td>configure-help</td>
 <td>configure_args</td>
 </tr>
 <tr>
 <td>configure_args</td>
 <td>connect</td>
 <td>cos</td>
 </tr>
 <tr>
 <td>cos</td>
 <td>cputime</td>
 <td>create-usergroup</td>
 </tr>
 <tr>
 <td>create-usergroup</td>
 <td>csh</td>
 <td>ctf</td>
 </tr>
 <tr>
-<td>cvs</td>
+<td>ctf</td>
 <td>debug</td>
 </tr>
 <tr>
 <td>declaration</td>
 <td>declare</td>
 </tr>
 <tr>
 <td>defined</td>
 <td>depend</td>
 </tr>
 <tr>
 <td>dependencies</td>
 <td>depends</td>
 </tr>
 <tr>
 <td>depends-checksum</td>
 <td>depends-fetch</td>
 </tr>
 <tr>
 <td>deps</td>
 <td>describe</td>
 </tr>
 <tr>
 <td>destdir</td>
 <td>disable</td>
 </tr>
 <tr>
 <td>distclean</td>
 <td>distinfo</td>
 </tr>
 <tr>
 <td>dl</td>
 <td>dlopen</td>
 </tr>
 <tr>
 <td>do-buildlink</td>
 <td>do-clean</td>
 </tr>
 <tr>
 <td>do-configure</td>
 <td>do-configure-post-hook</td>
 </tr>
 <tr>
 <td>do-extract</td>
 <td>do-fetch</td>
 </tr>
 <tr>
 <td>do-install</td>
 <td>emul</td>
 </tr>
 <tr>
 <td>emul-distinfo</td>
 <td>emul-fetch</td>
 </tr>
 <tr>
 <td>emulation</td>
 <td>emulator</td>
 </tr>
 <tr>
 <td>enable</td>
 <td>endian</td>
 </tr>
 <tr>
 <td>endif</td>
 <td>enomem</td>
 </tr>
 <tr>
 <td>ensurepip</td>
 <td>err</td>
 </tr>
 <tr>
 <td>err</td>
 <td>errx</td>
 <td>etc</td>
 </tr>
 <tr>
 <td>etc</td>
 <td>exp</td>
 <td>extract-rpm</td>
 </tr>
 <tr>
 <td>extract-rpm</td>
 <td>fabs</td>
 <td>feature</td>
 </tr>
 <tr>
 <td>feature</td>
 <td>features</td>
 <td>fetch</td>
 </tr>
 <tr>
 <td>fetch</td>
 <td>fetch-list</td>
 <td>follows</td>
 </tr>
 <tr>
 <td>follows</td>
 <td>forbids</td>
 <td>form</td>
 </tr>
 <tr>
 <td>form</td>
 <td>format</td>
 <td>fortify</td>
 </tr>
 <tr>
 <td>fortify</td>
 <td>fortify_source</td>
 <td>fossil</td>
 </tr>
 <tr>
 <td>friend</td>
 <td>fts</td>
 </tr>
 <tr>
 <td>fts_close</td>
 <td>fts_open</td>
 </tr>
 <tr>
 <td>fts_read</td>
 <td>fts_set</td>
 </tr>
 <tr>
 <td>gcc</td>
 <td>gethostbyaddr</td>
 </tr>
 <tr>
 <td>gethostbyname</td>
 <td>gethostbyname2</td>
 </tr>
 <tr>
 <td>getopt_long</td>
 <td>getprogname</td>
 </tr>
 <tr>
 <td>getservbyname</td>
 <td>getservbyport</td>
 </tr>
 <tr>
 <td>getservent</td>
 <td>gettext</td>
 </tr>
 <tr>
 <td>git</td>
 <td>github</td>
 </tr>
 <tr>
 <td>gitlab</td>
 <td>glob</td>
 </tr>
 <tr>
 <td>glob</td>
 <td>gnu</td>
 <td>gnu_configure_strict</td>
 </tr>
 <tr>
 <td>gnu_configure_strict</td>
 <td>go</td>
 <td>go-deps</td>
 </tr>
 <tr>
 <td>go-deps</td>
 <td>golang</td>
 <td>guess-license</td>
 </tr>
 <tr>
 <td>guess-license</td>
 <td>hashbang</td>
 <td>heimdal</td>
 </tr>
 <tr>
 <td>heimdal</td>
 <td>help</td>
 <td>hg</td>
 </tr>
 <tr>
 <td>imake</td>
 <td>increment</td>
 </tr>
 <tr>
 <td>indirect</td>
 <td>inet_aton</td>
 </tr>
 <tr>
 <td>interp</td>
 <td>interpreter</td>
 </tr>
 <tr>
 <td>intl</td>
 <td>ip4</td>
 </tr>
 <tr>
 <td>ip6</td>
 <td>ipv4</td>
 </tr>
 <tr>
 <td>ipv6</td>
 <td>iso</td>
 </tr>
 <tr>
 <td>kerberos</td>
 <td>krb</td>
 </tr>
 <tr>
 <td>krb5</td>
 <td>ksh</td>
 </tr>
 <tr>
 <td>lapack</td>
 <td>latex</td>
 </tr>
 <tr>
 <td>libintl_bindtextdomain</td>
 <td>libintl_gettext</td>
 </tr>
 <tr>
 <td>libintl_textdomain</td>
 <td>libnbcompat</td>
 </tr>
 <tr>
 <td>libs</td>
 <td>libtool</td>
 </tr>
 <tr>
 <td>licence</td>
 <td>license</td>
 </tr>
 <tr>
 <td>lintl</td>
 <td>little-endian</td>
 </tr>
 <tr>
 <td>lock</td>
 <td>locking</td>
 </tr>
 <tr>
 <td>lua</td>
 <td>lvalue</td>
 </tr>
 <tr>
 <td>make</td>
 <td>makesum</td>
 </tr>
 <tr>
 <td>memory</td>
 <td>mercurial</td>
 </tr>
 <tr>
 <td>meta</td>
 <td>meta-package</td>
 </tr>
 <tr>
 <td>meta-package</td>
 <td>meta_package</td>
 <td>mit-krb5</td>
 </tr>
 <tr>
 <td>mit-krb5</td>
 <td>mk.conf</td>
 <td>mkl</td>
 </tr>
 <tr>
 <td>mkl</td>
 <td>mount</td>
 <td>move</td>
 </tr>
 <tr>
 <td>move</td>
 <td>moved</td>
 <td>mprotect</td>
 </tr>
 <tr>
 <td>mprotect</td>
 <td>mremap</td>
 <td>nb</td>
 </tr>
 <tr>
 <td>nb</td>
 <td>nbcompat</td>
 <td>netlib</td>
 </tr>
 <tr>
 <td>netlib</td>
 <td>node</td>
 <td>node.js</td>
 </tr>
 <tr>
 <td>node.js</td>
 <td>nodejs</td>
 <td>obstack</td>
 </tr>
 <tr>
 <td>obstack</td>
 <td>obstack_ptr_grow</td>
 <td>occurs</td>
 </tr>
 <tr>
 <td>occurs</td>
 <td>only</td>
 <td>openblas</td>
 </tr>
 <tr>
 <td>openblas</td>
 <td>options</td>
 <td>options.mk</td>
 </tr>
 <tr>
 <td>options.mk</td>
 <td>order</td>
 <td>override</td>
 </tr>
 <tr>
 <td>override</td>
 <td>override-intltool</td>
 <td>override-message-intltool</td>
 </tr>
 <tr>
 <td>override-message-intltool</td>
 <td>package</td>
 <td>parallel</td>
 </tr>
 <tr>
 <td>parallel</td>
 <td>path</td>
 <td>pax</td>
 </tr>
 <tr>
 <td>pax</td>
 <td>paxctl</td>
 <td>pbulk-index</td>
 </tr>
 <tr>
 <td>pbulk-index</td>
 <td>pc</td>
 <td>perl</td>
 </tr>
 <tr>
 <td>perl</td>
 <td>perl5</td>
 <td>perms</td>
 </tr>
 <tr>
 <td>perms</td>
 <td>php</td>
 <td>pkg-build-options</td>
 </tr>
 <tr>
 <td>pkg-build-options</td>
 <td>pkg-config</td>
 <td>pkg_build_options</td>
 </tr>
 <tr>
 <td>pkg_build_options</td>
 <td>platform</td>
 <td>plist</td>
 </tr>
 <tr>
 <td>plist</td>
 <td>post-extract</td>
 <td>post-fetch</td>
 </tr>
 <tr>
 <td>post-fetch</td>
 <td>post-wrapper</td>
 <td>pre-build-checks-hook</td>
 </tr>
 <tr>
 <td>pre-build-checks-hook</td>
 <td>pre-configure</td>
 <td>pre-configure-checks-hook</td>
 </tr>
 <tr>
 <td>pre-configure-checks-hook</td>
 <td>pre-extract</td>
 <td>pre-fetch</td>
 </tr>
 <tr>
 <td>pre-fetch</td>
 <td>print-go-deps</td>
 <td>print-plist</td>
 </tr>
 <tr>
 <td>print-plist</td>
 <td>print-summary-data</td>
 <td>privileged-install-hook</td>
 </tr>
 <tr>
 <td>privileged-install-hook</td>
 <td>pypi</td>
 <td>python</td>
 </tr>
 <tr>
 <td>python</td>
 <td>r</td>
 <td>readme-all</td>
 </tr>
 <tr>
 <td>readme-all</td>
 <td>recursive</td>
 <td>recv</td>
 </tr>
 <tr>
 <td>recv</td>
 <td>recvfrom</td>
 <td>regcomp</td>
 </tr>
 <tr>
 <td>regcomp</td>
 <td>release-localbase-lock</td>
 <td>release-lock</td>
 </tr>
 <tr>
 <td>release-lock</td>
 <td>relro</td>
 <td>remove</td>
 </tr>
 <tr>
 <td>remove</td>
 <td>removed</td>
 <td>rename</td>
 </tr>
 <tr>
 <td>rename</td>
 <td>renamed</td>
 <td>reorder</td>
 </tr>
 <tr>
 <td>reorder</td>
 <td>replace</td>
 <td>replace_interpreter</td>
 </tr>
 <tr>
 <td>replace_interpreter</td>
 <td>reproducible</td>
 <td>resolv</td>
 </tr>
 <tr>
 <td>resolv</td>
 <td>root</td>
 <td>ruby</td>
 </tr>
 <tr>
 <td>ruby</td>
 <td>send</td>
 <td>sendfile</td>
 </tr>
 <tr>
 <td>sendfile</td>
 <td>sendto</td>
 <td>setenv</td>
 </tr>
 <tr>
 <td>setenv</td>
 <td>setgid</td>
 <td>setprogname</td>
 </tr>
 <tr>
 <td>setprogname</td>
 <td>setuid</td>
 <td>sh</td>
 </tr>
 <tr>
 <td>sh</td>
 <td>shebang</td>
 <td>show</td>
 </tr>
 <tr>
 <td>show</td>
 <td>show-all</td>
 <td>show-build-defs</td>
 </tr>
 <tr>
 <td>show-build-defs</td>
 <td>show-depends</td>
 <td>show-depends-dirs</td>
 </tr>
 <tr>
 <td>show-depends-dirs</td>
 <td>show-depends-pkgpaths</td>
 <td>show-depends-recursive</td>
 </tr>
 <tr>
 <td>show-depends-recursive</td>
 <td>show-deps</td>
 <td>show-distfiles</td>
 </tr>
 <tr>
 <td>show-distfiles</td>
 <td>show-downlevel</td>
 <td>show-subdir-var</td>
 </tr>
 <tr>
 <td>show-subdir-var</td>
 <td>show-tools</td>
 <td>show-var</td>
 </tr>
 <tr>
 <td>show-var</td>
 <td>show-vars</td>
 <td>snprintf</td>
 </tr>
 <tr>
 <td>snprintf</td>
 <td>socket</td>
 <td>ssp</td>
 </tr>
 <tr>
 <td>ssp</td>
 <td>st_mode</td>
 <td>stage-install</td>
 </tr>
 <tr>
 <td>stage-install</td>
 <td>strcasestr</td>
 <td>strict</td>
 </tr>
 <tr>
 <td>strict</td>
 <td>strip</td>
 <td>strndup</td>
 </tr>
 <tr>
 <td>strndup</td>
 <td>strnlen</td>
 <td>strsep</td>
 </tr>
 <tr>
 <td>strsep</td>
 <td>subst</td>
 <td>substitutions</td>
 </tr>
 <tr>
-<td>subversion</td>
+<td>substitutions</td>
 <td>sun</td>
 </tr>
 <tr>
 <td>sunpro</td>
 <td>sunwspro</td>
 </tr>
 <tr>
 <td>svn</td>
 <td>symlink</td>
 </tr>
 <tr>
 <td>test</td>
 <td>test-env</td>
 </tr>
 <tr>
 <td>test-env</td>
 <td>tex</td>
 <td>texlive</td>
 </tr>
 <tr>
 <td>texlive</td>
 <td>tmp</td>
 <td>todo</td>
 </tr>
 <tr>
 <td>todo</td>
 <td>tool</td>
 <td>tools</td>
 </tr>
 <tr>
 <td>tools</td>
 <td>tools-libtool-m4-override</td>
 <td>transitive</td>
 </tr>
 <tr>
 <td>transitive</td>
 <td>type</td>
 <td>ulimit</td>
 </tr>
 <tr>
 <td>ulimit</td>
 <td>undefined</td>
 <td>undo-replace</td>
 </tr>
 <tr>
 <td>undo-replace</td>
 <td>unlimit</td>
 <td>unprivileged</td>
 </tr>
 <tr>
 <td>unprivileged</td>
 <td>unprivileged-install-hook</td>
 <td>unstripped</td>
 </tr>
 <tr>
 <td>unstripped</td>
 <td>update</td>
 <td>updated</td>
 </tr>
 <tr>
 <td>updated</td>
 <td>upload</td>
 <td>upload-distfiles</td>
 </tr>
 <tr>
 <td>upload-distfiles</td>
 <td>use_tools</td>
 <td>user</td>
 </tr>
 <tr>
 <td>user</td>
 <td>utimes</td>
 <td>vasprintf</td>
 </tr>
 <tr>
 <td>vasprintf</td>
 <td>verbose</td>
 <td>vsnprintf</td>
 </tr>
 <tr>
 <td>vsnprintf</td>
 <td>warn</td>
 <td>warning</td>
 </tr>
 <tr>
 <td>warning</td>
 <td>warnings</td>
 <td>warnx</td>
 </tr>
 <tr>
 <td>warnx</td>
 <td>wattr_off</td>
 <td>wattr_on</td>
 </tr>
 <tr>
 <td>wattr_on</td>
 <td>work</td>
 <td>wrapper</td>
 </tr>
 <tr>
 <td>wrapper</td>
 <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>

 @@ -2526,1999 +2526,2006 @@ running:
 If you even decide to ignore NO_{SRC,BIN}_ON_{FTP,CDROM}, then you can get
 everything by running:
 % make fetch NO_SKIP=yes
 .10. What does "Don't know how to make /usr/share/tmac/tmac.andoc" mean?
 When compiling the pkgtools/pkg_install package, you get the error from make
 that it doesn't know how to make /usr/share/tmac/tmac.andoc? This indicates
 that you don't have installed the "text" set (nroff, ...) from the NetBSD base
 distribution on your machine. It is recommended to do that to format man pages.
 In the case of the pkgtools/pkg_install package, you can get away with setting
 NOMAN=YES either in the environment or in mk.conf.
 .11. What does "Could not find bsd.own.mk" mean?
 You didn't install the compiler set, comp.tgz, when you installed your NetBSD
 machine. Please get and install it, by extracting it in /:
 # cd /
 # tar --unlink -zxvpf .../comp.tgz
 comp.tgz is part of every NetBSD release. Get the one that corresponds to your
 release (determine via uname -r).
 .12. Using 'sudo' or `priv` with pkgsrc
 When installing packages as non-root user and using the just-in-time su(1)
 feature of pkgsrc, it can become annoying to type in the root password for each
 required package installed. To avoid this, the sudo package can be used, which
 does password caching over a limited time. To use it, install sudo or priv
 (either as binary package, from security/priv, or security/sudo) and then put
 the following into your mk.conf, somewhere after the definition of the
 LOCALBASE variable:
 .if exists(${LOCALBASE}/bin/sudo)
 SU_CMD=        ${LOCALBASE}/bin/sudo /bin/sh -c
 .endif
 .13. How do I change the location of configuration files?
 As the system administrator, you can choose where configuration files are
 installed. The default settings make all these files go into ${PREFIX}/etc or
 some of its subdirectories; this may be suboptimal depending on your
 expectations (e.g., a read-only, NFS-exported PREFIX with a need of per-machine
 configuration of the provided packages).
 In order to change the defaults, you can modify the PKG_SYSCONFBASE variable
 (in mk.conf) to point to your preferred configuration directory; some common
 examples include /etc or /etc/pkg.
 Furthermore, you can change this value on a per-package basis by setting the
 PKG_SYSCONFDIR.${PKG_SYSCONFVAR} variable. PKG_SYSCONFVAR's value usually
 matches the name of the package you would like to modify, that is, the contents
 of PKGBASE.
 Note that after changing these settings, you must rebuild and reinstall any
 affected packages.
 .14. Automated security checks
 Please be aware that there can often be bugs in third-party software, and some
 of these bugs can leave a machine vulnerable to exploitation by attackers. In
 an effort to lessen the exposure, the NetBSD packages team maintains a database
 of known-exploits to packages which have at one time been included in pkgsrc.
 The database can be downloaded automatically, and a security audit of all
 packages installed on a system can take place. To do this, refer to the
 following two tools (installed as part of the pkgtools/pkg_install package):
 . pkg_admin fetch-pkg-vulnerabilities, an easy way to download a list of the
     security vulnerabilities information. This list is kept up to date by the
     pkgsrc security team, and is distributed from the NetBSD ftp server:
     https://ftp.NetBSD.org/pub/NetBSD/packages/vulns/pkg-vulnerabilities
 . pkg_admin audit, an easy way to audit the current machine, checking each
     known vulnerability. If a vulnerable package is installed, it will be shown
     by output to stdout, including a description of the type of vulnerability,
     and a URL containing more information.
 Use of these tools is strongly recommended! See Section 5.1.6, "Checking for
 security vulnerabilities in installed packages" for instructions on how to
 automate checking and reporting.
 If this database is installed, pkgsrc builds will use it to perform a security
 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.
+    package. It is defined after including bsd.prefs.mk and can be used in
     makefile fragments that are used by several packages to distinguish between
     these packages. Other variables that would serve the same purpose are
     PKGBASE and PKGNAME, but these are only defined after including bsd.pkg.mk,
     which is too late.
     In mk.conf, the pkgsrc user can use PKGPATH to tweak variables like
     MAKE_JOBS and CFLAGS.
 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_CRATESIO      MASTER_SITE_CYGWIN
 MASTER_SITE_DEBIAN        MASTER_SITE_FREEBSD
 MASTER_SITE_FREEBSD_LOCAL MASTER_SITE_GENTOO
 MASTER_SITE_GITHUB        MASTER_SITE_GITLAB
 MASTER_SITE_GNOME         MASTER_SITE_GNU
 MASTER_SITE_GNUSTEP       MASTER_SITE_HASKELL_HACKAGE
 MASTER_SITE_IFARCHIVE     MASTER_SITE_KDE
 MASTER_SITE_MOZILLA       MASTER_SITE_MOZILLA_ALL
 MASTER_SITE_MYSQL         MASTER_SITE_NETLIB
 MASTER_SITE_OPENBSD       MASTER_SITE_OPENOFFICE
 MASTER_SITE_OSDN          MASTER_SITE_PERL_CPAN
 MASTER_SITE_PGSQL         MASTER_SITE_PYPI
 MASTER_SITE_RUBYGEMS      MASTER_SITE_R_CRAN
 MASTER_SITE_SOURCEFORGE   MASTER_SITE_SUNSITE
 MASTER_SITE_SUSE          MASTER_SITE_TEX_CTAN
 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}
 For software in PyPi, the name should match what PyPi specifies for "pip
 install software".
 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 \
 @@ -6426,1998 +6433,2005 @@ Both BROKEN_ON_PLATFORM and BROKEN_EXCEP
 (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 she-bangs in files. Please use the appropriate one, preferring REPLACE_SH
 when this shell is sufficient. Each should contain a list of scripts, relative
 to WRKSRC, 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 REPLACE_BASH, don't forget to add bash to 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.4.2. Missing atomic functions
 When building for older machine architectures (e.g., i386, PowerPC), builds may
 fail because the package expects modern 64-bit atomic functions which the
 underlying hardware either doesn't support, or will only support with specific
 compiler flags. This is generally handled via inclusion of mk/atomic64.mk.
 .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
 $ cd pkgname
 $ cvs add DESCR Makefile PLIST distinfo buildlink3.mk patches
 $ cvs add patches/p*
 $ cvs status | less
 $ cvs commit
 $ cd ..
 $ vi Makefile # add SUBDIRS+=pkgname line
 $ cvs commit Makefile
 $ cd pkgname
 $ make CTYPE=Added commit-changes-entry
 The commit message of the initial import should include part of the DESCR file,
 so people reading the mailing lists know what the package is/does.
 Also mention the new package in pkgsrc/doc/CHANGES-20xx.
 Previously, "cvs import" was suggested, but it was much easier to get wrong
 than "cvs add".
 .6. Updating a package to a newer version
 Please always put a concise, appropriate and relevant summary of the changes
 between old and new versions into the commit log when updating a package. There
 are various reasons for this:
   * A URL is volatile, and can change over time. It may go away completely or
     its information may be overwritten by newer information.
   * Having the change information between old and new versions in our CVS
     repository is very useful for people who use either cvs or anoncvs.
   * Having the change information between old and new versions in our CVS
     repository is very useful for people who read the pkgsrc-changes mailing
     list, so that they can make tactical decisions about when to upgrade the
     package.
 Please also recognize that, just because a new version of a package has been
 released, it should not automatically be upgraded in the CVS repository. We
 prefer to be conservative in the packages that are included in pkgsrc -
 development or beta packages are not really the best thing for most places in
 which pkgsrc is used. Please use your judgement about what should go into
 pkgsrc, and bear in mind that stability is to be preferred above new and
 possibly untested features.
 .7. Renaming a package in pkgsrc
 Renaming packages is not recommended.
 When renaming packages, be sure to fix any references to the old name in other
 Makefiles, options, buildlink files, etc.
 Also, when renaming a package, please add the package name and version pattern
 (s) of the previous package to SUPERSEDES. This may be repeated for multiple
 renames. The new package would be an exact replacement. Example:
 SUPERSEDES+=    p5-IO-Compress-Zlib<2.017
 SUPERSEDES+=    optcomp-[0-9]*
 Note that "successor" in the CHANGES-YYYY file doesn't necessarily mean that it
 supersedes, as that successor may not be an exact replacement but is a
 suggestion for the replaced functionality.
 .8. Moving a package in pkgsrc
 It is preferred that packages are not renamed or moved, but if needed please
 follow these steps.
 . Make a copy of the directory somewhere else.
 . Remove all CVS dirs.
     Alternatively to the first two steps you can also do:
     % cvs -d user@cvs.NetBSD.org:/cvsroot export -D today pkgsrc/category/package
     and use that for further work.
 . Fix CATEGORIES and any DEPENDS paths that just did "../package" instead of
     "../../category/package".
 . In the modified package's Makefile, consider setting PREV_PKGPATH to the
     previous category/package pathname. The PREV_PKGPATH can be used by tools
     for doing an update using pkgsrc building; for example, it can search the
     pkg_summary(5) database for PREV_PKGPATH (if no SUPERSEDES) and then use
     the corresponding new PKGPATH for that moved package. Note that it may have
     multiple matches, so the tool should also check on the PKGBASE too. The
     PREV_PKGPATH probably has no value unless SUPERSEDES is not set, i.e.
     PKGBASE stays the same.
 . cvs import the modified package in the new place.
 . Check if any package depends on it:
     % cd /usr/pkgsrc
     % grep /package */*/Makefile* */*/buildlink*
 . Fix paths in packages from step 5 to point to new location.
 . cvs rm (-f) the package at the old location.
 . Remove from oldcategory/Makefile.
 . Add to newcategory/Makefile.
 . Commit the changed and removed files:
     % cvs commit oldcategory/package oldcategory/Makefile newcategory/Makefile
     (and any packages from step 5, of course).
 Chapter 24. Frequently Asked Questions
 This section contains the answers to questions that may arise when you are
 writing a package. If you don't find your question answered here, first have a
 look in the other chapters, and if you still don't have the answer, ask on the
 pkgsrc-users mailing list.
 .1. What is the difference between MAKEFLAGS, .MAKEFLAGS and MAKE_FLAGS?
 .2. What is the difference between MAKE, GMAKE and MAKE_PROGRAM?
 .3. What is the difference between CC, PKG_CC and PKGSRC_COMPILER?
 .4. Why does make show-var VARNAME=BUILDLINK_PREFIX.foo say it's empty?
 .5. What does ${MASTER_SITE_SOURCEFORGE:=package/} mean? I don't understand
     the := inside it.
 .6. Which mailing lists are there for package developers?
 .7. Where is the pkgsrc documentation?
 .8. I have a little time to kill. What shall I do?
 .1. What is the difference between MAKEFLAGS, .MAKEFLAGS and MAKE_FLAGS?
       MAKEFLAGS are the flags passed to the pkgsrc-internal invocations of make
       (1).
       MAKE_FLAGS are the flags that are passed to the MAKE_PROGRAM when
       building the package.
       .MAKEFLAGS is an internal variable of bmake and should not be used by
       packages.
 .2. What is the difference between MAKE, GMAKE and MAKE_PROGRAM?
       MAKE is the path to the make(1) program that is used in the pkgsrc
       infrastructure.
       GMAKE is the path to GNU Make, but you need to say USE_TOOLS+=gmake to
       use that.
       MAKE_PROGRAM is the path to the Make program that is used for building
       the package.
 .3. What is the difference between CC, PKG_CC and PKGSRC_COMPILER?
       CC is the path to the real C compiler, which can be configured by the
       pkgsrc user.
       PKG_CC is the path to the compiler wrapper.
       PKGSRC_COMPILER is not a path to a compiler, but the type of compiler
       that should be used. See mk/compiler.mk for more information about the
       latter variable.
 .4. Why does make show-var VARNAME=BUILDLINK_PREFIX.foo say it's empty?
       For optimization reasons, some variables are only available in the "
       wrapper" phase and later. To "simulate" the wrapper phase, append
       PKG_PHASE=wrapper to the above command.
 .5. What does ${MASTER_SITE_SOURCEFORGE:=package/} mean? I don't understand
       the := inside it.
       The := is not an assignment operator, even though it may look like one.
       Instead, it is a degenerate form of ${LIST:old_string=new_string}, which
       is documented in the make(1) man page and which is commonly used in the
       form ${SRCS:.c=.o}. In the case of MASTER_SITE_*, old_string is the empty
       string and new_string is package/. That's where the : and the = fall
       together.
 .6. Which mailing lists are there for package developers?
       tech-pkg
           This is a list for technical discussions related to pkgsrc
           development, e.g. soliciting feedback for changes to pkgsrc
           infrastructure, proposed new features, questions related to porting
           pkgsrc to a new platform, advice for maintaining a package, patches
           that affect many packages, help requests moved from pkgsrc-users when
           an infrastructure bug is found, etc.
       pkgsrc-bugs
           All bug reports in category "pkg" sent with send-pr(1) appear here.
           Please do not report your bugs here directly; use one of the other
           mailing lists.
 .7. Where is the pkgsrc documentation?
       There are many places where you can find documentation about pkgsrc:
         * The pkgsrc guide (this document) is a collection of chapters that
           explain large parts of pkgsrc, but some chapters tend to be outdated.
           Which ones they are is hard to say.
         * On the mailing list archives (see https://mail-index.NetBSD.org/),
           you can find discussions about certain features, announcements of new
           parts of the pkgsrc infrastructure and sometimes even announcements
           that a certain feature has been marked as obsolete. The benefit here
           is that each message has a date appended to it.
         * Many of the files in the mk/ directory start with a comment that
           describes the purpose of the file and how it can be used by the
           pkgsrc user and package authors. An easy way to find this
           documentation is to run bmake help.
         * The CVS log messages are a rich source of information, but they tend
           to be highly abbreviated, especially for actions that occur often.
           Some contain a detailed description of what has changed, but they are
           geared towards the other pkgsrc developers, not towards an average
           pkgsrc user. They also only document changes, so if you don't know
           what has been before, these messages may not be worth too much to
           you.
         * Some parts of pkgsrc are only "implicitly documented", that is the
           documentation exists only in the mind of the developer who wrote the
           code. To get this information, use the cvs annotate command to see
           who has written it and ask on the tech-pkg mailing list, so that
           others can find your questions later (see above). To be sure that the
           developer in charge reads the mail, you may CC him or her.
 .8. I have a little time to kill. What shall I do?
       This is not really an FAQ yet, but here's the answer anyway.
         * Run pkg_chk -N (from the pkgtools/pkg_chk package). It will tell you
           about newer versions of installed packages that are available, but
           not yet updated in pkgsrc.
         * Browse pkgsrc/doc/TODO -- it contains a list of suggested new
           packages and a list of cleanups and enhancements for pkgsrc that
           would be nice to have.
         * Review packages for which review was requested on the tech-pkg
           mailing list.
 Part III. The pkgsrc infrastructure internals
 This part of the guide deals with everything from the infrastructure that is
 behind the interfaces described in the developer's guide. A casual package
 maintainer should not need anything from this part.
 Table of Contents
 . Design of the pkgsrc infrastructure
 .1. The meaning of variable definitions
 .2. Avoiding problems before they arise
 .3. Variable evaluation
 .3.1. At load time
 .3.2. At runtime
 .4. How can variables be specified?
 .5. Designing interfaces for Makefile fragments
 .5.1. Procedures with parameters
 .5.2. Actions taken on behalf of parameters
 .6. The order in which files are loaded
 .6.1. The order in bsd.prefs.mk
 .6.2. The order in bsd.pkg.mk
 . Regression tests
 .1. Running the regression tests
 .2. Adding a new regression test
 .2.1. Overridable functions
 .2.2. Helper functions
 . Porting pkgsrc
 .1. Porting pkgsrc to a new operating system
 Chapter 25. Design of the pkgsrc infrastructure
 @@ -8577,1821 +8591,1787 @@ 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                   CHANGES
-CHECKOUT_DATE                        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           COMPILER_RPATH_FLAG
 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
+CURSES_TYPE                          CXX
-CVS_MODULE                           CVS_PROJECT
+CYRUS_GROUP                          CYRUS_IDLE
-CVS_REPOSITORIES                     CVS_ROOT
+CYRUS_USER                           DAEMONTOOLS_GROUP
-CVS_ROOT_GNU                         CVS_ROOT_NONGNU
+DAEMONTOOLS_LOG_USER                 DARWIN_NO_SYSTEM_LIBS
-CVS_ROOT_SOURCEFORGE                 CVS_TAG
+DARWIN_REQUIRES_FILTER               DBUS_GROUP
-CXX                                  CYRUS_GROUP
+DBUS_USER                            DEFANG_GROUP
-CYRUS_IDLE                           CYRUS_USER
+DEFANG_USER                          DEFAULT_ACCEPTABLE_LICENSES
-DAEMONTOOLS_GROUP                    DAEMONTOOLS_LOG_USER
+DEFAULT_DISTFILES                    DEFAULT_IRC_SERVER
-DARWIN_NO_SYSTEM_LIBS                DARWIN_REQUIRES_FILTER
+DEFAULT_SERIAL_DEVICE                DEF_UMASK
-DBUS_GROUP                           DBUS_USER
+DEINSTALLDEPENDS                     DEINSTALL_SRC
-DEFANG_GROUP                         DEFANG_USER
+DEINSTALL_TEMPLATES                  DELAYED_ERROR_MSG
-DEFAULT_ACCEPTABLE_LICENSES          DEFAULT_DISTFILES
+DELAYED_WARNING_MSG                  DEPENDS
-DEFAULT_IRC_SERVER                   DEFAULT_SERIAL_DEVICE
+DEPENDS_TARGET                       DEPENDS_TYPE
-DEF_UMASK                            DEINSTALLDEPENDS
+DESTDIR                              DESTDIR_VARNAME
-DEINSTALL_SRC                        DEINSTALL_TEMPLATES
+DIALER_GROUP                         DIGEST_REQD
-DELAYED_ERROR_MSG                    DELAYED_WARNING_MSG
+DISTDIR                              DISTFILES
-DEPENDS                              DEPENDS_TARGET
+DISTINFO_FILE                        DISTNAME
-DEPENDS_TYPE                         DESTDIR
+DIST_PATH                            DIST_SUBDIR
-DESTDIR_VARNAME                      DIALER_GROUP
+DJBDNS_AXFR_USER                     DJBDNS_CACHE_USER
-DIGEST_REQD                          DISTDIR
+DJBDNS_DJBDNS_GROUP                  DJBDNS_LOG_USER
-DISTFILES                            DISTINFO_FILE
+DJBDNS_RBL_USER                      DJBDNS_TINY_USER
-DISTNAME                             DIST_PATH
+DLOPEN_REQUIRE_PTHREADS              DL_AUTO_VARS
-DIST_SUBDIR                          DJBDNS_AXFR_USER
+DL_CFLAGS                            DL_LDFLAGS
-DJBDNS_CACHE_USER                    DJBDNS_DJBDNS_GROUP
+DL_LIBS                              DNS
-DJBDNS_LOG_USER                      DJBDNS_RBL_USER
+DOCOWN                               DOWNLOADED_DISTFILE
-DJBDNS_TINY_USER                     DLOPEN_REQUIRE_PTHREADS
+DQCACHE_GROUP                        DQCACHE_USER
-DL_AUTO_VARS                         DL_CFLAGS
+DT_LAYOUT                            DYNAMIC_SITES_CMD
-DL_LDFLAGS                           DL_LIBS
+DYNAMIC_SITES_SCRIPT                 ECHO
-DNS                                  DOCOWN
+ECHO_N                               ELK_GUI
-DOWNLOADED_DISTFILE                  DQCACHE_GROUP
+EMACS_TYPE                           EMULDIR
-DQCACHE_USER                         DT_LAYOUT
+EMULSUBDIR                           EMULSUBDIRSLASH
-DYNAMIC_SITES_CMD                    DYNAMIC_SITES_SCRIPT
+EMUL_ARCH                            EMUL_DISTRO
-ECHO                                 ECHO_N
+EMUL_EXEC_FMT                        EMUL_IS_NATIVE
-ELK_GUI                              EMACS_TYPE
+EMUL_MODULES                         EMUL_OPSYS
-EMULDIR                              EMULSUBDIR
+EMUL_PKG_FMT                         EMUL_PLATFORM
-EMULSUBDIRSLASH                      EMUL_ARCH
+EMUL_PLATFORMS                       EMUL_PREFER
-EMUL_DISTRO                          EMUL_EXEC_FMT
+EMUL_REQD                            EMUL_TYPE
-EMUL_IS_NATIVE                       EMUL_MODULES
+ERROR_MSG                            EXIM_GROUP
-EMUL_OPSYS                           EMUL_PKG_FMT
+EXIM_USER                            EXPORT_SYMBOLS_LDFLAGS
-EMUL_PLATFORM                        EMUL_PLATFORMS
+EXTRACTOR                            EXTRACT_CMD
-EMUL_PREFER                          EMUL_REQD
+EXTRACT_CMD_DEFAULT                  EXTRACT_DIR
-EMUL_TYPE                            ERROR_MSG
+EXTRACT_ELEMENTS                     EXTRACT_ENV
-EXIM_GROUP                           EXIM_USER
+EXTRACT_ONLY                         EXTRACT_OPTS
-EXPORT_SYMBOLS_LDFLAGS               EXTRACTOR
+EXTRACT_SUFX                         EXTRACT_USING
-EXTRACT_CMD                          EXTRACT_CMD_DEFAULT
+FAIL                                 FAILOVER_FETCH
-EXTRACT_DIR                          EXTRACT_ELEMENTS
+FAIL_MSG                             FAKE_NCURSES
-EXTRACT_ENV                          EXTRACT_ONLY
+FAM                                  FAM_ACCEPTED
-EXTRACT_OPTS                         EXTRACT_SUFX
+FAM_DEFAULT                          FAM_SERVER
-EXTRACT_USING                        FAIL
+FCPATH                               FEATURE_CPPFLAGS
-FAILOVER_FETCH                       FAIL_MSG
+FEATURE_LDFLAGS                      FEATURE_LIBS
-FAKE_NCURSES                         FAM
+FETCH_AFTER_ARGS                     FETCH_BEFORE_ARGS
-FAM_ACCEPTED                         FAM_DEFAULT
+FETCH_CMD                            FETCH_OUTPUT_ARGS
-FAM_SERVER                           FCPATH
+FETCH_PROXY                          FETCH_RESUME_ARGS
-FEATURE_CPPFLAGS                     FEATURE_LDFLAGS
+FETCH_TIMEOUT                        FETCH_USE_IPV4_ONLY
-FEATURE_LIBS                         FETCH_AFTER_ARGS
+FETCH_USING                          FILES_SUBST
-FETCH_BEFORE_ARGS                    FETCH_CMD
+FILES_SUBST_SED                      FIX_SYSTEM_HEADERS
 FETCH_OUTPUT_ARGS                    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
+FOO_HACKS_MK                         FOX_USE_XUNICODE
 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_RELEASE                       GITLAB_SUBMODULES
 GITLAB_TAG                           GITLAB_TYPE
-GIT_BRANCH                           GIT_ENV
+GNU                                  GNU_CONFIGURE
-GIT_EXTRACTDIR                       GIT_REPO
+GNU_CONFIGURE_INFODIR                GNU_CONFIGURE_MANDIR
-GIT_REPOSITORIES                     GIT_REVISION
+GNU_CONFIGURE_QUIET                  GNU_CONFIGURE_STRICT
-GIT_TAG                              GNU
+GODEP_REDIRECTS                      GO_BUILD_PATTERN
-GNU_CONFIGURE                        GNU_CONFIGURE_INFODIR
+GO_DEPS                              GO_DIST_BASE
-GNU_CONFIGURE_MANDIR                 GNU_CONFIGURE_QUIET
+GO_EXTRA_MOD_DIRS                    GO_MODULE_FILES
-GNU_CONFIGURE_STRICT                 GODEP_REDIRECTS
+GO_SRCPATH                           GO_VERSION_DEFAULT
-GO_BUILD_PATTERN                     GO_DEPS
+GROUP_SPECIFIC_PKGS                  GRUB_NETWORK_CARDS
-GO_DIST_BASE                         GO_EXTRA_MOD_DIRS
+GRUB_PRESET_COMMAND                  GRUB_SCAN_ARGS
-GO_MODULE_FILES                      GO_SRCPATH
+GZIP                                 HASKELL_ENABLE_DYNAMIC_EXECUTABLE
 GO_VERSION_DEFAULT                   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                              HG_REPOSITORIES
+HOMEPAGE                             HOST_PKGTOOLS_ARGS
-HG_TAG                               HOMEPAGE
+HOST_SPECIFIC_PKGS                   HOWL_GROUP
-HOST_PKGTOOLS_ARGS                   HOST_SPECIFIC_PKGS
+HOWL_USER                            ICCBASE
-HOWL_GROUP                           HOWL_USER
+ICECAST_CHROOTDIR                    ICON_THEMES
-ICCBASE                              ICECAST_CHROOTDIR
+IDOBASE                              IGNORE_CCACHE
-ICON_THEMES                          IDOBASE
+IGNORE_INFO_DIRS                     IGNORE_INTERACTIVE_FETCH
-IGNORE_CCACHE                        IGNORE_INFO_DIRS
+IMAKE                                IMAKEOPTS
-IGNORE_INTERACTIVE_FETCH             IMAKE
+IMAKE_MAKE                           IMAKE_MANINSTALL
-IMAKEOPTS                            IMAKE_MAKE
+IMAP_UW_CCLIENT_MBOX_FMT             IMDICTDIR
-IMAKE_MANINSTALL                     IMAP_UW_CCLIENT_MBOX_FMT
+INCOMPAT_CURSES                      INFO_DIR
-IMDICTDIR                            INCOMPAT_CURSES
+INFO_FILES                           INFO_FILES_VERBOSE
-INFO_DIR                             INFO_FILES
+INFO_MSG                             INIT_SYSTEM
-INFO_FILES_VERBOSE                   INFO_MSG
+INN_DATA_DIR                         INN_GROUP
-INIT_SYSTEM                          INN_DATA_DIR
+INN_USER                             INSTALLATION_DIRS
-INN_GROUP                            INN_USER
+INSTALLATION_DIRS_FROM_PLIST         INSTALL_ENV
-INSTALLATION_DIRS                    INSTALLATION_DIRS_FROM_PLIST
+INSTALL_SH_OVERRIDE                  INSTALL_SRC
-INSTALL_ENV                          INSTALL_SH_OVERRIDE
+INSTALL_TEMPLATES                    INSTALL_UNSTRIPPED
-INSTALL_SRC                          INSTALL_TEMPLATES
+IRCD_HYBRID_IRC_GROUP                IRCD_HYBRID_IRC_USER
-INSTALL_UNSTRIPPED                   IRCD_HYBRID_IRC_GROUP
+IRCD_HYBRID_MAXCONN                  IRCD_HYBRID_NICLEN
-IRCD_HYBRID_IRC_USER                 IRCD_HYBRID_MAXCONN
+IRCD_HYBRID_SYSLOG_EVENTS            IRCD_HYBRID_SYSLOG_FACILITY
-IRCD_HYBRID_NICLEN                   IRCD_HYBRID_SYSLOG_EVENTS
+IRCD_HYBRID_TOPICLEN                 IRIX
-IRCD_HYBRID_SYSLOG_FACILITY          IRCD_HYBRID_TOPICLEN
+IRRD_USE_PGP                         JABBERD_GROUP
-IRIX                                 IRRD_USE_PGP
+JABBERD_LOGDIR                       JABBERD_PIDDIR
-JABBERD_GROUP                        JABBERD_LOGDIR
+JABBERD_SPOOLDIR                     JABBERD_USER
-JABBERD_PIDDIR                       JABBERD_SPOOLDIR
+JAVA_BINPREFIX                       JAVA_CLASSPATH
-JABBERD_USER                         JAVA_APP_PATH
+JAVA_HOME                            JAVA_LD_LIBRARY_PATH
-JAVA_APP_TARGETS                     JAVA_BINPREFIX
+JAVA_NAME                            JAVA_UNLIMIT
-JAVA_CLASSPATH                       JAVA_HOME
+JAVA_WRAPPERS                        JPEG_ACCEPTED
-JAVA_LD_LIBRARY_PATH                 JAVA_NAME
+JPEG_DEFAULT                         KERBEROS
-JAVA_UNLIMIT                         JAVA_WRAPPERS
+KERMIT_SUID_UUCP                     KJS_USE_PCRE
-JPEG_ACCEPTED                        JPEG_DEFAULT
+KNEWS_DOMAIN_FILE                    KNEWS_DOMAIN_NAME
-KERBEROS                             KERMIT_SUID_UUCP
+KRB5_ACCEPTED                        KRB5_DEFAULT
-KJS_USE_PCRE                         KNEWS_DOMAIN_FILE
+LANGUAGES                            LAPACKE_LIBS
-KNEWS_DOMAIN_NAME                    KRB5_ACCEPTED
+LAPACK_LIBS                          LATEX2HTML_ICONPATH
-KRB5_DEFAULT                         LANGUAGES
+LDCONFIG_ADD_CMD                     LDCONFIG_REMOVE_CMD
-LAPACKE_LIBS                         LAPACK_LIBS
+LDD                                  LEAFNODE_DATA_DIR
-LATEX2HTML_ICONPATH                  LDCONFIG_ADD_CMD
+LEAFNODE_GROUP                       LEAFNODE_USER
-LDCONFIG_REMOVE_CMD                  LDD
+LIBDVDCSS_HOMEPAGE                   LIBDVDCSS_MASTER_SITES
-LEAFNODE_DATA_DIR                    LEAFNODE_GROUP
+LIBRSVG_TYPE                         LIBTOOL
-LEAFNODE_USER                        LIBDVDCSS_HOMEPAGE
+LIBTOOLIZE_PLIST                     LIBTOOL_M4_OVERRIDE
-LIBDVDCSS_MASTER_SITES               LIBRSVG_TYPE
+LIBUSB_TYPE                          LICENSE
-LIBTOOL                              LIBTOOLIZE_PLIST
+LINKER_RPATH_FLAG                    LINK_RPATH_FLAG
 LIBTOOL_M4_OVERRIDE                  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                     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                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_TOPKG                      OMF
 ONLY_FOR_COMPILER                    ONLY_FOR_PLATFORM
 OPENSSH_CHROOT                       OPENSSH_GROUP
 OPENSSH_USER                         OPSYS
 OPSYS_EMULDIR                        OPSYS_VERSION
 OS                                   OSS_TYPE
 OSX                                  OSX_TOLERATE_SDK_SKEW
 OS_HAVE_ALSA                         OS_HAVE_RCD
 OS_VARIANT                           OS_VERSION
 OTF_FONTS_DIR                        OVERRIDE_DIRDEPTH
 OVERRIDE_GEMSPEC                     OVERRIDE_GNU_CONFIG_SCRIPTS
-OVERRIDE_ROCKSPEC                    OWN_DIRS
+OWN_DIRS                             OWN_DIRS_PERMS
-OWN_DIRS_PERMS                       P4GROUP
+P4GROUP                              P4PORT
-P4PORT                               P4ROOT
+P4ROOT                               P4USER
-P4USER                               PACKAGES
+PACKAGES                             PALMOS_DEFAULT_SDK
-PALMOS_DEFAULT_SDK                   PAMBASE
+PAMBASE                              PAM_DEFAULT
-PAM_DEFAULT                          PAPERSIZE
+PAPERSIZE                            PASSIVE_FETCH
-PASSIVE_FETCH                        PATCHDIR
+PATCHDIR                             PATCHFILES
-PATCHFILES                           PATCH_ARGS
+PATCH_ARGS                           PATCH_DEBUG
-PATCH_DEBUG                          PATCH_DIST_ARGS
+PATCH_DIST_ARGS                      PATCH_DIST_CAT
-PATCH_DIST_CAT                       PATCH_DIST_STRIP
+PATCH_DIST_STRIP                     PATCH_FUZZ_FACTOR
-PATCH_FUZZ_FACTOR                    PATCH_STRIP
+PATCH_STRIP                          PATH
-PATH                                 PCCBASE
+PCCBASE                              PEAR_CMD
-PEAR                                 PEAR_CHANNEL
+PEAR_LIB                             PEAR_PACKAGE_XML
-PEAR_CHANNEL_ALIAS                   PEAR_CHANNEL_VERSION
+PERL5                                PERL5_CONFIGURE
-PEAR_CMD                             PEAR_LIB
+PERL5_CONFIGURE_DIRS                 PERL5_LDFLAGS
-PEAR_PACKAGE_XML                     PERL5
+PERL5_LICENSE                        PERL5_MODULE_TYPE
-PERL5_CONFIGURE                      PERL5_CONFIGURE_DIRS
+PERL5_PACKLIST                       PERL5_PACKLIST_DIR
-PERL5_LDFLAGS                        PERL5_LICENSE
+PERL5_PERLBASE                       PERL5_SITEBASE
-PERL5_MODULE_TYPE                    PERL5_PACKLIST
+PERL5_USE_PACKLIST                   PERL5_VENDORBASE
-PERL5_PACKLIST_DIR                   PERL5_PERLBASE
+PFCTL                                PFVAR_H
-PERL5_SITEBASE                       PERL5_USE_PACKLIST
+PF_VERSION                           PGGROUP
-PERL5_VENDORBASE                     PFCTL
+PGHOME                               PGPKGSRCDIR
-PFVAR_H                              PF_VERSION
+PGSQL_TYPE                           PGSQL_VERSION
-PGGROUP                              PGHOME
+PGSQL_VERSIONS_ACCEPTED              PGSQL_VERSION_DEFAULT
-PGPKGSRCDIR                          PGSQL_TYPE
+PGUSER                               PG_LIB_EXT
-PGSQL_VERSION                        PGSQL_VERSIONS_ACCEPTED
+PHP                                  PHPCOMMON_MK
-PGSQL_VERSION_DEFAULT                PGUSER
+PHPPKGSRCDIR                         PHP_BASE_VERS
-PG_LIB_EXT                           PHP
+PHP_CHECK_INSTALLED                  PHP_EXTENSION_DIR
-PHPCOMMON_MK                         PHPPKGSRCDIR
+PHP_INITIAL_TEENY                    PHP_PKG_PREFIX
-PHP_BASE_VERS                        PHP_CHECK_INSTALLED
+PHP_VERSION                          PHP_VERSIONS_ACCEPTED
-PHP_EXTENSION_DIR                    PHP_INITIAL_TEENY
+PHP_VERSIONS_INCOMPATIBLE            PHP_VERSION_DEFAULT
-PHP_PKG_PREFIX                       PHP_VERSION
+PHP_VERSION_REQD                     PILRC_USE_GTK
-PHP_VERSIONS_ACCEPTED                PHP_VERSIONS_INCOMPATIBLE
+PKGCONFIG_BASE                       PKGCONFIG_FILE
-PHP_VERSION_DEFAULT                  PHP_VERSION_REQD
+PKGCONFIG_OVERRIDE                   PKGCONFIG_OVERRIDE_STAGE
-PILRC_USE_GTK                        PKGCONFIG_BASE
+PKGDIR                               PKGGNUDIR
-PKGCONFIG_FILE                       PKGCONFIG_OVERRIDE
+PKGINFODIR                           PKGLOCALEDIR
-PKGCONFIG_OVERRIDE_STAGE             PKGDIR
+PKGMANDIR                            PKGNAME
-PKGGNUDIR                            PKGINFODIR
+PKGNAME_REQD                         PKGPATH
-PKGLOCALEDIR                         PKGMANDIR
+PKGREVISION                          PKGSRC_BLAS_TYPES
-PKGNAME                              PKGNAME_REQD
+PKGSRC_CHANGES                       PKGSRC_COMPILER
-PKGPATH                              PKGREVISION
+PKGSRC_KEEP_BIN_PKGS                 PKGSRC_LOCKTYPE
-PKGSRC_BLAS_TYPES                    PKGSRC_CHANGES
+PKGSRC_MAKE_ENV                      PKGSRC_MESSAGE_RECIPIENTS
-PKGSRC_COMPILER                      PKGSRC_KEEP_BIN_PKGS
+PKGSRC_MKPIE                         PKGSRC_MKREPRO
-PKGSRC_LOCKTYPE                      PKGSRC_MAKE_ENV
+PKGSRC_OVERRIDE_MKPIE                PKGSRC_RUN_TEST
-PKGSRC_MESSAGE_RECIPIENTS            PKGSRC_MKPIE
+PKGSRC_SETENV                        PKGSRC_SLEEPSECS
-PKGSRC_MKREPRO                       PKGSRC_OVERRIDE_MKPIE
+PKGSRC_TODO                          PKGSRC_USE_CTF
-PKGSRC_RUN_TEST                      PKGSRC_SETENV
+PKGSRC_USE_FORTIFY                   PKGSRC_USE_MKTOOLS
-PKGSRC_SLEEPSECS                     PKGSRC_TODO
+PKGSRC_USE_RELRO                     PKGSRC_USE_SSP
-PKGSRC_USE_CTF                       PKGSRC_USE_FORTIFY
+PKGSRC_USE_STACK_CHECK               PKGTASKS_DATAFILE
-PKGSRC_USE_MKTOOLS                   PKGSRC_USE_RELRO
+PKGTOOLS_ARGS                        PKGTOOLS_ENV
-PKGSRC_USE_SSP                       PKGSRC_USE_STACK_CHECK
+PKG_ALTERNATIVES                     PKG_APACHE
-PKGTASKS_DATAFILE                    PKGTOOLS_ARGS
+PKG_APACHE_ACCEPTED                  PKG_APACHE_DEFAULT
-PKGTOOLS_ENV                         PKG_ALTERNATIVES
+PKG_BEST_EXISTS                      PKG_BUILD_OPTIONS
-PKG_APACHE                           PKG_APACHE_ACCEPTED
+PKG_COMPRESSION                      PKG_CONFIG
-PKG_APACHE_DEFAULT                   PKG_BEST_EXISTS
+PKG_CONFIG_PERMS                     PKG_CREATE_USERGROUP
-PKG_BUILD_OPTIONS                    PKG_COMPRESSION
+PKG_DB_TMPDIR                        PKG_DEBUG_LEVEL
-PKG_CONFIG                           PKG_CONFIG_PERMS
+PKG_DEFAULT_OPTIONS                  PKG_DESTDIR_SUPPORT
-PKG_CREATE_USERGROUP                 PKG_DB_TMPDIR
+PKG_DEVELOPER                        PKG_DISABLED_OPTIONS
-PKG_DEBUG_LEVEL                      PKG_DEFAULT_OPTIONS
+PKG_FATAL_ERRORS                     PKG_FC
-PKG_DESTDIR_SUPPORT                  PKG_DEVELOPER
+PKG_FILELIST_CMD                     PKG_GECOS
-PKG_DISABLED_OPTIONS                 PKG_FATAL_ERRORS
+PKG_GID                              PKG_GROUPS
-PKG_FC                               PKG_FILELIST_CMD
+PKG_GROUPS_VARS                      PKG_HOME
-PKG_GECOS                            PKG_GID
+PKG_INIT_SCRIPTS                     PKG_JAVA_HOME
-PKG_GROUPS                           PKG_GROUPS_VARS
+PKG_JVM                              PKG_JVMS_ACCEPTED
-PKG_HOME                             PKG_INIT_SCRIPTS
+PKG_JVM_DEFAULT                      PKG_LEGACY_OPTIONS
-PKG_JAVA_HOME                        PKG_JVM
+PKG_LIBTOOL                          PKG_MKSYMLINKS
-PKG_JVMS_ACCEPTED                    PKG_JVM_DEFAULT
+PKG_OPTIONS                          PKG_OPTIONS_DEPRECATED_WARNINGS
-PKG_LEGACY_OPTIONS                   PKG_LIBTOOL
+PKG_OPTIONS_LEGACY_OPTS              PKG_OPTIONS_LEGACY_VARS
-PKG_MKSYMLINKS                       PKG_OPTIONS
+PKG_OPTIONS_NONEMPTY_SETS            PKG_OPTIONS_OPTIONAL_GROUPS
-PKG_OPTIONS_DEPRECATED_WARNINGS      PKG_OPTIONS_LEGACY_OPTS
+PKG_OPTIONS_REQUIRED_GROUPS          PKG_OPTIONS_VAR
-PKG_OPTIONS_LEGACY_VARS              PKG_OPTIONS_NONEMPTY_SETS
+PKG_PHP                              PKG_PHP_MAJOR_VERS
-PKG_OPTIONS_OPTIONAL_GROUPS          PKG_OPTIONS_REQUIRED_GROUPS
+PKG_PHP_VERSION                      PKG_RCD_SCRIPTS
-PKG_OPTIONS_VAR                      PKG_PHP
+PKG_REFCOUNT_DBDIR                   PKG_REGISTER_SHELLS
-PKG_PHP_MAJOR_VERS                   PKG_PHP_VERSION
+PKG_RESUME_TRANSFERS                 PKG_SHELL
-PKG_RCD_SCRIPTS                      PKG_REFCOUNT_DBDIR
+PKG_SUGGESTED_OPTIONS                PKG_SUPPORTED_OPTIONS
-PKG_REGISTER_SHELLS                  PKG_RESUME_TRANSFERS
+PKG_SYSCONFBASE                      PKG_SYSCONFBASEDIR
-PKG_SHELL                            PKG_SUGGESTED_OPTIONS
+PKG_SYSCONFDIR                       PKG_SYSCONFDIR_PERMS
-PKG_SUPPORTED_OPTIONS                PKG_SYSCONFBASE
+PKG_SYSCONFSUBDIR                    PKG_SYSCONFVAR
-PKG_SYSCONFBASEDIR                   PKG_SYSCONFDIR
+PKG_TOOLS_BIN                        PKG_UID
-PKG_SYSCONFDIR_PERMS                 PKG_SYSCONFSUBDIR
+PKG_UPDATE_FONTS_DB                  PKG_USERS
-PKG_SYSCONFVAR                       PKG_TOOLS_BIN
+PKG_USERS_VARS                       PKG_VERBOSE
-PKG_UID                              PKG_UPDATE_FONTS_DB
+PLEASE                               PLIST
-PKG_USERS                            PKG_USERS_VARS
+PLIST_AWK                            PLIST_AWK_ENV
-PKG_VERBOSE                          PLEASE
+PLIST_SRC                            PLIST_SUBST
-PLIST                                PLIST_AWK
+PLIST_TYPE                           PLIST_VARS
-PLIST_AWK_ENV                        PLIST_SRC
+POPTOP_USE_MPPE                      POSSIBLE_GFORTRAN_VERSION
-PLIST_SUBST                          PLIST_TYPE
+POST_FETCH_HOOK                      PREFER
-PLIST_VARS                           POPTOP_USE_MPPE
+PREFER_NATIVE                        PREFER_NATIVE_PTHREADS
-POSSIBLE_GFORTRAN_VERSION            POST_FETCH_HOOK
+PREFER_PKGSRC                        PREFIX
-PREFER                               PREFER_NATIVE
+PREPEND_PATH                         PRE_ROOT_CMD
-PREFER_NATIVE_PTHREADS               PREFER_PKGSRC
+PRIVILEGED_STAGES                    PS
-PREFIX                               PREPEND_PATH
+PTHREAD_AUTO_VARS                    PTHREAD_CFLAGS
-PRE_ROOT_CMD                         PRIVILEGED_STAGES
+PTHREAD_LDFLAGS                      PTHREAD_LIBS
-PS                                   PTHREAD_AUTO_VARS
+PTHREAD_OPTS                         PTHREAD_TYPE
-PTHREAD_CFLAGS                       PTHREAD_LDFLAGS
+PVM_SSH                              PYPKGPREFIX
-PTHREAD_LIBS                         PTHREAD_OPTS
+PYTHON_FOR_BUILD_ONLY                PYTHON_SELF_CONFLICT
-PTHREAD_TYPE                         PVM_SSH
+PYTHON_VERSIONED_DEPENDENCIES        PYTHON_VERSIONS_ACCEPTED
-PYPKGPREFIX                          PYTHON_FOR_BUILD_ONLY
+PYTHON_VERSIONS_INCOMPATIBLE         PYTHON_VERSION_DEFAULT
-PYTHON_SELF_CONFLICT                 PYTHON_VERSIONED_DEPENDENCIES
+PYTHON_VERSION_REQD                  PYVERSSUFFIX
-PYTHON_VERSIONS_ACCEPTED             PYTHON_VERSIONS_INCOMPATIBLE
+QMAILDIR                             QMAIL_ALIAS_USER
-PYTHON_VERSION_DEFAULT               PYTHON_VERSION_REQD
+QMAIL_DAEMON_USER                    QMAIL_LOG_USER
-PYVERSSUFFIX                         QMAILDIR
+QMAIL_NOFILES_GROUP                  QMAIL_PASSWD_USER
-QMAIL_ALIAS_USER                     QMAIL_DAEMON_USER
+QMAIL_QMAIL_GROUP                    QMAIL_QUEUE_DIR
-QMAIL_LOG_USER                       QMAIL_NOFILES_GROUP
+QMAIL_QUEUE_EXTRA                    QMAIL_QUEUE_USER
-QMAIL_PASSWD_USER                    QMAIL_QMAIL_GROUP
+QMAIL_REMOTE_USER                    QMAIL_ROOT_USER
-QMAIL_QUEUE_DIR                      QMAIL_QUEUE_EXTRA
+QMAIL_SEND_USER                      QORE_LATEST_MODULE_API
-QMAIL_QUEUE_USER                     QMAIL_REMOTE_USER
+QORE_MODULE_API                      QORE_MODULE_DIR
-QMAIL_ROOT_USER                      QMAIL_SEND_USER
+QORE_USER_MODULE_DIR                 QORE_VERSION
-QORE_LATEST_MODULE_API               QORE_MODULE_API
+QPOPPER_FAC                          QPOPPER_SPOOL_DIR
-QORE_MODULE_DIR                      QORE_USER_MODULE_DIR
+QPOPPER_USER                         RAKE_NAME
-QORE_VERSION                         QPOPPER_FAC
+RASMOL_DEPTH                         RCD_SCRIPTS
-QPOPPER_SPOOL_DIR                    QPOPPER_USER
+RCD_SCRIPTS_DIR                      RCD_SCRIPTS_EXAMPLEDIR
-RAKE_NAME                            RASMOL_DEPTH
+RCD_SCRIPTS_MODE                     RCD_SCRIPTS_SHELL
-RCD_DIR                              RCD_ORDER
+RCD_SCRIPT_SRC                       RDOC
 RCD_SCRIPTS                          RCD_SCRIPTS_DIR
 RCD_SCRIPTS_EXAMPLEDIR               RCD_SCRIPTS_MODE
 RCD_SCRIPTS_SHELL                    RCD_SCRIPT_SRC
 RCD_SUBR                             RDOC
 READLINE_DEFAULT                     READLINE_TYPE
 REAL_ROOT_GROUP                      REAL_ROOT_USER
 RECURSIVE_MAKE                       RELAY_CTRL_DIR
 RELRO_SUPPORTED                      REPLACE_AWK
 REPLACE_BASH                         REPLACE_CSH
 REPLACE_KSH                          REPLACE_LUA
 REPLACE_NODEJS                       REPLACE_OCTAVE
 REPLACE_PERL                         REPLACE_PERL6
 REPLACE_PHP                          REPLACE_PYTHON
 REPLACE_QORE                         REPLACE_R
 REPLACE_RUBY                         REPLACE_RUBY_DIRS
 REPLACE_RUBY_PAT                     REPLACE_SH
 REPLACE_TEXLUA                       REPLACE_WISH
 REQD_DIRS                            REQD_DIRS_PERMS
 REQD_FILES                           REQD_FILES_MODE
 REQD_FILES_PERMS                     RESOLV_AUTO_VARS
 RESOLV_LDFLAGS                       RESOLV_LIBS
-RM                                   ROCKSPEC_NAME
+RM                                   ROOT_CMD
 ROCKSPEC_SPECFILE                    ROOT_CMD
 ROOT_GROUP                           ROOT_USER
 RPCGEN                               RPM
 RPM2PKG_PLIST                        RPM2PKG_PREFIX
 RPM2PKG_STAGE                        RPM2PKG_STRIP
 RPM2PKG_SUBPREFIX                    RPMFILES
 RPMIGNOREPATH                        RPM_DB_PREFIX
 RSSH_CVS_PATH                        RSSH_RDIST_PATH
 RSSH_RSYNC_PATH                      RSSH_SCP_PATH
 RSSH_SFTP_SERVER_PATH                RUBY
 RUBYGEM                              RUBYGEM_NAME
 RUBYGEM_OPTIONS                      RUBYGEM_VERBOSE
 RUBY_ABI_VERSION                     RUBY_ARCH
 RUBY_ARCHINC                         RUBY_ARCHLIB
 RUBY_BASE                            RUBY_BASERIDIR
 RUBY_BUILD_DOCUMENT                  RUBY_DLEXT
 RUBY_DOC                             RUBY_DYNAMIC_DIRS
 RUBY_EG                              RUBY_ENCODING_ARG
 RUBY_EXTCONF                         RUBY_EXTCONF_CHECK
 RUBY_EXTCONF_DEBUG                   RUBY_EXTCONF_MAKEFILE
 RUBY_GEM_ARCH                        RUBY_GEM_BASE
 RUBY_INC                             RUBY_LIB
 RUBY_LIB_BASE                        RUBY_NAME
 RUBY_NOVERSION                       RUBY_PKGPREFIX
 RUBY_RAILS                           RUBY_RAILS52_VERSION
 RUBY_RAILS60_VERSION                 RUBY_RAILS61_VERSION
 RUBY_RAILS70_VERSION                 RUBY_RAILS_ACCEPTED
 RUBY_RAILS_DEFAULT                   RUBY_RAILS_REQD
 RUBY_RAILS_STRICT_DEP                RUBY_RIDIR
 RUBY_SETUP                           RUBY_SHLIB
 RUBY_SHLIBALIAS                      RUBY_SHLIBVER
 RUBY_SIMPLE_INSTALL                  RUBY_SITEARCHLIB
 RUBY_SITELIB                         RUBY_SITELIB_BASE
 RUBY_SITERIDIR                       RUBY_SLEXT
 RUBY_SRCDIR                          RUBY_STATICLIB
 RUBY_SUFFIX                          RUBY_SYSRIDIR
 RUBY_USE_PTHREAD                     RUBY_VENDORARCHLIB
 RUBY_VENDORLIB                       RUBY_VENDORLIB_BASE
 RUBY_VER                             RUBY_VERSION
 RUBY_VERSIONS_ACCEPTED               RUBY_VERSIONS_INCOMPATIBLE
 RUBY_VERSION_DEFAULT                 RUBY_VERSION_REQD
 RUBY_VER_DIR                         RUN
 RUN_LDCONFIG                         RUST_TYPE
 SCO                                  SCREWS_GROUP
 SCREWS_USER                          SCRIPTS_ENV
 SCROLLKEEPER_DATADIR                 SCROLLKEEPER_REBUILDDB
 SCROLLKEEPER_UPDATEDB                SDIST_PAWD
 SDL12_TYPE                           SERIAL_DEVICES
 SETGIDGAME                           SETGID_GAMES_PERMS
 SETUID_ROOT_PERMS                    SH
-SHLIB                                SHORTNAME
+SHLIB                                SIGN_PACKAGES
-SIGN_PACKAGES                        SILC_CLIENT_WITH_PERL
+SILC_CLIENT_WITH_PERL                SITE_SPECIFIC_PKGS
-SITE_SPECIFIC_PKGS                   SKIP_DEPENDS
+SKIP_DEPENDS                         SMF_INSTANCES
-SMF_INSTANCES                        SMF_MANIFEST
+SMF_MANIFEST                         SMF_METHODS
-SMF_METHODS                          SMF_METHOD_SHELL
+SMF_METHOD_SHELL                     SMF_METHOD_SRC
-SMF_METHOD_SRC                       SMF_NAME
+SMF_NAME                             SMF_PREFIX
-SMF_PREFIX                           SMF_SRCDIR
+SMF_SRCDIR                           SNIPROXY_GROUP
-SNIPROXY_GROUP                       SNIPROXY_USER
+SNIPROXY_USER                        SOURCE_BUFFSIZE
-SOURCE_BUFFSIZE                      SPECIAL_PERMS
+SPECIAL_PERMS                        SPECIFIC_PKGS
-SPECIFIC_PKGS                        SSH_SUID
+SSH_SUID                             SSP_SUPPORTED
-SSP_SUPPORTED                        SSYNC_PAWD
+SSYNC_PAWD                           STEP_MSG
-STEP_MSG                             STRIP
+STRIP                                STRIP_DBG
-STRIP_DBG                            STRIP_DEBUG
+STRIP_DEBUG                          STRIP_DEBUG_SUPPORTED
-STRIP_DEBUG_SUPPORTED                STRIP_FILES_SKIP
+STRIP_FILES_SKIP                     SU
-SU                                   SUBDIR
+SUBDIR                               SUBST
-SUBST                                SUBST_CLASSES
+SUBST_CLASSES                        SUBST_FILES
-SUBST_FILES                          SUBST_FILTER_CMD
+SUBST_FILTER_CMD                     SUBST_MESSAGE
-SUBST_MESSAGE                        SUBST_NOOP_OK
+SUBST_NOOP_OK                        SUBST_SED
-SUBST_SED                            SUBST_SHOW_DIFF
+SUBST_SHOW_DIFF                      SUBST_SKIP_TEXT_CHECK
-SUBST_SKIP_TEXT_CHECK                SUBST_STAGE
+SUBST_STAGE                          SUBST_VARS
-SUBST_VARS                           SUNWSPROBASE
+SUNWSPROBASE                         SUSE_PREFER
-SUSE_PREFER                          SU_CMD
+SU_CMD                               SYSCONFBASE
-SVN_EXTRACTDIR                       SVN_REPO
+TARGET_ARCH                          TBL
-SVN_REPOSITORIES                     SVN_REVISION
+TERMCAP_TYPE                         TERMINFO_DEFAULT
-SYSCONFBASE                          TARGET_ARCH
+TERMINFO_TYPE                        TEST
-TBL                                  TERMCAP_TYPE
+TEST_DEPENDS                         TEST_DIRS
-TERMINFO_DEFAULT                     TERMINFO_TYPE
+TEST_ENV                             TEST_ENV_SHELL
-TEST                                 TEST_DEPENDS
+TEST_MAKE_CMD                        TEST_MAKE_FLAGS
-TEST_DIRS                            TEST_ENV
+TEST_TARGET                          TEXLIVE_IGNORE_PATTERNS
-TEST_ENV_SHELL                       TEST_MAKE_CMD
+TEXLIVE_REV                          TEXLIVE_UNVERSIONED
-TEST_MAKE_FLAGS                      TEST_TARGET
+TEXMFSITE                            TEX_FORMATS
-TEXLIVE_IGNORE_PATTERNS              TEXLIVE_REV
+TEX_HYPHEN_DAT                       TEX_HYPHEN_DEF
-TEXLIVE_UNVERSIONED                  TEXMFSITE
+TEX_TEXMF_DIRS                       THTTPD_LOG_FACILITY
-TEX_FORMATS                          TEX_HYPHEN_DAT
+TINYDYN_USER                         TLSWRAPPER_CHROOT
-TEX_HYPHEN_DEF                       TEX_TEXMF_DIRS
+TO                                   TOOLS_ALIASES
-THTTPD_LOG_FACILITY                  TINYDYN_USER
+TOOLS_ALWAYS_WRAP                    TOOLS_ARGS
-TLSWRAPPER_CHROOT                    TO
+TOOLS_BROKEN                         TOOLS_CMD
-TOOLS_ALIASES                        TOOLS_ALWAYS_WRAP
+TOOLS_CMDLINE_SED                    TOOLS_CREATE
-TOOLS_ARGS                           TOOLS_BROKEN
+TOOLS_CROSS_DESTDIR                  TOOLS_DIR
-TOOLS_CMD                            TOOLS_CMDLINE_SED
+TOOLS_FAIL                           TOOLS_GNU_MISSING
-TOOLS_CREATE                         TOOLS_CROSS_DESTDIR
+TOOLS_LDCONFIG                       TOOLS_NOOP
-TOOLS_DIR                            TOOLS_FAIL
+TOOLS_PATH                           TOOLS_SCRIPT
-TOOLS_GNU_MISSING                    TOOLS_LDCONFIG
+TOOLS_USE_CROSS_COMPILE              TOOL_DEPENDS
 TOOLS_NOOP                           TOOLS_PATH
 TOOLS_SCRIPT                         TOOLS_USE_CROSS_COMPILE
 TOOL_DEPENDS                         TTF_FONTDIR
 TTF_FONTS_DIR                        TYPE
 UAC_REQD_EXECS                       UCSPI_SSL_GROUP
 UCSPI_SSL_USER                       UNLIMIT_RESOURCES
 UNPRIVILEGED                         UNPRIVILEGED_GROUP
 UNPRIVILEGED_GROUPS                  UNPRIVILEGED_USER
 UNWRAP_FILES                         UNWRAP_PATTERNS
 UPDATE_GEMSPEC                       UPDATE_TARGET
 URI                                  USERGROUP_PHASE
 USERPPP_GROUP                        USER_SPECIFIC_PKGS
 USE_ABI_DEPENDS                      USE_APR
 USE_BSD_MAKEFILE                     USE_BUILTIN
 USE_CROSS_COMPILE                    USE_CURSES
 USE_CWRAPPERS                        USE_DB185
 USE_FEATURES                         USE_GAMESGROUP
 USE_GCC_RUNTIME                      USE_IMAKE
 USE_JAVA                             USE_JAVA2
 USE_LANGUAGES                        USE_LIBTOOL
 USE_NATIVE_GCC                       USE_NETBSD_REPO
 USE_PKGSRC_GCC                       USE_PKGSRC_GCC_RUNTIME
 USE_PKGTASKS                         USE_PKG_ADMIN_DIGEST
 USE_RUBY_EXTCONF                     USE_RUBY_INSTALL
 USE_RUBY_SETUP                       USE_RUBY_SETUP_PKG
 USE_TOOLS                            UUCP_GROUP
 UUCP_USER                            VARBASE
 VARNAME                              VIM_EXTRA_OPTS
 WARNING_MSG                          WCALC_CGIDIR
 WCALC_CGIPATH                        WCALC_HTMLDIR
 WCALC_HTMLPATH                       WDM_MANAGERS
 WRAPPER_CC                           WRAPPER_REORDER_CMDS
 WRKDIR                               WRKDIR_BASENAME
 WRKDIR_LOCKTYPE                      WRKLOG
 WRKOBJDIR                            WRKSRC
 X10_PORT                             X11
 X11BASE                              X11_PKGSRCDIR
 X11_TYPE                             X509_CERTIFICATE
 X509_KEY                             XAW_TYPE
 XLOCK_DEFAULT_MODE                   XMKMF
 XMKMF_FLAGS                          XXX
-XXXX                                 YES
+YES                                  ZSH_STATIC
-ZSH_STATIC                           __stdc__
+__stdc__                             _vargroups
-_vargroups                           accept
+accept                               acquire-localbase-lock
-acquire-localbase-lock               acquire-lock
+acquire-lock                         add
-add                                  added
+added                                administrator
-administrator                        alloca
+alloca                               alternatives
-alternatives                         aslr
+aslr                                 asprintf
-asprintf                             atlas
+atlas                                autoconf
-autoconf                             automake
+automake                             autoreconf
-autoreconf                           awk
+awk                                  bash
-bash                                 big-endian
+big-endian                           bin-install
-bin-install                          bind
+bind                                 binpkg-list
-binpkg-list                          blas
+blas                                 bootstrap-depends
-bootstrap-depends                    broken
+broken                               broken_on_platform
-broken_on_platform                   bsd
+bsd                                  bsd.prog.mk
-bsd.prog.mk                          build
+build                                build-env
-build-env                            buildlink-directories
+buildlink-directories                buildlink-oss-soundcard-h
-buildlink-oss-soundcard-h            c
+c                                    c++
-c++                                  ccache
+ccache                               cce
-cce                                  cdefs
+cdefs                                ceil
-ceil                                 changes
+changes                              changes-entry
-changes-entry                        changes-entry-noupdate
+changes-entry-noupdate               check
-check                                check-clean
+check-clean                          check-files
-check-files                          check-files-clean
+check-files-clean                    check-vulnerable
-check-vulnerable                     checksum
+checksum                             checksum-phase
-checksum-phase                       clean
+clean                                clean-depends
-clean-depends                        cleandir
+cleandir                             commit
-commit                               commit-changes-entry
+commit-changes-entry                 compact
-compact                              compiler
+compiler                             conf
-conf                                 config.guess
+config.guess                         config.sub
-config.sub                           configuration
+configuration                        configure
-configure                            configure-env
+configure-env                        configure-help
-configure-help                       configure_args
+configure_args                       connect
-connect                              cos
+cos                                  cputime
-cputime                              create-usergroup
+create-usergroup                     csh
-csh                                  ctf
+ctf                                  debug
 cvs                                  debug
 declaration                          declare
 defined                              depend
 dependencies                         depends
 depends-checksum                     depends-fetch
 deps                                 describe
 destdir                              disable
 distclean                            distinfo
 dl                                   dlopen
 do-buildlink                         do-clean
 do-configure                         do-configure-post-hook
 do-extract                           do-fetch
 do-install                           emul
 emul-distinfo                        emul-fetch
 emulation                            emulator
 enable                               endian
-endif                                enomem
+enomem                               ensurepip
-ensurepip                            err
+err                                  errx
-errx                                 etc
+etc                                  exp
-exp                                  extract-rpm
+extract-rpm                          fabs
-fabs                                 feature
+feature                              features
-features                             fetch
+fetch                                fetch-list
-fetch-list                           follows
+follows                              forbids
-forbids                              form
+form                                 format
-format                               fortify
+fortify                              fortify_source
 fortify_source                       fossil
 friend                               fts
 fts_close                            fts_open
 fts_read                             fts_set
 gcc                                  gethostbyaddr
 gethostbyname                        gethostbyname2
 getopt_long                          getprogname
 getservbyname                        getservbyport
 getservent                           gettext
-git                                  github
+github                               gitlab
-gitlab                               glob
+glob                                 gnu
-gnu                                  gnu_configure_strict
+gnu_configure_strict                 go
-go                                   go-deps
+go-deps                              golang
-golang                               guess-license
+guess-license                        hashbang
-hashbang                             heimdal
+heimdal                              help
 help                                 hg
 imake                                increment
 indirect                             inet_aton
 interp                               interpreter
 intl                                 ip4
 ip6                                  ipv4
 ipv6                                 iso
 kerberos                             krb
 krb5                                 ksh
 lapack                               latex
 libintl_bindtextdomain               libintl_gettext
 libintl_textdomain                   libnbcompat
 libs                                 libtool
 licence                              license
 lintl                                little-endian
 lock                                 locking
 lua                                  lvalue
 make                                 makesum
-memory                               mercurial
+memory                               meta
-meta                                 meta-package
+meta-package                         meta_package
-meta_package                         mit-krb5
+mit-krb5                             mk.conf
-mk.conf                              mkl
+mkl                                  mount
-mount                                move
+move                                 moved
-moved                                mprotect
+mprotect                             mremap
-mremap                               nb
+nb                                   nbcompat
-nbcompat                             netlib
+netlib                               node
-node                                 node.js
+node.js                              nodejs
-nodejs                               obstack
+obstack                              obstack_ptr_grow
-obstack_ptr_grow                     occurs
+occurs                               only
-only                                 openblas
+openblas                             options
-options                              options.mk
+options.mk                           order
-order                                override
+override                             override-intltool
-override-intltool                    override-message-intltool
+override-message-intltool            package
-package                              parallel
+parallel                             path
-path                                 pax
+pax                                  paxctl
-paxctl                               pbulk-index
+pbulk-index                          pc
-pc                                   perl
+perl                                 perl5
-perl5                                perms
+perms                                php
-php                                  pkg-build-options
+pkg-build-options                    pkg-config
-pkg-config                           pkg_build_options
+pkg_build_options                    platform
-platform                             plist
+plist                                post-extract
-post-extract                         post-fetch
+post-fetch                           post-wrapper
-post-wrapper                         pre-build-checks-hook
+pre-build-checks-hook                pre-configure
-pre-configure                        pre-configure-checks-hook
+pre-configure-checks-hook            pre-extract
-pre-extract                          pre-fetch
+pre-fetch                            print-go-deps
-print-go-deps                        print-plist
+print-plist                          print-summary-data
-print-summary-data                   privileged-install-hook
+privileged-install-hook              pypi
-pypi                                 python
+python                               r
-r                                    readme-all
+readme-all                           recursive
-recursive                            recv
+recv                                 recvfrom
-recvfrom                             regcomp
+regcomp                              release-localbase-lock
-release-localbase-lock               release-lock
+release-lock                         relro
-relro                                remove
+remove                               removed
-removed                              rename
+rename                               renamed
-renamed                              reorder
+reorder                              replace
-replace                              replace_interpreter
+replace_interpreter                  reproducible
-reproducible                         resolv
+resolv                               root
-root                                 ruby
+ruby                                 send
-send                                 sendfile
+sendfile                             sendto
-sendto                               setenv
+setenv                               setgid
-setgid                               setprogname
+setprogname                          setuid
-setuid                               sh
+sh                                   shebang
-shebang                              show
+show                                 show-all
-show-all                             show-build-defs
+show-build-defs                      show-depends
-show-depends                         show-depends-dirs
+show-depends-dirs                    show-depends-pkgpaths
-show-depends-pkgpaths                show-depends-recursive
+show-depends-recursive               show-deps
-show-deps                            show-distfiles
+show-distfiles                       show-downlevel
-show-downlevel                       show-subdir-var
+show-subdir-var                      show-tools
-show-tools                           show-var
+show-var                             show-vars
-show-vars                            snprintf
+snprintf                             socket
-socket                               ssp
+ssp                                  st_mode
-st_mode                              stage-install
+stage-install                        strcasestr
-strcasestr                           strict
+strict                               strip
-strip                                strndup
+strndup                              strnlen
-strnlen                              strsep
+strsep                               subst
-subst                                substitutions
+substitutions                        sun
 subversion                           sun
 sunpro                               sunwspro
-svn                                  symlink
+symlink                              test
-test                                 test-env
+test-env                             tex
-tex                                  texlive
+texlive                              tmp
-tmp                                  todo
+todo                                 tool
-tool                                 tools
+tools                                tools-libtool-m4-override
-tools-libtool-m4-override            transitive
+transitive                           type
-type                                 ulimit
+ulimit                               undefined
-undefined                            undo-replace
+undo-replace                         unlimit
-unlimit                              unprivileged
+unprivileged                         unprivileged-install-hook
-unprivileged-install-hook            unstripped
+unstripped                           update
-update                               updated
+updated                              upload
-upload                               upload-distfiles
+upload-distfiles                     use_tools
-use_tools                            user
+user                                 utimes
-utimes                               vasprintf
+vasprintf                            verbose
-verbose                              vsnprintf
+vsnprintf                            warn
-warn                                 warning
+warning                              warnings
-warnings                             warnx
+warnx                                wattr_off
-wattr_off                            wattr_on
+wattr_on                             work
-work                                 wrapper
+wrapper                              wrkdir
 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.