 @@ -8048,3112 +8048,3119 @@ SunPro C++  __SUNPRO_CC (0x580 for Sun C
 <tr>
 <td>accept, bind, connect</td>
 <td>-lsocket</td>
 <td>Solaris</td>
 </tr>
 <tr>
 <td>crypt</td>
 <td>-lcrypt</td>
 <td>DragonFly, NetBSD</td>
 </tr>
 <tr>
 <td>dlopen, dlsym</td>
 <td>-ldl</td>
 <td>Linux</td>
 </tr>
 <tr>
 <td>gethost*</td>
 <td>-lnsl</td>
 <td>Solaris</td>
 </tr>
 <tr>
 <td>inet_aton</td>
 <td>-lresolv</td>
 <td>Solaris</td>
 </tr>
 <tr>
 <td>nanosleep, sem_*, timer_*</td>
 <td>-lrt</td>
 <td>Solaris</td>
 </tr>
 <tr>
 <td>openpty</td>
 <td>-lutil</td>
 <td>Linux</td>
 </tr>
 </tbody>
 </table>
 </div>
 <p>To fix these linker errors, it is often sufficient to say
     <code class="literal">LIBS.<em class="replaceable"><code>OperatingSystem</code></em>+=
     -l<em class="replaceable"><code>foo</code></em></code> to the package
     <code class="filename">Makefile</code> and then say <span class="command"><strong>bmake clean;
     bmake</strong></span>.</p>
 <div class="sect3">
 <div class="titlepage"><div><div><h4 class="title">
 <a name="undefined-reference-sunpro"></a>21.5.3.1. Special issue: The SunPro compiler</h4></div></div></div>
 <p>When you are using the SunPro compiler, there is another
 possibility. That compiler cannot handle the following code:</p>
 <pre class="programlisting">
 extern int extern_func(int);
 static inline int
 inline_func(int x)
+{
         return extern_func(x);
+}
 int main(void)
+{
         return 0;
+}
 </pre>
 <p>It generates the code for <code class="function">inline_func</code> even if
 that function is never used. This code then refers to
 <code class="function">extern_func</code>, which can usually not be resolved. To
 solve this problem you can try to tell the package to disable inlining
 of functions.</p>
 </div>
 </div>
 <div class="sect2">
 <div class="titlepage"><div><div><h3 class="title">
 <a name="out-of-memory"></a>21.5.4. Running out of memory</h3></div></div></div>
 <p>Sometimes packages fail to build because the compiler runs
     into an operating system specific soft limit.  With the
     <code class="varname">UNLIMIT_RESOURCES</code> variable pkgsrc can be told
     to unlimit the resources.  Currently, the allowed values are any combination of
     <span class="quote">&#8220;<span class="quote">cputime</span>&#8221;</span>, <span class="quote">&#8220;<span class="quote">datasize</span>&#8221;</span>,
     <span class="quote">&#8220;<span class="quote">memorysize</span>&#8221;</span>, and <span class="quote">&#8220;<span class="quote">stacksize</span>&#8221;</span>.
     Setting this variable is similar to running the shell builtin
     <span class="command"><strong>ulimit</strong></span> command to raise the maximum data
     segment size or maximum stack size of a process, respectively, to
     their hard limits.</p>
 </div>
 </div>
 <div class="sect1">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
 <a name="fixes.install"></a>21.6. The <span class="emphasis"><em>install</em></span> phase</h2></div></div></div>
 <div class="sect2">
 <div class="titlepage"><div><div><h3 class="title">
 <a name="install-scripts"></a>21.6.1. Creating needed directories</h3></div></div></div>
 <p>The BSD-compatible <span class="command"><strong>install</strong></span> supplied
     with some operating systems cannot create more than one
     directory at a time. As such, you should call
     <code class="literal">${INSTALL_*_DIR}</code> like this:</p>
 <pre class="programlisting">
 ${INSTALL_DATA_DIR} ${PREFIX}/dir1
 ${INSTALL_DATA_DIR} ${PREFIX}/dir2
 </pre>
 <p>You can also just append <span class="quote">&#8220;<span class="quote"><code class="literal">dir1
     dir2</code></span>&#8221;</span> to the
     <code class="varname">INSTALLATION_DIRS</code> variable, which will
     automatically do the right thing.</p>
 </div>
 <div class="sect2">
 <div class="titlepage"><div><div><h3 class="title">
 <a name="where-to-install-documentation"></a>21.6.2. Where to install documentation</h3></div></div></div>
 <p>In general, documentation should be installed into
     <code class="filename">${PREFIX}/share/doc/${PKGBASE}</code> or
     <code class="filename">${PREFIX}/share/doc/${PKGNAME}</code> (the latter
     includes the version number of the package).</p>
 <p>Many modern packages using GNU autoconf allow to set the
     directory where HTML documentation is installed with the
     <span class="quote">&#8220;<span class="quote">--with-html-dir</span>&#8221;</span> option. Sometimes using this flag
     is needed because otherwise the documentation ends up in
     <code class="filename">${PREFIX}/share/doc/html</code> or other
     places.</p>
 <p>An exception to the above is that library API documentation
     generated with the <a href="https://cdn.NetBSD.org/pub/pkgsrc/current/pkgsrc/textproc/gtk-doc/README.html" target="_top"><code class="filename">textproc/gtk-doc</code></a> tools, for use by special
     browsers (devhelp) should be left at their default location, which
     is <code class="filename">${PREFIX}/share/gtk-doc</code>.  Such
     documentation can be recognized from files ending in
     <code class="filename">.devhelp</code> or <code class="filename">.devhelp2</code>.
     (It is also acceptable to install such files in
     <code class="filename">${PREFIX}/share/doc/${PKGBASE}</code> or
     <code class="filename">${PREFIX}/share/doc/${PKGNAME}</code>; the
     <code class="filename">.devhelp*</code> file must be directly in that
     directory then, no additional subdirectory level is allowed in
     this case. This is usually achieved by using
     <span class="quote">&#8220;<span class="quote">--with-html-dir=${PREFIX}/share/doc</span>&#8221;</span>.
     <code class="filename">${PREFIX}/share/gtk-doc</code> is preferred
     though.)</p>
 </div>
 <div class="sect2">
 <div class="titlepage"><div><div><h3 class="title">
 <a name="installing-score-files"></a>21.6.3. Installing highscore files</h3></div></div></div>
 <p>Certain packages, most of them in the games category, install
     a score file that allows all users on the system to record their
     highscores.  In order for this to work, the binaries need to be
     installed setgid and the score files owned by the appropriate
     group and/or owner (traditionally the "games" user/group).  Set
     <code class="varname">USE_GAMESGROUP</code> to yes to support this. The
     following variables, documented in more detail in
     <code class="filename">mk/defaults/mk.conf</code>, control this
     behaviour: <code class="varname">GAMEDATAMODE</code>,
     <code class="varname">GAMEDIRMODE</code>, <code class="varname">GAMES_GROUP</code>,
     <code class="varname">GAMEMODE</code>, <code class="varname">GAME_USER</code>.
     Other useful variables are: <code class="varname">GAMEDIR_PERMS</code>,
     <code class="varname">GAMEDATA_PERMS</code> and
     <code class="varname">SETGID_GAMES_PERMS</code>.</p>
 <p>An example that illustrates some of the variables described above is
     <code class="filename">games/moon-buggy</code>. <code class="varname">OWN_DIRS_PERMS</code> is
     used to properly set directory permissions of the directory where the
     scorefile is saved, <code class="varname">REQD_FILES_PERMS</code> is used to create a
     dummy scorefile (<code class="filename">mbscore</code>) with the proper permissions
     and <code class="varname">SPECIAL_PERMS</code> is used to install setgid the game
     binary:</p>
 <pre class="programlisting">
 USE_GAMESGROUP=         yes
 BUILD_DEFS+=            VARBASE
 OWN_DIRS_PERMS+=        ${VARBASE}/games/moon-buggy ${GAMEDIR_PERMS}
 REQD_FILES_PERMS+=      /dev/null ${VARBASE}/games/moon-buggy/mbscore ${GAMEDATA_PERMS}
 SPECIAL_PERMS+=         ${PREFIX}/bin/moon-buggy ${SETGID_GAMES_PERMS}
 </pre>
 <p>Various <code class="varname">INSTALL_*</code> variables are also available:
     <code class="varname">INSTALL_GAME</code> to install setgid game binaries,
     <code class="varname">INSTALL_GAME_DIR</code> to install game directories that are
     needed to be accessed by setgid games and
     <code class="varname">INSTALL_GAME_DATA</code> to install scorefiles.</p>
 <p>A package should therefore never hard code file ownership or
     access permissions but rely on <code class="varname">*_PERMS</code> as described above
     or alternatively on <code class="varname">INSTALL_GAME</code>,
     <code class="varname">INSTALL_GAME_DATA</code> and
     <code class="varname">INSTALL_GAME_DIR</code> to set these correctly.</p>
 </div>
 <div class="sect2">
 <div class="titlepage"><div><div><h3 class="title">
 <a name="destdir-support"></a>21.6.4. Adding DESTDIR support to packages</h3></div></div></div>
 <p><code class="varname">DESTDIR</code> support means that a package
     installs into a staging directory, not the final location of the
     files. Then a binary package is created which can be used for
     installation as usual. There are two ways: Either the package must
     install as root (<span class="quote">&#8220;<span class="quote">destdir</span>&#8221;</span>) or the package can
     install as non-root user (<span class="quote">&#8220;<span class="quote">user-destdir</span>&#8221;</span>).</p>
 <div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; ">
 <li class="listitem"><p><code class="varname">PKG_DESTDIR_SUPPORT</code> has to be
       set to <span class="quote">&#8220;<span class="quote">destdir</span>&#8221;</span> or <span class="quote">&#8220;<span class="quote">user-destdir</span>&#8221;</span>.
       By default <code class="varname">PKG_DESTDIR_SUPPORT</code>
       is set to <span class="quote">&#8220;<span class="quote">user-destdir</span>&#8221;</span> to help catching more
       potential packaging problems. If bsd.prefs.mk is included in the Makefile,
       <code class="varname">PKG_DESTDIR_SUPPORT</code> needs to be set before
       the inclusion.</p></li>
 <li class="listitem"><p>All installation operations have to be prefixed with
       <code class="filename">${DESTDIR}</code>.</p></li>
 <li class="listitem"><p>automake gets this DESTDIR mostly right
       automatically. Many manual rules and pre/post-install often are
       incorrect; fix them.</p></li>
 <li class="listitem"><p>If files are installed with special owner/group
       use <code class="varname">SPECIAL_PERMS</code>.</p></li>
 <li class="listitem"><p>In general, packages should support
       <code class="varname">UNPRIVILEGED</code> to be able to use
       DESTDIR.</p></li>
 </ul></div>
 </div>
 <div class="sect2">
 <div class="titlepage"><div><div><h3 class="title">
 <a name="hardcoded-paths"></a>21.6.5. Packages with hardcoded paths to other interpreters</h3></div></div></div>
 <p>Your package may also contain scripts with hardcoded paths to
       other interpreters besides (or as well as) perl.  To correct the
       full pathname to the script interpreter, you need to set the
       following definitions in your <code class="filename">Makefile</code> (we
     shall use <span class="command"><strong>tclsh</strong></span> in this example):</p>
 <pre class="programlisting">
 REPLACE_INTERPRETER+=   tcl
 REPLACE.tcl.old=        .*/bin/tclsh
 REPLACE.tcl.new=        ${PREFIX}/bin/tclsh
 REPLACE_FILES.tcl=      # list of tcl scripts which need to be fixed,
 # relative to ${WRKSRC}, just as in REPLACE_PERL
 </pre>
 <div class="note" style="margin-left: 0.5in; margin-right: 0.5in;">
 <h3 class="title">Note</h3>
 <p>Before March 2006, these variables were called
     <code class="varname">_REPLACE.*</code> and
     <code class="varname">_REPLACE_FILES.*</code>.</p>
 </div>
 </div>
 <div class="sect2">
 <div class="titlepage"><div><div><h3 class="title">
 <a name="perl-modules"></a>21.6.6. Packages installing perl modules</h3></div></div></div>
 <p>Makefiles of packages providing perl5 modules should include
     the Makefile fragment
     <code class="filename">../../lang/perl5/module.mk</code>.  It provides a
     <span class="command"><strong>do-configure</strong></span> target for the standard perl
     configuration for such modules as well as various hooks to tune
     this configuration.  See comments in this file for
     details.</p>
 <p>Perl5 modules will install into different places depending
     on the version of perl used during the build process.  To
     address this, pkgsrc will append lines to the
     <code class="filename">PLIST</code> corresponding to the files listed in
     the installed <code class="filename">.packlist</code> file generated by
     most perl5 modules.  This is invoked by defining
     <code class="varname">PERL5_PACKLIST</code> to a space-separated list of
     packlist files relative to <code class="varname">PERL5_PACKLIST_DIR</code>
     (<code class="varname">PERL5_INSTALLVENDORARCH</code> by default),
     e.g.:</p>
 <pre class="programlisting">
 PERL5_PACKLIST= auto/Pg/.packlist
 </pre>
 <p>The perl5 config variables
     <code class="varname">installarchlib</code>,
     <code class="varname">installscript</code>,
     <code class="varname">installvendorbin</code>,
     <code class="varname">installvendorscript</code>,
     <code class="varname">installvendorarch</code>,
     <code class="varname">installvendorlib</code>,
     <code class="varname">installvendorman1dir</code>, and
     <code class="varname">installvendorman3dir</code> represent those
     locations in which components of perl5 modules may be installed,
     provided as variable with uppercase and prefixed with
     <code class="varname">PERL5_</code>, e.g. <code class="varname">PERL5_INSTALLARCHLIB</code>
     and may be used by perl5 packages that don't have a packlist.
     These variables are also substituted for in the
     <code class="filename">PLIST</code> as uppercase prefixed with
     <code class="varname">PERL5_SUB_</code>.</p>
 </div>
 <div class="sect2">
 <div class="titlepage"><div><div><h3 class="title">
 <a name="faq.info-files"></a>21.6.7. Packages installing info files</h3></div></div></div>
 <p>Some packages install info files or use the
     <span class="quote">&#8220;<span class="quote">makeinfo</span>&#8221;</span>  or <span class="quote">&#8220;<span class="quote">install-info</span>&#8221;</span>
     commands.  <code class="varname">INFO_FILES</code> should be defined in
     the package Makefile so that <code class="filename">INSTALL</code> and
     <code class="filename">DEINSTALL</code> scripts will be generated to
     handle registration of the info files in the Info directory
     file. The <span class="quote">&#8220;<span class="quote">install-info</span>&#8221;</span> command used for the info
     files registration is either provided by the system, or by a
     special purpose package automatically added as dependency if
     needed.</p>
 <p><code class="varname">PKGINFODIR</code> is the directory under
     <code class="filename">${PREFIX}</code> where info files are primarily
     located. <code class="varname">PKGINFODIR</code> defaults to
     <span class="quote">&#8220;<span class="quote">info</span>&#8221;</span> and can be overridden by the user.</p>
 <p>The info files for the package should be listed in the
     package <code class="filename">PLIST</code>; however any split info files
     need not be listed.</p>
 <p>A package which needs the <span class="quote">&#8220;<span class="quote">makeinfo</span>&#8221;</span> command
     at build time must add <span class="quote">&#8220;<span class="quote">makeinfo</span>&#8221;</span> to
     <code class="varname">USE_TOOLS</code> in its Makefile. If a minimum
     version of the <span class="quote">&#8220;<span class="quote">makeinfo</span>&#8221;</span> command is needed it
     should be noted with the <code class="varname">TEXINFO_REQD</code>
     variable in the package <code class="filename">Makefile</code>. By
     default, a minimum version of 3.12 is required. If the system
     does not provide a <span class="command"><strong>makeinfo</strong></span> command or if it
     does not match the required minimum, a build dependency on the
     <a href="https://cdn.NetBSD.org/pub/pkgsrc/current/pkgsrc/devel/gtexinfo/README.html" target="_top"><code class="filename">devel/gtexinfo</code></a> package will
     be added automatically.</p>
 <p>The build and installation process of the software provided
     by the package should not use the
     <span class="command"><strong>install-info</strong></span> command as the registration of
     info files is the task of the package
     <code class="filename">INSTALL</code> script, and it must use the
     appropriate <span class="command"><strong>makeinfo</strong></span> command.</p>
 <p>To achieve this goal, the pkgsrc infrastructure creates
     overriding scripts for the <span class="command"><strong>install-info</strong></span> and
     <span class="command"><strong>makeinfo</strong></span> commands in a directory listed early
     in <code class="varname">PATH</code>.</p>
 <p>The script overriding <span class="command"><strong>install-info</strong></span> has
     no effect except the logging of a message. The script overriding
     <span class="command"><strong>makeinfo</strong></span> logs a message and according to the
     value of <code class="varname">TEXINFO_REQD</code> either runs the appropriate
     <span class="command"><strong>makeinfo</strong></span> command or exit on error.</p>
 </div>
 <div class="sect2">
 <div class="titlepage"><div><div><h3 class="title">
 <a name="manpages"></a>21.6.8. Packages installing man pages</h3></div></div></div>
 <p>All packages that install manual pages should install them
     into the same directory, so that there is one common place to look
     for them. In pkgsrc, this place is
     <code class="literal">${PREFIX}/${PKGMANDIR}</code>, and this expression
     should be used in packages. The default for
     <code class="varname">PKGMANDIR</code> is
     <span class="quote">&#8220;<span class="quote"><code class="filename">man</code></span>&#8221;</span>. Another often-used value
     is <span class="quote">&#8220;<span class="quote"><code class="filename">share/man</code></span>&#8221;</span>.</p>
 <div class="note" style="margin-left: 0.5in; margin-right: 0.5in;">
 <h3 class="title">Note</h3>
 <p>The support for a custom <code class="varname">PKGMANDIR</code>
     is far from complete.</p>
 </div>
 <p>The <code class="filename">PLIST</code> files can just use
     <code class="filename">man/</code> as the top level directory for the man
     page file entries, and the pkgsrc framework will convert as
     needed. In all other places, the correct
     <code class="varname">PKGMANDIR</code> must be used.</p>
 <p>Packages that are
     configured with <code class="varname">GNU_CONFIGURE</code> set as
     <span class="quote">&#8220;<span class="quote">yes</span>&#8221;</span>, by default will use the
     <code class="filename">./configure</code>
     --mandir switch to set where the man pages should be installed.
     The path is <code class="varname">GNU_CONFIGURE_MANDIR</code> which defaults
     to <code class="varname">${PREFIX}/${PKGMANDIR}</code>.</p>
 <p>Packages that use <code class="varname">GNU_CONFIGURE</code> but do not
     use --mandir, can set <code class="varname">CONFIGURE_HAS_MANDIR</code>
     to <span class="quote">&#8220;<span class="quote">no</span>&#8221;</span>.
     Or if the <code class="filename">./configure</code> script uses
     a non-standard use of --mandir, you can set
     <code class="varname">GNU_CONFIGURE_MANDIR</code> as needed.</p>
 <p>See <a class="xref" href="#manpage-compression" title="15.5. Man page compression">Section 15.5, &#8220;Man page compression&#8221;</a> for
     information on installation of compressed manual pages.</p>
 </div>
 <div class="sect2">
 <div class="titlepage"><div><div><h3 class="title">
 <a name="gconf-data-files"></a>21.6.9. Packages installing GConf data files</h3></div></div></div>
 <p>If a package installs <code class="filename">.schemas</code> or
     <code class="filename">.entries</code> files, used by GConf,
     you need to take some extra steps to make sure they get registered
     in the database:</p>
 <div class="orderedlist"><ol class="orderedlist" type="1">
 <li class="listitem"><p>Include <code class="filename">../../devel/GConf/schemas.mk</code>
 	instead of its <code class="filename">buildlink3.mk</code> file.  This
 	takes care of rebuilding the GConf database at installation and
 	deinstallation time, and tells the package where to install
 	GConf data files using some standard configure arguments.  It
 	also disallows any access to the database directly from the
 	package.</p></li>
 <li class="listitem"><p>Ensure that the package installs its
 	<code class="filename">.schemas</code> files under
 	<code class="filename">${PREFIX}/share/gconf/schemas</code>.  If they get
 	installed under <code class="filename">${PREFIX}/etc</code>, you will
 	need to manually patch the package.</p></li>
 <li class="listitem"><p>Check the PLIST and remove any entries under the etc/gconf
 	directory, as they will be handled automatically.  See
 	<a class="xref" href="#faq.conf" title="10.13. How do I change the location of configuration files?">Section 10.13, &#8220;How do I change the location of configuration files?&#8221;</a> for more information.</p></li>
 <li class="listitem"><p>Define the <code class="varname">GCONF_SCHEMAS</code> variable in
 	your <code class="filename">Makefile</code> with a list of all
 	<code class="filename">.schemas</code> files installed by the package, if
 	any.  Names must not contain any directories in them.</p></li>
 <li class="listitem"><p>Define the <code class="varname">GCONF_ENTRIES</code> variable in
 	your <code class="filename">Makefile</code> with a
 	list of all <code class="filename">.entries</code> files installed by the
 	package, if any. Names must not contain any directories in
 	them.</p></li>
 </ol></div>
 </div>
 <div class="sect2">
 <div class="titlepage"><div><div><h3 class="title">
 <a name="scrollkeeper-data-files"></a>21.6.10. Packages installing scrollkeeper/rarian data files</h3></div></div></div>
 <p>If a package installs <code class="filename">.omf</code> files, used by
     scrollkeeper/rarian, you need to take some extra steps to make sure they
     get registered in the database:</p>
 <div class="orderedlist"><ol class="orderedlist" type="1">
 <li class="listitem"><p>Include
 	<code class="filename">../../mk/omf-scrollkeeper.mk</code>
 	instead of rarian's <code class="filename">buildlink3.mk</code> file.  This
 	takes care of rebuilding the scrollkeeper database at
 	installation and deinstallation time, and disallows any access
 	to it directly from the package.</p></li>
 <li class="listitem"><p>Check the PLIST and remove any entries under the
 	<code class="filename">libdata/scrollkeeper</code> directory, as they
 	will be handled automatically.</p></li>
 <li class="listitem"><p>Remove the <code class="filename">share/omf</code> directory from
 	the PLIST.  It will be handled by rarian. (<span class="command"><strong>make
 	print-PLIST</strong></span> does this automatically.)</p></li>
 </ol></div>
 </div>
 <div class="sect2">
 <div class="titlepage"><div><div><h3 class="title">
 <a name="x11-fonts"></a>21.6.11. Packages installing X11 fonts</h3></div></div></div>
 <p>If a package installs font files, you will need to rebuild
     the fonts database in the directory where they get installed at
     installation and deinstallation time.  This can be automatically
     done by using the pkginstall framework.</p>
 <p>You can list the directories where fonts are installed in the
     <code class="varname">FONTS_DIRS.<em class="replaceable"><code>type</code></em></code>
     variables, where <em class="replaceable"><code>type</code></em> can be one of
     <span class="quote">&#8220;<span class="quote">ttf</span>&#8221;</span>, <span class="quote">&#8220;<span class="quote">type1</span>&#8221;</span> or <span class="quote">&#8220;<span class="quote">x11</span>&#8221;</span>.
     Also make sure that the database file
     <code class="filename">fonts.dir</code> is not listed in the PLIST.</p>
 <p>Note that you should not create new directories for fonts;
     instead use the standard ones to avoid that the user needs to
     manually configure his X server to find them.</p>
 </div>
 <div class="sect2">
 <div class="titlepage"><div><div><h3 class="title">
 <a name="gtk2-modules"></a>21.6.12. Packages installing GTK2 modules</h3></div></div></div>
 <p>If a package installs GTK2 immodules or loaders, you need to
     take some extra steps to get them registered in the GTK2 database
     properly:</p>
 <div class="orderedlist"><ol class="orderedlist" type="1">
 <li class="listitem"><p>Include
       <code class="filename">../../x11/gtk2/modules.mk</code> instead of its
       <code class="filename">buildlink3.mk</code> file.  This takes care of
       rebuilding the database at installation and deinstallation time.</p></li>
 <li class="listitem"><p>Set <code class="varname">GTK2_IMMODULES=YES</code> if
       your package installs GTK2 immodules.</p></li>
 <li class="listitem"><p>Set <code class="varname">GTK2_LOADERS=YES</code> if your package installs
       GTK2 loaders.</p></li>
 <li class="listitem">
 <p>Patch the package to not touch any of the GTK2
       databases directly.  These are:</p>
 <div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; ">
 <li class="listitem"><p><code class="filename">libdata/gtk-2.0/gdk-pixbuf.loaders</code></p></li>
 <li class="listitem"><p><code class="filename">libdata/gtk-2.0/gtk.immodules</code></p></li>
 </ul></div>
 </li>
 <li class="listitem"><p>Check the <code class="filename">PLIST</code> and remove
       any entries under the <code class="filename">libdata/gtk-2.0</code>
       directory, as they will be handled automatically.</p></li>
 </ol></div>
 </div>
 <div class="sect2">
 <div class="titlepage"><div><div><h3 class="title">
 <a name="sgml-xml-data"></a>21.6.13. Packages installing SGML or XML data</h3></div></div></div>
 <p>If a package installs SGML or XML data files that need to be
     registered in system-wide catalogs (like DTDs, sub-catalogs,
     etc.), you need to take some extra steps:</p>
 <div class="orderedlist"><ol class="orderedlist" type="1">
 <li class="listitem"><p>Include
 	<code class="filename">../../textproc/xmlcatmgr/catalogs.mk</code> in
 	your <code class="filename">Makefile</code>, which takes care of
 	registering those files in system-wide catalogs at
 	installation and deinstallation time.</p></li>
 <li class="listitem"><p>Set <code class="varname">SGML_CATALOGS</code> to the full path of
 	any SGML catalogs installed by the package.</p></li>
 <li class="listitem"><p>Set <code class="varname">XML_CATALOGS</code> to the full path of
 	any XML catalogs installed by the package.</p></li>
 <li class="listitem"><p>Set <code class="varname">SGML_ENTRIES</code> to individual entries
 	to be added to the SGML catalog.  These come in groups of
 	three strings; see xmlcatmgr(1) for more information
 	(specifically, arguments recognized by the 'add' action).
 	Note that you will normally not use this variable.</p></li>
 <li class="listitem"><p>Set <code class="varname">XML_ENTRIES</code> to individual entries
 	to be added to the XML catalog.  These come in groups of three
 	strings; see xmlcatmgr(1) for more information (specifically,
 	arguments recognized by the 'add' action).  Note that you will
 	normally not use this variable.</p></li>
 </ol></div>
 </div>
 <div class="sect2">
 <div class="titlepage"><div><div><h3 class="title">
 <a name="mime-database"></a>21.6.14. Packages installing extensions to the MIME database</h3></div></div></div>
 <p>If a package provides extensions to the MIME database by
     installing <code class="filename">.xml</code> files inside
     <code class="filename">${PREFIX}/share/mime/packages</code>, you
     need to take some extra steps to ensure that the database is kept
     consistent with respect to these new files:</p>
 <div class="orderedlist"><ol class="orderedlist" type="1">
 <li class="listitem"><p>Include
 	<code class="filename">../../databases/shared-mime-info/mimedb.mk</code>
 	(avoid using the <code class="filename">buildlink3.mk</code> file from
 	this same directory, which is reserved for inclusion from
 	other <code class="filename">buildlink3.mk</code> files).  It takes
 	care of rebuilding the MIME database at installation and
 	deinstallation time, and disallows any access to it directly
 	from the package.</p></li>
 <li class="listitem"><p>Check the PLIST and remove any entries under the
 	<code class="filename">share/mime</code> directory,
 	<span class="emphasis"><em>except</em></span> for files saved under
 	<code class="filename">share/mime/packages</code>.  The former are
 	handled automatically by
 	the update-mime-database program, but the latter are
 	package-dependent and must be removed by the package that
 	installed them in the first place.</p></li>
 <li class="listitem"><p>Remove any <code class="filename">share/mime/*</code> directories
 	from the PLIST.  They will be handled by the shared-mime-info
 	package.</p></li>
 </ol></div>
 </div>
 <div class="sect2">
 <div class="titlepage"><div><div><h3 class="title">
 <a name="intltool"></a>21.6.15. Packages using intltool</h3></div></div></div>
 <p>If a package uses intltool during its build, add
     <code class="literal">intltool</code> to the <code class="varname">USE_TOOLS</code>,
     which forces it to use the intltool package provided by pkgsrc,
     instead of the one bundled with the distribution file.</p>
 <p>This tracks intltool's build-time dependencies and uses the
     latest available version; this way, the package benefits of any
     bug fixes that may have appeared since it was released.</p>
 </div>
 <div class="sect2">
 <div class="titlepage"><div><div><h3 class="title">
 <a name="startup-scripts"></a>21.6.16. Packages installing startup scripts</h3></div></div></div>
 <p>If a package contains a rc.d script, it won't be copied into
     the startup directory by default, but you can enable it, by adding
     the option <code class="varname">PKG_RCD_SCRIPTS=YES</code> in
     <a class="link" href="#mk.conf"><code class="filename">mk.conf</code></a>. This option will copy the scripts
     into <code class="filename">/etc/rc.d</code> when a package is installed, and
     it will automatically remove the scripts when the package is
     deinstalled.</p>
 </div>
 <div class="sect2">
 <div class="titlepage"><div><div><h3 class="title">
 <a name="tex-packages"></a>21.6.17. Packages installing TeX modules</h3></div></div></div>
 <p>If a package installs TeX packages into the texmf tree,
     the <code class="filename">ls-R</code> database of the tree needs to be
     updated.</p>
 <div class="note" style="margin-left: 0.5in; margin-right: 0.5in;">
 <h3 class="title">Note</h3>
 <p>Except the main TeX packages such as kpathsea,
     packages should install files
     into <code class="filename">${PREFIX}/share/texmf-dist</code>,
     not <code class="filename">${PREFIX}/share/texmf</code>.</p>
 </div>
 <div class="orderedlist"><ol class="orderedlist" type="1">
 <li class="listitem"><p>Include
       <code class="filename">../../print/kpathsea/texmf.mk</code>.  This
       takes care of rebuilding the <code class="filename">ls-R</code>
       database at installation and deinstallation time.</p></li>
 <li class="listitem">
 <p>If your package installs files into a texmf
       tree other than the one
       at <code class="filename">${PREFIX}/share/texmf-dist</code>,
       set <code class="varname">TEX_TEXMF_DIRS</code> to the list of all texmf
       trees that need database update.</p>
 <p>If your package also installs font map files that need
       to be registered using <span class="command"><strong>updmap</strong></span>,
       include <code class="filename">../../print/tex-tetex/map.mk</code> and
       set <code class="varname">TEX_MAP_FILES</code> and/or
       <code class="varname">TEX_MIXEDMAP_FILES</code> to the list of all
       such font map files.  Then <span class="command"><strong>updmap</strong></span> will
       be run automatically at installation/deinstallation to
       enable/disable font map files for TeX output
       drivers.</p>
 </li>
 <li class="listitem"><p>Make sure that none of <code class="filename">ls-R</code>
       databases are included in <code class="filename">PLIST</code>, as
       they will be removed only by the kpathsea package.</p></li>
 </ol></div>
 </div>
 <div class="sect2">
 <div class="titlepage"><div><div><h3 class="title">
 <a name="emulation-packages"></a>21.6.18. Packages supporting running binaries in
     emulation</h3></div></div></div>
 <p>There are some packages that provide libraries and
     executables for running binaries from a one operating system
     on a different one (if the latter supports it).  One example
     is running Linux binaries on NetBSD.</p>
 <p>The <a href="https://cdn.NetBSD.org/pub/pkgsrc/current/pkgsrc/pkgtools/rpm2pkg/README.html" target="_top"><code class="filename">pkgtools/rpm2pkg</code></a>
     helps in extracting and packaging Linux rpm packages.</p>
 <p>The <code class="varname">CHECK_SHLIBS</code> can be set to no to
     avoid the <span class="command"><strong>check-shlibs</strong></span> target, which tests
     if all libraries for each installed executable can be found by
     the dynamic linker.  Since the standard dynamic linker is run,
     this fails for emulation packages, because the libraries used
     by the emulation are not in the standard directories.</p>
 </div>
 <div class="sect2">
 <div class="titlepage"><div><div><h3 class="title">
 <a name="hicolor-theme"></a>21.6.19. Packages installing hicolor theme icons</h3></div></div></div>
 <p>If a package installs images under the
     <code class="filename">share/icons/hicolor</code> and/or updates the
     <code class="filename">share/icons/hicolor/icon-theme.cache</code>
     database, you need to take some extra steps to make sure that the
     shared theme directory is handled appropriately and that the cache
     database is rebuilt:</p>
 <div class="orderedlist"><ol class="orderedlist" type="1">
 <li class="listitem"><p>Include
 	<code class="filename">../../graphics/hicolor-icon-theme/buildlink3.mk</code>.</p></li>
 <li class="listitem"><p>Check the <code class="filename">PLIST</code> and remove the
 	entry that refers to the theme cache.</p></li>
 <li class="listitem"><p>Ensure that the PLIST does not remove the shared icon
 	  directories from the <code class="filename">share/icons/hicolor</code>
 	  hierarchy because they will be handled automatically.</p></li>
 </ol></div>
 <p>The best way to verify that the PLIST is correct with
       respect to the last two points is to regenerate it using
       <span class="command"><strong>make print-PLIST</strong></span>.</p>
 </div>
 <div class="sect2">
 <div class="titlepage"><div><div><h3 class="title">
 <a name="desktop-files"></a>21.6.20. Packages installing desktop files</h3></div></div></div>
 <p>If a package installs <code class="filename">.desktop</code> files
       under <code class="filename">share/applications</code> and these include
       MIME information (MimeType key), you need to take extra steps to
       ensure that they are registered into the MIME database:</p>
 <div class="orderedlist"><ol class="orderedlist" type="1">
 <li class="listitem"><p>Include
 	  <code class="filename">../../sysutils/desktop-file-utils/desktopdb.mk</code>.</p></li>
 <li class="listitem"><p>Check the PLIST and remove the entry that refers to the
 	  <code class="filename">share/applications/mimeinfo.cache</code> file.
 	  It will be handled automatically.</p></li>
 </ol></div>
 <p>The best way to verify that the PLIST is correct with
       respect to the last point is to regenerate it using <span class="command"><strong>make
       print-PLIST</strong></span>.</p>
 </div>
 </div>
 <div class="sect1">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
 <a name="punting"></a>21.7. Marking packages as having problems</h2></div></div></div>
 <p>In some cases one does not have the time to solve a problem
   immediately. In this case, one can plainly mark a package as broken.  For
   this, one just sets the variable <code class="varname">BROKEN</code> to the
   reason why the package is broken (similar to the
   <code class="varname">PKG_FAIL_REASON</code> variable).  A user trying to build
   the package will immediately be shown this message, and the build
   will not be even tried.</p>
 <p><code class="varname">BROKEN</code> packages are removed from pkgsrc in irregular
   intervals.</p>
 </div>
 </div>
 <div class="chapter">
 <div class="titlepage"><div><div><h2 class="title">
 <a name="debug"></a>Chapter 22. Debugging</h2></div></div></div>
 <p>To check out all the gotchas when building a package, here are
   the steps that I do in order to get a package working.  Please note
   this is basically the same as what was explained in the previous
   sections, only with some debugging aids.</p>
 <div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; ">
 <li class="listitem"><p>Be sure to set <code class="varname">PKG_DEVELOPER=yes</code> in <a class="link" href="#mk.conf"><code class="filename">mk.conf</code></a>.</p></li>
 <li class="listitem">
 <p>Install <a href="https://cdn.NetBSD.org/pub/pkgsrc/current/pkgsrc/pkgtools/url2pkg/README.html" target="_top"><code class="filename">pkgtools/url2pkg</code></a>,
       create a directory for a new package, change into it, then run
       <span class="command"><strong>url2pkg</strong></span>:</p>
 <pre class="screen"><code class="prompt">%</code> <strong class="userinput"><code>mkdir /usr/pkgsrc/<em class="replaceable"><code>category</code></em>/<em class="replaceable"><code>examplepkg</code></em></code></strong>
 <code class="prompt">%</code> <strong class="userinput"><code>cd /usr/pkgsrc/<em class="replaceable"><code>category</code></em>/<em class="replaceable"><code>examplepkg</code></em></code></strong>
 <code class="prompt">%</code> <strong class="userinput"><code>url2pkg http://www.example.com/path/to/distfile.tar.gz</code></strong></pre>
 </li>
 <li class="listitem"><p>Edit the <code class="filename">Makefile</code> as requested.</p></li>
 <li class="listitem"><p>Fill in the <code class="filename">DESCR</code> file</p></li>
 <li class="listitem"><p>Run <span class="command"><strong>make configure</strong></span></p></li>
 <li class="listitem"><p>Add any dependencies glimpsed from documentation and the
       configure step to the package's
       <code class="filename">Makefile</code>.</p></li>
 <li class="listitem">
 <p>Make the package compile, doing multiple rounds of</p>
 <pre class="screen"><code class="prompt">%</code> <strong class="userinput"><code>make</code></strong>
 <code class="prompt">%</code> <strong class="userinput"><code>pkgvi ${WRKSRC}/some/file/that/does/not/compile</code></strong>
 <code class="prompt">%</code> <strong class="userinput"><code>mkpatches</code></strong>
 <code class="prompt">%</code> <strong class="userinput"><code>patchdiff</code></strong>
 <code class="prompt">%</code> <strong class="userinput"><code>mv ${WRKDIR}/.newpatches/* patches</code></strong>
 <code class="prompt">%</code> <strong class="userinput"><code>make mps</code></strong>
 <code class="prompt">%</code> <strong class="userinput"><code>make clean</code></strong></pre>
 <p>Doing this step as non-root user will ensure that no files
       are modified that shouldn't be, especially during the build
       phase.  <span class="command"><strong>mkpatches</strong></span>,
       <span class="command"><strong>patchdiff</strong></span> and <span class="command"><strong>pkgvi</strong></span> are
       from the <a href="https://cdn.NetBSD.org/pub/pkgsrc/current/pkgsrc/pkgtools/pkgdiff/README.html" target="_top"><code class="filename">pkgtools/pkgdiff</code></a>
       package.</p>
 </li>
 <li class="listitem"><p>Look at the <code class="filename">Makefile</code>, fix if
       necessary; see <a class="xref" href="#components.Makefile" title="13.1. Makefile">Section 13.1, &#8220;<code class="filename">Makefile</code>&#8221;</a>.</p></li>
 <li class="listitem">
 <p>Generate a <code class="filename">PLIST</code>:</p>
 <pre class="screen"><code class="prompt">#</code> <strong class="userinput"><code>make install</code></strong>
 <code class="prompt">#</code> <strong class="userinput"><code>make print-PLIST &gt;PLIST</code></strong>
 <code class="prompt">#</code> <strong class="userinput"><code>make deinstall</code></strong>
 <code class="prompt">#</code> <strong class="userinput"><code>make install</code></strong>
 <code class="prompt">#</code> <strong class="userinput"><code>make deinstall</code></strong></pre>
 <p>You usually need to be <code class="username">root</code> to do
       this.  Look if there are any files left:</p>
 <pre class="screen"><code class="prompt">#</code> <strong class="userinput"><code>make print-PLIST</code></strong></pre>
 <p>If this reveals any files that are missing in
       <code class="filename">PLIST</code>, add them.</p>
 </li>
 <li class="listitem">
 <p>Now that the <code class="filename">PLIST</code> is OK, install the
       package again and make a binary package:</p>
 <pre class="screen"><code class="prompt">#</code> <strong class="userinput"><code>make reinstall</code></strong>
 <code class="prompt">#</code> <strong class="userinput"><code>make package</code></strong></pre>
 </li>
 <li class="listitem">
 <p>Delete the installed package:</p>
 <pre class="screen"><code class="prompt">#</code> <strong class="userinput"><code>pkg_delete <em class="replaceable"><code>examplepkg</code></em></code></strong></pre>
 </li>
 <li class="listitem">
 <p>Repeat the above <span class="command"><strong>make print-PLIST</strong></span>
       command, which shouldn't find anything now:</p>
 <pre class="screen"><code class="prompt">#</code> <strong class="userinput"><code>make print-PLIST</code></strong></pre>
 </li>
 <li class="listitem">
 <p>Reinstall the binary package:</p>
 <pre class="screen"><code class="prompt">#</code> <strong class="userinput"><code>pkg_add .../<em class="replaceable"><code>examplepkg</code></em>.tgz</code></strong></pre>
 </li>
 <li class="listitem"><p>Play with it.  Make sure everything works.</p></li>
 <li class="listitem">
 <p>Run <span class="command"><strong>pkglint</strong></span> from <a href="https://cdn.NetBSD.org/pub/pkgsrc/current/pkgsrc/pkgtools/pkglint/README.html" target="_top"><code class="filename">pkgtools/pkglint</code></a>, and fix the problems it
       reports:</p>
 <pre class="screen"><code class="prompt">#</code> <strong class="userinput"><code>pkglint</code></strong></pre>
 </li>
 <li class="listitem"><p>Submit (or commit, if you have cvs access); see <a class="xref" href="#submit" title="Chapter 23. Submitting and Committing">Chapter 23, <i>Submitting and Committing</i></a>.</p></li>
 </ul></div>
 </div>
 <div class="chapter">
 <div class="titlepage"><div><div><h2 class="title">
 <a name="submit"></a>Chapter 23. Submitting and Committing</h2></div></div></div>
 <div class="toc">
 <p><b>Table of Contents</b></p>
 <dl class="toc">
 <dt><span class="sect1"><a href="#submitting-binary-packages">23.1. Submitting binary packages</a></span></dt>
 <dt><span class="sect1"><a href="#submitting-your-package">23.2. Submitting source packages (for non-NetBSD-developers)</a></span></dt>
 <dt><span class="sect1"><a href="#general-notes-for-changes">23.3. General notes when adding, updating, or removing packages</a></span></dt>
 <dt><span class="sect1"><a href="#commit-messages">23.4. Commit Messages</a></span></dt>
 <dt><span class="sect1"><a href="#committing-importing">23.5. Committing: Adding a package to CVS</a></span></dt>
 <dt><span class="sect1"><a href="#updating-package">23.6. Updating a package to a newer version</a></span></dt>
 <dt><span class="sect1"><a href="#renaming-package">23.7. Renaming a package in pkgsrc</a></span></dt>
 <dt><span class="sect1"><a href="#moving-package">23.8. Moving a package in pkgsrc</a></span></dt>
 </dl>
 </div>
 <div class="sect1">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
 <a name="submitting-binary-packages"></a>23.1. Submitting binary packages</h2></div></div></div>
 <p>Our policy is that we accept binaries only from pkgsrc
 	developers to guarantee that the packages don't contain any
 	trojan horses etc. This is not to annoy anyone but rather to
 	protect our users! You're still free to put up your home-made
 	binary packages and tell the world where to get them. NetBSD
 	developers doing bulk builds and wanting to upload them please
 	see <a class="xref" href="#bulk" title="Chapter 8. Creating binary packages for everything in pkgsrc (bulk builds)">Chapter 8, <i>Creating binary packages for everything in pkgsrc (bulk
 builds)</i></a>.</p>
 </div>
 <div class="sect1">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
 <a name="submitting-your-package"></a>23.2. Submitting source packages (for non-NetBSD-developers)</h2></div></div></div>
 <p>First, check that your package is complete, compiles and
 	runs well; see <a class="xref" href="#debug" title="Chapter 22. Debugging">Chapter 22, <i>Debugging</i></a> and the rest of this
 	document. Next, generate an uuencoded gzipped <a class="citerefentry" href="https://netbsd.gw.com/cgi-bin/man-cgi?tar+1.i386+NetBSD-8.1"><span class="citerefentry"><span class="refentrytitle">tar</span>(1)</span></a>
 	archive that contains all files that make up the package.
 	Finally, send this package to the pkgsrc bug tracking system,
 	either with the <a class="citerefentry" href="https://netbsd.gw.com/cgi-bin/man-cgi?send-pr+1.i386+NetBSD-8.1"><span class="citerefentry"><span class="refentrytitle">send-pr</span>(1)</span></a> command, or if you don't have
 	that, go to the web page
 	<a class="ulink" href="http://www.NetBSD.org/support/send-pr.html" target="_top">http://www.NetBSD.org/support/send-pr.html</a>,
 	which contains some instructions and a link to a form where you
 	can submit packages.  The
 	<a href="https://cdn.NetBSD.org/pub/pkgsrc/current/pkgsrc/sysutils/gtk-send-pr/README.html" target="_top"><code class="filename">sysutils/gtk-send-pr</code></a> package is
 	also available as a substitute for either of the above two tools.
 	</p>
 <p>In the form of the problem report, the category should be
 	<span class="quote">&#8220;<span class="quote">pkg</span>&#8221;</span>, the synopsis should include the package name
 	and version number, and the description field should contain a
 	short description of your package (contents of the COMMENT
 	variable or DESCR file are OK). The uuencoded package data should
 	go into the <span class="quote">&#8220;<span class="quote">fix</span>&#8221;</span> field.</p>
 <p>If you want to submit several packages, please send a
 	separate PR for each one, it's easier for us to track things
 	that way.</p>
 <p>Alternatively, you can also import new packages into
 	pkgsrc-wip (<span class="quote">&#8220;<span class="quote">pkgsrc work-in-progress</span>&#8221;</span>); see the
 	homepage at <a class="ulink" href="http://pkgsrc.org/wip/" target="_top">http://pkgsrc.org/wip/</a>
 	for details.</p>
 </div>
 <div class="sect1">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
 <a name="general-notes-for-changes"></a>23.3. General notes when adding, updating, or removing packages</h2></div></div></div>
 <p>Please note all package additions, updates, moves, and
 	removals in <code class="filename">pkgsrc/doc/CHANGES-<em class="replaceable"><code>YYYY</code></em></code>. It's very
 	important to keep this file up to date and conforming to the
 	existing format, because it will be used by scripts to
 	automatically update pages on <a class="ulink" href="http://www.NetBSD.org/" target="_top">www.NetBSD.org</a> and other
 	sites. Additionally, check the
 	<code class="filename">pkgsrc/doc/TODO</code> file and remove the entry
 	for the package you updated or removed, in case it was mentioned
 	there.</p>
 <p>When the <code class="varname">PKGREVISION</code> of a package is
 	bumped, the change should appear in
 	<code class="filename">pkgsrc/doc/CHANGES-<em class="replaceable"><code>YYYY</code></em></code> if it is security
 	related or otherwise relevant. Mass bumps that result from a
 	dependency being updated should not be mentioned. In all other
 	cases it's the developer's decision.</p>
 <p>There is a make target that helps in creating proper
   <code class="filename">CHANGES-<em class="replaceable"><code>YYYY</code></em></code> entries:  <span class="command"><strong>make
   changes-entry</strong></span>. It uses the optional <code class="varname">CTYPE</code>
   and <code class="varname">NETBSD_LOGIN_NAME</code> variables. The general
   usage is to first make sure that your <code class="filename">CHANGES-<em class="replaceable"><code>YYYY</code></em></code>
   file is up-to-date (to avoid having to resolve conflicts later-on)
   and then to <span class="command"><strong>cd</strong></span> to the package directory.  For
   package updates, <span class="command"><strong>make changes-entry</strong></span> is enough.
   For new packages, or package moves or removals, set the
   <code class="varname">CTYPE</code> variable on the command line to "Added",
   "Moved", or "Removed".  You can set <code class="varname">NETBSD_LOGIN_NAME</code>
   in <a class="link" href="#mk.conf"><code class="filename">mk.conf</code></a> if your local login name is
   not the same as your NetBSD login name. The target also automatically
   removes possibly existing entries for the package in the
   <code class="filename">TODO</code> file. Don't forget to commit
   the changes, e.g. by using <span class="command"><strong>make commit-changes-entry</strong></span>!
   If you are not using a checkout directly from cvs.NetBSD.org, but e.g.
   a local copy of the repository, you can set USE_NETBSD_REPO=yes. This
   makes the cvs commands use the main repository.
   </p>
 </div>
 <div class="sect1">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
 <a name="commit-messages"></a>23.4. Commit Messages</h2></div></div></div>
 <p>For several years, there have been mirrors of pkgsrc in
   fossil, git, and hg. Standard practise when using these tools is to
   make the first line of a commit message function as a summary that
   can be read without the rest, such as is commonly done with "git log
   --oneline". For this reason, we have the following guidelines for
   pkgsrc commit messages:</p>
 <div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; ">
 <li class="listitem"><p>Start the commit message with a line that explains the
     big picture in 65 characters or less. When a commit is for one
     package, include the name of the package. For updates, include the
     version to which it is updated.</p></li>
 <li class="listitem"><p>Leave the next line empty.</p></li>
 <li class="listitem"><p>Then come the details for the commit (changes in that
     package, reason for a change) and any relevant PRs. Wrap this
     section.</p></li>
 </ul></div>
 <p>Here is an example:
   </p>
 <pre class="programlisting">
   libxslt: update to 1.0.30
   Changes since 1.0.29:
   ...
   </pre>
 <p>
   </p>
 <p>Here is another example:
   </p>
 <pre class="programlisting">
   mk/bsd.pkg.mk: enable SSP by default on NetBSD
   (rationale)
   </pre>
 <p>
   </p>
 <p>Commit messages are final: no <span class="quote">&#8220;<span class="quote">cvs admin</span>&#8221;</span> is
   allowed on the pkgsrc repository to change commit messages.</p>
 </div>
 <div class="sect1">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
 <a name="committing-importing"></a>23.5. Committing: Adding a package to CVS</h2></div></div></div>
 <p>This section is only of interest for pkgsrc developers with write
   access to the pkgsrc repository.</p>
 <p>When the package is finished, <span class="quote">&#8220;<span class="quote">cvs add</span>&#8221;</span> the files.
 Start by adding the directory and then files in the directory. Don't
 forget to add the new package to the category's
 <code class="filename">Makefile</code>. Make sure you don't forget any files;
 you can check by running <span class="quote">&#8220;<span class="quote">cvs status</span>&#8221;</span>. An example:</p>
 <pre class="programlisting">
 <code class="prompt">$</code> cd .../pkgsrc/category
 <code class="prompt">$</code> cvs add pkgname
 <code class="prompt">$</code> cd pkgname
 <code class="prompt">$</code> cvs add DESCR Makefile PLIST distinfo buildlink3.mk patches
 <code class="prompt">$</code> cvs add patches/p*
 <code class="prompt">$</code> cvs status | less
 <code class="prompt">$</code> cvs commit
 <code class="prompt">$</code> cd ..
 <code class="prompt">$</code> vi Makefile # add SUBDIRS+=pkgname line
 <code class="prompt">$</code> cvs commit Makefile
 <code class="prompt">$</code> cd pkgname
 <code class="prompt">$</code> make CTYPE=Added commit-changes-entry
 </pre>
 <p>The commit message of the initial import should include part of the
   <code class="filename">DESCR</code> file, so people reading the mailing lists know
   what the package is/does.</p>
 <p>Also mention the new package in
 <code class="filename">pkgsrc/doc/CHANGES-20xx</code>.</p>
 <p>Previously, <span class="quote">&#8220;<span class="quote">cvs import</span>&#8221;</span> was suggested, but it was
 much easier to get wrong than <span class="quote">&#8220;<span class="quote">cvs add</span>&#8221;</span>.</p>
 </div>
 <div class="sect1">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
 <a name="updating-package"></a>23.6. Updating a package to a newer version</h2></div></div></div>
 <p>Please always put a concise, appropriate and relevant summary of the
   changes between old and new versions into the commit log when updating
   a package. There are various reasons for this:</p>
 <div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; ">
 <li class="listitem"><p>A URL is volatile, and can change over time. It may go away completely
   or its information may be overwritten by newer information.</p></li>
 <li class="listitem"><p>Having the change information between old and new versions in our CVS
   repository is very useful for people who use either cvs or anoncvs.</p></li>
 <li class="listitem"><p>Having the change information between old and new versions in our CVS
   repository is very useful for people who read the pkgsrc-changes mailing
   list, so that they can make tactical decisions about when to upgrade
   the package.</p></li>
 </ul></div>
 <p>Please also recognize that, just because a new version of a package
   has been released, it should not automatically be upgraded in the CVS
   repository.  We prefer to be conservative in the packages that are
   included in pkgsrc - development or beta packages are not really the
   best thing for most places in which pkgsrc is used. Please use your
   judgement about what should go into pkgsrc, and bear in mind that
   stability is to be preferred above new and possibly untested features.</p>
 </div>
 <div class="sect1">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
 <a name="renaming-package"></a>23.7. Renaming a package in pkgsrc</h2></div></div></div>
 <p>Renaming packages is not recommended.</p>
 <p>When renaming packages, be sure to fix any references to old name
   in other Makefiles, options, buildlink files, etc.</p>
 <p>
   Also when renaming a package, please add
   the package name and version pattern(s) of the previous package
   to <code class="varname">SUPERSEDES</code>.
   This may be repeated for multiple renames.
   The new package would be an exact replacement.
   Example:
 </p>
 <pre class="programlisting">
 SUPERSEDES+=    p5-IO-Compress-Zlib&lt;2.017
 SUPERSEDES+=    optcomp-[0-9]*
 </pre>
 <p>Note that <span class="quote">&#8220;<span class="quote">successor</span>&#8221;</span> in the
   CHANGES-<em class="replaceable"><code>YYYY</code></em> file doesn't necessarily
   mean that it <span class="emphasis"><em>supersedes</em></span>, as that successor may
   not be an exact replacement but is a suggestion for the replaced
   functionality.</p>
 </div>
 <div class="sect1">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
 <a name="moving-package"></a>23.8. Moving a package in pkgsrc</h2></div></div></div>
 <p>It is preferred that packages are not renamed or moved, but if needed
   please follow these steps.
 </p>
 <div class="orderedlist"><ol class="orderedlist" type="1">
 <li class="listitem"><p>Make a copy of the directory somewhere else.</p></li>
 <li class="listitem">
 <p>Remove all CVS dirs.</p>
 <p>Alternatively to the first two steps you can also do:</p>
 <pre class="screen"><code class="prompt">%</code> <strong class="userinput"><code>cvs -d user@cvs.NetBSD.org:/cvsroot export -D today pkgsrc/category/package</code></strong></pre>
 <p>and use that for further work.</p>
 </li>
 <li class="listitem"><p>Fix <code class="varname">CATEGORIES</code> and any
 <code class="varname">DEPENDS</code> paths that just did <span class="quote">&#8220;<span class="quote">../package</span>&#8221;</span>
 instead of <span class="quote">&#8220;<span class="quote">../../category/package</span>&#8221;</span>.</p></li>
 <li class="listitem"><p>In the modified package's Makefile, consider setting
 <code class="varname">PREV_PKGPATH</code> to the previous category/package
 pathname.  The <code class="varname">PREV_PKGPATH</code> can be used by tools
 for doing an update using pkgsrc building; for example, it can
 search the <a class="citerefentry" href="https://netbsd.gw.com/cgi-bin/man-cgi?pkg_summary+5.i386+NetBSD-8.1"><span class="citerefentry"><span class="refentrytitle">pkg_summary</span>(5)</span></a> database for <code class="varname">PREV_PKGPATH</code>
 (if no <code class="varname">SUPERSEDES</code>) and then use the corresponding
 new <code class="varname">PKGPATH</code> for that moved package.  Note that
 it may have multiple matches, so the tool should also check on the
 <code class="varname">PKGBASE</code> too.  The <code class="varname">PREV_PKGPATH</code>
 probably has no value unless <code class="varname">SUPERSEDES</code> is not
 set, i.e.  <code class="varname">PKGBASE</code> stays the same.  </p></li>
 <li class="listitem"><p><span class="command"><strong>cvs import</strong></span> the modified package in the new
 place.</p></li>
 <li class="listitem">
 <p>Check if any package depends on it:
 </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>grep /package */*/Makefile* */*/buildlink*</code></strong></pre>
 </li>
 <li class="listitem"><p>Fix paths in packages from step 5 to point to new location.</p></li>
 <li class="listitem"><p><span class="command"><strong>cvs rm (-f)</strong></span> the package at the old location.</p></li>
 <li class="listitem"><p>Remove from <code class="filename">oldcategory/Makefile</code>.</p></li>
 <li class="listitem"><p>Add to <code class="filename">newcategory/Makefile</code>.</p></li>
 <li class="listitem">
 <p>Commit the changed and removed files:</p>
 <pre class="screen"><code class="prompt">%</code> <strong class="userinput"><code>cvs commit oldcategory/package oldcategory/Makefile newcategory/Makefile</code></strong></pre>
 <p>(and any packages from step 5, of course).</p>
 </li>
 </ol></div>
 </div>
 </div>
 <div class="chapter">
 <div class="titlepage"><div><div><h2 class="title">
 <a name="devfaq"></a>Chapter 24. Frequently Asked Questions</h2></div></div></div>
 <p>This section contains the answers to questions that may
 	arise when you are writing a package. If you don't find your
 	question answered here, first have a look in the other chapters,
 	and if you still don't have the answer, ask on the
 	<code class="literal">pkgsrc-users</code> mailing list.</p>
 <div class="qandaset">
-<a name="idm81678864"></a><dl>
+<a name="idm79478288"></a><dl>
 <dt>24.1. <a href="#devfaq.makeflags">What is the difference between
 	MAKEFLAGS, .MAKEFLAGS and
 	MAKE_FLAGS?</a>
 </dt>
 <dt>24.2. <a href="#devfaq.make">What is the difference between
 	MAKE, GMAKE and
 	MAKE_PROGRAM?</a>
 </dt>
 <dt>24.3. <a href="#devfaq.cc">What is the difference between
 	CC, PKG_CC and
 	PKGSRC_COMPILER?</a>
 </dt>
 <dt>24.4. <a href="#devfaq.bl3flags">What is the difference between
 	BUILDLINK_LDFLAGS,
 	BUILDLINK_LDADD and
 	BUILDLINK_LIBS?</a>
 </dt>
 <dt>24.5. <a href="#devfaq.bl3prefix">Why does make show-var
 	VARNAME=BUILDLINK_PREFIX.foo
 	say it's empty?</a>
 </dt>
 <dt>24.6. <a href="#devfaq.master_sites">What does
 	${MASTER_SITE_SOURCEFORGE:=package/} mean? I
 	don't understand the := inside
 	it.</a>
 </dt>
 <dt>24.7. <a href="#devfaq.mailinglists">Which mailing lists are there for package
 	developers?</a>
 </dt>
 <dt>24.8. <a href="#devfaq.documentation">Where is the pkgsrc
 	documentation?</a>
 </dt>
 <dt>24.9. <a href="#devfaq.too-much-time">I have a little time to kill.  What shall I
 do?</a>
 </dt>
 </dl>
 <table border="0" style="width: 100%;">
 <colgroup>
 <col align="left" width="1%">
 <col>
 </colgroup>
 <tbody>
 <tr class="question">
 <td align="left" valign="top">
-<a name="devfaq.makeflags"></a><a name="idm81678480"></a><p><b>24.1.</b></p>
+<a name="devfaq.makeflags"></a><a name="idm79477904"></a><p><b>24.1.</b></p>
 </td>
 <td align="left" valign="top"><p>What is the difference between
 	<code class="varname">MAKEFLAGS</code>, <code class="varname">.MAKEFLAGS</code> and
 	<code class="varname">MAKE_FLAGS</code>?</p></td>
 </tr>
 <tr class="answer">
 <td align="left" valign="top"></td>
 <td align="left" valign="top"><p><code class="varname">MAKEFLAGS</code> are the flags passed
 	to the pkgsrc-internal invocations of <a class="citerefentry" href="https://netbsd.gw.com/cgi-bin/man-cgi?make+1.i386+NetBSD-8.1"><span class="citerefentry"><span class="refentrytitle">make</span>(1)</span></a>, while
 	<code class="varname">MAKE_FLAGS</code> are the flags that are passed to
 	the <code class="varname">MAKE_PROGRAM</code> when building the
 	package. [FIXME: What is .MAKEFLAGS for?]</p></td>
 </tr>
 <tr class="question">
 <td align="left" valign="top">
-<a name="devfaq.make"></a><a name="idm81674512"></a><p><b>24.2.</b></p>
+<a name="devfaq.make"></a><a name="idm79473936"></a><p><b>24.2.</b></p>
 </td>
 <td align="left" valign="top"><p>What is the difference between
 	<code class="varname">MAKE</code>, <code class="varname">GMAKE</code> and
 	<code class="varname">MAKE_PROGRAM</code>?</p></td>
 </tr>
 <tr class="answer">
 <td align="left" valign="top"></td>
 <td align="left" valign="top"><p><code class="varname">MAKE</code> is the path to the
 	<a class="citerefentry" href="https://netbsd.gw.com/cgi-bin/man-cgi?make+1.i386+NetBSD-8.1"><span class="citerefentry"><span class="refentrytitle">make</span>(1)</span></a> program that is used in the pkgsrc
 	infrastructure. <code class="varname">GMAKE</code> is the path to GNU
 	Make, but you need to say <code class="varname">USE_TOOLS+=gmake</code> to
 	use that. <code class="varname">MAKE_PROGRAM</code> is the path to the
 	Make program that is used for building the
 	package.</p></td>
 </tr>
 <tr class="question">
 <td align="left" valign="top">
-<a name="devfaq.cc"></a><a name="idm81670032"></a><p><b>24.3.</b></p>
+<a name="devfaq.cc"></a><a name="idm79469456"></a><p><b>24.3.</b></p>
 </td>
 <td align="left" valign="top"><p>What is the difference between
 	<code class="varname">CC</code>, <code class="varname">PKG_CC</code> and
 	<code class="varname">PKGSRC_COMPILER</code>?</p></td>
 </tr>
 <tr class="answer">
 <td align="left" valign="top"></td>
 <td align="left" valign="top"><p><code class="varname">CC</code> is the path to the real C
 	compiler, which can be configured by the pkgsrc user.
 	<code class="varname">PKG_CC</code> is the path to the compiler wrapper.
 	<code class="varname">PKGSRC_COMPILER</code> is <span class="emphasis"><em>not</em></span> a
 	path to a compiler, but the type of compiler that should be
 	used. See <code class="filename">mk/compiler.mk</code> for more
 	information about the latter variable.</p></td>
 </tr>
 <tr class="question">
 <td align="left" valign="top">
-<a name="devfaq.bl3flags"></a><a name="idm81665936"></a><p><b>24.4.</b></p>
+<a name="devfaq.bl3flags"></a><a name="idm79465360"></a><p><b>24.4.</b></p>
 </td>
 <td align="left" valign="top"><p>What is the difference between
 	<code class="varname">BUILDLINK_LDFLAGS</code>,
 	<code class="varname">BUILDLINK_LDADD</code> and
 	<code class="varname">BUILDLINK_LIBS</code>?</p></td>
 </tr>
 <tr class="answer">
 <td align="left" valign="top"></td>
 <td align="left" valign="top"><p>[FIXME]</p></td>
 </tr>
 <tr class="question">
 <td align="left" valign="top">
-<a name="devfaq.bl3prefix"></a><a name="idm81663632"></a><p><b>24.5.</b></p>
+<a name="devfaq.bl3prefix"></a><a name="idm79463184"></a><p><b>24.5.</b></p>
 </td>
 <td align="left" valign="top"><p>Why does <span class="command"><strong>make show-var
 	VARNAME=BUILDLINK_PREFIX.<em class="replaceable"><code>foo</code></em></strong></span>
 	say it's empty?</p></td>
 </tr>
 <tr class="answer">
 <td align="left" valign="top"></td>
 <td align="left" valign="top"><p>For optimization reasons, some variables are only
 	available in the <span class="quote">&#8220;<span class="quote">wrapper</span>&#8221;</span> phase and later. To
 	<span class="quote">&#8220;<span class="quote">simulate</span>&#8221;</span> the wrapper phase, append
 	<span class="command"><strong>PKG_PHASE=wrapper</strong></span> to the above
 	command.</p></td>
 </tr>
 <tr class="question">
 <td align="left" valign="top">
-<a name="devfaq.master_sites"></a><a name="idm81660560"></a><p><b>24.6.</b></p>
+<a name="devfaq.master_sites"></a><a name="idm79451792"></a><p><b>24.6.</b></p>
 </td>
 <td align="left" valign="top"><p>What does
 	<code class="code">${MASTER_SITE_SOURCEFORGE:=package/}</code> mean? I
 	don't understand the <code class="code">:=</code> inside
 	it.</p></td>
 </tr>
 <tr class="answer">
 <td align="left" valign="top"></td>
 <td align="left" valign="top"><p>The <code class="code">:=</code> is not really an
 	assignment operator, although it looks like it.
 	Instead, it is a degenerate form of
 	<code class="code">${LIST:<em class="replaceable"><code>old_string</code></em>=<em class="replaceable"><code>new_string</code></em>}</code>,
 	which is documented in the <a class="citerefentry" href="https://netbsd.gw.com/cgi-bin/man-cgi?make+1.i386+NetBSD-8.1"><span class="citerefentry"><span class="refentrytitle">make</span>(1)</span></a> man page and which is
 	commonly used in the form <code class="code">${SRCS:.c=.o}</code>. In the
 	case of <code class="varname">MASTER_SITE_*</code>,
 	<em class="replaceable"><code>old_string</code></em> is the empty string and
 	<em class="replaceable"><code>new_string</code></em> is
 	<code class="code">package/</code>. That's where the
 	<code class="code">:</code> and the <code class="code">=</code> fall
 	together.</p></td>
 </tr>
 <tr class="question">
 <td align="left" valign="top">
-<a name="devfaq.mailinglists"></a><a name="idm81653648"></a><p><b>24.7.</b></p>
+<a name="devfaq.mailinglists"></a><a name="idm79444880"></a><p><b>24.7.</b></p>
 </td>
 <td align="left" valign="top"><p>Which mailing lists are there for package
 	developers?</p></td>
 </tr>
 <tr class="answer">
 <td align="left" valign="top"></td>
 <td align="left" valign="top"><div class="variablelist"><dl class="variablelist">
 <dt><span class="term"><a class="ulink" href="http://www.NetBSD.org/mailinglists/index.html#tech-pkg" target="_top">tech-pkg</a></span></dt>
 <dd><p>This is a list for technical discussions related
 	to pkgsrc development, e.g. soliciting feedback for changes to
 	pkgsrc infrastructure, proposed new features, questions related
 	to porting pkgsrc to a new platform, advice for maintaining a
 	package, patches that affect many packages, help requests moved
 	from pkgsrc-users when an infrastructure bug is found,
 	etc.</p></dd>
 <dt><span class="term"><a class="ulink" href="http://www.NetBSD.org/mailinglists/index.html#pkgsrc-bugs" target="_top">pkgsrc-bugs</a></span></dt>
 <dd><p>All bug reports in category "pkg" sent with
 	<a class="citerefentry" href="https://netbsd.gw.com/cgi-bin/man-cgi?send-pr+1.i386+NetBSD-8.1"><span class="citerefentry"><span class="refentrytitle">send-pr</span>(1)</span></a> appear here. Please do not report your bugs here
 	directly; use one of the other mailing
 	lists.</p></dd>
 </dl></div></td>
 </tr>
 <tr class="question">
 <td align="left" valign="top">
-<a name="devfaq.documentation"></a><a name="idm81649936"></a><p><b>24.8.</b></p>
+<a name="devfaq.documentation"></a><a name="idm79441168"></a><p><b>24.8.</b></p>
 </td>
 <td align="left" valign="top"><p>Where is the pkgsrc
 	documentation?</p></td>
 </tr>
 <tr class="answer">
 <td align="left" valign="top"></td>
 <td align="left" valign="top">
 <p>There are many places where you can find
 	documentation about pkgsrc:</p>
 <div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; ">
 <li class="listitem"><p>The pkgsrc guide (this document) is a collection
 	of chapters that explain large parts of pkgsrc, but some
 	chapters tend to be outdated. Which ones they are is hard to
 	say.</p></li>
 <li class="listitem"><p>On the mailing list archives (see <a class="ulink" href="http://mail-index.NetBSD.org/" target="_top">http://mail-index.NetBSD.org/</a>), you can find discussions
 	about certain features, announcements of new parts of the pkgsrc
 	infrastructure and sometimes even announcements that a certain
 	feature has been marked as obsolete. The benefit here is that
 	each message has a date appended to it.</p></li>
 <li class="listitem"><p>Many of the files in the
 	<code class="filename">mk/</code> directory start with a comment that
 	describes the purpose of the file and how it can be used by the
 	pkgsrc user and package authors. An easy way to find this
 	documentation is to run <span class="command"><strong>bmake
 	help</strong></span>.</p></li>
 <li class="listitem"><p>The CVS log messages are a rich source of
 	information, but they tend to be highly abbreviated, especially
 	for actions that occur often. Some contain a detailed
 	description of what has changed, but they are geared towards the
 	other pkgsrc developers, not towards an average pkgsrc user.
 	They also only document <span class="emphasis"><em>changes</em></span>, so if you
 	don't know what has been before, these messages may not be worth
 	too much to you.</p></li>
 <li class="listitem"><p>Some parts of pkgsrc are only <span class="quote">&#8220;<span class="quote">implicitly
 	documented</span>&#8221;</span>, that is the documentation exists only in the
 	mind of the developer who wrote the code. To get this
 	information, use the <span class="command"><strong>cvs annotate</strong></span> command
 	to see who has written it and ask on the
 	<code class="literal">tech-pkg</code> mailing list, so that others can
 	find your questions later (see above). To be sure that the
 	developer in charge reads the mail, you may CC him or
 	her.</p></li>
 </ul></div>
 </td>
 </tr>
 <tr class="question">
 <td align="left" valign="top">
-<a name="devfaq.too-much-time"></a><a name="idm81635216"></a><p><b>24.9.</b></p>
+<a name="devfaq.too-much-time"></a><a name="idm79434640"></a><p><b>24.9.</b></p>
 </td>
 <td align="left" valign="top"><p>I have a little time to kill.  What shall I
 do?</p></td>
 </tr>
 <tr class="answer">
 <td align="left" valign="top"></td>
 <td align="left" valign="top">
 <p>This is not really an FAQ yet, but here's the answer
 anyway.</p>
 <div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; ">
 <li class="listitem"><p>Run <span class="command"><strong>pkg_chk -N</strong></span> (from the
     <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> package).  It
     will tell you about newer versions of installed packages that are
     available, but not yet updated in pkgsrc.</p></li>
 <li class="listitem"><p>Browse <code class="filename">pkgsrc/doc/TODO</code>
     &mdash; it contains a list of suggested new packages and a list of
     cleanups and enhancements for pkgsrc that would be nice to
     have.</p></li>
 <li class="listitem"><p>Review packages for which review was requested on
     the <a class="ulink" href="http://www.NetBSD.org/mailinglists/index.html#tech-pkg" target="_top">tech-pkg</a>
     mailing list.</p></li>
 </ul></div>
 </td>
 </tr>
 </tbody>
 </table>
 </div>
 </div>
 <div class="chapter">
 <div class="titlepage"><div><div><h2 class="title">
 <a name="gnome"></a>Chapter 25. GNOME packaging and porting</h2></div></div></div>
 <div class="toc">
 <p><b>Table of Contents</b></p>
 <dl class="toc">
 <dt><span class="sect1"><a href="#meta-packages">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>
 </div>
 <p>Quoting <a class="ulink" href="http://www.gnome.org/" target="_top">GNOME's web
 site</a>:</p>
 <div class="blockquote"><blockquote class="blockquote"><p>The GNOME project provides two things: The GNOME desktop
   environment, an intuitive and attractive desktop for users, and the
   GNOME development platform, an extensive framework for building
   applications that integrate into the rest of the desktop.</p></blockquote></div>
 <p>pkgsrc provides a seamless way to automatically build and install
 a complete GNOME environment <span class="emphasis"><em>under many different
 platforms</em></span>.  We can say with confidence that pkgsrc is one of
 the most advanced build and packaging systems for GNOME due to its
 included technologies buildlink3, the wrappers and tools framework and
 automatic configuration file management.  Lots of efforts are put into
 achieving a completely clean deinstallation of installed software
 components.</p>
 <p>Given that pkgsrc is <a class="ulink" href="http://www.NetBSD.org/" target="_top">NetBSD</a>'s official packaging system,
 the above also means that great efforts are put into making GNOME work
 under this operating system.  Recently, <a class="ulink" href="http://www.dragonflybsd.org/" target="_top">DragonFly BSD</a> also adopted
 pkgsrc as its preferred packaging system, contributing lots of
 portability fixes to make GNOME build and install under it.</p>
 <p>This chapter is aimed at pkgsrc developers and other people
 interested in helping our GNOME porting and packaging efforts.  It
 provides instructions on how to manage the existing packages and some
 important information regarding their internals.</p>
 <div class="note" style="margin-left: 0.5in; margin-right: 0.5in;">
 <h3 class="title">We need your help!</h3>
 <p>Should you have some spare cycles to devote to NetBSD, pkgsrc
   and GNOME and are willing to learn new exciting stuff, please jump
   straight to the <a class="ulink" href="http://www.NetBSD.org/contrib/projects.html#gnome" target="_top">pending
   work</a> list!  There is still a long way to go to get a
   fully-functional GNOME desktop under NetBSD and we need your help to
   achieve it!</p>
 </div>
 <div class="sect1">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
 <a name="meta-packages"></a>25.1. Meta packages</h2></div></div></div>
 <p>pkgsrc includes three GNOME-related meta packages:</p>
 <div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; ">
 <li class="listitem"><p><a href="https://cdn.NetBSD.org/pub/pkgsrc/current/pkgsrc/meta-pkgs/gnome-base/README.html" target="_top"><code class="filename">meta-pkgs/gnome-base</code></a>: Provides
     the core GNOME desktop environment.  It only includes the necessary
     bits to get it to boot correctly, although it may lack important
     functionality for daily operation.  The idea behind this package is
     to let end users build their own configurations on top of this one,
     first installing this meta package to achieve a functional setup and
     then adding individual applications.</p></li>
 <li class="listitem"><p><a href="https://cdn.NetBSD.org/pub/pkgsrc/current/pkgsrc/meta-pkgs/gnome/README.html" target="_top"><code class="filename">meta-pkgs/gnome</code></a>: Provides a
     complete installation of the GNOME platform and desktop as defined
     by the GNOME project; this is based on the components distributed in
     the <code class="filename">platform/x.y/x.y.z/sources</code> and
     <code class="filename">desktop/x.y/x.y.z/sources</code> directories of the
     official FTP server.  Developer-only tools found in those
     directories are not installed unless required by some other
     component to work properly.  Similarly, packages from the bindings
     set (<code class="filename">bindings/x.y/x.y.z/sources</code>) are not pulled
     in unless required as a dependency for an end-user component.  This
     package "extends" <a href="https://cdn.NetBSD.org/pub/pkgsrc/current/pkgsrc/meta-pkgs/gnome-base/README.html" target="_top"><code class="filename">meta-pkgs/gnome-base</code></a>.</p></li>
 <li class="listitem"><p><a href="https://cdn.NetBSD.org/pub/pkgsrc/current/pkgsrc/meta-pkgs/gnome-devel/README.html" target="_top"><code class="filename">meta-pkgs/gnome-devel</code></a>:
     Installs all the tools required to build a GNOME component when
     fetched from the CVS repository.  These are required to let the
     <span class="command"><strong>autogen.sh</strong></span> scripts work appropriately.</p></li>
 </ul></div>
 <p>In all these packages, the <code class="varname">DEPENDS</code> lines are
 sorted in a way that eases updates: a package may depend on other
 packages listed before it but not on any listed after it.  It is very
 important to keep this order to ease updates so... <span class="emphasis"><em>do not
 change it to alphabetical sorting!</em></span></p>
 </div>
 <div class="sect1">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
 <a name="new-package"></a>25.2. Packaging a GNOME application</h2></div></div></div>
 <p>Almost all GNOME applications are written in C and use a common
 set of tools as their build system.  Things get different with the new
 bindings to other languages (such as Python), but the following will
 give you a general idea on the minimum required tools:</p>
 <div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; ">
 <li class="listitem">
 <p>Almost all GNOME applications use the GNU Autotools as their
     build system.  As a general rule you will need to tell this to your
     package:</p>
 <pre class="programlisting">
 GNU_CONFIGURE=yes
 USE_LIBTOOL=yes
 USE_TOOLS+=gmake
 </pre>
 </li>
 <li class="listitem">
 <p>If the package uses pkg-config to detect dependencies, add this
     tool to the list of required utilities:</p>
 <pre class="programlisting">
 USE_TOOLS+=pkg-config
 </pre>
 <p>Also use <a href="https://cdn.NetBSD.org/pub/pkgsrc/current/pkgsrc/pkgtools/verifypc/README.html" target="_top"><code class="filename">pkgtools/verifypc</code></a> at
     the end of the build process to ensure that you did not miss to
     specify any dependency in your package and that the version
     requirements are all correct.</p>
 </li>
 <li class="listitem"><p>If the package uses intltool, be sure to add
     <code class="literal">intltool</code> to the <code class="varname">USE_TOOLS</code>
     to handle dependencies and to force the package to use the latest
     available version.</p></li>
 <li class="listitem">
 <p>If the package uses gtk-doc (a documentation generation
     utility), do <span class="emphasis"><em>not</em></span> add a dependency on it.  The
     tool is rather big and the distfile should come with pregenerated
     documentation anyway; if it does not, it is a bug that you ought to
     report.  For such packages you should disable gtk-doc (unless it is
     the default):</p>
 <pre class="programlisting">
 CONFIGURE_ARGS+=--disable-gtk-doc
 </pre>
 <p>The default location of installed HTML files
     (<code class="filename">share/gtk-doc/&lt;package-name&gt;</code>) is correct
     and should not be changed unless the package insists on installing
     them somewhere else.  Otherwise programs as
     <span class="command"><strong>devhelp</strong></span> will not be able to open them.  You can
     do that with an entry similar to:</p>
 <pre class="programlisting">
 CONFIGURE_ARGS+=--with-html-dir=${PREFIX}/share/gtk-doc/...
 </pre>
 </li>
 </ul></div>
 <p>GNOME uses multiple <span class="emphasis"><em>shared</em></span> directories and
 files under the installation prefix to maintain databases.  In this
 context, shared means that those exact same directories and files are
 used among several different packages, leading to conflicts in the
 <code class="filename">PLIST</code>.  pkgsrc currently includes functionality to
 handle the most common cases, so you have to forget about using
 <code class="literal">@unexec ${RMDIR}</code> lines in your file lists and
 omitting shared files from them.  If you find yourself doing those,
 <span class="emphasis"><em>your package is most likely incorrect</em></span>.</p>
 <p>The following table lists the common situations that result in
 using shared directories or files.  For each of them, the appropriate
 solution is given.  After applying the solution be sure to
 <span class="emphasis"><em>regenerate the package's file list</em></span> with
 <span class="command"><strong>make print-PLIST</strong></span> and ensure it is correct.</p>
 <div class="table">
 <a name="plist-handling"></a><p class="title"><b>Table 25.1. PLIST handling for GNOME packages</b></p>
 <div class="table-contents"><table class="table" summary="PLIST handling for GNOME packages" border="1">
 <colgroup>
 <col>
 <col>
 </colgroup>
 <thead><tr>
 <th>If the package...</th>
 <th>Then...</th>
 </tr></thead>
 <tbody>
 <tr>
 <td>Installs OMF files under <code class="filename">share/omf</code>.</td>
 <td>See <a class="xref" href="#scrollkeeper-data-files" title="21.6.10. Packages installing scrollkeeper/rarian data files">Section 21.6.10, &#8220;Packages installing scrollkeeper/rarian data files&#8221;</a>.</td>
 </tr>
 <tr>
 <td>Installs icons under the
         <code class="filename">share/icons/hicolor</code> hierarchy or updates
         <code class="filename">share/icons/hicolor/icon-theme.cache</code>.</td>
 <td>See <a class="xref" href="#hicolor-theme" title="21.6.19. Packages installing hicolor theme icons">Section 21.6.19, &#8220;Packages installing hicolor theme icons&#8221;</a>.</td>
 </tr>
 <tr>
 <td>Installs files under
         <code class="filename">share/mime/packages</code>.</td>
 <td>See <a class="xref" href="#mime-database" title="21.6.14. Packages installing extensions to the MIME database">Section 21.6.14, &#8220;Packages installing extensions to the MIME database&#8221;</a>.</td>
 </tr>
 <tr>
 <td>Installs <code class="filename">.desktop</code> files under
         <code class="filename">share/applications</code> and these include MIME
         information.</td>
 <td>See <a class="xref" href="#desktop-files" title="21.6.20. Packages installing desktop files">Section 21.6.20, &#8220;Packages installing desktop files&#8221;</a>.</td>
 </tr>
 </tbody>
 </table></div>
 </div>
 <br class="table-break">
 </div>
 <div class="sect1">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
 <a name="full-update"></a>25.3. Updating GNOME to a newer version</h2></div></div></div>
 <p>When seeing GNOME as a whole, there are two kinds of
 updates:</p>
 <div class="variablelist"><dl class="variablelist">
 <dt><span class="term">Major update</span></dt>
 <dd>
 <p>Given that there is still a very long way for GNOME 3 (if it
       ever appears), we consider a major update one that goes from a
       <code class="literal">2.X</code> version to a <code class="literal">2.Y</code> one,
       where <code class="literal">Y</code> is even and greater than
       <code class="literal">X</code>.  These are hard to achieve because they
       introduce lots of changes in the components' code and almost all
       GNOME distfiles are updated to newer versions.  Some of them can
       even break API and ABI compatibility with the previous major
       version series.  As a result, the update needs to be done all at
       once to minimize breakage.</p>
 <p>A major update typically consists of around 80 package
       updates and the addition of some new ones.</p>
 </dd>
 <dt><span class="term">Minor update</span></dt>
 <dd>
 <p>We consider a minor update one that goes from a
       <code class="literal">2.A.X</code> version to a <code class="literal">2.A.Y</code>
       one where <code class="literal">Y</code> is greater than
       <code class="literal">X</code>.  These are easy to achieve because they do
       not update all GNOME components, can be done in an incremental way
       and do not break API nor ABI compatibility.</p>
 <p>A minor update typically consists of around 50 package
       updates, although the numbers here may vary a lot.</p>
 </dd>
 </dl></div>
 <p>In order to update the GNOME components in pkgsrc to a new stable
 release (either major or minor), the following steps should be
 followed:</p>
 <div class="orderedlist"><ol class="orderedlist" type="1">
 <li class="listitem">
 <p>Get a list of all the tarballs that form the new release by
     using the following commands.  These will leave the full list of the
     components' distfiles into the <code class="filename">list.txt</code>
     file:</p>
 <pre class="screen"><code class="prompt">%</code> <strong class="userinput"><code>echo ls "*.tar.bz2" | \
     ftp -V ftp://ftp.gnome.org/pub/gnome/platform/x.y/x.y.z/sources/ | \
     awk '{ print $9 }' &gt;list.txt</code></strong>
 <code class="prompt">%</code> <strong class="userinput"><code>echo ls "*.tar.bz2" | \
     ftp -V ftp://ftp.gnome.org/pub/gnome/desktop/x.y/x.y.z/sources/ | \
     awk '{ print $9 }' &gt;&gt;list.txt</code></strong></pre>
 </li>
 <li class="listitem"><p>Open each meta package's <code class="filename">Makefile</code> and
     bump their version to the release you are updating them to.  The
     three meta packages should be always consistent with versioning.
     Obviously remove any <code class="varname">PKGREVISION</code>s that might be
     in them.</p></li>
 <li class="listitem">
 <p>For each meta package, update all its
     <code class="varname">DEPENDS</code> lines to match the latest versions as
     shown by the above commands.  Do <span class="emphasis"><em>not</em></span> list any
     newer version (even if found in the FTP) because the meta packages
     are supposed to list the exact versions that form a specific GNOME
     release.  Exceptions are permitted here if a newer version solves a
     serious issue in the overall desktop experience; these typically
     come in the form of a revision bump in pkgsrc, not in newer versions
     from the developers.</p>
 <p>Packages not listed in the <code class="filename">list.txt</code> file
     should be updated to the latest version available (if found in
     pkgsrc).  This is the case, for example, of the dependencies on the
     GNU Autotools in the <a href="https://cdn.NetBSD.org/pub/pkgsrc/current/pkgsrc/meta-pkgs/gnome-devel/README.html" target="_top"><code class="filename">meta-pkgs/gnome-devel</code></a> meta package.</p>
 </li>
 <li class="listitem">
 <p>Generate a patch from the modified meta packages and extract the
     list of "new" lines.  This will provide you an outline on what
     packages need to be updated in pkgsrc and in what order:</p>
 <pre class="screen"><code class="prompt">%</code> <strong class="userinput"><code>cvs diff -u gnome-devel gnome-base gnome | grep '^+D' &gt;todo.txt</code></strong></pre>
 </li>
 <li class="listitem"><p>For major desktop updates it is recommended to zap all your
     installed packages and start over from scratch at this point.</p></li>
 <li class="listitem"><p>Now comes the longest step by far: iterate over the contents
     of <code class="filename">todo.txt</code> and update the packages listed in
     it in order.  For major desktop updates none of these should be
     committed until the entire set is completed because there are chances
     of breaking not-yet-updated packages.</p></li>
 <li class="listitem"><p>Once the packages are up to date and working, commit them to
     the tree one by one with appropriate log messages.  At the end,
     commit the three meta package updates and all the corresponding
     changes to the <code class="filename">doc/CHANGES-&lt;YEAR&gt;</code> and
     <a href="http://cvsweb.NetBSD.org/bsdweb.cgi/pkgsrc/doc/TODO?rev=HEAD&amp;content-type=text/x-cvsweb-markup" target="_top"><code class="filename">pkgsrc/doc/TODO</code></a> files.</p></li>
 </ol></div>
 </div>
 <div class="sect1">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
 <a name="patching"></a>25.4. Patching guidelines</h2></div></div></div>
 <p>GNOME is a very big component in pkgsrc which approaches 100
 packages.  Please, it is very important that you always, always,
 <span class="strong"><strong>always</strong></span> feed back any portability
 fixes you do to a GNOME package to the mainstream developers (see <a class="xref" href="#components.patches.feedback" title="13.3.5. Feedback to the author">Section 13.3.5, &#8220;Feedback to the author&#8221;</a>).  This is the only way to get
 their attention on portability issues and to ensure that future versions
 can be built out-of-the box on NetBSD.  The less custom patches in
 pkgsrc, the easier further updates are.  Those developers in charge of
 issuing major GNOME updates will be grateful if you do that.</p>
 <p>The most common places to report bugs are the <a class="ulink" href="http://bugzilla.gnome.org/" target="_top">GNOME's Bugzilla</a> and the <a class="ulink" href="http://bugzilla.freedesktop.org/" target="_top">freedesktop.org's
 Bugzilla</a>.  Not all components use these to track bugs, but most
 of them do.  Do not be short on your reports: always provide detailed
 explanations of the current failure, how it can be improved to achieve
 maximum portability and, if at all possible, provide a patch against CVS
 head.  The more verbose you are, the higher chances of your patch being
 accepted.</p>
 <p>Also, please avoid using preprocessor magic to fix portability
 issues.  While the FreeBSD GNOME people are doing a great job in porting
 GNOME to their operating system, the official GNOME sources are now
 plagued by conditionals that check for <code class="varname">__FreeBSD__</code>
 and similar macros.  This hurts portability.  Please see our patching
 guidelines (<a class="xref" href="#components.patches.guidelines" title="13.3.4. Patching guidelines">Section 13.3.4, &#8220;Patching guidelines&#8221;</a>) for more
 details.</p>
 </div>
 </div>
 </div>
 <div class="part">
 <div class="titlepage"><div><div><h1 class="title">
 <a name="infrastructure"></a>Part III. The pkgsrc infrastructure internals</h1></div></div></div>
 <div class="partintro">
 <div></div>
 <p>This part of the guide deals with everything
 	from the infrastructure that is behind the interfaces described
 	in the developer's guide. A casual package maintainer should not
 	need anything from this part.</p>
 <div class="toc">
 <p><b>Table of Contents</b></p>
 <dl class="toc">
 <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>
 </div>
 </div>
 <div class="chapter">
 <div class="titlepage"><div><div><h2 class="title">
 <a name="infr.design"></a>Chapter 26. Design of the pkgsrc infrastructure</h2></div></div></div>
 <div class="toc">
 <p><b>Table of Contents</b></p>
 <dl class="toc">
 <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>
 </div>
 <p>The pkgsrc infrastructure consists of many small Makefile
 	fragments. Each such fragment needs a properly specified
 	interface. This chapter explains how such an interface looks
 	like.</p>
 <div class="sect1">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
 <a name="infr.vardef"></a>26.1. The meaning of variable definitions</h2></div></div></div>
 <p>Whenever a variable is defined in the pkgsrc
 	infrastructure, the location and the way of definition provide
 	much information about the intended use of that variable.
 	Additionally, more documentation may be found in a header
 	comment or in this pkgsrc guide.</p>
 <p>A special file is
 	<code class="filename">mk/defaults/mk.conf</code>, which lists all
 	variables that are intended to be user-defined. They are either
 	defined using the <code class="literal">?=</code> operator or they are
 	left undefined because defining them to anything would
 	effectively mean <span class="quote">&#8220;<span class="quote">yes</span>&#8221;</span>. All these variables may be
 	overridden by the pkgsrc user in the <code class="varname">MAKECONF</code>
 	file.</p>
 <p>Outside this file, the following conventions apply:
 	Variables that are defined using the <code class="literal">?=</code>
 	operator may be overridden by a package.</p>
 <p>Variables that are defined using the <code class="literal">=</code>
 	operator may be used read-only at run-time.</p>
 <p>Variables whose name starts with an underscore must not be
 	accessed outside the pkgsrc infrastructure at all. They may
 	change without further notice.</p>
 <div class="note" style="margin-left: 0.5in; margin-right: 0.5in;">
 <h3 class="title">Note</h3>
 <p>These conventions are currently not applied
 	consistently to the complete pkgsrc
 	infrastructure.</p>
 </div>
 </div>
 <div class="sect1">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
 <a name="infr.vardef.problems"></a>26.2. Avoiding problems before they arise</h2></div></div></div>
 <p>All variables that contain lists of things should default
 	to being empty. Two examples that do not follow this rule are
 	<code class="varname">USE_LANGUAGES</code> and
 	<code class="varname">DISTFILES</code>. These variables cannot simply be
 	modified using the <code class="literal">+=</code> operator in package
 	<code class="filename">Makefile</code>s (or other files included by
 	them), since there is no guarantee whether the variable is
 	already set or not, and what its value is. In the case of
 	<code class="varname">DISTFILES</code>, the packages <span class="quote">&#8220;<span class="quote">know</span>&#8221;</span>
 	the default value and just define it as in the following
 	example.</p>
 <pre class="programlisting">
 DISTFILES=      ${DISTNAME}${EXTRACT_SUFX} additional-files.tar.gz
 </pre>
 <p>Because of the selection of this default value, the same
 	value appears in many package Makefiles. Similarly for
 	<code class="varname">USE_LANGUAGES</code>, but in this case the default
 	value (<span class="quote">&#8220;<span class="quote"><code class="literal">c</code></span>&#8221;</span>) is so short that it
 	doesn't stand out. Nevertheless it is mentioned in many
 	files.</p>
 </div>
 <div class="sect1">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
 <a name="infr.var"></a>26.3. Variable evaluation</h2></div></div></div>
 <div class="sect2">
 <div class="titlepage"><div><div><h3 class="title">
 <a name="infr.var.load"></a>26.3.1. At load time</h3></div></div></div>
 <p>Variable evaluation takes place either at load time or at
 	runtime, depending on the context in which they occur. The
 	contexts where variables are evaluated at load time are:</p>
 <div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; ">
 <li class="listitem"><p>The right hand side of the <code class="literal">:=</code>
 	and <code class="literal">!=</code> operators,</p></li>
 <li class="listitem"><p>Make directives like <code class="literal">.if</code> or
 	<code class="literal">.for</code>,</p></li>
 <li class="listitem"><p>Dependency lines.</p></li>
 </ul></div>
 <p>A special exception are references to the iteration
 	variables of <code class="literal">.for</code> loops, which are expanded
 	inline, no matter in which context they appear.</p>
 <p>As the values of variables may change during load time,
 	care must be taken not to evaluate them by accident. Typical
 	examples for variables that should not be evaluated at load time
 	are <code class="varname">DEPENDS</code> and
 	<code class="varname">CONFIGURE_ARGS</code>. To make the effect more
 	clear, here is an example:</p>
 <pre class="programlisting">
 CONFIGURE_ARGS=         # none
 CFLAGS=                 -O
 CONFIGURE_ARGS+=        CFLAGS=${CFLAGS:Q}
 CONFIGURE_ARGS:=        ${CONFIGURE_ARGS}
 CFLAGS+=                -Wall
 </pre>
 <p>This code shows how the use of the <code class="literal">:=</code>
 	operator can quickly lead to unexpected results. The first
 	paragraph is fairly common code. The second paragraph evaluates
 	the <code class="varname">CONFIGURE_ARGS</code> variable, which results in
 	<code class="literal">CFLAGS=-O</code>. In the third paragraph, the
 	<code class="literal">-Wall</code> is appended to the
 	<code class="varname">CFLAGS</code>, but this addition will not appear in
 	<code class="varname">CONFIGURE_ARGS</code>. In actual code, the three
 	paragraphs from above typically occur in completely unrelated
 	files.</p>
 </div>
 <div class="sect2">
 <div class="titlepage"><div><div><h3 class="title">
 <a name="infr.var.run"></a>26.3.2. At runtime</h3></div></div></div>
 <p>After all the files have been loaded, the values of the
 	variables cannot be changed anymore. Variables that are used in
 	the shell commands are expanded at this point.</p>
 </div>
 </div>
 <div class="sect1">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
 <a name="infr.varspec"></a>26.4. How can variables be specified?</h2></div></div></div>
 <p>There are many ways in which the definition and use of a
 	variable can be restricted in order to detect bugs and violations
 	of the (mostly unwritten) policies. A package can be checked with
 	<code class="literal">pkglint -Wall</code> to see whether it meets these
 	rules.</p>
 </div>
 <div class="sect1">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
 <a name="infr.design.intf"></a>26.5. Designing interfaces for Makefile fragments</h2></div></div></div>
 <p>Most of the <code class="filename">.mk</code> files fall into one
 	of the following classes. Cases where a file falls into more
 	than one class should be avoided as it often leads to subtle
 	bugs.</p>
 <div class="sect2">
 <div class="titlepage"><div><div><h3 class="title">
 <a name="infr.design.intf.proc"></a>26.5.1. Procedures with parameters</h3></div></div></div>
 <p>In a traditional imperative programming language some of
 	the <code class="filename">.mk</code> files could be described as
 	procedures. They take some input parameters and&mdash;after
 	inclusion&mdash;provide a result in output parameters. Since all
 	variables in <code class="filename">Makefile</code>s have global scope
 	care must be taken not to use parameter names that have already
 	another meaning. For example, <code class="varname">PKGNAME</code> is a
 	bad choice for a parameter name.</p>
 <p>Procedures are completely evaluated at preprocessing time.
 	That is, when calling a procedure all input parameters must be
 	completely resolvable. For example,
 	<code class="varname">CONFIGURE_ARGS</code> should never be an input
 	parameter since it is very likely that further text will be
 	added after calling the procedure, which would effectively apply
 	the procedure to only a part of the variable. Also, references
 	to other variables will be modified after calling the
 	procedure.</p>
 <p>A procedure can declare its output parameters either as
 	suitable for use in preprocessing directives or as only
 	available at runtime. The latter alternative is for variables
 	that contain references to other runtime variables.</p>
 <p>Procedures shall be written such that it is possible to
 	call the procedure more than once. That is, the file must not
 	contain multiple-inclusion guards.</p>
 <p>Examples for procedures are
 	<code class="filename">mk/bsd.options.mk</code> and
 	<code class="filename">mk/buildlink3/bsd.builtin.mk</code>. To express
 	that the parameters are evaluated at load time, they should be
 	assigned using the <code class="literal">:=</code> operator, which should
 	be used only for this purpose.</p>
 </div>
 <div class="sect2">
 <div class="titlepage"><div><div><h3 class="title">
 <a name="infr.design.intf.action"></a>26.5.2. Actions taken on behalf of parameters</h3></div></div></div>
 <p>Action files take some input parameters and may define
 	runtime variables. They shall not define loadtime variables.
 	There are action files that are included implicitly by the
 	pkgsrc infrastructure, while other must be included
 	explicitly.</p>
 <p>An example for action files is
 	<code class="filename">mk/subst.mk</code>.</p>
 </div>
 </div>
 <div class="sect1">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
 <a name="infr.order"></a>26.6. The order in which files are loaded</h2></div></div></div>
 <p>Package <code class="filename">Makefile</code>s usually consist of
 	a set of variable definitions, and include the file
 	<code class="filename">../../mk/bsd.pkg.mk</code> in the very last line.
 	Before that, they may also include various other
 	<code class="filename">*.mk</code> files if they need to query the
 	availability of certain features like the type of compiler or
 	the X11 implementation. Due to the heavy use of preprocessor
 	directives like <code class="literal">.if</code> and
 	<code class="literal">.for</code>, the order in which the files are loaded
 	matters.</p>
 <p>This section describes at which point the various files
 	are loaded and gives reasons for that order.</p>
 <div class="sect2">
 <div class="titlepage"><div><div><h3 class="title">
 <a name="infr.order.prefs"></a>26.6.1. The order in <code class="filename">bsd.prefs.mk</code>
 </h3></div></div></div>
 <p>The very first action in <code class="filename">bsd.prefs.mk</code>
 	is to define some essential variables like
 	<code class="varname">OPSYS</code>, <code class="varname">OS_VERSION</code> and
 	<code class="varname">MACHINE_ARCH</code>.</p>
 <p>Then, the user settings are loaded from the file specified
 	in <code class="varname">MAKECONF</code>, which is usually <a class="link" href="#mk.conf"><code class="filename">mk.conf</code></a>.
 	After that, those variables
 	that have not been overridden by the user are loaded from
 	<code class="filename">mk/defaults/mk.conf</code>.</p>
 <p>After the user settings, the system settings and platform
 	settings are loaded, which may override the user
 	settings.</p>
 <p>Then, the tool definitions are loaded. The tool wrappers
 	are not yet in effect. This only happens when building a
 	package, so the proper variables must be used instead of the
 	direct tool names.</p>
 <p>As the last steps, some essential variables from the
 	wrapper and the package system flavor are loaded, as well as the
 	variables that have been cached in earlier phases of a package
 	build.</p>
 </div>
 <div class="sect2">
 <div class="titlepage"><div><div><h3 class="title">
 <a name="infr.order.pkg"></a>26.6.2. The order in <code class="filename">bsd.pkg.mk</code>
 </h3></div></div></div>
 <p>First, <code class="filename">bsd.prefs.mk</code> is loaded.</p>
 <p>Then, the various <code class="filename">*-vars.mk</code> files are
 	loaded, which fill default values for those variables that have
 	not been defined by the package. These variables may later
 	be used even in unrelated files.</p>
 <p>Then, the file <code class="filename">bsd.pkg.error.mk</code>
 	provides the target <code class="literal">error-check</code> that is added
 	as a special dependency to all other targets that use
 	<code class="varname">DELAYED_ERROR_MSG</code> or
 	<code class="varname">DELAYED_WARNING_MSG</code>.</p>
 <p>Then, the package-specific hacks from
 	<code class="filename">hacks.mk</code> are included.</p>
 <p>Then, various other files follow. Most of them don't have
 	any dependencies on what they need to have included before or
 	after them, though some do.</p>
 <p>The code to check <code class="varname">PKG_FAIL_REASON</code> and
 	<code class="varname">PKG_SKIP_REASON</code> is then executed, which
 	restricts the use of these variables to all the files that have
 	been included before. Appearances in later files will be
 	silently ignored.</p>
 <p>Then, the files for the main targets are included, in the
 	order of later execution, though the actual order should not
 	matter.</p>
 <p>At last, some more files are included that don't set any
 	interesting variables but rather just define make targets to be
 	executed.</p>
 </div>
 </div>
 </div>
 <div class="chapter">
 <div class="titlepage"><div><div><h2 class="title">
 <a name="regression"></a>Chapter 27. Regression tests</h2></div></div></div>
 <div class="toc">
 <p><b>Table of Contents</b></p>
 <dl class="toc">
 <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>
 </div>
 <p>The pkgsrc infrastructure consists of a large codebase,
 	and there are many corners where every little bit of a file is
 	well thought out, making pkgsrc likely to fail as soon as
 	anything is changed near those parts. To prevent most changes
 	from breaking anything, a suite of regression tests should go
 	along with every important part of the pkgsrc infrastructure.
 	This chapter describes how regression tests work in pkgsrc and
 	how you can add new tests.</p>
 <div class="sect1">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
 <a name="regression.run"></a>27.1. Running the regression tests</h2></div></div></div>
 <p>You first need to install the <a href="https://cdn.NetBSD.org/pub/pkgsrc/current/pkgsrc/pkgtools/pkg_regress/README.html" target="_top"><code class="filename">pkgtools/pkg_regress</code></a> package, which
 	provides the <span class="command"><strong>pkg_regress</strong></span> command. Then you
 	can simply run that command, which will run all tests in the
 	<code class="filename">regress/</code> directory.</p>
 </div>
 <div class="sect1">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
 <a name="regression.new"></a>27.2. Adding a new regression test</h2></div></div></div>
 <p>Every directory in the <code class="filename">regress/</code>
 	directory that contains a file called <code class="filename">spec</code>
 	is considered a regression test. This file is a shell program
 	that is included by the <span class="command"><strong>pkg_regress</strong></span> command.
 	The following functions can be overridden to suit your
 	needs.</p>
 <div class="sect2">
 <div class="titlepage"><div><div><h3 class="title">
 <a name="regression.fun.override"></a>27.2.1. Overridable functions</h3></div></div></div>
 <p>These functions do not take any parameters. Although they
 	are called in <span class="quote">&#8220;<span class="quote">set -e</span>&#8221;</span> mode, they don't stop at the
 	first failing command. See <a class="ulink" href="http://stackoverflow.com/q/4072984" target="_top">this Stack Overflow
 	question</a> for details.</p>
 <div class="variablelist"><dl class="variablelist">
 <dt><span class="term"><code class="varname">do_setup</code></span></dt>
 <dd><p>This function prepares the environment for the
 	test. By default it does nothing.</p></dd>
 <dt><span class="term"><code class="varname">do_test</code></span></dt>
 <dd>
 <p>This function runs the actual test. By default,
 	it calls <code class="varname">TEST_MAKE</code> with the arguments
 	<code class="varname">MAKEARGS_TEST</code> and writes its output including
 	error messages into the file
 	<code class="varname">TEST_OUTFILE</code>.</p>
 <p>When defining this function, make sure that all output that
 	needs to be checked is written to the correct output file.
 	Example:</p>
 <pre class="programlisting">
 do_test() {
         echo "Example output"
 } 1&gt;$TEST_OUTFILE 2&gt;&amp;1
 </pre>
 </dd>
 <dt><span class="term"><code class="varname">check_result</code></span></dt>
 <dd>
 <p>This function is run after the test and is
 	typically used to compare the actual output from the one that is
 	expected. It can make use of the various helper functions from
 	the next section. Example:</p>
 <pre class="programlisting">
 check_result() {
         exit_status 0
         output_require "Example"
         output_require "^[[:alpha:]+[[:space:]][[:alpha:]]{6}$"
         output_prohibit "no such file or directory"
         regress_fail "expected $expected but got $actual for input $input"
+}
 </pre>
 </dd>
 <dt><span class="term"><code class="varname">do_cleanup</code></span></dt>
 <dd><p>This function cleans everything up after the
 	test has been run. By default it does nothing.</p></dd>
 </dl></div>
 </div>
 <div class="sect2">
 <div class="titlepage"><div><div><h3 class="title">
 <a name="regression.fun.helper"></a>27.2.2. Helper functions</h3></div></div></div>
 <div class="variablelist"><dl class="variablelist">
 <dt><span class="term"><code class="varname">regress_fail <em class="replaceable"><code>message...</code></em></code></span></dt>
 <dd><p>This function makes the test fail with the given error message.</p></dd>
 <dt><span class="term"><code class="varname">exit_status expected</code></span></dt>
 <dd><p>This function compares the exitcode of the
 	<span class="command"><strong>do_test</strong></span> function with its first parameter.
 	If they differ, the test will fail.</p></dd>
 <dt><span class="term"><code class="varname">output_require regex...</code></span></dt>
 <dd>
 <p>This function checks for each of its parameters
 	if the output from <span class="command"><strong>do_test</strong></span> matches the
 	extended regular expression. If it does not, the test will
 	fail. Example:</p>
 <pre class="programlisting">
 output_require "looks fine"
 output_require "^[[:alpha:]+[[:space:]][[:alpha:]]{6}$"
 </pre>
 </dd>
 <dt><span class="term"><code class="varname">output_prohibit(regex...)</code></span></dt>
 <dd><p>This function checks for each of its parameters
 	if the output from <span class="command"><strong>do_test()</strong></span> does
 	<span class="emphasis"><em>not</em></span> match the extended regular expression.
 	If any of the regular expressions matches, the test will
 	fail.</p></dd>
 </dl></div>
 </div>
 </div>
 </div>
 <div class="chapter">
 <div class="titlepage"><div><div><h2 class="title">
 <a name="porting"></a>Chapter 28. Porting pkgsrc</h2></div></div></div>
 <div class="toc">
 <p><b>Table of Contents</b></p>
 <dl class="toc"><dt><span class="sect1"><a href="#porting.opsys">28.1. Porting pkgsrc to a new operating system</a></span></dt></dl>
 </div>
 <p>The pkgsrc system has already been ported to many
 	operating systems, hardware architectures and compilers. This
 	chapter explains the necessary steps to make pkgsrc even more
 	portable.</p>
 <div class="sect1">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
 <a name="porting.opsys"></a>28.1. Porting pkgsrc to a new operating system</h2></div></div></div>
 <p>To port pkgsrc to a new operating system (called
 	<code class="literal">MyOS</code> in this example), you need to touch the
 	following files:</p>
 <div class="variablelist"><dl class="variablelist">
 <dt><span class="term"><code class="filename">pkgtools/bootstrap-mk-files/files/mods/<em class="replaceable"><code>MyOS</code></em>.sys.mk</code></span></dt>
 <dd><p>This file contains some basic definitions, for
 	example the name of the C
 	compiler.</p></dd>
 <dt><span class="term"><code class="filename">mk/bsd.prefs.mk</code></span></dt>
 <dd><p>Insert code that defines the variables
 	<code class="varname">OPSYS</code>, <code class="varname">OS_VERSION</code>,
 	<code class="varname">LOWER_OS_VERSION</code>,
 	<code class="varname">LOWER_VENDOR</code>,
 	<code class="varname">MACHINE_ARCH</code>, <code class="varname">OBJECT_FMT</code>,
 	<code class="varname">APPEND_ELF</code>, and the other variables that
 	appear in this file.</p></dd>
 <dt><span class="term"><code class="filename">mk/platform/<em class="replaceable"><code>MyOS</code></em>.mk</code></span></dt>
 <dd><p>This file contains the platform-specific
 	definitions that are used by pkgsrc. Start by copying one of the
 	other files and edit it to your
 	needs.</p></dd>
 <dt><span class="term"><code class="filename">mk/tools/tools.<em class="replaceable"><code>MyOS</code></em>.mk</code></span></dt>
 <dd><p>This file defines the paths to all the tools
 	that are needed by one or the other package in pkgsrc, as well
 	as by pkgsrc itself. Find out where these tools are on your
 	platform and add them.</p></dd>
 </dl></div>
 <p>Now, you should be able to build some basic packages, like
 	<a href="https://cdn.NetBSD.org/pub/pkgsrc/current/pkgsrc/lang/perl5/README.html" target="_top"><code class="filename">lang/perl5</code></a>, <a href="https://cdn.NetBSD.org/pub/pkgsrc/current/pkgsrc/shells/bash/README.html" target="_top"><code class="filename">shells/bash</code></a>.</p>
 </div>
 </div>
 </div>
 <div class="appendix">
 <div class="titlepage"><div><div><h1 class="title">
 <a name="examples"></a>Appendix A. A simple example package: bison</h1></div></div></div>
 <div class="toc">
 <p><b>Table of Contents</b></p>
 <dl class="toc">
 <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 <span class="command"><strong>pkglint</strong></span></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>
 </div>
 <p>We checked to find a piece of software that wasn't in the packages
     collection, and picked GNU bison. Quite why someone would want to have
     <span class="command"><strong>bison</strong></span> when Berkeley <span class="command"><strong>yacc</strong></span> is already
     present in the tree is beyond us, but it's useful for the purposes of
     this exercise.</p>
 <div class="sect1">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
 <a name="example-files"></a>A.1. files</h2></div></div></div>
 <div class="sect2">
 <div class="titlepage"><div><div><h3 class="title">
 <a name="example-Makefile"></a>A.1.1. Makefile</h3></div></div></div>
 <pre class="programlisting">
 # $NetBSD$
+#
 DISTNAME=       bison-1.25
 CATEGORIES=     devel
-MASTER_SITES=   ${MASTER_SITE_GNU}
+MASTER_SITES=   ${MASTER_SITE_GNU:=bison/}
 MAINTAINER=     pkgsrc-users@NetBSD.org
 HOMEPAGE=       http://www.gnu.org/software/bison/bison.html
 COMMENT=        GNU yacc clone
 GNU_CONFIGURE=  yes
 INFO_FILES=     yes
 .include "../../mk/bsd.pkg.mk"
 </pre>
 </div>
 <div class="sect2">
 <div class="titlepage"><div><div><h3 class="title">
 <a name="example-descr"></a>A.1.2. DESCR</h3></div></div></div>
 <pre class="programlisting">
 GNU version of yacc.  Can make re-entrant parsers, and numerous other
 improvements.  Why you would want this when Berkeley <a class="citerefentry" href="https://netbsd.gw.com/cgi-bin/man-cgi?yacc+1.i386+NetBSD-8.1"><span class="citerefentry"><span class="refentrytitle">yacc</span>(1)</span></a> is part
 of the NetBSD source tree is beyond me.
 </pre>
 </div>
 <div class="sect2">
 <div class="titlepage"><div><div><h3 class="title">
 <a name="example-plist"></a>A.1.3. PLIST</h3></div></div></div>
 <pre class="programlisting">
 @comment $NetBSD$
 bin/bison
 man/man1/bison.1.gz
 share/bison.simple
 share/bison.hairy
 </pre>
 </div>
 <div class="sect2">
 <div class="titlepage"><div><div><h3 class="title">
 <a name="checking-package-with-pkglint"></a>A.1.4. Checking a package with <span class="command"><strong>pkglint</strong></span>
 </h3></div></div></div>
 <p>The NetBSD package system comes with
         <a href="https://cdn.NetBSD.org/pub/pkgsrc/current/pkgsrc/pkgtools/pkglint/README.html" target="_top"><code class="filename">pkgtools/pkglint</code></a>
 	which helps to check the contents of these
 	files. After installation it is quite easy to use, just change to the
-	directory of the package you wish to examine and execute
+	directory of the package you wish to examine and run
 	<span class="command"><strong>pkglint</strong></span>:</p>
 <pre class="screen"><code class="prompt">$</code> <strong class="userinput"><code>pkglint</code></strong>
-looks fine.</pre>
+ERROR: Makefile: Each package must define its LICENSE.
 WARN: Makefile:9: HOMEPAGE should migrate from http to https.
 NOTE: PLIST:3: The .gz extension is unnecessary for manual pages.
 WARN: PLIST:5: "share/bison.hairy" should be sorted before "share/bison.simple".
 error, 2 warnings and 1 note found.
 (Run "pkglint -e" to show explanations.)
 (Run "pkglint -fs" to show what can be fixed automatically.)
 (Run "pkglint.exe -F" to automatically fix some issues.)</pre>
 <p>Depending on the supplied command line arguments (see pkglint(1)),
 	more checks will be performed. Use e.g. <span class="command"><strong>pkglint
 	-Wall</strong></span> for a very thorough check.</p>
 </div>
 </div>
 <div class="sect1">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
 <a name="steps-for-b-i-p"></a>A.2. Steps for building, installing, packaging</h2></div></div></div>
 <p>Create the directory where the package lives,
       plus any auxiliary directories:</p>
 <pre class="screen"><code class="prompt">#</code> <strong class="userinput"><code>cd /usr/pkgsrc/lang</code></strong>
 <code class="prompt">#</code> <strong class="userinput"><code>mkdir bison</code></strong>
 <code class="prompt">#</code> <strong class="userinput"><code>cd bison</code></strong>
 <code class="prompt">#</code> <strong class="userinput"><code>mkdir patches</code></strong></pre>
 <p>Create <code class="filename">Makefile</code>, <code class="filename">DESCR</code> and
       <code class="filename">PLIST</code> (see <a class="xref" href="#components" title="Chapter 13. Package components - files, directories and contents">Chapter 13, <i>Package components - files, directories and contents</i></a>)
       then continue with fetching the distfile:</p>
 <pre class="screen"><code class="prompt">#</code> <strong class="userinput"><code>make fetch</code></strong>
 &gt;&gt; bison-1.25.tar.gz doesn't seem to exist on this system.
 &gt;&gt; Attempting to fetch from ftp://prep.ai.mit.edu/pub/gnu//.
 Requesting ftp://prep.ai.mit.edu/pub/gnu//bison-1.25.tar.gz (via ftp://orpheus.amdahl.com:80/)
 ftp: Error retrieving file: 500 Internal error
 &gt;&gt; Attempting to fetch from ftp://wuarchive.wustl.edu/systems/gnu//.
 Requesting ftp://wuarchive.wustl.edu/systems/gnu//bison-1.25.tar.gz (via ftp://orpheus.amdahl.com:80/)
 ftp: Error retrieving file: 500 Internal error
 &gt;&gt; Attempting to fetch from ftp://ftp.freebsd.org/pub/FreeBSD/distfiles//.
 Requesting ftp://ftp.freebsd.org/pub/FreeBSD/distfiles//bison-1.25.tar.gz (via ftp://orpheus.amdahl.com:80/)
 Successfully retrieved file.</pre>
 <p>Generate the checksum of the distfile into
       <code class="filename">distinfo</code>:</p>
 <pre class="screen"><code class="prompt">#</code> <strong class="userinput"><code>make makedistinfo</code></strong></pre>
 <p>Now compile:</p>
 <pre class="screen"><code class="prompt">#</code> <strong class="userinput"><code>make</code></strong>
 &gt;&gt; Checksum OK for bison-1.25.tar.gz.
 ===&gt;  Extracting for bison-1.25
 ===&gt;  Patching for bison-1.25
 ===&gt;   Ignoring empty patch directory
 ===&gt;  Configuring for bison-1.25
 creating cache ./config.cache
 checking for gcc... cc
 checking whether we are using GNU C... yes
 checking for a BSD compatible install... /usr/bin/install -c -o bin -g bin
 checking how to run the C preprocessor... cc -E
 checking for minix/config.h... no
 checking for POSIXized ISC... no
 checking whether cross-compiling... no
 checking for ANSI C header files... yes
 checking for string.h... yes
 checking for stdlib.h... yes
 checking for memory.h... yes
 checking for working const... yes
 checking for working alloca.h... no
 checking for alloca... yes
 checking for strerror... yes
 updating cache ./config.cache
 creating ./config.status
 creating Makefile
 ===&gt;  Building for bison-1.25
 cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include  -g LR0.c
 cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include  -g allocate.c
 cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include  -g closure.c
 cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include  -g conflicts.c
 cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include  -g derives.c
 cc -c -DXPFILE=\"/usr/pkg/share/bison.simple\"  -DXPFILE1=\"/usr/pkg/share/bison.hairy\" -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1  -g  ./files.c
 cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include  -g getargs.c
 cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include  -g gram.c
 cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include  -g lalr.c
 cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include  -g lex.c
 cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include  -g main.c
 cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include  -g nullable.c
 cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include  -g output.c
 cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include  -g print.c
 cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include  -g reader.c
 cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include  -g reduce.c
 cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include  -g symtab.c
 cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include  -g warshall.c
 cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include  -g version.c
 cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include  -g getopt.c
 cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include  -g getopt1.c
 cc  -g -o bison LR0.o allocate.o closure.o conflicts.o derives.o files.o         getargs.o gram.o lalr.o lex.o                                   main.o nullable.o output.o print.o reader.o reduce.o symtab.o   warshall.o version.o getopt.o getopt1.o
 ./files.c:240: warning: mktemp() possibly used unsafely, consider using mkstemp()
 rm -f bison.s1
 sed -e "/^#line/ s|bison|/usr/pkg/share/bison|" &lt; ./bison.simple &gt; bison.s1</pre>
 <p>Everything seems OK, so install the files:</p>
 <pre class="screen"><code class="prompt">#</code> <strong class="userinput"><code>make install</code></strong>
 &gt;&gt; Checksum OK for bison-1.25.tar.gz.
 ===&gt;  Installing for bison-1.25
 sh ./mkinstalldirs /usr/pkg/bin /usr/pkg/share  /usr/pkg/info /usr/pkg/man/man1
 rm -f /usr/pkg/bin/bison
 cd /usr/pkg/share; rm -f bison.simple bison.hairy
 rm -f /usr/pkg/man/man1/bison.1 /usr/pkg/info/bison.info*
 install -c  -o bin -g bin -m 555 bison /usr/pkg/bin/bison
 /usr/bin/install -c -o bin -g bin -m 644 bison.s1 /usr/pkg/share/bison.simple
 /usr/bin/install -c -o bin -g bin -m 644 ./bison.hairy /usr/pkg/share/bison.hairy
 cd .; for f in bison.info*;  do /usr/bin/install -c -o bin -g bin -m 644 $f /usr/pkg/info/$f; done
 /usr/bin/install -c -o bin -g bin -m 644 ./bison.1 /usr/pkg/man/man1/bison.1
 ===&gt;  Registering installation for bison-1.25</pre>
 <p>You can now use bison, and also - if you decide so - remove it with
       <span class="command"><strong>pkg_delete bison</strong></span>. Should you decide that you want a
       binary package, do this now:</p>
 <pre class="screen"><code class="prompt">#</code> <strong class="userinput"><code>make package</code></strong>
 &gt;&gt; Checksum OK for bison-1.25.tar.gz.
 ===&gt;  Building package for bison-1.25
 Creating package bison-1.25.tgz
 Registering depends:.
 Creating gzip'd tar ball in '/u/pkgsrc/lang/bison/bison-1.25.tgz'</pre>
 <p>Now that you don't need the source and object files
       any more, clean up:</p>
 <pre class="screen"><code class="prompt">#</code> <strong class="userinput"><code>make clean</code></strong>
 ===&gt;  Cleaning for bison-1.25</pre>
 </div>
 </div>
 <div class="appendix">
 <div class="titlepage"><div><div><h1 class="title">
 <a name="logs"></a>Appendix B. Build logs</h1></div></div></div>
 <div class="toc">
 <p><b>Table of Contents</b></p>
 <dl class="toc">
 <dt><span class="sect1"><a href="#logs.building">B.1. Building figlet</a></span></dt>
 <dt><span class="sect1"><a href="#logs.package">B.2. Packaging figlet</a></span></dt>
 </dl>
 </div>
 <div class="sect1">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
 <a name="logs.building"></a>B.1. Building figlet</h2></div></div></div>
 <pre class="screen"><code class="prompt">#</code> <strong class="userinput"><code>make</code></strong>
 ===&gt; Checking for vulnerabilities in figlet-2.2.1nb2
 =&gt; figlet221.tar.gz doesn't seem to exist on this system.
 =&gt; Attempting to fetch figlet221.tar.gz from ftp://ftp.figlet.org/pub/figlet/program/unix/.
 =&gt; [172219 bytes]
 Connected to ftp.plig.net.
 ftp.plig.org NcFTPd Server (licensed copy) ready.
 Guest login ok, send your complete e-mail address as password.
 -You are user #5 of 500 simultaneous users allowed.
 -
 -  ___ _             _ _
 - |  _| |_ ___   ___| |_|___   ___ ___ ___
 - |  _|  _| . |_| . | | | . |_| . |  _| . |
 - |_| |_| |  _|_|  _|_|_|_  |_|___|_| |_  |
 -         |_|   |_|     |___|         |___|
 -
 -** Welcome to ftp.plig.org **
 -
 -Please note that all transfers from this FTP site are logged. If you
 -do not like this, please disconnect now.
 -
 -This archive is available via
 -
 -HTTP:  http://ftp.plig.org/
 -FTP:   ftp://ftp.plig.org/     (max 500 connections)
 -RSYNC: rsync://ftp.plig.org/   (max  30 connections)
 -
 -Please email comments, bug reports and requests for packages to be
 -mirrored to ftp-admin@plig.org.
 -
 -
 Logged in anonymously.
 Remote system type is UNIX.
 Using binary mode to transfer files.
 Type okay.
 "/pub" is new cwd.
 -"/pub/figlet" is new cwd.
 -
 -Welcome to the figlet archive at ftp.figlet.org
 -
 -	ftp://ftp.figlet.org/pub/figlet/
 -
 -The official FIGlet web page is:
 -	http://www.figlet.org/
 -
 -If you have questions, please mailto:info@figlet.org. If you want to
 -contribute a font or something else, you can email us.
 "/pub/figlet/program" is new cwd.
 "/pub/figlet/program/unix" is new cwd.
 local: figlet221.tar.gz remote: figlet221.tar.gz
 Unimplemented command.
 Entering Passive Mode (195,40,6,41,246,104)
 Data connection accepted from 84.128.86.72:65131; transfer starting for figlet221.tar.gz (172219 bytes).
 % |**************                       | 65800      64.16 KB/s    00:01 ETA
 Transfer completed.
 bytes received in 00:02 (75.99 KB/s)
 Goodbye.
 =&gt; Checksum OK for figlet221.tar.gz.
 ===&gt; Extracting for figlet-2.2.1nb2
 ===&gt; Required installed package ccache-[0-9]*: ccache-2.3nb1 found
 ===&gt; Patching for figlet-2.2.1nb2
 ===&gt; Applying pkgsrc patches for figlet-2.2.1nb2
 ===&gt; Overriding tools for figlet-2.2.1nb2
 ===&gt; Creating toolchain wrappers for figlet-2.2.1nb2
 ===&gt; Configuring for figlet-2.2.1nb2
 ===&gt; Building for figlet-2.2.1nb2
 gcc -O2 -DDEFAULTFONTDIR=\"/usr/pkg/share/figlet\"  -DDEFAULTFONTFILE=\"standard.flf\"  figlet.c zipio.c crc.c inflate.c -o figlet
 chmod a+x figlet
 gcc -O2 -o chkfont chkfont.c
 =&gt; Unwrapping files-to-be-installed.
 <code class="prompt">#</code>
 <code class="prompt">#</code> <strong class="userinput"><code>make install</code></strong>
 ===&gt; Checking for vulnerabilities in figlet-2.2.1nb2
 ===&gt; Installing for figlet-2.2.1nb2
 install -d -o root -g wheel -m 755 /usr/pkg/bin
 install -d -o root -g wheel -m 755 /usr/pkg/man/man6
 mkdir -p /usr/pkg/share/figlet
 cp figlet /usr/pkg/bin
 cp chkfont /usr/pkg/bin
 chmod 555 figlist showfigfonts
 cp figlist /usr/pkg/bin
 cp showfigfonts /usr/pkg/bin
 cp fonts/*.flf /usr/pkg/share/figlet
 cp fonts/*.flc /usr/pkg/share/figlet
 cp figlet.6 /usr/pkg/man/man6
 ===&gt; Registering installation for figlet-2.2.1nb2
 <code class="prompt">#</code></pre>
 </div>
 <div class="sect1">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
 <a name="logs.package"></a>B.2. Packaging figlet</h2></div></div></div>
 <pre class="screen"><code class="prompt">#</code> <strong class="userinput"><code>make package</code></strong>
 ===&gt; Checking for vulnerabilities in figlet-2.2.1nb2
 ===&gt; Packaging figlet-2.2.1nb2
 ===&gt; Building binary package for figlet-2.2.1nb2
 Creating package /home/cvs/pkgsrc/packages/i386/All/figlet-2.2.1nb2.tgz
 Using SrcDir value of /usr/pkg
 Registering depends:.
 <code class="prompt">#</code></pre>
 </div>
 </div>
 <div class="appendix">
 <div class="titlepage"><div><div><h1 class="title">
 <a name="ftp-layout"></a>Appendix C. Directory layout of the pkgsrc FTP server</h1></div></div></div>
 <div class="toc">
 <p><b>Table of Contents</b></p>
 <dl class="toc">
 <dt><span class="sect1"><a href="#ftp-distfiles">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>
 </div>
 <p>As in other big projects, the directory layout of pkgsrc
 	is quite complex for newbies. This chapter explains where you
 	find things on the FTP server. The base directory on
 	<code class="filename">ftp.NetBSD.org</code> is <a class="ulink" href="ftp://ftp.NetBSD.org/pub/pkgsrc/" target="_top"><code class="filename">/pub/pkgsrc/</code></a>.
 	On other servers it may be different, but inside this directory,
 	everything should look the same, no matter on which server you
 	are. This directory contains some subdirectories, which are
 	explained below.</p>
 <div class="sect1">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
 <a name="ftp-distfiles"></a>C.1. <code class="filename">distfiles</code>: The distributed source files</h2></div></div></div>
 <p>The directory <code class="filename">distfiles</code> contains lots
 	of archive files from all pkgsrc packages, which are mirrored
 	here. The subdirectories are called after their package names
 	and are used when the distributed files have names that don't
 	explicitly contain a version number or are otherwise too generic
 	(for example <code class="filename">release.tar.gz</code>).</p>
 </div>
 <div class="sect1">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
 <a name="ftp-misc"></a>C.2. <code class="filename">misc</code>: Miscellaneous things</h2></div></div></div>
 <p>This directory contains things that individual pkgsrc
 	developers find worth publishing.</p>
 </div>
 <div class="sect1">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
 <a name="ftp-packages"></a>C.3. <code class="filename">packages</code>: Binary packages</h2></div></div></div>
 <p>This directory contains binary packages for the various
 	platforms that are supported by pkgsrc.
 	Each subdirectory is of the form <em class="replaceable"><code>OPSYS</code></em>/<em class="replaceable"><code>ARCH</code></em>/<em class="replaceable"><code>OSVERSION_TAG</code></em>. The meaning of these variables is:</p>
 <div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; ">
 <li class="listitem"><p><code class="varname">OPSYS</code> is the name of the
 	operating system for which the packages have been built. The
 	name is taken from the output of the <span class="command"><strong>uname</strong></span>
 	command, so it may differ from the one you are used to
 	hear.</p></li>
 <li class="listitem"><p><code class="varname">ARCH</code> is the hardware
 	architecture of the platform for which the packages have been
 	built. It also includes the <code class="varname">ABI</code> (Application
 	Binary Interface) for platforms that have several of
 	them.</p></li>
 <li class="listitem"><p><code class="varname">OSVERSION</code> is the version of
 	the operating system. For version numbers that change often (for
 	example NetBSD-current), the often-changing part should be
 	replaced with an <code class="literal">x</code>, for example
 	<code class="literal">4.99.x</code>.</p></li>
 <li class="listitem"><p><code class="varname">TAG</code> is either
 	<code class="literal">20<em class="replaceable"><code>xx</code></em>Q<em class="replaceable"><code>y</code></em></code>
 	for a stable branch, or <code class="literal">head</code> for packages
 	built from the HEAD branch. The latter should only be used when
 	the packages are updated on a regular basis. Otherwise the date
 	from checking out pkgsrc should be appended, for example
 	<code class="literal">head_20071015</code>.</p></li>
 </ul></div>
 <p>The rationale for exactly this scheme is that the pkgsrc users looking for binary packages
 	can quickly click through the directories on the
 	server and find the best binary packages for their machines. Since they
 	usually know the operating system and the hardware architecture, OPSYS
 	and ARCH are placed first. After these choices, they can select the
 	best combination of OSVERSION and TAG together, since it is usually the
 	case that packages stay compatible between different version of the
 	operating system.</p>
 <p>In each of these directories, there is a
 	whole binary packages collection for a specific platform. It has a directory called
 	<code class="filename">All</code> which contains all binary packages.
 	Besides that, there are various category directories that
 	contain symbolic links to the real binary packages.</p>
 </div>
 <div class="sect1">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
 <a name="ftp-reports"></a>C.4. <code class="filename">reports</code>: Bulk build reports</h2></div></div></div>
 <p>Here are the reports from bulk builds, for those who want
 	to fix packages that didn't build on some of the platforms. The
 	structure of subdirectories should look like the one in <a class="xref" href="#ftp-packages" title="C.3. packages: Binary packages">Section C.3, &#8220;<code class="filename">packages</code>: Binary packages&#8221;</a>.</p>
 </div>
 <div class="sect1">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
 <a name="ftp-source"></a>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</h2></div></div></div>
 <p>These directories contain the <span class="quote">&#8220;<span class="quote">real</span>&#8221;</span> pkgsrc,
 	that is the files that define how to create binary packages from
 	source archives.</p>
 <p>Each of the <code class="filename">current</code>,
 	<code class="filename">stable</code> and
 	<code class="filename">pkgsrc-20<em class="replaceable"><code>xx</code></em>Q<em class="replaceable"><code>y</code></em></code>
 	directories share the same structure.  They each contain a
 	<code class="filename">pkgsrc</code> directory and
 	<code class="filename">pkgsrc.tar.{bz,gz,xz}</code> file.</p>
 <p>The directory <code class="filename">pkgsrc</code> contains a
 	snapshot of the CVS repository, which is updated regularly. The
 	file <code class="filename">pkgsrc.tar.{bz,gz,xz}</code> contains the same
 	as the directory, ready to be downloaded as a whole.</p>
 <p>The <code class="filename">current</code> directory contains files
 	related to the HEAD branch of the CVS repository.
 	In this directory there is an additional file called
 	<code class="filename">pkgsrc-readmes.tar.{bz,gz,xz}</code> that contains
 	all pkgsrc <code class="filename">README</code>s with information about
 	categories and packages.
 	</p>
 <p>The <code class="filename">stable</code> directory is a symlink to
 	the latest
 	<code class="filename">pkgsrc-20<em class="replaceable"><code>xx</code></em>Q<em class="replaceable"><code>y</code></em></code>.
 	</p>
 <p>The
 	<code class="filename">pkgsrc-20<em class="replaceable"><code>xx</code></em>Q<em class="replaceable"><code>y</code></em></code>.
 	directories contain files related to the
 	<code class="filename">-20<em class="replaceable"><code>xx</code></em>Q<em class="replaceable"><code>y</code></em></code>
 	stable branch of the CVS repository. In these directories there is
 	an additional file called
 	<code class="filename">pkgsrc-20<em class="replaceable"><code>xx</code></em>Q<em class="replaceable"><code>y</code></em>.tar.{bz,gz,xz}</code>,
 	which contains the state of pkgsrc when it was branched.</p>
 </div>
 </div>
 <div class="appendix">
 <div class="titlepage"><div><div><h1 class="title">
 <a name="help-topics"></a>Appendix D. Help topics</h1></div></div></div>
 <p>
 	The following list contains all help topics that are available
 	when running <span class="command"><strong>bmake help topic=:index</strong></span>.
 </p>
 <table border="0" summary="Simple list" class="simplelist">
 <tr>
 <td>#!</td>
 <td>-lintl</td>
 </tr>
 <tr>
 <td>64bit</td>
 <td>ABI</td>
 </tr>
 <tr>
 <td>ACCEPTABLE_LICENSES</td>
 <td>ACROREAD_FONTPATH</td>
 </tr>
 <tr>
 <td>ADDITIONAL</td>
 <td>AFAIK</td>
 </tr>
 <tr>
 <td>AIX</td>
 <td>ALLOW_VULNERABLE_PACKAGES</td>
 </tr>
 <tr>
 <td>ALL_ENV</td>
 <td>ALSA_PC</td>
 </tr>
 <tr>
 <td>ALTERNATIVES_SRC</td>
 <td>AMANDA_TMP</td>
 </tr>
 <tr>
 <td>AMANDA_USER</td>
 <td>AMANDA_VAR</td>
 </tr>
 <tr>
 <td>APACHE_GROUP</td>
 <td>APACHE_MODULE_NAME</td>
 </tr>
 <tr>
 <td>APACHE_MODULE_SRC</td>
 <td>APACHE_MODULE_SRCDIR</td>
 </tr>
 <tr>
 <td>APACHE_PKG_PREFIX</td>
 <td>APACHE_SUEXEC_CONFIGURE_ARGS</td>
 </tr>
 <tr>
 <td>APACHE_SUEXEC_DOCROOT</td>
 <td>APACHE_USER</td>
 </tr>
 <tr>
 <td>APPEND_ABI</td>
 <td>APPEND_ELF</td>
 </tr>
 <tr>
 <td>ARLA_CACHE</td>
 <td>AUDIT_PACKAGES_FLAGS</td>
 </tr>
 <tr>
 <td>AUTOCONF_REQD</td>
 <td>AUTOMAKE_OVERRIDE</td>
 </tr>
 <tr>
 <td>AUTOMAKE_REQD</td>
 <td>AUTO_MKDIRS</td>
 </tr>
 <tr>
 <td>BDB185_DEFAULT</td>
 <td>BDBBASE</td>
 </tr>
 <tr>
 <td>BDB_ACCEPTED</td>
 <td>BDB_DEFAULT</td>
 </tr>
 <tr>
 <td>BDB_LIBS</td>
 <td>BDB_TYPE</td>
 </tr>
 <tr>
 <td>BIND_DIR</td>
 <td>BIND_GROUP</td>
 </tr>
 <tr>
 <td>BIND_USER</td>
 <td>BINPKG_SITES</td>
 </tr>
 <tr>
 <td>BIN_INSTALL_FLAGS</td>
 <td>BISON_PKGDATADIR</td>
 </tr>
 <tr>
 <td>BLAS_ACCEPTED</td>
 <td>BLAS_LIBS</td>
 </tr>
 <tr>
 <td>BLAS_TYPE</td>
 <td>BOOTSTRAP_DEPENDS</td>
 </tr>
 <tr>
 <td>BOOTSTRAP_SETUPTOOLS</td>
 <td>BROKEN</td>
 </tr>
 <tr>
 <td>BROKEN_EXCEPT_ON_PLATFORM</td>
 <td>BROKEN_ON_PLATFORM</td>
 </tr>
 <tr>
 <td>BSDSRCDIR</td>
 <td>BSDXSRCDIR</td>
 </tr>
 <tr>
 <td>BSD_MAKE_ENV</td>
 <td>BUILDLINK_AUTO_DIRS</td>
 </tr>
 <tr>
 <td>BUILDLINK_AUTO_VARS</td>
 <td>BUILDLINK_CFLAGS</td>
 </tr>
 <tr>
 <td>BUILDLINK_CONTENTS_FILTER</td>
 <td>BUILDLINK_CPPFLAGS</td>
 </tr>
 <tr>
 <td>BUILDLINK_DEPMETHOD</td>
 <td>BUILDLINK_FILES</td>
 </tr>
 <tr>
 <td>BUILDLINK_FILES_CMD</td>
 <td>BUILDLINK_FNAME_TRANSFORM</td>
 </tr>
 <tr>
 <td>BUILDLINK_LDFLAGS</td>
 <td>BUILDLINK_LIBS</td>
 </tr>
 <tr>
 <td>BUILDLINK_OPSYS_SUPPORT_PTHREAD</td>
 <td>BUILDLINK_PKGNAME</td>
 </tr>
 <tr>
 <td>BUILDLINK_PREFIX</td>
 <td>BUILDLINK_RPATHDIRS</td>
 </tr>
 <tr>
 <td>BUILDLINK_TREE</td>
 <td>BUILD_DEFS</td>
 </tr>
 <tr>
 <td>BUILD_DEFS_EFFECTS</td>
 <td>BUILD_DEPENDS</td>
 </tr>
 <tr>
 <td>BUILD_DIRS</td>
 <td>BUILD_ENV_SHELL</td>
 </tr>
 <tr>
 <td>BUILD_MAKE_CMD</td>
 <td>BUILD_MAKE_FLAGS</td>
 </tr>
 <tr>
 <td>BUILD_TARGET</td>
 <td>BUILTIN_FIND_FILES</td>
 </tr>
 <tr>
 <td>BUILTIN_FIND_FILES_VAR</td>
 <td>BUILTIN_FIND_GREP</td>
 </tr>
 <tr>
 <td>BUILTIN_FIND_HEADERS</td>
 <td>BUILTIN_FIND_HEADERS_VAR</td>
 </tr>
 <tr>
 <td>BUILTIN_PKG</td>
 <td>BUILTIN_TEST_CURSES_DEFINES</td>
 </tr>
 <tr>
 <td>BUILTIN_TEST_CURSES_FUNCS</td>
 <td>BUILTIN_VERSION_SCRIPT</td>
 </tr>
 <tr>
 <td>BUILTIN_X11_TYPE</td>
 <td>BUILTIN_X11_VERSION</td>
 </tr>
 <tr>
 <td>CACTI_GROUP</td>
 <td>CACTI_USER</td>
 </tr>
 <tr>
 <td>CANNA_GROUP</td>
 <td>CANNA_USER</td>
 </tr>
 <tr>
 <td>CAT</td>
 <td>CCACHE_BASE</td>
 </tr>
 <tr>
 <td>CCACHE_DIR</td>
 <td>CCACHE_LOGFILE</td>
 </tr>
 <tr>
 <td>CC_VERSION</td>
 <td>CC_VERSION_STRING</td>
 </tr>
 <tr>
 <td>CDRECORD_CONF</td>
 <td>CDROM_PKG_URL_DIR</td>
 </tr>
 <tr>
 <td>CDROM_PKG_URL_HOST</td>
 <td>CHECKOUT_DATE</td>
 </tr>
 <tr>
 <td>CHECK_FAKEHOME</td>
 <td>CHECK_FILES</td>
 </tr>
 <tr>
 <td>CHECK_FILES_SKIP</td>
 <td>CHECK_FILES_STRICT</td>
 </tr>
 <tr>
 <td>CHECK_HEADERS</td>
 <td>CHECK_HEADERS_SKIP</td>
 </tr>
 <tr>
 <td>CHECK_INTERPRETER</td>
 <td>CHECK_INTERPRETER_SKIP</td>
 </tr>
 <tr>
 <td>CHECK_PERMS</td>
 <td>CHECK_PERMS_AUTOFIX</td>
 </tr>
 <tr>
 <td>CHECK_PERMS_SKIP</td>
 <td>CHECK_PORTABILITY</td>
 </tr>
 <tr>
 <td>CHECK_PORTABILITY_SKIP</td>
 <td>CHECK_RELRO</td>
 </tr>
 <tr>
 <td>CHECK_RELRO_SKIP</td>
 <td>CHECK_RELRO_SUPPORTED</td>
 </tr>
 <tr>
 <td>CHECK_SHLIBS</td>
 <td>CHECK_SHLIBS_BLACKLIST</td>
 </tr>
 <tr>
 <td>CHECK_SHLIBS_SKIP</td>
 <td>CHECK_SHLIBS_SUPPORTED</td>
 </tr>
 <tr>
 <td>CHECK_SSP</td>
 <td>CHECK_SSP_SKIP</td>
 </tr>
 <tr>
 <td>CHECK_SSP_SUPPORTED</td>
 <td>CHECK_STRIPPED</td>
 </tr>
 <tr>
 <td>CHECK_STRIPPED_SKIP</td>
 <td>CHECK_WRKREF</td>
 </tr>
 <tr>
 <td>CHECK_WRKREF_EXTRA_DIRS</td>
 <td>CHECK_WRKREF_SKIP</td>
 </tr>
 <tr>
 <td>CLAMAV_DBDIR</td>
 <td>CLAMAV_GROUP</td>
 </tr>
 <tr>
 <td>CLAMAV_USER</td>
 <td>CLANGBASE</td>
 </tr>
 <tr>
 <td>CLEANDEPENDS</td>
 <td>CMAKE_DEPENDENCIES_REWRITE</td>
 </tr>
 <tr>
 <td>CMAKE_INSTALL_PREFIX</td>
 <td>CMAKE_MODULE_PATH_OVERRIDE</td>
 </tr>
 <tr>
 <td>CMAKE_PKGSRC_BUILD_FLAGS</td>
 <td>CMAKE_PREFIX_PATH</td>
 </tr>
 <tr>
 <td>CMAKE_USE_GNU_INSTALL_DIRS</td>
 <td>COMMON_LISP_DOCFILES</td>
 </tr>
 <tr>
 <td>COMMON_LISP_EXAMPLES</td>
 <td>COMMON_LISP_EXTRAFILES</td>
 </tr>
 <tr>
 <td>COMMON_LISP_PACKAGES</td>
 <td>COMMON_LISP_SYSTEM</td>
 </tr>
 <tr>
 <td>COMPILER_RPATH_FLAG</td>
 <td>COMPILER_USE_SYMLINKS</td>
 </tr>
 <tr>
 <td>CONFIGURE_ARGS</td>
 <td>CONFIGURE_DIRS</td>
 </tr>
 <tr>
 <td>CONFIGURE_ENV</td>
 <td>CONFIGURE_HAS_INFODIR</td>
 </tr>
 <tr>
 <td>CONFIGURE_HAS_MANDIR</td>
 <td>CONFIGURE_SCRIPT</td>
 </tr>
 <tr>
 <td>CONFIG_SHELL</td>
 <td>CONFIG_SHELL_FLAGS</td>
 </tr>
 <tr>
 <td>CONF_FILES</td>
 <td>CONF_FILES_MODE</td>
 </tr>
 <tr>
 <td>CONF_FILES_PERMS</td>
 <td>CONSERVER_DEFAULTHOST</td>
 </tr>
 <tr>
 <td>CONSERVER_DEFAULTPORT</td>
 <td>CP</td>
 </tr>
 <tr>
 <td>CPP</td>
 <td>CPP_PRECOMP_FLAGS</td>
 </tr>
 <tr>
 <td>CREATE_WRKDIR_SYMLINK</td>
 <td>CROSSBASE</td>
 </tr>
 <tr>
 <td>CTFCONVERT</td>
 <td>CTF_FILES_SKIP</td>
 </tr>
 <tr>
 <td>CTF_SUPPORTED</td>
 <td>CTYPE</td>
 </tr>
 <tr>
 <td>CUPS_GROUP</td>
 <td>CUPS_SYSTEM_GROUPS</td>
 </tr>
 <tr>
 <td>CUPS_USER</td>
 <td>CURSES_DEFAULT</td>
 </tr>
 <tr>
 <td>CURSES_TYPE</td>
 <td>CVS_EXTRACTDIR</td>
 </tr>
 <tr>
 <td>CVS_MODULE</td>
 <td>CVS_PROJECT</td>
 </tr>
 <tr>
 <td>CVS_REPOSITORIES</td>
 <td>CVS_ROOT</td>
 </tr>
 <tr>
 <td>CVS_ROOT_GNU</td>
 <td>CVS_ROOT_NONGNU</td>
 </tr>
 <tr>
 <td>CVS_ROOT_SOURCEFORGE</td>
 <td>CVS_TAG</td>
 </tr>
 <tr>
 <td>CXX</td>
 <td>CYRUS_GROUP</td>
 </tr>
 <tr>
 <td>CYRUS_IDLE</td>
 <td>CYRUS_USER</td>
 </tr>
 <tr>
 <td>DAEMONTOOLS_GROUP</td>
 <td>DAEMONTOOLS_LOG_USER</td>
 </tr>
 <tr>
 <td>DBUS_GROUP</td>
 <td>DBUS_USER</td>
 </tr>
 <tr>
 <td>DEFANG_GROUP</td>
 <td>DEFANG_USER</td>
 </tr>
 <tr>
 <td>DEFAULT_ACCEPTABLE_LICENSES</td>
 <td>DEFAULT_DISTFILES</td>
 </tr>
 <tr>
 <td>DEFAULT_IRC_SERVER</td>
 <td>DEFAULT_SERIAL_DEVICE</td>
 </tr>
 <tr>
 <td>DEF_UMASK</td>
 <td>DEINSTALLDEPENDS</td>
 </tr>
 <tr>
 <td>DEINSTALL_SRC</td>
 <td>DEINSTALL_TEMPLATES</td>
 </tr>
 <tr>
 <td>DELAYED_ERROR_MSG</td>
 <td>DELAYED_WARNING_MSG</td>
 </tr>
 <tr>
 <td>DEPENDS</td>
 <td>DEPENDS_TARGET</td>
 </tr>
 <tr>
 <td>DEPENDS_TYPE</td>
 <td>DESTDIR</td>
 </tr>
 <tr>
 <td>DESTDIR_VARNAME</td>
 <td>DIALER_GROUP</td>
 </tr>
 <tr>
 <td>DIGEST_REQD</td>
 <td>DISTDIR</td>
 </tr>
 <tr>
 <td>DISTFILES</td>
 <td>DISTINFO_FILE</td>
 </tr>
 <tr>
 <td>DISTNAME</td>
 <td>DIST_PATH</td>
 </tr>
 <tr>
 <td>DIST_SUBDIR</td>
 <td>DJBDNS_AXFR_USER</td>
 </tr>
 <tr>
 <td>DJBDNS_CACHE_USER</td>
 <td>DJBDNS_DJBDNS_GROUP</td>
 </tr>
 <tr>
 <td>DJBDNS_LOG_USER</td>
 <td>DJBDNS_RBL_USER</td>
 </tr>
 <tr>
 <td>DJBDNS_TINY_USER</td>
 <td>DLOPEN_REQUIRE_PTHREADS</td>
 </tr>
 <tr>
 <td>DL_AUTO_VARS</td>
 <td>DL_CFLAGS</td>
 </tr>
 <tr>
 <td>DL_LDFLAGS</td>
 <td>DL_LIBS</td>
 </tr>
 <tr>
 <td>DNS</td>
 <td>DOWNLOADED_DISTFILE</td>
 </tr>
 <tr>
 <td>DT_LAYOUT</td>
 <td>DYNAMIC_SITES_CMD</td>
 </tr>
 <tr>
 <td>DYNAMIC_SITES_SCRIPT</td>
 <td>ECHO</td>
 </tr>
 <tr>
 <td>ECHO_N</td>
 <td>ELK_GUI</td>
 </tr>
 <tr>
 <td>EMACS_TYPE</td>
 <td>EMULDIR</td>
 </tr>
 <tr>
 <td>EMULSUBDIR</td>
 <td>EMULSUBDIRSLASH</td>
 </tr>
 <tr>
 <td>EMUL_ARCH</td>
 <td>EMUL_DISTRO</td>
 </tr>
 <tr>
 <td>EMUL_EXEC_FMT</td>
 <td>EMUL_IS_NATIVE</td>
 </tr>
 <tr>
 <td>EMUL_MODULES</td>
 <td>EMUL_OPSYS</td>
 </tr>
 <tr>
 <td>EMUL_PKG_FMT</td>
 <td>EMUL_PLATFORM</td>
 </tr>
 <tr>
 <td>EMUL_PLATFORMS</td>
 <td>EMUL_PREFER</td>
 </tr>
 <tr>
 <td>EMUL_REQD</td>
 <td>EMUL_TYPE</td>
 </tr>
 <tr>
 <td>ERROR_MSG</td>
 <td>EXIM_GROUP</td>
 </tr>
 <tr>
 <td>EXIM_USER</td>
 <td>EXPORT_SYMBOLS_LDFLAGS</td>
 </tr>
 <tr>
 <td>EXTRACTOR</td>
 <td>EXTRACT_CMD</td>
 </tr>
 <tr>
 <td>EXTRACT_CMD_DEFAULT</td>
 <td>EXTRACT_DIR</td>
 </tr>
 <tr>
 <td>EXTRACT_ELEMENTS</td>
 <td>EXTRACT_ENV</td>
 </tr>
 <tr>
 <td>EXTRACT_ONLY</td>
 <td>EXTRACT_OPTS</td>
 </tr>
 <tr>
 <td>EXTRACT_SUFX</td>
 <td>EXTRACT_USING</td>
 </tr>
 <tr>
 <td>FAILOVER_FETCH</td>
 <td>FAIL_MSG</td>
 </tr>
 <tr>
 <td>FAKE_NCURSES</td>
 <td>FAM</td>
 </tr>
 <tr>
 <td>FAM_ACCEPTED</td>
 <td>FAM_DEFAULT</td>
 </tr>
 <tr>
 <td>FAM_SERVER</td>
 <td>FCPATH</td>
 </tr>
 <tr>
 <td>FEATURE_CPPFLAGS</td>
 <td>FEATURE_LDFLAGS</td>
 </tr>
 <tr>
 <td>FEATURE_LIBS</td>
 <td>FETCH_AFTER_ARGS</td>
 </tr>
 <tr>
 <td>FETCH_BEFORE_ARGS</td>
 <td>FETCH_CMD</td>
 </tr>
 <tr>
 <td>FETCH_OUTPUT_ARGS</td>
 <td>FETCH_PROXY</td>
 </tr>
 <tr>
 <td>FETCH_RESUME_ARGS</td>
 <td>FETCH_USING</td>
 </tr>
 <tr>
 <td>FILES_SUBST</td>
 <td>FILES_SUBST_SED</td>
 </tr>
 <tr>
 <td>FIX_SYSTEM_HEADERS</td>
 <td>FLUXBOX_USE_GNOME</td>
 </tr>
 <tr>
 <td>FLUXBOX_USE_KDE</td>
 <td>FLUXBOX_USE_XFT</td>
 </tr>
 <tr>
 <td>FLUXBOX_USE_XINERAMA</td>
 <td>FONTDIR</td>
 </tr>
 <tr>
 <td>FONTS_DIRS</td>
 <td>FONTS_VERBOSE</td>
 </tr>
 <tr>
 <td>FOO_HACKS_MK</td>
 <td>FOSSIL_EXTRACTDIR</td>
 </tr>
 <tr>
 <td>FOSSIL_REPO</td>
 <td>FOSSIL_REPOSITORIES</td>
 </tr>
 <tr>
 <td>FOSSIL_VERSION</td>
 <td>FOX_USE_XUNICODE</td>
 </tr>
 <tr>
 <td>FREEWNN_GROUP</td>
 <td>FREEWNN_USER</td>
 </tr>
 <tr>
 <td>FTP_PKG_URL_DIR</td>
 <td>FTP_PKG_URL_HOST</td>
 </tr>
 <tr>
 <td>GAMEDATAMODE</td>
 <td>GAMEDATA_PERMS</td>
 </tr>
 <tr>
 <td>GAMEDIRMODE</td>
 <td>GAMEDIR_PERMS</td>
 </tr>
 <tr>
 <td>GAMEGRP</td>
 <td>GAMEMODE</td>
 </tr>
 <tr>
 <td>GAMEOWN</td>
 <td>GAMES_GROUP</td>
 </tr>
 <tr>
 <td>GAMES_USER</td>
 <td>GCC</td>

 @@ -7196,2031 +7196,2038 @@ should include the package name and vers
 should contain a short description of your package (contents of the COMMENT
 variable or DESCR file are OK). The uuencoded package data should go into the "
 fix" field.
 If you want to submit several packages, please send a separate PR for each one,
 it's easier for us to track things that way.
 Alternatively, you can also import new packages into pkgsrc-wip ("pkgsrc
 work-in-progress"); see the homepage at http://pkgsrc.org/wip/ for details.
 .3. General notes when adding, updating, or removing packages
 Please note all package additions, updates, moves, and removals in pkgsrc/doc/
 CHANGES-YYYY. It's very important to keep this file up to date and conforming
 to the existing format, because it will be used by scripts to automatically
 update pages on www.NetBSD.org and other sites. Additionally, check the pkgsrc/
 doc/TODO file and remove the entry for the package you updated or removed, in
 case it was mentioned there.
 When the PKGREVISION of a package is bumped, the change should appear in pkgsrc
 /doc/CHANGES-YYYY if it is security related or otherwise relevant. Mass bumps
 that result from a dependency being updated should not be mentioned. In all
 other cases it's the developer's decision.
 There is a make target that helps in creating proper CHANGES-YYYY entries: make
 changes-entry. It uses the optional CTYPE and NETBSD_LOGIN_NAME variables. The
 general usage is to first make sure that your CHANGES-YYYY file is up-to-date
 (to avoid having to resolve conflicts later-on) and then to cd to the package
 directory. For package updates, make changes-entry is enough. For new packages,
 or package moves or removals, set the CTYPE variable on the command line to
 "Added", "Moved", or "Removed". You can set NETBSD_LOGIN_NAME in mk.conf if
 your local login name is not the same as your NetBSD login name. The target
 also automatically removes possibly existing entries for the package in the
 TODO file. Don't forget to commit the changes, e.g. by using make
 commit-changes-entry! If you are not using a checkout directly from
 cvs.NetBSD.org, but e.g. a local copy of the repository, you can set
 USE_NETBSD_REPO=yes. This makes the cvs commands use the main repository.
 .4. Commit Messages
 For several years, there have been mirrors of pkgsrc in fossil, git, and hg.
 Standard practise when using these tools is to make the first line of a commit
 message function as a summary that can be read without the rest, such as is
 commonly done with "git log --oneline". For this reason, we have the following
 guidelines for pkgsrc commit messages:
   * Start the commit message with a line that explains the big picture in 65
     characters or less. When a commit is for one package, include the name of
     the package. For updates, include the version to which it is updated.
   * Leave the next line empty.
   * Then come the details for the commit (changes in that package, reason for a
     change) and any relevant PRs. Wrap this section.
 Here is an example:
   libxslt: update to 1.0.30
   Changes since 1.0.29:
   ...
 Here is another example:
   mk/bsd.pkg.mk: enable SSP by default on NetBSD
   (rationale)
 Commit messages are final: no "cvs admin" is allowed on the pkgsrc repository
 to change commit messages.
 .5. Committing: Adding a package to CVS
 This section is only of interest for pkgsrc developers with write access to the
 pkgsrc repository.
 When the package is finished, "cvs add" the files. Start by adding the
 directory and then files in the directory. Don't forget to add the new package
 to the category's Makefile. Make sure you don't forget any files; you can check
 by running "cvs status". An example:
 $ cd .../pkgsrc/category
 $ cvs add pkgname
 $ cd pkgname
 $ cvs add DESCR Makefile PLIST distinfo buildlink3.mk patches
 $ cvs add patches/p*
 $ cvs status | less
 $ cvs commit
 $ cd ..
 $ vi Makefile # add SUBDIRS+=pkgname line
 $ cvs commit Makefile
 $ cd pkgname
 $ make CTYPE=Added commit-changes-entry
 The commit message of the initial import should include part of the DESCR file,
 so people reading the mailing lists know what the package is/does.
 Also mention the new package in pkgsrc/doc/CHANGES-20xx.
 Previously, "cvs import" was suggested, but it was much easier to get wrong
 than "cvs add".
 .6. Updating a package to a newer version
 Please always put a concise, appropriate and relevant summary of the changes
 between old and new versions into the commit log when updating a package. There
 are various reasons for this:
   * A URL is volatile, and can change over time. It may go away completely or
     its information may be overwritten by newer information.
   * Having the change information between old and new versions in our CVS
     repository is very useful for people who use either cvs or anoncvs.
   * Having the change information between old and new versions in our CVS
     repository is very useful for people who read the pkgsrc-changes mailing
     list, so that they can make tactical decisions about when to upgrade the
     package.
 Please also recognize that, just because a new version of a package has been
 released, it should not automatically be upgraded in the CVS repository. We
 prefer to be conservative in the packages that are included in pkgsrc -
 development or beta packages are not really the best thing for most places in
 which pkgsrc is used. Please use your judgement about what should go into
 pkgsrc, and bear in mind that stability is to be preferred above new and
 possibly untested features.
 .7. Renaming a package in pkgsrc
 Renaming packages is not recommended.
 When renaming packages, be sure to fix any references to old name in other
 Makefiles, options, buildlink files, etc.
 Also when renaming a package, please add the package name and version pattern
 (s) of the previous package to SUPERSEDES. This may be repeated for multiple
 renames. The new package would be an exact replacement. Example:
 SUPERSEDES+=    p5-IO-Compress-Zlib<2.017
 SUPERSEDES+=    optcomp-[0-9]*
 Note that "successor" in the CHANGES-YYYY file doesn't necessarily mean that it
 supersedes, as that successor may not be an exact replacement but is a
 suggestion for the replaced functionality.
 .8. Moving a package in pkgsrc
 It is preferred that packages are not renamed or moved, but if needed please
 follow these steps.
 . Make a copy of the directory somewhere else.
 . Remove all CVS dirs.
     Alternatively to the first two steps you can also do:
     % cvs -d user@cvs.NetBSD.org:/cvsroot export -D today pkgsrc/category/package
     and use that for further work.
 . Fix CATEGORIES and any DEPENDS paths that just did "../package" instead of
     "../../category/package".
 . In the modified package's Makefile, consider setting PREV_PKGPATH to the
     previous category/package pathname. The PREV_PKGPATH can be used by tools
     for doing an update using pkgsrc building; for example, it can search the
     pkg_summary(5) database for PREV_PKGPATH (if no SUPERSEDES) and then use
     the corresponding new PKGPATH for that moved package. Note that it may have
     multiple matches, so the tool should also check on the PKGBASE too. The
     PREV_PKGPATH probably has no value unless SUPERSEDES is not set, i.e.
     PKGBASE stays the same.
 . cvs import the modified package in the new place.
 . Check if any package depends on it:
     % cd /usr/pkgsrc
     % grep /package */*/Makefile* */*/buildlink*
 . Fix paths in packages from step 5 to point to new location.
 . cvs rm (-f) the package at the old location.
 . Remove from oldcategory/Makefile.
 . Add to newcategory/Makefile.
 . Commit the changed and removed files:
     % cvs commit oldcategory/package oldcategory/Makefile newcategory/Makefile
     (and any packages from step 5, of course).
 Chapter 24. Frequently Asked Questions
 This section contains the answers to questions that may arise when you are
 writing a package. If you don't find your question answered here, first have a
 look in the other chapters, and if you still don't have the answer, ask on the
 pkgsrc-users mailing list.
 .1. What is the difference between MAKEFLAGS, .MAKEFLAGS and MAKE_FLAGS?
 .2. What is the difference between MAKE, GMAKE and MAKE_PROGRAM?
 .3. What is the difference between CC, PKG_CC and PKGSRC_COMPILER?
 .4. What is the difference between BUILDLINK_LDFLAGS, BUILDLINK_LDADD and
     BUILDLINK_LIBS?
 .5. Why does make show-var VARNAME=BUILDLINK_PREFIX.foo say it's empty?
 .6. What does ${MASTER_SITE_SOURCEFORGE:=package/} mean? I don't understand
     the := inside it.
 .7. Which mailing lists are there for package developers?
 .8. Where is the pkgsrc documentation?
 .9. I have a little time to kill. What shall I do?
 .1. What is the difference between MAKEFLAGS, .MAKEFLAGS and MAKE_FLAGS?
       MAKEFLAGS are the flags passed to the pkgsrc-internal invocations of make
       (1), while MAKE_FLAGS are the flags that are passed to the MAKE_PROGRAM
       when building the package. [FIXME: What is .MAKEFLAGS for?]
 .2. What is the difference between MAKE, GMAKE and MAKE_PROGRAM?
       MAKE is the path to the make(1) program that is used in the pkgsrc
       infrastructure. GMAKE is the path to GNU Make, but you need to say
       USE_TOOLS+=gmake to use that. MAKE_PROGRAM is the path to the Make
       program that is used for building the package.
 .3. What is the difference between CC, PKG_CC and PKGSRC_COMPILER?
       CC is the path to the real C compiler, which can be configured by the
       pkgsrc user. PKG_CC is the path to the compiler wrapper. PKGSRC_COMPILER
       is not a path to a compiler, but the type of compiler that should be
       used. See mk/compiler.mk for more information about the latter variable.
 .4. What is the difference between BUILDLINK_LDFLAGS, BUILDLINK_LDADD and
       BUILDLINK_LIBS?
       [FIXME]
 .5. Why does make show-var VARNAME=BUILDLINK_PREFIX.foo say it's empty?
       For optimization reasons, some variables are only available in the "
       wrapper" phase and later. To "simulate" the wrapper phase, append
       PKG_PHASE=wrapper to the above command.
 .6. What does ${MASTER_SITE_SOURCEFORGE:=package/} mean? I don't understand
       the := inside it.
       The := is not really an assignment operator, although it looks like it.
       Instead, it is a degenerate form of ${LIST:old_string=new_string}, which
       is documented in the make(1) man page and which is commonly used in the
       form ${SRCS:.c=.o}. In the case of MASTER_SITE_*, old_string is the empty
       string and new_string is package/. That's where the : and the = fall
       together.
 .7. Which mailing lists are there for package developers?
       tech-pkg
           This is a list for technical discussions related to pkgsrc
           development, e.g. soliciting feedback for changes to pkgsrc
           infrastructure, proposed new features, questions related to porting
           pkgsrc to a new platform, advice for maintaining a package, patches
           that affect many packages, help requests moved from pkgsrc-users when
           an infrastructure bug is found, etc.
       pkgsrc-bugs
           All bug reports in category "pkg" sent with send-pr(1) appear here.
           Please do not report your bugs here directly; use one of the other
           mailing lists.
 .8. Where is the pkgsrc documentation?
       There are many places where you can find documentation about pkgsrc:
         * The pkgsrc guide (this document) is a collection of chapters that
           explain large parts of pkgsrc, but some chapters tend to be outdated.
           Which ones they are is hard to say.
         * On the mailing list archives (see http://mail-index.NetBSD.org/), you
           can find discussions about certain features, announcements of new
           parts of the pkgsrc infrastructure and sometimes even announcements
           that a certain feature has been marked as obsolete. The benefit here
           is that each message has a date appended to it.
         * Many of the files in the mk/ directory start with a comment that
           describes the purpose of the file and how it can be used by the
           pkgsrc user and package authors. An easy way to find this
           documentation is to run bmake help.
         * The CVS log messages are a rich source of information, but they tend
           to be highly abbreviated, especially for actions that occur often.
           Some contain a detailed description of what has changed, but they are
           geared towards the other pkgsrc developers, not towards an average
           pkgsrc user. They also only document changes, so if you don't know
           what has been before, these messages may not be worth too much to
           you.
         * Some parts of pkgsrc are only "implicitly documented", that is the
           documentation exists only in the mind of the developer who wrote the
           code. To get this information, use the cvs annotate command to see
           who has written it and ask on the tech-pkg mailing list, so that
           others can find your questions later (see above). To be sure that the
           developer in charge reads the mail, you may CC him or her.
 .9. I have a little time to kill. What shall I do?
       This is not really an FAQ yet, but here's the answer anyway.
         * Run pkg_chk -N (from the pkgtools/pkg_chk package). It will tell you
           about newer versions of installed packages that are available, but
           not yet updated in pkgsrc.
         * Browse pkgsrc/doc/TODO ? it contains a list of suggested new packages
           and a list of cleanups and enhancements for pkgsrc that would be nice
           to have.
         * Review packages for which review was requested on the tech-pkg
           mailing list.
 Chapter 25. GNOME packaging and porting
 Table of Contents
 .1. Meta packages
 .2. Packaging a GNOME application
 .3. Updating GNOME to a newer version
 .4. Patching guidelines
 Quoting GNOME's web site:
     The GNOME project provides two things: The GNOME desktop environment, an
     intuitive and attractive desktop for users, and the GNOME development
     platform, an extensive framework for building applications that integrate
     into the rest of the desktop.
 pkgsrc provides a seamless way to automatically build and install a complete
 GNOME environment under many different platforms. We can say with confidence
 that pkgsrc is one of the most advanced build and packaging systems for GNOME
 due to its included technologies buildlink3, the wrappers and tools framework
 and automatic configuration file management. Lots of efforts are put into
 achieving a completely clean deinstallation of installed software components.
 Given that pkgsrc is NetBSD's official packaging system, the above also means
 that great efforts are put into making GNOME work under this operating system.
 Recently, DragonFly BSD also adopted pkgsrc as its preferred packaging system,
 contributing lots of portability fixes to make GNOME build and install under
 it.
 This chapter is aimed at pkgsrc developers and other people interested in
 helping our GNOME porting and packaging efforts. It provides instructions on
 how to manage the existing packages and some important information regarding
 their internals.
 We need your help!
 Should you have some spare cycles to devote to NetBSD, pkgsrc and GNOME and are
 willing to learn new exciting stuff, please jump straight to the pending work
 list! There is still a long way to go to get a fully-functional GNOME desktop
 under NetBSD and we need your help to achieve it!
 .1. Meta packages
 pkgsrc includes three GNOME-related meta packages:
   * meta-pkgs/gnome-base: Provides the core GNOME desktop environment. It only
     includes the necessary bits to get it to boot correctly, although it may
     lack important functionality for daily operation. The idea behind this
     package is to let end users build their own configurations on top of this
     one, first installing this meta package to achieve a functional setup and
     then adding individual applications.
   * meta-pkgs/gnome: Provides a complete installation of the GNOME platform and
     desktop as defined by the GNOME project; this is based on the components
     distributed in the platform/x.y/x.y.z/sources and desktop/x.y/x.y.z/sources
     directories of the official FTP server. Developer-only tools found in those
     directories are not installed unless required by some other component to
     work properly. Similarly, packages from the bindings set (bindings/x.y/
     x.y.z/sources) are not pulled in unless required as a dependency for an
     end-user component. This package "extends" meta-pkgs/gnome-base.
   * meta-pkgs/gnome-devel: Installs all the tools required to build a GNOME
     component when fetched from the CVS repository. These are required to let
     the autogen.sh scripts work appropriately.
 In all these packages, the DEPENDS lines are sorted in a way that eases
 updates: a package may depend on other packages listed before it but not on any
 listed after it. It is very important to keep this order to ease updates so...
 do not change it to alphabetical sorting!
 .2. Packaging a GNOME application
 Almost all GNOME applications are written in C and use a common set of tools as
 their build system. Things get different with the new bindings to other
 languages (such as Python), but the following will give you a general idea on
 the minimum required tools:
   * Almost all GNOME applications use the GNU Autotools as their build system.
     As a general rule you will need to tell this to your package:
     GNU_CONFIGURE=yes
     USE_LIBTOOL=yes
     USE_TOOLS+=gmake
   * If the package uses pkg-config to detect dependencies, add this tool to the
     list of required utilities:
     USE_TOOLS+=pkg-config
     Also use pkgtools/verifypc at the end of the build process to ensure that
     you did not miss to specify any dependency in your package and that the
     version requirements are all correct.
   * If the package uses intltool, be sure to add intltool to the USE_TOOLS to
     handle dependencies and to force the package to use the latest available
     version.
   * If the package uses gtk-doc (a documentation generation utility), do not
     add a dependency on it. The tool is rather big and the distfile should come
     with pregenerated documentation anyway; if it does not, it is a bug that
     you ought to report. For such packages you should disable gtk-doc (unless
     it is the default):
     CONFIGURE_ARGS+=--disable-gtk-doc
     The default location of installed HTML files (share/gtk-doc/<package-name>)
     is correct and should not be changed unless the package insists on
     installing them somewhere else. Otherwise programs as devhelp will not be
     able to open them. You can do that with an entry similar to:
     CONFIGURE_ARGS+=--with-html-dir=${PREFIX}/share/gtk-doc/...
 GNOME uses multiple shared directories and files under the installation prefix
 to maintain databases. In this context, shared means that those exact same
 directories and files are used among several different packages, leading to
 conflicts in the PLIST. pkgsrc currently includes functionality to handle the
 most common cases, so you have to forget about using @unexec ${RMDIR} lines in
 your file lists and omitting shared files from them. If you find yourself doing
 those, your package is most likely incorrect.
 The following table lists the common situations that result in using shared
 directories or files. For each of them, the appropriate solution is given.
 After applying the solution be sure to regenerate the package's file list with
 make print-PLIST and ensure it is correct.
 Table 25.1. PLIST handling for GNOME packages
 +-----------------------------------------------------------------------------+
 |             If the package...             |             Then...             |
 |-------------------------------------------+---------------------------------|
 |                                           |See Section 21.6.10, "Packages   |
 |Installs OMF files under share/omf.        |installing scrollkeeper/rarian   |
 |                                           |data files".                     |
 |-------------------------------------------+---------------------------------|
 |Installs icons under the share/icons/      |See Section 21.6.19, "Packages   |
 |hicolor hierarchy or updates share/icons/  |installing hicolor theme icons". |
 |hicolor/icon-theme.cache.                  |                                 |
 |-------------------------------------------+---------------------------------|
 |                                           |See Section 21.6.14, "Packages   |
 |Installs files under share/mime/packages.  |installing extensions to the MIME|
 |                                           |database".                       |
 |-------------------------------------------+---------------------------------|
 |Installs .desktop files under share/       |See Section 21.6.20, "Packages   |
 |applications and these include MIME        |installing desktop files".       |
 |information.                               |                                 |
 +-----------------------------------------------------------------------------+
 .3. Updating GNOME to a newer version
 When seeing GNOME as a whole, there are two kinds of updates:
 Major update
     Given that there is still a very long way for GNOME 3 (if it ever appears),
     we consider a major update one that goes from a 2.X version to a 2.Y one,
     where Y is even and greater than X. These are hard to achieve because they
     introduce lots of changes in the components' code and almost all GNOME
     distfiles are updated to newer versions. Some of them can even break API
     and ABI compatibility with the previous major version series. As a result,
     the update needs to be done all at once to minimize breakage.
     A major update typically consists of around 80 package updates and the
     addition of some new ones.
 Minor update
     We consider a minor update one that goes from a 2.A.X version to a 2.A.Y
     one where Y is greater than X. These are easy to achieve because they do
     not update all GNOME components, can be done in an incremental way and do
     not break API nor ABI compatibility.
     A minor update typically consists of around 50 package updates, although
     the numbers here may vary a lot.
 In order to update the GNOME components in pkgsrc to a new stable release
 (either major or minor), the following steps should be followed:
 . Get a list of all the tarballs that form the new release by using the
     following commands. These will leave the full list of the components'
     distfiles into the list.txt file:
     % echo ls "*.tar.bz2" | \
         ftp -V ftp://ftp.gnome.org/pub/gnome/platform/x.y/x.y.z/sources/ | \
         awk '{ print $9 }' >list.txt
     % echo ls "*.tar.bz2" | \
         ftp -V ftp://ftp.gnome.org/pub/gnome/desktop/x.y/x.y.z/sources/ | \
         awk '{ print $9 }' >>list.txt
 . Open each meta package's Makefile and bump their version to the release you
     are updating them to. The three meta packages should be always consistent
     with versioning. Obviously remove any PKGREVISIONs that might be in them.
 . For each meta package, update all its DEPENDS lines to match the latest
     versions as shown by the above commands. Do not list any newer version
     (even if found in the FTP) because the meta packages are supposed to list
     the exact versions that form a specific GNOME release. Exceptions are
     permitted here if a newer version solves a serious issue in the overall
     desktop experience; these typically come in the form of a revision bump in
     pkgsrc, not in newer versions from the developers.
     Packages not listed in the list.txt file should be updated to the latest
     version available (if found in pkgsrc). This is the case, for example, of
     the dependencies on the GNU Autotools in the meta-pkgs/gnome-devel meta
     package.
 . Generate a patch from the modified meta packages and extract the list of
     "new" lines. This will provide you an outline on what packages need to be
     updated in pkgsrc and in what order:
     % cvs diff -u gnome-devel gnome-base gnome | grep '^+D' >todo.txt
 . For major desktop updates it is recommended to zap all your installed
     packages and start over from scratch at this point.
 . Now comes the longest step by far: iterate over the contents of todo.txt
     and update the packages listed in it in order. For major desktop updates
     none of these should be committed until the entire set is completed because
     there are chances of breaking not-yet-updated packages.
 . Once the packages are up to date and working, commit them to the tree one
     by one with appropriate log messages. At the end, commit the three meta
     package updates and all the corresponding changes to the doc/CHANGES-<YEAR>
     and pkgsrc/doc/TODO files.
 .4. Patching guidelines
 GNOME is a very big component in pkgsrc which approaches 100 packages. Please,
 it is very important that you always, always, always feed back any portability
 fixes you do to a GNOME package to the mainstream developers (see
 Section 13.3.5, "Feedback to the author"). This is the only way to get their
 attention on portability issues and to ensure that future versions can be built
 out-of-the box on NetBSD. The less custom patches in pkgsrc, the easier further
 updates are. Those developers in charge of issuing major GNOME updates will be
 grateful if you do that.
 The most common places to report bugs are the GNOME's Bugzilla and the
 freedesktop.org's Bugzilla. Not all components use these to track bugs, but
 most of them do. Do not be short on your reports: always provide detailed
 explanations of the current failure, how it can be improved to achieve maximum
 portability and, if at all possible, provide a patch against CVS head. The more
 verbose you are, the higher chances of your patch being accepted.
 Also, please avoid using preprocessor magic to fix portability issues. While
 the FreeBSD GNOME people are doing a great job in porting GNOME to their
 operating system, the official GNOME sources are now plagued by conditionals
 that check for __FreeBSD__ and similar macros. This hurts portability. Please
 see our patching guidelines (Section 13.3.4, "Patching guidelines") for more
 details.
 Part III. The pkgsrc infrastructure internals
 This part of the guide deals with everything from the infrastructure that is
 behind the interfaces described in the developer's guide. A casual package
 maintainer should not need anything from this part.
 Table of Contents
 . Design of the pkgsrc infrastructure
 .1. The meaning of variable definitions
 .2. Avoiding problems before they arise
 .3. Variable evaluation
 .3.1. At load time
 .3.2. At runtime
 .4. How can variables be specified?
 .5. Designing interfaces for Makefile fragments
 .5.1. Procedures with parameters
 .5.2. Actions taken on behalf of parameters
 .6. The order in which files are loaded
 .6.1. The order in bsd.prefs.mk
 .6.2. The order in bsd.pkg.mk
 . Regression tests
 .1. Running the regression tests
 .2. Adding a new regression test
 .2.1. Overridable functions
 .2.2. Helper functions
 . Porting pkgsrc
 .1. Porting pkgsrc to a new operating system
 Chapter 26. Design of the pkgsrc infrastructure
 Table of Contents
 .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
 The pkgsrc infrastructure consists of many small Makefile fragments. Each such
 fragment needs a properly specified interface. This chapter explains how such
 an interface looks like.
 .1. The meaning of variable definitions
 Whenever a variable is defined in the pkgsrc infrastructure, the location and
 the way of definition provide much information about the intended use of that
 variable. Additionally, more documentation may be found in a header comment or
 in this pkgsrc guide.
 A special file is mk/defaults/mk.conf, which lists all variables that are
 intended to be user-defined. They are either defined using the ?= operator or
 they are left undefined because defining them to anything would effectively
 mean "yes". All these variables may be overridden by the pkgsrc user in the
 MAKECONF file.
 Outside this file, the following conventions apply: Variables that are defined
 using the ?= operator may be overridden by a package.
 Variables that are defined using the = operator may be used read-only at
 run-time.
 Variables whose name starts with an underscore must not be accessed outside the
 pkgsrc infrastructure at all. They may change without further notice.
 Note
 These conventions are currently not applied consistently to the complete pkgsrc
 infrastructure.
 .2. Avoiding problems before they arise
 All variables that contain lists of things should default to being empty. Two
 examples that do not follow this rule are USE_LANGUAGES and DISTFILES. These
 variables cannot simply be modified using the += operator in package Makefiles
 (or other files included by them), since there is no guarantee whether the
 variable is already set or not, and what its value is. In the case of
 DISTFILES, the packages "know" the default value and just define it as in the
 following example.
 DISTFILES=      ${DISTNAME}${EXTRACT_SUFX} additional-files.tar.gz
 Because of the selection of this default value, the same value appears in many
 package Makefiles. Similarly for USE_LANGUAGES, but in this case the default
 value ("c") is so short that it doesn't stand out. Nevertheless it is mentioned
 in many files.
 .3. Variable evaluation
 .3.1. At load time
 Variable evaluation takes place either at load time or at runtime, depending on
 the context in which they occur. The contexts where variables are evaluated at
 load time are:
   * The right hand side of the := and != operators,
   * Make directives like .if or .for,
   * Dependency lines.
 A special exception are references to the iteration variables of .for loops,
 which are expanded inline, no matter in which context they appear.
 As the values of variables may change during load time, care must be taken not
 to evaluate them by accident. Typical examples for variables that should not be
 evaluated at load time are DEPENDS and CONFIGURE_ARGS. To make the effect more
 clear, here is an example:
 CONFIGURE_ARGS=         # none
 CFLAGS=                 -O
 CONFIGURE_ARGS+=        CFLAGS=${CFLAGS:Q}
 CONFIGURE_ARGS:=        ${CONFIGURE_ARGS}
 CFLAGS+=                -Wall
 This code shows how the use of the := operator can quickly lead to unexpected
 results. The first paragraph is fairly common code. The second paragraph
 evaluates the CONFIGURE_ARGS variable, which results in CFLAGS=-O. In the third
 paragraph, the -Wall is appended to the CFLAGS, but this addition will not
 appear in CONFIGURE_ARGS. In actual code, the three paragraphs from above
 typically occur in completely unrelated files.
 .3.2. At runtime
 After all the files have been loaded, the values of the variables cannot be
 changed anymore. Variables that are used in the shell commands are expanded at
 this point.
 .4. How can variables be specified?
 There are many ways in which the definition and use of a variable can be
 restricted in order to detect bugs and violations of the (mostly unwritten)
 policies. A package can be checked with pkglint -Wall to see whether it meets
 these rules.
 .5. Designing interfaces for Makefile fragments
 Most of the .mk files fall into one of the following classes. Cases where a
 file falls into more than one class should be avoided as it often leads to
 subtle bugs.
 .5.1. Procedures with parameters
 In a traditional imperative programming language some of the .mk files could be
 described as procedures. They take some input parameters and?after
 inclusion?provide a result in output parameters. Since all variables in
 Makefiles have global scope care must be taken not to use parameter names that
 have already another meaning. For example, PKGNAME is a bad choice for a
 parameter name.
 Procedures are completely evaluated at preprocessing time. That is, when
 calling a procedure all input parameters must be completely resolvable. For
 example, CONFIGURE_ARGS should never be an input parameter since it is very
 likely that further text will be added after calling the procedure, which would
 effectively apply the procedure to only a part of the variable. Also,
 references to other variables will be modified after calling the procedure.
 A procedure can declare its output parameters either as suitable for use in
 preprocessing directives or as only available at runtime. The latter
 alternative is for variables that contain references to other runtime
 variables.
 Procedures shall be written such that it is possible to call the procedure more
 than once. That is, the file must not contain multiple-inclusion guards.
 Examples for procedures are mk/bsd.options.mk and mk/buildlink3/bsd.builtin.mk.
 To express that the parameters are evaluated at load time, they should be
 assigned using the := operator, which should be used only for this purpose.
 .5.2. Actions taken on behalf of parameters
 Action files take some input parameters and may define runtime variables. They
 shall not define loadtime variables. There are action files that are included
 implicitly by the pkgsrc infrastructure, while other must be included
 explicitly.
 An example for action files is mk/subst.mk.
 .6. The order in which files are loaded
 Package Makefiles usually consist of a set of variable definitions, and include
 the file ../../mk/bsd.pkg.mk in the very last line. Before that, they may also
 include various other *.mk files if they need to query the availability of
 certain features like the type of compiler or the X11 implementation. Due to
 the heavy use of preprocessor directives like .if and .for, the order in which
 the files are loaded matters.
 This section describes at which point the various files are loaded and gives
 reasons for that order.
 .6.1. The order in bsd.prefs.mk
 The very first action in bsd.prefs.mk is to define some essential variables
 like OPSYS, OS_VERSION and MACHINE_ARCH.
 Then, the user settings are loaded from the file specified in MAKECONF, which
 is usually mk.conf. After that, those variables that have not been overridden
 by the user are loaded from mk/defaults/mk.conf.
 After the user settings, the system settings and platform settings are loaded,
 which may override the user settings.
 Then, the tool definitions are loaded. The tool wrappers are not yet in effect.
 This only happens when building a package, so the proper variables must be used
 instead of the direct tool names.
 As the last steps, some essential variables from the wrapper and the package
 system flavor are loaded, as well as the variables that have been cached in
 earlier phases of a package build.
 .6.2. The order in bsd.pkg.mk
 First, bsd.prefs.mk is loaded.
 Then, the various *-vars.mk files are loaded, which fill default values for
 those variables that have not been defined by the package. These variables may
 later be used even in unrelated files.
 Then, the file bsd.pkg.error.mk provides the target error-check that is added
 as a special dependency to all other targets that use DELAYED_ERROR_MSG or
 DELAYED_WARNING_MSG.
 Then, the package-specific hacks from hacks.mk are included.
 Then, various other files follow. Most of them don't have any dependencies on
 what they need to have included before or after them, though some do.
 The code to check PKG_FAIL_REASON and PKG_SKIP_REASON is then executed, which
 restricts the use of these variables to all the files that have been included
 before. Appearances in later files will be silently ignored.
 Then, the files for the main targets are included, in the order of later
 execution, though the actual order should not matter.
 At last, some more files are included that don't set any interesting variables
 but rather just define make targets to be executed.
 Chapter 27. Regression tests
 Table of Contents
 .1. Running the regression tests
 .2. Adding a new regression test
 .2.1. Overridable functions
 .2.2. Helper functions
 The pkgsrc infrastructure consists of a large codebase, and there are many
 corners where every little bit of a file is well thought out, making pkgsrc
 likely to fail as soon as anything is changed near those parts. To prevent most
 changes from breaking anything, a suite of regression tests should go along
 with every important part of the pkgsrc infrastructure. This chapter describes
 how regression tests work in pkgsrc and how you can add new tests.
 .1. Running the regression tests
 You first need to install the pkgtools/pkg_regress package, which provides the
 pkg_regress command. Then you can simply run that command, which will run all
 tests in the regress/ directory.
 .2. Adding a new regression test
 Every directory in the regress/ directory that contains a file called spec is
 considered a regression test. This file is a shell program that is included by
 the pkg_regress command. The following functions can be overridden to suit your
 needs.
 .2.1. Overridable functions
 These functions do not take any parameters. Although they are called in "set -e
 " mode, they don't stop at the first failing command. See this Stack Overflow
 question for details.
 do_setup
     This function prepares the environment for the test. By default it does
     nothing.
 do_test
     This function runs the actual test. By default, it calls TEST_MAKE with the
     arguments MAKEARGS_TEST and writes its output including error messages into
     the file TEST_OUTFILE.
     When defining this function, make sure that all output that needs to be
     checked is written to the correct output file. Example:
     do_test() {
             echo "Example output"
     } 1>$TEST_OUTFILE 2>&1
 check_result
     This function is run after the test and is typically used to compare the
     actual output from the one that is expected. It can make use of the various
     helper functions from the next section. Example:
     check_result() {
             exit_status 0
             output_require "Example"
             output_require "^[[:alpha:]+[[:space:]][[:alpha:]]{6}$"
             output_prohibit "no such file or directory"
             regress_fail "expected $expected but got $actual for input $input"
+    }
 do_cleanup
     This function cleans everything up after the test has been run. By default
     it does nothing.
 .2.2. Helper functions
 regress_fail message...
     This function makes the test fail with the given error message.
 exit_status expected
     This function compares the exitcode of the do_test function with its first
     parameter. If they differ, the test will fail.
 output_require regex...
     This function checks for each of its parameters if the output from do_test
     matches the extended regular expression. If it does not, the test will
     fail. Example:
     output_require "looks fine"
     output_require "^[[:alpha:]+[[:space:]][[:alpha:]]{6}$"
 output_prohibit(regex...)
     This function checks for each of its parameters if the output from do_test
     () does not match the extended regular expression. If any of the regular
     expressions matches, the test will fail.
 Chapter 28. Porting pkgsrc
 Table of Contents
 .1. Porting pkgsrc to a new operating system
 The pkgsrc system has already been ported to many operating systems, hardware
 architectures and compilers. This chapter explains the necessary steps to make
 pkgsrc even more portable.
 .1. Porting pkgsrc to a new operating system
 To port pkgsrc to a new operating system (called MyOS in this example), you
 need to touch the following files:
 pkgtools/bootstrap-mk-files/files/mods/MyOS.sys.mk
     This file contains some basic definitions, for example the name of the C
     compiler.
 mk/bsd.prefs.mk
     Insert code that defines the variables OPSYS, OS_VERSION, LOWER_OS_VERSION,
     LOWER_VENDOR, MACHINE_ARCH, OBJECT_FMT, APPEND_ELF, and the other variables
     that appear in this file.
 mk/platform/MyOS.mk
     This file contains the platform-specific definitions that are used by
     pkgsrc. Start by copying one of the other files and edit it to your needs.
 mk/tools/tools.MyOS.mk
     This file defines the paths to all the tools that are needed by one or the
     other package in pkgsrc, as well as by pkgsrc itself. Find out where these
     tools are on your platform and add them.
 Now, you should be able to build some basic packages, like lang/perl5, shells/
 bash.
 Appendix A. A simple example package: bison
 Table of Contents
 A.1. files
     A.1.1. Makefile
     A.1.2. DESCR
     A.1.3. PLIST
     A.1.4. Checking a package with pkglint
 A.2. Steps for building, installing, packaging
 We checked to find a piece of software that wasn't in the packages collection,
 and picked GNU bison. Quite why someone would want to have bison when Berkeley
 yacc is already present in the tree is beyond us, but it's useful for the
 purposes of this exercise.
 A.1. files
 A.1.1. Makefile
 # $NetBSD$
+#
 DISTNAME=       bison-1.25
 CATEGORIES=     devel
-MASTER_SITES=   ${MASTER_SITE_GNU}
+MASTER_SITES=   ${MASTER_SITE_GNU:=bison/}
 MAINTAINER=     pkgsrc-users@NetBSD.org
 HOMEPAGE=       http://www.gnu.org/software/bison/bison.html
 COMMENT=        GNU yacc clone
 GNU_CONFIGURE=  yes
 INFO_FILES=     yes
 .include "../../mk/bsd.pkg.mk"
 A.1.2. DESCR
 GNU version of yacc.  Can make re-entrant parsers, and numerous other
 improvements.  Why you would want this when Berkeley yacc(1) is part
 of the NetBSD source tree is beyond me.
 A.1.3. PLIST
 @comment $NetBSD$
 bin/bison
 man/man1/bison.1.gz
 share/bison.simple
 share/bison.hairy
 A.1.4. Checking a package with pkglint
 The NetBSD package system comes with pkgtools/pkglint which helps to check the
 contents of these files. After installation it is quite easy to use, just
-change to the directory of the package you wish to examine and execute pkglint:
+change to the directory of the package you wish to examine and run pkglint:
 $ pkglint
-looks fine.
+ERROR: Makefile: Each package must define its LICENSE.
 WARN: Makefile:9: HOMEPAGE should migrate from http to https.
 NOTE: PLIST:3: The .gz extension is unnecessary for manual pages.
 WARN: PLIST:5: "share/bison.hairy" should be sorted before "share/bison.simple".
 error, 2 warnings and 1 note found.
 (Run "pkglint -e" to show explanations.)
 (Run "pkglint -fs" to show what can be fixed automatically.)
 (Run "pkglint.exe -F" to automatically fix some issues.)
 Depending on the supplied command line arguments (see pkglint(1)), more checks
 will be performed. Use e.g. pkglint -Wall for a very thorough check.
 A.2. Steps for building, installing, packaging
 Create the directory where the package lives, plus any auxiliary directories:
 # cd /usr/pkgsrc/lang
 # mkdir bison
 # cd bison
 # mkdir patches
 Create Makefile, DESCR and PLIST (see Chapter 13, Package components - files,
 directories and contents) then continue with fetching the distfile:
 # make fetch
 >> bison-1.25.tar.gz doesn't seem to exist on this system.
 >> Attempting to fetch from ftp://prep.ai.mit.edu/pub/gnu//.
 Requesting ftp://prep.ai.mit.edu/pub/gnu//bison-1.25.tar.gz (via ftp://orpheus.amdahl.com:80/)
 ftp: Error retrieving file: 500 Internal error
 >> Attempting to fetch from ftp://wuarchive.wustl.edu/systems/gnu//.
 Requesting ftp://wuarchive.wustl.edu/systems/gnu//bison-1.25.tar.gz (via ftp://orpheus.amdahl.com:80/)
 ftp: Error retrieving file: 500 Internal error
 >> Attempting to fetch from ftp://ftp.freebsd.org/pub/FreeBSD/distfiles//.
 Requesting ftp://ftp.freebsd.org/pub/FreeBSD/distfiles//bison-1.25.tar.gz (via ftp://orpheus.amdahl.com:80/)
 Successfully retrieved file.
 Generate the checksum of the distfile into distinfo:
 # make makedistinfo
 Now compile:
 # make
 >> Checksum OK for bison-1.25.tar.gz.
 ===>  Extracting for bison-1.25
 ===>  Patching for bison-1.25
 ===>   Ignoring empty patch directory
 ===>  Configuring for bison-1.25
 creating cache ./config.cache
 checking for gcc... cc
 checking whether we are using GNU C... yes
 checking for a BSD compatible install... /usr/bin/install -c -o bin -g bin
 checking how to run the C preprocessor... cc -E
 checking for minix/config.h... no
 checking for POSIXized ISC... no
 checking whether cross-compiling... no
 checking for ANSI C header files... yes
 checking for string.h... yes
 checking for stdlib.h... yes
 checking for memory.h... yes
 checking for working const... yes
 checking for working alloca.h... no
 checking for alloca... yes
 checking for strerror... yes
 updating cache ./config.cache
 creating ./config.status
 creating Makefile
 ===>  Building for bison-1.25
 cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include  -g LR0.c
 cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include  -g allocate.c
 cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include  -g closure.c
 cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include  -g conflicts.c
 cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include  -g derives.c
 cc -c -DXPFILE=\"/usr/pkg/share/bison.simple\"  -DXPFILE1=\"/usr/pkg/share/bison.hairy\" -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1  -g  ./files.c
 cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include  -g getargs.c
 cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include  -g gram.c
 cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include  -g lalr.c
 cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include  -g lex.c
 cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include  -g main.c
 cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include  -g nullable.c
 cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include  -g output.c
 cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include  -g print.c
 cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include  -g reader.c
 cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include  -g reduce.c
 cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include  -g symtab.c
 cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include  -g warshall.c
 cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include  -g version.c
 cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include  -g getopt.c
 cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include  -g getopt1.c
 cc  -g -o bison LR0.o allocate.o closure.o conflicts.o derives.o files.o         getargs.o gram.o lalr.o lex.o                                   main.o nullable.o output.o print.o reader.o reduce.o symtab.o   warshall.o version.o getopt.o getopt1.o
 ./files.c:240: warning: mktemp() possibly used unsafely, consider using mkstemp()
 rm -f bison.s1
 sed -e "/^#line/ s|bison|/usr/pkg/share/bison|" < ./bison.simple > bison.s1
 Everything seems OK, so install the files:
 # make install
 >> Checksum OK for bison-1.25.tar.gz.
 ===>  Installing for bison-1.25
 sh ./mkinstalldirs /usr/pkg/bin /usr/pkg/share  /usr/pkg/info /usr/pkg/man/man1
 rm -f /usr/pkg/bin/bison
 cd /usr/pkg/share; rm -f bison.simple bison.hairy
 rm -f /usr/pkg/man/man1/bison.1 /usr/pkg/info/bison.info*
 install -c  -o bin -g bin -m 555 bison /usr/pkg/bin/bison
 /usr/bin/install -c -o bin -g bin -m 644 bison.s1 /usr/pkg/share/bison.simple
 /usr/bin/install -c -o bin -g bin -m 644 ./bison.hairy /usr/pkg/share/bison.hairy
 cd .; for f in bison.info*;  do /usr/bin/install -c -o bin -g bin -m 644 $f /usr/pkg/info/$f; done
 /usr/bin/install -c -o bin -g bin -m 644 ./bison.1 /usr/pkg/man/man1/bison.1
 ===>  Registering installation for bison-1.25
 You can now use bison, and also - if you decide so - remove it with pkg_delete
 bison. Should you decide that you want a binary package, do this now:
 # make package
 >> Checksum OK for bison-1.25.tar.gz.
 ===>  Building package for bison-1.25
 Creating package bison-1.25.tgz
 Registering depends:.
 Creating gzip'd tar ball in '/u/pkgsrc/lang/bison/bison-1.25.tgz'
 Now that you don't need the source and object files any more, clean up:
 # make clean
 ===>  Cleaning for bison-1.25
 Appendix B. Build logs
 Table of Contents
 B.1. Building figlet
 B.2. Packaging figlet
 B.1. Building figlet
 # make
 ===> Checking for vulnerabilities in figlet-2.2.1nb2
 => figlet221.tar.gz doesn't seem to exist on this system.
 => Attempting to fetch figlet221.tar.gz from ftp://ftp.figlet.org/pub/figlet/program/unix/.
 => [172219 bytes]
 Connected to ftp.plig.net.
 ftp.plig.org NcFTPd Server (licensed copy) ready.
 Guest login ok, send your complete e-mail address as password.
 -You are user #5 of 500 simultaneous users allowed.
 -
 -  ___ _             _ _
 - |  _| |_ ___   ___| |_|___   ___ ___ ___
 - |  _|  _| . |_| . | | | . |_| . |  _| . |
 - |_| |_| |  _|_|  _|_|_|_  |_|___|_| |_  |
 -         |_|   |_|     |___|         |___|
 -
 -** Welcome to ftp.plig.org **
 -
 -Please note that all transfers from this FTP site are logged. If you
 -do not like this, please disconnect now.
 -
 -This archive is available via
 -
 -HTTP:  http://ftp.plig.org/
 -FTP:   ftp://ftp.plig.org/     (max 500 connections)
 -RSYNC: rsync://ftp.plig.org/   (max  30 connections)
 -
 -Please email comments, bug reports and requests for packages to be
 -mirrored to ftp-admin@plig.org.
 -
 -
 Logged in anonymously.
 Remote system type is UNIX.
 Using binary mode to transfer files.
 Type okay.
 "/pub" is new cwd.
 -"/pub/figlet" is new cwd.
 -
 -Welcome to the figlet archive at ftp.figlet.org
 -
 -    ftp://ftp.figlet.org/pub/figlet/
 -
 -The official FIGlet web page is:
 -    http://www.figlet.org/
 -
 -If you have questions, please mailto:info@figlet.org. If you want to
 -contribute a font or something else, you can email us.
 "/pub/figlet/program" is new cwd.
 "/pub/figlet/program/unix" is new cwd.
 local: figlet221.tar.gz remote: figlet221.tar.gz
 Unimplemented command.
 Entering Passive Mode (195,40,6,41,246,104)
 Data connection accepted from 84.128.86.72:65131; transfer starting for figlet221.tar.gz (172219 bytes).
 % |**************                       | 65800      64.16 KB/s    00:01 ETA
 Transfer completed.
 bytes received in 00:02 (75.99 KB/s)
 Goodbye.
 => Checksum OK for figlet221.tar.gz.
 ===> Extracting for figlet-2.2.1nb2
 ===> Required installed package ccache-[0-9]*: ccache-2.3nb1 found
 ===> Patching for figlet-2.2.1nb2
 ===> Applying pkgsrc patches for figlet-2.2.1nb2
 ===> Overriding tools for figlet-2.2.1nb2
 ===> Creating toolchain wrappers for figlet-2.2.1nb2
 ===> Configuring for figlet-2.2.1nb2
 ===> Building for figlet-2.2.1nb2
 gcc -O2 -DDEFAULTFONTDIR=\"/usr/pkg/share/figlet\"  -DDEFAULTFONTFILE=\"standard.flf\"  figlet.c zipio.c crc.c inflate.c -o figlet
 chmod a+x figlet
 gcc -O2 -o chkfont chkfont.c
 => Unwrapping files-to-be-installed.
+#
 # make install
 ===> Checking for vulnerabilities in figlet-2.2.1nb2
 ===> Installing for figlet-2.2.1nb2
 install -d -o root -g wheel -m 755 /usr/pkg/bin
 install -d -o root -g wheel -m 755 /usr/pkg/man/man6
 mkdir -p /usr/pkg/share/figlet
 cp figlet /usr/pkg/bin
 cp chkfont /usr/pkg/bin
 chmod 555 figlist showfigfonts
 cp figlist /usr/pkg/bin
 cp showfigfonts /usr/pkg/bin
 cp fonts/*.flf /usr/pkg/share/figlet
 cp fonts/*.flc /usr/pkg/share/figlet
 cp figlet.6 /usr/pkg/man/man6
 ===> Registering installation for figlet-2.2.1nb2
+#
 B.2. Packaging figlet
 # make package
 ===> Checking for vulnerabilities in figlet-2.2.1nb2
 ===> Packaging figlet-2.2.1nb2
 ===> Building binary package for figlet-2.2.1nb2
 Creating package /home/cvs/pkgsrc/packages/i386/All/figlet-2.2.1nb2.tgz
 Using SrcDir value of /usr/pkg
 Registering depends:.
+#
 Appendix C. Directory layout of the pkgsrc FTP server
 Table of Contents
 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
 As in other big projects, the directory layout of pkgsrc is quite complex for
 newbies. This chapter explains where you find things on the FTP server. The
 base directory on ftp.NetBSD.org is /pub/pkgsrc/. On other servers it may be
 different, but inside this directory, everything should look the same, no
 matter on which server you are. This directory contains some subdirectories,
 which are explained below.
 C.1. distfiles: The distributed source files
 The directory distfiles contains lots of archive files from all pkgsrc
 packages, which are mirrored here. The subdirectories are called after their
 package names and are used when the distributed files have names that don't
 explicitly contain a version number or are otherwise too generic (for example
 release.tar.gz).
 C.2. misc: Miscellaneous things
 This directory contains things that individual pkgsrc developers find worth
 publishing.
 C.3. packages: Binary packages
 This directory contains binary packages for the various platforms that are
 supported by pkgsrc. Each subdirectory is of the form OPSYS/ARCH/OSVERSION_TAG.
 The meaning of these variables is:
   * OPSYS is the name of the operating system for which the packages have been
     built. The name is taken from the output of the uname command, so it may
     differ from the one you are used to hear.
   * ARCH is the hardware architecture of the platform for which the packages
     have been built. It also includes the ABI (Application Binary Interface)
     for platforms that have several of them.
   * OSVERSION is the version of the operating system. For version numbers that
     change often (for example NetBSD-current), the often-changing part should
     be replaced with an x, for example 4.99.x.
   * TAG is either 20xxQy for a stable branch, or head for packages built from
     the HEAD branch. The latter should only be used when the packages are
     updated on a regular basis. Otherwise the date from checking out pkgsrc
     should be appended, for example head_20071015.
 The rationale for exactly this scheme is that the pkgsrc users looking for
 binary packages can quickly click through the directories on the server and
 find the best binary packages for their machines. Since they usually know the
 operating system and the hardware architecture, OPSYS and ARCH are placed
 first. After these choices, they can select the best combination of OSVERSION
 and TAG together, since it is usually the case that packages stay compatible
 between different version of the operating system.
 In each of these directories, there is a whole binary packages collection for a
 specific platform. It has a directory called All which contains all binary
 packages. Besides that, there are various category directories that contain
 symbolic links to the real binary packages.
 C.4. reports: Bulk build reports
 Here are the reports from bulk builds, for those who want to fix packages that
 didn't build on some of the platforms. The structure of subdirectories should
 look like the one in Section C.3, "packages: Binary packages".
 C.5. current, stable, pkgsrc-20xxQy: source packages
 These directories contain the "real" pkgsrc, that is the files that define how
 to create binary packages from source archives.
 Each of the current, stable and pkgsrc-20xxQy directories share the same
 structure. They each contain a pkgsrc directory and pkgsrc.tar.{bz,gz,xz} file.
 The directory pkgsrc contains a snapshot of the CVS repository, which is
 updated regularly. The file pkgsrc.tar.{bz,gz,xz} contains the same as the
 directory, ready to be downloaded as a whole.
 The current directory contains files related to the HEAD branch of the CVS
 repository. In this directory there is an additional file called
 pkgsrc-readmes.tar.{bz,gz,xz} that contains all pkgsrc READMEs with information
 about categories and packages.
 The stable directory is a symlink to the latest pkgsrc-20xxQy.
 The pkgsrc-20xxQy. directories contain files related to the -20xxQy stable
 branch of the CVS repository. In these directories there is an additional file
 called pkgsrc-20xxQy.tar.{bz,gz,xz}, which contains the state of pkgsrc when it
 was branched.
 Appendix D. Help topics
 The following list contains all help topics that are available when running
 bmake help topic=:index.
 #!                               -lintl
 bit                            ABI
 ACCEPTABLE_LICENSES              ACROREAD_FONTPATH
 ADDITIONAL                       AFAIK
 AIX                              ALLOW_VULNERABLE_PACKAGES
 ALL_ENV                          ALSA_PC
 ALTERNATIVES_SRC                 AMANDA_TMP
 AMANDA_USER                      AMANDA_VAR
 APACHE_GROUP                     APACHE_MODULE_NAME
 APACHE_MODULE_SRC                APACHE_MODULE_SRCDIR
 APACHE_PKG_PREFIX                APACHE_SUEXEC_CONFIGURE_ARGS
 APACHE_SUEXEC_DOCROOT            APACHE_USER
 APPEND_ABI                       APPEND_ELF
 ARLA_CACHE                       AUDIT_PACKAGES_FLAGS
 AUTOCONF_REQD                    AUTOMAKE_OVERRIDE
 AUTOMAKE_REQD                    AUTO_MKDIRS
 BDB185_DEFAULT                   BDBBASE
 BDB_ACCEPTED                     BDB_DEFAULT
 BDB_LIBS                         BDB_TYPE
 BIND_DIR                         BIND_GROUP
 BIND_USER                        BINPKG_SITES
 BIN_INSTALL_FLAGS                BISON_PKGDATADIR
 BLAS_ACCEPTED                    BLAS_LIBS
 BLAS_TYPE                        BOOTSTRAP_DEPENDS
 BOOTSTRAP_SETUPTOOLS             BROKEN
 BROKEN_EXCEPT_ON_PLATFORM        BROKEN_ON_PLATFORM
 BSDSRCDIR                        BSDXSRCDIR
 BSD_MAKE_ENV                     BUILDLINK_AUTO_DIRS
 BUILDLINK_AUTO_VARS              BUILDLINK_CFLAGS
 BUILDLINK_CONTENTS_FILTER        BUILDLINK_CPPFLAGS
 BUILDLINK_DEPMETHOD              BUILDLINK_FILES
 BUILDLINK_FILES_CMD              BUILDLINK_FNAME_TRANSFORM
 BUILDLINK_LDFLAGS                BUILDLINK_LIBS
 BUILDLINK_OPSYS_SUPPORT_PTHREAD  BUILDLINK_PKGNAME
 BUILDLINK_PREFIX                 BUILDLINK_RPATHDIRS
 BUILDLINK_TREE                   BUILD_DEFS
 BUILD_DEFS_EFFECTS               BUILD_DEPENDS
 BUILD_DIRS                       BUILD_ENV_SHELL
 BUILD_MAKE_CMD                   BUILD_MAKE_FLAGS
 BUILD_TARGET                     BUILTIN_FIND_FILES
 BUILTIN_FIND_FILES_VAR           BUILTIN_FIND_GREP
 BUILTIN_FIND_HEADERS             BUILTIN_FIND_HEADERS_VAR
 BUILTIN_PKG                      BUILTIN_TEST_CURSES_DEFINES
 BUILTIN_TEST_CURSES_FUNCS        BUILTIN_VERSION_SCRIPT
 BUILTIN_X11_TYPE                 BUILTIN_X11_VERSION
 CACTI_GROUP                      CACTI_USER
 CANNA_GROUP                      CANNA_USER
 CAT                              CCACHE_BASE
 CCACHE_DIR                       CCACHE_LOGFILE
 CC_VERSION                       CC_VERSION_STRING
 CDRECORD_CONF                    CDROM_PKG_URL_DIR
 CDROM_PKG_URL_HOST               CHECKOUT_DATE
 CHECK_FAKEHOME                   CHECK_FILES
 CHECK_FILES_SKIP                 CHECK_FILES_STRICT
 CHECK_HEADERS                    CHECK_HEADERS_SKIP
 CHECK_INTERPRETER                CHECK_INTERPRETER_SKIP
 CHECK_PERMS                      CHECK_PERMS_AUTOFIX
 CHECK_PERMS_SKIP                 CHECK_PORTABILITY
 CHECK_PORTABILITY_SKIP           CHECK_RELRO
 CHECK_RELRO_SKIP                 CHECK_RELRO_SUPPORTED
 CHECK_SHLIBS                     CHECK_SHLIBS_BLACKLIST
 CHECK_SHLIBS_SKIP                CHECK_SHLIBS_SUPPORTED
 CHECK_SSP                        CHECK_SSP_SKIP
 CHECK_SSP_SUPPORTED              CHECK_STRIPPED
 CHECK_STRIPPED_SKIP              CHECK_WRKREF
 CHECK_WRKREF_EXTRA_DIRS          CHECK_WRKREF_SKIP
 CLAMAV_DBDIR                     CLAMAV_GROUP
 CLAMAV_USER                      CLANGBASE
 CLEANDEPENDS                     CMAKE_DEPENDENCIES_REWRITE
 CMAKE_INSTALL_PREFIX             CMAKE_MODULE_PATH_OVERRIDE
 CMAKE_PKGSRC_BUILD_FLAGS         CMAKE_PREFIX_PATH
 CMAKE_USE_GNU_INSTALL_DIRS       COMMON_LISP_DOCFILES
 COMMON_LISP_EXAMPLES             COMMON_LISP_EXTRAFILES
 COMMON_LISP_PACKAGES             COMMON_LISP_SYSTEM
 COMPILER_RPATH_FLAG              COMPILER_USE_SYMLINKS
 CONFIGURE_ARGS                   CONFIGURE_DIRS
 CONFIGURE_ENV                    CONFIGURE_HAS_INFODIR
 CONFIGURE_HAS_MANDIR             CONFIGURE_SCRIPT
 CONFIG_SHELL                     CONFIG_SHELL_FLAGS
 CONF_FILES                       CONF_FILES_MODE
 CONF_FILES_PERMS                 CONSERVER_DEFAULTHOST
 CONSERVER_DEFAULTPORT            CP
 CPP                              CPP_PRECOMP_FLAGS
 CREATE_WRKDIR_SYMLINK            CROSSBASE
 CTFCONVERT                       CTF_FILES_SKIP
 CTF_SUPPORTED                    CTYPE
 CUPS_GROUP                       CUPS_SYSTEM_GROUPS
 CUPS_USER                        CURSES_DEFAULT
 CURSES_TYPE                      CVS_EXTRACTDIR
 CVS_MODULE                       CVS_PROJECT
 CVS_REPOSITORIES                 CVS_ROOT
 CVS_ROOT_GNU                     CVS_ROOT_NONGNU
 CVS_ROOT_SOURCEFORGE             CVS_TAG
 CXX                              CYRUS_GROUP
 CYRUS_IDLE                       CYRUS_USER
 DAEMONTOOLS_GROUP                DAEMONTOOLS_LOG_USER
 DBUS_GROUP                       DBUS_USER
 DEFANG_GROUP                     DEFANG_USER
 DEFAULT_ACCEPTABLE_LICENSES      DEFAULT_DISTFILES
 DEFAULT_IRC_SERVER               DEFAULT_SERIAL_DEVICE
 DEF_UMASK                        DEINSTALLDEPENDS
 DEINSTALL_SRC                    DEINSTALL_TEMPLATES
 DELAYED_ERROR_MSG                DELAYED_WARNING_MSG
 DEPENDS                          DEPENDS_TARGET
 DEPENDS_TYPE                     DESTDIR
 DESTDIR_VARNAME                  DIALER_GROUP
 DIGEST_REQD                      DISTDIR
 DISTFILES                        DISTINFO_FILE
 DISTNAME                         DIST_PATH
 DIST_SUBDIR                      DJBDNS_AXFR_USER
 DJBDNS_CACHE_USER                DJBDNS_DJBDNS_GROUP
 DJBDNS_LOG_USER                  DJBDNS_RBL_USER
 DJBDNS_TINY_USER                 DLOPEN_REQUIRE_PTHREADS
 DL_AUTO_VARS                     DL_CFLAGS
 DL_LDFLAGS                       DL_LIBS
 DNS                              DOWNLOADED_DISTFILE
 DT_LAYOUT                        DYNAMIC_SITES_CMD
 DYNAMIC_SITES_SCRIPT             ECHO
 ECHO_N                           ELK_GUI
 EMACS_TYPE                       EMULDIR
 EMULSUBDIR                       EMULSUBDIRSLASH
 EMUL_ARCH                        EMUL_DISTRO
 EMUL_EXEC_FMT                    EMUL_IS_NATIVE
 EMUL_MODULES                     EMUL_OPSYS
 EMUL_PKG_FMT                     EMUL_PLATFORM
 EMUL_PLATFORMS                   EMUL_PREFER
 EMUL_REQD                        EMUL_TYPE
 ERROR_MSG                        EXIM_GROUP
 EXIM_USER                        EXPORT_SYMBOLS_LDFLAGS
 EXTRACTOR                        EXTRACT_CMD
 EXTRACT_CMD_DEFAULT              EXTRACT_DIR
 EXTRACT_ELEMENTS                 EXTRACT_ENV
 EXTRACT_ONLY                     EXTRACT_OPTS
 EXTRACT_SUFX                     EXTRACT_USING
 FAILOVER_FETCH                   FAIL_MSG
 FAKE_NCURSES                     FAM
 FAM_ACCEPTED                     FAM_DEFAULT
 FAM_SERVER                       FCPATH
 FEATURE_CPPFLAGS                 FEATURE_LDFLAGS
 FEATURE_LIBS                     FETCH_AFTER_ARGS
 FETCH_BEFORE_ARGS                FETCH_CMD
 FETCH_OUTPUT_ARGS                FETCH_PROXY
 FETCH_RESUME_ARGS                FETCH_USING
 FILES_SUBST                      FILES_SUBST_SED
 FIX_SYSTEM_HEADERS               FLUXBOX_USE_GNOME
 FLUXBOX_USE_KDE                  FLUXBOX_USE_XFT
 FLUXBOX_USE_XINERAMA             FONTDIR
 FONTS_DIRS                       FONTS_VERBOSE
 FOO_HACKS_MK                     FOSSIL_EXTRACTDIR
 FOSSIL_REPO                      FOSSIL_REPOSITORIES
 FOSSIL_VERSION                   FOX_USE_XUNICODE
 FREEWNN_GROUP                    FREEWNN_USER
 FTP_PKG_URL_DIR                  FTP_PKG_URL_HOST
 GAMEDATAMODE                     GAMEDATA_PERMS
 GAMEDIRMODE                      GAMEDIR_PERMS
 GAMEGRP                          GAMEMODE
 GAMEOWN                          GAMES_GROUP
 GAMES_USER                       GCC
 GCCBASE                          GCC_REQD
 GCC_VERSION_SUFFIX               GEM_BUILD
 GEM_CLEANBUILD                   GEM_CLEANBUILD_EXTENSIONS
 GEM_DOCDIR                       GEM_EXTSDIR
 GEM_HOME                         GEM_LIBDIR
 GEM_NAME                         GEM_PATH
 GEM_SPECFILE                     GENERATE_PLIST
 GHOSTSCRIPT_REQD                 GITHUB_PROJECT
 GITHUB_RELEASE                   GITHUB_TAG
 GITHUB_TYPE                      GIT_BRANCH
 GIT_ENV                          GIT_EXTRACTDIR
 GIT_REPO                         GIT_REPOSITORIES
 GIT_REVISION                     GIT_TAG
 GNU                              GNU_CONFIGURE
 GNU_CONFIGURE_INFODIR            GNU_CONFIGURE_MANDIR
 GNU_CONFIGURE_STRICT             GODEP_REDIRECTS
 GO_BUILD_PATTERN                 GO_DEPS
 GO_DIST_BASE                     GO_SRCPATH
 GO_VERSION_DEFAULT               GROUP_SPECIFIC_PKGS
 GRUB_NETWORK_CARDS               GRUB_PRESET_COMMAND
 GRUB_SCAN_ARGS                   GZIP
 HASKELL_COMPILER                 HASKELL_ENABLE_HADDOCK_DOCUMENTATION
 HASKELL_ENABLE_LIBRARY_PROFILING HASKELL_ENABLE_SHARED_LIBRARY
 HASKELL_OPTIMIZATION_LEVEL       HAS_CONFIGURE
 HEADER_TEMPLATES                 HG_REPO
 HG_REPOSITORIES                  HG_TAG
 HOST_PKGTOOLS_ARGS               HOST_SPECIFIC_PKGS
 HOWL_GROUP                       HOWL_USER
 ICCBASE                          ICECAST_CHROOTDIR
 ICON_THEMES                      IDOBASE
 IGNORE_CCACHE                    IGNORE_INFO_DIRS
 IGNORE_INTERACTIVE_FETCH         IMAKE
 IMAKEOPTS                        IMAKE_MAKE
 IMAKE_MANINSTALL                 IMAP_UW_CCLIENT_MBOX_FMT
 IMDICTDIR                        INCOMPAT_CURSES
 INFO_DIR                         INFO_FILES
 INFO_FILES_VERBOSE               INFO_MSG
 INIT_SYSTEM                      INN_DATA_DIR
 INN_GROUP                        INN_USER
 INSTALLATION_DIRS                INSTALLATION_DIRS_FROM_PLIST
 INSTALL_ENV                      INSTALL_SH_OVERRIDE
 INSTALL_SRC                      INSTALL_TEMPLATES
 INSTALL_UNSTRIPPED               IRCD_HYBRID_IRC_GROUP
 IRCD_HYBRID_IRC_USER             IRCD_HYBRID_MAXCONN
 IRCD_HYBRID_NICLEN               IRCD_HYBRID_SYSLOG_EVENTS
 IRCD_HYBRID_SYSLOG_FACILITY      IRCD_HYBRID_TOPICLEN
 IRIX                             IRRD_USE_PGP
 JABBERD_GROUP                    JABBERD_LOGDIR
 JABBERD_PIDDIR                   JABBERD_SPOOLDIR
 JABBERD_USER                     JAKARTA_HOME
 JAVA_APP_PATH                    JAVA_APP_TARGETS
 JAVA_BINPREFIX                   JAVA_CLASSPATH
 JAVA_HOME                        JAVA_LD_LIBRARY_PATH
 JAVA_NAME                        JAVA_UNLIMIT
 JAVA_WRAPPERS                    JPEG_ACCEPTED
 JPEG_DEFAULT                     KERBEROS
 KERMIT_SUID_UUCP                 KJS_USE_PCRE
 KNEWS_DOMAIN_FILE                KNEWS_DOMAIN_NAME
 KRB5_ACCEPTED                    KRB5_DEFAULT
 LANGUAGES                        LAPACK_LIBS
 LATEX2HTML_ICONPATH              LDCONFIG_ADD_CMD
 LDCONFIG_REMOVE_CMD              LEAFNODE_DATA_DIR
 LEAFNODE_GROUP                   LEAFNODE_USER
 LIBDVDCSS_HOMEPAGE               LIBDVDCSS_MASTER_SITES
 LIBRSVG_TYPE                     LIBTOOL
 LIBTOOLIZE_PLIST                 LIBTOOL_M4_OVERRIDE
 LIBUSB_TYPE                      LICENSE
 LINKER_RPATH_FLAG                LINK_RPATH_FLAG
 LINUX_BASE_NODEPS                LINUX_BASE_PREFERRED
 LINUX_BASE_REQUIRED              LINUX_LOCALES
 LOCALBASE                        LOCALBASE_LOCKTYPE
 LOCALPATCHES                     LOVE_DATA
 LOVE_GAME                        LOVE_VERSION
 LP64PLATFORMS                    MACHINE_PLATFORM
 MAILAGENT_DOMAIN                 MAILAGENT_EMAIL
 MAILAGENT_FQDN                   MAILAGENT_ORGANIZATION
 MAJORDOMO_HOMEDIR                MAJOR_OS_VERSION
 MAKEINFO_ARGS                    MAKE_DIRS
 MAKE_DIRS_PERMS                  MAKE_ENV
 MAKE_FILE                        MAKE_FLAGS
 MAKE_JOBS                        MAKE_JOBS_SAFE
 MAKE_PROGRAM                     MANINSTALL
 MANZ                             MASTER_SITES
 MASTER_SITE_BACKUP               MASTER_SITE_CYGWIN
 MASTER_SITE_GNOME                MASTER_SITE_GNU
 MASTER_SITE_LOCAL                MASTER_SITE_MOZILLA
 MASTER_SITE_OPENOFFICE           MASTER_SITE_OVERRIDE
 MASTER_SITE_PERL_CPAN            MASTER_SITE_SUNSITE
 MASTER_SITE_SUSE                 MASTER_SITE_TEX_CTAN
 MASTER_SITE_XCONTRIB             MASTER_SITE_XEMACS
 MASTER_SORT                      MASTER_SORT_RANDOM
 MASTER_SORT_REGEX                MECAB_CHARSET
 MEDIATOMB_GROUP                  MEDIATOMB_USER
 MIPSPROBASE                      MIREDO_GROUP
 MIREDO_USER                      MISSING_FEATURES
 MKDIR                            MLDONKEY_GROUP
 MLDONKEY_HOME                    MLDONKEY_USER
 MONOTONE_GROUP                   MONOTONE_USER
 MOTIFBASE                        MOTIF_TYPE
 MOTIF_TYPE_DEFAULT               MPI_TYPE
 MSGFMT_STRIP_MSGCTXT             MSGFMT_STRIP_MSGID_PLURAL
 MTOOLS_ENABLE_FLOPPYD            MUST
 MV                               MYSQL_CHARSET
 MYSQL_DATADIR                    MYSQL_EXTRA_CHARSET
 MYSQL_GROUP                      MYSQL_PKGSRCDIR
 MYSQL_USER                       MYSQL_VERSIONS_ACCEPTED
 MYSQL_VERSION_DEFAULT            NAGIOSCMD_GROUP
 NAGIOSDIR                        NAGIOS_GROUP
 NAGIOS_USER                      NATIVE_APPEND_ABI
 NATIVE_APPEND_ELF                NATIVE_EXEC_FMT
 NATIVE_MACHINE_PLATFORM          NATIVE_OBJECT_FMT
 NBPAX_PROGRAM_PREFIX             NETBSD_LOGIN_NAME
 NMH_EDITOR                       NMH_MTA
 NMH_PAGER                        NOLOGIN
 NONZERO_FILESIZE_P               NOTE
 NOT_FOR_PLATFORM                 NOT_PAX_ASLR_SAFE
 NOT_PAX_MPROTECT_SAFE            NO_BUILD
 NO_CHECKSUM                      NO_CONFIGURE
 NO_SKIP                          NS_PREFERRED
 NULLMAILER_GROUP                 NULLMAILER_USER
 OASIS                            OASIS_BUILD_ARGS
 OBJHOSTNAME                      OBJMACHINE
 OCAML_FINDLIB_DIRS               OCAML_FINDLIB_REGISTER
 OCAML_FINDLIB_REGISTER_VERBOSE   OCAML_SITELIBDIR
 OCAML_TOPKG_DOCDIR               OCAML_USE_DUNE
 OCAML_USE_FINDLIB                OCAML_USE_JBUILDER
 OCAML_USE_OASIS                  OCAML_USE_OASIS_DYNRUN
 OCAML_USE_OPAM                   OCAML_USE_OPT_COMPILER
 OCAML_USE_TOPKG                  OMF
 ONLY_FOR_COMPILER                ONLY_FOR_PLATFORM
 OPENSSH_CHROOT                   OPENSSH_GROUP
 OPENSSH_USER                     OPSYS
 OPSYS_EMULDIR                    OSS_TYPE
 OSX                              OSX_TOLERATE_SDK_SKEW
 OS_HAVE_ALSA                     OS_HAVE_RCD
 OS_VARIANT                       OS_VERSION
 OTF_FONTS_DIR                    OVERRIDE_DIRDEPTH
 OVERRIDE_GEMSPEC                 OVERRIDE_GNU_CONFIG_SCRIPTS
 OVERRIDE_ROCKSPEC                OWN_DIRS
 OWN_DIRS_PERMS                   P4GROUP
 P4PORT                           P4ROOT
 P4USER                           PACKAGES
 PALMOS_DEFAULT_SDK               PAMBASE
 PAM_DEFAULT                      PAPERSIZE
 PASSIVE_FETCH                    PATCHDIR
 PATCHFILES                       PATCH_ARGS
 PATCH_DEBUG                      PATCH_DIST_ARGS
 PATCH_DIST_CAT                   PATCH_DIST_STRIP
 PATCH_FUZZ_FACTOR                PATCH_STRIP
 PATH                             PCCBASE
 PEAR                             PEAR_CHANNEL
 PEAR_CHANNEL_ALIAS               PEAR_CHANNEL_VERSION
 PEAR_CMD                         PEAR_LIB
 PEAR_PACKAGE_XML                 PERL5
 PERL5_CONFIGURE                  PERL5_CONFIGURE_DIRS
 PERL5_LDFLAGS                    PERL5_LICENSE
 PERL5_MODULE_TYPE                PERL5_PACKLIST
 PERL5_PACKLIST_DIR               PERL5_PERLBASE
 PERL5_SITEBASE                   PERL5_USE_PACKLIST
 PERL5_VENDORBASE                 PFCTL
 PFVAR_H                          PF_VERSION
 PGGROUP                          PGHOME
 PGPKGSRCDIR                      PGSQL_TYPE
 PGSQL_VERSIONS_ACCEPTED          PGSQL_VERSION_DEFAULT
 PGUSER                           PG_LIB_EXT
 PHP                              PHPCOMMON_MK
 PHPPKGSRCDIR                     PHP_BASE_VERS
 PHP_CHECK_INSTALLED              PHP_EXTENSION_DIR
 PHP_INITIAL_TEENY                PHP_PKG_PREFIX
 PHP_VERSION                      PHP_VERSIONS_ACCEPTED
 PHP_VERSIONS_INCOMPATIBLE        PHP_VERSION_DEFAULT
 PHP_VERSION_REQD                 PILRC_USE_GTK
 PKGCONFIG_BASE                   PKGCONFIG_FILE
 PKGCONFIG_OVERRIDE               PKGCONFIG_OVERRIDE_STAGE
 PKGDIR                           PKGGNUDIR
 PKGINFODIR                       PKGLOCALEDIR
 PKGMANDIR                        PKGNAME
 PKGNAME_REQD                     PKGPATH
 PKGREVISION                      PKGSRC_BLAS_TYPES
 PKGSRC_CHANGES                   PKGSRC_COMPILER
 PKGSRC_KEEP_BIN_PKGS             PKGSRC_LOCKTYPE
 PKGSRC_MAKE_ENV                  PKGSRC_MESSAGE_RECIPIENTS
 PKGSRC_MKPIE                     PKGSRC_MKREPRO
 PKGSRC_RUN_TEST                  PKGSRC_SETENV
 PKGSRC_SLEEPSECS                 PKGSRC_TODO
 PKGSRC_USE_CTF                   PKGSRC_USE_FORTIFY
 PKGSRC_USE_RELRO                 PKGSRC_USE_SSP
 PKGSRC_USE_STACK_CHECK           PKGTASKS_DATAFILE
 PKGTOOLS_ARGS                    PKGTOOLS_ENV
 PKG_ALTERNATIVES                 PKG_APACHE
 PKG_APACHE_ACCEPTED              PKG_APACHE_DEFAULT
 PKG_BEST_EXISTS                  PKG_BUILD_OPTIONS
 PKG_COMPRESSION                  PKG_CONFIG
 PKG_CONFIG_PERMS                 PKG_CREATE_USERGROUP
 PKG_DB_TMPDIR                    PKG_DEBUG_LEVEL
 PKG_DEFAULT_OPTIONS              PKG_DESTDIR_SUPPORT
 PKG_DEVELOPER                    PKG_DISABLED_OPTIONS
 PKG_FATAL_ERRORS                 PKG_FC
 PKG_FILELIST_CMD                 PKG_GECOS
 PKG_GID                          PKG_GROUPS
 PKG_GROUPS_VARS                  PKG_HOME
 PKG_INIT_SCRIPTS                 PKG_JAVA_HOME
 PKG_JVM                          PKG_JVMS_ACCEPTED
 PKG_JVM_DEFAULT                  PKG_LEGACY_OPTIONS
 PKG_LIBTOOL                      PKG_OPTIONS
 PKG_OPTIONS_DEPRECATED_WARNINGS  PKG_OPTIONS_LEGACY_OPTS
 PKG_OPTIONS_LEGACY_VARS          PKG_OPTIONS_NONEMPTY_SETS
 PKG_OPTIONS_OPTIONAL_GROUPS      PKG_OPTIONS_REQUIRED_GROUPS
 PKG_OPTIONS_VAR                  PKG_PHP
 PKG_PHP_MAJOR_VERS               PKG_PHP_VERSION
 PKG_RCD_SCRIPTS                  PKG_REFCOUNT_DBDIR
 PKG_REGISTER_SHELLS              PKG_RESUME_TRANSFERS
 PKG_SHELL                        PKG_SUGGESTED_OPTIONS
 PKG_SUPPORTED_OPTIONS            PKG_SYSCONFBASE
 PKG_SYSCONFBASEDIR               PKG_SYSCONFDIR
 PKG_SYSCONFDIR_PERMS             PKG_SYSCONFSUBDIR
 PKG_SYSCONFVAR                   PKG_TOOLS_BIN
 PKG_UID                          PKG_UPDATE_FONTS_DB
 PKG_USERS                        PKG_USERS_VARS
 PKG_VERBOSE                      PLIST
 PLIST_AWK                        PLIST_AWK_ENV
 PLIST_SRC                        PLIST_SUBST
 PLIST_TYPE                       PLIST_VARS
 POPTOP_USE_MPPE                  POST_FETCH_HOOK
 PREFER                           PREFER_NATIVE
 PREFER_NATIVE_PTHREADS           PREFER_PKGSRC
 PREFIX                           PREPEND_PATH
 PRE_ROOT_CMD                     PRIVILEGED_STAGES
 PS                               PTHREAD_AUTO_VARS
 PTHREAD_CFLAGS                   PTHREAD_LDFLAGS
 PTHREAD_LIBS                     PTHREAD_OPTS
 PTHREAD_TYPE                     PVM_SSH
 PYPKGPREFIX                      PYTHON_FOR_BUILD_ONLY
 PYTHON_SELF_CONFLICT             PYTHON_VERSIONED_DEPENDENCIES
 PYTHON_VERSIONS_ACCEPTED         PYTHON_VERSIONS_INCOMPATIBLE
 PYTHON_VERSION_DEFAULT           PYTHON_VERSION_REQD
 PYVERSSUFFIX                     PY_NO_EGG
 QMAILDIR                         QMAIL_ALIAS_USER
 QMAIL_DAEMON_USER                QMAIL_LOG_USER
 QMAIL_NOFILES_GROUP              QMAIL_PASSWD_USER
 QMAIL_QMAIL_GROUP                QMAIL_QUEUE_DIR
 QMAIL_QUEUE_EXTRA                QMAIL_QUEUE_USER
 QMAIL_REMOTE_USER                QMAIL_ROOT_USER
 QMAIL_SEND_USER                  QPOPPER_FAC
 QPOPPER_SPOOL_DIR                QPOPPER_USER
 RAKE_NAME                        RASMOL_DEPTH
 RCD_DIR                          RCD_ORDER
 RCD_SCRIPTS                      RCD_SCRIPTS_DIR
 RCD_SCRIPTS_EXAMPLEDIR           RCD_SCRIPTS_MODE
 RCD_SCRIPTS_SHELL                RCD_SCRIPT_SRC
 RCD_SUBR                         RDOC
 READLINE_DEFAULT                 READLINE_TYPE
 REAL_ROOT_GROUP                  REAL_ROOT_USER
 RECURSIVE_MAKE                   RELAY_CTRL_DIR
 REPLACE_AWK                      REPLACE_BASH
 REPLACE_CSH                      REPLACE_KSH
 REPLACE_PERL                     REPLACE_PERL6
 REPLACE_PHP                      REPLACE_PYTHON
 REPLACE_RUBY                     REPLACE_RUBY_DIRS
 REPLACE_RUBY_PAT                 REPLACE_SH
 REPLACE_TEXLUA                   REQD_DIRS
 REQD_DIRS_PERMS                  REQD_FILES
 REQD_FILES_MODE                  REQD_FILES_PERMS
 RESOLV_AUTO_VARS                 RESOLV_LDFLAGS
 RESOLV_LIBS                      RM
 ROCKSPEC_NAME                    ROCKSPEC_SPECFILE
 ROOT_CMD                         ROOT_GROUP
 ROOT_USER                        RPCGEN
 RPM                              RPM2PKG_PLIST
 RPM2PKG_PREFIX                   RPM2PKG_STAGE
 RPM2PKG_STRIP                    RPM2PKG_SUBPREFIX
 RPMFILES                         RPMIGNOREPATH
 RPM_DB_PREFIX                    RSSH_CVS_PATH
 RSSH_RDIST_PATH                  RSSH_RSYNC_PATH
 RSSH_SCP_PATH                    RSSH_SFTP_SERVER_PATH
 RUBY                             RUBYGEM
 RUBYGEM_NAME                     RUBYGEM_OPTIONS
 RUBY_ABI_VERSION                 RUBY_ARCH
 RUBY_ARCHINC                     RUBY_ARCHLIB
 RUBY_BASE                        RUBY_BASERIDIR
 RUBY_BUILD_DOCUMENT              RUBY_DLEXT
 RUBY_DOC                         RUBY_DYNAMIC_DIRS
 RUBY_EG                          RUBY_ENCODING_ARG
 RUBY_EXTCONF                     RUBY_EXTCONF_CHECK
 RUBY_EXTCONF_DEBUG               RUBY_EXTCONF_MAKEFILE
 RUBY_GEM_BASE                    RUBY_INC
 RUBY_LIB                         RUBY_LIB_BASE
 RUBY_NAME                        RUBY_NOVERSION
 RUBY_PKGPREFIX                   RUBY_RAILS
 RUBY_RAILS42_VERSION             RUBY_RAILS51_VERSION
 RUBY_RAILS52_VERSION             RUBY_RAILS_ACCEPTED
 RUBY_RAILS_DEFAULT               RUBY_RAILS_REQD
 RUBY_RAILS_STRICT_DEP            RUBY_RIDIR
 RUBY_SETUP                       RUBY_SHLIB
 RUBY_SHLIBALIAS                  RUBY_SHLIBVER
 RUBY_SIMPLE_INSTALL              RUBY_SITEARCHLIB
 RUBY_SITELIB                     RUBY_SITELIB_BASE
 RUBY_SITERIDIR                   RUBY_SLEXT
 RUBY_SRCDIR                      RUBY_STATICLIB
 RUBY_SUFFIX                      RUBY_SYSRIDIR
 RUBY_USE_PTHREAD                 RUBY_VENDORARCHLIB
 RUBY_VENDORLIB                   RUBY_VENDORLIB_BASE
 RUBY_VER                         RUBY_VERSION
 RUBY_VERSIONS_ACCEPTED           RUBY_VERSION_DEFAULT
 RUBY_VERSION_REQD                RUBY_VER_DIR
 RUN                              RUN_LDCONFIG
 SAWFISH_THEMES                   SCO
 SCREWS_GROUP                     SCREWS_USER
 SCRIPTS_ENV                      SCROLLKEEPER_DATADIR
 SCROLLKEEPER_REBUILDDB           SCROLLKEEPER_UPDATEDB
 SDIST_PAWD                       SERIAL_DEVICES
 SETGIDGAME                       SETGID_GAMES_PERMS
 SETUID_ROOT_PERMS                SH
 SHLIB                            SHORTNAME
 SIGN_PACKAGES                    SILC_CLIENT_WITH_PERL
 SITE_SPECIFIC_PKGS               SKIP_DEPENDS
 SMF_INSTANCES                    SMF_MANIFEST
 SMF_METHODS                      SMF_METHOD_SHELL
 SMF_METHOD_SRC                   SMF_NAME
 SMF_PREFIX                       SMF_SRCDIR
 SNIPROXY_GROUP                   SNIPROXY_USER
 SOURCE_BUFFSIZE                  SPECIAL_PERMS
 SPECIFIC_PKGS                    SSH_SUID
 SSP_SUPPORTED                    SSYNC_PAWD
 STEP_MSG                         STRIP
 STRIP_DBG                        STRIP_DEBUG
 STRIP_DEBUG_SUPPORTED            STRIP_FILES_SKIP
 SU                               SUBDIR
 SUBST_CLASSES                    SUBST_FILES
 SUBST_FILTER_CMD                 SUBST_MESSAGE
 SUBST_SED                        SUBST_SHOW_DIFF
 SUBST_SKIP_TEXT_CHECK            SUBST_STAGE
 SUBST_VARS                       SUNWSPROBASE
 SUSE_PREFER                      SU_CMD
 SVN_EXTRACTDIR                   SVN_REPO
 SVN_REPOSITORIES                 SVN_REVISION
 TERMCAP_TYPE                     TERMINFO_DEFAULT
 TERMINFO_TYPE                    TEST
 TEST_DEPENDS                     TEST_DIRS
 TEST_ENV                         TEST_MAKE_CMD
 TEST_MAKE_FLAGS                  TEST_TARGET
 TEXLIVE_IGNORE_PATTERNS          TEXLIVE_REV
 TEXLIVE_UNVERSIONED              TEXMFSITE
 TEX_FORMATS                      TEX_HYPHEN_DAT
 TEX_HYPHEN_DEF                   TEX_TEXMF_DIRS
 THTTPD_LOG_FACILITY              TO
 TOOLS_ALIASES                    TOOLS_ARGS
 TOOLS_BROKEN                     TOOLS_CMD
 TOOLS_CREATE                     TOOLS_DIR
 TOOLS_FAIL                       TOOLS_GNU_MISSING
 TOOLS_LDCONFIG                   TOOLS_NOOP
 TOOLS_PATH                       TOOLS_SCRIPT
 TOOL_DEPENDS                     TTF_FONTDIR
 TTF_FONTS_DIR                    TYPE
 UAC_REQD_EXECS                   UCSPI_SSL_GROUP
 UCSPI_SSL_USER                   UNLIMIT_RESOURCES
 UNPRIVILEGED                     UNPRIVILEGED_GROUP
 UNPRIVILEGED_GROUPS              UNPRIVILEGED_USER
 UNWRAP_FILES                     UNWRAP_PATTERNS
 UPDATE_GEMSPEC                   UPDATE_TARGET
 URI                              USA
 USERGROUP_PHASE                  USERPPP_GROUP
 USER_SPECIFIC_PKGS               USE_ABI_DEPENDS
 USE_APR                          USE_BSD_MAKEFILE
 USE_BUILTIN                      USE_CROSS_COMPILE
 USE_CURSES                       USE_CWRAPPERS
 USE_DB185                        USE_FEATURES
 USE_GAMESGROUP                   USE_GCC_RUNTIME
 USE_IMAKE                        USE_JAVA
 USE_JAVA2                        USE_LANGUAGES
 USE_LIBTOOL                      USE_NATIVE_GCC
 USE_NETBSD_REPO                  USE_PKGSRC_GCC
 USE_PKGSRC_GCC_RUNTIME           USE_PKGTASKS
 USE_PKG_ADMIN_DIGEST             USE_RUBY_EXTCONF
 USE_RUBY_INSTALL                 USE_RUBY_SETUP
 USE_RUBY_SETUP_PKG               USE_TOOLS
 UUCP_GROUP                       UUCP_USER
 VARBASE                          VARNAME
 VIM_EXTRA_OPTS                   WARNING_MSG
 WCALC_CGIDIR                     WCALC_CGIPATH
 WCALC_HTMLDIR                    WCALC_HTMLPATH
 WDM_MANAGERS                     WRAPPER_REORDER_CMDS
 WRKDIR                           WRKDIR_BASENAME
 WRKDIR_LOCKTYPE                  WRKLOG
 WRKOBJDIR                        WRKSRC
 WXGTK_ACCEPTED                   WXGTK_DEFAULT
 X10_PORT                         X11
 X11BASE                          X11_PKGSRCDIR
 X11_TYPE                         X509_CERTIFICATE
 X509_KEY                         XAW_TYPE
 XLOCK_DEFAULT_MODE               XMKMF_FLAGS
 XXX                              XXXX
 YES                              ZERO_FILESIZE_P
 ZSH_STATIC                       __stdc__
 _vargroups                       add
 all                              alternatives
 aslr                             asprintf
 atlas                            autoconf
 automake                         autoreconf
 awk                              bash
 big-endian                       bin-install
 binpkg-list                      blas
 bootstrap-depends                broken
 broken_on_platform               build
 build-env                        buildlink-directories
 buildlink-oss-soundcard-h        c
 c++                              ccache
 cce                              cdefs
 changes                          changes-entry
 changes-entry-noupdate           check
 check-clean                      check-files
 check-files-clean                check-vulnerable
 checksum                         checksum-phase
 clean                            clean-depends
 cleandir                         commit
 commit-changes-entry             compact
 compiler                         conf
 config.guess                     config.sub
 configuration                    configure
 configure-help                   configure_args
 cputime                          create-usergroup
 csh                              ctf
 cvs                              debug
 declaration                      declare
 defined                          depend
 dependencies                     depends
 depends-checksum                 depends-fetch
 deps                             describe
 destdir                          disable
 distclean                        distinfo
 dl                               dlopen
 do-build                         do-buildlink
 do-clean                         do-configure
 do-configure-post-hook           do-extract
 do-fetch                         do-install
 emul                             emulation
 emulator                         enable
 endian                           enomem
 err                              errx
 etc                              feature
 features                         fetch
 fetch-list                       follows
 forbids                          form
 format                           fortify
 fortify_source                   fossil
 friend                           from
 fts                              fts_close
 fts_open                         fts_read
 fts_set                          full
 gcc                              getopt_long
 getprogname                      gettext
 git                              github
 glob                             gnu
 gnu_configure_strict             go
 go-deps                          golang
 guess-license                    hashbang
 heimdal                          help
 hg                               imake
 increment                        interp
 interpreter                      intl
 iso                              kerberos
 krb                              krb5
 ksh                              lapack
 latex                            libnbcompat
 libs                             libtool
 licence                          license
 lintl                            little-endian
 lock                             locking
 lvalue                           make
 makesum                          memory
 mercurial                        meta
 meta-package                     meta_package
 mit-krb5                         mk.conf
 mkl                              mount
 mprotect                         mremap
 nb                               nbcompat
 no                               obstack
 obstack_ptr_grow                 occurs
 only                             openblas
 options                          options.mk
 order                            override
 override-intltool                override-message-intltool
 package                          parallel
 partial                          path
 pax                              paxctl
 pbulk-index                      pc
 perl                             perl5
 perms                            php
 pkg-build-options                pkg-config
 pkg_build_options                platform
 plist                            post-extract
 post-fetch                       post-wrapper
 pre-configure                    pre-extract
 pre-fetch                        print-go-deps
 print-plist                      print-summary-data
 privileged-install-hook          pypi
 python                           readme-all
 regcomp                          relro
 rename                           reorder
 replace                          replace_interpreter
 reproducible                     resolv
 root                             ruby
 setenv                           setgid
 setprogname                      setuid
 sh                               show
 show-all                         show-build-defs
 show-depends                     show-deps
 show-distfiles                   show-downlevel
 show-subdir-var                  show-tools
 show-var                         show-vars
 snprintf                         ssp
 st_mode                          stage-install