 @@ -1,3449 +1,3388 @@
 <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
 <html>
 <head>
 <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
 <title>The pkgsrc guide</title>
 <link rel="stylesheet" type="text/css" href="/global.css">
 <meta name="generator" content="DocBook XSL Stylesheets VX.X.X">
 <meta name="description" content="pkgsrc is a centralized package management system for Unix-like operating systems. This guide provides information for users and developers of pkgsrc. It covers installation of binary and source packages, creation of binary and source packages and a high-level overview about the infrastructure.">
 </head>
 <body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="book">
 <div class="titlepage">
 <div>
 <div><h1 class="title">
 <a name="the-pkgsrc-guide"></a>The pkgsrc guide</h1></div>
 <div><h2 class="subtitle">Documentation on the NetBSD packages system</h2></div>
 <div><div class="authorgroup">
 <div class="author">
 <h3 class="author">
 <span class="firstname">Alistair</span> <span class="surname">Crooks</span>
 </h3>
 <div class="affiliation"><div class="address"><p><code class="email">&lt;<a class="email" href="mailto:agc@NetBSD.org">agc@NetBSD.org</a>&gt;</code></p></div></div>
 </div>
 <div class="author">
 <h3 class="author">
 <span class="firstname">Hubert</span> <span class="surname">Feyrer</span>
 </h3>
 <div class="affiliation"><div class="address"><p><code class="email">&lt;<a class="email" href="mailto:hubertf@NetBSD.org">hubertf@NetBSD.org</a>&gt;</code></p></div></div>
 </div>
 <h3 class="corpauthor">
         The pkgsrc Developers
       </h3>
 </div></div>
 <div><p class="copyright">Copyright © 1994-2020 The NetBSD Foundation, Inc</p></div>
 <div><p class="pubdate">$NetBSD: pkgsrc.xml,v 1.36 2020/01/03 15:55:24 leot Exp $</p></div>
 <div><div class="abstract">
 <p class="title"><b>Abstract</b></p>
 <p>pkgsrc is a centralized package management system for
 	Unix-like operating systems. This guide provides information for
 	users and developers of pkgsrc. It covers installation of binary
 	and source packages, creation of binary and source packages and
 	a high-level overview about the infrastructure.</p>
 </div></div>
 </div>
 <hr>
 </div>
 <div class="toc">
 <p><b>Table of Contents</b></p>
 <dl class="toc">
 <dt><span class="chapter"><a href="#introduction">1. What is pkgsrc?</a></span></dt>
 <dd><dl>
 <dt><span class="sect1"><a href="#introduction-section">1.1. Introduction</a></span></dt>
 <dd><dl>
 <dt><span class="sect2"><a href="#why-pkgsrc">1.1.1. Why pkgsrc?</a></span></dt>
 <dt><span class="sect2"><a href="#intro.platforms">1.1.2. Supported platforms</a></span></dt>
 </dl></dd>
 <dt><span class="sect1"><a href="#overview">1.2. Overview</a></span></dt>
 <dt><span class="sect1"><a href="#terminology">1.3. Terminology</a></span></dt>
 <dd><dl><dt><span class="sect2"><a href="#term.roles">1.3.1. Roles involved in pkgsrc</a></span></dt></dl></dd>
 <dt><span class="sect1"><a href="#typography">1.4. Typography</a></span></dt>
 </dl></dd>
 <dt><span class="part"><a href="#users-guide">I. The pkgsrc user's guide</a></span></dt>
 <dd><dl>
 <dt><span class="chapter"><a href="#help-user">2. Getting help</a></span></dt>
 <dt><span class="chapter"><a href="#getting">3. Where to get pkgsrc and how to keep it up-to-date</a></span></dt>
 <dd><dl>
 <dt><span class="sect1"><a href="#getting-first">3.1. Getting pkgsrc for the first time</a></span></dt>
 <dd><dl>
 <dt><span class="sect2"><a href="#getting-via-tar">3.1.1. As tar archive</a></span></dt>
 <dt><span class="sect2"><a href="#getting-via-cvs">3.1.2. Via anonymous CVS</a></span></dt>
 </dl></dd>
 <dt><span class="sect1"><a href="#uptodate">3.2. Keeping pkgsrc up-to-date</a></span></dt>
 <dd><dl>
 <dt><span class="sect2"><a href="#uptodate-tar">3.2.1. Via tar files</a></span></dt>
 <dt><span class="sect2"><a href="#uptodate-cvs">3.2.2. Via CVS</a></span></dt>
 </dl></dd>
 </dl></dd>
 <dt><span class="chapter"><a href="#platforms">4. Using pkgsrc on systems other than NetBSD</a></span></dt>
 <dd><dl>
 <dt><span class="sect1"><a href="#binarydist">4.1. Binary distribution</a></span></dt>
 <dt><span class="sect1"><a href="#bootstrapping-pkgsrc">4.2. Bootstrapping pkgsrc</a></span></dt>
 </dl></dd>
 <dt><span class="chapter"><a href="#using">5. Using pkgsrc</a></span></dt>
 <dd><dl>
 <dt><span class="sect1"><a href="#using-pkg">5.1. Using binary packages</a></span></dt>
 <dd><dl>
 <dt><span class="sect2"><a href="#finding-binary-packages">5.1.1. Finding binary packages</a></span></dt>
 <dt><span class="sect2"><a href="#installing-binary-packages">5.1.2. Installing binary packages</a></span></dt>
 <dt><span class="sect2"><a href="#using.pkg_delete">5.1.3. Deinstalling packages</a></span></dt>
 <dt><span class="sect2"><a href="#using.pkg_info">5.1.4. Getting information about installed packages</a></span></dt>
 <dt><span class="sect2"><a href="#vulnerabilities">5.1.5. Checking for security vulnerabilities in installed packages</a></span></dt>
 <dt><span class="sect2"><a href="#pkg_versions">5.1.6. Finding if newer versions of your installed packages are in pkgsrc</a></span></dt>
 <dt><span class="sect2"><a href="#using.pkg_admin">5.1.7. Other administrative functions</a></span></dt>
 </dl></dd>
 <dt><span class="sect1"><a href="#building-packages-from-source">5.2. Building packages from source</a></span></dt>
 <dd><dl>
 <dt><span class="sect2"><a href="#requirements">5.2.1. Requirements</a></span></dt>
 <dt><span class="sect2"><a href="#fetching-distfiles">5.2.2. Fetching distfiles</a></span></dt>
 <dt><span class="sect2"><a href="#how-to-build-and-install">5.2.3. How to build and install</a></span></dt>
 </dl></dd>
 </dl></dd>
 <dt><span class="chapter"><a href="#configuring">6. Configuring pkgsrc</a></span></dt>
 <dd><dl>
 <dt><span class="sect1"><a href="#general-configuration">6.1. General configuration</a></span></dt>
 <dt><span class="sect1"><a href="#variables-affecting-build">6.2. Variables affecting the build process</a></span></dt>
 <dt><span class="sect1"><a href="#variables-affecting-installation">6.3. Variables affecting the installation process</a></span></dt>
 <dt><span class="sect1"><a href="#conf.compiler">6.4. Selecting and configuring the compiler</a></span></dt>
 <dd><dl>
 <dt><span class="sect2"><a href="#selecting-the-compiler">6.4.1. Selecting the compiler</a></span></dt>
 <dt><span class="sect2"><a href="#conf.cflags">6.4.2. Additional flags to the compiler (<code class="varname">CFLAGS</code>)</a></span></dt>
 <dt><span class="sect2"><a href="#conf.ldflags">6.4.3. Additional flags to the linker (<code class="varname">LDFLAGS</code>)</a></span></dt>
 </dl></dd>
 <dt><span class="sect1"><a href="#developer-advanced-settings">6.5. Developer/advanced settings</a></span></dt>
 <dt><span class="sect1"><a href="#selecting-build-options">6.6. Selecting Build Options</a></span></dt>
 </dl></dd>
 <dt><span class="chapter"><a href="#binary">7. Creating binary packages</a></span></dt>
 <dd><dl>
 <dt><span class="sect1"><a href="#building-a-single-binary-package">7.1. Building a single binary package</a></span></dt>
 <dt><span class="sect1"><a href="#settings-for-creationg-of-binary-packages">7.2. Settings for creation of binary packages</a></span></dt>
 </dl></dd>
 <dt><span class="chapter"><a href="#bulk">8. Creating binary packages for everything in pkgsrc (bulk
 builds)</a></span></dt>
 <dd><dl>
 <dt><span class="sect1"><a href="#bulk.pre">8.1. Preparations</a></span></dt>
 <dt><span class="sect1"><a href="#bulk.pbulk">8.2. Running a pbulk-style bulk build</a></span></dt>
 <dd><dl><dt><span class="sect2"><a href="#bulk.pbulk.conf">8.2.1. Configuration</a></span></dt></dl></dd>
 <dt><span class="sect1"><a href="#bulk.req">8.3. Requirements of a full bulk build</a></span></dt>
 <dt><span class="sect1"><a href="#bulk.var">8.4. Bulk build variants</a></span></dt>
 <dd><dl>
-<dt><span class="sect2"><a href="#bulk.var.subst_noop">8.4.1. Strict SUBST blocks</a></span></dt>
+<dt><span class="sect2"><a href="#bulk.var.confopt">8.4.1. Detect unknown configure options</a></span></dt>
-<dt><span class="sect2"><a href="#bulk.var.confopt">8.4.2. Detect unknown configure options</a></span></dt>
+<dt><span class="sect2"><a href="#bulk.var.comperr">8.4.2. Detect classes of bugs by forcing compiler warnings</a></span></dt>
-<dt><span class="sect2"><a href="#bulk.var.comperr">8.4.3. Detect classes of bugs by forcing compiler warnings</a></span></dt>
+<dt><span class="sect2"><a href="#bulk.var.dirs">8.4.3. Use custom directories</a></span></dt>
-<dt><span class="sect2"><a href="#bulk.var.dirs">8.4.4. Use custom directories</a></span></dt>
+<dt><span class="sect2"><a href="#bulk.var.warn">8.4.4. Turn warnings into errors</a></span></dt>
-<dt><span class="sect2"><a href="#bulk.var.warn">8.4.5. Turn warnings into errors</a></span></dt>
+<dt><span class="sect2"><a href="#bulk.var.pkglint">8.4.5. Reject packages for which pkglint reports errors</a></span></dt>
-<dt><span class="sect2"><a href="#bulk.var.pkglint">8.4.6. Reject packages for which pkglint reports errors</a></span></dt>
+<dt><span class="sect2"><a href="#bulk.var.strings">8.4.6. Reject packages that contain forbidden strings</a></span></dt>
-<dt><span class="sect2"><a href="#bulk.var.strings">8.4.7. Reject packages that contain forbidden strings</a></span></dt>
+<dt><span class="sect2"><a href="#bulk.var.test">8.4.7. Reject packages whose self-test fails</a></span></dt>
-<dt><span class="sect2"><a href="#bulk.var.test">8.4.8. Reject packages whose self-test fails</a></span></dt>
+<dt><span class="sect2"><a href="#bulk.var.shvar">8.4.8. Reject packages that use undefined shell variables</a></span></dt>
-<dt><span class="sect2"><a href="#bulk.var.shvar">8.4.9. Reject packages that use undefined shell variables</a></span></dt>
+<dt><span class="sect2"><a href="#bulk.var.quiet">8.4.9. Turn off verbose logging</a></span></dt>
 <dt><span class="sect2"><a href="#bulk.var.quiet">8.4.10. Turn off verbose logging</a></span></dt>
 <dt><span class="sect2"><a href="#bulk.var.options">8.4.11. Select random sets of options</a></span></dt>
 <dt><span class="sect2"><a href="#bulk.var.build_defs">8.4.12. Select random configurations of BUILD_DEFS</a></span></dt>
 </dl></dd>
 <dt><span class="sect1"><a href="#creating-cdroms">8.5. Creating a multiple CD-ROM packages collection</a></span></dt>
 <dd><dl><dt><span class="sect2"><a href="#cdpack-example">8.5.1. Example of cdpack</a></span></dt></dl></dd>
 </dl></dd>
 <dt><span class="chapter"><a href="#files">9. Directory layout of the installed files</a></span></dt>
 <dd><dl>
 <dt><span class="sect1"><a href="#files.localbase">9.1. File system layout in <code class="literal">${LOCALBASE}</code></a></span></dt>
 <dt><span class="sect1"><a href="#files.varbase">9.2. File system layout in <code class="literal">${VARBASE}</code></a></span></dt>
 </dl></dd>
 <dt><span class="chapter"><a href="#faq">10. Frequently Asked Questions</a></span></dt>
 <dd><dl>
 <dt><span class="sect1"><a href="#mailing-list-pointers">10.1. Are there any mailing lists for pkg-related discussion?</a></span></dt>
 <dt><span class="sect1"><a href="#faq-pkgtools">10.2. Utilities for package management (pkgtools)</a></span></dt>
 <dt><span class="sect1"><a href="#non-root-pkgsrc">10.3. How to use pkgsrc as non-root</a></span></dt>
 <dt><span class="sect1"><a href="#resume-transfers">10.4. How to resume transfers when fetching distfiles?</a></span></dt>
 <dt><span class="sect1"><a href="#x.org-from-pkgsrc">10.5. How can I install/use modular X.org from pkgsrc?</a></span></dt>
 <dt><span class="sect1"><a href="#fetch-behind-firewall">10.6. How to fetch files from behind a firewall</a></span></dt>
 <dt><span class="sect1"><a href="#fetch-https">10.7. How to fetch files from HTTPS sites</a></span></dt>
 <dt><span class="sect1"><a href="#passive-ftp">10.8. How do I tell <span class="command"><strong>make fetch</strong></span> to do passive FTP?</a></span></dt>
 <dt><span class="sect1"><a href="#fetching-all-distfiles">10.9. How to fetch all distfiles at once</a></span></dt>
 <dt><span class="sect1"><a href="#tmac.andoc-missing">10.10. What does <span class="quote">&#8220;<span class="quote">Don't know how to make
 /usr/share/tmac/tmac.andoc</span>&#8221;</span> mean?</a></span></dt>
 <dt><span class="sect1"><a href="#bsd.own.mk-missing">10.11. What does <span class="quote">&#8220;<span class="quote">Could not find bsd.own.mk</span>&#8221;</span> mean?</a></span></dt>
 <dt><span class="sect1"><a href="#using-sudo-with-pkgsrc">10.12. Using 'sudo' with pkgsrc</a></span></dt>
 <dt><span class="sect1"><a href="#faq.conf">10.13. How do I change the location of configuration files?</a></span></dt>
 <dt><span class="sect1"><a href="#audit-packages">10.14. Automated security checks</a></span></dt>
 <dt><span class="sect1"><a href="#ufaq-cflags">10.15. Why do some packages ignore my <code class="varname">CFLAGS</code>?</a></span></dt>
 <dt><span class="sect1"><a href="#ufaq-fail">10.16. A package does not build.  What shall I do?</a></span></dt>
 <dt><span class="sect1"><a href="#faq.rcs-conflicts">10.17. What does <span class="quote">&#8220;<span class="quote">Makefile appears to contain unresolved cvs/rcs/??? merge conflicts</span>&#8221;</span> mean?</a></span></dt>
 </dl></dd>
 </dl></dd>
 <dt><span class="part"><a href="#developers-guide">II. The pkgsrc developer's guide</a></span></dt>
 <dd><dl>
 <dt><span class="chapter"><a href="#help-devel">11. Getting help</a></span></dt>
 <dt><span class="chapter"><a href="#creating">12. Creating a new pkgsrc package from scratch</a></span></dt>
 <dd><dl>
 <dt><span class="sect1"><a href="#creating.common">12.1. Common types of packages</a></span></dt>
 <dd><dl>
 <dt><span class="sect2"><a href="#creating.perl-module">12.1.1. Perl modules</a></span></dt>
 <dt><span class="sect2"><a href="#creating.python-module">12.1.2. Python modules and programs</a></span></dt>
 <dt><span class="sect2"><a href="#creating.R-package">12.1.3. R packages</a></span></dt>
 <dt><span class="sect2"><a href="#creating.TeX-package">12.1.4. TeXlive packages</a></span></dt>
 </dl></dd>
 <dt><span class="sect1"><a href="#creating.examples">12.2. Examples</a></span></dt>
 <dd><dl><dt><span class="sect2"><a href="#creating.nvu">12.2.1. How the www/nvu package came into pkgsrc</a></span></dt></dl></dd>
 </dl></dd>
 <dt><span class="chapter"><a href="#components">13. Package components - files, directories and contents</a></span></dt>
 <dd><dl>
 <dt><span class="sect1"><a href="#components.Makefile">13.1. <code class="filename">Makefile</code></a></span></dt>
 <dt><span class="sect1"><a href="#components.distinfo">13.2. <code class="filename">distinfo</code></a></span></dt>
 <dt><span class="sect1"><a href="#components.patches">13.3. <code class="filename">patches/*</code></a></span></dt>
 <dd><dl>
 <dt><span class="sect2"><a href="#components.patch.structure">13.3.1. Structure of a single patch file</a></span></dt>
 <dt><span class="sect2"><a href="#components.patches.caveats">13.3.2. Creating patch files</a></span></dt>
 <dt><span class="sect2"><a href="#components.patches.sources">13.3.3. Sources where the patch files come from</a></span></dt>
 <dt><span class="sect2"><a href="#components.patches.guidelines">13.3.4. Patching guidelines</a></span></dt>
 <dt><span class="sect2"><a href="#components.patches.feedback">13.3.5. Feedback to the author</a></span></dt>
 </dl></dd>
 <dt><span class="sect1"><a href="#other-mandatory-files">13.4. Other mandatory files</a></span></dt>
 <dt><span class="sect1"><a href="#components.optional">13.5. Optional files</a></span></dt>
 <dd><dl>
 <dt><span class="sect2"><a href="#components.optional.bin">13.5.1. Files affecting the binary package</a></span></dt>
 <dt><span class="sect2"><a href="#components.optional.build">13.5.2. Files affecting the build process</a></span></dt>
 <dt><span class="sect2"><a href="#components.optional.none">13.5.3. Files affecting nothing at all</a></span></dt>
 </dl></dd>
 <dt><span class="sect1"><a href="#work-dir">13.6. <code class="filename">work*</code></a></span></dt>
 <dt><span class="sect1"><a href="#files-dir">13.7. <code class="filename">files/*</code></a></span></dt>
 </dl></dd>
 <dt><span class="chapter"><a href="#makefile">14. Programming in <code class="filename">Makefile</code>s</a></span></dt>
 <dd><dl>
 <dt><span class="sect1"><a href="#makefile.style">14.1. Caveats</a></span></dt>
 <dt><span class="sect1"><a href="#makefile.variables">14.2. <code class="filename">Makefile</code> variables</a></span></dt>
 <dd><dl><dt><span class="sect2"><a href="#makefile.variables.names">14.2.1. Naming conventions</a></span></dt></dl></dd>
 <dt><span class="sect1"><a href="#makefile.code">14.3. Code snippets</a></span></dt>
 <dd><dl>
 <dt><span class="sect2"><a href="#adding-to-list">14.3.1. Adding things to a list</a></span></dt>
 <dt><span class="sect2"><a href="#echo-literal">14.3.2. Echoing a string exactly as-is</a></span></dt>
 <dt><span class="sect2"><a href="#cflags-gnu-configure">14.3.3. Passing <code class="varname">CFLAGS</code> to GNU configure scripts</a></span></dt>
 <dt><span class="sect2"><a href="#empty-variables">14.3.4. Handling possibly empty variables</a></span></dt>
 </dl></dd>
 </dl></dd>
 <dt><span class="chapter"><a href="#plist">15. PLIST issues</a></span></dt>
 <dd><dl>
 <dt><span class="sect1"><a href="#rcs-id">15.1. RCS ID</a></span></dt>
 <dt><span class="sect1"><a href="#automatic-plist-generation">15.2. Semi-automatic <code class="filename">PLIST</code> generation</a></span></dt>
 <dt><span class="sect1"><a href="#print-PLIST">15.3. Tweaking output of <span class="command"><strong>make print-PLIST</strong></span></a></span></dt>
 <dt><span class="sect1"><a href="#plist.misc">15.4. Variable substitution in PLIST</a></span></dt>
 <dt><span class="sect1"><a href="#manpage-compression">15.5. Man page compression</a></span></dt>
 <dt><span class="sect1"><a href="#using-PLIST_SRC">15.6. Changing PLIST source with <code class="varname">PLIST_SRC</code></a></span></dt>
 <dt><span class="sect1"><a href="#platform-specific-plist">15.7. Platform-specific and differing PLISTs</a></span></dt>
 <dt><span class="sect1"><a href="#build-plist">15.8. Build-specific PLISTs</a></span></dt>
 <dt><span class="sect1"><a href="#faq.common-dirs">15.9. Sharing directories between packages</a></span></dt>
 </dl></dd>
 <dt><span class="chapter"><a href="#buildlink">16. Buildlink methodology</a></span></dt>
 <dd><dl>
 <dt><span class="sect1"><a href="#converting-to-buildlink3">16.1. Converting packages to use buildlink3</a></span></dt>
 <dt><span class="sect1"><a href="#creating-buildlink3.mk">16.2. Writing <code class="filename">buildlink3.mk</code> files</a></span></dt>
 <dd><dl>
 <dt><span class="sect2"><a href="#anatomy-of-bl3">16.2.1. Anatomy of a buildlink3.mk file</a></span></dt>
 <dt><span class="sect2"><a href="#updating-buildlink-depends">16.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">16.3. Writing <code class="filename">builtin.mk</code> files</a></span></dt>
 <dd><dl>
 <dt><span class="sect2"><a href="#anatomy-of-builtin.mk">16.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">16.3.2. Global preferences for native or pkgsrc software</a></span></dt>
 </dl></dd>
 </dl></dd>
 <dt><span class="chapter"><a href="#pkginstall">17. The pkginstall framework</a></span></dt>
 <dd><dl>
 <dt><span class="sect1"><a href="#files-and-dirs-outside-prefix">17.1. Files and directories outside the installation prefix</a></span></dt>
 <dd><dl>
 <dt><span class="sect2"><a href="#dirs-outside-prefix">17.1.1. Directory manipulation</a></span></dt>
 <dt><span class="sect2"><a href="#files-outside-prefix">17.1.2. File manipulation</a></span></dt>
 </dl></dd>
 <dt><span class="sect1"><a href="#conf-files">17.2. Configuration files</a></span></dt>
 <dd><dl>
 <dt><span class="sect2"><a href="#conf-files-sysconfdir">17.2.1. How <code class="varname">PKG_SYSCONFDIR</code> is set</a></span></dt>
 <dt><span class="sect2"><a href="#conf-files-configure">17.2.2. Telling the software where configuration files are</a></span></dt>
 <dt><span class="sect2"><a href="#conf-files-patching">17.2.3. Patching installations</a></span></dt>
 <dt><span class="sect2"><a href="#conf-files-disable">17.2.4. Disabling handling of configuration files</a></span></dt>
 </dl></dd>
 <dt><span class="sect1"><a href="#rcd-scripts">17.3. System startup scripts</a></span></dt>
 <dd><dl><dt><span class="sect2"><a href="#rcd-scripts-disable">17.3.1. Disabling handling of system startup scripts</a></span></dt></dl></dd>
 <dt><span class="sect1"><a href="#users-and-groups">17.4. System users and groups</a></span></dt>
 <dt><span class="sect1"><a href="#shells">17.5. System shells</a></span></dt>
 <dd><dl><dt><span class="sect2"><a href="#shells-disable">17.5.1. Disabling shell registration</a></span></dt></dl></dd>
 <dt><span class="sect1"><a href="#fonts">17.6. Fonts</a></span></dt>
 <dd><dl><dt><span class="sect2"><a href="#fonts-disable">17.6.1. Disabling automatic update of the fonts databases</a></span></dt></dl></dd>
 </dl></dd>
 <dt><span class="chapter"><a href="#options">18. Options handling</a></span></dt>
 <dd><dl>
 <dt><span class="sect1"><a href="#global-default-options">18.1. Global default options</a></span></dt>
 <dt><span class="sect1"><a href="#converting-to-options">18.2. Converting packages to use <code class="filename">bsd.options.mk</code></a></span></dt>
 <dt><span class="sect1"><a href="#option-names">18.3. Option Names</a></span></dt>
 <dt><span class="sect1"><a href="#option-build">18.4. Determining the options of dependencies</a></span></dt>
 </dl></dd>
 <dt><span class="chapter"><a href="#build">19. The build process</a></span></dt>
 <dd><dl>
 <dt><span class="sect1"><a href="#build.intro">19.1. Introduction</a></span></dt>
 <dt><span class="sect1"><a href="#build.prefix">19.2. Program location</a></span></dt>
 <dt><span class="sect1"><a href="#build.builddirs">19.3. Directories used during the build process</a></span></dt>
 <dt><span class="sect1"><a href="#build.running">19.4. Running a phase</a></span></dt>
 <dt><span class="sect1"><a href="#build.fetch">19.5. The <span class="emphasis"><em>fetch</em></span> phase</a></span></dt>
 <dd><dl>
 <dt><span class="sect2"><a href="#build.fetch.what">19.5.1. What to fetch and where to get it from</a></span></dt>
 <dt><span class="sect2"><a href="#build.fetch.how">19.5.2. How are the files fetched?</a></span></dt>
 </dl></dd>
 <dt><span class="sect1"><a href="#build.checksum">19.6. The <span class="emphasis"><em>checksum</em></span> phase</a></span></dt>
 <dt><span class="sect1"><a href="#build.extract">19.7. The <span class="emphasis"><em>extract</em></span> phase</a></span></dt>
 <dt><span class="sect1"><a href="#build.patch">19.8. The <span class="emphasis"><em>patch</em></span> phase</a></span></dt>
 <dt><span class="sect1"><a href="#build.tools">19.9. The <span class="emphasis"><em>tools</em></span> phase</a></span></dt>
 <dt><span class="sect1"><a href="#build.wrapper">19.10. The <span class="emphasis"><em>wrapper</em></span> phase</a></span></dt>
 <dt><span class="sect1"><a href="#build.configure">19.11. The <span class="emphasis"><em>configure</em></span> phase</a></span></dt>
 <dt><span class="sect1"><a href="#build.build">19.12. The <span class="emphasis"><em>build</em></span> phase</a></span></dt>
 <dt><span class="sect1"><a href="#build.test">19.13. The <span class="emphasis"><em>test</em></span> phase</a></span></dt>
 <dt><span class="sect1"><a href="#build.install">19.14. The <span class="emphasis"><em>install</em></span> phase</a></span></dt>
 <dt><span class="sect1"><a href="#build.package">19.15. The <span class="emphasis"><em>package</em></span> phase</a></span></dt>
 <dt><span class="sect1"><a href="#build.clean">19.16. Cleaning up</a></span></dt>
 <dt><span class="sect1"><a href="#build.helpful-targets">19.17. Other helpful targets</a></span></dt>
 </dl></dd>
 <dt><span class="chapter"><a href="#tools">20. Tools needed for building or running</a></span></dt>
 <dd><dl>
 <dt><span class="sect1"><a href="#pkgsrc-tools">20.1. Tools for pkgsrc builds</a></span></dt>
 <dt><span class="sect1"><a href="#package-tools">20.2. Tools needed by packages</a></span></dt>
 <dt><span class="sect1"><a href="#platform-tools">20.3. Tools provided by platforms</a></span></dt>
 </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>
 </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="#perl-scripts">21.4.3. Packages containing perl scripts</a></span></dt>
 <dt><span class="sect2"><a href="#shell-scripts">21.4.4. Packages containing shell scripts</a></span></dt>
 <dt><span class="sect2"><a href="#other-programming-languages">21.4.5. 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="#gconf-data-files">21.6.9. Packages installing GConf data files</a></span></dt>
 <dt><span class="sect2"><a href="#scrollkeeper-data-files">21.6.10. Packages installing scrollkeeper/rarian data files</a></span></dt>
 <dt><span class="sect2"><a href="#x11-fonts">21.6.11. Packages installing X11 fonts</a></span></dt>
 <dt><span class="sect2"><a href="#gtk2-modules">21.6.12. Packages installing GTK2 modules</a></span></dt>
 <dt><span class="sect2"><a href="#sgml-xml-data">21.6.13. Packages installing SGML or XML data</a></span></dt>
 <dt><span class="sect2"><a href="#mime-database">21.6.14. Packages installing extensions to the MIME database</a></span></dt>
 <dt><span class="sect2"><a href="#intltool">21.6.15. Packages using intltool</a></span></dt>
 <dt><span class="sect2"><a href="#startup-scripts">21.6.16. Packages installing startup scripts</a></span></dt>
 <dt><span class="sect2"><a href="#tex-packages">21.6.17. Packages installing TeX modules</a></span></dt>
 <dt><span class="sect2"><a href="#emulation-packages">21.6.18. Packages supporting running binaries in
     emulation</a></span></dt>
 <dt><span class="sect2"><a href="#hicolor-theme">21.6.19. Packages installing hicolor theme icons</a></span></dt>
 <dt><span class="sect2"><a href="#desktop-files">21.6.20. 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="#debug">22. Debugging</a></span></dt>
 <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>
 <dt><span class="chapter"><a href="#gnome">25. GNOME packaging and porting</a></span></dt>
 <dd><dl>
 <dt><span class="sect1"><a href="#meta-packages">25.1. Meta packages</a></span></dt>
 <dt><span class="sect1"><a href="#new-package">25.2. Packaging a GNOME application</a></span></dt>
 <dt><span class="sect1"><a href="#full-update">25.3. Updating GNOME to a newer version</a></span></dt>
 <dt><span class="sect1"><a href="#patching">25.4. Patching guidelines</a></span></dt>
 </dl></dd>
 </dl></dd>
 <dt><span class="part"><a href="#infrastructure">III. The pkgsrc infrastructure internals</a></span></dt>
 <dd><dl>
 <dt><span class="chapter"><a href="#infr.design">26. Design of the pkgsrc infrastructure</a></span></dt>
 <dd><dl>
 <dt><span class="sect1"><a href="#infr.vardef">26.1. The meaning of variable definitions</a></span></dt>
 <dt><span class="sect1"><a href="#infr.vardef.problems">26.2. Avoiding problems before they arise</a></span></dt>
 <dt><span class="sect1"><a href="#infr.var">26.3. Variable evaluation</a></span></dt>
 <dd><dl>
 <dt><span class="sect2"><a href="#infr.var.load">26.3.1. At load time</a></span></dt>
 <dt><span class="sect2"><a href="#infr.var.run">26.3.2. At runtime</a></span></dt>
 </dl></dd>
 <dt><span class="sect1"><a href="#infr.varspec">26.4. How can variables be specified?</a></span></dt>
 <dt><span class="sect1"><a href="#infr.design.intf">26.5. Designing interfaces for Makefile fragments</a></span></dt>
 <dd><dl>
 <dt><span class="sect2"><a href="#infr.design.intf.proc">26.5.1. Procedures with parameters</a></span></dt>
 <dt><span class="sect2"><a href="#infr.design.intf.action">26.5.2. Actions taken on behalf of parameters</a></span></dt>
 </dl></dd>
 <dt><span class="sect1"><a href="#infr.order">26.6. The order in which files are loaded</a></span></dt>
 <dd><dl>
 <dt><span class="sect2"><a href="#infr.order.prefs">26.6.1. The order in <code class="filename">bsd.prefs.mk</code></a></span></dt>
 <dt><span class="sect2"><a href="#infr.order.pkg">26.6.2. The order in <code class="filename">bsd.pkg.mk</code></a></span></dt>
 </dl></dd>
 </dl></dd>
 <dt><span class="chapter"><a href="#regression">27. Regression tests</a></span></dt>
 <dd><dl>
 <dt><span class="sect1"><a href="#regression.run">27.1. Running the regression tests</a></span></dt>
 <dt><span class="sect1"><a href="#regression.new">27.2. Adding a new regression test</a></span></dt>
 <dd><dl>
 <dt><span class="sect2"><a href="#regression.fun.override">27.2.1. Overridable functions</a></span></dt>
 <dt><span class="sect2"><a href="#regression.fun.helper">27.2.2. Helper functions</a></span></dt>
 </dl></dd>
 </dl></dd>
 <dt><span class="chapter"><a href="#porting">28. Porting pkgsrc</a></span></dt>
 <dd><dl><dt><span class="sect1"><a href="#porting.opsys">28.1. Porting pkgsrc to a new operating system</a></span></dt></dl></dd>
 </dl></dd>
 <dt><span class="appendix"><a href="#examples">A. A simple example package: bison</a></span></dt>
 <dd><dl>
 <dt><span class="sect1"><a href="#example-files">A.1. files</a></span></dt>
 <dd><dl>
 <dt><span class="sect2"><a href="#example-Makefile">A.1.1. Makefile</a></span></dt>
 <dt><span class="sect2"><a href="#example-descr">A.1.2. DESCR</a></span></dt>
 <dt><span class="sect2"><a href="#example-plist">A.1.3. PLIST</a></span></dt>
 <dt><span class="sect2"><a href="#checking-package-with-pkglint">A.1.4. Checking a package with pkglint</a></span></dt>
 </dl></dd>
 <dt><span class="sect1"><a href="#steps-for-b-i-p">A.2. Steps for building, installing, packaging</a></span></dt>
 </dl></dd>
 <dt><span class="appendix"><a href="#logs">B. Build logs</a></span></dt>
 <dd><dl>
 <dt><span class="sect1"><a href="#logs.building">B.1. Building figlet</a></span></dt>
 <dt><span class="sect1"><a href="#logs.package">B.2. Packaging figlet</a></span></dt>
 </dl></dd>
 <dt><span class="appendix"><a href="#ftp-layout">C. Directory layout of the pkgsrc FTP server</a></span></dt>
 <dd><dl>
 <dt><span class="sect1"><a href="#ftp-distfiles">C.1. <code class="filename">distfiles</code>: The distributed source files</a></span></dt>
 <dt><span class="sect1"><a href="#ftp-misc">C.2. <code class="filename">misc</code>: Miscellaneous things</a></span></dt>
 <dt><span class="sect1"><a href="#ftp-packages">C.3. <code class="filename">packages</code>: Binary packages</a></span></dt>
 <dt><span class="sect1"><a href="#ftp-reports">C.4. <code class="filename">reports</code>: Bulk build reports</a></span></dt>
 <dt><span class="sect1"><a href="#ftp-source">C.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></dd>
 <dt><span class="appendix"><a href="#help-topics">D. Help topics</a></span></dt>
 <dt><span class="appendix"><a href="#editing">E. Editing guidelines for the pkgsrc guide</a></span></dt>
 <dd><dl>
 <dt><span class="sect1"><a href="#targets">E.1. Make targets</a></span></dt>
 <dt><span class="sect1"><a href="#procedure">E.2. Procedure</a></span></dt>
 </dl></dd>
 </dl>
 </div>
 <div class="list-of-tables">
 <p><b>List of Tables</b></p>
 <dl>
 <dt>1.1. <a href="#supported-platforms">Platforms supported by pkgsrc</a>
 </dt>
 <dt>13.1. <a href="#patch-examples">Patching examples</a>
 </dt>
 <dt>25.1. <a href="#plist-handling">PLIST handling for GNOME packages</a>
 </dt>
 </dl>
 </div>
 <div class="chapter">
 <div class="titlepage"><div><div><h1 class="title">
 <a name="introduction"></a>Chapter 1. What is pkgsrc?</h1></div></div></div>
 <div class="toc">
 <p><b>Table of Contents</b></p>
 <dl class="toc">
 <dt><span class="sect1"><a href="#introduction-section">1.1. Introduction</a></span></dt>
 <dd><dl>
 <dt><span class="sect2"><a href="#why-pkgsrc">1.1.1. Why pkgsrc?</a></span></dt>
 <dt><span class="sect2"><a href="#intro.platforms">1.1.2. Supported platforms</a></span></dt>
 </dl></dd>
 <dt><span class="sect1"><a href="#overview">1.2. Overview</a></span></dt>
 <dt><span class="sect1"><a href="#terminology">1.3. Terminology</a></span></dt>
 <dd><dl><dt><span class="sect2"><a href="#term.roles">1.3.1. Roles involved in pkgsrc</a></span></dt></dl></dd>
 <dt><span class="sect1"><a href="#typography">1.4. Typography</a></span></dt>
 </dl>
 </div>
 <div class="sect1">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
 <a name="introduction-section"></a>1.1. Introduction</h2></div></div></div>
 <p>There is a lot of software freely available for Unix-based
 systems, which is usually available in form of the source code. Before
 such software can be used, it needs to be configured to the local
 system, compiled and installed, and this is exactly what The NetBSD
 Packages Collection (pkgsrc) does. pkgsrc also has some basic commands
 to handle binary packages, so that not every user has to build the
 packages for himself, which is a time-costly task.</p>
 <p>pkgsrc currently contains several thousand packages,
       including:</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/www/apache24/README.html" target="_top"><code class="filename">www/apache24</code></a> - The Apache
 	  web server</p></li>
 <li class="listitem"><p><a href="https://cdn.NetBSD.org/pub/pkgsrc/current/pkgsrc/www/firefox/README.html" target="_top"><code class="filename">www/firefox</code></a> - The Firefox
 	  web browser</p></li>
 <li class="listitem"><p><a href="https://cdn.NetBSD.org/pub/pkgsrc/current/pkgsrc/meta-pkgs/gnome/README.html" target="_top"><code class="filename">meta-pkgs/gnome</code></a> - The GNOME
 	  Desktop Environment</p></li>
 <li class="listitem"><p><a href="https://cdn.NetBSD.org/pub/pkgsrc/current/pkgsrc/meta-pkgs/kde4/README.html" target="_top"><code class="filename">meta-pkgs/kde4</code></a> - The K
 	  Desktop Environment</p></li>
 </ul></div>
 <p>&#8230; just to name a few.</p>
 <p>pkgsrc has built-in support for handling varying dependencies,
       such as pthreads and X11, and extended features such as IPv6 support on
       a range of platforms.</p>
 <div class="sect2">
 <div class="titlepage"><div><div><h3 class="title">
 <a name="why-pkgsrc"></a>1.1.1. Why pkgsrc?</h3></div></div></div>
 <p>
 pkgsrc provides the following key features:
 </p>
 <div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; ">
 <li class="listitem"><p>Easy building of software from source as well as the creation
   and installation of binary packages. The source and latest
   patches are retrieved from a master or mirror download site, checksum
   verified, then built on your system. Support for binary-only
   distributions is available for both native platforms and NetBSD
   emulated platforms.</p></li>
 <li class="listitem"><p>All packages are installed in a consistent directory tree,
   including binaries, libraries, man pages and other
   documentation.</p></li>
 <li class="listitem"><p>Tracking of package dependencies automatically, including when
   performing updates, to ensure required packages are installed. The
   configuration files of various packages are handled automatically during
   updates, so local changes are preserved.</p></li>
 <li class="listitem"><p>Like NetBSD, pkgsrc is designed with portability in mind and
   consists of highly portable code. This allows the greatest speed of
   development when porting to a new platform. This portability also
   ensures that pkgsrc is <span class="emphasis"><em>consistent across all
   platforms</em></span>.</p></li>
 <li class="listitem"><p>The installation prefix, acceptable software licenses,
   international encryption requirements and build-time options for a
   large number of packages are all set in a simple, central
   configuration file.</p></li>
 <li class="listitem"><p>The entire source (not including the distribution files) is
   freely available under a BSD license, so you may extend and adapt
   pkgsrc to your needs. Support for local packages and patches is
   available right out of the box, so you can configure it specifically
   for your environment.</p></li>
 </ul></div>
 <p>The following principles are basic to pkgsrc:</p>
 <div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; ">
 <li class="listitem"><p><span class="quote">&#8220;<span class="quote">It should only work if it's right.</span>&#8221;</span>
 &mdash; That means, if a package contains bugs, it's better to find
 them and to complain about them rather than to just install the package
 and hope that it works. There are numerous checks in pkgsrc that try to
 find such bugs: static analysis tools (<a href="https://cdn.NetBSD.org/pub/pkgsrc/current/pkgsrc/pkgtools/pkglint/README.html" target="_top"><code class="filename">pkgtools/pkglint</code></a>), build-time checks (portability
 of shell scripts), and post-installation checks (installed files,
 references to shared libraries, script interpreters).</p></li>
 <li class="listitem"><p><span class="quote">&#8220;<span class="quote">If it works, it should work everywhere</span>&#8221;</span>
 &mdash; Like NetBSD has been ported to many hardware architectures,
 pkgsrc has been ported to many operating systems. Care is taken that
 packages behave the same on all platforms.</p></li>
 </ul></div>
 </div>
 <div class="sect2">
 <div class="titlepage"><div><div><h3 class="title">
 <a name="intro.platforms"></a>1.1.2. Supported platforms</h3></div></div></div>
 <p>pkgsrc consists of both a source distribution and a binary
 distribution for these operating systems. After retrieving the required
 source or binaries, you can be up and running with pkgsrc in just
 minutes!</p>
 <p>pkgsrc was derived from FreeBSD's ports system, and
       initially developed for NetBSD only. Since then, pkgsrc has
       grown a lot, and now supports the following platforms:</p>
 <div class="table">
 <a name="supported-platforms"></a><p class="title"><b>Table 1.1. Platforms supported by pkgsrc</b></p>
 <div class="table-contents"><table class="table" summary="Platforms supported by pkgsrc" border="1">
 <colgroup>
 <col>
 <col>
 <col>
 </colgroup>
 <thead><tr>
 <th>Platform</th>
 <th>Date Support Added</th>
 <th>Notes</th>
 </tr></thead>
 <tbody>
 <tr>
 <td><a class="ulink" href="https://www.NetBSD.org/" target="_top">NetBSD</a></td>
 <td align="center">Aug 1997</td>
 <td class="auto-generated"> </td>
 </tr>
 <tr>
 <td><a class="ulink" href="http://wwws.sun.com/software/solaris/" target="_top">Solaris</a></td>
 <td align="center">Mar 1999</td>
 <td><a class="ulink" href="https://cdn.NetBSD.org/pub/pkgsrc/current/pkgsrc/bootstrap/README.Solaris" target="_top">README.Solaris</a></td>
 </tr>
 <tr>
 <td><a class="ulink" href="https://www.kernel.org/" target="_top">Linux</a></td>
 <td align="center">Jun 1999</td>
 <td><a class="ulink" href="https://cdn.NetBSD.org/pub/pkgsrc/current/pkgsrc/bootstrap/README.Linux" target="_top">README.Linux</a></td>
 </tr>
 <tr>
 <td>
           <a class="ulink" href="https://developer.apple.com/macos/" target="_top">Darwin / Mac OS X / OS X / macOS</a>
         </td>
 <td align="center">Oct 2001</td>
 <td><a class="ulink" href="https://cdn.NetBSD.org/pub/pkgsrc/current/pkgsrc/bootstrap/README.MacOSX" target="_top">README.MacOSX</a></td>
 </tr>
 <tr>
 <td><a class="ulink" href="https://www.freebsd.org/" target="_top">FreeBSD</a></td>
 <td align="center">Nov 2002</td>
 <td><a class="ulink" href="https://cdn.NetBSD.org/pub/pkgsrc/current/pkgsrc/bootstrap/README.FreeBSD" target="_top">README.FreeBSD</a></td>
 </tr>
 <tr>
 <td><a class="ulink" href="https://www.openbsd.org/" target="_top">OpenBSD</a></td>
 <td align="center">Nov 2002</td>
 <td><a class="ulink" href="https://cdn.NetBSD.org/pub/pkgsrc/current/pkgsrc/bootstrap/README.OpenBSD" target="_top">README.OpenBSD</a></td>
 </tr>
 <tr>
 <td><a class="ulink" href="https://www.sgi.com/software/irix/" target="_top">IRIX</a></td>
 <td align="center">Dec 2002</td>
 <td>
 	<a class="ulink" href="https://cdn.NetBSD.org/pub/pkgsrc/current/pkgsrc/bootstrap/README.IRIX" target="_top">README.IRIX</a>
 	<a class="ulink" href="https://cdn.NetBSD.org/pub/pkgsrc/current/pkgsrc/bootstrap/README.IRIX5.3" target="_top">README.IRIX5.3</a>
 	</td>
 </tr>
 <tr>
 <td>BSD/OS</td>
 <td align="center">Dec 2003</td>
 <td class="auto-generated"> </td>
 </tr>
 <tr>
 <td><a class="ulink" href="https://www-1.ibm.com/servers/aix/" target="_top">AIX</a></td>
 <td align="center">Dec 2003</td>
 <td><a class="ulink" href="https://cdn.NetBSD.org/pub/pkgsrc/current/pkgsrc/bootstrap/README.AIX" target="_top">README.AIX</a></td>
 </tr>
 <tr>
 <td>
           <a class="ulink" href="https://www.microsoft.com/windows/sfu/" target="_top">Interix</a>
           (Microsoft Windows Services for Unix)
         </td>
 <td align="center">Mar 2004</td>
 <td><a class="ulink" href="https://cdn.NetBSD.org/pub/pkgsrc/current/pkgsrc/bootstrap/README.Interix" target="_top">README.Interix</a></td>
 </tr>
 <tr>
 <td><a class="ulink" href="https://www.dragonflybsd.org/" target="_top">DragonFlyBSD</a></td>
 <td align="center">Oct 2004</td>
 <td class="auto-generated"> </td>
 </tr>
 <tr>
 <td><a class="ulink" href="http://www.tru64.org/" target="_top">OSF/1</a></td>
 <td align="center">Nov 2004</td>
 <td><a class="ulink" href="https://cdn.NetBSD.org/pub/pkgsrc/current/pkgsrc/bootstrap/README.OSF1" target="_top">README.OSF1</a></td>
 </tr>
 <tr>
 <td><a class="ulink" href="https://www.hp.com/products1/unix/" target="_top">HP-UX</a></td>
 <td align="center">Apr 2007</td>
 <td><a class="ulink" href="https://cdn.NetBSD.org/pub/pkgsrc/current/pkgsrc/bootstrap/README.HPUX" target="_top">README.HPUX</a></td>
 </tr>
 <tr>
 <td><a class="ulink" href="https://www.haiku-os.org/" target="_top">Haiku</a></td>
 <td align="center">Sep 2010</td>
 <td><a class="ulink" href="https://cdn.NetBSD.org/pub/pkgsrc/current/pkgsrc/bootstrap/README.Haiku" target="_top">README.Haiku</a></td>
 </tr>
 <tr>
 <td><a class="ulink" href="https://www.mirbsd.org/" target="_top">MirBSD</a></td>
 <td align="center">Jan 2011</td>
 <td class="auto-generated"> </td>
 </tr>
 <tr>
 <td><a class="ulink" href="https://www.minix3.org/" target="_top">Minix3</a></td>
 <td align="center">Nov 2011</td>
 <td><a class="ulink" href="https://cdn.NetBSD.org/pub/pkgsrc/current/pkgsrc/bootstrap/README.Minix3" target="_top">README.Minix3</a></td>
 </tr>
 <tr>
 <td><a class="ulink" href="https://cygwin.com/" target="_top">Cygwin</a></td>
 <td align="center">Mar 2013</td>
 <td><a class="ulink" href="https://cdn.NetBSD.org/pub/pkgsrc/current/pkgsrc/bootstrap/README.Cygwin" target="_top">README.Cygwin</a></td>
 </tr>
 <tr>
 <td><a class="ulink" href="https://www.debian.org/ports/kfreebsd-gnu/" target="_top">GNU/kFreeBSD</a></td>
 <td align="center">Jul 2013</td>
 <td><a class="ulink" href="https://cdn.NetBSD.org/pub/pkgsrc/current/pkgsrc/bootstrap/README.GNUkFreeBSD" target="_top">README.GNUkFreeBSD</a></td>
 </tr>
 <tr>
 <td><a class="ulink" href="https://www.bitrig.org/" target="_top">Bitrig</a></td>
 <td align="center">Jun 2014</td>
 <td><a class="ulink" href="https://cdn.NetBSD.org/pub/pkgsrc/current/pkgsrc/bootstrap/README.Bitrig" target="_top">README.Bitrig</a></td>
 </tr>
 </tbody>
 </table></div>
 </div>
 <br class="table-break">
 </div>
 </div>
 <div class="sect1">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
 <a name="overview"></a>1.2. Overview</h2></div></div></div>
 <p>This document is divided into three parts. The first,
 	<a class="link" href="#users-guide" title="Part I. The pkgsrc user's guide">The pkgsrc user's guide</a>,
 	describes how one can use one of the packages in the Package
 	Collection, either by installing a precompiled binary package,
 	or by building one's own copy using the NetBSD package system.
 	The second part, <a class="link" href="#developers-guide" title="Part II. The pkgsrc developer's guide">The pkgsrc developer's guide</a>, explains how to prepare a
 	package so it can be easily built by other NetBSD users without
 	knowing about the package's building details. The third part,
 	<a class="link" href="#infrastructure" title="Part III. The pkgsrc infrastructure internals">The pkgsrc infrastructure internals</a>
 	is intended for those who want to understand how pkgsrc is
 	implemented.</p>
 <p>This document is available in various formats:
 	<span class="simplelist"><a class="ulink" href="index.html" target="_top">HTML</a>, <a class="ulink" href="pkgsrc.pdf" target="_top">PDF</a>, <a class="ulink" href="pkgsrc.ps" target="_top">PS</a>, <a class="ulink" href="pkgsrc.txt" target="_top">TXT</a></span>.</p>
 </div>
 <div class="sect1">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
 <a name="terminology"></a>1.3. Terminology</h2></div></div></div>
 <p>There has been a lot of talk about <span class="quote">&#8220;<span class="quote">ports</span>&#8221;</span>,
       <span class="quote">&#8220;<span class="quote">packages</span>&#8221;</span>, etc. so far. Here is a description of all the
       terminology used within this document.</p>
 <div class="variablelist"><dl class="variablelist">
 <dt><span class="term">Package</span></dt>
 <dd><p>A set of files and building instructions
 	    that describe what's necessary
 	    to build a certain piece of software using
             pkgsrc. Packages are traditionally stored under
 	    <code class="filename">/usr/pkgsrc</code>,
 	    but may be stored in any location,
 	    referred to as <code class="varname">PKGSRCDIR</code>.</p></dd>
 <dt><span class="term">The NetBSD package system</span></dt>
 <dd><p>This is the former name of <span class="quote">&#8220;<span class="quote">pkgsrc</span>&#8221;</span>.  It
 	  is part of the NetBSD operating system and can be bootstrapped
 	  to run on non-NetBSD operating systems as well.  It handles
 	  building (compiling), installing, and removing of
 	  packages.</p></dd>
 <dt><span class="term">Distfile</span></dt>
 <dd><p>This term describes the file or files that are
 	    provided by the author of the piece of software to
 	    distribute his work. All the changes necessary to build on
 	    NetBSD are reflected in the corresponding package. Usually
 	    the distfile is in the form of a compressed tar-archive,
 	    but other types are possible, too. Distfiles are usually
 	    stored below
 	    <code class="filename">/usr/pkgsrc/distfiles</code>.</p></dd>
 <dt><span class="term">Port</span></dt>
 <dd><p>This is the term used by FreeBSD and OpenBSD people
 	    for what we call a package.
 	    In NetBSD terminology, <span class="quote">&#8220;<span class="quote">port</span>&#8221;</span> refers to a different
 	    architecture.</p></dd>
 <dt><span class="term">Precompiled/binary package</span></dt>
 <dd>
 <p>A set of binaries built with pkgsrc from a distfile
 	    and stuffed together in a single <code class="filename">.tgz</code>
 	    file so it can be installed on machines of the same
 	    machine architecture without the need to
 	    recompile. Packages are usually generated in
 	    <code class="filename">/usr/pkgsrc/packages</code>; there is also
 	    an archive on <a class="ulink" href="ftp://ftp.NetBSD.org/pub/pkgsrc/packages/" target="_top">ftp.NetBSD.org</a>.</p>
 <p>Sometimes, this is referred to by the term <span class="quote">&#8220;<span class="quote">package</span>&#8221;</span> too,
 	    especially in the context of precompiled packages.</p>
 </dd>
 <dt><span class="term">Program</span></dt>
 <dd><p>The piece of software to be installed which will be
 	  constructed from all the files in the distfile by the
 	  actions defined in the corresponding package.</p></dd>
 </dl></div>
 <div class="sect2">
 <div class="titlepage"><div><div><h3 class="title">
 <a name="term.roles"></a>1.3.1. Roles involved in pkgsrc</h3></div></div></div>
 <div class="variablelist"><dl class="variablelist">
 <dt><span class="term">pkgsrc users</span></dt>
 <dd>
 <p>The
 	pkgsrc users are people who use the packages provided by pkgsrc.
 	Typically they are system administrators. The people using the
 	software that is inside the packages (maybe called <span class="quote">&#8220;<span class="quote">end
 	users</span>&#8221;</span>) are not covered by the pkgsrc guide.</p>
 <p>There are two kinds of pkgsrc users: Some only want to
 	install pre-built binary packages. Others build the pkgsrc
 	packages from source, either for installing them directly or for
 	building binary packages themselves. For pkgsrc users <a class="xref" href="#users-guide" title="Part I. The pkgsrc user's guide">Part I, &#8220;The pkgsrc user's guide&#8221;</a> should provide all necessary
 	documentation.</p>
 </dd>
 <dt><span class="term">package maintainers</span></dt>
 <dd><p>A
 	package maintainer creates packages as described in <a class="xref" href="#developers-guide" title="Part II. The pkgsrc developer's guide">Part II, &#8220;The pkgsrc developer's guide&#8221;</a>.</p></dd>
 <dt><span class="term">infrastructure developers</span></dt>
 <dd><p>These people are involved in all those files
 	that live in the <code class="filename">mk/</code> directory and below.
 	Only these people should need to read through <a class="xref" href="#infrastructure" title="Part III. The pkgsrc infrastructure internals">Part III, &#8220;The pkgsrc infrastructure internals&#8221;</a>, though others might be curious,
 	too.</p></dd>
 </dl></div>
 </div>
 </div>
 <div class="sect1">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
 <a name="typography"></a>1.4. Typography</h2></div></div></div>
 <p>When giving examples for commands, shell prompts are used to
       show if the command should/can be issued as root, or if
       <span class="quote">&#8220;<span class="quote">normal</span>&#8221;</span> user privileges are sufficient. We use a
       <code class="prompt">#</code> for root's shell prompt, a <code class="prompt">%</code> for users'
       shell prompt, assuming they use the C-shell or tcsh and a <code class="prompt">$</code> for
       bourne shell and derivatives.</p>
 </div>
 </div>
 <div class="part">
 <div class="titlepage"><div><div><h1 class="title">
 <a name="users-guide"></a>Part I. The pkgsrc user's guide</h1></div></div></div>
 <div class="toc">
 <p><b>Table of Contents</b></p>
 <dl class="toc">
 <dt><span class="chapter"><a href="#help-user">2. Getting help</a></span></dt>
 <dt><span class="chapter"><a href="#getting">3. Where to get pkgsrc and how to keep it up-to-date</a></span></dt>
 <dd><dl>
 <dt><span class="sect1"><a href="#getting-first">3.1. Getting pkgsrc for the first time</a></span></dt>
 <dd><dl>
 <dt><span class="sect2"><a href="#getting-via-tar">3.1.1. As tar archive</a></span></dt>
 <dt><span class="sect2"><a href="#getting-via-cvs">3.1.2. Via anonymous CVS</a></span></dt>
 </dl></dd>
 <dt><span class="sect1"><a href="#uptodate">3.2. Keeping pkgsrc up-to-date</a></span></dt>
 <dd><dl>
 <dt><span class="sect2"><a href="#uptodate-tar">3.2.1. Via tar files</a></span></dt>
 <dt><span class="sect2"><a href="#uptodate-cvs">3.2.2. Via CVS</a></span></dt>
 </dl></dd>
 </dl></dd>
 <dt><span class="chapter"><a href="#platforms">4. Using pkgsrc on systems other than NetBSD</a></span></dt>
 <dd><dl>
 <dt><span class="sect1"><a href="#binarydist">4.1. Binary distribution</a></span></dt>
 <dt><span class="sect1"><a href="#bootstrapping-pkgsrc">4.2. Bootstrapping pkgsrc</a></span></dt>
 </dl></dd>
 <dt><span class="chapter"><a href="#using">5. Using pkgsrc</a></span></dt>
 <dd><dl>
 <dt><span class="sect1"><a href="#using-pkg">5.1. Using binary packages</a></span></dt>
 <dd><dl>
 <dt><span class="sect2"><a href="#finding-binary-packages">5.1.1. Finding binary packages</a></span></dt>
 <dt><span class="sect2"><a href="#installing-binary-packages">5.1.2. Installing binary packages</a></span></dt>
 <dt><span class="sect2"><a href="#using.pkg_delete">5.1.3. Deinstalling packages</a></span></dt>
 <dt><span class="sect2"><a href="#using.pkg_info">5.1.4. Getting information about installed packages</a></span></dt>
 <dt><span class="sect2"><a href="#vulnerabilities">5.1.5. Checking for security vulnerabilities in installed packages</a></span></dt>
 <dt><span class="sect2"><a href="#pkg_versions">5.1.6. Finding if newer versions of your installed packages are in pkgsrc</a></span></dt>
 <dt><span class="sect2"><a href="#using.pkg_admin">5.1.7. Other administrative functions</a></span></dt>
 </dl></dd>
 <dt><span class="sect1"><a href="#building-packages-from-source">5.2. Building packages from source</a></span></dt>
 <dd><dl>
 <dt><span class="sect2"><a href="#requirements">5.2.1. Requirements</a></span></dt>
 <dt><span class="sect2"><a href="#fetching-distfiles">5.2.2. Fetching distfiles</a></span></dt>
 <dt><span class="sect2"><a href="#how-to-build-and-install">5.2.3. How to build and install</a></span></dt>
 </dl></dd>
 </dl></dd>
 <dt><span class="chapter"><a href="#configuring">6. Configuring pkgsrc</a></span></dt>
 <dd><dl>
 <dt><span class="sect1"><a href="#general-configuration">6.1. General configuration</a></span></dt>
 <dt><span class="sect1"><a href="#variables-affecting-build">6.2. Variables affecting the build process</a></span></dt>
 <dt><span class="sect1"><a href="#variables-affecting-installation">6.3. Variables affecting the installation process</a></span></dt>
 <dt><span class="sect1"><a href="#conf.compiler">6.4. Selecting and configuring the compiler</a></span></dt>
 <dd><dl>
 <dt><span class="sect2"><a href="#selecting-the-compiler">6.4.1. Selecting the compiler</a></span></dt>
 <dt><span class="sect2"><a href="#conf.cflags">6.4.2. Additional flags to the compiler (<code class="varname">CFLAGS</code>)</a></span></dt>
 <dt><span class="sect2"><a href="#conf.ldflags">6.4.3. Additional flags to the linker (<code class="varname">LDFLAGS</code>)</a></span></dt>
 </dl></dd>
 <dt><span class="sect1"><a href="#developer-advanced-settings">6.5. Developer/advanced settings</a></span></dt>
 <dt><span class="sect1"><a href="#selecting-build-options">6.6. Selecting Build Options</a></span></dt>
 </dl></dd>
 <dt><span class="chapter"><a href="#binary">7. Creating binary packages</a></span></dt>
 <dd><dl>
 <dt><span class="sect1"><a href="#building-a-single-binary-package">7.1. Building a single binary package</a></span></dt>
 <dt><span class="sect1"><a href="#settings-for-creationg-of-binary-packages">7.2. Settings for creation of binary packages</a></span></dt>
 </dl></dd>
 <dt><span class="chapter"><a href="#bulk">8. Creating binary packages for everything in pkgsrc (bulk
 builds)</a></span></dt>
 <dd><dl>
 <dt><span class="sect1"><a href="#bulk.pre">8.1. Preparations</a></span></dt>
 <dt><span class="sect1"><a href="#bulk.pbulk">8.2. Running a pbulk-style bulk build</a></span></dt>
 <dd><dl><dt><span class="sect2"><a href="#bulk.pbulk.conf">8.2.1. Configuration</a></span></dt></dl></dd>
 <dt><span class="sect1"><a href="#bulk.req">8.3. Requirements of a full bulk build</a></span></dt>
 <dt><span class="sect1"><a href="#bulk.var">8.4. Bulk build variants</a></span></dt>
 <dd><dl>
-<dt><span class="sect2"><a href="#bulk.var.subst_noop">8.4.1. Strict SUBST blocks</a></span></dt>
+<dt><span class="sect2"><a href="#bulk.var.confopt">8.4.1. Detect unknown configure options</a></span></dt>
-<dt><span class="sect2"><a href="#bulk.var.confopt">8.4.2. Detect unknown configure options</a></span></dt>
+<dt><span class="sect2"><a href="#bulk.var.comperr">8.4.2. Detect classes of bugs by forcing compiler warnings</a></span></dt>
-<dt><span class="sect2"><a href="#bulk.var.comperr">8.4.3. Detect classes of bugs by forcing compiler warnings</a></span></dt>
+<dt><span class="sect2"><a href="#bulk.var.dirs">8.4.3. Use custom directories</a></span></dt>
-<dt><span class="sect2"><a href="#bulk.var.dirs">8.4.4. Use custom directories</a></span></dt>
+<dt><span class="sect2"><a href="#bulk.var.warn">8.4.4. Turn warnings into errors</a></span></dt>
-<dt><span class="sect2"><a href="#bulk.var.warn">8.4.5. Turn warnings into errors</a></span></dt>
+<dt><span class="sect2"><a href="#bulk.var.pkglint">8.4.5. Reject packages for which pkglint reports errors</a></span></dt>
-<dt><span class="sect2"><a href="#bulk.var.pkglint">8.4.6. Reject packages for which pkglint reports errors</a></span></dt>
+<dt><span class="sect2"><a href="#bulk.var.strings">8.4.6. Reject packages that contain forbidden strings</a></span></dt>
-<dt><span class="sect2"><a href="#bulk.var.strings">8.4.7. Reject packages that contain forbidden strings</a></span></dt>
+<dt><span class="sect2"><a href="#bulk.var.test">8.4.7. Reject packages whose self-test fails</a></span></dt>
-<dt><span class="sect2"><a href="#bulk.var.test">8.4.8. Reject packages whose self-test fails</a></span></dt>
+<dt><span class="sect2"><a href="#bulk.var.shvar">8.4.8. Reject packages that use undefined shell variables</a></span></dt>
-<dt><span class="sect2"><a href="#bulk.var.shvar">8.4.9. Reject packages that use undefined shell variables</a></span></dt>
+<dt><span class="sect2"><a href="#bulk.var.quiet">8.4.9. Turn off verbose logging</a></span></dt>
 <dt><span class="sect2"><a href="#bulk.var.quiet">8.4.10. Turn off verbose logging</a></span></dt>
 <dt><span class="sect2"><a href="#bulk.var.options">8.4.11. Select random sets of options</a></span></dt>
 <dt><span class="sect2"><a href="#bulk.var.build_defs">8.4.12. Select random configurations of BUILD_DEFS</a></span></dt>
 </dl></dd>
 <dt><span class="sect1"><a href="#creating-cdroms">8.5. Creating a multiple CD-ROM packages collection</a></span></dt>
 <dd><dl><dt><span class="sect2"><a href="#cdpack-example">8.5.1. Example of cdpack</a></span></dt></dl></dd>
 </dl></dd>
 <dt><span class="chapter"><a href="#files">9. Directory layout of the installed files</a></span></dt>
 <dd><dl>
 <dt><span class="sect1"><a href="#files.localbase">9.1. File system layout in <code class="literal">${LOCALBASE}</code></a></span></dt>
 <dt><span class="sect1"><a href="#files.varbase">9.2. File system layout in <code class="literal">${VARBASE}</code></a></span></dt>
 </dl></dd>
 <dt><span class="chapter"><a href="#faq">10. Frequently Asked Questions</a></span></dt>
 <dd><dl>
 <dt><span class="sect1"><a href="#mailing-list-pointers">10.1. Are there any mailing lists for pkg-related discussion?</a></span></dt>
 <dt><span class="sect1"><a href="#faq-pkgtools">10.2. Utilities for package management (pkgtools)</a></span></dt>
 <dt><span class="sect1"><a href="#non-root-pkgsrc">10.3. How to use pkgsrc as non-root</a></span></dt>
 <dt><span class="sect1"><a href="#resume-transfers">10.4. How to resume transfers when fetching distfiles?</a></span></dt>
 <dt><span class="sect1"><a href="#x.org-from-pkgsrc">10.5. How can I install/use modular X.org from pkgsrc?</a></span></dt>
 <dt><span class="sect1"><a href="#fetch-behind-firewall">10.6. How to fetch files from behind a firewall</a></span></dt>
 <dt><span class="sect1"><a href="#fetch-https">10.7. How to fetch files from HTTPS sites</a></span></dt>
 <dt><span class="sect1"><a href="#passive-ftp">10.8. How do I tell <span class="command"><strong>make fetch</strong></span> to do passive FTP?</a></span></dt>
 <dt><span class="sect1"><a href="#fetching-all-distfiles">10.9. How to fetch all distfiles at once</a></span></dt>
 <dt><span class="sect1"><a href="#tmac.andoc-missing">10.10. What does <span class="quote">&#8220;<span class="quote">Don't know how to make
 /usr/share/tmac/tmac.andoc</span>&#8221;</span> mean?</a></span></dt>
 <dt><span class="sect1"><a href="#bsd.own.mk-missing">10.11. What does <span class="quote">&#8220;<span class="quote">Could not find bsd.own.mk</span>&#8221;</span> mean?</a></span></dt>
 <dt><span class="sect1"><a href="#using-sudo-with-pkgsrc">10.12. Using 'sudo' with pkgsrc</a></span></dt>
 <dt><span class="sect1"><a href="#faq.conf">10.13. How do I change the location of configuration files?</a></span></dt>
 <dt><span class="sect1"><a href="#audit-packages">10.14. Automated security checks</a></span></dt>
 <dt><span class="sect1"><a href="#ufaq-cflags">10.15. Why do some packages ignore my <code class="varname">CFLAGS</code>?</a></span></dt>
 <dt><span class="sect1"><a href="#ufaq-fail">10.16. A package does not build.  What shall I do?</a></span></dt>
 <dt><span class="sect1"><a href="#faq.rcs-conflicts">10.17. What does <span class="quote">&#8220;<span class="quote">Makefile appears to contain unresolved cvs/rcs/??? merge conflicts</span>&#8221;</span> mean?</a></span></dt>
 </dl></dd>
 </dl>
 </div>
 <div class="chapter">
 <div class="titlepage"><div><div><h2 class="title">
 <a name="help-user"></a>Chapter 2. Getting help</h2></div></div></div>
 <p>
 	To get help when using 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 D. Help topics">Appendix D, <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 pkgsrc-users mailing list, to which
 	<a class="ulink" href="https://www.NetBSD.org/mailinglists/#pkgsrc-users" target="_top">you
 	can subscribe</a> and then <a class="ulink" href="mailto:pkgsrc-users@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="getting"></a>Chapter 3. Where to get pkgsrc and how to keep it up-to-date</h2></div></div></div>
 <div class="toc">
 <p><b>Table of Contents</b></p>
 <dl class="toc">
 <dt><span class="sect1"><a href="#getting-first">3.1. Getting pkgsrc for the first time</a></span></dt>
 <dd><dl>
 <dt><span class="sect2"><a href="#getting-via-tar">3.1.1. As tar archive</a></span></dt>
 <dt><span class="sect2"><a href="#getting-via-cvs">3.1.2. Via anonymous CVS</a></span></dt>
 </dl></dd>
 <dt><span class="sect1"><a href="#uptodate">3.2. Keeping pkgsrc up-to-date</a></span></dt>
 <dd><dl>
 <dt><span class="sect2"><a href="#uptodate-tar">3.2.1. Via tar files</a></span></dt>
 <dt><span class="sect2"><a href="#uptodate-cvs">3.2.2. Via CVS</a></span></dt>
 </dl></dd>
 </dl>
 </div>
 <p>Before you download and extract the files, you need to decide
 where you want to extract them. When using pkgsrc as root user, pkgsrc
 is usually installed in <code class="filename">/usr/pkgsrc</code>. You are though
 free to install the sources and binary packages wherever you want in
 your filesystem, provided that the pathname does not contain white-space
 or other characters that are interpreted specially by the shell and some
 other programs. A safe bet is to use only letters, digits, underscores
 and dashes.</p>
 <div class="sect1">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
 <a name="getting-first"></a>3.1. Getting pkgsrc for the first time</h2></div></div></div>
 <p>Before you download any pkgsrc files, you should decide
 	whether you want the <span class="emphasis"><em>current</em></span> branch or the
 	<span class="emphasis"><em>stable</em></span> branch. The latter is forked on a
 	quarterly basis from the current branch and only gets modified
 	for security updates. The names of the stable branches are built
 	from the year and the quarter, for example
 	<code class="literal">2020Q1</code>.</p>
 <p>The second step is to decide <span class="emphasis"><em>how</em></span> you
 	want to download pkgsrc. You can get it as a tar file or via CVS.
 	Both ways are described here.</p>
 <p>Note that tar archive contains CVS working copy.
 	Thus you can switch to using CVS at any later time.</p>
 <div class="sect2">
 <div class="titlepage"><div><div><h3 class="title">
 <a name="getting-via-tar"></a>3.1.1. As tar archive</h3></div></div></div>
 <p>The primary download location for all pkgsrc files is
 	<a class="ulink" href="https://cdn.NetBSD.org/pub/pkgsrc/" target="_top">https://cdn.NetBSD.org/pub/pkgsrc/</a> or
 	<a class="ulink" href="ftp://ftp.NetBSD.org/pub/pkgsrc/" target="_top">ftp://ftp.NetBSD.org/pub/pkgsrc/</a>
 	(it points to the same location).
 	There are a number of subdirectories for different purposes,
 	which are described in detail in <a class="xref" href="#ftp-layout" title="Appendix C. Directory layout of the pkgsrc FTP server">Appendix C, <i>Directory layout of the pkgsrc FTP server</i></a>.</p>
 <p>The tar archive for the current branch is in the directory
 	<code class="filename">current</code> and is called <a class="ulink" href="https://cdn.NetBSD.org/pub/pkgsrc/current/pkgsrc.tar.gz" target="_top"><code class="filename">pkgsrc.tar.gz</code></a>.
 	It is autogenerated weekly.</p>
 <p>To save download time we provide bzip2- and
 	xz-compressed archives which are published at
 	<a class="ulink" href="https://cdn.NetBSD.org/pub/pkgsrc/current/pkgsrc.tar.bz2" target="_top"><code class="filename">pkgsrc.tar.bz2</code></a>
 	and
 	<a class="ulink" href="https://cdn.NetBSD.org/pub/pkgsrc/current/pkgsrc.tar.xz" target="_top"><code class="filename">pkgsrc.tar.xz</code></a>
 	respectively.
 	</p>
 <p>You can fetch the same files using FTP.</p>
 <p>The tar file for the stable branch 2020Q1 is in the
 	directory <code class="filename">pkgsrc-2020Q1</code> and is also called <a class="ulink" href="https://cdn.NetBSD.org/pub/pkgsrc/pkgsrc-2020Q1/pkgsrc.tar.gz" target="_top"><code class="filename">pkgsrc.tar.gz</code></a>.</p>
 <p>To download the latest pkgsrc stable tarball, run:</p>
 <pre class="screen">
 <code class="prompt">$</code> <strong class="userinput"><code>ftp ftp://ftp.NetBSD.org/pub/pkgsrc/pkgsrc-2020Q1/pkgsrc.tar.gz</code></strong></pre>
 <p>If you prefer, you can also fetch it using "wget", "curl",
 	or your web browser.</p>
 <p>Then, extract it with:</p>
 <pre class="screen"><code class="prompt">$</code> <strong class="userinput"><code>tar -xzf pkgsrc.tar.gz -C /usr</code></strong></pre>
 <p>This will create the directory <code class="filename">pkgsrc/</code>
 	in <code class="filename">/usr/</code> and all the package source will be
 	stored under <code class="filename">/usr/pkgsrc/</code>.</p>
 <p>To download pkgsrc-current, run:</p>
 <pre class="screen"><code class="prompt">$</code> <strong class="userinput"><code>ftp ftp://ftp.NetBSD.org/pub/pkgsrc/current/pkgsrc.tar.gz</code></strong></pre>
 </div>
 <div class="sect2">
 <div class="titlepage"><div><div><h3 class="title">
 <a name="getting-via-cvs"></a>3.1.2. Via anonymous CVS</h3></div></div></div>
 <p>To fetch a specific pkgsrc stable branch, run:</p>
 <pre class="screen"><code class="prompt">$</code> <strong class="userinput"><code>cd /usr &amp;&amp; cvs -q -z2 -d anoncvs@anoncvs.NetBSD.org:/cvsroot checkout -r pkgsrc-2020Q1 -P pkgsrc</code></strong>
 </pre>
 <p>This will create the directory <code class="filename">pkgsrc/</code>
 	in your <code class="filename">/usr/</code> directory and all the package source
 	will be stored under <code class="filename">/usr/pkgsrc/</code>.</p>
 <p>To fetch the pkgsrc current branch, run:</p>
 <pre class="screen"><code class="prompt">$</code> <strong class="userinput"><code>cd /usr &amp;&amp; cvs -q -z2 -d anoncvs@anoncvs.NetBSD.org:/cvsroot checkout -P pkgsrc</code></strong>
 </pre>
 <p>Refer to the <a class="ulink" href="https://www.NetBSD.org/mirrors/#anoncvs" target="_top">list of available mirrors</a> to choose a faster CVS mirror, if needed.</p>
 <p>If you get error messages from <code class="literal">rsh</code>, you need to set CVS_RSH variable. E.g.:</p>
 <pre class="screen"><code class="prompt">$</code> <strong class="userinput"><code>cd /usr &amp;&amp; env CVS_RSH=ssh cvs -q -z2 -d anoncvs@anoncvs.NetBSD.org:/cvsroot checkout -P pkgsrc</code></strong>
 </pre>
 <p>Refer to documentation on your command shell how to set CVS_RSH=ssh permanently.
 	For Bourne shells, you can set it in your <code class="filename">.profile</code>
 	or better globally in <code class="filename">/etc/profile</code>:</p>
 <pre class="programlisting">
 # set CVS remote shell command
 CVS_RSH=ssh
 export CVS_RSH
 </pre>
 <p>By default, CVS doesn't do things like most people would expect it to do.
 	But there is a way to convince CVS, by creating a file called <code class="filename">.cvsrc</code>
 	in your home directory and saving the following lines to it.
 	This file will save you lots of headache and some bug reports, so we strongly recommend it.
 	You can find an explanation of this file in the CVS documentation.</p>
 <pre class="programlisting">
 # recommended CVS configuration file from the pkgsrc guide
 cvs -q
 checkout -P
 update -dP
 diff -upN
 rdiff -u
 release -d
 </pre>
 </div>
 </div>
 <div class="sect1">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
 <a name="uptodate"></a>3.2. Keeping pkgsrc up-to-date</h2></div></div></div>
 <p>The preferred way to keep pkgsrc up-to-date is via CVS
 	(which also works if you have first installed it via a tar
 	file). It saves bandwidth and hard disk activity, compared to
 	downloading the tar file again.</p>
 <div class="sect2">
 <div class="titlepage"><div><div><h3 class="title">
 <a name="uptodate-tar"></a>3.2.1. Via tar files</h3></div></div></div>
 <div class="warning" style="margin-left: 0.5in; margin-right: 0.5in;">
 <h3 class="title">Warning</h3>
 <p>When updating from a tar file, you first need to
 	completely remove the old pkgsrc directory. Otherwise those
 	files that have been removed from pkgsrc in the mean time will
 	not be removed on your local disk, resulting in inconsistencies.
 	When removing the old files, any changes that you have done to
 	the pkgsrc files will be lost after updating. Therefore updating
 	via CVS is strongly recommended.</p>
 </div>
 <p>Note that by default the distfiles and the binary packages
 	are saved in the pkgsrc tree, so don't forget to rescue them
 	before updating. You can also configure pkgsrc to store distfiles
         and packages in directories outside the pkgsrc tree by setting the
 	<code class="varname">DISTDIR</code> and <code class="varname">PACKAGES</code>
 	variables. See <a class="xref" href="#configuring" title="Chapter 6. Configuring pkgsrc">Chapter 6, <i>Configuring pkgsrc</i></a> for the details.</p>
 <p>To update pkgsrc from a tar file, download the tar file as
 	explained above. Then, make sure that you have not made any
 	changes to the files in the pkgsrc directory. Remove the pkgsrc
 	directory and extract the new tar file. Done.</p>
 </div>
 <div class="sect2">
 <div class="titlepage"><div><div><h3 class="title">
 <a name="uptodate-cvs"></a>3.2.2. Via CVS</h3></div></div></div>
 <p>To update pkgsrc via CVS, change to the <code class="filename">pkgsrc</code> directory and run cvs:</p>
 <pre class="screen"><code class="prompt">$</code> <strong class="userinput"><code>cd /usr/pkgsrc &amp;&amp; cvs update -dP</code></strong>
 </pre>
 <p>If you get error messages from <code class="literal">rsh</code>, you need to set CVS_RSH variable as described above. E.g.:</p>
 <pre class="screen"><code class="prompt">$</code> <strong class="userinput"><code>cd /usr/pkgsrc &amp;&amp; env CVS_RSH=ssh cvs up -dP</code></strong>
 </pre>
 <div class="sect3">
 <div class="titlepage"><div><div><h4 class="title">
 <a name="uptodate-cvs-switch"></a>3.2.2.1. Switching between different pkgsrc branches</h4></div></div></div>
 <p>When updating pkgsrc, the CVS program keeps track of the
 	branch you selected. But if you, for whatever reason, want to
 	switch from the stable branch to the current one, you can do it
 	by adding the option <span class="quote">&#8220;<span class="quote">-A</span>&#8221;</span> after the
 	<span class="quote">&#8220;<span class="quote">update</span>&#8221;</span> keyword. To switch from the current branch
 	back to the stable branch, add the
 	<span class="quote">&#8220;<span class="quote">-rpkgsrc-2020Q1</span>&#8221;</span> option.</p>
 </div>
 <div class="sect3">
 <div class="titlepage"><div><div><h4 class="title">
 <a name="uptodate-cvs-changes"></a>3.2.2.2. What happens to my changes when updating?</h4></div></div></div>
 <p>When you update pkgsrc, the CVS program will only touch
 	those files that are registered in the CVS repository. That
 	means that any packages that you created on your own will stay
 	unmodified. If you change files that are managed by CVS, later
 	updates will try to merge your changes with those that have been
 	done by others. See the CVS manual, chapter
 	<span class="quote">&#8220;<span class="quote">update</span>&#8221;</span> for details.</p>
 </div>
 </div>
 </div>
 </div>
 <div class="chapter">
 <div class="titlepage"><div><div><h2 class="title">
 <a name="platforms"></a>Chapter 4. Using pkgsrc on systems other than NetBSD</h2></div></div></div>
 <div class="toc">
 <p><b>Table of Contents</b></p>
 <dl class="toc">
 <dt><span class="sect1"><a href="#binarydist">4.1. Binary distribution</a></span></dt>
 <dt><span class="sect1"><a href="#bootstrapping-pkgsrc">4.2. Bootstrapping pkgsrc</a></span></dt>
 </dl>
 </div>
 <div class="sect1">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
 <a name="binarydist"></a>4.1. Binary distribution</h2></div></div></div>
 <p>See <a class="xref" href="#using-pkg" title="5.1. Using binary packages">Section 5.1, &#8220;Using binary packages&#8221;</a>.</p>
 </div>
 <div class="sect1">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
 <a name="bootstrapping-pkgsrc"></a>4.2. Bootstrapping pkgsrc</h2></div></div></div>
 <p>pkgsrc can be bootstrapped for use in two different modes:
     privileged and unprivileged one. In unprivileged mode in contrast
     to privileged one all programs are installed under one particular user
     and cannot utilise privileged operations (packages don't create
     special users and all special file permissions like setuid are ignored).
     </p>
 <p>Installing the bootstrap kit from source should be as simple as:</p>
 <pre class="screen">
 <code class="prompt">#</code> <strong class="userinput"><code>env CVS_RSH=ssh cvs -d anoncvs@anoncvs.NetBSD.org:/cvsroot checkout -P pkgsrc</code></strong>
 <code class="prompt">#</code> <strong class="userinput"><code>cd pkgsrc/bootstrap</code></strong>
 <code class="prompt">#</code> <strong class="userinput"><code>./bootstrap</code></strong>
     </pre>
 <p>To bootstrap in unprivileged mode pass <span class="quote">&#8220;<span class="quote">--unprivileged</span>&#8221;</span> flag to <span class="command"><strong>bootstrap</strong></span></p>
 <p>By default, in privileged mode pkgsrc uses
     <code class="filename">/usr/pkg</code> for <span class="emphasis"><em>prefix</em></span>
     where programs will be installed in,
     and <code class="filename">/usr/pkg/pkgdb</code> for the package database
     directory where pkgsrc will do its internal bookkeeping,
     <code class="filename">/var</code> is used as <span class="emphasis"><em>varbase</em></span>,
     where packages install their persistent data.
     In unprivileged mode pkgsrc uses
     <code class="filename">~/pkg</code> for <span class="emphasis"><em>prefix</em></span>,
     <code class="filename">~/pkg/pkgdb</code> for the package database,
     and <code class="filename">~/pkg/var</code> for <span class="emphasis"><em>varbase</em></span>.
     </p>
 <p>You can change default layout using command-line arguments.
     Run <span class="quote">&#8220;<span class="quote">./bootstrap --help</span>&#8221;</span> to get details.
     </p>
 <div class="note" style="margin-left: 0.5in; margin-right: 0.5in;">
 <h3 class="title">Note</h3>
 <p>The bootstrap installs a <span class="command"><strong>bmake</strong></span> tool.
       Use this <span class="command"><strong>bmake</strong></span> when building via pkgsrc.
       For examples in this guide, use <span class="command"><strong>bmake</strong></span>
       instead of <span class="quote">&#8220;<span class="quote">make</span>&#8221;</span>.</p>
 </div>
 <div class="note" style="margin-left: 0.5in; margin-right: 0.5in;">
 <h3 class="title">Note</h3>
 <p>It is possible to bootstrap multiple instances of pkgsrc
       using non-intersecting directories. Use <span class="command"><strong>bmake</strong></span>
       corresponding to the installation you're working with to build
       and install packages.
       </p>
 </div>
 </div>
 </div>
 <div class="chapter">
 <div class="titlepage"><div><div><h2 class="title">
 <a name="using"></a>Chapter 5. Using pkgsrc</h2></div></div></div>
 <div class="toc">
 <p><b>Table of Contents</b></p>
 <dl class="toc">
 <dt><span class="sect1"><a href="#using-pkg">5.1. Using binary packages</a></span></dt>
 <dd><dl>
 <dt><span class="sect2"><a href="#finding-binary-packages">5.1.1. Finding binary packages</a></span></dt>
 <dt><span class="sect2"><a href="#installing-binary-packages">5.1.2. Installing binary packages</a></span></dt>
 <dt><span class="sect2"><a href="#using.pkg_delete">5.1.3. Deinstalling packages</a></span></dt>
 <dt><span class="sect2"><a href="#using.pkg_info">5.1.4. Getting information about installed packages</a></span></dt>
 <dt><span class="sect2"><a href="#vulnerabilities">5.1.5. Checking for security vulnerabilities in installed packages</a></span></dt>
 <dt><span class="sect2"><a href="#pkg_versions">5.1.6. Finding if newer versions of your installed packages are in pkgsrc</a></span></dt>
 <dt><span class="sect2"><a href="#using.pkg_admin">5.1.7. Other administrative functions</a></span></dt>
 </dl></dd>
 <dt><span class="sect1"><a href="#building-packages-from-source">5.2. Building packages from source</a></span></dt>
 <dd><dl>
 <dt><span class="sect2"><a href="#requirements">5.2.1. Requirements</a></span></dt>
 <dt><span class="sect2"><a href="#fetching-distfiles">5.2.2. Fetching distfiles</a></span></dt>
 <dt><span class="sect2"><a href="#how-to-build-and-install">5.2.3. How to build and install</a></span></dt>
 </dl></dd>
 </dl>
 </div>
 <p>Basically, there are two ways of using pkgsrc. The first
 is to only install the package tools and to use binary packages
 that someone else has prepared. This is the <span class="quote">&#8220;<span class="quote">pkg</span>&#8221;</span>
 in pkgsrc. The second way is to install the <span class="quote">&#8220;<span class="quote">src</span>&#8221;</span>
 of pkgsrc, too. Then you are able to build your own packages,
 and you can still use binary packages from someone else.</p>
 <div class="sect1">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
 <a name="using-pkg"></a>5.1. Using binary packages</h2></div></div></div>
-<p>On the <a class="ulink" href="https://cdn.NetBSD.org/" target="_top">cdn.NetBSD.org</a>
+<p>On the <a class="ulink" href="http://cdn.NetBSD.org/" target="_top">cdn.NetBSD.org</a>
   site and mirrors, there are collections of binary packages,
   ready to be installed. These binary packages have been built using the
   default settings for the directories, that is:</p>
 <div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; ">
 <li class="listitem"><p><code class="filename">/usr/pkg</code> for <code class="varname">LOCALBASE</code>, where most of the files are installed,</p></li>
 <li class="listitem"><p><code class="filename">/usr/pkg/etc</code> for configuration files,</p></li>
 <li class="listitem"><p><code class="filename">/var</code> for <code class="varname">VARBASE</code>, where those files are installed that may change after installation.</p></li>
 </ul></div>
 <p>If you cannot use these directories for whatever reasons (maybe
   because you're not root), you cannot use these binary packages, but
   have to build the packages yourself, which is explained in <a class="xref" href="#bootstrapping-pkgsrc" title="4.2. Bootstrapping pkgsrc">Section 4.2, &#8220;Bootstrapping pkgsrc&#8221;</a>.</p>
 <div class="sect2">
 <div class="titlepage"><div><div><h3 class="title">
 <a name="finding-binary-packages"></a>5.1.1. Finding binary packages</h3></div></div></div>
 <p>To install binary packages, you first need to know from where
     to get them. The first place where you should look is on the main
     pkgsrc FTP server in the directory <a class="ulink" href="https://cdn.NetBSD.org/pub/pkgsrc/packages/" target="_top"><code class="filename">/pub/pkgsrc/packages</code></a>.</p>
     pkgsrc FTP server in the directory <a class="ulink" href="http://cdn.NetBSD.org/pub/pkgsrc/packages/" target="_top"><code class="filename">/pub/pkgsrc/packages</code></a>.</p>
 <p>This directory contains binary packages for multiple
     platforms. First, select your operating system. (Ignore the
     directories with version numbers attached to it, they just exist for
     legacy reasons.) Then, select your hardware architecture, and in the
     third step, the OS version and the <span class="quote">&#8220;<span class="quote">version</span>&#8221;</span> of pkgsrc.</p>
 <p>In this directory, you often find a file called
     <code class="filename">bootstrap.tar.gz</code> which contains the package
     management tools. If the file is missing, it is likely that your
     operating system already provides those tools. Download the file and
     extract it in the <code class="filename">/</code> directory. It will create
     the directories <code class="filename">/usr/pkg</code> (containing the tools
     for managing binary packages and the database of installed packages).</p>
 </div>
 <div class="sect2">
 <div class="titlepage"><div><div><h3 class="title">
 <a name="installing-binary-packages"></a>5.1.2. Installing binary packages</h3></div></div></div>
 <p>In the directory from the last section, there is a
     subdirectory called <code class="filename">All/</code>, which contains all the
     binary packages that are available for the platform, excluding those
     that may not be distributed via FTP or CDROM (depending on which
     medium you are using).</p>
 <p>To install packages directly from an FTP or HTTP server, run
     the following commands in a Bourne-compatible shell (be sure to
     <span class="command"><strong>su</strong></span> to root first):</p>
 <pre class="screen">
 <code class="prompt">#</code> <strong class="userinput"><code>PATH="/usr/pkg/sbin:$PATH"</code></strong>
 <code class="prompt">#</code> <strong class="userinput"><code>PKG_PATH="https://cdn.NetBSD.org/pub/pkgsrc/packages"</code></strong>
 <code class="prompt">#</code> <strong class="userinput"><code>PKG_PATH="http://cdn.NetBSD.org/pub/pkgsrc/packages"</code></strong>
 <code class="prompt">#</code> <strong class="userinput"><code>PKG_PATH="$PKG_PATH/<em class="replaceable"><code>OPSYS</code></em>/<em class="replaceable"><code>ARCH</code></em>/<em class="replaceable"><code>VERSIONS</code></em>/All/"</code></strong>
 <code class="prompt">#</code> <strong class="userinput"><code>export PATH PKG_PATH</code></strong>
 </pre>
 <p>Instead of URLs, you can also use local paths, for example if
     you are installing from a set of CDROMs, DVDs or an NFS-mounted
     repository. If you want to install packages from multiple sources,
     you can separate them by a semicolon in
     <code class="varname">PKG_PATH</code>.</p>
 <p>After these preparations, installing a package is very
     easy:</p>
 <pre class="screen">
 <code class="prompt">#</code> <strong class="userinput"><code>pkg_add libreoffice</code></strong>
 <code class="prompt">#</code> <strong class="userinput"><code>pkg_add ap24-php71-*</code></strong>
 </pre>
 <p>Note that any prerequisite packages needed to run the
     package in question will be installed, too, assuming they are
     present where you install from.</p>
 <p>Adding packages might install vulnerable packages.
     Thus you should run <span class="command"><strong>pkg_admin audit</strong></span>
     regularly, especially after installing new packages, and verify
     that the vulnerabilities are acceptable for your configuration.</p>
 <p>After you've installed packages, be sure to have
     <code class="filename">/usr/pkg/bin</code> and <code class="filename">/usr/pkg/sbin</code> in your
     <code class="varname">PATH</code> so you can actually start the just
     installed program.</p>
 </div>
 <div class="sect2">
 <div class="titlepage"><div><div><h3 class="title">
 <a name="using.pkg_delete"></a>5.1.3. Deinstalling packages</h3></div></div></div>
 <p>To deinstall a package, it does not matter whether it was
     installed from source code or from a binary package. The
     <span class="command"><strong>pkg_delete</strong></span> command does not know it anyway.
     To delete a package, you can just run <span class="command"><strong>pkg_delete
     <em class="replaceable"><code>package-name</code></em></strong></span>. The package
     name can be given with or without version number. Wildcards can
     also be used to deinstall a set of packages, for example
     <code class="literal">*emacs*</code>. Be sure to include them in quotes,
     so that the shell does not expand them before
     <code class="literal">pkg_delete</code> sees them.</p>
 <p>The <code class="option">-r</code> option is very powerful: it
     removes all the packages that require the package in question
     and then removes the package itself. For example:
     </p>
 <pre class="screen">
 <code class="prompt">#</code> <strong class="userinput"><code>pkg_delete -r jpeg</code></strong>
     </pre>
 <p>
     will remove jpeg and all the packages that used it; this allows
     upgrading the jpeg package.</p>
 </div>
 <div class="sect2">
 <div class="titlepage"><div><div><h3 class="title">
 <a name="using.pkg_info"></a>5.1.4. Getting information about installed packages</h3></div></div></div>
 <p>The <span class="command"><strong>pkg_info</strong></span> shows information about
     installed packages or binary package files.</p>
 </div>
 <div class="sect2">
 <div class="titlepage"><div><div><h3 class="title">
 <a name="vulnerabilities"></a>5.1.5. Checking for security vulnerabilities in installed packages</h3></div></div></div>
 <p>
       The pkgsrc Security Team and Packages Groups maintain a list of
       known security vulnerabilities to packages which are (or have been)
       included in pkgsrc.  The list is available from the NetBSD
       FTP site at <a class="ulink" href="https://ftp.NetBSD.org/pub/NetBSD/packages/vulns/pkg-vulnerabilities" target="_top">https://ftp.NetBSD.org/pub/NetBSD/packages/vulns/pkg-vulnerabilities</a>.
       FTP site at <a class="ulink" href="http://ftp.NetBSD.org/pub/NetBSD/packages/vulns/pkg-vulnerabilities" target="_top">http://ftp.NetBSD.org/pub/NetBSD/packages/vulns/pkg-vulnerabilities</a>.
     </p>
 <p>
       Through <span class="command"><strong>pkg_admin fetch-pkg-vulnerabilities</strong></span>,
       this list can be downloaded
       automatically, and a security audit of all packages installed on a system
       can take place.
     </p>
 <p>
       There are two components to auditing.  The first
       step, <span class="command"><strong>pkg_admin fetch-pkg-vulnerabilities</strong></span>,
       is for downloading
       the list of vulnerabilities from the NetBSD FTP site.  The second
       step, <span class="command"><strong>pkg_admin audit</strong></span>, checks to see if any of your
       installed packages are vulnerable.  If a package is vulnerable, you
       will see output similar to the following:
     </p>
 <pre class="screen">Package samba-2.0.9 has a local-root-shell vulnerability, see
     https://www.samba.org/samba/whatsnew/macroexploit.html</pre>
 <p>
       You may wish to have the
       <a class="ulink" href="https://ftp.NetBSD.org/pub/pkgsrc/distfiles/vulnerabilities" target="_top">vulnerabilities</a>
       <a class="ulink" href="http://ftp.NetBSD.org/pub/pkgsrc/distfiles/vulnerabilities" target="_top">vulnerabilities</a>
       file downloaded daily so that
       it remains current.  This may be done by adding an appropriate entry
       to the root users <a class="citerefentry" href="https://netbsd.gw.com/cgi-bin/man-cgi?crontab+5.i386+NetBSD-9.0"><span class="citerefentry"><span class="refentrytitle">crontab</span>(5)</span></a> entry.  For example the entry
       </p>
 <pre class="screen">
 # Download vulnerabilities file
 3 * * * /usr/pkg/sbin/pkg_admin fetch-pkg-vulnerabilities &gt;/dev/null 2&gt;&amp;1
 # Audit the installed packages and email results to root
 3 * * * /usr/pkg/sbin/pkg_admin audit |mail -s "Installed package audit result" \
 	    root &gt;/dev/null 2&gt;&amp;1
       </pre>
 <p>
       will update the vulnerability list every day at 3AM, followed by an audit
       at 3:09AM. The result of the audit are then emailed to root.
       On NetBSD this may be accomplished instead by adding the following
       line to <code class="filename">/etc/daily.conf</code>:
       </p>
 <pre class="screen">
 fetch_pkg_vulnerabilities=YES
       </pre>
 <p>
       to fetch the vulnerability list from the daily security script. The system
       is set to audit the packages by default but can be set explicitly, if
       desired (not required), by adding the following line to
 <code class="filename">/etc/security.conf</code>:
       </p>
 <pre class="screen">
 check_pkg_vulnerabilities=YES
       </pre>
 <p>
       see <a class="citerefentry" href="https://netbsd.gw.com/cgi-bin/man-cgi?daily.conf+5.i386+NetBSD-9.0"><span class="citerefentry"><span class="refentrytitle">daily.conf</span>(5)</span></a> and <a class="citerefentry" href="https://netbsd.gw.com/cgi-bin/man-cgi?security.conf+5.i386+NetBSD-9.0"><span class="citerefentry"><span class="refentrytitle">security.conf</span>(5)</span></a> for more details.
     </p>
 </div>
 <div class="sect2">
 <div class="titlepage"><div><div><h3 class="title">
 <a name="pkg_versions"></a>5.1.6. Finding if newer versions of your installed packages are in pkgsrc</h3></div></div></div>
 <p>
       Install <a href="https://cdn.NetBSD.org/pub/pkgsrc/current/pkgsrc/pkgtools/lintpkgsrc/README.html" target="_top"><code class="filename">pkgtools/lintpkgsrc</code></a> and run
       <span class="command"><strong>lintpkgsrc</strong></span> with the <span class="quote">&#8220;<span class="quote">-i</span>&#8221;</span>
       argument to check if your packages are up-to-date, e.g.
     </p>
 <pre class="screen">
 <code class="prompt">%</code> <strong class="userinput"><code>lintpkgsrc -i</code></strong>
 ...
 Version mismatch: 'tcsh' 6.09.00 vs 6.10.00
     </pre>
 <p>You can then use <span class="command"><strong>make update</strong></span> to update the
     package on your system and rebuild any dependencies.
     </p>
 </div>
 <div class="sect2">
 <div class="titlepage"><div><div><h3 class="title">
 <a name="using.pkg_admin"></a>5.1.7. Other administrative functions</h3></div></div></div>
 <p>The <span class="command"><strong>pkg_admin</strong></span> executes various
     administrative functions on the package system.</p>
 </div>
 </div>
 <div class="sect1">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
 <a name="building-packages-from-source"></a>5.2. Building packages from source</h2></div></div></div>
 <p>After obtaining pkgsrc, the <code class="filename">pkgsrc</code>
   directory now contains a set of packages, organized into
   categories. You can browse the online index of packages, or run
   <span class="command"><strong>make readme</strong></span> from the <code class="filename">pkgsrc</code>
   directory to build local <code class="filename">README.html</code> files for
   all packages, viewable with any web browser such as <a href="https://cdn.NetBSD.org/pub/pkgsrc/current/pkgsrc/www/lynx/README.html" target="_top"><code class="filename">www/lynx</code></a> or <a href="https://cdn.NetBSD.org/pub/pkgsrc/current/pkgsrc/www/firefox/README.html" target="_top"><code class="filename">www/firefox</code></a>.</p>
 <p>The default <span class="emphasis"><em>prefix</em></span> for installed packages
   is <code class="filename">/usr/pkg</code>. If you wish to change this, you
   should do so by setting <code class="varname">LOCALBASE</code> in
   <a class="link" href="#mk.conf"><code class="filename">mk.conf</code></a>. You should not try to use multiple
   different <code class="varname">LOCALBASE</code> definitions on the same
   system (inside a chroot is an exception). </p>
 <p>The rest of this chapter assumes that the package is already
   in pkgsrc. If it is not, see <a class="xref" href="#developers-guide" title="Part II. The pkgsrc developer's guide">Part II, &#8220;The pkgsrc developer's guide&#8221;</a> for
   instructions how to create your own packages.</p>
 <div class="sect2">
 <div class="titlepage"><div><div><h3 class="title">
 <a name="requirements"></a>5.2.1. Requirements</h3></div></div></div>
 <p>To build packages from source, you need a working C
     compiler. On NetBSD, you need to install the
     <span class="quote">&#8220;<span class="quote">comp</span>&#8221;</span> and the <span class="quote">&#8220;<span class="quote">text</span>&#8221;</span> distribution
     sets. If you want to build X11-related packages, the
     <span class="quote">&#8220;<span class="quote">xbase</span>&#8221;</span> and <span class="quote">&#8220;<span class="quote">xcomp</span>&#8221;</span> distribution
     sets are required, too.</p>
 </div>
 <div class="sect2">
 <div class="titlepage"><div><div><h3 class="title">
 <a name="fetching-distfiles"></a>5.2.2. Fetching distfiles</h3></div></div></div>
 <p>The first step for building a package is downloading the
     distfiles (i.e. the unmodified source). If they have not yet been
     downloaded, pkgsrc will fetch them automatically.</p>
 <p>If you have all files that you need in the
     <code class="filename">distfiles</code> directory,
     you don't need to connect. If the distfiles are on CD-ROM, you can
     mount the CD-ROM on <code class="filename">/cdrom</code> and add:
     </p>
 <pre class="screen">DISTDIR=/cdrom/pkgsrc/distfiles</pre>
 <p>
     to your <a class="link" href="#mk.conf"><code class="filename">mk.conf</code></a>.</p>
 <p>By default a list of distribution sites will be randomly
     intermixed to prevent huge load on servers which holding popular
     packages (for example, SourceForge.net mirrors). Thus, every
     time when you need to fetch yet another distfile all the mirrors
     will be tried in new (random) order. You can turn this feature
     off by setting <code class="varname">MASTER_SORT_RANDOM=NO</code> (for
     <code class="varname">PKG_DEVELOPER</code>s it's already disabled).</p>
 <p>You can overwrite some of the major distribution sites to
     fit to sites that are close to your own.  By setting one or two
     variables you can modify the order in which the master sites are
     accessed.  <code class="varname">MASTER_SORT</code> contains a whitespace
     delimited list of domain suffixes.
     <code class="varname">MASTER_SORT_REGEX</code> is even more flexible, it
     contains a whitespace delimited list of regular expressions.  It
     has higher priority than <code class="varname">MASTER_SORT</code>.  Have a
     look at <code class="filename">pkgsrc/mk/defaults/mk.conf</code> to find
     some examples.  This may save some of your bandwidth and
     time.</p>
 <p>You can change these settings either in your shell's environment, or,
     if you want to keep the settings, by editing the
     <a class="link" href="#mk.conf"><code class="filename">mk.conf</code></a> file,
     and adding the definitions there.</p>
 <p>
       If a package depends on many other packages (such as
       <a href="https://cdn.NetBSD.org/pub/pkgsrc/current/pkgsrc/meta-pkgs/kde4/README.html" target="_top"><code class="filename">meta-pkgs/kde4</code></a>), the build process may
       alternate between periods of
       downloading source, and compiling. To ensure you have all the source
       downloaded initially you can run the command:
       </p>
 <pre class="screen"><code class="prompt">%</code> <strong class="userinput"><code>make fetch-list | sh</code></strong></pre>
 <p>
       which will output and run a set of shell commands to fetch the
       necessary files into the <code class="filename">distfiles</code> directory.  You can
       also choose to download the files manually.
     </p>
 </div>
 <div class="sect2">
 <div class="titlepage"><div><div><h3 class="title">
 <a name="how-to-build-and-install"></a>5.2.3. How to build and install</h3></div></div></div>
 <p>
       Once the software has downloaded, any patches will be applied, then it
       will be compiled for you. This may take some time depending on your
       computer, and how many other packages the software depends on and their
       compile time.
     </p>
 <div class="note" style="margin-left: 0.5in; margin-right: 0.5in;">
 <h3 class="title">Note</h3>
 <p>If using bootstrap or pkgsrc on a non-NetBSD system,
     use the pkgsrc <span class="command"><strong>bmake</strong></span> command instead of
     <span class="quote">&#8220;<span class="quote">make</span>&#8221;</span> in the examples in this guide.</p>
 </div>
 <p>For example, type</p>
 <pre class="screen">
 <code class="prompt">%</code> <strong class="userinput"><code>cd misc/figlet</code></strong>
 <code class="prompt">%</code> <strong class="userinput"><code>make</code></strong>
     </pre>
 <p>at the shell prompt to build the various components of the
     package.</p>
 <p>The next stage is to actually install the newly compiled
     program onto your system. Do this by entering:
     </p>
 <pre class="screen">
 <code class="prompt">%</code> <strong class="userinput"><code>make install</code></strong>
     </pre>
 <p>
     while you are still in the directory for whatever package you
     are installing.</p>
 <p>Installing the package on your system may require you to
     be root.  However, pkgsrc has a
     <span class="emphasis"><em>just-in-time-su</em></span> feature, which allows you
     to only become root for the actual installation step.</p>
 <p>That's it, the software should now be installed and setup for use.
     You can now enter:
     </p>
 <pre class="screen">
 <code class="prompt">%</code> <strong class="userinput"><code>make clean</code></strong>
     </pre>
 <p>
     to remove the compiled files in the work directory, as you shouldn't need
     them any more. If other packages were also added to your system
     (dependencies) to allow your program to compile, you can tidy these up
     also with the command:</p>
 <pre class="screen">
 <code class="prompt">%</code> <strong class="userinput"><code>make clean-depends</code></strong>
     </pre>
 <p>Taking the figlet utility as an example, we can install it on our
     system by building as shown in <a class="xref" href="#logs" title="Appendix B. Build logs">Appendix B, <i>Build logs</i></a>.</p>
 <p>The program is installed under the default root of the
     packages tree - <code class="filename">/usr/pkg</code>. Should this not
     conform to your tastes, set the <code class="varname">LOCALBASE</code>
     variable in your environment, and it will use that value as the
     root of your packages tree. So, to use
     <code class="filename">/usr/local</code>, set
     <code class="varname">LOCALBASE=/usr/local</code> in your environment.
     Please note that you should use a directory which is dedicated to
     packages and not shared with other programs (i.e., do not try and
     use <code class="varname">LOCALBASE=/usr</code>).  Also, you should not try
     to add any of your own files or directories (such as
     <code class="filename">src/</code>, <code class="filename">obj/</code>, or
     <code class="filename">pkgsrc/</code>) below the
     <code class="varname">LOCALBASE</code> tree.  This is to prevent possible
     conflicts between programs and other files installed by the
     package system and whatever else may have been installed
     there.</p>
 <p>Some packages look in <a class="link" href="#mk.conf"><code class="filename">mk.conf</code></a> to
     alter some configuration options at build time.  Have a look at
     <code class="filename">pkgsrc/mk/defaults/mk.conf</code> to get an overview
     of what will be set there by default.  Environment variables such
     as <code class="varname">LOCALBASE</code> can be set in
     <a class="link" href="#mk.conf"><code class="filename">mk.conf</code></a> to save having to remember to
     set them each time you want to use pkgsrc.</p>
 <p>Occasionally, people want to <span class="quote">&#8220;<span class="quote">look under the
     covers</span>&#8221;</span> to see what is going on when a package is building
     or being installed. This may be for debugging purposes, or out of
     simple curiosity. A number of utility values have been added to
     help with this.</p>
 <div class="orderedlist"><ol class="orderedlist" type="1">
 <li class="listitem">
 <p>If you invoke the <a class="citerefentry" href="https://netbsd.gw.com/cgi-bin/man-cgi?make+1.i386+NetBSD-9.0"><span class="citerefentry"><span class="refentrytitle">make</span>(1)</span></a> command with
 	<code class="varname">PKG_DEBUG_LEVEL=2</code>, then a huge amount of
 	information will be displayed. For example,</p>
 <pre class="screen"><strong class="userinput"><code>make patch PKG_DEBUG_LEVEL=2</code></strong></pre>
 <p>will show all the commands that are invoked, up to and
 	including the <span class="quote">&#8220;<span class="quote">patch</span>&#8221;</span> stage.</p>
 </li>
 <li class="listitem">
 <p>If you want to know the value of a certain <a class="citerefentry" href="https://netbsd.gw.com/cgi-bin/man-cgi?make+1.i386+NetBSD-9.0"><span class="citerefentry"><span class="refentrytitle">make</span>(1)</span></a>
 	definition, then the <code class="varname">VARNAME</code> definition
 	should be used, in conjunction with the show-var
 	target. e.g. to show the expansion of the <a class="citerefentry" href="https://netbsd.gw.com/cgi-bin/man-cgi?make+1.i386+NetBSD-9.0"><span class="citerefentry"><span class="refentrytitle">make</span>(1)</span></a>
 	variable <code class="varname">LOCALBASE</code>:</p>
 <pre class="screen">
 <code class="prompt">%</code> <strong class="userinput"><code>make show-var VARNAME=LOCALBASE</code></strong>
 /usr/pkg
 <code class="prompt">%</code>
 	</pre>
 </li>
 </ol></div>
 <p>If you want to install a binary package that you've either
     created yourself (see next section), that you put into
     pkgsrc/packages manually or that is located on a remote FTP
     server, you can use the "bin-install" target. This target will
     install a binary package - if available - via <a class="citerefentry" href="https://netbsd.gw.com/cgi-bin/man-cgi?pkg_add+1.i386+NetBSD-9.0"><span class="citerefentry"><span class="refentrytitle">pkg_add</span>(1)</span></a>,
     else do a <span class="command"><strong>make package</strong></span>.  The list of remote FTP
     sites searched is kept in the variable
     <code class="varname">BINPKG_SITES</code>, which defaults to
     ftp.NetBSD.org. Any flags that should be added to <a class="citerefentry" href="https://netbsd.gw.com/cgi-bin/man-cgi?pkg_add+1.i386+NetBSD-9.0"><span class="citerefentry"><span class="refentrytitle">pkg_add</span>(1)</span></a>
     can be put into <code class="varname">BIN_INSTALL_FLAGS</code>.  See
     <code class="filename">pkgsrc/mk/defaults/mk.conf</code> for more
     details.</p>
 <p>A final word of warning: If you set up a system that has a
     non-standard setting for <code class="varname">LOCALBASE</code>, be sure to
     set that before any packages are installed, as you cannot use
     several directories for the same purpose. Doing so will result in
     pkgsrc not being able to properly detect your installed packages,
     and fail miserably. Note also that precompiled binary packages are
     usually built with the default <code class="varname">LOCALBASE</code> of
     <code class="filename">/usr/pkg</code>, and that you should
     <span class="emphasis"><em>not</em></span> install any if you use a non-standard
     <code class="varname">LOCALBASE</code>.</p>
 </div>
 </div>
 </div>
 <div class="chapter">
 <div class="titlepage"><div><div><h2 class="title">
 <a name="configuring"></a>Chapter 6. Configuring pkgsrc</h2></div></div></div>
 <div class="toc">
 <p><b>Table of Contents</b></p>
 <dl class="toc">
 <dt><span class="sect1"><a href="#general-configuration">6.1. General configuration</a></span></dt>
 <dt><span class="sect1"><a href="#variables-affecting-build">6.2. Variables affecting the build process</a></span></dt>
 <dt><span class="sect1"><a href="#variables-affecting-installation">6.3. Variables affecting the installation process</a></span></dt>
 <dt><span class="sect1"><a href="#conf.compiler">6.4. Selecting and configuring the compiler</a></span></dt>
 <dd><dl>
 <dt><span class="sect2"><a href="#selecting-the-compiler">6.4.1. Selecting the compiler</a></span></dt>
 <dt><span class="sect2"><a href="#conf.cflags">6.4.2. Additional flags to the compiler (<code class="varname">CFLAGS</code>)</a></span></dt>
 <dt><span class="sect2"><a href="#conf.ldflags">6.4.3. Additional flags to the linker (<code class="varname">LDFLAGS</code>)</a></span></dt>
 </dl></dd>
 <dt><span class="sect1"><a href="#developer-advanced-settings">6.5. Developer/advanced settings</a></span></dt>
 <dt><span class="sect1"><a href="#selecting-build-options">6.6. Selecting Build Options</a></span></dt>
 </dl>
 </div>
 <a name="mk.conf"></a><p>The whole pkgsrc system is configured in a single file, usually
 called <code class="filename">mk.conf</code>. In which directory pkgsrc looks for
 that file depends on the installation. On NetBSD, when you use
 <a class="citerefentry" href="https://netbsd.gw.com/cgi-bin/man-cgi?make+1.i386+NetBSD-9.0"><span class="citerefentry"><span class="refentrytitle">make</span>(1)</span></a> from the base system, it is in the directory
 <code class="filename">/etc/</code>. In all other cases the default location is
 <code class="literal">${PREFIX}/etc/</code>, depending on where you told the
 bootstrap program to install the binary packages.</p>
 <p>The format of the configuration file is that of the usual
 BSD-style <code class="filename">Makefile</code>s. The whole pkgsrc configuration
 is done by setting variables in this file. Note that you can define all
 kinds of variables, and no special error checking (for example for
 spelling mistakes) takes place.</p>
 <div class="sect1">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
 <a name="general-configuration"></a>6.1. General configuration</h2></div></div></div>
 <p>The following variables apply to all
     pkgsrc packages. A complete list of the variables that can be
     configured by the user is available in
     <code class="filename">mk/defaults/mk.conf</code>, together with some
     comments that describe each variable's intent.</p>
 <div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; ">
 <li class="listitem"><p><code class="varname">LOCALBASE</code>: Where
 	    packages will be installed. The default is
 	    <code class="filename">/usr/pkg</code>. Do not mix binary packages
 	    with different <code class="varname">LOCALBASE</code>s!</p></li>
 <li class="listitem"><p><code class="varname">CROSSBASE</code>: Where
 	    <span class="quote">&#8220;<span class="quote">cross</span>&#8221;</span> category packages will be
 	    installed. The default is
 	    <code class="filename">${LOCALBASE}/cross</code>.</p></li>
 <li class="listitem"><p><code class="varname">X11BASE</code>: Where
 	    X11 is installed on the system. The default is
 	    <code class="filename">/usr/X11R7</code>.</p></li>
 <li class="listitem"><p><code class="varname">DISTDIR</code>: Where to store the
 	    downloaded copies of the original source distributions used
 	    for building pkgsrc packages. The default is
 	    <code class="filename">${PKGSRCDIR}/distfiles</code>.</p></li>
 <li class="listitem"><p><code class="varname">PKG_DBDIR</code>: Where the
 	    database about installed packages is stored.  The default is
 	    <code class="filename">/usr/pkg/pkgdb</code>.</p></li>
 <li class="listitem"><p><code class="varname">MASTER_SITE_OVERRIDE</code>:
 	    If set, override the packages'
 	    <code class="varname">MASTER_SITES</code> with this value.</p></li>
 <li class="listitem"><p><code class="varname">MASTER_SITE_BACKUP</code>:
 	    Backup location(s) for distribution files and patch files
 	    if not found locally or in
 	    <code class="filename">${MASTER_SITES}</code> or
 	    <code class="filename">${PATCH_SITES}</code> respectively.
 	    The defaults is
 	    <code class="filename">ftp://ftp.NetBSD.org/pub/pkgsrc/distfiles/${DIST_SUBDIR}/</code>.</p></li>
 <li class="listitem"><p><code class="varname">BINPKG_SITES</code>:
 	    List of sites carrying binary pkgs. <em class="replaceable"><code>rel</code></em> and
 	    <em class="replaceable"><code>arch</code></em> are replaced with OS
 	    release (<span class="quote">&#8220;<span class="quote">2.0</span>&#8221;</span>, etc.) and architecture
 	    (<span class="quote">&#8220;<span class="quote">mipsel</span>&#8221;</span>, etc.).</p></li>
 <li class="listitem"><p><code class="varname">ACCEPTABLE_LICENSES</code>:
 	    List of acceptable licenses. License names are case-sensitive.
 	    Whenever you try to build a package whose license is not in this
 	    list, you will get an error message. If the license condition is
 	    simple enough, the error message will include specific
 	    instructions on how to change this variable.</p></li>
 </ul></div>
 </div>
 <div class="sect1">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
 <a name="variables-affecting-build"></a>6.2. Variables affecting the build process</h2></div></div></div>
 <p>
       </p>
 <div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; ">
 <li class="listitem"><p><code class="varname">PACKAGES</code>: The top level
 	    directory for the binary packages. The default is
 	    <code class="filename">${PKGSRCDIR}/packages</code>.</p></li>
 <li class="listitem"><p><code class="varname">WRKOBJDIR</code>:
 	    The top level directory where, if defined, the separate
 	    working directories will get created, and symbolically
 	    linked to from <code class="filename">${WRKDIR}</code> (see below).
 	    This is useful for building packages on several
 	    architectures, then <code class="filename">${PKGSRCDIR}</code>
 	    can be NFS-mounted while <code class="filename">${WRKOBJDIR}</code>
 	    is local to every architecture. (It should be noted that
 	    <code class="varname">PKGSRCDIR</code> should not be set by the user
 	    &mdash; it is an internal definition which refers to the
 	    root of the pkgsrc tree. It is possible to have many
 	    pkgsrc tree instances.)</p></li>
 <li class="listitem"><p><code class="varname">LOCALPATCHES</code>:
 	    Directory for local patches that aren't part of pkgsrc.
 	    See <a class="xref" href="#components.patches" title="13.3. patches/*">Section 13.3, &#8220;<code class="filename">patches/*</code>&#8221;</a> for more
 	    information.</p></li>
 <li class="listitem"><p><code class="varname">PKGMAKECONF</code>: Location of
 	    the <a class="link" href="#mk.conf"><code class="filename">mk.conf</code></a> file used by a package's
 	    BSD-style Makefile. If this is not set,
 	    <code class="varname">MAKECONF</code> is set to
 	    <code class="filename">/dev/null</code> to avoid picking up
 	    settings used by builds in <code class="filename">/usr/src</code>.</p></li>
 </ul></div>
 </div>
 <div class="sect1">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
 <a name="variables-affecting-installation"></a>6.3. Variables affecting the installation process</h2></div></div></div>
 <div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; "><li class="listitem"><p><code class="varname">PKGSRC_KEEP_BIN_PKGSRC</code>:
                 By default, binary packages of built packages are
                 preserved in <code class="filename">${PACKAGES}/All</code>. Setting
 		this variable to "no" prevents this.</p></li></ul></div>
 <p>Packages have to support installation into a
     subdirectory of <code class="varname">WRKDIR</code>. This allows a package
     to be built, before the actual filesystem is touched. DESTDIR
     support exists in two variations:</p>
 <div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; ">
 <li class="listitem"><p>Basic DESTDIR support means that the package
       installation and packaging is still run as root.</p></li>
 <li class="listitem"><p>Full DESTDIR support can run the complete
       build, installation and packaging as normal user. Root
       privileges are only needed to add packages.</p></li>
 </ul></div>
 <p>With basic DESTDIR support, <strong class="userinput"><code>make
     clean</code></strong> needs to be run as root.</p>
 <p>Considering the <code class="filename">foo/bar</code> package,
     DESTDIR full support can be tested using the following commands
 </p>
 <pre class="programlisting">
 <code class="prompt">$</code> id
 uid=1000(myusername) gid=100(users) groups=100(users),0(wheel)
 <code class="prompt">$</code> mkdir $HOME/packages
 <code class="prompt">$</code> cd $PKGSRCDIR/foo/bar
 </pre>
 <p>
     Verify <code class="varname">DESTDIR</code> full support, no root privileges
     should be needed
 </p>
 <pre class="programlisting">
 <code class="prompt">$</code> make stage-install
 </pre>
 <p>
     Create a package without root privileges
 </p>
 <pre class="programlisting">
 <code class="prompt">$</code> make PACKAGES=$HOME/packages package
 </pre>
 <p>
     For the following command, you must be able to gain root
     privileges using <a class="citerefentry" href="https://netbsd.gw.com/cgi-bin/man-cgi?su+1.i386+NetBSD-9.0"><span class="citerefentry"><span class="refentrytitle">su</span>(1)</span></a>
 </p>
 <pre class="programlisting">
 <code class="prompt">$</code> make PACKAGES=$HOME/packages install
 </pre>
 <p>
     Then, as a simple user
 </p>
 <pre class="programlisting">
 <code class="prompt">$</code> make clean
 </pre>
 <p>
     </p>
 </div>
 <div class="sect1">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
 <a name="conf.compiler"></a>6.4. Selecting and configuring the compiler</h2></div></div></div>
 <div class="sect2">
 <div class="titlepage"><div><div><h3 class="title">
 <a name="selecting-the-compiler"></a>6.4.1. Selecting the compiler</h3></div></div></div>
 <p>By default, pkgsrc will use GCC to build packages.  This may be
     overridden by setting the following variables in /etc/mk.conf:</p>
 <div class="variablelist"><dl class="variablelist">
 <dt><span class="term"><code class="varname">PKGSRC_COMPILER</code>:</span></dt>
 <dd>
 <p>This is a list of values specifying the chain of
 	  compilers to invoke when building packages.  Valid values
 	  are:</p>
 <div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; ">
 <li class="listitem"><p><code class="varname">ccc</code>:
 	    Compaq C Compilers (Tru64)</p></li>
 <li class="listitem"><p><code class="varname">ccache</code>:
 	    compiler cache (chainable)</p></li>
 <li class="listitem"><p><code class="varname">clang</code>:
 	    Clang C and Objective-C compiler</p></li>
 <li class="listitem"><p><code class="varname">distcc</code>:
 	    distributed C/C++ (chainable)</p></li>
 <li class="listitem"><p><code class="varname">f2c</code>:
 	    Fortran 77 to C compiler (chainable)</p></li>
 <li class="listitem"><p><code class="varname">icc</code>:
 	    Intel C++ Compiler (Linux)</p></li>
 <li class="listitem"><p><code class="varname">ido</code>:
 	    SGI IRIS Development Option cc (IRIX 5)</p></li>
 <li class="listitem"><p><code class="varname">gcc</code>:
 	    GNU C/C++ Compiler</p></li>
 <li class="listitem"><p><code class="varname">hp</code>:
 	    HP-UX C/aC++ compilers</p></li>
 <li class="listitem"><p><code class="varname">mipspro</code>:
 	    Silicon Graphics, Inc. MIPSpro (n32/n64)</p></li>
 <li class="listitem"><p><code class="varname">mipspro-ucode</code>:
 	    Silicon Graphics, Inc. MIPSpro (o32)</p></li>
 <li class="listitem"><p><code class="varname">sunpro</code>:
 	    Sun Microsystems, Inc. WorkShip/Forte/Sun ONE Studio</p></li>
 <li class="listitem"><p><code class="varname">xlc</code>:
 	    IBM's XL C/C++ compiler suite</p></li>
 </ul></div>
 <p>The default is
 	  <span class="quote">&#8220;<span class="quote"><code class="varname">gcc</code></span>&#8221;</span>.  You can use
 	  <code class="varname">ccache</code> and/or
 	  <code class="varname">distcc</code> with an appropriate
 	  <code class="varname">PKGSRC_COMPILER</code> setting,
 	  e.g. <span class="quote">&#8220;<span class="quote"><code class="varname">ccache gcc</code></span>&#8221;</span>.  This
 	  variable should always be terminated with a value for
 	  a real compiler.  Note that only one real compiler
 	  should be listed (e.g. <span class="quote">&#8220;<span class="quote"><code class="varname">sunpro gcc</code></span>&#8221;</span>
 	  is not allowed).</p>
 </dd>
 <dt><span class="term"><code class="varname">GCC_REQD</code>:</span></dt>
 <dd><p>This specifies the minimum version of GCC to use
 	  when building packages.  If the system GCC doesn't
 	  satisfy this requirement, then pkgsrc will build and
 	  install one of the GCC packages to use instead.</p></dd>
 <dt><span class="term"><code class="varname">PYTHON_VERSION_DEFAULT</code>:</span></dt>
 <dd><p>Specifies which version of python to use when several
 	  options are available.</p></dd>
 <dt><span class="term"><code class="varname">PKGSRC_FORTRAN</code>:</span></dt>
 <dd><p>Specifies the Fortran compiler to use.
 	  The default is <code class="varname">gfortran</code>.</p></dd>
 <dt><span class="term"><code class="varname">GFORTRAN_VERSION</code>:</span></dt>
 <dd><p>If <code class="varname">PKGSRC_FORTRAN</code><code class="literal">=</code>
 	  <code class="varname">gfortran</code> is used, this option specifies which
 	  version to use.</p></dd>
 </dl></div>
 </div>
 <div class="sect2">
 <div class="titlepage"><div><div><h3 class="title">
 <a name="conf.cflags"></a>6.4.2. Additional flags to the compiler (<code class="varname">CFLAGS</code>)</h3></div></div></div>
 <p>If you wish to set the <code class="varname">CFLAGS</code> variable,
 	please make sure to use the <code class="literal">+=</code> operator
 	instead of the <code class="literal">=</code> operator:</p>
 <pre class="programlisting">
 CFLAGS+=        -your -flags
 </pre>
 <p>Using <code class="varname">CFLAGS=</code> (i.e. without the
 	<span class="quote">&#8220;<span class="quote">+</span>&#8221;</span>) may lead to problems with packages that
 	need to add their own flags.  You may want to take a look
 	at the <a href="https://cdn.NetBSD.org/pub/pkgsrc/current/pkgsrc/devel/cpuflags/README.html" target="_top"><code class="filename">devel/cpuflags</code></a>
 	package if you're interested in optimization specifically
 	for the current CPU. </p>
 </div>
 <div class="sect2">
 <div class="titlepage"><div><div><h3 class="title">
 <a name="conf.ldflags"></a>6.4.3. Additional flags to the linker (<code class="varname">LDFLAGS</code>)</h3></div></div></div>
 <p>If you want to pass flags to the linker, both in the configure
 step and the build step, you can do this in two ways.  Either set
 <code class="varname">LDFLAGS</code> or <code class="varname">LIBS</code>.  The difference
 between the two is that <code class="varname">LIBS</code> will be appended to
 the command line, while <code class="varname">LDFLAGS</code> come earlier.
 <code class="varname">LDFLAGS</code> is pre-loaded with rpath settings for ELF
 machines depending on the setting of <code class="varname">USE_IMAKE</code> or
 the inclusion of <code class="filename">mk/x11.buildlink3.mk</code>.  As with
 <code class="varname">CFLAGS</code>, if you do not wish to override these
 settings, use the <code class="literal">+=</code> operator:</p>
 <pre class="programlisting">
 LDFLAGS+=        -your -linkerflags
 </pre>
 </div>
 </div>
 <div class="sect1">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
 <a name="developer-advanced-settings"></a>6.5. Developer/advanced settings</h2></div></div></div>
 <p>
       </p>
 <div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; ">
 <li class="listitem">
 <p><code class="varname">PKG_DEVELOPER</code>:
 	    Run some sanity checks that package developers want:
 	    </p>
 <div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: circle; ">
 <li class="listitem"><p>make sure patches apply with zero
 	      fuzz</p></li>
 <li class="listitem"><p>run check-shlibs to see that all
 	      binaries will find their shared libs.</p></li>
 </ul></div>
 <p>
 	</p>
 </li>
 <li class="listitem"><p><code class="varname">PKG_DEBUG_LEVEL</code>: The level
 	of debugging output which is displayed whilst making and
 	installing the package.  The default value for this is 0,
 	which will not display the commands as they are executed
 	(normal, default, quiet operation); the value 1 will display
 	all shell commands before their invocation, and the value 2
 	will display both the shell commands before their invocation,
 	as well as their actual execution progress with <span class="command"><strong>set
 	-x</strong></span>.</p></li>
 </ul></div>
 <p>
     </p>
 </div>
 <div class="sect1">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
 <a name="selecting-build-options"></a>6.6. Selecting Build Options</h2></div></div></div>
 <p>Some packages have build time options, usually to select
     between different dependencies, enable optional support for big
     dependencies or enable experimental features.</p>
 <p>To see which options, if any, a package supports, and which
     options are mutually exclusive, run <span class="command"><strong>make
     show-options</strong></span>, for example:</p>
 <pre class="programlisting">
     The following options are supported by this package:
         ssl      Enable SSL support.
     Exactly one of the following gecko options is required:
         firefox  Use firefox as gecko rendering engine.
         mozilla  Use mozilla as gecko rendering engine.
     At most one of the following database options may be selected:
         mysql    Enable support for MySQL database.
         pgsql    Enable support for PostgreSQL database.
     These options are enabled by default: firefox
     These options are currently enabled: mozilla ssl
 </pre>
 <p>The following variables can be defined in
     <a class="link" href="#mk.conf"><code class="filename">mk.conf</code></a> to select which options to
     enable for a package: <code class="varname">PKG_DEFAULT_OPTIONS</code>,
     which can be used to select or disable options for all packages
     that support them, and
     <code class="varname">PKG_OPTIONS.<em class="replaceable"><code>pkgbase</code></em></code>,
     which can be used to select or disable options specifically for
     package <em class="replaceable"><code>pkgbase</code></em>.  Options listed in
     these variables are selected, options preceded by <span class="quote">&#8220;<span class="quote">-</span>&#8221;</span>
     are disabled. A few examples:</p>
 <pre class="screen">
 <code class="prompt">$</code> <span class="command"><strong>grep "PKG.*OPTION" <a class="link" href="#mk.conf"><code class="filename">mk.conf</code></a></strong></span>
 PKG_DEFAULT_OPTIONS=    -arts -dvdread -esound
 PKG_OPTIONS.kdebase=    debug -sasl
 PKG_OPTIONS.apache=     suexec </pre>
 <p>It is important to note that options that were specifically
     suggested by the package maintainer must be explicitly removed if
     you do not wish to include the option.  If you are unsure you can view
     the current state with <span class="command"><strong>make show-options</strong></span>.</p>
 <p>The following settings are consulted in the order given, and
     the last setting that selects or disables an option is
     used:</p>
 <div class="orderedlist"><ol class="orderedlist" type="1">
 <li class="listitem"><p>the default options as suggested by the package
       maintainer</p></li>
 <li class="listitem"><p>the options implied by the settings of legacy
       variables (see below)</p></li>
 <li class="listitem"><p><code class="varname">PKG_DEFAULT_OPTIONS</code></p></li>
 <li class="listitem"><p><code class="varname">PKG_OPTIONS.<em class="replaceable"><code>pkgbase</code></em></code></p></li>
 </ol></div>
 <p>For groups of mutually exclusive options, the last option
     selected is used, all others are automatically disabled.  If an
     option of the group is explicitly disabled, the previously
     selected option, if any, is used.  It is an error if no option
     from a required group of options is selected, and building the
     package will fail.</p>
 <p>Before the options framework was introduced, build options
     were selected by setting a variable (often named
     <code class="varname">USE_<em class="replaceable"><code>FOO</code></em></code>) in
     <a class="link" href="#mk.conf"><code class="filename">mk.conf</code></a> for each option.  To ease
     transition to the options framework for the user, these legacy
     variables are converted to the appropriate options setting
     (<code class="varname">PKG_OPTIONS.<em class="replaceable"><code>pkgbase</code></em></code>)
     automatically.  A warning is issued to prompt the user to update
     <a class="link" href="#mk.conf"><code class="filename">mk.conf</code></a> to use the options framework
     directly.  Support for the legacy variables will be removed
     eventually.</p>
 </div>
 </div>
 <div class="chapter">
 <div class="titlepage"><div><div><h2 class="title">
 <a name="binary"></a>Chapter 7. Creating binary packages</h2></div></div></div>
 <div class="toc">
 <p><b>Table of Contents</b></p>
 <dl class="toc">
 <dt><span class="sect1"><a href="#building-a-single-binary-package">7.1. Building a single binary package</a></span></dt>
 <dt><span class="sect1"><a href="#settings-for-creationg-of-binary-packages">7.2. Settings for creation of binary packages</a></span></dt>
 </dl>
 </div>
 <div class="sect1">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
 <a name="building-a-single-binary-package"></a>7.1. Building a single binary package</h2></div></div></div>
 <p>Once you have built and installed a package, you can create
     a <span class="emphasis"><em>binary package</em></span> which can be installed on
     another system with <a class="citerefentry" href="https://netbsd.gw.com/cgi-bin/man-cgi?pkg_add+1.i386+NetBSD-9.0"><span class="citerefentry"><span class="refentrytitle">pkg_add</span>(1)</span></a>. This saves having to build
     the same package on a group of hosts and wasting CPU time. It also
     provides a simple means for others to install your package, should
     you distribute it.</p>
 <p>To create a binary package, change into the appropriate
     directory in pkgsrc, and run <span class="command"><strong>make
     package</strong></span>:</p>
 <pre class="screen">
 <code class="prompt">$</code> <strong class="userinput"><code>cd misc/figlet</code></strong>
 <code class="prompt">$</code> <strong class="userinput"><code>make package</code></strong>
 </pre>
 <p>This will build and install your package (if not already done),
     and then build a binary package from what was installed. You can
     then use the <span class="command"><strong>pkg_*</strong></span> tools to manipulate
     it. Binary packages are created by default in
     <code class="filename">/usr/pkgsrc/packages</code>, in the form of a
     gzipped tar file. See <a class="xref" href="#logs.package" title="B.2. Packaging figlet">Section B.2, &#8220;Packaging figlet&#8221;</a> for a
     continuation of the above <a href="https://cdn.NetBSD.org/pub/pkgsrc/current/pkgsrc/misc/figlet/README.html" target="_top"><code class="filename">misc/figlet</code></a> example.</p>
 <p>See <a class="xref" href="#submit" title="Chapter 23. Submitting and Committing">Chapter 23, <i>Submitting and Committing</i></a> for information on how to submit
     such a binary package.</p>
 </div>
 <div class="sect1">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
 <a name="settings-for-creationg-of-binary-packages"></a>7.2. Settings for creation of binary packages</h2></div></div></div>
 <p>See <a class="xref" href="#build.helpful-targets" title="19.17. Other helpful targets">Section 19.17, &#8220;Other helpful targets&#8221;</a>.</p>
 </div>
 </div>
 <div class="chapter">
 <div class="titlepage"><div><div><h2 class="title">
 <a name="bulk"></a>Chapter 8. Creating binary packages for everything in pkgsrc (bulk
 builds)</h2></div></div></div>
 <div class="toc">
 <p><b>Table of Contents</b></p>
 <dl class="toc">
 <dt><span class="sect1"><a href="#bulk.pre">8.1. Preparations</a></span></dt>
 <dt><span class="sect1"><a href="#bulk.pbulk">8.2. Running a pbulk-style bulk build</a></span></dt>
 <dd><dl><dt><span class="sect2"><a href="#bulk.pbulk.conf">8.2.1. Configuration</a></span></dt></dl></dd>
 <dt><span class="sect1"><a href="#bulk.req">8.3. Requirements of a full bulk build</a></span></dt>
 <dt><span class="sect1"><a href="#bulk.var">8.4. Bulk build variants</a></span></dt>
 <dd><dl>
-<dt><span class="sect2"><a href="#bulk.var.subst_noop">8.4.1. Strict SUBST blocks</a></span></dt>
+<dt><span class="sect2"><a href="#bulk.var.confopt">8.4.1. Detect unknown configure options</a></span></dt>
-<dt><span class="sect2"><a href="#bulk.var.confopt">8.4.2. Detect unknown configure options</a></span></dt>
+<dt><span class="sect2"><a href="#bulk.var.comperr">8.4.2. Detect classes of bugs by forcing compiler warnings</a></span></dt>
-<dt><span class="sect2"><a href="#bulk.var.comperr">8.4.3. Detect classes of bugs by forcing compiler warnings</a></span></dt>
+<dt><span class="sect2"><a href="#bulk.var.dirs">8.4.3. Use custom directories</a></span></dt>
-<dt><span class="sect2"><a href="#bulk.var.dirs">8.4.4. Use custom directories</a></span></dt>
+<dt><span class="sect2"><a href="#bulk.var.warn">8.4.4. Turn warnings into errors</a></span></dt>
-<dt><span class="sect2"><a href="#bulk.var.warn">8.4.5. Turn warnings into errors</a></span></dt>
+<dt><span class="sect2"><a href="#bulk.var.pkglint">8.4.5. Reject packages for which pkglint reports errors</a></span></dt>
-<dt><span class="sect2"><a href="#bulk.var.pkglint">8.4.6. Reject packages for which pkglint reports errors</a></span></dt>
+<dt><span class="sect2"><a href="#bulk.var.strings">8.4.6. Reject packages that contain forbidden strings</a></span></dt>
-<dt><span class="sect2"><a href="#bulk.var.strings">8.4.7. Reject packages that contain forbidden strings</a></span></dt>
+<dt><span class="sect2"><a href="#bulk.var.test">8.4.7. Reject packages whose self-test fails</a></span></dt>
-<dt><span class="sect2"><a href="#bulk.var.test">8.4.8. Reject packages whose self-test fails</a></span></dt>
+<dt><span class="sect2"><a href="#bulk.var.shvar">8.4.8. Reject packages that use undefined shell variables</a></span></dt>
-<dt><span class="sect2"><a href="#bulk.var.shvar">8.4.9. Reject packages that use undefined shell variables</a></span></dt>
+<dt><span class="sect2"><a href="#bulk.var.quiet">8.4.9. Turn off verbose logging</a></span></dt>
 <dt><span class="sect2"><a href="#bulk.var.quiet">8.4.10. Turn off verbose logging</a></span></dt>
 <dt><span class="sect2"><a href="#bulk.var.options">8.4.11. Select random sets of options</a></span></dt>
 <dt><span class="sect2"><a href="#bulk.var.build_defs">8.4.12. Select random configurations of BUILD_DEFS</a></span></dt>
 </dl></dd>
 <dt><span class="sect1"><a href="#creating-cdroms">8.5. Creating a multiple CD-ROM packages collection</a></span></dt>
 <dd><dl><dt><span class="sect2"><a href="#cdpack-example">8.5.1. Example of cdpack</a></span></dt></dl></dd>
 </dl>
 </div>
 <p>For a number of reasons, you may want to build binary packages
 for a large selected set of packages in pkgsrc, or even for all pkgsrc packages.
 For instance, when you have multiple machines that should run the same software,
 it is wasted time if they all build their packages themselves from source.
 Or you may want to build a list of packages you want and check them before
 deploying onto production systems.
 There is a way of getting a set of binary packages:
 the bulk build system, or pbulk ("p" stands for "parallel").
 This chapter describes how to set it up.</p>
 <div class="sect1">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
 <a name="bulk.pre"></a>8.1. Preparations</h2></div></div></div>
 <p>First of all, you have to decide whether you build all packages
 or a limited set of them. Full bulk builds usually consume a lot more resources,
 both space and time, than builds for some practical sets of packages.
 A number of particularly heavy packages exist that are not actually
 interesting to a wide audience. (The approximate resource consumption for a
 full bulk build is given in section <a class="xref" href="#bulk.req" title="8.3. Requirements of a full bulk build">Section 8.3, &#8220;Requirements of a full bulk build&#8221;</a>.)
 For limited bulk builds you need to make a list of packages you want to build.
 Note that all their dependencies will be built, so you don't need to track them manually.
 </p>
 <p>During bulk builds various packages are installed and deinstalled
 in <code class="filename">/usr/pkg</code> (or whatever <code class="filename">LOCALBASE</code> is),
 so make sure that you don't need any package during the builds.
 Essentially, you should provide a fresh system, either a chroot environment
 or something even more restrictive, depending on what the operating system provides,
 or dedicate the whole physical machine.
 As a useful side effect this makes sure that bulk builds cannot
 break anything in your system. There have been numerous cases where
 certain packages tried to install files outside the
 <code class="filename">LOCALBASE</code> or wanted to edit some files in
 <code class="filename">/etc</code>.
 </p>
 </div>
 <div class="sect1">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
 <a name="bulk.pbulk"></a>8.2. Running a pbulk-style bulk build</h2></div></div></div>
 <p>Running a pbulk-style bulk build works roughly as follows:</p>
 <div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; ">
 <li class="listitem"><p>First, build the pbulk infrastructure in a fresh pkgsrc location.</p></li>
 <li class="listitem"><p>Then, build each of the packages from a clean installation directory using the infrastructure.</p></li>
 </ul></div>
 <div class="sect2">
 <div class="titlepage"><div><div><h3 class="title">
 <a name="bulk.pbulk.conf"></a>8.2.1. Configuration</h3></div></div></div>
 <p>To simplify configuration, we provide the helper script <code class="filename">mk/pbulk/pbulk.sh</code>.</p>
 <p>In order to use it, prepare a clear system (real one, chroot environment, jail, zone, virtual machine).
 Configure network access to fetch distribution files.
 Create a user with name "pbulk".</p>
 <p>Fetch and extract pkgsrc. Use a command like one of these:</p>
 <pre class="screen">
 <code class="prompt">#</code> <strong class="userinput"><code>(cd /usr &amp;&amp; ftp -o - https://cdn.NetBSD.org/pub/pkgsrc/current/pkgsrc.tar.gz | tar -zxf-)</code></strong>
 <code class="prompt">#</code> <strong class="userinput"><code>(cd /usr &amp;&amp; fetch -o - https://cdn.NetBSD.org/pub/pkgsrc/current/pkgsrc.tar.gz | tar -zxf-)</code></strong>
 <code class="prompt">#</code> <strong class="userinput"><code>(cd /usr &amp;&amp; cvs -Q -z3 -d anoncvs@anoncvs.NetBSD.org:/cvsroot get -P pkgsrc)</code></strong>
 </pre>
 <p>Or any other way that fits (e.g., curl, wget).</p>
 <p>Deploy and configure pbulk tools, e.g.:</p>
 <pre class="screen">
 <code class="prompt">#</code> <strong class="userinput"><code>sh pbulk.sh -n # use native make, no bootstrap kit needed (for use on NetBSD)</code></strong>
 <code class="prompt">#</code> <strong class="userinput"><code>sh pbulk.sh -n -c mk.conf.frag # native, apply settings from given mk.conf fragment</code></strong>
 <code class="prompt">#</code> <strong class="userinput"><code>sh pbulk.sh -nlc mk.conf.frag # native, apply settings, configure for limited build</code></strong>
 </pre>
 <div class="note" style="margin-left: 0.5in; margin-right: 0.5in;">
 <h3 class="title">Note</h3>
 <p><code class="filename">mk.conf.frag</code> is a fragment of
 <code class="filename">mk.conf</code> that contains settings you want to
 apply to packages you build. For instance,</p>
 <pre class="programlisting">
 PKG_DEVELOPER=          yes     # perform more checks
 X11_TYPE=               modular # use pkgsrc X11
 SKIP_LICENSE_CHECK=     yes     # accept all licences (useful
                                 # when building all packages)
 </pre>
 </div>
 <p>If configured for limited list, replace the list in <code class="filename">/usr/pbulk/etc/pbulk.list</code>
 with your list of packages, one per line without empty lines or comments. E.g.:</p>
 <pre class="programlisting">
 www/firefox
 mail/thunderbird
 misc/libreoffice4
 </pre>
 <p>At this point you can also review configuration in <code class="filename">/usr/pbulk/etc</code>
 and make final amendments, if wanted.</p>
 <p>Start it:</p>
 <pre class="screen">
 <code class="prompt">#</code> <strong class="userinput"><code>/usr/pbulk/bin/bulkbuild</code></strong>
 </pre>
 <p>After it finishes, you'll have <code class="filename">/mnt</code> filled with distribution files, binary packages, and reports,
 plain text summary in <code class="filename">/mnt/bulklog/meta/report.txt</code>
 </p>
 <div class="note" style="margin-left: 0.5in; margin-right: 0.5in;">
 <h3 class="title">Note</h3>
 <p>The <code class="filename">pbulk.sh</code> script does not cover all possible use cases.
 While being ready to run, it serves as a good starting point to understand and build more complex setups.
 The script is kept small enough for better understanding.</p>
 </div>
 <div class="note" style="margin-left: 0.5in; margin-right: 0.5in;">
 <h3 class="title">Note</h3>
 <p>The <code class="filename">pbulk.sh</code> script supports running
 unprivileged bulk build and helps configuring distributed bulk builds.</p>
 </div>
 </div>
 </div>
 <div class="sect1">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
 <a name="bulk.req"></a>8.3. Requirements of a full bulk build</h2></div></div></div>
 <p>A complete bulk build requires lots of disk space. Some of the
 disk space can be read-only, some other must be writable. Some can be on
 remote filesystems (such as NFS) and some should be local. Some can be
 temporary filesystems, others must survive a sudden reboot.</p>
 <div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; ">
 <li class="listitem"><p>40 GB for the distfiles (read-write, remote, temporary)</p></li>
 <li class="listitem"><p>30 GB for the binary packages (read-write, remote, permanent)</p></li>
 <li class="listitem"><p>1 GB for the pkgsrc tree (read-only, remote, permanent)</p></li>
 <li class="listitem"><p>5 GB for <code class="filename">LOCALBASE</code> (read-write, local, temporary)</p></li>
 <li class="listitem"><p>10 GB for the log files (read-write, remote, permanent)</p></li>
 <li class="listitem"><p>5 GB for temporary files (read-write, local, temporary)</p></li>
 </ul></div>
 </div>
 <div class="sect1">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
 <a name="bulk.var"></a>8.4. Bulk build variants</h2></div></div></div>
 <p>To ensure that pkgsrc packages work in different configurations, it
 makes sense to run non-default bulk builds from time to time. This
 section lists some ideas for bulk builds that intentionally let packages
 fail if they don't follow the pkgsrc style.</p>
 <div class="sect2">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="bulk.var.subst_noop"></a>8.4.1. Strict SUBST blocks</h3></div></div></div>
+<a name="bulk.var.confopt"></a>8.4.1. Detect unknown configure options</h3></div></div></div>
 <p>Up to May 2020, the SUBST blocks ignored files that didn't exist,
 as well as substitutions that didn't have any effect. There were quite a
 few SUBST blocks that were redundant, and these have been removed
 already.</p>
 <p>The next step would be to not only check that each filename pattern
 has an effect but also that each substitution in SUBST_SED or SUBST_VARS
 applies to at least one file.</p>
 <p>To do this, <code class="filename">mk/subst.mk</code> would have to be
 adjusted, in a similar way as the check for no-op SUBST_FILES. There are
 several regression tests in <code class="filename">regress/infra-unittests</code>
 that help to get all edge cases correct.</p>
 <p>When a package fails this additional check, there are various
 possible causes why the <code class="varname">SUBST_SED</code> became a
 no-op.</p>
 <div class="orderedlist"><ol class="orderedlist" type="1">
 <li class="listitem"><p>The pattern used to be found in a former version of the
 package, but is not needed anymore. In that case, just remove
 it.</p></li>
 <li class="listitem"><p>The pattern contains a typo. In that case, fix the typo
 and bump <code class="varname">PKGREVISION</code>, since the fixed typo will
 probably modify the resulting binary package.</p></li>
 <li class="listitem"><p>There is a patch that is applied before the SUBST block,
 and the patch accidentally contains the change that was intended for the
 SUBST block. In that case, remove the respective hunk from the
 patch.</p></li>
 </ol></div>
 </div>
 <div class="sect2">
 <div class="titlepage"><div><div><h3 class="title">
 <a name="bulk.var.confopt"></a>8.4.2. Detect unknown configure options</h3></div></div></div>
 <p>Add the following line to <a class="link" href="#mk.conf"><code class="filename">mk.conf</code></a>.</p>
 <pre class="programlisting">
 GNU_CONFIGURE_STRICT=   yes
 </pre>
 <p>When a package fails this additional check, the most common cause
 is that the configure option was valid for an older version of the
 package but does not apply anymore. In that case, just remove it.</p>
 </div>
 <div class="sect2">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="bulk.var.comperr"></a>8.4.3. Detect classes of bugs by forcing compiler warnings</h3></div></div></div>
+<a name="bulk.var.comperr"></a>8.4.2. Detect classes of bugs by forcing compiler warnings</h3></div></div></div>
 <p>The job of a compiler is not restricted to producing executable
-code, most compilers also detects typical mistakes.</p>
+code, most compilers also detect typical programming mistakes. The pkgsrc
-<p>Add the following line to <a class="link" href="#mk.conf"><code class="filename">mk.conf</code></a>.</p>
+compiler wrappers make it easy to force compiler options when the package
 is built. This can be used to find typical bugs across all packages that
 are in pkgsrc. By reporting these bugs upstream, the packages will be
 more reliable with the next updates.</p>
 <p>Add some of the following lines to <a class="link" href="#mk.conf"><code class="filename">mk.conf</code></a>:</p>
 <pre class="programlisting">
 CFLAGS+=        -Werror=char-subscripts
 CFLAGS+=        -Werror=implicit-function-declaration
 </pre>
-<p>When a package fails this additional check, first document the
+<p>When a package fails to build using these stricter compiler
-circumstances in which the compiler produced the error message. This
+options, document the circumstances in which the compiler produced the
-includes:</p>
+error message. This includes:</p>
 <div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; ">
 <li class="listitem"><p>The platform
 (<code class="varname">MACHINE_PLATFORM</code>)</p></li>
 <li class="listitem"><p>The source file</p></li>
 <li class="listitem"><p>An excerpt of the code. GCC and Clang already do this as
 part of the diagnostic.</p></li>
-<li class="listitem"><p>The error message from the compiler.</p></li>
+<li class="listitem"><p>The exact error message from the compiler.</p></li>
 </ul></div>
 <p>If a package produces these error messages, but the package is
-fine, document this in the package Makefile, like this:</p>
+fine, record this in your local <a class="link" href="#mk.conf"><code class="filename">mk.conf</code></a>, like this, to skip this check
 in the next builds:</p>
 <pre class="programlisting">
 .if ${PKGPATH} == category/package
 # Version ${VERSION} failed on ${MACHINE_PLATFORM}:
 # error message
 # code
-# reason why the code does not need to be fixed
+# Reason why the code does not need to be fixed.
 BUILDLINK_TRANSFORM+=   rm:-Werror=char-subscripts
 .endif
 </pre>
 <p>If the error messages from the compiler are valid and the code
-needs to be fixed, prepare a patch for a single source file, or if it's a
+needs to be fixed, prepare a local patch (see
-one-liner fix, add a SUBST block to the package Makefile. In any case,
+<code class="varname">LOCALPATCHES</code>) and report the bug to the upstream
-report it to the upstream authors of the package.</p>
+authors of the package, providing them with the information you collected
 above.</p>
 <p>Patches that are not essential for the package to work should only
 be reported upstream but not committed to pkgsrc, to make future updates
 easier.</p>
 </div>
 <div class="sect2">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="bulk.var.dirs"></a>8.4.4. Use custom directories</h3></div></div></div>
+<a name="bulk.var.dirs"></a>8.4.3. Use custom directories</h3></div></div></div>
 <p>Some directories like <code class="varname">PREFIX</code>,
 <code class="varname">VARBASE</code>, <code class="varname">PKG_SYSCONFDIR</code>,
 <code class="varname">PKGMANDIR</code>, <code class="varname">PKG_INFODIR</code> can be
 configured in pkgsrc. Set these to arbitrary paths during bootstrap or
 afterwards in <a class="link" href="#mk.conf"><code class="filename">mk.conf</code></a>.</p>
 <pre class="programlisting">
 PREFIX=         /a-random-uuid
 PKG_SYSCONFDIR= /a-random-uuid
 VARBASE=        /a-random-uuid
 PKGMANDIR=	a-random-uuid
 PKG_INFODIR=	a-random-uuid
 </pre>
 </div>
 <div class="sect2">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="bulk.var.warn"></a>8.4.5. Turn warnings into errors</h3></div></div></div>
+<a name="bulk.var.warn"></a>8.4.4. Turn warnings into errors</h3></div></div></div>
 <p>When building a package, warnings are typically ignored since they
 just flow by and do not cause the build to fail immediately. To find
 these warnings, redefine them to errors in <a class="link" href="#mk.conf"><code class="filename">mk.conf</code></a>.</p>
 <pre class="programlisting">
 DELAYED_WARNING_MSG=    ${DELAYED_ERROR_MSG} "(was warning)"
 WARNING_MSG=            ${FAIL_MSG} "(was warning)"
 </pre>
 <p>(There are many more classes of warnings in pkgsrc, and most of
 them can be redefined with a simple definition like above.</p>
-<p>If a package suggest to add <code class="varname">USE_TOOLS+=perl</code> to
+<p>If a package suggests to add <code class="varname">USE_TOOLS+=perl</code> to
 the package Makefile, research whether the package actually needs Perl.
 If it does, add <code class="varname">USE_TOOLS+=perl</code> to the package
 Makefile, and if it doesn't, add
 <code class="varname">TOOLS_BROKEN+=perl</code>.</p>
 </div>
 <div class="sect2">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="bulk.var.pkglint"></a>8.4.6. Reject packages for which pkglint reports errors</h3></div></div></div>
+<a name="bulk.var.pkglint"></a>8.4.5. Reject packages for which pkglint reports errors</h3></div></div></div>
 <p>Using pkglint as part of the regular build process is mostly a
 waste of time. If you want to fix some of the warnings, just run pkglint
 recursively on the whole pkgsrc tree. This will take a few minutes (up to
 ), which is much faster than a complete bulk build.</p>
 </div>
 <div class="sect2">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="bulk.var.strings"></a>8.4.7. Reject packages that contain forbidden strings</h3></div></div></div>
+<a name="bulk.var.strings"></a>8.4.6. Reject packages that contain forbidden strings</h3></div></div></div>
 <p>To ensure that the binary packages don't contain references to the
 build directory, there is already <code class="varname">CHECK_WRKREF</code>. If
 that variable includes the item <code class="literal">extra</code>, it is
 possible to define additional patterns that must not appear in any
 installed file. This is specified in <a class="link" href="#mk.conf"><code class="filename">mk.conf</code></a>.</p>
 <pre class="programlisting">
 CHECK_WRKREF=                   extra
 CHECK_WRKREF_EXTRA_DIRS+=       /usr/local
 CHECK_WRKREF_EXTRA_DIRS+=       /usr/pkg
 CHECK_WRKREF_EXTRA_DIRS+=	@[A-Z][A-Z]*@
 </pre>
 <p>The above patterns will probably generate many false positives,
 therefore the results need to be taken with a grain of salt.</p>
 </div>
 <div class="sect2">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="bulk.var.test"></a>8.4.8. Reject packages whose self-test fails</h3></div></div></div>
+<a name="bulk.var.test"></a>8.4.7. Reject packages whose self-test fails</h3></div></div></div>
 <p>To run the test suites that come with each package, add this line
 to <a class="link" href="#mk.conf"><code class="filename">mk.conf</code></a>.</p>
 <pre class="programlisting">
 PKGSRC_RUN_TEST=        yes
 </pre>
 <p>Be prepared that even the most basic packages fail this test. When
 doing a bulk build with this, it will often abort in the early phase
 where the packages are scanned for their dependencies since there are
 cyclic dependencies. There is still a lot to do in this area.</p>
 </div>
 <div class="sect2">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="bulk.var.shvar"></a>8.4.9. Reject packages that use undefined shell variables</h3></div></div></div>
+<a name="bulk.var.shvar"></a>8.4.8. Reject packages that use undefined shell variables</h3></div></div></div>
 <p>To catch typos in the shell snippets from the Makefile fragments,
 add the <code class="literal">-u</code> flag to most of the commands by adding this
 line to <a class="link" href="#mk.conf"><code class="filename">mk.conf</code></a>.</p>
 <pre class="programlisting">
 RUN=    @set -eu;
 </pre>
 <p>See <code class="filename">mk/misc/common.mk</code> for the existing
 definition.</p>
 </div>
 <div class="sect2">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="bulk.var.quiet"></a>8.4.10. Turn off verbose logging</h3></div></div></div>
+<a name="bulk.var.quiet"></a>8.4.9. Turn off verbose logging</h3></div></div></div>
 <p>The build logs of a package are often quite long. This allows error
 messages or other interesting details to hide between the noise. To make
 the actual error message stand out more, add these lines to
 <a class="link" href="#mk.conf"><code class="filename">mk.conf</code></a>.</p>
 <pre class="programlisting">
 GNU_CONFIGURE_QUIET=    yes
 MAKE_FLAGS+=            -s
 </pre>
 <p>The <code class="literal">-s</code> option works for both GNU Make and BSD
 Make. On exotic platforms with their own make, it may be a little
 different.</p>
 </div>
 <div class="sect2">
 <div class="titlepage"><div><div><h3 class="title">
 <a name="bulk.var.options"></a>8.4.11. Select random sets of options</h3></div></div></div>
 <p>Most bulk builds run with the default package options. This means
 that other combinations of options are not regularly tested. To do this,
 run a bulk build with these configurations.</p>
 <div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; ">
 <li class="listitem"><p>no options enabled</p></li>
 <li class="listitem"><p>all options enabled</p></li>
 <li class="listitem"><p>2n + 0</p></li>
 <li class="listitem"><p>2n + 1</p></li>
 <li class="listitem"><p>4n + 0..1</p></li>
 <li class="listitem"><p>4n + 2..3</p></li>
 <li class="listitem"><p>8n + 0..3</p></li>
 <li class="listitem"><p>8n + 4..7</p></li>
 <li class="listitem"><p>2048n + 0..1023</p></li>
 <li class="listitem"><p>2048n + 1024..2047</p></li>
 </ul></div>
 <p>Open questions are:</p>
 <div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; ">
 <li class="listitem"><p>how to collect all options from the entire
 pkgsrc</p></li>
 <li class="listitem"><p>how to handle mutually exclusive
 options</p></li>
 <li class="listitem"><p>the sets of mutually exclusive options are defined
 per-package</p></li>
 <li class="listitem"><p>the sets of nonempty sets are defined
 per-package</p></li>
 </ul></div>
 </div>
 <div class="sect2">
 <div class="titlepage"><div><div><h3 class="title">
 <a name="bulk.var.build_defs"></a>8.4.12. Select random configurations of BUILD_DEFS</h3></div></div></div>
 <p>Just like the <code class="varname">PKG_OPTIONS</code>, the
 <code class="varname">BUILD_DEFS</code> also allow different variants of pkgsrc to
 be created. The same ideas as in <a class="xref" href="#bulk.var.options" title="8.4.11. Select random sets of options">Section 8.4.11, &#8220;Select random sets of options&#8221;</a>
 apply.</p>
 </div>
 </div>
 <div class="sect1">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
 <a name="creating-cdroms"></a>8.5. Creating a multiple CD-ROM packages collection</h2></div></div></div>
 <p>After your pkgsrc bulk-build has completed, you may wish to
     create a CD-ROM set of the resulting binary packages to assist
     in installing packages on other machines.  The
     <a href="https://cdn.NetBSD.org/pub/pkgsrc/current/pkgsrc/pkgtools/cdpack/README.html" target="_top"><code class="filename">pkgtools/cdpack</code></a> package provides
     a simple tool for creating the ISO 9660 images.
     <span class="command"><strong>cdpack</strong></span> arranges the packages on the CD-ROMs in a
     way that keeps all the dependencies for a given package on the same
     CD as that package.</p>
 <div class="sect2">
 <div class="titlepage"><div><div><h3 class="title">
 <a name="cdpack-example"></a>8.5.1. Example of cdpack</h3></div></div></div>
 <p>Complete documentation for cdpack is found in the cdpack(1)
       man page. The following short example assumes that the binary
       packages are left in
       <code class="filename">/usr/pkgsrc/packages/All</code> and that
       sufficient disk space exists in <code class="filename">/u2</code> to
       hold the ISO 9660 images.</p>
 <pre class="screen">
 <code class="prompt">#</code> <strong class="userinput"><code>mkdir /u2/images</code></strong>
 <code class="prompt">#</code> <strong class="userinput"><code>pkg_add /usr/pkgsrc/packages/All/cdpack</code></strong>
 <code class="prompt">#</code> <strong class="userinput"><code>cdpack /usr/pkgsrc/packages/All /u2/images</code></strong>
       </pre>
 <p>If you wish to include a common set of files
       (<code class="filename">COPYRIGHT</code>, <code class="filename">README</code>,
       etc.) on each CD in the collection, then you need to create a
       directory which contains these files, e.g.:</p>
 <pre class="screen">
 <code class="prompt">#</code> <strong class="userinput"><code>mkdir /tmp/common</code></strong>
 <code class="prompt">#</code> <strong class="userinput"><code>echo "This is a README" &gt; /tmp/common/README</code></strong>
 <code class="prompt">#</code> <strong class="userinput"><code>echo "Another file" &gt; /tmp/common/COPYING</code></strong>
 <code class="prompt">#</code> <strong class="userinput"><code>mkdir /tmp/common/bin</code></strong>
 <code class="prompt">#</code> <strong class="userinput"><code>echo "#!/bin/sh" &gt; /tmp/common/bin/myscript</code></strong>
 <code class="prompt">#</code> <strong class="userinput"><code>echo "echo Hello world" &gt;&gt; /tmp/common/bin/myscript</code></strong>
 <code class="prompt">#</code> <strong class="userinput"><code>chmod 755 /tmp/common/bin/myscript</code></strong>
       </pre>
 <p>Now create the images:</p>
 <pre class="screen"><code class="prompt">#</code> <strong class="userinput"><code>cdpack -x /tmp/common /usr/pkgsrc/packages/All /u2/images</code></strong></pre>
 <p>Each image will contain <code class="filename">README</code>,
       <code class="filename">COPYING</code>, and <code class="filename">bin/myscript</code>
       in their root directories.</p>
 </div>
 </div>
 </div>
 <div class="chapter">
 <div class="titlepage"><div><div><h2 class="title">
 <a name="files"></a>Chapter 9. Directory layout of the installed files</h2></div></div></div>
 <div class="toc">
 <p><b>Table of Contents</b></p>
 <dl class="toc">
 <dt><span class="sect1"><a href="#files.localbase">9.1. File system layout in <code class="literal">${LOCALBASE}</code></a></span></dt>
 <dt><span class="sect1"><a href="#files.varbase">9.2. File system layout in <code class="literal">${VARBASE}</code></a></span></dt>
 </dl>
 </div>
 <p>The files that are installed by pkgsrc are organized in a way that
 is similar to what you find in the <code class="filename">/usr</code> directory
 of the base system. But some details are different. This is because
 pkgsrc initially came from FreeBSD and had adopted its file system
 hierarchy. Later it was largely influenced by NetBSD. But no matter
 which operating system you are using pkgsrc with, you can expect the
 same layout for pkgsrc.</p>
 <p>There are mainly four root directories for pkgsrc, which are all
 configurable in the <code class="filename">bootstrap/bootstrap</code> script.
 When pkgsrc has been installed as root, the default locations
 are:</p>
 <pre class="programlisting">
 LOCALBASE=              /usr/pkg
 PKG_SYSCONFBASE=        /usr/pkg/etc
 VARBASE=                /var
 PKG_DBDIR=              /usr/pkg/pkgdb
 </pre>
 <p>In unprivileged mode (when pkgsrc has been installed as any other
 user), the default locations are:</p>
 <pre class="programlisting">
 LOCALBASE=              ${HOME}/pkg
 PKG_SYSCONFBASE=        ${HOME}/pkg/etc
 VARBASE=                ${HOME}/pkg/var
 PKG_DBDIR=              ${HOME}/pkg/pkgdb
 </pre>
 <p>What these four directories are for, and what they look like is
 explained below.</p>
 <div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; ">
 <li class="listitem"><p><code class="varname">LOCALBASE</code> corresponds to the
 <code class="filename">/usr</code> directory in the base system. It is the
 <span class="quote">&#8220;<span class="quote">main</span>&#8221;</span> directory where the files are installed and contains
 the well-known subdirectories like <code class="filename">bin</code>,
 <code class="filename">include</code>, <code class="filename">lib</code>,
 <code class="filename">share</code> and
 <code class="filename">sbin</code>.</p></li>
 <li class="listitem"><p><code class="varname">VARBASE</code> corresponds to
 <code class="filename">/var</code> in the base system. Some programs (especially
 games, network daemons) need write access to it during normal
 operation.</p></li>
 <li class="listitem"><p><code class="varname">PKG_SYSCONFDIR</code> corresponds to
 <code class="filename">/etc</code> in the base system. It contains configuration
 files of the packages, as well as pkgsrc's <a class="link" href="#mk.conf"><code class="filename">mk.conf</code></a>
 itself.</p></li>
 </ul></div>
 <div class="sect1">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
 <a name="files.localbase"></a>9.1. File system layout in <code class="literal">${LOCALBASE}</code>
 </h2></div></div></div>
 <p>The following directories exist in a typical pkgsrc installation
 in <code class="filename">${LOCALBASE}</code>.</p>
 <div class="variablelist"><dl class="variablelist">
 <dt><span class="term"><code class="filename">bin</code></span></dt>
 <dd><p>Contains executable programs that are intended to be
 directly used by the end user.</p></dd>
 <dt><span class="term"><code class="filename">emul</code></span></dt>
 <dd><p>Contains files for the emulation layers of various other
 operating systems, especially for
 NetBSD.</p></dd>
 <dt><span class="term"><code class="filename">etc</code> (the usual location of
 <code class="filename">${PKG_SYSCONFDIR}</code>)</span></dt>
 <dd><p>Contains
 the configuration files.</p></dd>
 <dt><span class="term"><code class="filename">include</code></span></dt>
 <dd><p>Contains headers for the C and C++ programming
 languages.</p></dd>
 <dt><span class="term"><code class="filename">info</code></span></dt>
 <dd><p>Contains GNU info files of various
 packages.</p></dd>
 <dt><span class="term"><code class="filename">lib</code></span></dt>
 <dd><p>Contains shared and static
 libraries.</p></dd>
 <dt><span class="term"><code class="filename">libdata</code></span></dt>
 <dd><p>Contains data files that don't change after
 installation. Other data files belong into
 <code class="filename">${VARBASE}</code>.</p></dd>
 <dt><span class="term"><code class="filename">libexec</code></span></dt>
 <dd><p>Contains programs that are not intended to be used by
 end users, such as helper programs or network
 daemons.</p></dd>
 <dt><span class="term"><code class="filename">libexec/cgi-bin</code></span></dt>
 <dd><p>Contains programs that are intended to be executed as
 CGI scripts by a web server.</p></dd>
 <dt><span class="term"><code class="filename">man</code> (the usual value of
 <code class="filename">${PKGMANDIR}</code>)</span></dt>
 <dd><p>Contains brief
 documentation in form of manual pages.</p></dd>
 <dt><span class="term"><code class="filename">sbin</code></span></dt>
 <dd><p>Contains programs that are intended to be used only by
 the super-user.</p></dd>
 <dt><span class="term"><code class="filename">share</code></span></dt>
 <dd><p>Contains platform-independent data files that don't
 change after installation.</p></dd>
 <dt><span class="term"><code class="filename">share/doc</code></span></dt>
 <dd><p>Contains documentation files provided by the
 packages.</p></dd>
 <dt><span class="term"><code class="filename">share/examples</code></span></dt>
 <dd><p>Contains example files provided by the packages. Among
 others, the original configuration files are saved here and copied to
 <code class="filename">${PKG_SYSCONFDIR}</code> during
 installation.</p></dd>
 <dt><span class="term"><code class="filename">share/examples/rc.d</code></span></dt>
 <dd><p>Contains the original files for rc.d
 scripts.</p></dd>
 <dt><span class="term"><code class="filename">var</code> (the usual location of
 <code class="filename">${VARBASE}</code>)</span></dt>
 <dd><p>Contains files
 that may be modified after
 installation.</p></dd>
 </dl></div>
 </div>
 <div class="sect1">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
 <a name="files.varbase"></a>9.2. File system layout in <code class="literal">${VARBASE}</code>
 </h2></div></div></div>
 <div class="variablelist"><dl class="variablelist">
 <dt><span class="term"><code class="filename">db/pkg</code> (the usual location of
 <code class="filename">${PKG_DBDIR}</code>)</span></dt>
 <dd><p>Contains
 information about the currently installed
 packages.</p></dd>
 <dt><span class="term"><code class="filename">games</code></span></dt>
 <dd><p>Contains highscore
 files.</p></dd>
 <dt><span class="term"><code class="filename">log</code></span></dt>
 <dd><p>Contains log files.</p></dd>
 <dt><span class="term"><code class="filename">run</code></span></dt>
 <dd><p>Contains informational files about daemons that are
 currently running.</p></dd>
 </dl></div>
 </div>
 </div>
 <div class="chapter">
 <div class="titlepage"><div><div><h2 class="title">
 <a name="faq"></a>Chapter 10. Frequently Asked Questions</h2></div></div></div>
 <div class="toc">
 <p><b>Table of Contents</b></p>
 <dl class="toc">
 <dt><span class="sect1"><a href="#mailing-list-pointers">10.1. Are there any mailing lists for pkg-related discussion?</a></span></dt>
 <dt><span class="sect1"><a href="#faq-pkgtools">10.2. Utilities for package management (pkgtools)</a></span></dt>
 <dt><span class="sect1"><a href="#non-root-pkgsrc">10.3. How to use pkgsrc as non-root</a></span></dt>
 <dt><span class="sect1"><a href="#resume-transfers">10.4. How to resume transfers when fetching distfiles?</a></span></dt>
 <dt><span class="sect1"><a href="#x.org-from-pkgsrc">10.5. How can I install/use modular X.org from pkgsrc?</a></span></dt>
 <dt><span class="sect1"><a href="#fetch-behind-firewall">10.6. How to fetch files from behind a firewall</a></span></dt>
 <dt><span class="sect1"><a href="#fetch-https">10.7. How to fetch files from HTTPS sites</a></span></dt>
 <dt><span class="sect1"><a href="#passive-ftp">10.8. How do I tell <span class="command"><strong>make fetch</strong></span> to do passive FTP?</a></span></dt>
 <dt><span class="sect1"><a href="#fetching-all-distfiles">10.9. How to fetch all distfiles at once</a></span></dt>
 <dt><span class="sect1"><a href="#tmac.andoc-missing">10.10. What does <span class="quote">&#8220;<span class="quote">Don't know how to make
 /usr/share/tmac/tmac.andoc</span>&#8221;</span> mean?</a></span></dt>
 <dt><span class="sect1"><a href="#bsd.own.mk-missing">10.11. What does <span class="quote">&#8220;<span class="quote">Could not find bsd.own.mk</span>&#8221;</span> mean?</a></span></dt>
 <dt><span class="sect1"><a href="#using-sudo-with-pkgsrc">10.12. Using 'sudo' with pkgsrc</a></span></dt>
 <dt><span class="sect1"><a href="#faq.conf">10.13. How do I change the location of configuration files?</a></span></dt>
 <dt><span class="sect1"><a href="#audit-packages">10.14. Automated security checks</a></span></dt>
 <dt><span class="sect1"><a href="#ufaq-cflags">10.15. Why do some packages ignore my <code class="varname">CFLAGS</code>?</a></span></dt>
 <dt><span class="sect1"><a href="#ufaq-fail">10.16. A package does not build.  What shall I do?</a></span></dt>
 <dt><span class="sect1"><a href="#faq.rcs-conflicts">10.17. What does <span class="quote">&#8220;<span class="quote">Makefile appears to contain unresolved cvs/rcs/??? merge conflicts</span>&#8221;</span> mean?</a></span></dt>
 </dl>
 </div>
 <p>This section contains hints, tips &amp; tricks on special things in
 pkgsrc that we didn't find a better place for in the previous chapters, and
 it contains items for both pkgsrc users and developers.</p>
 <div class="sect1">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
 <a name="mailing-list-pointers"></a>10.1. Are there any mailing lists for pkg-related discussion?</h2></div></div></div>
 <p>The following mailing lists may be of interest to pkgsrc users:</p>
 <div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; ">
 <li class="listitem"><p><a class="ulink" href="http://www.NetBSD.org/mailinglists/index.html#pkgsrc-users" target="_top">pkgsrc-users</a>:
 	  This is a general purpose list for most issues regarding
 	  pkgsrc, regardless of platform, e.g. soliciting user help
 	  for pkgsrc configuration, unexpected build failures, using
 	  particular packages, upgrading pkgsrc installations,
 	  questions regarding the pkgsrc release branches, etc.  General announcements or
 	  proposals for changes that impact the pkgsrc user community,
 	  e.g. major infrastructure changes, new features, package
 	  removals, etc., may also be posted.</p></li>
 <li class="listitem"><p><a class="ulink" href="https://www.NetBSD.org/mailinglists/index.html#pkgsrc-bulk" target="_top">pkgsrc-bulk</a>:
 	  A list where the results of pkgsrc bulk builds are sent and
 	  discussed.</p></li>
 <li class="listitem"><p><a class="ulink" href="https://www.NetBSD.org/mailinglists/index.html#pkgsrc-changes" target="_top">pkgsrc-changes</a>:
 	  This list is for those who are interested in getting a
 	  commit message for every change committed to pkgsrc. It is
 	  also available in digest form, meaning one daily message
 	  containing all commit messages for changes to the package
 	  source tree in that 24 hour period.</p></li>
 </ul></div>
 <p>To subscribe, do:</p>
 <pre class="programlisting">
 <code class="prompt">%</code> echo subscribe <em class="replaceable"><code>listname</code></em> | mail majordomo@NetBSD.org
 </pre>
 <p>Archives for all these mailing lists are available from
 <a class="ulink" href="https://mail-index.NetBSD.org/" target="_top">https://mail-index.NetBSD.org/</a>.</p>
 </div>
 <div class="sect1">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
 <a name="faq-pkgtools"></a>10.2. Utilities for package management (pkgtools)</h2></div></div></div>
 <p>The directory <code class="filename">pkgsrc/pkgtools</code> contains
 a number of useful utilities for both users and developers of pkgsrc.  This
 section attempts only to make the reader aware of some of the utilities and when
 they might be useful, and not to duplicate the documentation that comes
 with each package.</p>
 <p>Utilities used by pkgsrc (automatically installed when needed):</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/pkgtools/x11-links/README.html" target="_top"><code class="filename">pkgtools/x11-links</code></a>:
       Symlinks for use by buildlink.</p></li></ul></div>
 <p>OS tool augmentation (automatically installed when needed):</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/pkgtools/digest/README.html" target="_top"><code class="filename">pkgtools/digest</code></a>:
       Calculates various kinds of checksums (including SHA3).</p></li>
 <li class="listitem"><p><a href="https://cdn.NetBSD.org/pub/pkgsrc/current/pkgsrc/pkgtools/libnbcompat/README.html" target="_top"><code class="filename">pkgtools/libnbcompat</code></a>:
       Compatibility library for pkgsrc tools.</p></li>
 <li class="listitem"><p><a href="https://cdn.NetBSD.org/pub/pkgsrc/current/pkgsrc/pkgtools/mtree/README.html" target="_top"><code class="filename">pkgtools/mtree</code></a>: Installed on
       non-BSD systems due to lack of native mtree.</p></li>
 <li class="listitem"><p><a href="https://cdn.NetBSD.org/pub/pkgsrc/current/pkgsrc/pkgtools/pkg_install/README.html" target="_top"><code class="filename">pkgtools/pkg_install</code></a>:
       Up-to-date replacement for
       <code class="filename">/usr/sbin/pkg_install</code>, or for use on operating
       systems where pkg_install is not present.</p></li>
 </ul></div>
 <p>Utilities used by pkgsrc (not automatically installed):</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/pkgtools/pkg_tarup/README.html" target="_top"><code class="filename">pkgtools/pkg_tarup</code></a>:
       Create a binary package from an
       already-installed package.  Used by <span class="command"><strong>make replace</strong></span> to
       save the old package.</p></li>
 <li class="listitem"><p><a href="https://cdn.NetBSD.org/pub/pkgsrc/current/pkgsrc/pkgtools/dfdisk/README.html" target="_top"><code class="filename">pkgtools/dfdisk</code></a>:
       Adds extra functionality to pkgsrc, allowing it to fetch distfiles
       from multiple locations. It currently supports the following
       methods: multiple CD-ROMs and network FTP/HTTP connections.</p></li>
 <li class="listitem"><p><a href="https://cdn.NetBSD.org/pub/pkgsrc/current/pkgsrc/devel/cpuflags/README.html" target="_top"><code class="filename">devel/cpuflags</code></a>: Determine
       the best compiler flags to optimise code for your current
       CPU and compiler. </p></li>
 </ul></div>
 <p>Utilities for keeping track of installed packages, being up to date,
 etc:</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/pkgtools/pkgin/README.html" target="_top"><code class="filename">pkgtools/pkgin</code></a>: A package
     update tool similar to apt(1). Download, install, and upgrade
     binary packages easily.</p></li>
 <li class="listitem"><p><a href="https://cdn.NetBSD.org/pub/pkgsrc/current/pkgsrc/pkgtools/pkg_chk/README.html" target="_top"><code class="filename">pkgtools/pkg_chk</code></a>: Reports on
       packages whose installed versions do not match the latest pkgsrc
       entries.</p></li>
 <li class="listitem"><p><a href="https://cdn.NetBSD.org/pub/pkgsrc/current/pkgsrc/pkgtools/pkgdep/README.html" target="_top"><code class="filename">pkgtools/pkgdep</code></a>: Makes
       dependency graphs of packages, to aid in choosing a strategy for
       updating.</p></li>
 <li class="listitem"><p><a href="https://cdn.NetBSD.org/pub/pkgsrc/current/pkgsrc/pkgtools/pkgdepgraph/README.html" target="_top"><code class="filename">pkgtools/pkgdepgraph</code></a>: Makes
       graphs from the output of <a href="https://cdn.NetBSD.org/pub/pkgsrc/current/pkgsrc/pkgtools/pkgdep/README.html" target="_top"><code class="filename">pkgtools/pkgdep</code></a> (uses graphviz).</p></li>
 <li class="listitem"><p><a href="https://cdn.NetBSD.org/pub/pkgsrc/current/pkgsrc/pkgtools/pkglint/README.html" target="_top"><code class="filename">pkgtools/pkglint</code></a>: The
       pkglint(1) program checks a pkgsrc entry for errors.</p></li>
 <li class="listitem"><p><a href="https://cdn.NetBSD.org/pub/pkgsrc/current/pkgsrc/pkgtools/lintpkgsrc/README.html" target="_top"><code class="filename">pkgtools/lintpkgsrc</code></a>: The lintpkgsrc(1) program
       does various checks on the complete pkgsrc system.</p></li>
 <li class="listitem"><p><a href="https://cdn.NetBSD.org/pub/pkgsrc/current/pkgsrc/pkgtools/pkgsurvey/README.html" target="_top"><code class="filename">pkgtools/pkgsurvey</code></a>: Report what
       packages you have installed.</p></li>
 </ul></div>
 <p>Utilities for people maintaining or creating individual 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/pkgtools/pkgdiff/README.html" target="_top"><code class="filename">pkgtools/pkgdiff</code></a>: Automate
       making and maintaining patches for a package (includes pkgdiff,
       pkgvi, mkpatches, etc.).</p></li>
 <li class="listitem"><p><a href="https://cdn.NetBSD.org/pub/pkgsrc/current/pkgsrc/pkgtools/url2pkg/README.html" target="_top"><code class="filename">pkgtools/url2pkg</code></a>: Aids in
       converting to pkgsrc.</p></li>
 </ul></div>
 <p>Utilities for people maintaining pkgsrc (or: more obscure pkg
 utilities)</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/pkgtools/pkg_comp/README.html" target="_top"><code class="filename">pkgtools/pkg_comp</code></a>: Build
       packages in a chrooted area.</p></li>
 <li class="listitem"><p><a href="https://cdn.NetBSD.org/pub/pkgsrc/current/pkgsrc/pkgtools/libkver/README.html" target="_top"><code class="filename">pkgtools/libkver</code></a>: Spoof
       kernel version for chrooted cross builds.</p></li>
 </ul></div>
 </div>
 <div class="sect1">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
 <a name="non-root-pkgsrc"></a>10.3. How to use pkgsrc as non-root</h2></div></div></div>
 <p>To install packages from source as a non-root user, download
 pkgsrc as described in <a class="xref" href="#getting" title="Chapter 3. Where to get pkgsrc and how to keep it up-to-date">Chapter 3, <i>Where to get pkgsrc and how to keep it up-to-date</i></a>, cd into that
 directory and run the command <span class="command"><strong>./bootstrap/bootstrap
 --unprivileged</strong></span>.</p>
 <p>This will install the binary part of pkgsrc to
 <code class="filename">~/pkg</code> and put the pkgsrc configuration <a class="link" href="#mk.conf"><code class="filename">mk.conf</code></a>
 into <code class="filename">~/pkg/etc</code>.</p>
 <p>For more details, see <code class="filename">mk/unprivileged.mk</code>.</p>
 </div>
 <div class="sect1">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
 <a name="resume-transfers"></a>10.4. How to resume transfers when fetching distfiles?</h2></div></div></div>
 <p>By default, resuming transfers in pkgsrc is disabled, but you can
 enable this feature by adding the option
 <code class="varname">PKG_RESUME_TRANSFERS=YES</code> into
 <a class="link" href="#mk.conf"><code class="filename">mk.conf</code></a>.  If, during a fetch step, an incomplete
 distfile is found, pkgsrc will try to resume it.</p>
 <p>You can also
 use a different program than the platform default program by changing the
 <code class="varname">FETCH_USING</code> variable.  You can specify the program by
 using of ftp, fetch, wget or curl.  Alternatively, fetching can be disabled
 by using the value manual.  A value of custom disables the system defaults
 and dependency tracking for the fetch program.  In that case you have to
 provide <code class="varname">FETCH_CMD</code>, <code class="varname">FETCH_BEFORE_ARGS</code>,
 <code class="varname">FETCH_RESUME_ARGS</code>, <code class="varname">FETCH_OUTPUT_ARGS</code>,
 <code class="varname">FETCH_AFTER_ARGS</code>.</p>
 <p>For example, if you want to use
 <code class="filename">wget</code> to download, you'll have to use something
 like:</p>
 <pre class="programlisting">
 FETCH_USING=    wget
 </pre>
 </div>
 <div class="sect1">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
 <a name="x.org-from-pkgsrc"></a>10.5. How can I install/use modular X.org from pkgsrc?</h2></div></div></div>
 <p>If you want to use modular X.org from pkgsrc instead of your system's own X11
 (<code class="filename">/usr/X11R6</code>, <code class="filename">/usr/openwin</code>, ...)
 you will have to add the following line into
 <a class="link" href="#mk.conf"><code class="filename">mk.conf</code></a>:</p>
 <pre class="programlisting">
 X11_TYPE=modular
 </pre>
 </div>
 <div class="sect1">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
 <a name="fetch-behind-firewall"></a>10.6. How to fetch files from behind a firewall</h2></div></div></div>
 <p>If you are sitting behind a firewall which does not allow direct
 connections to Internet hosts (i.e. non-NAT), you may specify the
 relevant proxy hosts.  This is done using an environment variable in the
 form of a URL, e.g. in Amdahl, the machine
 <span class="quote">&#8220;<span class="quote">orpheus.amdahl.com</span>&#8221;</span> is one of the firewalls, and it uses
 port 80 as the proxy port number.  So the proxy environment variables
 are:</p>
 <pre class="programlisting">
 ftp_proxy=ftp://orpheus.amdahl.com:80/
 http_proxy=http://orpheus.amdahl.com:80/
 </pre>
 </div>
 <div class="sect1">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
 <a name="fetch-https"></a>10.7. How to fetch files from HTTPS sites</h2></div></div></div>
 <p>Some fetch tools are not prepared to support HTTPS by default
 (for example, the one in NetBSD 6.0), or the one installed by the
 pkgsrc bootstrap (to avoid an openssl dependency that low in the
 dependency graph).</p>
 <p>Usually you won't notice, because distribution files are
 mirrored weekly to <span class="quote">&#8220;<span class="quote">ftp.NetBSD.org</span>&#8221;</span>, but that might not
 be often enough if you are following pkgsrc-current. In that case, set
 <code class="varname">FETCH_USING</code> in your <a class="link" href="#mk.conf"><code class="filename">mk.conf</code></a> file to
 <span class="quote">&#8220;<span class="quote">curl</span>&#8221;</span> or <span class="quote">&#8220;<span class="quote">wget</span>&#8221;</span>, which are both compiled
 with HTTPS support by default. Of course, these tools need to be
 installed before you can use them this way.</p>
 </div>
 <div class="sect1">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
 <a name="passive-ftp"></a>10.8. How do I tell <span class="command"><strong>make fetch</strong></span> to do passive FTP?</h2></div></div></div>
 <p>This depends on which utility is used to retrieve distfiles.  From
 <code class="filename">bsd.pkg.mk</code>, <code class="varname">FETCH_CMD</code> is assigned
 the first available command from the following list:</p>
 <div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; ">
 <li class="listitem"><p><code class="filename">${LOCALBASE}/bin/ftp</code></p></li>
 <li class="listitem"><p><code class="filename">/usr/bin/ftp</code></p></li>
 </ul></div>
 <p>On a default NetBSD installation, this will be
 <code class="filename">/usr/bin/ftp</code>, which automatically tries passive
 connections first, and falls back to active connections if the server
 refuses to do passive.  For the other tools, add the following to your
 <a class="link" href="#mk.conf"><code class="filename">mk.conf</code></a> file:
 <code class="varname">PASSIVE_FETCH=1</code>.</p>
 <p>Having that option present will prevent
 <code class="filename">/usr/bin/ftp</code> from falling back to active
 transfers.</p>
 </div>
 <div class="sect1">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
 <a name="fetching-all-distfiles"></a>10.9. How to fetch all distfiles at once</h2></div></div></div>
 <p>You would like to download all the distfiles in a single batch
 from work or university, where you can't run a <span class="command"><strong>make
 fetch</strong></span>.  There is an archive of distfiles on <a class="ulink" href="ftp://ftp.NetBSD.org/pub/pkgsrc/distfiles/" target="_top">ftp.NetBSD.org</a>,
 but downloading the entire directory may not be appropriate.</p>
 <p>The answer here is to do a <span class="command"><strong>make fetch-list</strong></span> in
 <code class="filename">/usr/pkgsrc</code> or one of its subdirectories, carry the
 resulting list to your machine at work/school and use it there.  If you
 don't have a NetBSD-compatible <a class="citerefentry" href="https://netbsd.gw.com/cgi-bin/man-cgi?ftp+1.i386+NetBSD-9.0"><span class="citerefentry"><span class="refentrytitle">ftp</span>(1)</span></a> (like tnftp) at work, don't
 forget to set <code class="varname">FETCH_CMD</code> to something that fetches a
 URL:</p>
 <p>At home:</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>make fetch-list FETCH_CMD=wget DISTDIR=/tmp/distfiles &gt;/tmp/fetch.sh</code></strong>
 <code class="prompt">%</code> <strong class="userinput"><code>scp /tmp/fetch.sh work:/tmp</code></strong></pre>
 <p>At work:</p>
 <pre class="screen"><code class="prompt">%</code> <strong class="userinput"><code>sh /tmp/fetch.sh</code></strong></pre>
 <p>then tar up <code class="filename">/tmp/distfiles</code> and take it
 home.</p>
 <p>If you have a machine running NetBSD, and you want to get
 <span class="emphasis"><em>all</em></span> distfiles (even ones that aren't for your
 machine architecture), you can do so by using the above-mentioned
 <span class="command"><strong>make fetch-list</strong></span> approach, or fetch the distfiles
 directly by running:</p>
 <pre class="screen"><code class="prompt">%</code> <strong class="userinput"><code>make mirror-distfiles</code></strong></pre>
 <p>If you even decide to ignore
 <code class="varname">NO_{SRC,BIN}_ON_{FTP,CDROM}</code>, then you can get everything
 by running:</p>
 <pre class="screen"><code class="prompt">%</code> <strong class="userinput"><code>make fetch NO_SKIP=yes</code></strong></pre>
 </div>
 <div class="sect1">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
 <a name="tmac.andoc-missing"></a>10.10. What does <span class="quote">&#8220;<span class="quote">Don't know how to make
 /usr/share/tmac/tmac.andoc</span>&#8221;</span> mean?</h2></div></div></div>
 <p>When compiling the <a href="https://cdn.NetBSD.org/pub/pkgsrc/current/pkgsrc/pkgtools/pkg_install/README.html" target="_top"><code class="filename">pkgtools/pkg_install</code></a>
 package, you get the error from make that it doesn't know how to make
 <code class="filename">/usr/share/tmac/tmac.andoc</code>? This indicates that
 you don't have installed the <span class="quote">&#8220;<span class="quote">text</span>&#8221;</span> set (nroff, ...) from
 the NetBSD base distribution on your machine.  It is recommended to do
 that to format man pages.</p>
 <p>In the case of the <a href="https://cdn.NetBSD.org/pub/pkgsrc/current/pkgsrc/pkgtools/pkg_install/README.html" target="_top"><code class="filename">pkgtools/pkg_install</code></a> package, you
 can get away with setting <code class="varname">NOMAN=YES</code> either in the
 environment or in <a class="link" href="#mk.conf"><code class="filename">mk.conf</code></a>.</p>
 </div>
 <div class="sect1">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
 <a name="bsd.own.mk-missing"></a>10.11. What does <span class="quote">&#8220;<span class="quote">Could not find bsd.own.mk</span>&#8221;</span> mean?</h2></div></div></div>
 <p>You didn't install the compiler set, <code class="filename">comp.tgz</code>,
 when you installed your NetBSD machine.  Please get and install it, by
 extracting it in <code class="filename">/</code>:</p>
 <pre class="screen"><code class="prompt">#</code> <strong class="userinput"><code>cd /</code></strong>
 <code class="prompt">#</code> <strong class="userinput"><code>tar --unlink -zxvpf .../comp.tgz</code></strong></pre>
 <p><code class="filename">comp.tgz</code> is part of every NetBSD release.  Get
 the one that corresponds to your release (determine via <span class="command"><strong>uname
 -r</strong></span>).</p>
 </div>
 <div class="sect1">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
 <a name="using-sudo-with-pkgsrc"></a>10.12. Using 'sudo' with pkgsrc</h2></div></div></div>
 <p>When installing packages as non-root user and using the just-in-time
 <a class="citerefentry" href="https://netbsd.gw.com/cgi-bin/man-cgi?su+1.i386+NetBSD-9.0"><span class="citerefentry"><span class="refentrytitle">su</span>(1)</span></a> 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 (either as binary package or from
 <a href="https://cdn.NetBSD.org/pub/pkgsrc/current/pkgsrc/security/sudo/README.html" target="_top"><code class="filename">security/sudo</code></a>) and then put the
 following into your <a class="link" href="#mk.conf"><code class="filename">mk.conf</code></a>, somewhere
 <span class="emphasis"><em>after</em></span> the definition of the
 <code class="varname">LOCALBASE</code> variable:</p>
 <pre class="programlisting">
 .if exists(${LOCALBASE}/bin/sudo)
 SU_CMD=        ${LOCALBASE}/bin/sudo /bin/sh -c
 .endif
 </pre>
 </div>
 <div class="sect1">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
 <a name="faq.conf"></a>10.13. How do I change the location of configuration files?</h2></div></div></div>
 <p>As the system administrator, you can choose where configuration files
 are installed.  The default settings make all these files go into
 <code class="filename">${PREFIX}/etc</code> or some of its subdirectories; this may
 be suboptimal depending on your expectations (e.g., a read-only,
 NFS-exported <code class="varname">PREFIX</code> with a need of per-machine
 configuration of the provided packages).</p>
 <p>In order to change the defaults, you can modify the
 <code class="varname">PKG_SYSCONFBASE</code> variable (in
 <a class="link" href="#mk.conf"><code class="filename">mk.conf</code></a>) to point to your preferred configuration
 directory; some common examples include <code class="filename">/etc</code> or
 <code class="filename">/etc/pkg</code>.</p>
 <p>Furthermore, you can change this value on a per-package basis by
 setting the <code class="varname">PKG_SYSCONFDIR.${PKG_SYSCONFVAR}</code> variable.
 <code class="varname">PKG_SYSCONFVAR</code>'s value usually matches the name of the
 package you would like to modify, that is, the contents of
 <code class="varname">PKGBASE</code>.</p>
 <p>Note that after changing these settings, you must rebuild and
 reinstall any affected packages.</p>
 </div>
 <div class="sect1">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
 <a name="audit-packages"></a>10.14. Automated security checks</h2></div></div></div>
 <p>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
 <a href="https://cdn.NetBSD.org/pub/pkgsrc/current/pkgsrc/pkgtools/pkg_install/README.html" target="_top"><code class="filename">pkgtools/pkg_install</code></a> package):</p>
 <div class="orderedlist"><ol class="orderedlist" type="1">
 <li class="listitem">
 <p><span class="command"><strong>pkg_admin fetch-pkg-vulnerabilities</strong></span>, 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:</p>
 <p><a class="ulink" href="https://ftp.NetBSD.org/pub/NetBSD/packages/vulns/pkg-vulnerabilities" target="_top">https://ftp.NetBSD.org/pub/NetBSD/packages/vulns/pkg-vulnerabilities</a></p>
 </li>
 <li class="listitem"><p><span class="command"><strong>pkg_admin audit</strong></span>, 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.</p></li>
 </ol></div>
 <p>Use of these tools is strongly recommended!
 See <a class="xref" href="#vulnerabilities" title="5.1.5. Checking for security vulnerabilities in installed packages">Section 5.1.5, &#8220;Checking for security vulnerabilities in installed packages&#8221;</a> for instructions on how to automate checking and
 reporting.</p>
 <p>If this database is installed, pkgsrc builds will use it to
 perform a security check before building any package.</p>
 </div>
 <div class="sect1">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
 <a name="ufaq-cflags"></a>10.15. Why do some packages ignore my <code class="varname">CFLAGS</code>?</h2></div></div></div>
 <p>When you add your own preferences to the
 	<code class="varname">CFLAGS</code> variable in your
 	<a class="link" href="#mk.conf"><code class="filename">mk.conf</code></a>, these flags are passed in
 	environment variables to the <code class="filename">./configure</code>
 	scripts and to <a class="citerefentry" href="https://netbsd.gw.com/cgi-bin/man-cgi?make+1.i386+NetBSD-9.0"><span class="citerefentry"><span class="refentrytitle">make</span>(1)</span></a>. Some package authors ignore the
 	<code class="varname">CFLAGS</code> from the environment variable by
 	overriding them in the <code class="filename">Makefile</code>s of their
 	package.</p>
 <p>Currently there is no solution to this problem. If you
 	really need the package to use your <code class="varname">CFLAGS</code>
 	you should run <span class="command"><strong>make patch</strong></span> in the package
 	directory and then inspect any <code class="filename">Makefile</code> and
 	<code class="filename">Makefile.in</code> for whether they define
 	<code class="varname">CFLAGS</code> explicitly. Usually you can remove
 	these lines. But be aware that some <span class="quote">&#8220;<span class="quote">smart</span>&#8221;</span>
 	programmers write so bad code that it only works for the
 	specific combination of <code class="varname">CFLAGS</code> they have
 	chosen.</p>
 <p>To find out where the CFLAGS are ignored, add the following lines to <a class="link" href="#mk.conf"><code class="filename">mk.conf</code></a>:</p>
 <pre class="programlisting">
 CPPFLAGS+=              -Dpkgsrc___CPPFLAGS
 CFLAGS+=                -Dpkgsrc___CFLAGS
 CXXFLAGS+=              -Dpkgsrc___CXXFLAGS
 </pre>
 <p>Then run <span class="command"><strong>bmake show-all-configure show-all-build</strong></span>
 to see whether the above flags are passed to the actual build
 commands in general.</p>
 <p>To find out whether the flags are passed to individual compiler
 commands, have a look at the file <code class="filename">work/.work.log</code>. In
 most cases, the flags from the original command lines (the lines starting
 with <code class="literal">[*]</code>) are passed unmodified to the actual compiler
 (the lines starting with <code class="literal">&lt;.&gt;</code>). If the flag is
 missing from the actual compiler command, it must have been removed by
 the <a class="link" href="#build.wrapper" title="19.10. The wrapper phase">pkgsrc compiler wrappers</a>.</p>
 </div>
 <div class="sect1">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
 <a name="ufaq-fail"></a>10.16. A package does not build.  What shall I do?</h2></div></div></div>
 <div class="procedure"><ol class="procedure" type="1">
 <li class="step"><p>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.</p></li>
 <li class="step"><p>Make sure that you don't have any CVS conflicts.
 	Search for <span class="quote">&#8220;<span class="quote">&lt;&lt;&lt;&lt;&lt;&lt;</span>&#8221;</span> or
 	<span class="quote">&#8220;<span class="quote">&gt;&gt;&gt;&gt;&gt;&gt;</span>&#8221;</span> in all your pkgsrc
 	files.</p></li>
 <li class="step"><p>Make sure that you don't have old copies of the packages
 	extracted. Run <span class="command"><strong>make clean clean-depends</strong></span> to
 	verify this.</p></li>
 <li class="step"><p>If you are a package developer who wants to invest
 	some work, have a look at <a class="xref" href="#fixes" title="Chapter 21. Making your package work">Chapter 21, <i>Making your package work</i></a>.</p></li>
 <li class="step"><p>If the problem still exists, write a mail to the
 	<code class="literal">pkgsrc-users</code> mailing list.</p></li>
 </ol></div>
 </div>
 <div class="sect1">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
 <a name="faq.rcs-conflicts"></a>10.17. What does <span class="quote">&#8220;<span class="quote">Makefile appears to contain unresolved cvs/rcs/??? merge conflicts</span>&#8221;</span> mean?</h2></div></div></div>
 <p>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
 <code class="literal">cvs</code> command marked the conflicting changes in the
 file. Because of these markers, the file is no longer a valid
 <code class="filename">Makefile</code>.</p>
 <p>Have a look at that file, and if you don't need your local changes
 anymore, you can remove that file and run <span class="command"><strong>cvs -q update
 -dP</strong></span> in that directory to download the current version.</p>
 </div>
 </div>
 </div>
 <div class="part">
 <div class="titlepage"><div><div><h1 class="title">
 <a name="developers-guide"></a>Part II. The pkgsrc developer's guide</h1></div></div></div>
 <div class="partintro">
 <div></div>
 <p>This part of the book deals with creating and
 	modifying packages. It starts with a <span class="quote">&#8220;<span class="quote">HOWTO</span>&#8221;</span>-like
 	guide on creating a new package. The remaining chapters are more
 	like a reference manual for pkgsrc.</p>
 <div class="toc">
 <p><b>Table of Contents</b></p>
 <dl class="toc">
 <dt><span class="chapter"><a href="#help-devel">11. Getting help</a></span></dt>
 <dt><span class="chapter"><a href="#creating">12. Creating a new pkgsrc package from scratch</a></span></dt>
 <dd><dl>
 <dt><span class="sect1"><a href="#creating.common">12.1. Common types of packages</a></span></dt>
 <dd><dl>
 <dt><span class="sect2"><a href="#creating.perl-module">12.1.1. Perl modules</a></span></dt>
 <dt><span class="sect2"><a href="#creating.python-module">12.1.2. Python modules and programs</a></span></dt>
 <dt><span class="sect2"><a href="#creating.R-package">12.1.3. R packages</a></span></dt>
 <dt><span class="sect2"><a href="#creating.TeX-package">12.1.4. TeXlive packages</a></span></dt>
 </dl></dd>
 <dt><span class="sect1"><a href="#creating.examples">12.2. Examples</a></span></dt>
 <dd><dl><dt><span class="sect2"><a href="#creating.nvu">12.2.1. How the www/nvu package came into pkgsrc</a></span></dt></dl></dd>
 </dl></dd>
 <dt><span class="chapter"><a href="#components">13. Package components - files, directories and contents</a></span></dt>
 <dd><dl>
 <dt><span class="sect1"><a href="#components.Makefile">13.1. <code class="filename">Makefile</code></a></span></dt>
 <dt><span class="sect1"><a href="#components.distinfo">13.2. <code class="filename">distinfo</code></a></span></dt>
 <dt><span class="sect1"><a href="#components.patches">13.3. <code class="filename">patches/*</code></a></span></dt>
 <dd><dl>
 <dt><span class="sect2"><a href="#components.patch.structure">13.3.1. Structure of a single patch file</a></span></dt>
 <dt><span class="sect2"><a href="#components.patches.caveats">13.3.2. Creating patch files</a></span></dt>
 <dt><span class="sect2"><a href="#components.patches.sources">13.3.3. Sources where the patch files come from</a></span></dt>
 <dt><span class="sect2"><a href="#components.patches.guidelines">13.3.4. Patching guidelines</a></span></dt>
 <dt><span class="sect2"><a href="#components.patches.feedback">13.3.5. Feedback to the author</a></span></dt>
 </dl></dd>
 <dt><span class="sect1"><a href="#other-mandatory-files">13.4. Other mandatory files</a></span></dt>
 <dt><span class="sect1"><a href="#components.optional">13.5. Optional files</a></span></dt>
 <dd><dl>
 <dt><span class="sect2"><a href="#components.optional.bin">13.5.1. Files affecting the binary package</a></span></dt>
 <dt><span class="sect2"><a href="#components.optional.build">13.5.2. Files affecting the build process</a></span></dt>
 <dt><span class="sect2"><a href="#components.optional.none">13.5.3. Files affecting nothing at all</a></span></dt>
 </dl></dd>
 <dt><span class="sect1"><a href="#work-dir">13.6. <code class="filename">work*</code></a></span></dt>
 <dt><span class="sect1"><a href="#files-dir">13.7. <code class="filename">files/*</code></a></span></dt>
 </dl></dd>
 <dt><span class="chapter"><a href="#makefile">14. Programming in <code class="filename">Makefile</code>s</a></span></dt>
 <dd><dl>
 <dt><span class="sect1"><a href="#makefile.style">14.1. Caveats</a></span></dt>
 <dt><span class="sect1"><a href="#makefile.variables">14.2. <code class="filename">Makefile</code> variables</a></span></dt>
 <dd><dl><dt><span class="sect2"><a href="#makefile.variables.names">14.2.1. Naming conventions</a></span></dt></dl></dd>
 <dt><span class="sect1"><a href="#makefile.code">14.3. Code snippets</a></span></dt>
 <dd><dl>
 <dt><span class="sect2"><a href="#adding-to-list">14.3.1. Adding things to a list</a></span></dt>
 <dt><span class="sect2"><a href="#echo-literal">14.3.2. Echoing a string exactly as-is</a></span></dt>
 <dt><span class="sect2"><a href="#cflags-gnu-configure">14.3.3. Passing <code class="varname">CFLAGS</code> to GNU configure scripts</a></span></dt>
 <dt><span class="sect2"><a href="#empty-variables">14.3.4. Handling possibly empty variables</a></span></dt>
 </dl></dd>
 </dl></dd>
 <dt><span class="chapter"><a href="#plist">15. PLIST issues</a></span></dt>
 <dd><dl>
 <dt><span class="sect1"><a href="#rcs-id">15.1. RCS ID</a></span></dt>
 <dt><span class="sect1"><a href="#automatic-plist-generation">15.2. Semi-automatic <code class="filename">PLIST</code> generation</a></span></dt>
 <dt><span class="sect1"><a href="#print-PLIST">15.3. Tweaking output of <span class="command"><strong>make print-PLIST</strong></span></a></span></dt>
 <dt><span class="sect1"><a href="#plist.misc">15.4. Variable substitution in PLIST</a></span></dt>
 <dt><span class="sect1"><a href="#manpage-compression">15.5. Man page compression</a></span></dt>
 <dt><span class="sect1"><a href="#using-PLIST_SRC">15.6. Changing PLIST source with <code class="varname">PLIST_SRC</code></a></span></dt>
 <dt><span class="sect1"><a href="#platform-specific-plist">15.7. Platform-specific and differing PLISTs</a></span></dt>
 <dt><span class="sect1"><a href="#build-plist">15.8. Build-specific PLISTs</a></span></dt>
 <dt><span class="sect1"><a href="#faq.common-dirs">15.9. Sharing directories between packages</a></span></dt>
 </dl></dd>
 <dt><span class="chapter"><a href="#buildlink">16. Buildlink methodology</a></span></dt>
 <dd><dl>
 <dt><span class="sect1"><a href="#converting-to-buildlink3">16.1. Converting packages to use buildlink3</a></span></dt>
 <dt><span class="sect1"><a href="#creating-buildlink3.mk">16.2. Writing <code class="filename">buildlink3.mk</code> files</a></span></dt>
 <dd><dl>
 <dt><span class="sect2"><a href="#anatomy-of-bl3">16.2.1. Anatomy of a buildlink3.mk file</a></span></dt>
 <dt><span class="sect2"><a href="#updating-buildlink-depends">16.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">16.3. Writing <code class="filename">builtin.mk</code> files</a></span></dt>
 <dd><dl>
 <dt><span class="sect2"><a href="#anatomy-of-builtin.mk">16.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">16.3.2. Global preferences for native or pkgsrc software</a></span></dt>
 </dl></dd>
 </dl></dd>
 <dt><span class="chapter"><a href="#pkginstall">17. The pkginstall framework</a></span></dt>
 <dd><dl>
 <dt><span class="sect1"><a href="#files-and-dirs-outside-prefix">17.1. Files and directories outside the installation prefix</a></span></dt>
 <dd><dl>
 <dt><span class="sect2"><a href="#dirs-outside-prefix">17.1.1. Directory manipulation</a></span></dt>
 <dt><span class="sect2"><a href="#files-outside-prefix">17.1.2. File manipulation</a></span></dt>
 </dl></dd>
 <dt><span class="sect1"><a href="#conf-files">17.2. Configuration files</a></span></dt>
 <dd><dl>
 <dt><span class="sect2"><a href="#conf-files-sysconfdir">17.2.1. How <code class="varname">PKG_SYSCONFDIR</code> is set</a></span></dt>
 <dt><span class="sect2"><a href="#conf-files-configure">17.2.2. Telling the software where configuration files are</a></span></dt>
 <dt><span class="sect2"><a href="#conf-files-patching">17.2.3. Patching installations</a></span></dt>
 <dt><span class="sect2"><a href="#conf-files-disable">17.2.4. Disabling handling of configuration files</a></span></dt>
 </dl></dd>
 <dt><span class="sect1"><a href="#rcd-scripts">17.3. System startup scripts</a></span></dt>
 <dd><dl><dt><span class="sect2"><a href="#rcd-scripts-disable">17.3.1. Disabling handling of system startup scripts</a></span></dt></dl></dd>
 <dt><span class="sect1"><a href="#users-and-groups">17.4. System users and groups</a></span></dt>
 <dt><span class="sect1"><a href="#shells">17.5. System shells</a></span></dt>
 <dd><dl><dt><span class="sect2"><a href="#shells-disable">17.5.1. Disabling shell registration</a></span></dt></dl></dd>
 <dt><span class="sect1"><a href="#fonts">17.6. Fonts</a></span></dt>
 <dd><dl><dt><span class="sect2"><a href="#fonts-disable">17.6.1. Disabling automatic update of the fonts databases</a></span></dt></dl></dd>
 </dl></dd>
 <dt><span class="chapter"><a href="#options">18. Options handling</a></span></dt>
 <dd><dl>
 <dt><span class="sect1"><a href="#global-default-options">18.1. Global default options</a></span></dt>
 <dt><span class="sect1"><a href="#converting-to-options">18.2. Converting packages to use <code class="filename">bsd.options.mk</code></a></span></dt>
 <dt><span class="sect1"><a href="#option-names">18.3. Option Names</a></span></dt>
 <dt><span class="sect1"><a href="#option-build">18.4. Determining the options of dependencies</a></span></dt>
 </dl></dd>
 <dt><span class="chapter"><a href="#build">19. The build process</a></span></dt>
 <dd><dl>
 <dt><span class="sect1"><a href="#build.intro">19.1. Introduction</a></span></dt>
 <dt><span class="sect1"><a href="#build.prefix">19.2. Program location</a></span></dt>
 <dt><span class="sect1"><a href="#build.builddirs">19.3. Directories used during the build process</a></span></dt>
 <dt><span class="sect1"><a href="#build.running">19.4. Running a phase</a></span></dt>
 <dt><span class="sect1"><a href="#build.fetch">19.5. The <span class="emphasis"><em>fetch</em></span> phase</a></span></dt>
 <dd><dl>
 <dt><span class="sect2"><a href="#build.fetch.what">19.5.1. What to fetch and where to get it from</a></span></dt>
 <dt><span class="sect2"><a href="#build.fetch.how">19.5.2. How are the files fetched?</a></span></dt>
 </dl></dd>
 <dt><span class="sect1"><a href="#build.checksum">19.6. The <span class="emphasis"><em>checksum</em></span> phase</a></span></dt>
 <dt><span class="sect1"><a href="#build.extract">19.7. The <span class="emphasis"><em>extract</em></span> phase</a></span></dt>
 <dt><span class="sect1"><a href="#build.patch">19.8. The <span class="emphasis"><em>patch</em></span> phase</a></span></dt>
 <dt><span class="sect1"><a href="#build.tools">19.9. The <span class="emphasis"><em>tools</em></span> phase</a></span></dt>
 <dt><span class="sect1"><a href="#build.wrapper">19.10. The <span class="emphasis"><em>wrapper</em></span> phase</a></span></dt>
 <dt><span class="sect1"><a href="#build.configure">19.11. The <span class="emphasis"><em>configure</em></span> phase</a></span></dt>
 <dt><span class="sect1"><a href="#build.build">19.12. The <span class="emphasis"><em>build</em></span> phase</a></span></dt>
 <dt><span class="sect1"><a href="#build.test">19.13. The <span class="emphasis"><em>test</em></span> phase</a></span></dt>
 <dt><span class="sect1"><a href="#build.install">19.14. The <span class="emphasis"><em>install</em></span> phase</a></span></dt>
 <dt><span class="sect1"><a href="#build.package">19.15. The <span class="emphasis"><em>package</em></span> phase</a></span></dt>
 <dt><span class="sect1"><a href="#build.clean">19.16. Cleaning up</a></span></dt>
 <dt><span class="sect1"><a href="#build.helpful-targets">19.17. Other helpful targets</a></span></dt>
 </dl></dd>
 <dt><span class="chapter"><a href="#tools">20. Tools needed for building or running</a></span></dt>
 <dd><dl>
 <dt><span class="sect1"><a href="#pkgsrc-tools">20.1. Tools for pkgsrc builds</a></span></dt>
 <dt><span class="sect1"><a href="#package-tools">20.2. Tools needed by packages</a></span></dt>
 <dt><span class="sect1"><a href="#platform-tools">20.3. Tools provided by platforms</a></span></dt>
 </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>
 </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="#perl-scripts">21.4.3. Packages containing perl scripts</a></span></dt>
 <dt><span class="sect2"><a href="#shell-scripts">21.4.4. Packages containing shell scripts</a></span></dt>
 <dt><span class="sect2"><a href="#other-programming-languages">21.4.5. 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="#gconf-data-files">21.6.9. Packages installing GConf data files</a></span></dt>
 <dt><span class="sect2"><a href="#scrollkeeper-data-files">21.6.10. Packages installing scrollkeeper/rarian data files</a></span></dt>
 <dt><span class="sect2"><a href="#x11-fonts">21.6.11. Packages installing X11 fonts</a></span></dt>
 <dt><span class="sect2"><a href="#gtk2-modules">21.6.12. Packages installing GTK2 modules</a></span></dt>
 <dt><span class="sect2"><a href="#sgml-xml-data">21.6.13. Packages installing SGML or XML data</a></span></dt>
 <dt><span class="sect2"><a href="#mime-database">21.6.14. Packages installing extensions to the MIME database</a></span></dt>
 <dt><span class="sect2"><a href="#intltool">21.6.15. Packages using intltool</a></span></dt>
 <dt><span class="sect2"><a href="#startup-scripts">21.6.16. Packages installing startup scripts</a></span></dt>
 <dt><span class="sect2"><a href="#tex-packages">21.6.17. Packages installing TeX modules</a></span></dt>
 <dt><span class="sect2"><a href="#emulation-packages">21.6.18. Packages supporting running binaries in
     emulation</a></span></dt>
 <dt><span class="sect2"><a href="#hicolor-theme">21.6.19. Packages installing hicolor theme icons</a></span></dt>
 <dt><span class="sect2"><a href="#desktop-files">21.6.20. 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="#debug">22. Debugging</a></span></dt>
 <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>
 <dt><span class="chapter"><a href="#gnome">25. GNOME packaging and porting</a></span></dt>
 <dd><dl>
 <dt><span class="sect1"><a href="#meta-packages">25.1. Meta packages</a></span></dt>
 <dt><span class="sect1"><a href="#new-package">25.2. Packaging a GNOME application</a></span></dt>
 <dt><span class="sect1"><a href="#full-update">25.3. Updating GNOME to a newer version</a></span></dt>
 <dt><span class="sect1"><a href="#patching">25.4. Patching guidelines</a></span></dt>
 </dl></dd>
 </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 D. Help topics">Appendix D, <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="creating"></a>Chapter 12. 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">12.1. Common types of packages</a></span></dt>
 <dd><dl>
 <dt><span class="sect2"><a href="#creating.perl-module">12.1.1. Perl modules</a></span></dt>
 <dt><span class="sect2"><a href="#creating.python-module">12.1.2. Python modules and programs</a></span></dt>
 <dt><span class="sect2"><a href="#creating.R-package">12.1.3. R packages</a></span></dt>
 <dt><span class="sect2"><a href="#creating.TeX-package">12.1.4. TeXlive packages</a></span></dt>
 </dl></dd>
 <dt><span class="sect1"><a href="#creating.examples">12.2. Examples</a></span></dt>
 <dd><dl><dt><span class="sect2"><a href="#creating.nvu">12.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>First, install the packages <a href="https://cdn.NetBSD.org/pub/pkgsrc/current/pkgsrc/pkgtools/url2pkg/README.html" target="_top"><code class="filename">pkgtools/url2pkg</code></a> and <a href="https://cdn.NetBSD.org/pub/pkgsrc/current/pkgsrc/pkgtools/pkglint/README.html" target="_top"><code class="filename">pkgtools/pkglint</code></a>.</p></li>
 <li class="step"><p>Then, 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>). In that
 category directory, create another directory for your package and change
 into it.</p></li>
 <li class="step"><p>Run the program <span class="command"><strong>url2pkg</strong></span>, which will ask
 you for a URL. Enter the URL of the distribution file (in most cases a
 <code class="filename">.tar.gz</code> file) and watch how the basic ingredients
 of your package are created automatically. The distribution file is
 extracted automatically to fill in some details in the
 <code class="filename">Makefile</code> that would otherwise have to be done
 manually.</p></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 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 architecture 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 architecture for which the package
 is built. There is also <code class="varname">TEST_DEPENDS</code>, which is used
 to specify a dependency used only for testing the resulting package
 built, using the upstream project's included test suite.
 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="12.1. Common types of packages">Section 12.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

 @@ -1,3076 +1,3009 @@
 The pkgsrc guide
 Documentation on the NetBSD packages system
 Alistair Crooks
 <agc@NetBSD.org>
 Hubert Feyrer
 <hubertf@NetBSD.org>
 The pkgsrc Developers
 Copyright   1994-2020 The NetBSD Foundation, Inc
 $NetBSD: pkgsrc.xml,v 1.36 2020/01/03 15:55:24 leot Exp $
 Abstract
 pkgsrc is a centralized package management system for Unix-like operating
 systems. This guide provides information for users and developers of pkgsrc. It
 covers installation of binary and source packages, creation of binary and
 source packages and a high-level overview about the infrastructure.
 -------------------------------------------------------------------------------
 Table of Contents
 . What is pkgsrc?
 .1. Introduction
 .1.1. Why pkgsrc?
 .1.2. Supported platforms
 .2. Overview
 .3. Terminology
 .3.1. Roles involved in pkgsrc
 .4. Typography
 I. The pkgsrc user's guide
 . Getting help
 . Where to get pkgsrc and how to keep it up-to-date
 .1. Getting pkgsrc for the first time
 .1.1. As tar archive
 .1.2. Via anonymous CVS
 .2. Keeping pkgsrc up-to-date
 .2.1. Via tar files
 .2.2. Via CVS
 . Using pkgsrc on systems other than NetBSD
 .1. Binary distribution
 .2. Bootstrapping pkgsrc
 . Using pkgsrc
 .1. Using binary packages
 .1.1. Finding binary packages
 .1.2. Installing binary packages
 .1.3. Deinstalling packages
 .1.4. Getting information about installed packages
 .1.5. Checking for security vulnerabilities in installed packages
 .1.6. Finding if newer versions of your installed packages are in
                 pkgsrc
 .1.7. Other administrative functions
 .2. Building packages from source
 .2.1. Requirements
 .2.2. Fetching distfiles
 .2.3. How to build and install
 . Configuring pkgsrc
 .1. General configuration
 .2. Variables affecting the build process
 .3. Variables affecting the installation process
 .4. Selecting and configuring the compiler
 .4.1. Selecting the compiler
 .4.2. Additional flags to the compiler (CFLAGS)
 .4.3. Additional flags to the linker (LDFLAGS)
 .5. Developer/advanced settings
 .6. Selecting Build Options
 . Creating binary packages
 .1. Building a single binary package
 .2. Settings for creation of binary packages
 . Creating binary packages for everything in pkgsrc (bulk builds)
 .1. Preparations
 .2. Running a pbulk-style bulk build
 .2.1. Configuration
 .3. Requirements of a full bulk build
 .4. Bulk build variants
-.4.1. Strict SUBST blocks
+.4.1. Detect unknown configure options
-.4.2. Detect unknown configure options
+.4.2. Detect classes of bugs by forcing compiler warnings
-.4.3. Detect classes of bugs by forcing compiler warnings
+.4.3. Use custom directories
-.4.4. Use custom directories
+.4.4. Turn warnings into errors
-.4.5. Turn warnings into errors
+.4.5. Reject packages for which pkglint reports errors
-.4.6. Reject packages for which pkglint reports errors
+.4.6. Reject packages that contain forbidden strings
-.4.7. Reject packages that contain forbidden strings
+.4.7. Reject packages whose self-test fails
-.4.8. Reject packages whose self-test fails
+.4.8. Reject packages that use undefined shell variables
-.4.9. Reject packages that use undefined shell variables
+.4.9. Turn off verbose logging
 .4.10. Turn off verbose logging
 .4.11. Select random sets of options
 .4.12. Select random configurations of BUILD_DEFS
 .5. Creating a multiple CD-ROM packages collection
 .5.1. Example of cdpack
 . Directory layout of the installed files
 .1. File system layout in ${LOCALBASE}
 .2. File system layout in ${VARBASE}
 . Frequently Asked Questions
 .1. Are there any mailing lists for pkg-related discussion?
 .2. Utilities for package management (pkgtools)
 .3. How to use pkgsrc as non-root
 .4. How to resume transfers when fetching distfiles?
 .5. How can I install/use modular X.org from pkgsrc?
 .6. How to fetch files from behind a firewall
 .7. How to fetch files from HTTPS sites
 .8. How do I tell make fetch to do passive FTP?
 .9. How to fetch all distfiles at once
 .10. What does "Don't know how to make /usr/share/tmac/tmac.andoc"
             mean?
 .11. What does "Could not find bsd.own.mk" mean?
 .12. Using 'sudo' with pkgsrc
 .13. How do I change the location of configuration files?
 .14. Automated security checks
 .15. Why do some packages ignore my CFLAGS?
 .16. A package does not build. What shall I do?
 .17. What does "Makefile appears to contain unresolved cvs/rcs/???
             merge conflicts" mean?
 II. The pkgsrc developer's guide
 . Getting help
 . Creating a new pkgsrc package from scratch
 .1. Common types of packages
 .1.1. Perl modules
 .1.2. Python modules and programs
 .1.3. R packages
 .1.4. TeXlive packages
 .2. Examples
 .2.1. How the www/nvu package came into pkgsrc
 . 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/*
 . 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
 . 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
 . 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
 . 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
 . Options handling
 .1. Global default options
 .2. Converting packages to use bsd.options.mk
 .3. Option Names
 .4. Determining the options of dependencies
 . 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
 . Tools needed for building or running
 .1. Tools for pkgsrc builds
 .2. Tools needed by packages
 .3. Tools provided by platforms
 . 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
 .4. Programming languages
 .4.1. C, C++, and Fortran
 .4.2. Java
 .4.3. Packages containing perl scripts
 .4.4. Packages containing shell scripts
 .4.5. 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 GConf data files
 .6.10. Packages installing scrollkeeper/rarian data files
 .6.11. Packages installing X11 fonts
 .6.12. Packages installing GTK2 modules
 .6.13. Packages installing SGML or XML data
 .6.14. Packages installing extensions to the MIME database
 .6.15. Packages using intltool
 .6.16. Packages installing startup scripts
 .6.17. Packages installing TeX modules
 .6.18. Packages supporting running binaries in emulation
 .6.19. Packages installing hicolor theme icons
 .6.20. Packages installing desktop files
 .7. Marking packages as having problems
 . Debugging
 . 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
 . GNOME packaging and porting
 .1. Meta packages
 .2. Packaging a GNOME application
 .3. Updating GNOME to a newer version
 .4. Patching guidelines
 III. The pkgsrc infrastructure internals
 . 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
 A. A simple example package: bison
     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
 B. Build logs
     B.1. Building figlet
     B.2. Packaging figlet
 C. Directory layout of the pkgsrc FTP server
     C.1. distfiles: The distributed source files
     C.2. misc: Miscellaneous things
     C.3. packages: Binary packages
     C.4. reports: Bulk build reports
     C.5. current, stable, pkgsrc-20xxQy: source packages
 D. Help topics
 E. Editing guidelines for the pkgsrc guide
     E.1. Make targets
     E.2. Procedure
 List of Tables
 .1. Platforms supported by pkgsrc
 .1. Patching examples
 .1. PLIST handling for GNOME packages
 Chapter 1. What is pkgsrc?
 Table of Contents
 .1. Introduction
 .1.1. Why pkgsrc?
 .1.2. Supported platforms
 .2. Overview
 .3. Terminology
 .3.1. Roles involved in pkgsrc
 .4. Typography
 .1. Introduction
 There is a lot of software freely available for Unix-based systems, which is
 usually available in form of the source code. Before such software can be used,
 it needs to be configured to the local system, compiled and installed, and this
 is exactly what The NetBSD Packages Collection (pkgsrc) does. pkgsrc also has
 some basic commands to handle binary packages, so that not every user has to
 build the packages for himself, which is a time-costly task.
 pkgsrc currently contains several thousand packages, including:
   * www/apache24 - The Apache web server
   * www/firefox - The Firefox web browser
   * meta-pkgs/gnome - The GNOME Desktop Environment
   * meta-pkgs/kde4 - The K Desktop Environment
 ? just to name a few.
 pkgsrc has built-in support for handling varying dependencies, such as pthreads
 and X11, and extended features such as IPv6 support on a range of platforms.
 .1.1. Why pkgsrc?
 pkgsrc provides the following key features:
   * Easy building of software from source as well as the creation and
     installation of binary packages. The source and latest patches are
     retrieved from a master or mirror download site, checksum verified, then
     built on your system. Support for binary-only distributions is available
     for both native platforms and NetBSD emulated platforms.
   * All packages are installed in a consistent directory tree, including
     binaries, libraries, man pages and other documentation.
   * Tracking of package dependencies automatically, including when performing
     updates, to ensure required packages are installed. The configuration files
     of various packages are handled automatically during updates, so local
     changes are preserved.
   * Like NetBSD, pkgsrc is designed with portability in mind and consists of
     highly portable code. This allows the greatest speed of development when
     porting to a new platform. This portability also ensures that pkgsrc is
     consistent across all platforms.
   * The installation prefix, acceptable software licenses, international
     encryption requirements and build-time options for a large number of
     packages are all set in a simple, central configuration file.
   * The entire source (not including the distribution files) is freely
     available under a BSD license, so you may extend and adapt pkgsrc to your
     needs. Support for local packages and patches is available right out of the
     box, so you can configure it specifically for your environment.
 The following principles are basic to pkgsrc:
   * "It should only work if it's right." ? That means, if a package contains
     bugs, it's better to find them and to complain about them rather than to
     just install the package and hope that it works. There are numerous checks
     in pkgsrc that try to find such bugs: static analysis tools (pkgtools/
     pkglint), build-time checks (portability of shell scripts), and
     post-installation checks (installed files, references to shared libraries,
     script interpreters).
   * "If it works, it should work everywhere" ? Like NetBSD has been ported to
     many hardware architectures, pkgsrc has been ported to many operating
     systems. Care is taken that packages behave the same on all platforms.
 .1.2. Supported platforms
 pkgsrc consists of both a source distribution and a binary distribution for
 these operating systems. After retrieving the required source or binaries, you
 can be up and running with pkgsrc in just minutes!
 pkgsrc was derived from FreeBSD's ports system, and initially developed for
 NetBSD only. Since then, pkgsrc has grown a lot, and now supports the following
 platforms:
 Table 1.1. Platforms supported by pkgsrc
 +-----------------------------------------------------------------------------+
 |               Platform               | Date Support  |        Notes         |
 |                                      |     Added     |                      |
 |--------------------------------------+---------------+----------------------|
 |NetBSD                                |   Aug 1997    |                      |
 |--------------------------------------+---------------+----------------------|
 |Solaris                               |   Mar 1999    |README.Solaris        |
 |--------------------------------------+---------------+----------------------|
 |Linux                                 |   Jun 1999    |README.Linux          |
 |--------------------------------------+---------------+----------------------|
 |Darwin / Mac OS X / OS X / macOS      |   Oct 2001    |README.MacOSX         |
 |--------------------------------------+---------------+----------------------|
 |FreeBSD                               |   Nov 2002    |README.FreeBSD        |
 |--------------------------------------+---------------+----------------------|
 |OpenBSD                               |   Nov 2002    |README.OpenBSD        |
 |--------------------------------------+---------------+----------------------|
 |IRIX                                  |   Dec 2002    |README.IRIX           |
 |                                      |               |README.IRIX5.3        |
 |--------------------------------------+---------------+----------------------|
 |BSD/OS                                |   Dec 2003    |                      |
 |--------------------------------------+---------------+----------------------|
 |AIX                                   |   Dec 2003    |README.AIX            |
 |--------------------------------------+---------------+----------------------|
 |Interix (Microsoft Windows Services   |   Mar 2004    |README.Interix        |
 |for Unix)                             |               |                      |
 |--------------------------------------+---------------+----------------------|
 |DragonFlyBSD                          |   Oct 2004    |                      |
 |--------------------------------------+---------------+----------------------|
 |OSF/1                                 |   Nov 2004    |README.OSF1           |
 |--------------------------------------+---------------+----------------------|
 |HP-UX                                 |   Apr 2007    |README.HPUX           |
 |--------------------------------------+---------------+----------------------|
 |Haiku                                 |   Sep 2010    |README.Haiku          |
 |--------------------------------------+---------------+----------------------|
 |MirBSD                                |   Jan 2011    |                      |
 |--------------------------------------+---------------+----------------------|
 |Minix3                                |   Nov 2011    |README.Minix3         |
 |--------------------------------------+---------------+----------------------|
 |Cygwin                                |   Mar 2013    |README.Cygwin         |
 |--------------------------------------+---------------+----------------------|
 |GNU/kFreeBSD                          |   Jul 2013    |README.GNUkFreeBSD    |
 |--------------------------------------+---------------+----------------------|
 |Bitrig                                |   Jun 2014    |README.Bitrig         |
 +-----------------------------------------------------------------------------+
 .2. Overview
 This document is divided into three parts. The first, The pkgsrc user's guide,
 describes how one can use one of the packages in the Package Collection, either
 by installing a precompiled binary package, or by building one's own copy using
 the NetBSD package system. The second part, The pkgsrc developer's guide,
 explains how to prepare a package so it can be easily built by other NetBSD
 users without knowing about the package's building details. The third part, The
 pkgsrc infrastructure internals is intended for those who want to understand
 how pkgsrc is implemented.
 This document is available in various formats: HTML, PDF, PS, TXT.
 .3. Terminology
 There has been a lot of talk about "ports", "packages", etc. so far. Here is a
 description of all the terminology used within this document.
 Package
     A set of files and building instructions that describe what's necessary to
     build a certain piece of software using pkgsrc. Packages are traditionally
     stored under /usr/pkgsrc, but may be stored in any location, referred to as
     PKGSRCDIR.
 The NetBSD package system
     This is the former name of "pkgsrc". It is part of the NetBSD operating
     system and can be bootstrapped to run on non-NetBSD operating systems as
     well. It handles building (compiling), installing, and removing of
     packages.
 Distfile
     This term describes the file or files that are provided by the author of
     the piece of software to distribute his work. All the changes necessary to
     build on NetBSD are reflected in the corresponding package. Usually the
     distfile is in the form of a compressed tar-archive, but other types are
     possible, too. Distfiles are usually stored below /usr/pkgsrc/distfiles.
 Port
     This is the term used by FreeBSD and OpenBSD people for what we call a
     package. In NetBSD terminology, "port" refers to a different architecture.
 Precompiled/binary package
     A set of binaries built with pkgsrc from a distfile and stuffed together in
     a single .tgz file so it can be installed on machines of the same machine
     architecture without the need to recompile. Packages are usually generated
     in /usr/pkgsrc/packages; there is also an archive on ftp.NetBSD.org.
     Sometimes, this is referred to by the term "package" too, especially in the
     context of precompiled packages.
 Program
     The piece of software to be installed which will be constructed from all
     the files in the distfile by the actions defined in the corresponding
     package.
 .3.1. Roles involved in pkgsrc
 pkgsrc users
     The pkgsrc users are people who use the packages provided by pkgsrc.
     Typically they are system administrators. The people using the software
     that is inside the packages (maybe called "end users") are not covered by
     the pkgsrc guide.
     There are two kinds of pkgsrc users: Some only want to install pre-built
     binary packages. Others build the pkgsrc packages from source, either for
     installing them directly or for building binary packages themselves. For
     pkgsrc users Part I, "The pkgsrc user's guide" should provide all necessary
     documentation.
 package maintainers
     A package maintainer creates packages as described in Part II, "The pkgsrc
     developer's guide".
 infrastructure developers
     These people are involved in all those files that live in the mk/ directory
     and below. Only these people should need to read through Part III, "The
     pkgsrc infrastructure internals", though others might be curious, too.
 .4. Typography
 When giving examples for commands, shell prompts are used to show if the
 command should/can be issued as root, or if "normal" user privileges are
 sufficient. We use a # for root's shell prompt, a % for users' shell prompt,
 assuming they use the C-shell or tcsh and a $ for bourne shell and derivatives.
 Part I. The pkgsrc user's guide
 Table of Contents
 . Getting help
 . Where to get pkgsrc and how to keep it up-to-date
 .1. Getting pkgsrc for the first time
 .1.1. As tar archive
 .1.2. Via anonymous CVS
 .2. Keeping pkgsrc up-to-date
 .2.1. Via tar files
 .2.2. Via CVS
 . Using pkgsrc on systems other than NetBSD
 .1. Binary distribution
 .2. Bootstrapping pkgsrc
 . Using pkgsrc
 .1. Using binary packages
 .1.1. Finding binary packages
 .1.2. Installing binary packages
 .1.3. Deinstalling packages
 .1.4. Getting information about installed packages
 .1.5. Checking for security vulnerabilities in installed packages
 .1.6. Finding if newer versions of your installed packages are in
             pkgsrc
 .1.7. Other administrative functions
 .2. Building packages from source
 .2.1. Requirements
 .2.2. Fetching distfiles
 .2.3. How to build and install
 . Configuring pkgsrc
 .1. General configuration
 .2. Variables affecting the build process
 .3. Variables affecting the installation process
 .4. Selecting and configuring the compiler
 .4.1. Selecting the compiler
 .4.2. Additional flags to the compiler (CFLAGS)
 .4.3. Additional flags to the linker (LDFLAGS)
 .5. Developer/advanced settings
 .6. Selecting Build Options
 . Creating binary packages
 .1. Building a single binary package
 .2. Settings for creation of binary packages
 . Creating binary packages for everything in pkgsrc (bulk builds)
 .1. Preparations
 .2. Running a pbulk-style bulk build
 .2.1. Configuration
 .3. Requirements of a full bulk build
 .4. Bulk build variants
-.4.1. Strict SUBST blocks
+.4.1. Detect unknown configure options
-.4.2. Detect unknown configure options
+.4.2. Detect classes of bugs by forcing compiler warnings
-.4.3. Detect classes of bugs by forcing compiler warnings
+.4.3. Use custom directories
-.4.4. Use custom directories
+.4.4. Turn warnings into errors
-.4.5. Turn warnings into errors
+.4.5. Reject packages for which pkglint reports errors
-.4.6. Reject packages for which pkglint reports errors
+.4.6. Reject packages that contain forbidden strings
-.4.7. Reject packages that contain forbidden strings
+.4.7. Reject packages whose self-test fails
-.4.8. Reject packages whose self-test fails
+.4.8. Reject packages that use undefined shell variables
-.4.9. Reject packages that use undefined shell variables
+.4.9. Turn off verbose logging
 .4.10. Turn off verbose logging
 .4.11. Select random sets of options
 .4.12. Select random configurations of BUILD_DEFS
 .5. Creating a multiple CD-ROM packages collection
 .5.1. Example of cdpack
 . Directory layout of the installed files
 .1. File system layout in ${LOCALBASE}
 .2. File system layout in ${VARBASE}
 . Frequently Asked Questions
 .1. Are there any mailing lists for pkg-related discussion?
 .2. Utilities for package management (pkgtools)
 .3. How to use pkgsrc as non-root
 .4. How to resume transfers when fetching distfiles?
 .5. How can I install/use modular X.org from pkgsrc?
 .6. How to fetch files from behind a firewall
 .7. How to fetch files from HTTPS sites
 .8. How do I tell make fetch to do passive FTP?
 .9. How to fetch all distfiles at once
 .10. What does "Don't know how to make /usr/share/tmac/tmac.andoc" mean?
 .11. What does "Could not find bsd.own.mk" mean?
 .12. Using 'sudo' with pkgsrc
 .13. How do I change the location of configuration files?
 .14. Automated security checks
 .15. Why do some packages ignore my CFLAGS?
 .16. A package does not build. What shall I do?
 .17. What does "Makefile appears to contain unresolved cvs/rcs/??? merge
         conflicts" mean?
 Chapter 2. Getting help
 To get help when using 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 D, 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 pkgsrc-users 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 3. Where to get pkgsrc and how to keep it up-to-date
 Table of Contents
 .1. Getting pkgsrc for the first time
 .1.1. As tar archive
 .1.2. Via anonymous CVS
 .2. Keeping pkgsrc up-to-date
 .2.1. Via tar files
 .2.2. Via CVS
 Before you download and extract the files, you need to decide where you want to
 extract them. When using pkgsrc as root user, pkgsrc is usually installed in /
 usr/pkgsrc. You are though free to install the sources and binary packages
 wherever you want in your filesystem, provided that the pathname does not
 contain white-space or other characters that are interpreted specially by the
 shell and some other programs. A safe bet is to use only letters, digits,
 underscores and dashes.
 .1. Getting pkgsrc for the first time
 Before you download any pkgsrc files, you should decide whether you want the
 current branch or the stable branch. The latter is forked on a quarterly basis
 from the current branch and only gets modified for security updates. The names
 of the stable branches are built from the year and the quarter, for example
 Q1.
 The second step is to decide how you want to download pkgsrc. You can get it as
 a tar file or via CVS. Both ways are described here.
 Note that tar archive contains CVS working copy. Thus you can switch to using
 CVS at any later time.
 .1.1. As tar archive
 The primary download location for all pkgsrc files is https://cdn.NetBSD.org/
 pub/pkgsrc/ or ftp://ftp.NetBSD.org/pub/pkgsrc/ (it points to the same
 location). There are a number of subdirectories for different purposes, which
 are described in detail in Appendix C, Directory layout of the pkgsrc FTP
 server.
 The tar archive for the current branch is in the directory current and is
 called pkgsrc.tar.gz. It is autogenerated weekly.
 To save download time we provide bzip2- and xz-compressed archives which are
 published at pkgsrc.tar.bz2 and pkgsrc.tar.xz respectively.
 You can fetch the same files using FTP.
 The tar file for the stable branch 2020Q1 is in the directory pkgsrc-2020Q1 and
 is also called pkgsrc.tar.gz.
 To download the latest pkgsrc stable tarball, run:
 $ ftp ftp://ftp.NetBSD.org/pub/pkgsrc/pkgsrc-2020Q1/pkgsrc.tar.gz
 If you prefer, you can also fetch it using "wget", "curl", or your web browser.
 Then, extract it with:
 $ tar -xzf pkgsrc.tar.gz -C /usr
 This will create the directory pkgsrc/ in /usr/ and all the package source will
 be stored under /usr/pkgsrc/.
 To download pkgsrc-current, run:
 $ ftp ftp://ftp.NetBSD.org/pub/pkgsrc/current/pkgsrc.tar.gz
 .1.2. Via anonymous CVS
 To fetch a specific pkgsrc stable branch, run:
 $ cd /usr && cvs -q -z2 -d anoncvs@anoncvs.NetBSD.org:/cvsroot checkout -r pkgsrc-2020Q1 -P pkgsrc
 This will create the directory pkgsrc/ in your /usr/ directory and all the
 package source will be stored under /usr/pkgsrc/.
 To fetch the pkgsrc current branch, run:
 $ cd /usr && cvs -q -z2 -d anoncvs@anoncvs.NetBSD.org:/cvsroot checkout -P pkgsrc
 Refer to the list of available mirrors to choose a faster CVS mirror, if
 needed.
 If you get error messages from rsh, you need to set CVS_RSH variable. E.g.:
 $ cd /usr && env CVS_RSH=ssh cvs -q -z2 -d anoncvs@anoncvs.NetBSD.org:/cvsroot checkout -P pkgsrc
 Refer to documentation on your command shell how to set CVS_RSH=ssh
 permanently. For Bourne shells, you can set it in your .profile or better
 globally in /etc/profile:
 # set CVS remote shell command
 CVS_RSH=ssh
 export CVS_RSH
 By default, CVS doesn't do things like most people would expect it to do. But
 there is a way to convince CVS, by creating a file called .cvsrc in your home
 directory and saving the following lines to it. This file will save you lots of
 headache and some bug reports, so we strongly recommend it. You can find an
 explanation of this file in the CVS documentation.
 # recommended CVS configuration file from the pkgsrc guide
 cvs -q
 checkout -P
 update -dP
 diff -upN
 rdiff -u
 release -d
 .2. Keeping pkgsrc up-to-date
 The preferred way to keep pkgsrc up-to-date is via CVS (which also works if you
 have first installed it via a tar file). It saves bandwidth and hard disk
 activity, compared to downloading the tar file again.
 .2.1. Via tar files
 Warning
 When updating from a tar file, you first need to completely remove the old
 pkgsrc directory. Otherwise those files that have been removed from pkgsrc in
 the mean time will not be removed on your local disk, resulting in
 inconsistencies. When removing the old files, any changes that you have done to
 the pkgsrc files will be lost after updating. Therefore updating via CVS is
 strongly recommended.
 Note that by default the distfiles and the binary packages are saved in the
 pkgsrc tree, so don't forget to rescue them before updating. You can also
 configure pkgsrc to store distfiles and packages in directories outside the
 pkgsrc tree by setting the DISTDIR and PACKAGES variables. See Chapter 6,
 Configuring pkgsrc for the details.
 To update pkgsrc from a tar file, download the tar file as explained above.
 Then, make sure that you have not made any changes to the files in the pkgsrc
 directory. Remove the pkgsrc directory and extract the new tar file. Done.
 .2.2. Via CVS
 To update pkgsrc via CVS, change to the pkgsrc directory and run cvs:
 $ cd /usr/pkgsrc && cvs update -dP
 If you get error messages from rsh, you need to set CVS_RSH variable as
 described above. E.g.:
 $ cd /usr/pkgsrc && env CVS_RSH=ssh cvs up -dP
 .2.2.1. Switching between different pkgsrc branches
 When updating pkgsrc, the CVS program keeps track of the branch you selected.
 But if you, for whatever reason, want to switch from the stable branch to the
 current one, you can do it by adding the option "-A" after the "update"
 keyword. To switch from the current branch back to the stable branch, add the "
 -rpkgsrc-2020Q1" option.
 .2.2.2. What happens to my changes when updating?
 When you update pkgsrc, the CVS program will only touch those files that are
 registered in the CVS repository. That means that any packages that you created
 on your own will stay unmodified. If you change files that are managed by CVS,
 later updates will try to merge your changes with those that have been done by
 others. See the CVS manual, chapter "update" for details.
 Chapter 4. Using pkgsrc on systems other than NetBSD
 Table of Contents
 .1. Binary distribution
 .2. Bootstrapping pkgsrc
 .1. Binary distribution
 See Section 5.1, "Using binary packages".
 .2. Bootstrapping pkgsrc
 pkgsrc can be bootstrapped for use in two different modes: privileged and
 unprivileged one. In unprivileged mode in contrast to privileged one all
 programs are installed under one particular user and cannot utilise privileged
 operations (packages don't create special users and all special file
 permissions like setuid are ignored).
 Installing the bootstrap kit from source should be as simple as:
 # env CVS_RSH=ssh cvs -d anoncvs@anoncvs.NetBSD.org:/cvsroot checkout -P pkgsrc
 # cd pkgsrc/bootstrap
 # ./bootstrap
 To bootstrap in unprivileged mode pass "--unprivileged" flag to bootstrap
 By default, in privileged mode pkgsrc uses /usr/pkg for prefix where programs
 will be installed in, and /usr/pkg/pkgdb for the package database directory
 where pkgsrc will do its internal bookkeeping, /var is used as varbase, where
 packages install their persistent data. In unprivileged mode pkgsrc uses ~/pkg
 for prefix, ~/pkg/pkgdb for the package database, and ~/pkg/var for varbase.
 You can change default layout using command-line arguments. Run "./bootstrap
 --help" to get details.
 Note
 The bootstrap installs a bmake tool. Use this bmake when building via pkgsrc.
 For examples in this guide, use bmake instead of "make".
 Note
 It is possible to bootstrap multiple instances of pkgsrc using non-intersecting
 directories. Use bmake corresponding to the installation you're working with to
 build and install packages.
 Chapter 5. Using pkgsrc
 Table of Contents
 .1. Using binary packages
 .1.1. Finding binary packages
 .1.2. Installing binary packages
 .1.3. Deinstalling packages
 .1.4. Getting information about installed packages
 .1.5. Checking for security vulnerabilities in installed packages
 .1.6. Finding if newer versions of your installed packages are in pkgsrc
 .1.7. Other administrative functions
 .2. Building packages from source
 .2.1. Requirements
 .2.2. Fetching distfiles
 .2.3. How to build and install
 Basically, there are two ways of using pkgsrc. The first is to only install the
 package tools and to use binary packages that someone else has prepared. This
 is the "pkg" in pkgsrc. The second way is to install the "src" of pkgsrc, too.
 Then you are able to build your own packages, and you can still use binary
 packages from someone else.
 .1. Using binary packages
 On the cdn.NetBSD.org site and mirrors, there are collections of binary
 packages, ready to be installed. These binary packages have been built using
 the default settings for the directories, that is:
   * /usr/pkg for LOCALBASE, where most of the files are installed,
   * /usr/pkg/etc for configuration files,
   * /var for VARBASE, where those files are installed that may change after
     installation.
 If you cannot use these directories for whatever reasons (maybe because you're
 not root), you cannot use these binary packages, but have to build the packages
 yourself, which is explained in Section 4.2, "Bootstrapping pkgsrc".
 .1.1. Finding binary packages
 To install binary packages, you first need to know from where to get them. The
 first place where you should look is on the main pkgsrc FTP server in the
 directory /pub/pkgsrc/packages.
 This directory contains binary packages for multiple platforms. First, select
 your operating system. (Ignore the directories with version numbers attached to
 it, they just exist for legacy reasons.) Then, select your hardware
 architecture, and in the third step, the OS version and the "version" of
 pkgsrc.
 In this directory, you often find a file called bootstrap.tar.gz which contains
 the package management tools. If the file is missing, it is likely that your
 operating system already provides those tools. Download the file and extract it
 in the / directory. It will create the directories /usr/pkg (containing the
 tools for managing binary packages and the database of installed packages).
 .1.2. Installing binary packages
 In the directory from the last section, there is a subdirectory called All/,
 which contains all the binary packages that are available for the platform,
 excluding those that may not be distributed via FTP or CDROM (depending on
 which medium you are using).
 To install packages directly from an FTP or HTTP server, run the following
 commands in a Bourne-compatible shell (be sure to su to root first):
 # PATH="/usr/pkg/sbin:$PATH"
 # PKG_PATH="https://cdn.NetBSD.org/pub/pkgsrc/packages"
 # PKG_PATH="http://cdn.NetBSD.org/pub/pkgsrc/packages"
 # PKG_PATH="$PKG_PATH/OPSYS/ARCH/VERSIONS/All/"
 # export PATH PKG_PATH
 Instead of URLs, you can also use local paths, for example if you are
 installing from a set of CDROMs, DVDs or an NFS-mounted repository. If you want
 to install packages from multiple sources, you can separate them by a semicolon
 in PKG_PATH.
 After these preparations, installing a package is very easy:
 # pkg_add libreoffice
 # pkg_add ap24-php71-*
 Note that any prerequisite packages needed to run the package in question will
 be installed, too, assuming they are present where you install from.
 Adding packages might install vulnerable packages. Thus you should run
 pkg_admin audit regularly, especially after installing new packages, and verify
 that the vulnerabilities are acceptable for your configuration.
 After you've installed packages, be sure to have /usr/pkg/bin and /usr/pkg/sbin
 in your PATH so you can actually start the just installed program.
 .1.3. Deinstalling packages
 To deinstall a package, it does not matter whether it was installed from source
 code or from a binary package. The pkg_delete command does not know it anyway.
 To delete a package, you can just run pkg_delete package-name. The package name
 can be given with or without version number. Wildcards can also be used to
 deinstall a set of packages, for example *emacs*. Be sure to include them in
 quotes, so that the shell does not expand them before pkg_delete sees them.
 The -r option is very powerful: it removes all the packages that require the
 package in question and then removes the package itself. For example:
 # pkg_delete -r jpeg
 will remove jpeg and all the packages that used it; this allows upgrading the
 jpeg package.
 .1.4. Getting information about installed packages
 The pkg_info shows information about installed packages or binary package
 files.
 .1.5. Checking for security vulnerabilities in installed packages
 The pkgsrc Security Team and Packages Groups maintain a list of known security
 vulnerabilities to packages which are (or have been) included in pkgsrc. The
-list is available from the NetBSD FTP site at https://ftp.NetBSD.org/pub/NetBSD
+list is available from the NetBSD FTP site at http://ftp.NetBSD.org/pub/NetBSD/
-/packages/vulns/pkg-vulnerabilities.
+packages/vulns/pkg-vulnerabilities.
 Through pkg_admin fetch-pkg-vulnerabilities, this list can be downloaded
 automatically, and a security audit of all packages installed on a system can
 take place.
 There are two components to auditing. The first step, pkg_admin
 fetch-pkg-vulnerabilities, is for downloading the list of vulnerabilities from
 the NetBSD FTP site. The second step, pkg_admin audit, checks to see if any of
 your installed packages are vulnerable. If a package is vulnerable, you will
 see output similar to the following:
 Package samba-2.0.9 has a local-root-shell vulnerability, see
     https://www.samba.org/samba/whatsnew/macroexploit.html
 You may wish to have the vulnerabilities file downloaded daily so that it
 remains current. This may be done by adding an appropriate entry to the root
 users crontab(5) entry. For example the entry
 # Download vulnerabilities file
 3 * * * /usr/pkg/sbin/pkg_admin fetch-pkg-vulnerabilities >/dev/null 2>&1
 # Audit the installed packages and email results to root
 3 * * * /usr/pkg/sbin/pkg_admin audit |mail -s "Installed package audit result" \
             root >/dev/null 2>&1
 will update the vulnerability list every day at 3AM, followed by an audit at
 :09AM. The result of the audit are then emailed to root. On NetBSD this may be
 accomplished instead by adding the following line to /etc/daily.conf:
 fetch_pkg_vulnerabilities=YES
 to fetch the vulnerability list from the daily security script. The system is
 set to audit the packages by default but can be set explicitly, if desired (not
 required), by adding the following line to /etc/security.conf:
 check_pkg_vulnerabilities=YES
 see daily.conf(5) and security.conf(5) for more details.
 .1.6. Finding if newer versions of your installed packages are in pkgsrc
 Install pkgtools/lintpkgsrc and run lintpkgsrc with the "-i" argument to check
 if your packages are up-to-date, e.g.
 % lintpkgsrc -i
 ...
 Version mismatch: 'tcsh' 6.09.00 vs 6.10.00
 You can then use make update to update the package on your system and rebuild
 any dependencies.
 .1.7. Other administrative functions
 The pkg_admin executes various administrative functions on the package system.
 .2. Building packages from source
 After obtaining pkgsrc, the pkgsrc directory now contains a set of packages,
 organized into categories. You can browse the online index of packages, or run
 make readme from the pkgsrc directory to build local README.html files for all
 packages, viewable with any web browser such as www/lynx or www/firefox.
 The default prefix for installed packages is /usr/pkg. If you wish to change
 this, you should do so by setting LOCALBASE in mk.conf. You should not try to
 use multiple different LOCALBASE definitions on the same system (inside a
 chroot is an exception).
 The rest of this chapter assumes that the package is already in pkgsrc. If it
 is not, see Part II, "The pkgsrc developer's guide" for instructions how to
 create your own packages.
 .2.1. Requirements
 To build packages from source, you need a working C compiler. On NetBSD, you
 need to install the "comp" and the "text" distribution sets. If you want to
 build X11-related packages, the "xbase" and "xcomp" distribution sets are
 required, too.
 .2.2. Fetching distfiles
 The first step for building a package is downloading the distfiles (i.e. the
 unmodified source). If they have not yet been downloaded, pkgsrc will fetch
 them automatically.
 If you have all files that you need in the distfiles directory, you don't need
 to connect. If the distfiles are on CD-ROM, you can mount the CD-ROM on /cdrom
 and add:
 DISTDIR=/cdrom/pkgsrc/distfiles
 to your mk.conf.
 By default a list of distribution sites will be randomly intermixed to prevent
 huge load on servers which holding popular packages (for example,
 SourceForge.net mirrors). Thus, every time when you need to fetch yet another
 distfile all the mirrors will be tried in new (random) order. You can turn this
 feature off by setting MASTER_SORT_RANDOM=NO (for PKG_DEVELOPERs it's already
 disabled).
 You can overwrite some of the major distribution sites to fit to sites that are
 close to your own. By setting one or two variables you can modify the order in
 which the master sites are accessed. MASTER_SORT contains a whitespace
 delimited list of domain suffixes. MASTER_SORT_REGEX is even more flexible, it
 contains a whitespace delimited list of regular expressions. It has higher
 priority than MASTER_SORT. Have a look at pkgsrc/mk/defaults/mk.conf to find
 some examples. This may save some of your bandwidth and time.
 You can change these settings either in your shell's environment, or, if you
 want to keep the settings, by editing the mk.conf file, and adding the
 definitions there.
 If a package depends on many other packages (such as meta-pkgs/kde4), the build
 process may alternate between periods of downloading source, and compiling. To
 ensure you have all the source downloaded initially you can run the command:
 % make fetch-list | sh
 which will output and run a set of shell commands to fetch the necessary files
 into the distfiles directory. You can also choose to download the files
 manually.
 .2.3. How to build and install
 Once the software has downloaded, any patches will be applied, then it will be
 compiled for you. This may take some time depending on your computer, and how
 many other packages the software depends on and their compile time.
 Note
 If using bootstrap or pkgsrc on a non-NetBSD system, use the pkgsrc bmake
 command instead of "make" in the examples in this guide.
 For example, type
 % cd misc/figlet
 % make
 at the shell prompt to build the various components of the package.
 The next stage is to actually install the newly compiled program onto your
 system. Do this by entering:
 % make install
 while you are still in the directory for whatever package you are installing.
 Installing the package on your system may require you to be root. However,
 pkgsrc has a just-in-time-su feature, which allows you to only become root for
 the actual installation step.
 That's it, the software should now be installed and setup for use. You can now
 enter:
 % make clean
 to remove the compiled files in the work directory, as you shouldn't need them
 any more. If other packages were also added to your system (dependencies) to
 allow your program to compile, you can tidy these up also with the command:
 % make clean-depends
 Taking the figlet utility as an example, we can install it on our system by
 building as shown in Appendix B, Build logs.
 The program is installed under the default root of the packages tree - /usr/
 pkg. Should this not conform to your tastes, set the LOCALBASE variable in your
 environment, and it will use that value as the root of your packages tree. So,
 to use /usr/local, set LOCALBASE=/usr/local in your environment. Please note
 that you should use a directory which is dedicated to packages and not shared
 with other programs (i.e., do not try and use LOCALBASE=/usr). Also, you should
 not try to add any of your own files or directories (such as src/, obj/, or
 pkgsrc/) below the LOCALBASE tree. This is to prevent possible conflicts
 between programs and other files installed by the package system and whatever
 else may have been installed there.
 Some packages look in mk.conf to alter some configuration options at build
 time. Have a look at pkgsrc/mk/defaults/mk.conf to get an overview of what will
 be set there by default. Environment variables such as LOCALBASE can be set in
 mk.conf to save having to remember to set them each time you want to use
 pkgsrc.
 Occasionally, people want to "look under the covers" to see what is going on
 when a package is building or being installed. This may be for debugging
 purposes, or out of simple curiosity. A number of utility values have been
 added to help with this.
 . If you invoke the make(1) command with PKG_DEBUG_LEVEL=2, then a huge
     amount of information will be displayed. For example,
     make patch PKG_DEBUG_LEVEL=2
     will show all the commands that are invoked, up to and including the "patch
     " stage.
 . If you want to know the value of a certain make(1) definition, then the
     VARNAME definition should be used, in conjunction with the show-var target.
     e.g. to show the expansion of the make(1) variable LOCALBASE:
     % make show-var VARNAME=LOCALBASE
     /usr/pkg
+    %
 If you want to install a binary package that you've either created yourself
 (see next section), that you put into pkgsrc/packages manually or that is
 located on a remote FTP server, you can use the "bin-install" target. This
 target will install a binary package - if available - via pkg_add(1), else do a
 make package. The list of remote FTP sites searched is kept in the variable
 BINPKG_SITES, which defaults to ftp.NetBSD.org. Any flags that should be added
 to pkg_add(1) can be put into BIN_INSTALL_FLAGS. See pkgsrc/mk/defaults/mk.conf
 for more details.
 A final word of warning: If you set up a system that has a non-standard setting
 for LOCALBASE, be sure to set that before any packages are installed, as you
 cannot use several directories for the same purpose. Doing so will result in
 pkgsrc not being able to properly detect your installed packages, and fail
 miserably. Note also that precompiled binary packages are usually built with
 the default LOCALBASE of /usr/pkg, and that you should not install any if you
 use a non-standard LOCALBASE.
 Chapter 6. Configuring pkgsrc
 Table of Contents
 .1. General configuration
 .2. Variables affecting the build process
 .3. Variables affecting the installation process
 .4. Selecting and configuring the compiler
 .4.1. Selecting the compiler
 .4.2. Additional flags to the compiler (CFLAGS)
 .4.3. Additional flags to the linker (LDFLAGS)
 .5. Developer/advanced settings
 .6. Selecting Build Options
 The whole pkgsrc system is configured in a single file, usually called mk.conf.
 In which directory pkgsrc looks for that file depends on the installation. On
 NetBSD, when you use make(1) from the base system, it is in the directory /etc
 /. In all other cases the default location is ${PREFIX}/etc/, depending on
 where you told the bootstrap program to install the binary packages.
 The format of the configuration file is that of the usual BSD-style Makefiles.
 The whole pkgsrc configuration is done by setting variables in this file. Note
 that you can define all kinds of variables, and no special error checking (for
 example for spelling mistakes) takes place.
 .1. General configuration
 The following variables apply to all pkgsrc packages. A complete list of the
 variables that can be configured by the user is available in mk/defaults/
 mk.conf, together with some comments that describe each variable's intent.
   * LOCALBASE: Where packages will be installed. The default is /usr/pkg. Do
     not mix binary packages with different LOCALBASEs!
   * CROSSBASE: Where "cross" category packages will be installed. The default
     is ${LOCALBASE}/cross.
   * X11BASE: Where X11 is installed on the system. The default is /usr/X11R7.
   * DISTDIR: Where to store the downloaded copies of the original source
     distributions used for building pkgsrc packages. The default is $
     {PKGSRCDIR}/distfiles.
   * PKG_DBDIR: Where the database about installed packages is stored. The
     default is /usr/pkg/pkgdb.
   * MASTER_SITE_OVERRIDE: If set, override the packages' MASTER_SITES with this
     value.
   * MASTER_SITE_BACKUP: Backup location(s) for distribution files and patch
     files if not found locally or in ${MASTER_SITES} or ${PATCH_SITES}
     respectively. The defaults is ftp://ftp.NetBSD.org/pub/pkgsrc/distfiles/$
     {DIST_SUBDIR}/.
   * BINPKG_SITES: List of sites carrying binary pkgs. rel and arch are replaced
     with OS release ("2.0", etc.) and architecture ("mipsel", etc.).
   * ACCEPTABLE_LICENSES: List of acceptable licenses. License names are
     case-sensitive. Whenever you try to build a package whose license is not in
     this list, you will get an error message. If the license condition is
     simple enough, the error message will include specific instructions on how
     to change this variable.
 .2. Variables affecting the build process
   * PACKAGES: The top level directory for the binary packages. The default is $
     {PKGSRCDIR}/packages.
   * WRKOBJDIR: The top level directory where, if defined, the separate working
     directories will get created, and symbolically linked to from ${WRKDIR}
     (see below). This is useful for building packages on several architectures,
     then ${PKGSRCDIR} can be NFS-mounted while ${WRKOBJDIR} is local to every
     architecture. (It should be noted that PKGSRCDIR should not be set by the
     user ? it is an internal definition which refers to the root of the pkgsrc
     tree. It is possible to have many pkgsrc tree instances.)
   * LOCALPATCHES: Directory for local patches that aren't part of pkgsrc. See
     Section 13.3, "patches/*" for more information.
   * PKGMAKECONF: Location of the mk.conf file used by a package's BSD-style
     Makefile. If this is not set, MAKECONF is set to /dev/null to avoid picking
     up settings used by builds in /usr/src.
 .3. Variables affecting the installation process
   * PKGSRC_KEEP_BIN_PKGSRC: By default, binary packages of built packages are
     preserved in ${PACKAGES}/All. Setting this variable to "no" prevents this.
 Packages have to support installation into a subdirectory of WRKDIR. This
 allows a package to be built, before the actual filesystem is touched. DESTDIR
 support exists in two variations:
   * Basic DESTDIR support means that the package installation and packaging is
     still run as root.
   * Full DESTDIR support can run the complete build, installation and packaging
     as normal user. Root privileges are only needed to add packages.
 With basic DESTDIR support, make clean needs to be run as root.
 Considering the foo/bar package, DESTDIR full support can be tested using the
 following commands
 $ id
 uid=1000(myusername) gid=100(users) groups=100(users),0(wheel)
 $ mkdir $HOME/packages
 $ cd $PKGSRCDIR/foo/bar
 Verify DESTDIR full support, no root privileges should be needed
 $ make stage-install
 Create a package without root privileges
 $ make PACKAGES=$HOME/packages package
 For the following command, you must be able to gain root privileges using su(1)
 $ make PACKAGES=$HOME/packages install
 Then, as a simple user
 $ make clean
 .4. Selecting and configuring the compiler
 .4.1. Selecting the compiler
 By default, pkgsrc will use GCC to build packages. This may be overridden by
 setting the following variables in /etc/mk.conf:
 PKGSRC_COMPILER:
     This is a list of values specifying the chain of compilers to invoke when
     building packages. Valid values are:
       + ccc: Compaq C Compilers (Tru64)
       + ccache: compiler cache (chainable)
       + clang: Clang C and Objective-C compiler
       + distcc: distributed C/C++ (chainable)
       + f2c: Fortran 77 to C compiler (chainable)
       + icc: Intel C++ Compiler (Linux)
       + ido: SGI IRIS Development Option cc (IRIX 5)
       + gcc: GNU C/C++ Compiler
       + hp: HP-UX C/aC++ compilers
       + mipspro: Silicon Graphics, Inc. MIPSpro (n32/n64)
       + mipspro-ucode: Silicon Graphics, Inc. MIPSpro (o32)
       + sunpro: Sun Microsystems, Inc. WorkShip/Forte/Sun ONE Studio
       + xlc: IBM's XL C/C++ compiler suite
     The default is "gcc". You can use ccache and/or distcc with an appropriate
     PKGSRC_COMPILER setting, e.g. "ccache gcc". This variable should always be
     terminated with a value for a real compiler. Note that only one real
     compiler should be listed (e.g. "sunpro gcc" is not allowed).
 GCC_REQD:
     This specifies the minimum version of GCC to use when building packages. If
     the system GCC doesn't satisfy this requirement, then pkgsrc will build and
     install one of the GCC packages to use instead.
 PYTHON_VERSION_DEFAULT:
     Specifies which version of python to use when several options are
     available.
 PKGSRC_FORTRAN:
     Specifies the Fortran compiler to use. The default is gfortran.
 GFORTRAN_VERSION:
     If PKGSRC_FORTRAN= gfortran is used, this option specifies which version to
     use.
 .4.2. Additional flags to the compiler (CFLAGS)
 If you wish to set the CFLAGS variable, please make sure to use the += operator
 instead of the = operator:
 CFLAGS+=        -your -flags
 Using CFLAGS= (i.e. without the "+") may lead to problems with packages that
 need to add their own flags. You may want to take a look at the devel/cpuflags
 package if you're interested in optimization specifically for the current CPU.
 .4.3. Additional flags to the linker (LDFLAGS)
 If you want to pass flags to the linker, both in the configure step and the
 build step, you can do this in two ways. Either set LDFLAGS or LIBS. The
 difference between the two is that LIBS will be appended to the command line,
 while LDFLAGS come earlier. LDFLAGS is pre-loaded with rpath settings for ELF
 machines depending on the setting of USE_IMAKE or the inclusion of mk/
 x11.buildlink3.mk. As with CFLAGS, if you do not wish to override these
 settings, use the += operator:
 LDFLAGS+=        -your -linkerflags
 .5. Developer/advanced settings
   * PKG_DEVELOPER: Run some sanity checks that package developers want:
       + make sure patches apply with zero fuzz
       + run check-shlibs to see that all binaries will find their shared libs.
   * PKG_DEBUG_LEVEL: The level of debugging output which is displayed whilst
     making and installing the package. The default value for this is 0, which
     will not display the commands as they are executed (normal, default, quiet
     operation); the value 1 will display all shell commands before their
     invocation, and the value 2 will display both the shell commands before
     their invocation, as well as their actual execution progress with set -x.
 .6. Selecting Build Options
 Some packages have build time options, usually to select between different
 dependencies, enable optional support for big dependencies or enable
 experimental features.
 To see which options, if any, a package supports, and which options are
 mutually exclusive, run make show-options, for example:
     The following options are supported by this package:
         ssl      Enable SSL support.
     Exactly one of the following gecko options is required:
         firefox  Use firefox as gecko rendering engine.
         mozilla  Use mozilla as gecko rendering engine.
     At most one of the following database options may be selected:
         mysql    Enable support for MySQL database.
         pgsql    Enable support for PostgreSQL database.
     These options are enabled by default: firefox
     These options are currently enabled: mozilla ssl
 The following variables can be defined in mk.conf to select which options to
 enable for a package: PKG_DEFAULT_OPTIONS, which can be used to select or
 disable options for all packages that support them, and PKG_OPTIONS.pkgbase,
 which can be used to select or disable options specifically for package pkgbase
 . Options listed in these variables are selected, options preceded by "-" are
 disabled. A few examples:
 $ grep "PKG.*OPTION" mk.conf
 PKG_DEFAULT_OPTIONS=    -arts -dvdread -esound
 PKG_OPTIONS.kdebase=    debug -sasl
 PKG_OPTIONS.apache=     suexec
 It is important to note that options that were specifically suggested by the
 package maintainer must be explicitly removed if you do not wish to include the
 option. If you are unsure you can view the current state with make show-options
+.
 The following settings are consulted in the order given, and the last setting
 that selects or disables an option is used:
 . the default options as suggested by the package maintainer
 . the options implied by the settings of legacy variables (see below)
 . PKG_DEFAULT_OPTIONS
 . PKG_OPTIONS.pkgbase
 For groups of mutually exclusive options, the last option selected is used, all
 others are automatically disabled. If an option of the group is explicitly
 disabled, the previously selected option, if any, is used. It is an error if no
 option from a required group of options is selected, and building the package
 will fail.
 Before the options framework was introduced, build options were selected by
 setting a variable (often named USE_FOO) in mk.conf for each option. To ease
 transition to the options framework for the user, these legacy variables are
 converted to the appropriate options setting (PKG_OPTIONS.pkgbase)
 automatically. A warning is issued to prompt the user to update mk.conf to use
 the options framework directly. Support for the legacy variables will be
 removed eventually.
 Chapter 7. Creating binary packages
 Table of Contents
 .1. Building a single binary package
 .2. Settings for creation of binary packages
 .1. Building a single binary package
 Once you have built and installed a package, you can create a binary package
 which can be installed on another system with pkg_add(1). This saves having to
 build the same package on a group of hosts and wasting CPU time. It also
 provides a simple means for others to install your package, should you
 distribute it.
 To create a binary package, change into the appropriate directory in pkgsrc,
 and run make package:
 $ cd misc/figlet
 $ make package
 This will build and install your package (if not already done), and then build
 a binary package from what was installed. You can then use the pkg_* tools to
 manipulate it. Binary packages are created by default in /usr/pkgsrc/packages,
 in the form of a gzipped tar file. See Section B.2, "Packaging figlet" for a
 continuation of the above misc/figlet example.
 See Chapter 23, Submitting and Committing for information on how to submit such
 a binary package.
 .2. Settings for creation of binary packages
 See Section 19.17, "Other helpful targets".
 Chapter 8. Creating binary packages for everything in pkgsrc (bulk builds)
 Table of Contents
 .1. Preparations
 .2. Running a pbulk-style bulk build
 .2.1. Configuration
 .3. Requirements of a full bulk build
 .4. Bulk build variants
-.4.1. Strict SUBST blocks
+.4.1. Detect unknown configure options
-.4.2. Detect unknown configure options
+.4.2. Detect classes of bugs by forcing compiler warnings
-.4.3. Detect classes of bugs by forcing compiler warnings
+.4.3. Use custom directories
-.4.4. Use custom directories
+.4.4. Turn warnings into errors
-.4.5. Turn warnings into errors
+.4.5. Reject packages for which pkglint reports errors
-.4.6. Reject packages for which pkglint reports errors
+.4.6. Reject packages that contain forbidden strings
-.4.7. Reject packages that contain forbidden strings
+.4.7. Reject packages whose self-test fails
-.4.8. Reject packages whose self-test fails
+.4.8. Reject packages that use undefined shell variables
-.4.9. Reject packages that use undefined shell variables
+.4.9. Turn off verbose logging
 .4.10. Turn off verbose logging
 .4.11. Select random sets of options
 .4.12. Select random configurations of BUILD_DEFS
 .5. Creating a multiple CD-ROM packages collection
 .5.1. Example of cdpack
 For a number of reasons, you may want to build binary packages for a large
 selected set of packages in pkgsrc, or even for all pkgsrc packages. For
 instance, when you have multiple machines that should run the same software, it
 is wasted time if they all build their packages themselves from source. Or you
 may want to build a list of packages you want and check them before deploying
 onto production systems. There is a way of getting a set of binary packages:
 the bulk build system, or pbulk ("p" stands for "parallel"). This chapter
 describes how to set it up.
 .1. Preparations
 First of all, you have to decide whether you build all packages or a limited
 set of them. Full bulk builds usually consume a lot more resources, both space
 and time, than builds for some practical sets of packages. A number of
 particularly heavy packages exist that are not actually interesting to a wide
 audience. (The approximate resource consumption for a full bulk build is given
 in section Section 8.3, "Requirements of a full bulk build".) For limited bulk
 builds you need to make a list of packages you want to build. Note that all
 their dependencies will be built, so you don't need to track them manually.
 During bulk builds various packages are installed and deinstalled in /usr/pkg
 (or whatever LOCALBASE is), so make sure that you don't need any package during
 the builds. Essentially, you should provide a fresh system, either a chroot
 environment or something even more restrictive, depending on what the operating
 system provides, or dedicate the whole physical machine. As a useful side
 effect this makes sure that bulk builds cannot break anything in your system.
 There have been numerous cases where certain packages tried to install files
 outside the LOCALBASE or wanted to edit some files in /etc.
 .2. Running a pbulk-style bulk build
 Running a pbulk-style bulk build works roughly as follows:
   * First, build the pbulk infrastructure in a fresh pkgsrc location.
   * Then, build each of the packages from a clean installation directory using
     the infrastructure.
 .2.1. Configuration
 To simplify configuration, we provide the helper script mk/pbulk/pbulk.sh.
 In order to use it, prepare a clear system (real one, chroot environment, jail,
 zone, virtual machine). Configure network access to fetch distribution files.
 Create a user with name "pbulk".
 Fetch and extract pkgsrc. Use a command like one of these:
 # (cd /usr && ftp -o - https://cdn.NetBSD.org/pub/pkgsrc/current/pkgsrc.tar.gz | tar -zxf-)
 # (cd /usr && fetch -o - https://cdn.NetBSD.org/pub/pkgsrc/current/pkgsrc.tar.gz | tar -zxf-)
 # (cd /usr && cvs -Q -z3 -d anoncvs@anoncvs.NetBSD.org:/cvsroot get -P pkgsrc)
 Or any other way that fits (e.g., curl, wget).
 Deploy and configure pbulk tools, e.g.:
 # sh pbulk.sh -n # use native make, no bootstrap kit needed (for use on NetBSD)
 # sh pbulk.sh -n -c mk.conf.frag # native, apply settings from given mk.conf fragment
 # sh pbulk.sh -nlc mk.conf.frag # native, apply settings, configure for limited build
 Note
 mk.conf.frag is a fragment of mk.conf that contains settings you want to apply
 to packages you build. For instance,
 PKG_DEVELOPER=          yes     # perform more checks
 X11_TYPE=               modular # use pkgsrc X11
 SKIP_LICENSE_CHECK=     yes     # accept all licences (useful
                                 # when building all packages)
 If configured for limited list, replace the list in /usr/pbulk/etc/pbulk.list
 with your list of packages, one per line without empty lines or comments. E.g.:
 www/firefox
 mail/thunderbird
 misc/libreoffice4
 At this point you can also review configuration in /usr/pbulk/etc and make
 final amendments, if wanted.
 Start it:
 # /usr/pbulk/bin/bulkbuild
 After it finishes, you'll have /mnt filled with distribution files, binary
 packages, and reports, plain text summary in /mnt/bulklog/meta/report.txt
 Note
 The pbulk.sh script does not cover all possible use cases. While being ready to
 run, it serves as a good starting point to understand and build more complex
 setups. The script is kept small enough for better understanding.
 Note
 The pbulk.sh script supports running unprivileged bulk build and helps
 configuring distributed bulk builds.
 .3. Requirements of a full bulk build
 A complete bulk build requires lots of disk space. Some of the disk space can
 be read-only, some other must be writable. Some can be on remote filesystems
 (such as NFS) and some should be local. Some can be temporary filesystems,
 others must survive a sudden reboot.
   * 40 GB for the distfiles (read-write, remote, temporary)
   * 30 GB for the binary packages (read-write, remote, permanent)
   * 1 GB for the pkgsrc tree (read-only, remote, permanent)
   * 5 GB for LOCALBASE (read-write, local, temporary)
   * 10 GB for the log files (read-write, remote, permanent)
   * 5 GB for temporary files (read-write, local, temporary)
 .4. Bulk build variants
 To ensure that pkgsrc packages work in different configurations, it makes sense
 to run non-default bulk builds from time to time. This section lists some ideas
 for bulk builds that intentionally let packages fail if they don't follow the
 pkgsrc style.
-.4.1. Strict SUBST blocks
+.4.1. Detect unknown configure options
 Up to May 2020, the SUBST blocks ignored files that didn't exist, as well as
 substitutions that didn't have any effect. There were quite a few SUBST blocks
 that were redundant, and these have been removed already.
 The next step would be to not only check that each filename pattern has an
 effect but also that each substitution in SUBST_SED or SUBST_VARS applies to at
 least one file.
 To do this, mk/subst.mk would have to be adjusted, in a similar way as the
 check for no-op SUBST_FILES. There are several regression tests in regress/
 infra-unittests that help to get all edge cases correct.
 When a package fails this additional check, there are various possible causes
 why the SUBST_SED became a no-op.
 . The pattern used to be found in a former version of the package, but is not
     needed anymore. In that case, just remove it.
 . The pattern contains a typo. In that case, fix the typo and bump
     PKGREVISION, since the fixed typo will probably modify the resulting binary
     package.
 . There is a patch that is applied before the SUBST block, and the patch
     accidentally contains the change that was intended for the SUBST block. In
     that case, remove the respective hunk from the patch.
 .4.2. Detect unknown configure options
 Add the following line to mk.conf.
 GNU_CONFIGURE_STRICT=   yes
 When a package fails this additional check, the most common cause is that the
 configure option was valid for an older version of the package but does not
 apply anymore. In that case, just remove it.
-.4.3. Detect classes of bugs by forcing compiler warnings
+.4.2. Detect classes of bugs by forcing compiler warnings
 The job of a compiler is not restricted to producing executable code, most
-compilers also detects typical mistakes.
+compilers also detect typical programming mistakes. The pkgsrc compiler
 wrappers make it easy to force compiler options when the package is built. This
 can be used to find typical bugs across all packages that are in pkgsrc. By
 reporting these bugs upstream, the packages will be more reliable with the next
 updates.
-Add the following line to mk.conf.
+Add some of the following lines to mk.conf:
 CFLAGS+=        -Werror=char-subscripts
 CFLAGS+=        -Werror=implicit-function-declaration
-When a package fails this additional check, first document the circumstances in
+When a package fails to build using these stricter compiler options, document
-which the compiler produced the error message. This includes:
+the circumstances in which the compiler produced the error message. This
 includes:
   * The platform (MACHINE_PLATFORM)
   * The source file
   * An excerpt of the code. GCC and Clang already do this as part of the
     diagnostic.
-  * The error message from the compiler.
+  * The exact error message from the compiler.
-If a package produces these error messages, but the package is fine, document
+If a package produces these error messages, but the package is fine, record
-this in the package Makefile, like this:
+this in your local mk.conf, like this, to skip this check in the next builds:
 .if ${PKGPATH} == category/package
 # Version ${VERSION} failed on ${MACHINE_PLATFORM}:
 # error message
 # code
-# reason why the code does not need to be fixed
+# Reason why the code does not need to be fixed.
 BUILDLINK_TRANSFORM+=   rm:-Werror=char-subscripts
 .endif
 If the error messages from the compiler are valid and the code needs to be
-fixed, prepare a patch for a single source file, or if it's a one-liner fix,
+fixed, prepare a local patch (see LOCALPATCHES) and report the bug to the
-add a SUBST block to the package Makefile. In any case, report it to the
+upstream authors of the package, providing them with the information you
-upstream authors of the package.
+collected above.
-.4.4. Use custom directories
+Patches that are not essential for the package to work should only be reported
 upstream but not committed to pkgsrc, to make future updates easier.
 .4.3. Use custom directories
 Some directories like PREFIX, VARBASE, PKG_SYSCONFDIR, PKGMANDIR, PKG_INFODIR
 can be configured in pkgsrc. Set these to arbitrary paths during bootstrap or
 afterwards in mk.conf.
 PREFIX=         /a-random-uuid
 PKG_SYSCONFDIR= /a-random-uuid
 VARBASE=        /a-random-uuid
 PKGMANDIR=      a-random-uuid
 PKG_INFODIR=    a-random-uuid
-.4.5. Turn warnings into errors
+.4.4. Turn warnings into errors
 When building a package, warnings are typically ignored since they just flow by
 and do not cause the build to fail immediately. To find these warnings,
 redefine them to errors in mk.conf.
 DELAYED_WARNING_MSG=    ${DELAYED_ERROR_MSG} "(was warning)"
 WARNING_MSG=            ${FAIL_MSG} "(was warning)"
 (There are many more classes of warnings in pkgsrc, and most of them can be
 redefined with a simple definition like above.
-If a package suggest to add USE_TOOLS+=perl to the package Makefile, research
+If a package suggests to add USE_TOOLS+=perl to the package Makefile, research
 whether the package actually needs Perl. If it does, add USE_TOOLS+=perl to the
 package Makefile, and if it doesn't, add TOOLS_BROKEN+=perl.
-.4.6. Reject packages for which pkglint reports errors
+.4.5. Reject packages for which pkglint reports errors
 Using pkglint as part of the regular build process is mostly a waste of time.
 If you want to fix some of the warnings, just run pkglint recursively on the
 whole pkgsrc tree. This will take a few minutes (up to 10), which is much
 faster than a complete bulk build.
-.4.7. Reject packages that contain forbidden strings
+.4.6. Reject packages that contain forbidden strings
 To ensure that the binary packages don't contain references to the build
 directory, there is already CHECK_WRKREF. If that variable includes the item
 extra, it is possible to define additional patterns that must not appear in any
 installed file. This is specified in mk.conf.
 CHECK_WRKREF=                   extra
 CHECK_WRKREF_EXTRA_DIRS+=       /usr/local
 CHECK_WRKREF_EXTRA_DIRS+=       /usr/pkg
 CHECK_WRKREF_EXTRA_DIRS+=       @[A-Z][A-Z]*@
 The above patterns will probably generate many false positives, therefore the
 results need to be taken with a grain of salt.
-.4.8. Reject packages whose self-test fails
+.4.7. Reject packages whose self-test fails
 To run the test suites that come with each package, add this line to mk.conf.
 PKGSRC_RUN_TEST=        yes
 Be prepared that even the most basic packages fail this test. When doing a bulk
 build with this, it will often abort in the early phase where the packages are
 scanned for their dependencies since there are cyclic dependencies. There is
 still a lot to do in this area.
-.4.9. Reject packages that use undefined shell variables
+.4.8. Reject packages that use undefined shell variables
 To catch typos in the shell snippets from the Makefile fragments, add the -u
 flag to most of the commands by adding this line to mk.conf.
 RUN=    @set -eu;
 See mk/misc/common.mk for the existing definition.
-.4.10. Turn off verbose logging
+.4.9. Turn off verbose logging
 The build logs of a package are often quite long. This allows error messages or
 other interesting details to hide between the noise. To make the actual error
 message stand out more, add these lines to mk.conf.
 GNU_CONFIGURE_QUIET=    yes
 MAKE_FLAGS+=            -s
 The -s option works for both GNU Make and BSD Make. On exotic platforms with
 their own make, it may be a little different.
 .4.11. Select random sets of options
 Most bulk builds run with the default package options. This means that other
 combinations of options are not regularly tested. To do this, run a bulk build
 with these configurations.
   * no options enabled
   * all options enabled
   * 2n + 0
   * 2n + 1
   * 4n + 0..1
   * 4n + 2..3
   * 8n + 0..3
   * 8n + 4..7
   * 2048n + 0..1023
   * 2048n + 1024..2047
 Open questions are:
   * how to collect all options from the entire pkgsrc
   * how to handle mutually exclusive options
   * the sets of mutually exclusive options are defined per-package
   * the sets of nonempty sets are defined per-package
 .4.12. Select random configurations of BUILD_DEFS
 Just like the PKG_OPTIONS, the BUILD_DEFS also allow different variants of
 pkgsrc to be created. The same ideas as in Section 8.4.11, "Select random sets
 of options" apply.
 .5. Creating a multiple CD-ROM packages collection
 After your pkgsrc bulk-build has completed, you may wish to create a CD-ROM set
 of the resulting binary packages to assist in installing packages on other
 machines. The pkgtools/cdpack package provides a simple tool for creating the
 ISO 9660 images. cdpack arranges the packages on the CD-ROMs in a way that
 keeps all the dependencies for a given package on the same CD as that package.
 .5.1. Example of cdpack
 Complete documentation for cdpack is found in the cdpack(1) man page. The
 following short example assumes that the binary packages are left in /usr/
 pkgsrc/packages/All and that sufficient disk space exists in /u2 to hold the
 ISO 9660 images.
 # mkdir /u2/images
 # pkg_add /usr/pkgsrc/packages/All/cdpack
 # cdpack /usr/pkgsrc/packages/All /u2/images
 If you wish to include a common set of files (COPYRIGHT, README, etc.) on each
 CD in the collection, then you need to create a directory which contains these
 files, e.g.:
 # mkdir /tmp/common
 # echo "This is a README" > /tmp/common/README
 # echo "Another file" > /tmp/common/COPYING
 # mkdir /tmp/common/bin
 # echo "#!/bin/sh" > /tmp/common/bin/myscript
 # echo "echo Hello world" >> /tmp/common/bin/myscript
 # chmod 755 /tmp/common/bin/myscript
 Now create the images:
 # cdpack -x /tmp/common /usr/pkgsrc/packages/All /u2/images
 Each image will contain README, COPYING, and bin/myscript in their root
 directories.
 Chapter 9. Directory layout of the installed files
 Table of Contents
 .1. File system layout in ${LOCALBASE}
 .2. File system layout in ${VARBASE}
 The files that are installed by pkgsrc are organized in a way that is similar
 to what you find in the /usr directory of the base system. But some details are
 different. This is because pkgsrc initially came from FreeBSD and had adopted
 its file system hierarchy. Later it was largely influenced by NetBSD. But no
 matter which operating system you are using pkgsrc with, you can expect the
 same layout for pkgsrc.
 There are mainly four root directories for pkgsrc, which are all configurable
 in the bootstrap/bootstrap script. When pkgsrc has been installed as root, the
 default locations are:
 LOCALBASE=              /usr/pkg
 PKG_SYSCONFBASE=        /usr/pkg/etc
 VARBASE=                /var
 PKG_DBDIR=              /usr/pkg/pkgdb
 In unprivileged mode (when pkgsrc has been installed as any other user), the
 default locations are:
 LOCALBASE=              ${HOME}/pkg
 PKG_SYSCONFBASE=        ${HOME}/pkg/etc
 VARBASE=                ${HOME}/pkg/var
 PKG_DBDIR=              ${HOME}/pkg/pkgdb
 What these four directories are for, and what they look like is explained
 below.
   * LOCALBASE corresponds to the /usr directory in the base system. It is the "
     main" directory where the files are installed and contains the well-known
     subdirectories like bin, include, lib, share and sbin.
   * VARBASE corresponds to /var in the base system. Some programs (especially
     games, network daemons) need write access to it during normal operation.
   * PKG_SYSCONFDIR corresponds to /etc in the base system. It contains
     configuration files of the packages, as well as pkgsrc's mk.conf itself.
 .1. File system layout in ${LOCALBASE}
 The following directories exist in a typical pkgsrc installation in $
 {LOCALBASE}.
 bin
     Contains executable programs that are intended to be directly used by the
     end user.
 emul
     Contains files for the emulation layers of various other operating systems,
     especially for NetBSD.
 etc (the usual location of ${PKG_SYSCONFDIR})
     Contains the configuration files.
 include
     Contains headers for the C and C++ programming languages.
 info
     Contains GNU info files of various packages.
 lib
     Contains shared and static libraries.
 libdata
     Contains data files that don't change after installation. Other data files
     belong into ${VARBASE}.
 libexec
     Contains programs that are not intended to be used by end users, such as
     helper programs or network daemons.
 libexec/cgi-bin
     Contains programs that are intended to be executed as CGI scripts by a web
     server.
 man (the usual value of ${PKGMANDIR})
     Contains brief documentation in form of manual pages.
 sbin
     Contains programs that are intended to be used only by the super-user.
 share
     Contains platform-independent data files that don't change after
     installation.
 share/doc
     Contains documentation files provided by the packages.
 share/examples
     Contains example files provided by the packages. Among others, the original
     configuration files are saved here and copied to ${PKG_SYSCONFDIR} during
     installation.
 share/examples/rc.d
     Contains the original files for rc.d scripts.
 var (the usual location of ${VARBASE})
     Contains files that may be modified after installation.
 .2. File system layout in ${VARBASE}
 db/pkg (the usual location of ${PKG_DBDIR})
     Contains information about the currently installed packages.
 games
     Contains highscore files.
 log
     Contains log files.
 run
     Contains informational files about daemons that are currently running.
 Chapter 10. Frequently Asked Questions
 Table of Contents
 .1. Are there any mailing lists for pkg-related discussion?
 .2. Utilities for package management (pkgtools)
 .3. How to use pkgsrc as non-root
 .4. How to resume transfers when fetching distfiles?
 .5. How can I install/use modular X.org from pkgsrc?
 .6. How to fetch files from behind a firewall
 .7. How to fetch files from HTTPS sites
 .8. How do I tell make fetch to do passive FTP?
 .9. How to fetch all distfiles at once
 .10. What does "Don't know how to make /usr/share/tmac/tmac.andoc" mean?
 .11. What does "Could not find bsd.own.mk" mean?
 .12. Using 'sudo' with pkgsrc
 .13. How do I change the location of configuration files?
 .14. Automated security checks
 .15. Why do some packages ignore my CFLAGS?
 .16. A package does not build. What shall I do?
 .17. What does "Makefile appears to contain unresolved cvs/rcs/??? merge
     conflicts" mean?
 This section contains hints, tips & tricks on special things in pkgsrc that we
 didn't find a better place for in the previous chapters, and it contains items
 for both pkgsrc users and developers.
 .1. Are there any mailing lists for pkg-related discussion?
 The following mailing lists may be of interest to pkgsrc users:
   * pkgsrc-users: This is a general purpose list for most issues regarding
     pkgsrc, regardless of platform, e.g. soliciting user help for pkgsrc
     configuration, unexpected build failures, using particular packages,
     upgrading pkgsrc installations, questions regarding the pkgsrc release
     branches, etc. General announcements or proposals for changes that impact
     the pkgsrc user community, e.g. major infrastructure changes, new features,
     package removals, etc., may also be posted.
   * pkgsrc-bulk: A list where the results of pkgsrc bulk builds are sent and
     discussed.
   * pkgsrc-changes: This list is for those who are interested in getting a
     commit message for every change committed to pkgsrc. It is also available
     in digest form, meaning one daily message containing all commit messages
     for changes to the package source tree in that 24 hour period.
 To subscribe, do:
 % echo subscribe listname | mail majordomo@NetBSD.org
 Archives for all these mailing lists are available from https://
 mail-index.NetBSD.org/.
 .2. Utilities for package management (pkgtools)
 The directory pkgsrc/pkgtools contains a number of useful utilities for both
 users and developers of pkgsrc. This section attempts only to make the reader
 aware of some of the utilities and when they might be useful, and not to
 duplicate the documentation that comes with each package.
 Utilities used by pkgsrc (automatically installed when needed):
   * pkgtools/x11-links: Symlinks for use by buildlink.
 OS tool augmentation (automatically installed when needed):
   * pkgtools/digest: Calculates various kinds of checksums (including SHA3).
   * pkgtools/libnbcompat: Compatibility library for pkgsrc tools.
   * pkgtools/mtree: Installed on non-BSD systems due to lack of native mtree.
   * pkgtools/pkg_install: Up-to-date replacement for /usr/sbin/pkg_install, or
     for use on operating systems where pkg_install is not present.
 Utilities used by pkgsrc (not automatically installed):
   * pkgtools/pkg_tarup: Create a binary package from an already-installed
     package. Used by make replace to save the old package.
   * pkgtools/dfdisk: Adds extra functionality to pkgsrc, allowing it to fetch
     distfiles from multiple locations. It currently supports the following
     methods: multiple CD-ROMs and network FTP/HTTP connections.
   * devel/cpuflags: Determine the best compiler flags to optimise code for your
     current CPU and compiler.
 Utilities for keeping track of installed packages, being up to date, etc:
   * pkgtools/pkgin: A package update tool similar to apt(1). Download, install,
     and upgrade binary packages easily.
   * pkgtools/pkg_chk: Reports on packages whose installed versions do not match
     the latest pkgsrc entries.
   * pkgtools/pkgdep: Makes dependency graphs of packages, to aid in choosing a
     strategy for updating.
   * pkgtools/pkgdepgraph: Makes graphs from the output of pkgtools/pkgdep (uses
     graphviz).
   * pkgtools/pkglint: The pkglint(1) program checks a pkgsrc entry for errors.
   * pkgtools/lintpkgsrc: The lintpkgsrc(1) program does various checks on the
     complete pkgsrc system.
   * pkgtools/pkgsurvey: Report what packages you have installed.
 Utilities for people maintaining or creating individual packages:
   * pkgtools/pkgdiff: Automate making and maintaining patches for a package
     (includes pkgdiff, pkgvi, mkpatches, etc.).
   * pkgtools/url2pkg: Aids in converting to pkgsrc.
 Utilities for people maintaining pkgsrc (or: more obscure pkg utilities)
   * pkgtools/pkg_comp: Build packages in a chrooted area.
   * pkgtools/libkver: Spoof kernel version for chrooted cross builds.
 .3. How to use pkgsrc as non-root
 To install packages from source as a non-root user, download pkgsrc as
 described in Chapter 3, Where to get pkgsrc and how to keep it up-to-date, cd
 into that directory and run the command ./bootstrap/bootstrap --unprivileged.
 This will install the binary part of pkgsrc to ~/pkg and put the pkgsrc
 configuration mk.conf into ~/pkg/etc.
 For more details, see mk/unprivileged.mk.
 .4. How to resume transfers when fetching distfiles?
 By default, resuming transfers in pkgsrc is disabled, but you can enable this
 feature by adding the option PKG_RESUME_TRANSFERS=YES into mk.conf. If, during
 a fetch step, an incomplete distfile is found, pkgsrc will try to resume it.
 You can also use a different program than the platform default program by
 changing the FETCH_USING variable. You can specify the program by using of ftp,
 fetch, wget or curl. Alternatively, fetching can be disabled by using the value
 manual. A value of custom disables the system defaults and dependency tracking
 for the fetch program. In that case you have to provide FETCH_CMD,
 FETCH_BEFORE_ARGS, FETCH_RESUME_ARGS, FETCH_OUTPUT_ARGS, FETCH_AFTER_ARGS.
 For example, if you want to use wget to download, you'll have to use something
 like:
 FETCH_USING=    wget
 .5. How can I install/use modular X.org from pkgsrc?
 If you want to use modular X.org from pkgsrc instead of your system's own X11
 (/usr/X11R6, /usr/openwin, ...) you will have to add the following line into
 mk.conf:
 X11_TYPE=modular
 .6. How to fetch files from behind a firewall
 If you are sitting behind a firewall which does not allow direct connections to
 Internet hosts (i.e. non-NAT), you may specify the relevant proxy hosts. This
 is done using an environment variable in the form of a URL, e.g. in Amdahl, the
 machine "orpheus.amdahl.com" is one of the firewalls, and it uses port 80 as
 the proxy port number. So the proxy environment variables are:
 ftp_proxy=ftp://orpheus.amdahl.com:80/
 http_proxy=http://orpheus.amdahl.com:80/
 .7. How to fetch files from HTTPS sites
 Some fetch tools are not prepared to support HTTPS by default (for example, the
 one in NetBSD 6.0), or the one installed by the pkgsrc bootstrap (to avoid an
 openssl dependency that low in the dependency graph).
 Usually you won't notice, because distribution files are mirrored weekly to "
 ftp.NetBSD.org", but that might not be often enough if you are following
 pkgsrc-current. In that case, set FETCH_USING in your mk.conf file to "curl" or
 "wget", which are both compiled with HTTPS support by default. Of course, these
 tools need to be installed before you can use them this way.
 .8. How do I tell make fetch to do passive FTP?
 This depends on which utility is used to retrieve distfiles. From bsd.pkg.mk,
 FETCH_CMD is assigned the first available command from the following list:
   * ${LOCALBASE}/bin/ftp
   * /usr/bin/ftp
 On a default NetBSD installation, this will be /usr/bin/ftp, which
 automatically tries passive connections first, and falls back to active
 connections if the server refuses to do passive. For the other tools, add the
 following to your mk.conf file: PASSIVE_FETCH=1.
 Having that option present will prevent /usr/bin/ftp from falling back to
 active transfers.
 .9. How to fetch all distfiles at once
 You would like to download all the distfiles in a single batch from work or
 university, where you can't run a make fetch. There is an archive of distfiles
 on ftp.NetBSD.org, but downloading the entire directory may not be appropriate.
 The answer here is to do a make fetch-list in /usr/pkgsrc or one of its
 subdirectories, carry the resulting list to your machine at work/school and use
 it there. If you don't have a NetBSD-compatible ftp(1) (like tnftp) at work,
 don't forget to set FETCH_CMD to something that fetches a URL:
 At home:
 % cd /usr/pkgsrc
 % make fetch-list FETCH_CMD=wget DISTDIR=/tmp/distfiles >/tmp/fetch.sh
 % scp /tmp/fetch.sh work:/tmp
 At work:
 % sh /tmp/fetch.sh
 then tar up /tmp/distfiles and take it home.
 If you have a machine running NetBSD, and you want to get all distfiles (even
 ones that aren't for your machine architecture), you can do so by using the
 above-mentioned make fetch-list approach, or fetch the distfiles directly by
 running:
 % make mirror-distfiles
 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' 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 (either as
 binary package or from 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.5, "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
 . Creating a new pkgsrc package from scratch
 .1. Common types of packages
 .1.1. Perl modules
 .1.2. Python modules and programs
 .1.3. R packages
 .1.4. TeXlive packages
 .2. Examples
 .2.1. How the www/nvu package came into pkgsrc
 . 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/*
 . 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
 . 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
 . 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
 . 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
 . Options handling
 .1. Global default options
 .2. Converting packages to use bsd.options.mk
 .3. Option Names
 .4. Determining the options of dependencies
 . 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
 . Tools needed for building or running
 .1. Tools for pkgsrc builds
 .2. Tools needed by packages
 .3. Tools provided by platforms
 . 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
 .4. Programming languages
 .4.1. C, C++, and Fortran
 .4.2. Java
 .4.3. Packages containing perl scripts
 .4.4. Packages containing shell scripts
 .4.5. 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 GConf data files
 .6.10. Packages installing scrollkeeper/rarian data files
 .6.11. Packages installing X11 fonts
 .6.12. Packages installing GTK2 modules
 .6.13. Packages installing SGML or XML data
 .6.14. Packages installing extensions to the MIME database
 .6.15. Packages using intltool
 .6.16. Packages installing startup scripts
 .6.17. Packages installing TeX modules
 .6.18. Packages supporting running binaries in emulation
 .6.19. Packages installing hicolor theme icons
 .6.20. Packages installing desktop files
 .7. Marking packages as having problems
 . Debugging
 . 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
 . GNOME packaging and porting
 .1. Meta packages
 .2. Packaging a GNOME application
 .3. Updating GNOME to a newer version
 .4. Patching guidelines
 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 D, 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. Creating a new pkgsrc package from scratch
 Table of Contents
 .1. Common types of packages
 .1.1. Perl modules
 .1.2. Python modules and programs
 .1.3. R packages
 .1.4. 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.
 . First, install the packages pkgtools/url2pkg and pkgtools/pkglint.
 . Then, 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). In that category directory, create another directory
     for your package and change into it.
 . Run the program url2pkg, which will ask you for a URL. Enter the URL of the
     distribution file (in most cases a .tar.gz file) and watch how the basic
     ingredients of your package are created automatically. The distribution
     file is extracted automatically to fill in some details in the Makefile
     that would otherwise have to be done manually.
 . 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 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 architecture where
     the package is built; BUILD_DEPENDS are target packages, i.e. packages for
     the architecture for which the package is built. There is also
     TEST_DEPENDS, which is used to specify a dependency used only for testing
     the resulting package built, using the upstream project's included test
     suite. 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 12.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 has
     been saved in the working directory, which may become wrong 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.
 . 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 has 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 package to create a binary package from the set of installed
     files.
 .1. Common types of packages
 .1.1. Perl modules
 Simple Perl modules are handled automatically by url2pkg, including
 dependencies.
 .1.2. 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, ../../lang/python/distutils.mk, or ../../lang/python/extension.mk.
 Most Python packages use either "distutils" or easy-setup/setuptools ("eggs").
 If the packaged software is using setuptools, you only need to include "../../
 lang/python/egg.mk". Otherwise, if the software uses "distutils", include "..
 /../lang/python/distutils.mk", so pkgsrc will use this framework. "distutils"
 uses a script called setup.py; if the "distutils" driver is not called
 setup.py, set the PYSETUP variable to the name of the script.
 Either way, the package directory should be called "py-software" and PKGNAME
 should be set to "${PYPKGPREFIX}-${DISTNAME}", e.g.
 DISTNAME=   foopymodule-1.2.10
 PKGNAME=    ${PYPKGPREFIX}-${DISTNAME}
 If it is an application, include "../../lang/python/application.mk". In order
 to correctly set the path to the Python interpreter, use the REPLACE_PYTHON
 variable and set it to the list of files (paths relative to WRKSRC) that must
 be corrected. For example:
 REPLACE_PYTHON=   *.py
 Some Python modules have separate distributions for Python-2.x and Python-3.x
 support. In pkgsrc this is handled by the versioned_dependencies.mk file. Set
 PYTHON_VERSIONED_DEPENDENCIES to the list of packages that should be depended
 upon and include "../../lang/python/versioned_dependencies.mk", then the pkgsrc
 infrastructure will depend on the appropriate package version. For example:
 PYTHON_VERSIONED_DEPENDENCIES=dialog
 Look inside versioned_dependencies.mk for a list of supported packages.
 .1.3. 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.4. 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