pkgsrc-Changes archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
CVS commit: pkgsrc/doc
Module Name: pkgsrc
Committed By: leot
Date: Sun Dec 21 11:17:54 UTC 2025
Modified Files:
pkgsrc/doc: pkgsrc.html pkgsrc.txt
Log Message:
doc/pkgsrc.*: regen
To generate a diff of this commit:
cvs rdiff -u -r1.384 -r1.385 pkgsrc/doc/pkgsrc.html
cvs rdiff -u -r1.382 -r1.383 pkgsrc/doc/pkgsrc.txt
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
Modified files:
Index: pkgsrc/doc/pkgsrc.html
diff -u pkgsrc/doc/pkgsrc.html:1.384 pkgsrc/doc/pkgsrc.html:1.385
--- pkgsrc/doc/pkgsrc.html:1.384 Wed Jul 2 16:30:34 2025
+++ pkgsrc/doc/pkgsrc.html Sun Dec 21 11:17:54 2025
@@ -1,7 +1,7 @@
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
-<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
+<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<title>The pkgsrc guide</title>
<link rel="stylesheet" type="text/css" href="/global.css">
<meta name="generator" content="DocBook XSL Stylesheets VX.X.X">
@@ -30,7 +30,7 @@
The pkgsrc Developers
</h3>
</div></div>
-<div><p class="copyright">Copyright � 1994-2025 The NetBSD Foundation, Inc</p></div>
+<div><p class="copyright">Copyright © 1994-2025 The NetBSD Foundation, Inc</p></div>
<div><p class="pubdate">$NetBSD: pkgsrc.xml,v 1.45 2025/04/17 22:00:11 wiz Exp $</p></div>
<div><div class="abstract">
<p class="title"><b>Abstract</b></p>
@@ -158,15 +158,15 @@ builds)</a></span></dt>
<dt><span class="sect1"><a href="#fetch-https">10.7. How to fetch files from HTTPS sites</a></span></dt>
<dt><span class="sect1"><a href="#passive-ftp">10.8. How do I tell <span class="command"><strong>make fetch</strong></span> to do passive FTP?</a></span></dt>
<dt><span class="sect1"><a href="#fetching-all-distfiles">10.9. How to fetch all distfiles at once</a></span></dt>
-<dt><span class="sect1"><a href="#tmac.andoc-missing">10.10. What does <span class="quote">“<span class="quote">Don't know how to make
-/usr/share/tmac/tmac.andoc</span>”</span> mean?</a></span></dt>
-<dt><span class="sect1"><a href="#bsd.own.mk-missing">10.11. What does <span class="quote">“<span class="quote">Could not find bsd.own.mk</span>”</span> mean?</a></span></dt>
+<dt><span class="sect1"><a href="#tmac.andoc-missing">10.10. What does <span class="quote">“<span class="quote">Don't know how to make
+/usr/share/tmac/tmac.andoc</span>”</span> mean?</a></span></dt>
+<dt><span class="sect1"><a href="#bsd.own.mk-missing">10.11. What does <span class="quote">“<span class="quote">Could not find bsd.own.mk</span>”</span> mean?</a></span></dt>
<dt><span class="sect1"><a href="#using-sudo-with-pkgsrc">10.12. Using 'sudo' or `priv` with pkgsrc</a></span></dt>
<dt><span class="sect1"><a href="#faq.conf">10.13. How do I change the location of configuration files?</a></span></dt>
<dt><span class="sect1"><a href="#audit-packages">10.14. Automated security checks</a></span></dt>
<dt><span class="sect1"><a href="#ufaq-cflags">10.15. Why do some packages ignore my <code class="varname">CFLAGS</code>?</a></span></dt>
<dt><span class="sect1"><a href="#ufaq-fail">10.16. A package does not build. What shall I do?</a></span></dt>
-<dt><span class="sect1"><a href="#faq.rcs-conflicts">10.17. What does <span class="quote">“<span class="quote">Makefile appears to contain unresolved cvs/rcs/??? merge
conflicts</span>”</span> mean?</a></span></dt>
+<dt><span class="sect1"><a href="#faq.rcs-conflicts">10.17. What does <span class="quote">“<span class="quote">Makefile appears to contain unresolved cvs/rcs/??? merge conflicts</span>”</span>
mean?</a></span></dt>
</dl></dd>
</dl></dd>
<dt><span class="part"><a href="#developers-guide">II. The pkgsrc developer's guide</a></span></dt>
@@ -351,7 +351,7 @@ builds)</a></span></dt>
<dt><span class="sect2"><a href="#fixes.build.cpp">21.5.1. Compiling C and C++ code conditionally</a></span></dt>
<dt><span class="sect2"><a href="#compiler-bugs">21.5.2. How to handle compiler bugs</a></span></dt>
<dt><span class="sect2"><a href="#fixes.build.header">21.5.3. No such file or directory</a></span></dt>
-<dt><span class="sect2"><a href="#undefined-reference">21.5.4. Undefined reference to <span class="quote">“<span class="quote">...</span>”</span></a></span></dt>
+<dt><span class="sect2"><a href="#undefined-reference">21.5.4. Undefined reference to <span class="quote">“<span class="quote">...</span>”</span></a></span></dt>
<dt><span class="sect2"><a href="#out-of-memory">21.5.5. Running out of memory</a></span></dt>
</dl></dd>
<dt><span class="sect1"><a href="#fixes.install">21.6. The <span class="emphasis"><em>install</em></span> phase</a></span></dt>
@@ -511,7 +511,7 @@ source packages</a></span></dt>
</div>
<div class="chapter">
<div class="titlepage"><div><div><h1 class="title">
-<a name="introduction"></a>Chapter�1.�What is pkgsrc?</h1></div></div></div>
+<a name="introduction"></a>Chapter 1. What is pkgsrc?</h1></div></div></div>
<div class="toc">
<p><b>Table of Contents</b></p>
<dl class="toc">
@@ -528,7 +528,7 @@ source packages</a></span></dt>
</div>
<div class="sect1">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="introduction-section"></a>1.1.�Introduction</h2></div></div></div>
+<a name="introduction-section"></a>1.1. Introduction</h2></div></div></div>
<p>There is a lot of software freely available for Unix-based
systems, which is usually available in form of the source code. Before
such software can be used, it needs to be configured to the local
@@ -548,13 +548,13 @@ packages for himself, which is a time-co
<li class="listitem"><p><a href="https://cdn.NetBSD.org/pub/pkgsrc/current/pkgsrc/meta-pkgs/kde4/index.html" target="_top"><code class="filename">meta-pkgs/kde4</code></a> - The K
Desktop Environment</p></li>
</ul></div>
-<p>… just to name a few.</p>
+<p>… just to name a few.</p>
<p>pkgsrc has built-in support for handling varying dependencies,
such as pthreads and X11, and extended features such as IPv6 support on
a range of platforms.</p>
<div class="sect2">
<div class="titlepage"><div><div><h3 class="title">
-<a name="why-pkgsrc"></a>1.1.1.�Why pkgsrc?</h3></div></div></div>
+<a name="why-pkgsrc"></a>1.1.1. Why pkgsrc?</h3></div></div></div>
<p>
pkgsrc provides the following key features:
</p>
@@ -589,14 +589,14 @@ pkgsrc provides the following key featur
</ul></div>
<p>The following principles are basic to pkgsrc:</p>
<div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; ">
-<li class="listitem"><p><span class="quote">“<span class="quote">It should only work if it's right.</span>”</span>
+<li class="listitem"><p><span class="quote">“<span class="quote">It should only work if it's right.</span>”</span>
— That means, if a package contains bugs, it's better to find
them and to complain about them rather than to just install the package
and hope that it works. There are numerous checks in pkgsrc that try to
find such bugs: static analysis tools (<a href="https://cdn.NetBSD.org/pub/pkgsrc/current/pkgsrc/pkgtools/pkglint/index.html" target="_top"><code class="filename">pkgtools/pkglint</code></a>),
build-time checks (portability
of shell scripts), and post-installation checks (installed files,
references to shared libraries, script interpreters).</p></li>
-<li class="listitem"><p><span class="quote">“<span class="quote">If it works, it should work everywhere</span>”</span>
+<li class="listitem"><p><span class="quote">“<span class="quote">If it works, it should work everywhere</span>”</span>
— Like NetBSD has been ported to many hardware architectures,
pkgsrc has been ported to many operating systems. Care is taken that
packages behave the same on all platforms.</p></li>
@@ -604,7 +604,7 @@ packages behave the same on all platform
</div>
<div class="sect2">
<div class="titlepage"><div><div><h3 class="title">
-<a name="intro.platforms"></a>1.1.2.�Supported platforms</h3></div></div></div>
+<a name="intro.platforms"></a>1.1.2. Supported platforms</h3></div></div></div>
<p>pkgsrc consists of both a source distribution and a binary
distribution for these operating systems. After retrieving the required
source or binaries, you can be up and running with pkgsrc in just
@@ -613,7 +613,7 @@ minutes!</p>
initially developed for NetBSD only. Since then, pkgsrc has
grown a lot, and now supports the following platforms:</p>
<div class="table">
-<a name="supported-platforms"></a><p class="title"><b>Table�1.1.�Platforms supported by pkgsrc</b></p>
+<a name="supported-platforms"></a><p class="title"><b>Table 1.1. Platforms supported by pkgsrc</b></p>
<div class="table-contents"><table class="table" summary="Platforms supported by pkgsrc" border="1">
<colgroup>
<col>
@@ -629,7 +629,7 @@ minutes!</p>
<tr>
<td><a class="ulink" href="https://www.NetBSD.org/" target="_top">NetBSD</a></td>
<td align="center">Aug 1997</td>
-<td class="auto-generated">�</td>
+<td class="auto-generated"> </td>
</tr>
<tr>
<td><a class="ulink" href="http://wwws.sun.com/software/solaris/" target="_top">Solaris</a></td>
@@ -686,7 +686,7 @@ minutes!</p>
<tr>
<td><a class="ulink" href="https://www.dragonflybsd.org/" target="_top">DragonFlyBSD</a></td>
<td align="center">Oct 2004</td>
-<td class="auto-generated">�</td>
+<td class="auto-generated"> </td>
</tr>
<tr>
<td><a class="ulink" href="http://www.tru64.org/" target="_top">OSF/1</a></td>
@@ -736,16 +736,16 @@ minutes!</p>
</div>
<div class="sect1">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="overview"></a>1.2.�Overview</h2></div></div></div>
+<a name="overview"></a>1.2. Overview</h2></div></div></div>
<p>This document is divided into three parts. The first,
- <a class="link" href="#users-guide" title="Part�I.�The pkgsrc user's guide">The pkgsrc user's guide</a>,
+ <a class="link" href="#users-guide" title="Part I. The pkgsrc user's guide">The pkgsrc user's guide</a>,
describes how one can use one of the packages in the Package
Collection, either by installing a precompiled binary package,
or by building one's own copy using the NetBSD package system.
- The second part, <a class="link" href="#developers-guide" title="Part�II.�The pkgsrc developer's guide">The pkgsrc developer's guide</a>, explains how to prepare a
+ The second part, <a class="link" href="#developers-guide" title="Part II. The pkgsrc developer's guide">The pkgsrc developer's guide</a>, explains how to prepare a
package so it can be easily built by other NetBSD users without
knowing about the package's building details. The third part,
- <a class="link" href="#infrastructure" title="Part�III.�The pkgsrc infrastructure internals">The pkgsrc infrastructure internals</a>
+ <a class="link" href="#infrastructure" title="Part III. The pkgsrc infrastructure internals">The pkgsrc infrastructure internals</a>
is intended for those who want to understand how pkgsrc is
implemented.</p>
<p>This document is available in various formats:
@@ -753,9 +753,9 @@ minutes!</p>
</div>
<div class="sect1">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="terminology"></a>1.3.�Terminology</h2></div></div></div>
-<p>There has been a lot of talk about <span class="quote">“<span class="quote">ports</span>”</span>,
- <span class="quote">“<span class="quote">packages</span>”</span>, etc. so far. Here is a description of all the
+<a name="terminology"></a>1.3. Terminology</h2></div></div></div>
+<p>There has been a lot of talk about <span class="quote">“<span class="quote">ports</span>”</span>,
+ <span class="quote">“<span class="quote">packages</span>”</span>, etc. so far. Here is a description of all the
terminology used within this document.</p>
<div class="variablelist"><dl class="variablelist">
<dt><span class="term">Package</span></dt>
@@ -767,7 +767,7 @@ minutes!</p>
but may be stored in any location,
referred to as <code class="varname">PKGSRCDIR</code>.</p></dd>
<dt><span class="term">The NetBSD package system</span></dt>
-<dd><p>This is the former name of <span class="quote">“<span class="quote">pkgsrc</span>”</span>. It
+<dd><p>This is the former name of <span class="quote">“<span class="quote">pkgsrc</span>”</span>. It
is part of the NetBSD operating system and can be bootstrapped
to run on non-NetBSD operating systems as well. It handles
building (compiling), installing, and removing of
@@ -784,7 +784,7 @@ minutes!</p>
<dt><span class="term">Port</span></dt>
<dd><p>This is the term used by FreeBSD and OpenBSD people
for what we call a package.
- In NetBSD terminology, <span class="quote">“<span class="quote">port</span>”</span> refers to a different
+ In NetBSD terminology, <span class="quote">“<span class="quote">port</span>”</span> refers to a different
architecture.</p></dd>
<dt><span class="term">Precompiled/binary package</span></dt>
<dd>
@@ -795,7 +795,7 @@ minutes!</p>
recompile. Packages are usually generated in
<code class="filename">/usr/pkgsrc/packages</code>; there is also
an archive on <a class="ulink" href="ftp://ftp.NetBSD.org/pub/pkgsrc/packages/" target="_top">ftp.NetBSD.org</a>.</p>
-<p>Sometimes, this is referred to by the term <span class="quote">“<span class="quote">package</span>”</span> too,
+<p>Sometimes, this is referred to by the term <span class="quote">“<span class="quote">package</span>”</span> too,
especially in the context of precompiled packages.</p>
</dd>
<dt><span class="term">Program</span></dt>
@@ -805,38 +805,38 @@ minutes!</p>
</dl></div>
<div class="sect2">
<div class="titlepage"><div><div><h3 class="title">
-<a name="term.roles"></a>1.3.1.�Roles involved in pkgsrc</h3></div></div></div>
+<a name="term.roles"></a>1.3.1. Roles involved in pkgsrc</h3></div></div></div>
<div class="variablelist"><dl class="variablelist">
<dt><span class="term">pkgsrc users</span></dt>
<dd>
<p>The
pkgsrc users are people who use the packages provided by pkgsrc.
Typically they are system administrators. The people using the
- software that is inside the packages (maybe called <span class="quote">“<span class="quote">end
- users</span>”</span>) are not covered by the pkgsrc guide.</p>
+ software that is inside the packages (maybe called <span class="quote">“<span class="quote">end
+ users</span>”</span>) are not covered by the pkgsrc guide.</p>
<p>There are two kinds of pkgsrc users: Some only want to
install pre-built binary packages. Others build the pkgsrc
packages from source, either for installing them directly or for
- building binary packages themselves. For pkgsrc users <a class="xref" href="#users-guide" title="Part�I.�The pkgsrc user's guide">Part�I, “The pkgsrc user's guide”</a> should
provide all necessary
+ building binary packages themselves. For pkgsrc users <a class="xref" href="#users-guide" title="Part I. The pkgsrc user's guide">Part I, “The pkgsrc user's guide”</a> should provide all
necessary
documentation.</p>
</dd>
<dt><span class="term">package maintainers</span></dt>
<dd><p>A
- package maintainer creates packages as described in <a class="xref" href="#developers-guide" title="Part�II.�The pkgsrc developer's guide">Part�II, “The pkgsrc developer's
guide”</a>.</p></dd>
+ package maintainer creates packages as described in <a class="xref" href="#developers-guide" title="Part II. The pkgsrc developer's guide">Part II, “The pkgsrc developer's guide”</a>.</p></dd>
<dt><span class="term">infrastructure developers</span></dt>
<dd><p>These people are involved in all those files
that live in the <code class="filename">mk/</code> directory and below.
- Only these people should need to read through <a class="xref" href="#infrastructure" title="Part�III.�The pkgsrc infrastructure internals">Part�III, “The pkgsrc infrastructure
internals”</a>, though others might be curious,
+ Only these people should need to read through <a class="xref" href="#infrastructure" title="Part III. The pkgsrc infrastructure internals">Part III, “The pkgsrc infrastructure internals”</a>,
though others might be curious,
too.</p></dd>
</dl></div>
</div>
</div>
<div class="sect1">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="typography"></a>1.4.�Typography</h2></div></div></div>
+<a name="typography"></a>1.4. Typography</h2></div></div></div>
<p>When giving examples for commands, shell prompts are used to
show if the command should/can be issued as root, or if
- <span class="quote">“<span class="quote">normal</span>”</span> user privileges are sufficient. We use a
+ <span class="quote">“<span class="quote">normal</span>”</span> user privileges are sufficient. We use a
<code class="prompt">#</code> for root's shell prompt, a <code class="prompt">%</code> for users'
shell prompt, assuming they use the C-shell or tcsh and a <code class="prompt">$</code> for
Bourne shell and derivatives.</p>
@@ -844,7 +844,7 @@ minutes!</p>
</div>
<div class="part">
<div class="titlepage"><div><div><h1 class="title">
-<a name="users-guide"></a>Part�I.�The pkgsrc user's guide</h1></div></div></div>
+<a name="users-guide"></a>Part I. The pkgsrc user's guide</h1></div></div></div>
<div class="toc">
<p><b>Table of Contents</b></p>
<dl class="toc">
@@ -946,21 +946,21 @@ builds)</a></span></dt>
<dt><span class="sect1"><a href="#fetch-https">10.7. How to fetch files from HTTPS sites</a></span></dt>
<dt><span class="sect1"><a href="#passive-ftp">10.8. How do I tell <span class="command"><strong>make fetch</strong></span> to do passive FTP?</a></span></dt>
<dt><span class="sect1"><a href="#fetching-all-distfiles">10.9. How to fetch all distfiles at once</a></span></dt>
-<dt><span class="sect1"><a href="#tmac.andoc-missing">10.10. What does <span class="quote">“<span class="quote">Don't know how to make
-/usr/share/tmac/tmac.andoc</span>”</span> mean?</a></span></dt>
-<dt><span class="sect1"><a href="#bsd.own.mk-missing">10.11. What does <span class="quote">“<span class="quote">Could not find bsd.own.mk</span>”</span> mean?</a></span></dt>
+<dt><span class="sect1"><a href="#tmac.andoc-missing">10.10. What does <span class="quote">“<span class="quote">Don't know how to make
+/usr/share/tmac/tmac.andoc</span>”</span> mean?</a></span></dt>
+<dt><span class="sect1"><a href="#bsd.own.mk-missing">10.11. What does <span class="quote">“<span class="quote">Could not find bsd.own.mk</span>”</span> mean?</a></span></dt>
<dt><span class="sect1"><a href="#using-sudo-with-pkgsrc">10.12. Using 'sudo' or `priv` with pkgsrc</a></span></dt>
<dt><span class="sect1"><a href="#faq.conf">10.13. How do I change the location of configuration files?</a></span></dt>
<dt><span class="sect1"><a href="#audit-packages">10.14. Automated security checks</a></span></dt>
<dt><span class="sect1"><a href="#ufaq-cflags">10.15. Why do some packages ignore my <code class="varname">CFLAGS</code>?</a></span></dt>
<dt><span class="sect1"><a href="#ufaq-fail">10.16. A package does not build. What shall I do?</a></span></dt>
-<dt><span class="sect1"><a href="#faq.rcs-conflicts">10.17. What does <span class="quote">“<span class="quote">Makefile appears to contain unresolved cvs/rcs/??? merge
conflicts</span>”</span> mean?</a></span></dt>
+<dt><span class="sect1"><a href="#faq.rcs-conflicts">10.17. What does <span class="quote">“<span class="quote">Makefile appears to contain unresolved cvs/rcs/??? merge conflicts</span>”</span>
mean?</a></span></dt>
</dl></dd>
</dl>
</div>
<div class="chapter">
<div class="titlepage"><div><div><h2 class="title">
-<a name="help-user"></a>Chapter�2.�Getting help</h2></div></div></div>
+<a name="help-user"></a>Chapter 2. Getting help</h2></div></div></div>
<p>
To get help when using pkgsrc, the definitive source is this
document, the pkgsrc guide. If you don't find anything here,
@@ -970,12 +970,12 @@ builds)</a></span></dt>
<li class="listitem">
<p>
The built-in pkgsrc help, which is available after bootstrapping
- pkgsrc. Run <span class="command"><strong>bmake help topic=…</strong></span> to get
+ pkgsrc. Run <span class="command"><strong>bmake help topic=…</strong></span> to get
help for any topic, such as a variable name like
<code class="varname">BUILD_DEFS</code>, a make target like
<span class="command"><strong>do-build</strong></span>, a missing C or C++ function like
<span class="command"><strong>strcasecmp</strong></span> or any other topic.</p>
-<p>The available help topics are listed in <a class="xref" href="#help-topics" title="Appendix�E.�Help topics">Appendix�E, <i>Help topics</i></a>.</p>
+<p>The available help topics are listed in <a class="xref" href="#help-topics" title="Appendix E. Help topics">Appendix E, <i>Help topics</i></a>.</p>
</li>
<li class="listitem"><p>
To see the value of a single variable, run <span class="command"><strong>bmake
@@ -1003,7 +1003,7 @@ builds)</a></span></dt>
</div>
<div class="chapter">
<div class="titlepage"><div><div><h2 class="title">
-<a name="getting"></a>Chapter�3.�Where to get pkgsrc and how to keep it up-to-date</h2></div></div></div>
+<a name="getting"></a>Chapter 3. Where to get pkgsrc and how to keep it up-to-date</h2></div></div></div>
<div class="toc">
<p><b>Table of Contents</b></p>
<dl class="toc">
@@ -1029,14 +1029,14 @@ other programs. A safe bet is to use onl
and dashes.</p>
<div class="sect1">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="getting-first"></a>3.1.�Getting pkgsrc for the first time</h2></div></div></div>
+<a name="getting-first"></a>3.1. Getting pkgsrc for the first time</h2></div></div></div>
<p>Before you download any pkgsrc files, you should decide
whether you want the <span class="emphasis"><em>current</em></span> branch or the
<span class="emphasis"><em>stable</em></span> branch. The latter is forked on a
quarterly basis from the current branch and only gets modified
for security updates. The names of the stable branches are built
from the year and the quarter, for example
- <code class="literal">2025Q2</code>.</p>
+ <code class="literal">2025Q4</code>.</p>
<p>The second step is to decide <span class="emphasis"><em>how</em></span> you
want to download pkgsrc. You can get it as a tar file or via CVS.
Both ways are described here.</p>
@@ -1044,13 +1044,13 @@ and dashes.</p>
Thus you can switch to using CVS at any later time.</p>
<div class="sect2">
<div class="titlepage"><div><div><h3 class="title">
-<a name="getting-via-tar"></a>3.1.1.�As tar archive</h3></div></div></div>
+<a name="getting-via-tar"></a>3.1.1. As tar archive</h3></div></div></div>
<p>The primary download location for all pkgsrc files is
<a class="ulink" href="https://cdn.NetBSD.org/pub/pkgsrc/" target="_top">https://cdn.NetBSD.org/pub/pkgsrc/</a> or
<a class="ulink" href="ftp://ftp.NetBSD.org/pub/pkgsrc/" target="_top">ftp://ftp.NetBSD.org/pub/pkgsrc/</a>
(it points to the same location).
There are a number of subdirectories for different purposes,
- which are described in detail in <a class="xref" href="#ftp-layout" title="Appendix�D.�Directory layout of the pkgsrc FTP server">Appendix�D, <i>Directory layout of the pkgsrc FTP
server</i></a>.</p>
+ which are described in detail in <a class="xref" href="#ftp-layout" title="Appendix D. Directory layout of the pkgsrc FTP server">Appendix D, <i>Directory layout of the pkgsrc FTP
server</i></a>.</p>
<p>The tar archive for the current branch is in the directory
<code class="filename">current</code> and is called <a class="ulink" href="https://cdn.NetBSD.org/pub/pkgsrc/current/pkgsrc.tar.gz" target="_top"><code
class="filename">pkgsrc.tar.gz</code></a>.
It is autogenerated weekly.</p>
@@ -1062,11 +1062,11 @@ and dashes.</p>
respectively.
</p>
<p>You can fetch the same files using FTP.</p>
-<p>The tar file for the stable branch 2025Q2 is in the
- directory <code class="filename">pkgsrc-2025Q2</code> and is also called <a class="ulink" href="https://cdn.NetBSD.org/pub/pkgsrc/pkgsrc-2025Q2/pkgsrc.tar.gz" target="_top"><code
class="filename">pkgsrc.tar.gz</code></a>.</p>
+<p>The tar file for the stable branch 2025Q4 is in the
+ directory <code class="filename">pkgsrc-2025Q4</code> and is also called <a class="ulink" href="https://cdn.NetBSD.org/pub/pkgsrc/pkgsrc-2025Q4/pkgsrc.tar.gz" target="_top"><code
class="filename">pkgsrc.tar.gz</code></a>.</p>
<p>To download the latest pkgsrc stable tarball, run:</p>
<pre class="screen">
-<code class="prompt">$</code> <strong class="userinput"><code>ftp ftp://ftp.NetBSD.org/pub/pkgsrc/pkgsrc-2025Q2/pkgsrc.tar.gz</code></strong></pre>
+<code class="prompt">$</code> <strong class="userinput"><code>ftp ftp://ftp.NetBSD.org/pub/pkgsrc/pkgsrc-2025Q4/pkgsrc.tar.gz</code></strong></pre>
<p>If you prefer, you can also fetch it using "wget", "curl",
or your web browser.</p>
<p>Then, extract it with:</p>
@@ -1079,9 +1079,9 @@ and dashes.</p>
</div>
<div class="sect2">
<div class="titlepage"><div><div><h3 class="title">
-<a name="getting-via-cvs"></a>3.1.2.�Via anonymous CVS</h3></div></div></div>
+<a name="getting-via-cvs"></a>3.1.2. Via anonymous CVS</h3></div></div></div>
<p>To fetch a specific pkgsrc stable branch, run:</p>
-<pre class="screen"><code class="prompt">$</code> <strong class="userinput"><code>cd /usr && cvs -q -z2 -d anoncvs%anoncvs.NetBSD.org@localhost:/cvsroot checkout -r pkgsrc-2025Q2 -P
pkgsrc</code></strong>
+<pre class="screen"><code class="prompt">$</code> <strong class="userinput"><code>cd /usr && cvs -q -z2 -d anoncvs%anoncvs.NetBSD.org@localhost:/cvsroot checkout -r pkgsrc-2025Q4 -P
pkgsrc</code></strong>
</pre>
<p>This will create the directory <code class="filename">pkgsrc/</code>
in your <code class="filename">/usr/</code> directory and all the package source
@@ -1119,14 +1119,14 @@ release -d
</div>
<div class="sect1">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="uptodate"></a>3.2.�Keeping pkgsrc up-to-date</h2></div></div></div>
+<a name="uptodate"></a>3.2. Keeping pkgsrc up-to-date</h2></div></div></div>
<p>The preferred way to keep pkgsrc up-to-date is via CVS
(which also works if you have first installed it via a tar
file). It saves bandwidth and hard disk activity, compared to
downloading the tar file again.</p>
<div class="sect2">
<div class="titlepage"><div><div><h3 class="title">
-<a name="uptodate-tar"></a>3.2.1.�Via tar files</h3></div></div></div>
+<a name="uptodate-tar"></a>3.2.1. Via tar files</h3></div></div></div>
<div class="warning" style="margin-left: 0.5in; margin-right: 0.5in;">
<h3 class="title">Warning</h3>
<p>When updating from a tar file, you first need to
@@ -1142,7 +1142,7 @@ release -d
before updating. You can also configure pkgsrc to store distfiles
and packages in directories outside the pkgsrc tree by setting the
<code class="varname">DISTDIR</code> and <code class="varname">PACKAGES</code>
- variables. See <a class="xref" href="#configuring" title="Chapter�6.�Configuring pkgsrc">Chapter�6, <i>Configuring pkgsrc</i></a> for the details.</p>
+ variables. See <a class="xref" href="#configuring" title="Chapter 6. Configuring pkgsrc">Chapter 6, <i>Configuring pkgsrc</i></a> for the details.</p>
<p>To update pkgsrc from a tar file, download the tar file as
explained above. Then, make sure that you have not made any
changes to the files in the pkgsrc directory. Remove the pkgsrc
@@ -1150,7 +1150,7 @@ release -d
</div>
<div class="sect2">
<div class="titlepage"><div><div><h3 class="title">
-<a name="uptodate-cvs"></a>3.2.2.�Via CVS</h3></div></div></div>
+<a name="uptodate-cvs"></a>3.2.2. Via CVS</h3></div></div></div>
<p>To update pkgsrc via CVS, change to the <code class="filename">pkgsrc</code> directory and run cvs:</p>
<pre class="screen"><code class="prompt">$</code> <strong class="userinput"><code>cd /usr/pkgsrc && cvs update -dP</code></strong>
</pre>
@@ -1159,32 +1159,32 @@ release -d
</pre>
<div class="sect3">
<div class="titlepage"><div><div><h4 class="title">
-<a name="uptodate-cvs-switch"></a>3.2.2.1.�Switching between different pkgsrc branches</h4></div></div></div>
+<a name="uptodate-cvs-switch"></a>3.2.2.1. Switching between different pkgsrc branches</h4></div></div></div>
<p>When updating pkgsrc, the CVS program keeps track of the
branch you selected. But if you, for whatever reason, want to
switch from the stable branch to the current one, you can do it
- by adding the option <span class="quote">“<span class="quote">-A</span>”</span> after the
- <span class="quote">“<span class="quote">update</span>”</span> keyword. To switch from the current branch
+ by adding the option <span class="quote">“<span class="quote">-A</span>”</span> after the
+ <span class="quote">“<span class="quote">update</span>”</span> keyword. To switch from the current branch
back to the stable branch, add the
- <span class="quote">“<span class="quote">-rpkgsrc-2025Q2</span>”</span> option.</p>
+ <span class="quote">“<span class="quote">-rpkgsrc-2025Q4</span>”</span> option.</p>
</div>
<div class="sect3">
<div class="titlepage"><div><div><h4 class="title">
-<a name="uptodate-cvs-changes"></a>3.2.2.2.�What happens to my changes when updating?</h4></div></div></div>
+<a name="uptodate-cvs-changes"></a>3.2.2.2. What happens to my changes when updating?</h4></div></div></div>
<p>When you update pkgsrc, the CVS program will only touch
those files that are registered in the CVS repository. That
means that any packages that you created on your own will stay
unmodified. If you change files that are managed by CVS, later
updates will try to merge your changes with those that have been
done by others. See the CVS manual, chapter
- <span class="quote">“<span class="quote">update</span>”</span> for details.</p>
+ <span class="quote">“<span class="quote">update</span>”</span> for details.</p>
</div>
</div>
</div>
</div>
<div class="chapter">
<div class="titlepage"><div><div><h2 class="title">
-<a name="platforms"></a>Chapter�4.�Using pkgsrc on systems other than NetBSD</h2></div></div></div>
+<a name="platforms"></a>Chapter 4. Using pkgsrc on systems other than NetBSD</h2></div></div></div>
<div class="toc">
<p><b>Table of Contents</b></p>
<dl class="toc">
@@ -1194,12 +1194,12 @@ release -d
</div>
<div class="sect1">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="binarydist"></a>4.1.�Binary distribution</h2></div></div></div>
-<p>See <a class="xref" href="#using-pkg" title="5.1.�Using binary packages">Section�5.1, “Using binary packages”</a>.</p>
+<a name="binarydist"></a>4.1. Binary distribution</h2></div></div></div>
+<p>See <a class="xref" href="#using-pkg" title="5.1. Using binary packages">Section 5.1, “Using binary packages”</a>.</p>
</div>
<div class="sect1">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="bootstrapping-pkgsrc"></a>4.2.�Bootstrapping pkgsrc</h2></div></div></div>
+<a name="bootstrapping-pkgsrc"></a>4.2. Bootstrapping pkgsrc</h2></div></div></div>
<p>pkgsrc can be bootstrapped for use in two different modes:
privileged and unprivileged one. In unprivileged mode in contrast
to privileged one all programs are installed under one particular user
@@ -1212,7 +1212,7 @@ release -d
<code class="prompt">#</code> <strong class="userinput"><code>cd pkgsrc/bootstrap</code></strong>
<code class="prompt">#</code> <strong class="userinput"><code>./bootstrap</code></strong>
</pre>
-<p>To bootstrap in unprivileged mode pass <span class="quote">“<span class="quote">--unprivileged</span>”</span> flag to <span class="command"><strong>bootstrap</strong></span></p>
+<p>To bootstrap in unprivileged mode pass <span class="quote">“<span class="quote">--unprivileged</span>”</span> flag to <span class="command"><strong>bootstrap</strong></span></p>
<p>By default, in privileged mode pkgsrc uses
<code class="filename">/usr/pkg</code> for <span class="emphasis"><em>prefix</em></span>
where programs will be installed in,
@@ -1226,14 +1226,14 @@ release -d
and <code class="filename">~/pkg/var</code> for <span class="emphasis"><em>varbase</em></span>.
</p>
<p>You can change default layout using command-line arguments.
- Run <span class="quote">“<span class="quote">./bootstrap --help</span>”</span> to get details.
+ Run <span class="quote">“<span class="quote">./bootstrap --help</span>”</span> to get details.
</p>
<div class="note" style="margin-left: 0.5in; margin-right: 0.5in;">
<h3 class="title">Note</h3>
<p>The bootstrap installs a <span class="command"><strong>bmake</strong></span> tool.
Use this <span class="command"><strong>bmake</strong></span> when building via pkgsrc.
For examples in this guide, use <span class="command"><strong>bmake</strong></span>
- instead of <span class="quote">“<span class="quote">make</span>”</span>.</p>
+ instead of <span class="quote">“<span class="quote">make</span>”</span>.</p>
</div>
<div class="note" style="margin-left: 0.5in; margin-right: 0.5in;">
<h3 class="title">Note</h3>
@@ -1247,7 +1247,7 @@ release -d
</div>
<div class="chapter">
<div class="titlepage"><div><div><h2 class="title">
-<a name="using"></a>Chapter�5.�Using pkgsrc</h2></div></div></div>
+<a name="using"></a>Chapter 5. Using pkgsrc</h2></div></div></div>
<div class="toc">
<p><b>Table of Contents</b></p>
<dl class="toc">
@@ -1272,13 +1272,13 @@ release -d
</div>
<p>Basically, there are two ways of using pkgsrc. The first
is to only install the package tools and to use binary packages
-that someone else has prepared. This is the <span class="quote">“<span class="quote">pkg</span>”</span>
-in pkgsrc. The second way is to install the <span class="quote">“<span class="quote">src</span>”</span>
+that someone else has prepared. This is the <span class="quote">“<span class="quote">pkg</span>”</span>
+in pkgsrc. The second way is to install the <span class="quote">“<span class="quote">src</span>”</span>
of pkgsrc, too. Then you are able to build your own packages,
and you can still use binary packages from someone else.</p>
<div class="sect1">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="using-pkg"></a>5.1.�Using binary packages</h2></div></div></div>
+<a name="using-pkg"></a>5.1. Using binary packages</h2></div></div></div>
<p>On the <a class="ulink" href="https://cdn.NetBSD.org/" target="_top">cdn.NetBSD.org</a>
site and mirrors, there are collections of binary packages,
ready to be installed. These binary packages have been built using the
@@ -1290,17 +1290,17 @@ and you can still use binary packages fr
</ul></div>
<p>If you cannot use these directories for whatever reasons (maybe
because you're not root), you cannot use these binary packages, but
- have to build the packages yourself, which is explained in <a class="xref" href="#bootstrapping-pkgsrc" title="4.2.�Bootstrapping pkgsrc">Section�4.2, “Bootstrapping pkgsrc”</a>.</p>
+ have to build the packages yourself, which is explained in <a class="xref" href="#bootstrapping-pkgsrc" title="4.2. Bootstrapping pkgsrc">Section 4.2, “Bootstrapping pkgsrc”</a>.</p>
<div class="sect2">
<div class="titlepage"><div><div><h3 class="title">
-<a name="finding-binary-packages"></a>5.1.1.�Finding binary packages</h3></div></div></div>
+<a name="finding-binary-packages"></a>5.1.1. Finding binary packages</h3></div></div></div>
<p>To install binary packages, you first need to know from where
to get them. The first place where you should look is on the main
pkgsrc CDN in the directory <a class="ulink" href="https://cdn.NetBSD.org/pub/pkgsrc/packages/" target="_top"><code class="filename">/pub/pkgsrc/packages</code></a>.</p>
<p>This directory contains binary packages for multiple
platforms. First, select your operating system. Then, select your
hardware architecture, and in the third step, the OS version and
- the <span class="quote">“<span class="quote">version</span>”</span> of pkgsrc.</p>
+ the <span class="quote">“<span class="quote">version</span>”</span> of pkgsrc.</p>
<p>In this directory, you may find a file called
<code class="filename">bootstrap.tar.gz</code> which contains the package
management tools. If the file is missing, it is likely that your
@@ -1311,7 +1311,7 @@ and you can still use binary packages fr
</div>
<div class="sect2">
<div class="titlepage"><div><div><h3 class="title">
-<a name="installing-binary-packages"></a>5.1.2.�Installing binary packages</h3></div></div></div>
+<a name="installing-binary-packages"></a>5.1.2. Installing binary packages</h3></div></div></div>
<p>In the directory from the last section, there is a
subdirectory called <code class="filename">All/</code>, which contains all the
binary packages that are available for the platform, excluding those
@@ -1351,7 +1351,7 @@ nginx-1.18.0nb8 Lightweight HTTP se
</div>
<div class="sect2">
<div class="titlepage"><div><div><h3 class="title">
-<a name="using.pkgin_update"></a>5.1.3.�Updating packages</h3></div></div></div>
+<a name="using.pkgin_update"></a>5.1.3. Updating packages</h3></div></div></div>
<p>To update binary packages, it is recommended that you use
<span class="command"><strong>pkgin upgrade</strong></span>. This will compare the remote
package repository to your locally installed packages and safely
@@ -1363,7 +1363,7 @@ nginx-1.18.0nb8 Lightweight HTTP se
</div>
<div class="sect2">
<div class="titlepage"><div><div><h3 class="title">
-<a name="using.pkg_delete"></a>5.1.4.�Deinstalling packages</h3></div></div></div>
+<a name="using.pkg_delete"></a>5.1.4. Deinstalling packages</h3></div></div></div>
<p>To deinstall a package, it does not matter whether it was
installed from source code or from a binary package. Neither the
<span class="command"><strong>pkgin</strong></span> or the <span class="command"><strong>pkg_delete</strong></span>
@@ -1374,7 +1374,7 @@ nginx-1.18.0nb8 Lightweight HTTP se
</div>
<div class="sect2">
<div class="titlepage"><div><div><h3 class="title">
-<a name="using.pkg_info"></a>5.1.5.�Getting information about installed packages</h3></div></div></div>
+<a name="using.pkg_info"></a>5.1.5. Getting information about installed packages</h3></div></div></div>
<p>The <span class="command"><strong>pkg_info</strong></span> shows information about
installed packages or binary package files.
As with other management tools, it works with packages installed
@@ -1382,7 +1382,7 @@ nginx-1.18.0nb8 Lightweight HTTP se
</div>
<div class="sect2">
<div class="titlepage"><div><div><h3 class="title">
-<a name="vulnerabilities"></a>5.1.6.�Checking for security vulnerabilities in installed packages</h3></div></div></div>
+<a name="vulnerabilities"></a>5.1.6. Checking for security vulnerabilities in installed packages</h3></div></div></div>
<p>
The pkgsrc Security Team and Packages Groups maintain a list of
known vulnerabilities to packages which are (or have been)
@@ -1453,10 +1453,10 @@ check_pkg_vulnerabilities=YES
</div>
<div class="sect2">
<div class="titlepage"><div><div><h3 class="title">
-<a name="pkg_versions"></a>5.1.7.�Finding if newer versions of your installed packages are in pkgsrc</h3></div></div></div>
+<a name="pkg_versions"></a>5.1.7. Finding if newer versions of your installed packages are in pkgsrc</h3></div></div></div>
<p>
Install <a href="https://cdn.NetBSD.org/pub/pkgsrc/current/pkgsrc/pkgtools/lintpkgsrc/index.html" target="_top"><code class="filename">pkgtools/lintpkgsrc</code></a> and run
- <span class="command"><strong>lintpkgsrc</strong></span> with the <span class="quote">“<span class="quote">-i</span>”</span>
+ <span class="command"><strong>lintpkgsrc</strong></span> with the <span class="quote">“<span class="quote">-i</span>”</span>
argument to check if any packages are stale, e.g.
</p>
<pre class="screen">
@@ -1467,14 +1467,14 @@ Version mismatch: 'tcsh' 6.09.00 vs 6.10
</div>
<div class="sect2">
<div class="titlepage"><div><div><h3 class="title">
-<a name="using.pkg_admin"></a>5.1.8.�Other administrative functions</h3></div></div></div>
+<a name="using.pkg_admin"></a>5.1.8. Other administrative functions</h3></div></div></div>
<p>The <span class="command"><strong>pkg_admin</strong></span> executes various
administrative functions on the package system.</p>
</div>
</div>
<div class="sect1">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="building-packages-from-source"></a>5.2.�Building packages from source</h2></div></div></div>
+<a name="building-packages-from-source"></a>5.2. Building packages from source</h2></div></div></div>
<p>After obtaining pkgsrc, the <code class="filename">pkgsrc</code>
directory now contains a set of packages, organized into
categories. You can browse the online index of packages, or run
@@ -1488,21 +1488,21 @@ Version mismatch: 'tcsh' 6.09.00 vs 6.10
different <code class="varname">LOCALBASE</code> definitions on the same
system (inside a chroot is an exception). </p>
<p>The rest of this chapter assumes that the package is already
- in pkgsrc. If it is not, see <a class="xref" href="#developers-guide" title="Part�II.�The pkgsrc developer's guide">Part�II, “The pkgsrc developer's guide”</a> for
+ in pkgsrc. If it is not, see <a class="xref" href="#developers-guide" title="Part II. The pkgsrc developer's guide">Part II, “The pkgsrc developer's guide”</a> for
instructions how to create your own packages.</p>
<div class="sect2">
<div class="titlepage"><div><div><h3 class="title">
-<a name="requirements"></a>5.2.1.�Requirements</h3></div></div></div>
+<a name="requirements"></a>5.2.1. Requirements</h3></div></div></div>
<p>To build packages from source, you need a working C
compiler. On NetBSD, you need to install the
- <span class="quote">“<span class="quote">comp</span>”</span> and the <span class="quote">“<span class="quote">text</span>”</span> distribution
+ <span class="quote">“<span class="quote">comp</span>”</span> and the <span class="quote">“<span class="quote">text</span>”</span> distribution
sets. If you want to build X11-related packages, the
- <span class="quote">“<span class="quote">xbase</span>”</span> and <span class="quote">“<span class="quote">xcomp</span>”</span> distribution
+ <span class="quote">“<span class="quote">xbase</span>”</span> and <span class="quote">“<span class="quote">xcomp</span>”</span> distribution
sets are required, too.</p>
</div>
<div class="sect2">
<div class="titlepage"><div><div><h3 class="title">
-<a name="fetching-distfiles"></a>5.2.2.�Fetching distfiles</h3></div></div></div>
+<a name="fetching-distfiles"></a>5.2.2. Fetching distfiles</h3></div></div></div>
<p>The first step for building a package is downloading the
distfiles (i.e. the unmodified source). If they have not yet been
downloaded, pkgsrc will fetch them automatically.</p>
@@ -1552,7 +1552,7 @@ Version mismatch: 'tcsh' 6.09.00 vs 6.10
</div>
<div class="sect2">
<div class="titlepage"><div><div><h3 class="title">
-<a name="how-to-build-and-install"></a>5.2.3.�How to build and install</h3></div></div></div>
+<a name="how-to-build-and-install"></a>5.2.3. How to build and install</h3></div></div></div>
<p>
Once the software has downloaded, any patches will be applied, then it
will be compiled for you. This may take some time depending on your
@@ -1563,7 +1563,7 @@ Version mismatch: 'tcsh' 6.09.00 vs 6.10
<h3 class="title">Note</h3>
<p>If using bootstrap or pkgsrc on a non-NetBSD system,
use the pkgsrc <span class="command"><strong>bmake</strong></span> command instead of
- <span class="quote">“<span class="quote">make</span>”</span> in the examples in this guide.</p>
+ <span class="quote">“<span class="quote">make</span>”</span> in the examples in this guide.</p>
</div>
<p>For example, type</p>
<pre class="screen">
@@ -1604,7 +1604,7 @@ Version mismatch: 'tcsh' 6.09.00 vs 6.10
<code class="prompt">%</code> <strong class="userinput"><code>make clean-depends</code></strong>
</pre>
<p>Taking the figlet utility as an example, we can install it on our
- system by building as shown in <a class="xref" href="#logs" title="Appendix�C.�Build logs">Appendix�C, <i>Build logs</i></a>.</p>
+ system by building as shown in <a class="xref" href="#logs" title="Appendix C. Build logs">Appendix C, <i>Build logs</i></a>.</p>
<p>The program is installed under the default root of the
packages tree - <code class="filename">/usr/pkg</code>. Should this not
conform to your tastes, set the <code class="varname">LOCALBASE</code>
@@ -1629,8 +1629,8 @@ Version mismatch: 'tcsh' 6.09.00 vs 6.10
as <code class="varname">LOCALBASE</code> can be set in
<a class="link" href="#mk.conf"><code class="filename">mk.conf</code></a> to save having to remember to
set them each time you want to use pkgsrc.</p>
-<p>Occasionally, people want to <span class="quote">“<span class="quote">look under the
- covers</span>”</span> to see what is going on when a package is building
+<p>Occasionally, people want to <span class="quote">“<span class="quote">look under the
+ covers</span>”</span> to see what is going on when a package is building
or being installed. This may be for debugging purposes, or out of
simple curiosity. A number of utility values have been added to
help with this.</p>
@@ -1641,7 +1641,7 @@ Version mismatch: 'tcsh' 6.09.00 vs 6.10
information will be displayed. For example,</p>
<pre class="screen"><strong class="userinput"><code>make patch PKG_DEBUG_LEVEL=2</code></strong></pre>
<p>will show all the commands that are invoked, up to and
- including the <span class="quote">“<span class="quote">patch</span>”</span> stage.</p>
+ including the <span class="quote">“<span class="quote">patch</span>”</span> stage.</p>
</li>
<li class="listitem">
<p>If you want to know the value of a certain <a class="citerefentry" href="//man.NetBSD.org/NetBSD-10.1/make.1"><span class="citerefentry"><span class="refentrytitle">make</span>(1)</span></a>
@@ -1683,7 +1683,7 @@ Version mismatch: 'tcsh' 6.09.00 vs 6.10
</div>
<div class="chapter">
<div class="titlepage"><div><div><h2 class="title">
-<a name="configuring"></a>Chapter�6.�Configuring pkgsrc</h2></div></div></div>
+<a name="configuring"></a>Chapter 6. Configuring pkgsrc</h2></div></div></div>
<div class="toc">
<p><b>Table of Contents</b></p>
<dl class="toc">
@@ -1715,7 +1715,7 @@ kinds of variables, and no special error
spelling mistakes) takes place.</p>
<div class="sect1">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="general-configuration"></a>6.1.�General configuration</h2></div></div></div>
+<a name="general-configuration"></a>6.1. General configuration</h2></div></div></div>
<p>The following variables apply to all
pkgsrc packages. A complete list of the variables that can be
configured by the user is available in
@@ -1727,7 +1727,7 @@ spelling mistakes) takes place.</p>
<code class="filename">/usr/pkg</code>. Do not mix binary packages
with different <code class="varname">LOCALBASE</code>s!</p></li>
<li class="listitem"><p><code class="varname">CROSSBASE</code>: Where
- <span class="quote">“<span class="quote">cross</span>”</span> category packages will be
+ <span class="quote">“<span class="quote">cross</span>”</span> category packages will be
installed. The default is
<code class="filename">${LOCALBASE}/cross</code>.</p></li>
<li class="listitem"><p><code class="varname">X11BASE</code>: Where
@@ -1753,8 +1753,8 @@ spelling mistakes) takes place.</p>
<li class="listitem"><p><code class="varname">BINPKG_SITES</code>:
List of sites carrying binary pkgs. <em class="replaceable"><code>rel</code></em> and
<em class="replaceable"><code>arch</code></em> are replaced with OS
- release (<span class="quote">“<span class="quote">2.0</span>”</span>, etc.) and architecture
- (<span class="quote">“<span class="quote">mipsel</span>”</span>, etc.).</p></li>
+ release (<span class="quote">“<span class="quote">2.0</span>”</span>, etc.) and architecture
+ (<span class="quote">“<span class="quote">mipsel</span>”</span>, etc.).</p></li>
<li class="listitem"><p><code class="varname">ACCEPTABLE_LICENSES</code>:
List of acceptable licenses. License names are case-sensitive.
Whenever you try to build a package whose license is not in this
@@ -1765,7 +1765,7 @@ spelling mistakes) takes place.</p>
</div>
<div class="sect1">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="variables-affecting-build"></a>6.2.�Variables affecting the build process</h2></div></div></div>
+<a name="variables-affecting-build"></a>6.2. Variables affecting the build process</h2></div></div></div>
<p>
</p>
<div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; ">
@@ -1786,7 +1786,7 @@ spelling mistakes) takes place.</p>
pkgsrc tree instances.)</p></li>
<li class="listitem"><p><code class="varname">LOCALPATCHES</code>:
Directory for local patches that aren't part of pkgsrc.
- See <a class="xref" href="#components.patches" title="12.3.�patches/*">Section�12.3, “<code class="filename">patches/*</code>”</a> for more
+ See <a class="xref" href="#components.patches" title="12.3. patches/*">Section 12.3, “<code class="filename">patches/*</code>”</a> for more
information.</p></li>
<li class="listitem"><p><code class="varname">PKGMAKECONF</code>: Location of
the <a class="link" href="#mk.conf"><code class="filename">mk.conf</code></a> file used by a package's
@@ -1798,7 +1798,7 @@ spelling mistakes) takes place.</p>
</div>
<div class="sect1">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="native-or-pkgsrc-preference"></a>6.3.�Preferences for native or pkgsrc software</h2></div></div></div>
+<a name="native-or-pkgsrc-preference"></a>6.3. Preferences for native or pkgsrc software</h2></div></div></div>
<p>Whenever a package depends on a package that has a
<code class="filename">builtin.mk</code> file, the dependent package can
either use the built-in (native) version from the base system or the
@@ -1806,21 +1806,21 @@ spelling mistakes) takes place.</p>
still possible to build the pkgsrc package <a href="https://cdn.NetBSD.org/pub/pkgsrc/current/pkgsrc/devel/pcre++/index.html" target="_top"><code class="filename">devel/pcre++</code></a> even
when other packages depend
on the native pcre++ version instead.</p>
<p>To force using the pkgsrc-provided version for a particular
- package, define <span class="quote">“<span class="quote"><code class="varname">PREFER_PKGSRC</code> =
- <em class="replaceable"><code>package-ID</code></em></span>”</span> in <a class="link" href="#mk.conf"><code class="filename">mk.conf</code></a>. To force
+ package, define <span class="quote">“<span class="quote"><code class="varname">PREFER_PKGSRC</code> =
+ <em class="replaceable"><code>package-ID</code></em></span>”</span> in <a class="link" href="#mk.conf"><code class="filename">mk.conf</code></a>. To force
using the native package, define
- <span class="quote">“<span class="quote"><code class="varname">PREFER_NATIVE</code> =
- <em class="replaceable"><code>package-ID</code></em></span>”</span>. In both cases, the
+ <span class="quote">“<span class="quote"><code class="varname">PREFER_NATIVE</code> =
+ <em class="replaceable"><code>package-ID</code></em></span>”</span>. In both cases, the
<em class="replaceable"><code>package-ID</code></em> is the one from the
<code class="filename">buildlink3.mk</code> of the package. In most cases,
this ID is the same as the directory name of the package, but for
example, <code class="filename">devel/pcre++</code> has the
- package ID <span class="quote">“<span class="quote">pcrexx</span>”</span>.</p>
+ package ID <span class="quote">“<span class="quote">pcrexx</span>”</span>.</p>
<p>For the packages that are not listed by their package ID,
pkgsrc uses the pkgsrc-provided version if
<code class="varname">PREFER_PKGSRC</code> contains the word
- <span class="quote">“<span class="quote">yes</span>”</span>. Otherwise, if <code class="varname">PREFER_NATIVE</code>
- contains the word <span class="quote">“<span class="quote">yes</span>”</span>, pkgsrc uses the native
+ <span class="quote">“<span class="quote">yes</span>”</span>. Otherwise, if <code class="varname">PREFER_NATIVE</code>
+ contains the word <span class="quote">“<span class="quote">yes</span>”</span>, pkgsrc uses the native
version. For example, to require using the pkgsrc-provided versions
for all but the most basic bits on a NetBSD system, you can
set:</p>
@@ -1847,7 +1847,7 @@ PREFER_NATIVE= getopt skey tcp_wrappers
whose preference has been changed. This is not trivial and should
be avoided.</p>
<p>When using pkgsrc on Linux systems, there is high risk of
- <span class="quote">“<span class="quote">leakage</span>”</span>, where programs installed by pkgsrc may
+ <span class="quote">“<span class="quote">leakage</span>”</span>, where programs installed by pkgsrc may
inadvertently use a command or library not installed by pkgsrc, e.g.
those installed by yum or apt. Such foreign dependencies may be
installed, removed, or upgraded to a version incompatible with the
@@ -1859,15 +1859,15 @@ PREFER_NATIVE= getopt skey tcp_wrappers
outdated for use by pkgsrc. Even intentionally using foreign
dependencies, not considered leakage, can lead to these problems, so
it is generally discouraged. In order to minimize such problems,
- PREFER_PKGSRC defaults to <span class="quote">“<span class="quote">yes</span>”</span> on Linux systems. This ensures that
+ PREFER_PKGSRC defaults to <span class="quote">“<span class="quote">yes</span>”</span> on Linux systems. This ensures that
pkgsrc is aware of any changes to dependency packages and can
rebuild or upgrade the entire dependency tree as needed. This
default can be overridden by setting --prefer-pkgsrc to a
- list of packages and --prefer-native to <span class="quote">“<span class="quote">yes</span>”</span>.</p>
+ list of packages and --prefer-native to <span class="quote">“<span class="quote">yes</span>”</span>.</p>
</div>
<div class="sect1">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="variables-affecting-installation"></a>6.4.�Variables affecting the installation process</h2></div></div></div>
+<a name="variables-affecting-installation"></a>6.4. Variables affecting the installation process</h2></div></div></div>
<div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; "><li class="listitem"><p><code class="varname">PKGSRC_KEEP_BIN_PKGS</code>:
By default, binary packages of built packages are
preserved in <code class="filename">${PACKAGES}/All</code>. Setting
@@ -1935,10 +1935,10 @@ uid=1000(myusername) gid=100(users) grou
</div>
<div class="sect1">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="conf.compiler"></a>6.5.�Selecting and configuring the compiler</h2></div></div></div>
+<a name="conf.compiler"></a>6.5. Selecting and configuring the compiler</h2></div></div></div>
<div class="sect2">
<div class="titlepage"><div><div><h3 class="title">
-<a name="selecting-the-compiler"></a>6.5.1.�Selecting the compiler</h3></div></div></div>
+<a name="selecting-the-compiler"></a>6.5.1. Selecting the compiler</h3></div></div></div>
<p>By default, pkgsrc will use GCC to build packages. This may be
overridden by setting the following variables in /etc/mk.conf:</p>
<div class="variablelist"><dl class="variablelist">
@@ -1976,14 +1976,14 @@ uid=1000(myusername) gid=100(users) grou
IBM's XL C/C++ compiler suite</p></li>
</ul></div>
<p>The default is
- <span class="quote">“<span class="quote"><code class="varname">gcc</code></span>”</span>. You can use
+ <span class="quote">“<span class="quote"><code class="varname">gcc</code></span>”</span>. You can use
<code class="varname">ccache</code> and/or
<code class="varname">distcc</code> with an appropriate
<code class="varname">PKGSRC_COMPILER</code> setting,
- e.g. <span class="quote">“<span class="quote"><code class="varname">ccache gcc</code></span>”</span>. This
+ e.g. <span class="quote">“<span class="quote"><code class="varname">ccache gcc</code></span>”</span>. This
variable should always be terminated with a value for
a real compiler. Note that only one real compiler
- should be listed (e.g. <span class="quote">“<span class="quote"><code class="varname">sunpro gcc</code></span>”</span>
+ should be listed (e.g. <span class="quote">“<span class="quote"><code class="varname">sunpro gcc</code></span>”</span>
is not allowed).</p>
</dd>
<dt><span class="term"><code class="varname">GCC_REQD</code>:</span></dt>
@@ -2005,7 +2005,7 @@ uid=1000(myusername) gid=100(users) grou
</div>
<div class="sect2">
<div class="titlepage"><div><div><h3 class="title">
-<a name="conf.cflags"></a>6.5.2.�Additional flags to the compiler (<code class="varname">CFLAGS</code>)</h3></div></div></div>
+<a name="conf.cflags"></a>6.5.2. Additional flags to the compiler (<code class="varname">CFLAGS</code>)</h3></div></div></div>
<p>If you wish to set the <code class="varname">CFLAGS</code> variable,
please make sure to use the <code class="literal">+=</code> operator
instead of the <code class="literal">=</code> operator:</p>
@@ -2013,7 +2013,7 @@ uid=1000(myusername) gid=100(users) grou
CFLAGS+= -your -flags
</pre>
<p>Using <code class="varname">CFLAGS=</code> (i.e. without the
- <span class="quote">“<span class="quote">+</span>”</span>) may lead to problems with packages that
+ <span class="quote">“<span class="quote">+</span>”</span>) may lead to problems with packages that
need to add their own flags. You may want to take a look
at the <a href="https://cdn.NetBSD.org/pub/pkgsrc/current/pkgsrc/devel/cpuflags/index.html" target="_top"><code class="filename">devel/cpuflags</code></a>
package if you're interested in optimization specifically
@@ -2021,7 +2021,7 @@ CFLAGS+= -your -flags
</div>
<div class="sect2">
<div class="titlepage"><div><div><h3 class="title">
-<a name="conf.ldflags"></a>6.5.3.�Additional flags to the linker (<code class="varname">LDFLAGS</code>)</h3></div></div></div>
+<a name="conf.ldflags"></a>6.5.3. Additional flags to the linker (<code class="varname">LDFLAGS</code>)</h3></div></div></div>
<p>If you want to pass flags to the linker, both in the configure
step and the build step, you can do this in two ways. Either set
<code class="varname">LDFLAGS</code> or <code class="varname">LIBS</code>. The difference
@@ -2039,7 +2039,7 @@ LDFLAGS+= -your -linkerflags
</div>
<div class="sect1">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="developer-advanced-settings"></a>6.6.�Developer/advanced settings</h2></div></div></div>
+<a name="developer-advanced-settings"></a>6.6. Developer/advanced settings</h2></div></div></div>
<p>
</p>
<div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; ">
@@ -2073,7 +2073,7 @@ LDFLAGS+= -your -linkerflags
</div>
<div class="sect1">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="selecting-build-options"></a>6.7.�Selecting Build Options</h2></div></div></div>
+<a name="selecting-build-options"></a>6.7. Selecting Build Options</h2></div></div></div>
<p>Some packages have build time options, usually to select
between different dependencies, enable optional support for big
dependencies or enable experimental features.</p>
@@ -2101,7 +2101,7 @@ LDFLAGS+= -your -linkerflags
<code class="varname">PKG_OPTIONS.<em class="replaceable"><code>pkgbase</code></em></code>,
which can be used to select or disable options specifically for
package <em class="replaceable"><code>pkgbase</code></em>. Options listed in
- these variables are selected, options preceded by <span class="quote">“<span class="quote">-</span>”</span>
+ these variables are selected, options preceded by <span class="quote">“<span class="quote">-</span>”</span>
are disabled. A few examples:</p>
<pre class="screen">
<code class="prompt">$</code> <span class="command"><strong>grep "PKG.*OPTION" <a class="link" href="#mk.conf"><code class="filename">mk.conf</code></a></strong></span>
@@ -2144,7 +2144,7 @@ PKG_OPTIONS.apache= suexec </pre>
</div>
<div class="chapter">
<div class="titlepage"><div><div><h2 class="title">
-<a name="binary"></a>Chapter�7.�Creating binary packages</h2></div></div></div>
+<a name="binary"></a>Chapter 7. Creating binary packages</h2></div></div></div>
<div class="toc">
<p><b>Table of Contents</b></p>
<dl class="toc">
@@ -2154,7 +2154,7 @@ PKG_OPTIONS.apache= suexec </pre>
</div>
<div class="sect1">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="building-a-single-binary-package"></a>7.1.�Building a single binary package</h2></div></div></div>
+<a name="building-a-single-binary-package"></a>7.1. Building a single binary package</h2></div></div></div>
<p>Once you have built and installed a package, you can create
a <span class="emphasis"><em>binary package</em></span> which can be installed on
another system with <a class="citerefentry" href="//man.NetBSD.org/NetBSD-10.1/pkg_add.1"><span class="citerefentry"><span class="refentrytitle">pkg_add</span>(1)</span></a>. This saves having
to build
@@ -2173,21 +2173,21 @@ PKG_OPTIONS.apache= suexec </pre>
<span class="command"><strong>pkg_*</strong></span> tools to manipulate it. Binary packages are
created in <code class="varname">PACKAGES</code>, which defaults to
<code class="filename">/usr/pkgsrc/packages</code>, in the form of a compressed
- tar file. See <a class="xref" href="#logs.package" title="C.2.�Packaging figlet">Section�C.2, “Packaging figlet”</a> for a continuation of
+ tar file. See <a class="xref" href="#logs.package" title="C.2. Packaging figlet">Section C.2, “Packaging figlet”</a> for a continuation of
the above <a href="https://cdn.NetBSD.org/pub/pkgsrc/current/pkgsrc/misc/figlet/index.html" target="_top"><code class="filename">misc/figlet</code></a>
example.</p>
-<p>See <a class="xref" href="#submit" title="Chapter�23.�Submitting and Committing">Chapter�23, <i>Submitting and Committing</i></a> for information on how to submit
+<p>See <a class="xref" href="#submit" title="Chapter 23. Submitting and Committing">Chapter 23, <i>Submitting and Committing</i></a> for information on how to submit
such a binary package.</p>
</div>
<div class="sect1">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="settings-for-creationg-of-binary-packages"></a>7.2.�Settings for creation of binary packages</h2></div></div></div>
-<p>See <a class="xref" href="#build.helpful-targets" title="13.17.�Other helpful targets">Section�13.17, “Other helpful targets”</a>.</p>
+<a name="settings-for-creationg-of-binary-packages"></a>7.2. Settings for creation of binary packages</h2></div></div></div>
+<p>See <a class="xref" href="#build.helpful-targets" title="13.17. Other helpful targets">Section 13.17, “Other helpful targets”</a>.</p>
</div>
</div>
<div class="chapter">
<div class="titlepage"><div><div><h2 class="title">
-<a name="bulk"></a>Chapter�8.�Creating binary packages for everything in pkgsrc (bulk
+<a name="bulk"></a>Chapter 8. Creating binary packages for everything in pkgsrc (bulk
builds)</h2></div></div></div>
<div class="toc">
<p><b>Table of Contents</b></p>
@@ -2224,13 +2224,13 @@ the bulk build system, or pbulk ("p" sta
This chapter describes how to set it up.</p>
<div class="sect1">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="bulk.pre"></a>8.1.�Preparations</h2></div></div></div>
+<a name="bulk.pre"></a>8.1. Preparations</h2></div></div></div>
<p>First of all, you have to decide whether you build all packages
or a limited set of them. Full bulk builds usually consume a lot more resources,
both space and time, than builds for some practical sets of packages.
A number of particularly heavy packages exist that are not actually
interesting to a wide audience. (The approximate resource consumption for a
-full bulk build is given in section <a class="xref" href="#bulk.req" title="8.3.�Requirements of a full bulk build">Section�8.3, “Requirements of a full bulk build”</a>.)
+full bulk build is given in section <a class="xref" href="#bulk.req" title="8.3. Requirements of a full bulk build">Section 8.3, “Requirements of a full bulk build”</a>.)
For limited bulk builds you need to make a list of packages you want to build.
Note that all their dependencies will be built, so you don't need to track them manually.
</p>
@@ -2249,7 +2249,7 @@ certain packages tried to install files
</div>
<div class="sect1">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="bulk.pbulk"></a>8.2.�Running a bulk build</h2></div></div></div>
+<a name="bulk.pbulk"></a>8.2. Running a bulk build</h2></div></div></div>
<p>Running a bulk build works roughly as follows:</p>
<div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; ">
<li class="listitem"><p>First, build the pbulk infrastructure in a fresh pkgsrc location.</p></li>
@@ -2257,7 +2257,7 @@ certain packages tried to install files
</ul></div>
<div class="sect2">
<div class="titlepage"><div><div><h3 class="title">
-<a name="bulk.pbulk.conf"></a>8.2.1.�Configuration</h3></div></div></div>
+<a name="bulk.pbulk.conf"></a>8.2.1. Configuration</h3></div></div></div>
<p>To simplify configuration, we provide the helper script <code class="filename">mk/pbulk/pbulk.sh</code>.</p>
<p>In order to use it, prepare a clear system (real one, chroot environment, jail, zone, virtual machine).
Configure network access to fetch distribution files.
@@ -2323,7 +2323,7 @@ an IP address that must be accessible ov
</div>
<div class="sect1">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="bulk.req"></a>8.3.�Requirements of a full bulk build</h2></div></div></div>
+<a name="bulk.req"></a>8.3. Requirements of a full bulk build</h2></div></div></div>
<p>A complete bulk build requires lots of disk space. Some of the
disk space can be read-only, some other must be writable. Some can be on
remote filesystems (such as NFS) and some should be local. Some can be
@@ -2339,14 +2339,14 @@ temporary filesystems, others must survi
</div>
<div class="sect1">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="bulk.var"></a>8.4.�Bulk build variants</h2></div></div></div>
+<a name="bulk.var"></a>8.4. Bulk build variants</h2></div></div></div>
<p>To ensure that pkgsrc packages work in different configurations, it
makes sense to run non-default bulk builds from time to time. This
section lists some ideas for bulk builds that intentionally let packages
fail if they don't follow the pkgsrc style.</p>
<div class="sect2">
<div class="titlepage"><div><div><h3 class="title">
-<a name="bulk.var.confopt"></a>8.4.1.�Detect unknown configure options</h3></div></div></div>
+<a name="bulk.var.confopt"></a>8.4.1. Detect unknown configure options</h3></div></div></div>
<p>Add the following line to <a class="link" href="#mk.conf"><code class="filename">mk.conf</code></a>.</p>
<pre class="programlisting">
GNU_CONFIGURE_STRICT= yes
@@ -2357,7 +2357,7 @@ package but does not apply anymore. In t
</div>
<div class="sect2">
<div class="titlepage"><div><div><h3 class="title">
-<a name="bulk.var.comperr"></a>8.4.2.�Detect classes of bugs by forcing compiler warnings</h3></div></div></div>
+<a name="bulk.var.comperr"></a>8.4.2. Detect classes of bugs by forcing compiler warnings</h3></div></div></div>
<p>The job of a compiler is not restricted to producing executable
code, most compilers also detect typical programming mistakes. The pkgsrc
compiler wrappers make it easy to force compiler options when the package
@@ -2403,7 +2403,7 @@ easier.</p>
</div>
<div class="sect2">
<div class="titlepage"><div><div><h3 class="title">
-<a name="bulk.var.builderr"></a>8.4.3.�Force compiler options only in the build phase</h3></div></div></div>
+<a name="bulk.var.builderr"></a>8.4.3. Force compiler options only in the build phase</h3></div></div></div>
<p>When adding custom compiler flags via <code class="varname">CFLAGS</code>,
these apply to all phases of the package build process. Especially in the
configure phase, adding <code class="literal">-Werror</code> leads to wrong
@@ -2478,11 +2478,11 @@ with the added compiler options. Examine
corresponding lines starting with <code class="literal"><.></code> do end
with these options.</p>
<p>Building packages using this setup variant and fixing the resulting
-bugs is the same as in <a class="xref" href="#bulk.var.comperr" title="8.4.2.�Detect classes of bugs by forcing compiler warnings">Section�8.4.2, “Detect classes of bugs by forcing compiler
warnings”</a>.</p>
+bugs is the same as in <a class="xref" href="#bulk.var.comperr" title="8.4.2. Detect classes of bugs by forcing compiler warnings">Section 8.4.2, “Detect classes of bugs by forcing compiler
warnings”</a>.</p>
</div>
<div class="sect2">
<div class="titlepage"><div><div><h3 class="title">
-<a name="bulk.var.dirs"></a>8.4.4.�Use custom directories</h3></div></div></div>
+<a name="bulk.var.dirs"></a>8.4.4. Use custom directories</h3></div></div></div>
<p>Some directories like <code class="varname">PREFIX</code>,
<code class="varname">VARBASE</code>, <code class="varname">PKG_SYSCONFDIR</code>,
<code class="varname">PKGMANDIR</code>, <code class="varname">PKG_INFODIR</code> can be
@@ -2498,7 +2498,7 @@ PKG_INFODIR= a-random-uuid
</div>
<div class="sect2">
<div class="titlepage"><div><div><h3 class="title">
-<a name="bulk.var.warn"></a>8.4.5.�Turn warnings into errors</h3></div></div></div>
+<a name="bulk.var.warn"></a>8.4.5. Turn warnings into errors</h3></div></div></div>
<p>When building a package, warnings are typically ignored since they
just flow by and do not cause the build to fail immediately. To find
these warnings, redefine them to errors in <a class="link" href="#mk.conf"><code class="filename">mk.conf</code></a>.</p>
@@ -2516,7 +2516,7 @@ Makefile, and if it doesn't, add
</div>
<div class="sect2">
<div class="titlepage"><div><div><h3 class="title">
-<a name="bulk.var.pkglint"></a>8.4.6.�Reject packages for which pkglint reports errors</h3></div></div></div>
+<a name="bulk.var.pkglint"></a>8.4.6. Reject packages for which pkglint reports errors</h3></div></div></div>
<p>Using pkglint as part of the regular build process is mostly a
waste of time. If you want to fix some of the warnings, just run pkglint
recursively on the whole pkgsrc tree. This will take a few minutes (up to
@@ -2524,7 +2524,7 @@ recursively on the whole pkgsrc tree. Th
</div>
<div class="sect2">
<div class="titlepage"><div><div><h3 class="title">
-<a name="bulk.var.strings"></a>8.4.7.�Reject packages that contain forbidden strings</h3></div></div></div>
+<a name="bulk.var.strings"></a>8.4.7. Reject packages that contain forbidden strings</h3></div></div></div>
<p>To ensure that the binary packages don't contain references to the
build directory, there is already <code class="varname">CHECK_WRKREF</code>. If
that variable includes the item <code class="literal">extra</code>, it is
@@ -2541,7 +2541,7 @@ therefore the results need to be taken w
</div>
<div class="sect2">
<div class="titlepage"><div><div><h3 class="title">
-<a name="bulk.var.test"></a>8.4.8.�Reject packages whose self-test fails</h3></div></div></div>
+<a name="bulk.var.test"></a>8.4.8. Reject packages whose self-test fails</h3></div></div></div>
<p>To run the test suites that come with each package, add this line
to <a class="link" href="#mk.conf"><code class="filename">mk.conf</code></a>.</p>
<pre class="programlisting">
@@ -2554,7 +2554,7 @@ cyclic dependencies. There is still a lo
</div>
<div class="sect2">
<div class="titlepage"><div><div><h3 class="title">
-<a name="bulk.var.shvar"></a>8.4.9.�Reject packages that use undefined shell variables</h3></div></div></div>
+<a name="bulk.var.shvar"></a>8.4.9. Reject packages that use undefined shell variables</h3></div></div></div>
<p>To catch typos in the shell snippets from the Makefile fragments,
add the <code class="literal">-u</code> flag to most of the commands by adding this
line to <a class="link" href="#mk.conf"><code class="filename">mk.conf</code></a>.</p>
@@ -2570,7 +2570,7 @@ definition.</p>
</div>
<div class="sect2">
<div class="titlepage"><div><div><h3 class="title">
-<a name="bulk.var.quiet"></a>8.4.10.�Turn off verbose logging</h3></div></div></div>
+<a name="bulk.var.quiet"></a>8.4.10. Turn off verbose logging</h3></div></div></div>
<p>The build logs of a package are often quite long. This allows error
messages or other interesting details to hide between the noise. To make
the actual error message stand out more, add these lines to
@@ -2586,7 +2586,7 @@ different.</p>
</div>
<div class="sect1">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="creating-cdroms"></a>8.5.�Creating a multiple CD-ROM packages collection</h2></div></div></div>
+<a name="creating-cdroms"></a>8.5. Creating a multiple CD-ROM packages collection</h2></div></div></div>
<p>After your pkgsrc bulk-build has completed, you may wish to
create a CD-ROM set of the resulting binary packages to assist
in installing packages on other machines. The
@@ -2597,7 +2597,7 @@ different.</p>
CD as that package.</p>
<div class="sect2">
<div class="titlepage"><div><div><h3 class="title">
-<a name="cdpack-example"></a>8.5.1.�Example of cdpack</h3></div></div></div>
+<a name="cdpack-example"></a>8.5.1. Example of cdpack</h3></div></div></div>
<p>Complete documentation for cdpack is found in the cdpack(1)
man page. The following short example assumes that the binary
packages are left in
@@ -2632,7 +2632,7 @@ different.</p>
</div>
<div class="chapter">
<div class="titlepage"><div><div><h2 class="title">
-<a name="files"></a>Chapter�9.�Directory layout of the installed files</h2></div></div></div>
+<a name="files"></a>Chapter 9. Directory layout of the installed files</h2></div></div></div>
<div class="toc">
<p><b>Table of Contents</b></p>
<dl class="toc">
@@ -2670,7 +2670,7 @@ explained below.</p>
<div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; ">
<li class="listitem"><p><code class="varname">LOCALBASE</code> corresponds to the
<code class="filename">/usr</code> directory in the base system. It is the
-<span class="quote">“<span class="quote">main</span>”</span> directory where the files are installed and contains
+<span class="quote">“<span class="quote">main</span>”</span> directory where the files are installed and contains
the well-known subdirectories like <code class="filename">bin</code>,
<code class="filename">include</code>, <code class="filename">lib</code>,
<code class="filename">share</code> and
@@ -2686,7 +2686,7 @@ itself.</p></li>
</ul></div>
<div class="sect1">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="files.localbase"></a>9.1.�File system layout in <code class="literal">${LOCALBASE}</code>
+<a name="files.localbase"></a>9.1. File system layout in <code class="literal">${LOCALBASE}</code>
</h2></div></div></div>
<p>The following directories exist in a typical pkgsrc installation
in <code class="filename">${LOCALBASE}</code>.</p>
@@ -2752,7 +2752,7 @@ installation.</p></dd>
</div>
<div class="sect1">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="files.varbase"></a>9.2.�File system layout in <code class="literal">${VARBASE}</code>
+<a name="files.varbase"></a>9.2. File system layout in <code class="literal">${VARBASE}</code>
</h2></div></div></div>
<div class="variablelist"><dl class="variablelist">
<dt><span class="term"><code class="filename">db/pkg</code> (the usual location of
@@ -2773,7 +2773,7 @@ currently running.</p></dd>
</div>
<div class="chapter">
<div class="titlepage"><div><div><h2 class="title">
-<a name="faq"></a>Chapter�10.�Frequently Asked Questions</h2></div></div></div>
+<a name="faq"></a>Chapter 10. Frequently Asked Questions</h2></div></div></div>
<div class="toc">
<p><b>Table of Contents</b></p>
<dl class="toc">
@@ -2786,15 +2786,15 @@ currently running.</p></dd>
<dt><span class="sect1"><a href="#fetch-https">10.7. How to fetch files from HTTPS sites</a></span></dt>
<dt><span class="sect1"><a href="#passive-ftp">10.8. How do I tell <span class="command"><strong>make fetch</strong></span> to do passive FTP?</a></span></dt>
<dt><span class="sect1"><a href="#fetching-all-distfiles">10.9. How to fetch all distfiles at once</a></span></dt>
-<dt><span class="sect1"><a href="#tmac.andoc-missing">10.10. What does <span class="quote">“<span class="quote">Don't know how to make
-/usr/share/tmac/tmac.andoc</span>”</span> mean?</a></span></dt>
-<dt><span class="sect1"><a href="#bsd.own.mk-missing">10.11. What does <span class="quote">“<span class="quote">Could not find bsd.own.mk</span>”</span> mean?</a></span></dt>
+<dt><span class="sect1"><a href="#tmac.andoc-missing">10.10. What does <span class="quote">“<span class="quote">Don't know how to make
+/usr/share/tmac/tmac.andoc</span>”</span> mean?</a></span></dt>
+<dt><span class="sect1"><a href="#bsd.own.mk-missing">10.11. What does <span class="quote">“<span class="quote">Could not find bsd.own.mk</span>”</span> mean?</a></span></dt>
<dt><span class="sect1"><a href="#using-sudo-with-pkgsrc">10.12. Using 'sudo' or `priv` with pkgsrc</a></span></dt>
<dt><span class="sect1"><a href="#faq.conf">10.13. How do I change the location of configuration files?</a></span></dt>
<dt><span class="sect1"><a href="#audit-packages">10.14. Automated security checks</a></span></dt>
<dt><span class="sect1"><a href="#ufaq-cflags">10.15. Why do some packages ignore my <code class="varname">CFLAGS</code>?</a></span></dt>
<dt><span class="sect1"><a href="#ufaq-fail">10.16. A package does not build. What shall I do?</a></span></dt>
-<dt><span class="sect1"><a href="#faq.rcs-conflicts">10.17. What does <span class="quote">“<span class="quote">Makefile appears to contain unresolved cvs/rcs/??? merge
conflicts</span>”</span> mean?</a></span></dt>
+<dt><span class="sect1"><a href="#faq.rcs-conflicts">10.17. What does <span class="quote">“<span class="quote">Makefile appears to contain unresolved cvs/rcs/??? merge conflicts</span>”</span>
mean?</a></span></dt>
</dl>
</div>
<p>This section contains hints, tips & tricks on special things in
@@ -2802,7 +2802,7 @@ pkgsrc that we didn't find a better plac
it contains items for both pkgsrc users and developers.</p>
<div class="sect1">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="mailing-list-pointers"></a>10.1.�Are there any mailing lists for pkg-related discussion?</h2></div></div></div>
+<a name="mailing-list-pointers"></a>10.1. Are there any mailing lists for pkg-related discussion?</h2></div></div></div>
<p>The following mailing lists may be of interest to pkgsrc users:</p>
<div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; ">
<li class="listitem"><p><a class="ulink" href="http://www.NetBSD.org/mailinglists/index.html#pkgsrc-users" target="_top">pkgsrc-users</a>:
@@ -2833,7 +2833,7 @@ it contains items for both pkgsrc users
</div>
<div class="sect1">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="faq-pkgtools"></a>10.2.�Utilities for package management (pkgtools)</h2></div></div></div>
+<a name="faq-pkgtools"></a>10.2. Utilities for package management (pkgtools)</h2></div></div></div>
<p>The directory <code class="filename">pkgsrc/pkgtools</code> contains
a number of useful utilities for both users and developers of pkgsrc. This
section attempts only to make the reader aware of some of the utilities and when
@@ -2909,9 +2909,9 @@ utilities)</p>
</div>
<div class="sect1">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="non-root-pkgsrc"></a>10.3.�How to use pkgsrc as non-root</h2></div></div></div>
+<a name="non-root-pkgsrc"></a>10.3. How to use pkgsrc as non-root</h2></div></div></div>
<p>To install packages from source as a non-root user, download
-pkgsrc as described in <a class="xref" href="#getting" title="Chapter�3.�Where to get pkgsrc and how to keep it up-to-date">Chapter�3, <i>Where to get pkgsrc and how to keep it up-to-date</i></a>,
cd into that
+pkgsrc as described in <a class="xref" href="#getting" title="Chapter 3. Where to get pkgsrc and how to keep it up-to-date">Chapter 3, <i>Where to get pkgsrc and how to keep it up-to-date</i></a>,
cd into that
directory and run the command <span class="command"><strong>./bootstrap/bootstrap
--unprivileged</strong></span>.</p>
<p>This will install the binary part of pkgsrc to
@@ -2921,7 +2921,7 @@ into <code class="filename">~/pkg/etc</c
</div>
<div class="sect1">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="resume-transfers"></a>10.4.�How to resume transfers when fetching distfiles?</h2></div></div></div>
+<a name="resume-transfers"></a>10.4. How to resume transfers when fetching distfiles?</h2></div></div></div>
<p>By default, resuming transfers in pkgsrc is disabled, but you can
enable this feature by adding the option
<code class="varname">PKG_RESUME_TRANSFERS=YES</code> into
@@ -2945,7 +2945,7 @@ FETCH_USING= wget
</div>
<div class="sect1">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="x.org-from-pkgsrc"></a>10.5.�How can I install/use modular X.org from pkgsrc?</h2></div></div></div>
+<a name="x.org-from-pkgsrc"></a>10.5. How can I install/use modular X.org from pkgsrc?</h2></div></div></div>
<p>If you want to use modular X.org from pkgsrc instead of your system's own X11
(<code class="filename">/usr/X11R6</code>, <code class="filename">/usr/openwin</code>, ...)
you will have to add the following line into
@@ -2956,12 +2956,12 @@ X11_TYPE=modular
</div>
<div class="sect1">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="fetch-behind-firewall"></a>10.6.�How to fetch files from behind a firewall</h2></div></div></div>
+<a name="fetch-behind-firewall"></a>10.6. How to fetch files from behind a firewall</h2></div></div></div>
<p>If you are sitting behind a firewall which does not allow direct
connections to Internet hosts (i.e. non-NAT), you may specify the
relevant proxy hosts. This is done using an environment variable in the
form of a URL, e.g. in Amdahl, the machine
-<span class="quote">“<span class="quote">orpheus.amdahl.com</span>”</span> is one of the firewalls, and it uses
+<span class="quote">“<span class="quote">orpheus.amdahl.com</span>”</span> is one of the firewalls, and it uses
port 80 as the proxy port number. So the proxy environment variables
are:</p>
<pre class="programlisting">
@@ -2971,22 +2971,22 @@ http_proxy=http://orpheus.amdahl.com:80/
</div>
<div class="sect1">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="fetch-https"></a>10.7.�How to fetch files from HTTPS sites</h2></div></div></div>
+<a name="fetch-https"></a>10.7. How to fetch files from HTTPS sites</h2></div></div></div>
<p>Some fetch tools are not prepared to support HTTPS by default
(for example, the one in NetBSD 6.0), or the one installed by the
pkgsrc bootstrap (to avoid an openssl dependency that low in the
dependency graph).</p>
<p>Usually you won't notice, because distribution files are
-mirrored weekly to <span class="quote">“<span class="quote">ftp.NetBSD.org</span>”</span>, but that might not
+mirrored weekly to <span class="quote">“<span class="quote">ftp.NetBSD.org</span>”</span>, but that might not
be often enough if you are following pkgsrc-current. In that case, set
<code class="varname">FETCH_USING</code> in your <a class="link" href="#mk.conf"><code class="filename">mk.conf</code></a> file to
-<span class="quote">“<span class="quote">curl</span>”</span> or <span class="quote">“<span class="quote">wget</span>”</span>, which are both compiled
+<span class="quote">“<span class="quote">curl</span>”</span> or <span class="quote">“<span class="quote">wget</span>”</span>, which are both compiled
with HTTPS support by default. Of course, these tools need to be
installed before you can use them this way.</p>
</div>
<div class="sect1">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="passive-ftp"></a>10.8.�How do I tell <span class="command"><strong>make fetch</strong></span> to do passive FTP?</h2></div></div></div>
+<a name="passive-ftp"></a>10.8. How do I tell <span class="command"><strong>make fetch</strong></span> to do passive FTP?</h2></div></div></div>
<p>This depends on which utility is used to retrieve distfiles. From
<code class="filename">bsd.pkg.mk</code>, <code class="varname">FETCH_CMD</code> is assigned
the first available command from the following list:</p>
@@ -3006,7 +3006,7 @@ transfers.</p>
</div>
<div class="sect1">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="fetching-all-distfiles"></a>10.9.�How to fetch all distfiles at once</h2></div></div></div>
+<a name="fetching-all-distfiles"></a>10.9. How to fetch all distfiles at once</h2></div></div></div>
<p>You would like to download all the distfiles in a single batch
from work or university, where you can't run a <span class="command"><strong>make
fetch</strong></span>. There is an archive of distfiles on <a class="ulink" href="ftp://ftp.NetBSD.org/pub/pkgsrc/distfiles/" target="_top">ftp.NetBSD.org</a>,
@@ -3038,12 +3038,12 @@ by running:</p>
</div>
<div class="sect1">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="tmac.andoc-missing"></a>10.10.�What does <span class="quote">“<span class="quote">Don't know how to make
-/usr/share/tmac/tmac.andoc</span>”</span> mean?</h2></div></div></div>
+<a name="tmac.andoc-missing"></a>10.10. What does <span class="quote">“<span class="quote">Don't know how to make
+/usr/share/tmac/tmac.andoc</span>”</span> mean?</h2></div></div></div>
<p>When compiling the <a href="https://cdn.NetBSD.org/pub/pkgsrc/current/pkgsrc/pkgtools/pkg_install/index.html" target="_top"><code class="filename">pkgtools/pkg_install</code></a>
package, you get the error from make that it doesn't know how to make
<code class="filename">/usr/share/tmac/tmac.andoc</code>? This indicates that
-you don't have installed the <span class="quote">“<span class="quote">text</span>”</span> set (nroff, ...) from
+you don't have installed the <span class="quote">“<span class="quote">text</span>”</span> set (nroff, ...) from
the NetBSD base distribution on your machine. It is recommended to do
that to format man pages.</p>
<p>In the case of the <a href="https://cdn.NetBSD.org/pub/pkgsrc/current/pkgsrc/pkgtools/pkg_install/index.html" target="_top"><code class="filename">pkgtools/pkg_install</code></a> package, you
@@ -3052,7 +3052,7 @@ environment or in <a class="link" href="
</div>
<div class="sect1">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="bsd.own.mk-missing"></a>10.11.�What does <span class="quote">“<span class="quote">Could not find bsd.own.mk</span>”</span> mean?</h2></div></div></div>
+<a name="bsd.own.mk-missing"></a>10.11. What does <span class="quote">“<span class="quote">Could not find bsd.own.mk</span>”</span> mean?</h2></div></div></div>
<p>You didn't install the compiler set, <code class="filename">comp.tgz</code>,
when you installed your NetBSD machine. Please get and install it, by
extracting it in <code class="filename">/</code>:</p>
@@ -3064,7 +3064,7 @@ the one that corresponds to your release
</div>
<div class="sect1">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="using-sudo-with-pkgsrc"></a>10.12.�Using 'sudo' or `priv` with pkgsrc</h2></div></div></div>
+<a name="using-sudo-with-pkgsrc"></a>10.12. Using 'sudo' or `priv` with pkgsrc</h2></div></div></div>
<p>When installing packages as non-root user and using the just-in-time
<a class="citerefentry" href="//man.NetBSD.org/NetBSD-10.1/su.1"><span class="citerefentry"><span class="refentrytitle">su</span>(1)</span></a> feature of pkgsrc, it can become annoying to type in
the root
password for each required package installed. To avoid this, the sudo
@@ -3089,7 +3089,7 @@ package with a non-default python versio
</div>
<div class="sect1">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="faq.conf"></a>10.13.�How do I change the location of configuration files?</h2></div></div></div>
+<a name="faq.conf"></a>10.13. How do I change the location of configuration files?</h2></div></div></div>
<p>As the system administrator, you can choose where configuration files
are installed. The default settings make all these files go into
<code class="filename">${PREFIX}/etc</code> or some of its subdirectories; this may
@@ -3111,7 +3111,7 @@ reinstall any affected packages.</p>
</div>
<div class="sect1">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="audit-packages"></a>10.14.�Automated security checks</h2></div></div></div>
+<a name="audit-packages"></a>10.14. Automated security checks</h2></div></div></div>
<p>Please be aware that there can often be bugs in third-party software,
and some of these bugs can leave a machine vulnerable to exploitation by
attackers. In an effort to lessen the exposure, the NetBSD packages team
@@ -3135,14 +3135,14 @@ do this, refer to the following two tool
containing more information.</p></li>
</ol></div>
<p>Use of these tools is strongly recommended!
-See <a class="xref" href="#vulnerabilities" title="5.1.6.�Checking for security vulnerabilities in installed packages">Section�5.1.6, “Checking for security vulnerabilities in installed
packages”</a> for instructions on how to automate checking and
+See <a class="xref" href="#vulnerabilities" title="5.1.6. Checking for security vulnerabilities in installed packages">Section 5.1.6, “Checking for security vulnerabilities in installed
packages”</a> for instructions on how to automate checking and
reporting.</p>
<p>If this database is installed, pkgsrc builds will use it to
perform a security check before building any package.</p>
</div>
<div class="sect1">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="ufaq-cflags"></a>10.15.�Why do some packages ignore my <code class="varname">CFLAGS</code>?</h2></div></div></div>
+<a name="ufaq-cflags"></a>10.15. Why do some packages ignore my <code class="varname">CFLAGS</code>?</h2></div></div></div>
<p>When you add your own preferences to the
<code class="varname">CFLAGS</code> variable in your
<a class="link" href="#mk.conf"><code class="filename">mk.conf</code></a>, these flags are passed in
@@ -3157,7 +3157,7 @@ perform a security check before building
directory and then inspect any <code class="filename">Makefile</code> and
<code class="filename">Makefile.in</code> for whether they define
<code class="varname">CFLAGS</code> explicitly. Usually you can remove
- these lines. But be aware that some <span class="quote">“<span class="quote">smart</span>”</span>
+ these lines. But be aware that some <span class="quote">“<span class="quote">smart</span>”</span>
programmers write so bad code that it only works for the
specific combination of <code class="varname">CFLAGS</code> they have
chosen.</p>
@@ -3176,11 +3176,11 @@ most cases, the flags from the original
with <code class="literal">[*]</code>) are passed unmodified to the actual compiler
(the lines starting with <code class="literal"><.></code>). If the flag is
missing from the actual compiler command, it must have been removed by
-the <a class="link" href="#build.wrapper" title="13.10.�The wrapper phase">pkgsrc compiler wrappers</a>.</p>
+the <a class="link" href="#build.wrapper" title="13.10. The wrapper phase">pkgsrc compiler wrappers</a>.</p>
</div>
<div class="sect1">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="ufaq-fail"></a>10.16.�A package does not build. What shall I do?</h2></div></div></div>
+<a name="ufaq-fail"></a>10.16. A package does not build. What shall I do?</h2></div></div></div>
<div class="procedure"><ol class="procedure" type="1">
<li class="step"><p>Make sure that your copy of pkgsrc is consistent. A
case that occurs often is that people only update pkgsrc in
@@ -3189,21 +3189,21 @@ the <a class="link" href="#build.wrapper
sometimes changes that only work when the whole pkgsrc tree is
updated.</p></li>
<li class="step"><p>Make sure that you don't have any CVS conflicts.
- Search for <span class="quote">“<span class="quote"><<<<<<</span>”</span> or
- <span class="quote">“<span class="quote">>>>>>></span>”</span> in all your pkgsrc
+ Search for <span class="quote">“<span class="quote"><<<<<<</span>”</span> or
+ <span class="quote">“<span class="quote">>>>>>></span>”</span> in all your pkgsrc
files.</p></li>
<li class="step"><p>Make sure that you don't have old copies of the packages
extracted. Run <span class="command"><strong>make clean clean-depends</strong></span> to
verify this.</p></li>
<li class="step"><p>If you are a package developer who wants to invest
- some work, have a look at <a class="xref" href="#fixes" title="Chapter�21.�Making your package work">Chapter�21, <i>Making your package work</i></a>.</p></li>
+ some work, have a look at <a class="xref" href="#fixes" title="Chapter 21. Making your package work">Chapter 21, <i>Making your package work</i></a>.</p></li>
<li class="step"><p>If the problem still exists, write a mail to the
<code class="literal">pkgsrc-users</code> mailing list.</p></li>
</ol></div>
</div>
<div class="sect1">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="faq.rcs-conflicts"></a>10.17.�What does <span class="quote">“<span class="quote">Makefile appears to contain unresolved cvs/rcs/??? merge conflicts</span>”</span>
mean?</h2></div></div></div>
+<a name="faq.rcs-conflicts"></a>10.17. What does <span class="quote">“<span class="quote">Makefile appears to contain unresolved cvs/rcs/??? merge conflicts</span>”</span>
mean?</h2></div></div></div>
<p>You have modified a file from pkgsrc, and someone else has
modified that same file afterwards in the CVS repository. Both changes
are in the same region of the file, so when you updated pkgsrc, the
@@ -3218,11 +3218,11 @@ anymore, you can remove that file and ru
</div>
<div class="part">
<div class="titlepage"><div><div><h1 class="title">
-<a name="developers-guide"></a>Part�II.�The pkgsrc developer's guide</h1></div></div></div>
+<a name="developers-guide"></a>Part II. The pkgsrc developer's guide</h1></div></div></div>
<div class="partintro">
<div></div>
<p>This part of the book deals with creating and
- modifying packages. It starts with a <span class="quote">“<span class="quote">HOWTO</span>”</span>-like
+ modifying packages. It starts with a <span class="quote">“<span class="quote">HOWTO</span>”</span>-like
guide on creating a new package. The remaining chapters are more
like a reference manual for pkgsrc.</p>
<div class="toc">
@@ -3408,7 +3408,7 @@ anymore, you can remove that file and ru
<dt><span class="sect2"><a href="#fixes.build.cpp">21.5.1. Compiling C and C++ code conditionally</a></span></dt>
<dt><span class="sect2"><a href="#compiler-bugs">21.5.2. How to handle compiler bugs</a></span></dt>
<dt><span class="sect2"><a href="#fixes.build.header">21.5.3. No such file or directory</a></span></dt>
-<dt><span class="sect2"><a href="#undefined-reference">21.5.4. Undefined reference to <span class="quote">“<span class="quote">...</span>”</span></a></span></dt>
+<dt><span class="sect2"><a href="#undefined-reference">21.5.4. Undefined reference to <span class="quote">“<span class="quote">...</span>”</span></a></span></dt>
<dt><span class="sect2"><a href="#out-of-memory">21.5.5. Running out of memory</a></span></dt>
</dl></dd>
<dt><span class="sect1"><a href="#fixes.install">21.6. The <span class="emphasis"><em>install</em></span> phase</a></span></dt>
@@ -3467,7 +3467,7 @@ anymore, you can remove that file and ru
</div>
<div class="chapter">
<div class="titlepage"><div><div><h2 class="title">
-<a name="help-devel"></a>Chapter�11.�Getting help</h2></div></div></div>
+<a name="help-devel"></a>Chapter 11. Getting help</h2></div></div></div>
<p>
To get help when developing pkgsrc, the definitive source is this
document, the pkgsrc guide. If you don't find anything here,
@@ -3477,12 +3477,12 @@ anymore, you can remove that file and ru
<li class="listitem">
<p>
The built-in pkgsrc help, which is available after bootstrapping
- pkgsrc. Run <span class="command"><strong>bmake help topic=…</strong></span> to get
+ pkgsrc. Run <span class="command"><strong>bmake help topic=…</strong></span> to get
help for any topic, such as a variable name like
<code class="varname">BUILD_DEFS</code>, a make target like
<span class="command"><strong>do-build</strong></span>, a missing C or C++ function like
<span class="command"><strong>strcasecmp</strong></span> or any other topic.</p>
-<p>The available help topics are listed in <a class="xref" href="#help-topics" title="Appendix�E.�Help topics">Appendix�E, <i>Help topics</i></a>.</p>
+<p>The available help topics are listed in <a class="xref" href="#help-topics" title="Appendix E. Help topics">Appendix E, <i>Help topics</i></a>.</p>
</li>
<li class="listitem"><p>
To see the value of a single variable, run <span class="command"><strong>bmake
@@ -3510,7 +3510,7 @@ anymore, you can remove that file and ru
</div>
<div class="chapter">
<div class="titlepage"><div><div><h2 class="title">
-<a name="components"></a>Chapter�12.�Package components - files, directories and contents</h2></div></div></div>
+<a name="components"></a>Chapter 12. Package components - files, directories and contents</h2></div></div></div>
<div class="toc">
<p><b>Table of Contents</b></p>
<dl class="toc">
@@ -3540,7 +3540,7 @@ files involved which are described in th
sections.</p>
<div class="sect1">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="components.Makefile"></a>12.1.�<code class="filename">Makefile</code>
+<a name="components.Makefile"></a>12.1. <code class="filename">Makefile</code>
</h2></div></div></div>
<p>Building, installation and creation of a binary package are all
controlled by the package's <code class="filename">Makefile</code>.
@@ -3594,7 +3594,7 @@ converters games mbone
<code class="varname">DYNAMIC_MASTER_SITES</code>,
<code class="varname">DIST_SUBDIR</code>, <code class="varname">EXTRACT_SUFX</code>
and <code class="varname">DISTFILES</code> are discussed in detail in
- <a class="xref" href="#build.fetch" title="13.5.�The fetch phase">Section�13.5, “The <span class="emphasis"><em>fetch</em></span> phase”</a>.</p></li>
+ <a class="xref" href="#build.fetch" title="13.5. The fetch phase">Section 13.5, “The <span class="emphasis"><em>fetch</em></span> phase”</a>.</p></li>
</ul></div>
<p>The second section contains information about separately
downloaded patches, if any.
@@ -3656,7 +3656,7 @@ converters games mbone
description of the package (should not include the package
name).</p></li>
<li class="listitem"><p><code class="varname">LICENSE</code> indicates the license(s)
- applicable for the package. See <a class="xref" href="#handling-licenses" title="21.1.3.�Handling licenses">Section�21.1.3, “Handling licenses”</a> for further details.</p></li>
+ applicable for the package. See <a class="xref" href="#handling-licenses" title="21.1.3. Handling licenses">Section 21.1.3, “Handling licenses”</a> for further details.</p></li>
</ul></div>
<p>Other variables that affect the build:
</p>
@@ -3698,14 +3698,14 @@ converters games mbone
BSD-style makefiles which honor MANZ, there is
<code class="varname">MANCOMPRESSED_IF_MANZ</code>.</p></li>
<li class="listitem"><p>Replace <code class="filename">/usr/local</code> with
- <span class="quote">“<span class="quote">${PREFIX}</span>”</span> in all files (see patches,
+ <span class="quote">“<span class="quote">${PREFIX}</span>”</span> in all files (see patches,
below).</p></li>
-<li class="listitem"><p>If the package installs any info files, see <a class="xref" href="#faq.info-files" title="21.6.8.�Packages installing info files">Section�21.6.8, “Packages installing
info files”</a>.</p></li>
+<li class="listitem"><p>If the package installs any info files, see <a class="xref" href="#faq.info-files" title="21.6.8. Packages installing info files">Section 21.6.8, “Packages installing info
files”</a>.</p></li>
</ul></div>
</div>
<div class="sect1">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="components.distinfo"></a>12.2.�<code class="filename">distinfo</code>
+<a name="components.distinfo"></a>12.2. <code class="filename">distinfo</code>
</h2></div></div></div>
<p>The <code class="filename">distinfo</code> file contains the message
digest, or checksum, of each distfile needed for the package. This
@@ -3716,7 +3716,7 @@ converters games mbone
and SHA512), as well as the file size.</p>
<p>The <code class="filename">distinfo</code> file also contains the
checksums for all the patches found in the
- <code class="filename">patches</code> directory (see <a class="xref" href="#components.patches" title="12.3.�patches/*">Section�12.3, “<code class="filename">patches/*</code>”</a>).
These checksums ensure that patches
+ <code class="filename">patches</code> directory (see <a class="xref" href="#components.patches" title="12.3. patches/*">Section 12.3, “<code class="filename">patches/*</code>”</a>). These
checksums ensure that patches
are only applied intentionally and that they don't accidentally change,
e.g. when merging different changes together. They also make sure that
new patches are actually added to CVS and old ones are removed.
@@ -3732,7 +3732,7 @@ converters games mbone
</div>
<div class="sect1">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="components.patches"></a>12.3.�<code class="filename">patches/*</code>
+<a name="components.patches"></a>12.3. <code class="filename">patches/*</code>
</h2></div></div></div>
<p>Some packages don't work out-of-the box on the various
platforms that are supported by pkgsrc. These packages need
@@ -3743,7 +3743,7 @@ converters games mbone
extracting them, in alphabetic order.</p>
<div class="sect2">
<div class="titlepage"><div><div><h3 class="title">
-<a name="components.patch.structure"></a>12.3.1.�Structure of a single patch file</h3></div></div></div>
+<a name="components.patch.structure"></a>12.3.1. Structure of a single patch file</h3></div></div></div>
<p>The <code class="filename">patch-*</code> files should be in
<span class="command"><strong>diff -bu</strong></span> format, and apply without a fuzz to avoid
problems. (To force patches to apply with fuzz you can set
@@ -3771,7 +3771,7 @@ converters games mbone
</div>
<div class="sect2">
<div class="titlepage"><div><div><h3 class="title">
-<a name="components.patches.caveats"></a>12.3.2.�Creating patch files</h3></div></div></div>
+<a name="components.patches.caveats"></a>12.3.2. Creating patch files</h3></div></div></div>
<p>One important thing to mention is to pay attention that no RCS
IDs get stored in the patch files, as these will cause problems when
later checked into the NetBSD CVS tree. Use the
@@ -3790,7 +3790,7 @@ converters games mbone
the changes.</p>
<p>When you have finished a package, remember to generate
the checksums for the patch files by using the <span class="command"><strong>make
- makepatchsum</strong></span> command, see <a class="xref" href="#components.distinfo" title="12.2.�distinfo">Section�12.2, “<code class="filename">distinfo</code>”</a>.</p>
+ makepatchsum</strong></span> command, see <a class="xref" href="#components.distinfo" title="12.2. distinfo">Section 12.2, “<code class="filename">distinfo</code>”</a>.</p>
<p>When adding a patch that corrects a problem in the
distfile (rather than e.g. enforcing pkgsrc's view of where
man pages should go), send the patch as a bug report to the
@@ -3814,7 +3814,7 @@ converters games mbone
</div>
<div class="sect2">
<div class="titlepage"><div><div><h3 class="title">
-<a name="components.patches.sources"></a>12.3.3.�Sources where the patch files come from</h3></div></div></div>
+<a name="components.patches.sources"></a>12.3.3. Sources where the patch files come from</h3></div></div></div>
<p>If you want to share patches between multiple packages
in pkgsrc, e.g. because they use the same distfiles, set
<code class="varname">PATCHDIR</code> to the path where the patch files
@@ -3829,7 +3829,7 @@ PATCHDIR= ../../editors/xemacs/pat
committed into pkgsrc, they can be kept outside the pkgsrc
tree in the <code class="filename">$LOCALPATCHES</code> directory. The
directory tree there is expected to have the same
- <span class="quote">“<span class="quote">category/package</span>”</span> structure as pkgsrc, and
+ <span class="quote">“<span class="quote">category/package</span>”</span> structure as pkgsrc, and
patches are expected to be stored inside these dirs (also
known as <code class="filename">$LOCALPATCHES/$PKGPATH</code>). For
example, if you want to keep a private patch for
@@ -3841,7 +3841,7 @@ PATCHDIR= ../../editors/xemacs/pat
</div>
<div class="sect2">
<div class="titlepage"><div><div><h3 class="title">
-<a name="components.patches.guidelines"></a>12.3.4.�Patching guidelines</h3></div></div></div>
+<a name="components.patches.guidelines"></a>12.3.4. Patching guidelines</h3></div></div></div>
<p>When fixing a portability issue in the code do not use
preprocessor magic to check for the current operating system nor
platform. Doing so hurts portability to other platforms because
@@ -3865,7 +3865,7 @@ PATCHDIR= ../../editors/xemacs/pat
<span class="emphasis"><em>It doesn't work unless it is right!</em></span></p>
<p>Some typical examples:</p>
<div class="table">
-<a name="patch-examples"></a><p class="title"><b>Table�12.1.�Patching examples</b></p>
+<a name="patch-examples"></a><p class="title"><b>Table 12.1. Patching examples</b></p>
<div class="table-contents"><table class="table" summary="Patching examples" border="1">
<colgroup>
<col>
@@ -3949,7 +3949,7 @@ monitor_file(...)
</div>
<div class="sect2">
<div class="titlepage"><div><div><h3 class="title">
-<a name="components.patches.feedback"></a>12.3.5.�Feedback to the author</h3></div></div></div>
+<a name="components.patches.feedback"></a>12.3.5. Feedback to the author</h3></div></div></div>
<p>Always, always, <span class="strong"><strong>always</strong></span>
feed back any <span class="emphasis"><em>portability fixes</em></span> or
improvements you do to a package to the mainstream developers.
@@ -3972,7 +3972,7 @@ monitor_file(...)
</div>
<div class="sect1">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="other-mandatory-files"></a>12.4.�Other mandatory files</h2></div></div></div>
+<a name="other-mandatory-files"></a>12.4. Other mandatory files</h2></div></div></div>
<div class="variablelist"><dl class="variablelist">
<dt><span class="term"><code class="filename">DESCR</code></span></dt>
<dd><p>A multi-line description of the piece of software. This should include
@@ -3984,16 +3984,16 @@ monitor_file(...)
system: all the binaries, manual pages, etc. There are other
directives which may be entered in this file, to control the
creation and deletion of directories, and the location of
- inserted files. See <a class="xref" href="#plist" title="Chapter�19.�PLIST issues">Chapter�19, <i>PLIST issues</i></a> for more
+ inserted files. See <a class="xref" href="#plist" title="Chapter 19. PLIST issues">Chapter 19, <i>PLIST issues</i></a> for more
information.</p></dd>
</dl></div>
</div>
<div class="sect1">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="components.optional"></a>12.5.�Optional files</h2></div></div></div>
+<a name="components.optional"></a>12.5. Optional files</h2></div></div></div>
<div class="sect2">
<div class="titlepage"><div><div><h3 class="title">
-<a name="components.optional.bin"></a>12.5.1.�Files affecting the binary package</h3></div></div></div>
+<a name="components.optional.bin"></a>12.5.1. Files affecting the binary package</h3></div></div></div>
<div class="variablelist"><dl class="variablelist">
<dt><span class="term"><code class="filename">INSTALL</code></span></dt>
<dd>
@@ -4003,14 +4003,14 @@ monitor_file(...)
are moved in place. This can be used to do any custom
procedures not possible with @exec commands in
<code class="filename">PLIST</code>. See <a class="citerefentry" href="//man.NetBSD.org/NetBSD-10.1/pkg_add.1"><span class="citerefentry"><span
class="refentrytitle">pkg_add</span>(1)</span></a> and
- <a class="citerefentry" href="//man.NetBSD.org/NetBSD-10.1/pkg_create.1"><span class="citerefentry"><span class="refentrytitle">pkg_create</span>(1)</span></a> for more information. See
also <a class="xref" href="#files-and-dirs-outside-prefix" title="20.1.�Files and directories outside the installation prefix">Section�20.1, “Files and directories outside the installation
prefix”</a>.
+ <a class="citerefentry" href="//man.NetBSD.org/NetBSD-10.1/pkg_create.1"><span class="citerefentry"><span class="refentrytitle">pkg_create</span>(1)</span></a> for more information. See
also <a class="xref" href="#files-and-dirs-outside-prefix" title="20.1. Files and directories outside the installation prefix">Section 20.1, “Files and directories outside the installation
prefix”</a>.
Please note that you can modify variables in it easily by using
<code class="varname">FILES_SUBST</code> in the package's
<code class="filename">Makefile</code>:</p>
<pre class="programlisting">
FILES_SUBST+= SOMEVAR="somevalue"
</pre>
-<p>replaces "@SOMEVAR@" with <span class="quote">“<span class="quote">somevalue</span>”</span> in the
+<p>replaces "@SOMEVAR@" with <span class="quote">“<span class="quote">somevalue</span>”</span> in the
<code class="filename">INSTALL</code>. By default, substitution is
performed for <code class="varname">PREFIX</code>,
<code class="varname">LOCALBASE</code>, <code class="varname">X11BASE</code>,
@@ -4059,7 +4059,7 @@ FILES_SUBST+= SOMEVAR="somevalue"
<pre class="programlisting">
MESSAGE_SUBST+= SOMEVAR="somevalue"
</pre>
-<p>replaces "${SOMEVAR}" with <span class="quote">“<span class="quote">somevalue</span>”</span> in
+<p>replaces "${SOMEVAR}" with <span class="quote">“<span class="quote">somevalue</span>”</span> in
<code class="filename">MESSAGE</code>. By default, substitution is
performed for <code class="varname">PKGNAME</code>,
<code class="varname">PKGBASE</code>, <code class="varname">PREFIX</code>,
@@ -4087,7 +4087,7 @@ MESSAGE_SUBST+= SOMEVAR="somevalue"
</div>
<div class="sect2">
<div class="titlepage"><div><div><h3 class="title">
-<a name="components.optional.build"></a>12.5.2.�Files affecting the build process</h3></div></div></div>
+<a name="components.optional.build"></a>12.5.2. Files affecting the build process</h3></div></div></div>
<div class="variablelist"><dl class="variablelist">
<dt><span class="term"><code class="filename">Makefile.common</code></span></dt>
<dd><p>This file contains arbitrary things that could
@@ -4099,7 +4099,7 @@ MESSAGE_SUBST+= SOMEVAR="somevalue"
describes what it does.</p></dd>
<dt><span class="term"><code class="filename">buildlink3.mk</code></span></dt>
<dd><p>This file contains the dependency information
- for the buildlink3 framework (see <a class="xref" href="#buildlink" title="Chapter�18.�Buildlink methodology">Chapter�18, <i>Buildlink methodology</i></a>).</p></dd>
+ for the buildlink3 framework (see <a class="xref" href="#buildlink" title="Chapter 18. Buildlink methodology">Chapter 18, <i>Buildlink methodology</i></a>).</p></dd>
<dt><span class="term"><code class="filename">hacks.mk</code></span></dt>
<dd><p>This file contains workarounds for compiler bugs
and similar things. It is included automatically by the pkgsrc
@@ -4108,7 +4108,7 @@ MESSAGE_SUBST+= SOMEVAR="somevalue"
it.</p></dd>
<dt><span class="term"><code class="filename">options.mk</code></span></dt>
<dd><p>This file contains the code for the
- package-specific options (see <a class="xref" href="#options" title="Chapter�16.�Options handling">Chapter�16, <i>Options handling</i></a>) that can be
+ package-specific options (see <a class="xref" href="#options" title="Chapter 16. Options handling">Chapter 16, <i>Options handling</i></a>) that can be
selected by the user. If a package has only one or two options,
it is equally acceptable to put the code directly into the
<code class="filename">Makefile</code>.</p></dd>
@@ -4116,7 +4116,7 @@ MESSAGE_SUBST+= SOMEVAR="somevalue"
</div>
<div class="sect2">
<div class="titlepage"><div><div><h3 class="title">
-<a name="components.optional.none"></a>12.5.3.�Files affecting nothing at all</h3></div></div></div>
+<a name="components.optional.none"></a>12.5.3. Files affecting nothing at all</h3></div></div></div>
<div class="variablelist"><dl class="variablelist">
<dt><span class="term"><code class="filename">README*</code></span></dt>
<dd><p>These files do not take place in the creation of
@@ -4131,7 +4131,7 @@ MESSAGE_SUBST+= SOMEVAR="somevalue"
</div>
<div class="sect1">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="work-dir"></a>12.6.�<code class="filename">work*</code>
+<a name="work-dir"></a>12.6. <code class="filename">work*</code>
</h2></div></div></div>
<p>When you type <span class="command"><strong>make</strong></span>, the distribution files are
unpacked into the directory denoted by
@@ -4145,12 +4145,12 @@ MESSAGE_SUBST+= SOMEVAR="somevalue"
</div>
<div class="sect1">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="files-dir"></a>12.7.�<code class="filename">files/*</code>
+<a name="files-dir"></a>12.7. <code class="filename">files/*</code>
</h2></div></div></div>
<p>If you have any files that you wish to be placed in the package
prior to configuration or building, you can place these files here
and use a <span class="command"><strong>${CP}</strong></span> command in the
- <span class="quote">“<span class="quote">post-extract</span>”</span> target to achieve this.</p>
+ <span class="quote">“<span class="quote">post-extract</span>”</span> target to achieve this.</p>
<p>If you want to share files in this way with other
packages, set the <code class="varname">FILESDIR</code> variable to point
to the other package's <code class="filename">files</code> directory,
@@ -4162,7 +4162,7 @@ FILESDIR= ../../editors/xemacs/fil
</div>
<div class="chapter">
<div class="titlepage"><div><div><h2 class="title">
-<a name="build"></a>Chapter�13.�The build process</h2></div></div></div>
+<a name="build"></a>Chapter 13. The build process</h2></div></div></div>
<div class="toc">
<p><b>Table of Contents</b></p>
<dl class="toc">
@@ -4191,7 +4191,7 @@ FILESDIR= ../../editors/xemacs/fil
</div>
<div class="sect1">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="build.intro"></a>13.1.�Introduction</h2></div></div></div>
+<a name="build.intro"></a>13.1. Introduction</h2></div></div></div>
<p>This chapter gives a detailed description on how a package is
built. Building a package is separated into different
<span class="emphasis"><em>phases</em></span> (for example <code class="varname">fetch</code>,
@@ -4218,7 +4218,7 @@ FILESDIR= ../../editors/xemacs/fil
</div>
<div class="sect1">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="build.prefix"></a>13.2.�Program location</h2></div></div></div>
+<a name="build.prefix"></a>13.2. Program location</h2></div></div></div>
<p>Before outlining the process performed by the NetBSD package system in
the next section, here's a brief discussion on where programs are
installed, and which variables influence this.</p>
@@ -4229,18 +4229,18 @@ FILESDIR= ../../editors/xemacs/fil
for pkgs in the <code class="filename">cross</code> category. The value of
<code class="varname">PREFIX</code> needs to be put
into the various places in the program's source where paths to
- these files are encoded. See <a class="xref" href="#components.patches" title="12.3.�patches/*">Section�12.3, “<code class="filename">patches/*</code>”</a> and <a class="xref"
href="#fixes.libtool" title="21.3.1.�Shared libraries - libtool">Section�21.3.1, “Shared libraries - libtool”</a> for more details.</p>
+ these files are encoded. See <a class="xref" href="#components.patches" title="12.3. patches/*">Section 12.3, “<code class="filename">patches/*</code>”</a> and <a class="xref"
href="#fixes.libtool" title="21.3.1. Shared libraries - libtool">Section 21.3.1, “Shared libraries - libtool”</a> for more details.</p>
<p>When choosing which of these variables to use,
follow the following rules:</p>
<div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; ">
<li class="listitem"><p><code class="varname">PREFIX</code> always points to the location
where the current pkg will be installed. When referring to a
pkg's own installation path, use
- <span class="quote">“<span class="quote">${PREFIX}</span>”</span>.</p></li>
+ <span class="quote">“<span class="quote">${PREFIX}</span>”</span>.</p></li>
<li class="listitem"><p><code class="varname">LOCALBASE</code> is where all pkgs
are installed. If you need to construct a -I or -L argument
to the compiler to find includes and libraries installed by
- another pkg, use <span class="quote">“<span class="quote">${LOCALBASE}</span>”</span>. The name
+ another pkg, use <span class="quote">“<span class="quote">${LOCALBASE}</span>”</span>. The name
<code class="varname">LOCALBASE</code> stems from FreeBSD, which
installed all packages in <code class="filename">/usr/local</code>. As
pkgsrc leaves <code class="filename">/usr/local</code> for the system
@@ -4248,7 +4248,7 @@ FILESDIR= ../../editors/xemacs/fil
<li class="listitem"><p><code class="varname">X11BASE</code> is where the actual X11
distribution (from xsrc, etc.) is installed. When looking for
<span class="emphasis"><em>standard</em></span> X11 includes (not those
- installed by a package), use <span class="quote">“<span class="quote">${X11BASE}</span>”</span>.</p></li>
+ installed by a package), use <span class="quote">“<span class="quote">${X11BASE}</span>”</span>.</p></li>
<li class="listitem"><p>X11-based packages using imake must set
<code class="varname">USE_IMAKE</code> to be installed correctly under
<code class="varname">LOCALBASE</code>.</p></li>
@@ -4260,7 +4260,7 @@ FILESDIR= ../../editors/xemacs/fil
</div>
<div class="sect1">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="build.builddirs"></a>13.3.�Directories used during the build process</h2></div></div></div>
+<a name="build.builddirs"></a>13.3. Directories used during the build process</h2></div></div></div>
<p>When building a package, various directories are used to store
source files, temporary files, pkgsrc-internal files, and so on. These
directories are explained here.</p>
@@ -4317,7 +4317,7 @@ FILESDIR= ../../editors/xemacs/fil
</div>
<div class="sect1">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="build.running"></a>13.4.�Running a phase</h2></div></div></div>
+<a name="build.running"></a>13.4. Running a phase</h2></div></div></div>
<p>You can run a particular phase by typing <span class="command"><strong>make
<em class="replaceable"><code>phase</code></em></strong></span>, where
<em class="replaceable"><code>phase</code></em> is the name of the phase. This will
@@ -4328,14 +4328,14 @@ FILESDIR= ../../editors/xemacs/fil
</div>
<div class="sect1">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="build.fetch"></a>13.5.�The <span class="emphasis"><em>fetch</em></span> phase</h2></div></div></div>
+<a name="build.fetch"></a>13.5. The <span class="emphasis"><em>fetch</em></span> phase</h2></div></div></div>
<p>The first step in building a package is to fetch the
distribution files (distfiles) from the sites that are providing
them. This is the task of the <span class="emphasis"><em>fetch</em></span>
phase.</p>
<div class="sect2">
<div class="titlepage"><div><div><h3 class="title">
-<a name="build.fetch.what"></a>13.5.1.�What to fetch and where to get it from</h3></div></div></div>
+<a name="build.fetch.what"></a>13.5.1. What to fetch and where to get it from</h3></div></div></div>
<p>In simple cases, <code class="varname">MASTER_SITES</code>
defines all URLs from where the distfile, whose name is
derived from the <code class="varname">DISTNAME</code> variable, is
@@ -4493,7 +4493,7 @@ MASTER_SITES= ${MASTER_SITE_SOURCEFORG
</div>
<div class="sect2">
<div class="titlepage"><div><div><h3 class="title">
-<a name="build.fetch.how"></a>13.5.2.�How are the files fetched?</h3></div></div></div>
+<a name="build.fetch.how"></a>13.5.2. How are the files fetched?</h3></div></div></div>
<p>The <span class="emphasis"><em>fetch</em></span> phase makes sure that
all the distfiles exist in a local directory
(<code class="varname">DISTDIR</code>, which can be set by the pkgsrc
@@ -4521,13 +4521,13 @@ ${FETCH_CMD} ${FETCH_BEFORE_ARGS} ${site
<span class="emphasis"><em>mirror-distfiles</em></span> target to mirror the
distfiles, if they are freely distributable. Packages setting
<code class="varname">NO_SRC_ON_FTP</code> (usually to
- <span class="quote">“<span class="quote">${RESTRICTED}</span>”</span>) will not have their distfiles
+ <span class="quote">“<span class="quote">${RESTRICTED}</span>”</span>) will not have their distfiles
mirrored.</p>
</div>
</div>
<div class="sect1">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="build.checksum"></a>13.6.�The <span class="emphasis"><em>checksum</em></span> phase</h2></div></div></div>
+<a name="build.checksum"></a>13.6. The <span class="emphasis"><em>checksum</em></span> phase</h2></div></div></div>
<p>After the distfile(s) are fetched, their checksum is
generated and compared with the checksums stored in the
distinfo file. If the checksums don't match, the build is
@@ -4538,7 +4538,7 @@ ${FETCH_CMD} ${FETCH_BEFORE_ARGS} ${site
</div>
<div class="sect1">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="build.extract"></a>13.7.�The <span class="emphasis"><em>extract</em></span> phase</h2></div></div></div>
+<a name="build.extract"></a>13.7. The <span class="emphasis"><em>extract</em></span> phase</h2></div></div></div>
<p>When the distfiles are present on the local system, they
need to be extracted, as they usually come in the form of some
compressed archive format.</p>
@@ -4578,7 +4578,7 @@ ${FETCH_CMD} ${FETCH_BEFORE_ARGS} ${site
</div>
<div class="sect1">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="build.patch"></a>13.8.�The <span class="emphasis"><em>patch</em></span> phase</h2></div></div></div>
+<a name="build.patch"></a>13.8. The <span class="emphasis"><em>patch</em></span> phase</h2></div></div></div>
<p>After extraction, all the patches named by the
<code class="varname">PATCHFILES</code>, those present in the patches
subdirectory of the package as well as in
@@ -4589,7 +4589,7 @@ ${FETCH_CMD} ${FETCH_BEFORE_ARGS} ${site
applied, files ending in <code class="filename">.orig</code> or
<code class="filename">.rej</code> are ignored. Any special options to
<a class="citerefentry" href="//man.NetBSD.org/NetBSD-10.1/patch.1"><span class="citerefentry"><span class="refentrytitle">patch</span>(1)</span></a> can be handed in
- <code class="varname">PATCH_DIST_ARGS</code>. See <a class="xref" href="#components.patches" title="12.3.�patches/*">Section�12.3, “<code class="filename">patches/*</code>”</a> for
more details.</p>
+ <code class="varname">PATCH_DIST_ARGS</code>. See <a class="xref" href="#components.patches" title="12.3. patches/*">Section 12.3, “<code class="filename">patches/*</code>”</a> for more
details.</p>
<p>By default <a class="citerefentry" href="//man.NetBSD.org/NetBSD-10.1/patch.1"><span class="citerefentry"><span class="refentrytitle">patch</span>(1)</span></a> is given special arguments to make
it
fail if the expected text from the patch context is not found in the
patched file. If that happens, fix the patch file by comparing it
@@ -4597,13 +4597,13 @@ ${FETCH_CMD} ${FETCH_BEFORE_ARGS} ${site
</div>
<div class="sect1">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="build.tools"></a>13.9.�The <span class="emphasis"><em>tools</em></span> phase</h2></div></div></div>
-<p>This is covered in <a class="xref" href="#tools" title="Chapter�17.�Tools needed for building or running">Chapter�17, <i>Tools needed for building or running</i></a>.
+<a name="build.tools"></a>13.9. The <span class="emphasis"><em>tools</em></span> phase</h2></div></div></div>
+<p>This is covered in <a class="xref" href="#tools" title="Chapter 17. Tools needed for building or running">Chapter 17, <i>Tools needed for building or running</i></a>.
</p>
</div>
<div class="sect1">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="build.wrapper"></a>13.10.�The <span class="emphasis"><em>wrapper</em></span> phase</h2></div></div></div>
+<a name="build.wrapper"></a>13.10. The <span class="emphasis"><em>wrapper</em></span> phase</h2></div></div></div>
<p>This phase creates wrapper programs for the compilers and
linkers. The following variables can be used to tweak the
wrappers.</p>
@@ -4638,7 +4638,7 @@ ${FETCH_CMD} ${FETCH_BEFORE_ARGS} ${site
</div>
<div class="sect1">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="build.configure"></a>13.11.�The <span class="emphasis"><em>configure</em></span> phase</h2></div></div></div>
+<a name="build.configure"></a>13.11. The <span class="emphasis"><em>configure</em></span> phase</h2></div></div></div>
<p>Most pieces of software need information on the header
files, system calls, and library routines which are available
on the platform they run on. The process of determining this
@@ -4648,9 +4648,9 @@ ${FETCH_CMD} ${FETCH_BEFORE_ARGS} ${site
files, Makefiles, etc.</p>
<p>If the package contains a configure script, this can be
invoked by setting <code class="varname">HAS_CONFIGURE</code> to
- <span class="quote">“<span class="quote">yes</span>”</span>. If the configure script is a GNU autoconf
+ <span class="quote">“<span class="quote">yes</span>”</span>. If the configure script is a GNU autoconf
script, you should set <code class="varname">GNU_CONFIGURE</code> to
- <span class="quote">“<span class="quote">yes</span>”</span> instead.</p>
+ <span class="quote">“<span class="quote">yes</span>”</span> instead.</p>
<p>In the <code class="literal">do-configure</code> stage, a rough
equivalent of the following command is run. See
<code class="filename">mk/configure/configure.mk</code>, target
@@ -4664,14 +4664,14 @@ ${FETCH_CMD} ${FETCH_BEFORE_ARGS} ${site
.endfor
</pre>
<p><code class="varname">CONFIGURE_DIRS</code> (default:
- <span class="quote">“<span class="quote">.</span>”</span>) is a list of pathnames relative to
+ <span class="quote">“<span class="quote">.</span>”</span>) is a list of pathnames relative to
<code class="varname">WRKSRC</code>. In each of these directories, the
configure script is run with the environment
<code class="varname">CONFIGURE_ENV</code> and arguments
<code class="varname">CONFIGURE_ARGS</code>. The variables
<code class="varname">CONFIGURE_ENV</code>,
<code class="varname">CONFIGURE_SCRIPT</code> (default:
- <span class="quote">“<span class="quote">./configure</span>”</span>) and
+ <span class="quote">“<span class="quote">./configure</span>”</span>) and
<code class="varname">CONFIGURE_ARGS</code> may all be changed by the
package.</p>
<p>If the program uses the Perl way of configuration (mainly Perl
@@ -4683,7 +4683,7 @@ ${FETCH_CMD} ${FETCH_BEFORE_ARGS} ${site
<p>If the program uses an <code class="filename">Imakefile</code>
for configuration, the appropriate steps can be invoked by
setting <code class="varname">USE_IMAKE</code> to
- <span class="quote">“<span class="quote">yes</span>”</span>. If you only need xmkmf, add it to <code class="varname">USE_TOOLS</code>.
+ <span class="quote">“<span class="quote">yes</span>”</span>. If you only need xmkmf, add it to <code class="varname">USE_TOOLS</code>.
You can add variables to xmkmf's environment by adding them to the
<code class="varname">SCRIPTS_ENV</code> variable.</p>
<p>If the program uses <code class="filename">cmake</code>
@@ -4698,7 +4698,7 @@ ${FETCH_CMD} ${FETCH_BEFORE_ARGS} ${site
<code class="varname">CMAKE_INSTALL_ARGS</code> variables.
You can set the <code class="varname">CONFIGURE_DIRS</code> variable to the
directories in which CMake should be run, relative to
- <code class="varname">WRKSRC</code>. This defaults to to <span class="quote">“<span class="quote">.</span>”</span>.
+ <code class="varname">WRKSRC</code>. This defaults to to <span class="quote">“<span class="quote">.</span>”</span>.
</p>
<p>Any package using the now-deprecated
<code class="varname">USE_CMAKE=yes</code> should be converted.
@@ -4708,11 +4708,11 @@ ${FETCH_CMD} ${FETCH_BEFORE_ARGS} ${site
intend to perform the build in a subdirectory.
</p>
<p>If there is no configure step at all, set
- <code class="varname">NO_CONFIGURE</code> to <span class="quote">“<span class="quote">yes</span>”</span>.</p>
+ <code class="varname">NO_CONFIGURE</code> to <span class="quote">“<span class="quote">yes</span>”</span>.</p>
</div>
<div class="sect1">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="build.build"></a>13.12.�The <span class="emphasis"><em>build</em></span> phase</h2></div></div></div>
+<a name="build.build"></a>13.12. The <span class="emphasis"><em>build</em></span> phase</h2></div></div></div>
<p>For building a package, a rough equivalent of the following
code is executed; see <code class="filename">mk/build/build.mk</code>, target
<code class="literal">do-build</code> for the exact definition.</p>
@@ -4726,7 +4726,7 @@ ${FETCH_CMD} ${FETCH_BEFORE_ARGS} ${site
.endfor
</pre>
<p><code class="varname">BUILD_DIRS</code> (default:
- <span class="quote">“<span class="quote">.</span>”</span>) is a list of pathnames relative to
+ <span class="quote">“<span class="quote">.</span>”</span>) is a list of pathnames relative to
<code class="varname">WRKSRC</code>. In each of these directories,
<code class="varname">MAKE_PROGRAM</code> is run with the environment
<code class="varname">MAKE_ENV</code> and arguments
@@ -4737,22 +4737,22 @@ ${FETCH_CMD} ${FETCH_BEFORE_ARGS} ${site
<code class="varname">BUILD_TARGET</code> may all be changed by the
package.</p>
<p>The default value of <code class="varname">MAKE_PROGRAM</code> is
- <span class="quote">“<span class="quote">gmake</span>”</span> if <code class="varname">USE_TOOLS</code> contains
- <span class="quote">“<span class="quote">gmake</span>”</span>, <span class="quote">“<span class="quote">make</span>”</span> otherwise. The
+ <span class="quote">“<span class="quote">gmake</span>”</span> if <code class="varname">USE_TOOLS</code> contains
+ <span class="quote">“<span class="quote">gmake</span>”</span>, <span class="quote">“<span class="quote">make</span>”</span> otherwise. The
default value of <code class="varname">MAKE_FILE</code> is
- <span class="quote">“<span class="quote">Makefile</span>”</span>, and <code class="varname">BUILD_TARGET</code>
- defaults to <span class="quote">“<span class="quote">all</span>”</span>.</p>
+ <span class="quote">“<span class="quote">Makefile</span>”</span>, and <code class="varname">BUILD_TARGET</code>
+ defaults to <span class="quote">“<span class="quote">all</span>”</span>.</p>
<p>If there is no build step at all, set
- <code class="varname">NO_BUILD</code> to <span class="quote">“<span class="quote">yes</span>”</span>.</p>
+ <code class="varname">NO_BUILD</code> to <span class="quote">“<span class="quote">yes</span>”</span>.</p>
</div>
<div class="sect1">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="build.test"></a>13.13.�The <span class="emphasis"><em>test</em></span> phase</h2></div></div></div>
+<a name="build.test"></a>13.13. The <span class="emphasis"><em>test</em></span> phase</h2></div></div></div>
<p>[TODO]</p>
</div>
<div class="sect1">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="build.install"></a>13.14.�The <span class="emphasis"><em>install</em></span> phase</h2></div></div></div>
+<a name="build.install"></a>13.14. The <span class="emphasis"><em>install</em></span> phase</h2></div></div></div>
<p>Once the build stage has completed, the final step is to
install the software in public directories, so users can
access the programs and files.</p>
@@ -4775,8 +4775,8 @@ ${FETCH_CMD} ${FETCH_BEFORE_ARGS} ${site
<span class="emphasis"><em>build</em></span> phase.
<code class="varname">INSTALL_DIRS</code> defaults to
<code class="varname">BUILD_DIRS</code>. <code class="varname">INSTALL_TARGET</code>
- is <span class="quote">“<span class="quote">install</span>”</span> by default, plus
- <span class="quote">“<span class="quote">install.man</span>”</span> if <code class="varname">USE_IMAKE</code> is
+ is <span class="quote">“<span class="quote">install</span>”</span> by default, plus
+ <span class="quote">“<span class="quote">install.man</span>”</span> if <code class="varname">USE_IMAKE</code> is
defined and <code class="varname">NO_INSTALL_MANPAGES</code> is not
defined.</p>
<p>In the <span class="emphasis"><em>install</em></span> phase, the following
@@ -4840,13 +4840,13 @@ ${FETCH_CMD} ${FETCH_BEFORE_ARGS} ${site
</p></dd>
</dl></div>
<p>In the rare cases that a package shouldn't install anything,
- set <code class="varname">NO_INSTALL</code> to <span class="quote">“<span class="quote">yes</span>”</span>. This is
+ set <code class="varname">NO_INSTALL</code> to <span class="quote">“<span class="quote">yes</span>”</span>. This is
mostly relevant for packages in the <code class="filename">regress</code>
category.</p>
</div>
<div class="sect1">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="build.package"></a>13.15.�The <span class="emphasis"><em>package</em></span> phase</h2></div></div></div>
+<a name="build.package"></a>13.15. The <span class="emphasis"><em>package</em></span> phase</h2></div></div></div>
<p>Once the install stage has completed, a binary package of
the installed files can be built. These binary packages can be
used for quick installation without previous compilation, e.g. by
@@ -4861,7 +4861,7 @@ ${FETCH_CMD} ${FETCH_BEFORE_ARGS} ${site
</div>
<div class="sect1">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="build.clean"></a>13.16.�Cleaning up</h2></div></div></div>
+<a name="build.clean"></a>13.16. Cleaning up</h2></div></div></div>
<p>Once you're finished with a package, you can clean the work
directory by running <span class="command"><strong>make clean</strong></span>. If you want
to clean the work directories of all dependencies too, use
@@ -4869,14 +4869,14 @@ ${FETCH_CMD} ${FETCH_BEFORE_ARGS} ${site
</div>
<div class="sect1">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="build.helpful-targets"></a>13.17.�Other helpful targets</h2></div></div></div>
+<a name="build.helpful-targets"></a>13.17. Other helpful targets</h2></div></div></div>
<div class="variablelist"><dl class="variablelist">
<dt><span class="term">pre/post-*</span></dt>
<dd>
<p>For any of the main targets described in the previous
section (configure, build, install, etc.), two auxiliary
targets exist with
- <span class="quote">“<span class="quote">pre-</span>”</span> and <span class="quote">“<span class="quote">post-</span>”</span> used as a
+ <span class="quote">“<span class="quote">pre-</span>”</span> and <span class="quote">“<span class="quote">post-</span>”</span> used as a
prefix for the main target's name. These targets are
invoked before and after the main target is called,
allowing extra configuration or installation steps be
@@ -4905,12 +4905,12 @@ ${FETCH_CMD} ${FETCH_BEFORE_ARGS} ${site
<p>If you did a <span class="command"><strong>make install</strong></span> and
you noticed some file was not installed properly, you
can repeat the installation with this target, which will
- ignore the <span class="quote">“<span class="quote">already installed</span>”</span> flag.</p>
+ ignore the <span class="quote">“<span class="quote">already installed</span>”</span> flag.</p>
<p>This is the default value of
<code class="varname">DEPENDS_TARGET</code> except in the case of
<span class="command"><strong>make update</strong></span> and <span class="command"><strong>make
package</strong></span>, where the defaults are
- <span class="quote">“<span class="quote">package</span>”</span> and <span class="quote">“<span class="quote">update</span>”</span>,
+ <span class="quote">“<span class="quote">package</span>”</span> and <span class="quote">“<span class="quote">update</span>”</span>,
respectively.</p>
</dd>
<dt><span class="term">deinstall</span></dt>
@@ -4930,7 +4930,7 @@ ${FETCH_CMD} ${FETCH_BEFORE_ARGS} ${site
DEINSTALLDEPENDS=1</strong></span> is done in
<code class="filename">pkgsrc/x11/kde</code>, this is
likely to remove whole KDE. Works by adding
- <span class="quote">“<span class="quote">-R</span>”</span> to the <a class="citerefentry" href="//man.NetBSD.org/NetBSD-10.1/pkg_delete.1"><span class="citerefentry"><span
class="refentrytitle">pkg_delete</span>(1)</span></a>
+ <span class="quote">“<span class="quote">-R</span>”</span> to the <a class="citerefentry" href="//man.NetBSD.org/NetBSD-10.1/pkg_delete.1"><span class="citerefentry"><span
class="refentrytitle">pkg_delete</span>(1)</span></a>
command line.</p></dd>
</dl></div>
</dd>
@@ -4963,7 +4963,7 @@ ${FETCH_CMD} ${FETCH_BEFORE_ARGS} ${site
<span class="command"><strong>make install</strong></span> (or whatever
<code class="varname">UPDATE_TARGET</code> is set to) for these
packages.</p>
-<p>You can use the <span class="quote">“<span class="quote">update</span>”</span> target to
+<p>You can use the <span class="quote">“<span class="quote">update</span>”</span> target to
resume package updating in case a previous <span class="command"><strong>make
update</strong></span> was interrupted for some reason.
However, in this case, make sure you don't call
@@ -4987,18 +4987,18 @@ ${FETCH_CMD} ${FETCH_BEFORE_ARGS} ${site
<dd><p>Install target to recursively use for the
updated package and the dependent packages.
Defaults to <code class="varname">DEPENDS_TARGET</code> if
- set, <span class="quote">“<span class="quote">install</span>”</span> otherwise for
+ set, <span class="quote">“<span class="quote">install</span>”</span> otherwise for
<span class="command"><strong>make update</strong></span>. Other good
- targets are <span class="quote">“<span class="quote">package</span>”</span> or
- <span class="quote">“<span class="quote">bin-install</span>”</span>. Do not set this to
- <span class="quote">“<span class="quote">update</span>”</span> or you will get stuck in an
+ targets are <span class="quote">“<span class="quote">package</span>”</span> or
+ <span class="quote">“<span class="quote">bin-install</span>”</span>. Do not set this to
+ <span class="quote">“<span class="quote">update</span>”</span> or you will get stuck in an
endless loop!</p></dd>
<dt><span class="term"><code class="varname">NOCLEAN</code></span></dt>
<dd><p>Don't clean up after updating. Useful if
you want to leave the work sources of the updated
packages around for inspection or other purposes.
Be sure you eventually clean up the source tree
- (see the <span class="quote">“<span class="quote">clean-update</span>”</span> target below)
+ (see the <span class="quote">“<span class="quote">clean-update</span>”</span> target below)
or you may run into troubles with old source code
still lying around on your next
<span class="command"><strong>make</strong></span> or <span class="command"><strong>make
@@ -5007,13 +5007,13 @@ ${FETCH_CMD} ${FETCH_BEFORE_ARGS} ${site
<dd><p>Deinstall each package before installing
(making <code class="varname">DEPENDS_TARGET</code>). This
may be necessary if the
- <span class="quote">“<span class="quote">clean-update</span>”</span> target (see below) was
+ <span class="quote">“<span class="quote">clean-update</span>”</span> target (see below) was
called after interrupting a running <span class="command"><strong>make
update</strong></span>.</p></dd>
<dt><span class="term"><code class="varname">DEPENDS_TARGET</code></span></dt>
<dd><p>Allows you to disable recursion and hardcode
the target for packages. The default is
- <span class="quote">“<span class="quote">update</span>”</span> for the update target,
+ <span class="quote">“<span class="quote">update</span>”</span> for the update target,
facilitating a recursive update of prerequisite
packages. Only set
<code class="varname">DEPENDS_TARGET</code> if you want to
@@ -5139,7 +5139,7 @@ ${FETCH_CMD} ${FETCH_BEFORE_ARGS} ${site
readme</strong></span>.</p></dd>
<dt><span class="term">cdrom-readme</span></dt>
<dd><p>This is very much the same as the
- <span class="quote">“<span class="quote">readme</span>”</span> target (see above), but is to be
+ <span class="quote">“<span class="quote">readme</span>”</span> target (see above), but is to be
used when generating a pkgsrc tree to be written to a
CD-ROM. This target also produces
<code class="filename">index.html</code> files, and can be made
@@ -5169,7 +5169,7 @@ ${FETCH_CMD} ${FETCH_BEFORE_ARGS} ${site
intended to be used by people who may wish to upgrade
many packages on a single host, and can be invoked from
the top-level pkgsrc Makefile by using the
- <span class="quote">“<span class="quote">show-host-specific-pkgs</span>”</span> target.</p></dd>
+ <span class="quote">“<span class="quote">show-host-specific-pkgs</span>”</span> target.</p></dd>
<dt><span class="term">show-installed-depends</span></dt>
<dd><p>This target shows which installed packages match
the current package's <code class="varname">DEPENDS</code>. Useful
@@ -5188,7 +5188,7 @@ ${FETCH_CMD} ${FETCH_BEFORE_ARGS} ${site
if <code class="varname">PKG_DEVELOPER</code> is set in <a class="link" href="#mk.conf"><code class="filename">mk.conf</code></a>.</p></dd>
<dt><span class="term">print-PLIST</span></dt>
<dd>
-<p>After a <span class="quote">“<span class="quote">make install</span>”</span> from a new or
+<p>After a <span class="quote">“<span class="quote">make install</span>”</span> from a new or
upgraded pkg, this prints out an attempt to generate a
new <code class="filename">PLIST</code> from a <span class="command"><strong>find
-newer work/.extract_done</strong></span>. An attempt is made
@@ -5201,36 +5201,36 @@ ${FETCH_CMD} ${FETCH_BEFORE_ARGS} ${site
<p>If the package installs files via <a class="citerefentry" href="//man.NetBSD.org/NetBSD-10.1/tar.1"><span class="citerefentry"><span class="refentrytitle">tar</span>(1)</span></a> or
other methods that don't update file access times, be
sure to add these files manually to your
- <code class="filename">PLIST</code>, as the <span class="quote">“<span class="quote">find
- -newer</span>”</span> command used by this target won't catch
+ <code class="filename">PLIST</code>, as the <span class="quote">“<span class="quote">find
+ -newer</span>”</span> command used by this target won't catch
them!</p>
-<p>See <a class="xref" href="#print-PLIST" title="19.3.�Tweaking output of make print-PLIST">Section�19.3, “Tweaking output of <span class="command"><strong>make
print-PLIST</strong></span>”</a> for more
+<p>See <a class="xref" href="#print-PLIST" title="19.3. Tweaking output of make print-PLIST">Section 19.3, “Tweaking output of <span class="command"><strong>make print-PLIST</strong></span>”</a> for
more
information on this target.</p>
</dd>
<dt><span class="term">rebuild</span></dt>
<dd><p>If you did a <span class="command"><strong>make build</strong></span> and you
noticed some further modifications of sources are needed,
you can repeat the build with this target, which will ignore
- the <span class="quote">“<span class="quote">already built</span>”</span> flag. This target is
+ the <span class="quote">“<span class="quote">already built</span>”</span> flag. This target is
helpful while working with patches.</p></dd>
<dt><span class="term">repackage</span></dt>
<dd><p>If you did a <span class="command"><strong>make package</strong></span> and you
noticed some further modifications of sources are needed,
you can repeat the package with this target, which will ignore
- the <span class="quote">“<span class="quote">already packaged</span>”</span> flag. This target is
+ the <span class="quote">“<span class="quote">already packaged</span>”</span> flag. This target is
helpful while working with patches, PLIST* files etc.</p></dd>
<dt><span class="term">retest</span></dt>
<dd><p>If you did a <span class="command"><strong>make test</strong></span> and you
noticed some further modifications of sources are needed,
you can repeat the test with this target, which will ignore
- the <span class="quote">“<span class="quote">already tested</span>”</span> flag. This target is
+ the <span class="quote">“<span class="quote">already tested</span>”</span> flag. This target is
helpful while working with patches.</p></dd>
</dl></div>
</div>
</div>
<div class="chapter">
<div class="titlepage"><div><div><h2 class="title">
-<a name="creating"></a>Chapter�14.�Creating a new pkgsrc package from scratch</h2></div></div></div>
+<a name="creating"></a>Chapter 14. Creating a new pkgsrc package from scratch</h2></div></div></div>
<div class="toc">
<p><b>Table of Contents</b></p>
<dl class="toc">
@@ -5318,12 +5318,12 @@ DEPENDS+= screen>=4.0:../../mis
</pre>
</li>
<li class="step"><p>Run <span class="command"><strong>pkglint</strong></span> to see what things still need
-to be done to make your package a <span class="quote">“<span class="quote">good</span>”</span> one. If you don't
+to be done to make your package a <span class="quote">“<span class="quote">good</span>”</span> one. If you don't
know what pkglint's warnings want to tell you, try <span class="command"><strong>pkglint
--explain</strong></span> or <span class="command"><strong>pkglint -e</strong></span>, which outputs
additional explanations.</p></li>
<li class="step"><p>In many cases the package is not yet ready to build. You can
-find instructions for the most common cases in the next section, <a class="xref" href="#creating.common" title="14.1.�Common types of packages">Section�14.1, “Common types of
packages”</a>. After you have followed the instructions
+find instructions for the most common cases in the next section, <a class="xref" href="#creating.common" title="14.1. Common types of packages">Section 14.1, “Common types of packages”</a>. After
you have followed the instructions
over there, you can hopefully continue here.</p></li>
<li class="step"><p>Run <span class="command"><strong>bmake clean</strong></span> to clean the working
directory from the extracted files. Besides these files, a lot of cache
@@ -5332,7 +5332,7 @@ directory, which may have become outdate
<code class="filename">Makefile</code>.</p></li>
<li class="step">
<p>Now, run <span class="command"><strong>bmake</strong></span> to build the package. For
-the various things that can go wrong in this phase, consult <a class="xref" href="#fixes" title="Chapter�21.�Making your package work">Chapter�21, <i>Making your package work</i></a>.</p>
+the various things that can go wrong in this phase, consult <a class="xref" href="#fixes" title="Chapter 21. Making your package work">Chapter 21, <i>Making your package work</i></a>.</p>
<p>If the extracted files from the package need to be fixed, run
multiple rounds of these commands:</p>
<pre class="screen"><code class="prompt">$</code> <strong class="userinput"><code>bmake</code></strong>
@@ -5363,14 +5363,14 @@ from above again in a single step, makin
and the whole package is created as intended.</p></li>
<li class="step"><p>Run <span class="command"><strong>pkglint</strong></span> to see if there's anything
left to do.</p></li>
-<li class="step"><p>Commit the package to pkgsrc-wip or main pkgsrc; see <a class="xref" href="#submit" title="Chapter�23.�Submitting and Committing">Chapter�23, <i>Submitting and
Committing</i></a>.</p></li>
+<li class="step"><p>Commit the package to pkgsrc-wip or main pkgsrc; see <a class="xref" href="#submit" title="Chapter 23. Submitting and Committing">Chapter 23, <i>Submitting and
Committing</i></a>.</p></li>
</ol></div>
<div class="sect1">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="creating.common"></a>14.1.�Common types of packages</h2></div></div></div>
+<a name="creating.common"></a>14.1. Common types of packages</h2></div></div></div>
<div class="sect2">
<div class="titlepage"><div><div><h3 class="title">
-<a name="creating.python-module"></a>14.1.1.�Python modules and programs</h3></div></div></div>
+<a name="creating.python-module"></a>14.1.1. Python modules and programs</h3></div></div></div>
<p>Python modules and programs packages are easily created using a
set of predefined variables.</p>
<p>
@@ -5392,8 +5392,8 @@ specifically requires as packaging tools
package Makefile.
</p>
<p>The package directory should be called
-<span class="quote">“<span class="quote">py-software</span>”</span> and <code class="varname">PKGNAME</code> should be set to
-<span class="quote">“<span class="quote">${PYPKGPREFIX}-${DISTNAME}</span>”</span>, e.g.
+<span class="quote">“<span class="quote">py-software</span>”</span> and <code class="varname">PKGNAME</code> should be set to
+<span class="quote">“<span class="quote">${PYPKGPREFIX}-${DISTNAME}</span>”</span>, e.g.
</p>
<pre class="programlisting">
DISTNAME= foopymodule-1.2.10
@@ -5404,7 +5404,7 @@ For software in PyPi, the name should ma
"pip install software".
</p>
<p>If it is an application, include
-<span class="quote">“<span class="quote"><code class="filename">../../lang/python/application.mk</code></span>”</span>.
+<span class="quote">“<span class="quote"><code class="filename">../../lang/python/application.mk</code></span>”</span>.
In order to correctly set the path to the Python interpreter, use the
<code class="varname">REPLACE_PYTHON</code> variable and set it to the list of files
(paths relative to <code class="varname">WRKSRC</code>) that must be corrected.
@@ -5416,7 +5416,7 @@ REPLACE_PYTHON= *.py
</div>
<div class="sect2">
<div class="titlepage"><div><div><h3 class="title">
-<a name="creating.R-package"></a>14.1.2.�R packages</h3></div></div></div>
+<a name="creating.R-package"></a>14.1.2. R packages</h3></div></div></div>
<p>Simple R packages from <a class="ulink" href="https://cran.r-project.org/web/packages/available_packages_by_name.html" target="_top">CRAN</a>
are handled automatically by <span class="command"><strong>R2pkg</strong></span>, which is
available in <a href="https://cdn.NetBSD.org/pub/pkgsrc/current/pkgsrc/pkgtools/R2pkg/index.html" target="_top"><code class="filename">pkgtools/R2pkg</code></a>.
@@ -5431,12 +5431,12 @@ package should be reviewed for correctne
</div>
<div class="sect2">
<div class="titlepage"><div><div><h3 class="title">
-<a name="creating.TeX-package"></a>14.1.3.�TeXlive packages</h3></div></div></div>
+<a name="creating.TeX-package"></a>14.1.3. TeXlive packages</h3></div></div></div>
<p>TeXlive packages from <a class="ulink" href="https://www.ctan.org/" target="_top">CTAN</a> are handled automatically by
<span class="command"><strong>texlive2pkg</strong></span>, which is available in <a href="https://cdn.NetBSD.org/pub/pkgsrc/current/pkgsrc/pkgtools/texlive2pkg/index.html" target="_top"><code
class="filename">pkgtools/texlive2pkg</code></a>.</p>
<p>If the TeXlive package name is not known, it may be useful to
search <a class="ulink" href="https://www.ctan.org/" target="_top">CTAN</a>. A
-<span class="quote">“<span class="quote">Contained in</span>”</span> field on the package page typically
+<span class="quote">“<span class="quote">Contained in</span>”</span> field on the package page typically
identifies the basename of the package file in the <a class="ulink" href="https://www.ctan.org/tex-archive/systems/texlive/tlnet/archive" target="_top">TeXlive
archive</a>.</p>
<p>If the TeXlive package name is known, download the files from
@@ -5468,17 +5468,17 @@ make upload-distfiles
</div>
<div class="sect1">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="creating.examples"></a>14.2.�Examples</h2></div></div></div>
+<a name="creating.examples"></a>14.2. Examples</h2></div></div></div>
<div class="sect2">
<div class="titlepage"><div><div><h3 class="title">
-<a name="creating.nvu"></a>14.2.1.�How the www/nvu package came into pkgsrc</h3></div></div></div>
+<a name="creating.nvu"></a>14.2.1. How the www/nvu package came into pkgsrc</h3></div></div></div>
<div class="sect3">
<div class="titlepage"><div><div><h4 class="title">
-<a name="creating.nvu.init"></a>14.2.1.1.�The initial package</h4></div></div></div>
+<a name="creating.nvu.init"></a>14.2.1.1. The initial package</h4></div></div></div>
<p>Looking at the file <code class="filename">pkgsrc/doc/TODO</code>, I saw
-that the <span class="quote">“<span class="quote">nvu</span>”</span> package has not yet been imported into
+that the <span class="quote">“<span class="quote">nvu</span>”</span> package has not yet been imported into
pkgsrc. As the description says it has to do with the web, the obvious
-choice for the category is <span class="quote">“<span class="quote">www</span>”</span>.</p>
+choice for the category is <span class="quote">“<span class="quote">www</span>”</span>.</p>
<pre class="programlisting">
<code class="prompt">$</code> mkdir www/nvu
<code class="prompt">$</code> cd www/nvu
@@ -5490,7 +5490,7 @@ I fed that URL to the <span class="comma
</pre>
<p>My editor popped up, and I added a <code class="varname">PKGNAME</code> line
below the <code class="varname">DISTNAME</code> line, as the package name should
-not have the word <span class="quote">“<span class="quote">sources</span>”</span> in it. I also filled in the
+not have the word <span class="quote">“<span class="quote">sources</span>”</span> in it. I also filled in the
<code class="varname">MAINTAINER</code>, <code class="varname">HOMEPAGE</code> and
<code class="varname">COMMENT</code> fields. Then the package
<code class="filename">Makefile</code> looked like that:</p>
@@ -5540,7 +5540,7 @@ Good luck! (See pkgsrc/doc/pkgsrc.txt fo
</div>
<div class="sect3">
<div class="titlepage"><div><div><h4 class="title">
-<a name="creating.nvu.problems"></a>14.2.1.2.�Fixing all kinds of problems to make the package work</h4></div></div></div>
+<a name="creating.nvu.problems"></a>14.2.1.2. Fixing all kinds of problems to make the package work</h4></div></div></div>
<p>Now that the package has been extracted, let's see what's inside
it. The package has a <code class="filename">README.txt</code>, but that only
says something about mozilla, so it's probably useless for seeing what
@@ -5563,9 +5563,9 @@ WARNING: Please add USE_TOOLS+=perl to t
</pre>
<p>That worked quite well. So I opened the package Makefile in my
editor, and since it already has a <code class="varname">USE_TOOLS</code> line, I
-just appended <span class="quote">“<span class="quote">perl</span>”</span> to it. Since the dependencies of the
+just appended <span class="quote">“<span class="quote">perl</span>”</span> to it. Since the dependencies of the
package have changed now, and since a perl wrapper is automatically
-installed in the <span class="quote">“<span class="quote">tools</span>”</span> phase, I need to build the package
+installed in the <span class="quote">“<span class="quote">tools</span>”</span> phase, I need to build the package
from scratch.</p>
<pre class="programlisting">
<code class="prompt">$</code> bmake clean
@@ -5576,7 +5576,7 @@ from scratch.</p>
GNU Make. You will not be able to build Mozilla without GNU Make.
[...]
</pre>
-<p>So I added <span class="quote">“<span class="quote">gmake</span>”</span> to the
+<p>So I added <span class="quote">“<span class="quote">gmake</span>”</span> to the
<code class="varname">USE_TOOLS</code> line and tried again (from scratch).</p>
<pre class="programlisting">
[...]
@@ -5601,7 +5601,7 @@ one result, which is very good. But ther
packages. Before GNOME 2 had been released, there were already many
GNOME 1 packages in pkgsrc. To be able to continue to use these
packages, the GNOME 2 packages were imported as separate packages, and
-their names usually have a <span class="quote">“<span class="quote">2</span>”</span> appended. So I checked
+their names usually have a <span class="quote">“<span class="quote">2</span>”</span> appended. So I checked
whether this was the case here, and indeed it was.</p>
<p>Since the GTK2 package has a <code class="filename">buildlink3.mk</code>
file, adding the dependency is very easy. I just inserted an
@@ -5626,8 +5626,8 @@ checking for GTK - version >= 1.2.0..
configure: error: Test for GTK failed.
[...]
</pre>
-<p>In this particular case, the assumption that <span class="quote">“<span class="quote">every package
-prefers GNOME 2</span>”</span> had been wrong. The first of the lines above
+<p>In this particular case, the assumption that <span class="quote">“<span class="quote">every package
+prefers GNOME 2</span>”</span> had been wrong. The first of the lines above
told me that this package really wanted to have the GNOME 1 version of
GTK. If the package had looked for GTK2, it would have looked for
<span class="command"><strong>pkg-config</strong></span> instead of <span class="command"><strong>gtk-config</strong></span>.
@@ -5676,7 +5676,7 @@ everything worked.</p>
</div>
<div class="sect3">
<div class="titlepage"><div><div><h4 class="title">
-<a name="creating.nvu.inst"></a>14.2.1.3.�Installing the package</h4></div></div></div>
+<a name="creating.nvu.inst"></a>14.2.1.3. Installing the package</h4></div></div></div>
<pre class="programlisting">
<code class="prompt">$</code> bmake CHECK_FILES=no install
[...]
@@ -5690,7 +5690,7 @@ everything worked.</p>
</div>
<div class="chapter">
<div class="titlepage"><div><div><h2 class="title">
-<a name="makefile"></a>Chapter�15.�Programming in <code class="filename">Makefile</code>s</h2></div></div></div>
+<a name="makefile"></a>Chapter 15. Programming in <code class="filename">Makefile</code>s</h2></div></div></div>
<div class="toc">
<p><b>Table of Contents</b></p>
<dl class="toc">
@@ -5723,7 +5723,7 @@ everything worked.</p>
with them.</p>
<div class="sect1">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="makefile.style"></a>15.1.�Caveats</h2></div></div></div>
+<a name="makefile.style"></a>15.1. Caveats</h2></div></div></div>
<div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; "><li class="listitem">
<p>When you are creating a file as a
target of a rule, always write the data to a temporary file first
@@ -5756,7 +5756,7 @@ correct:
</div>
<div class="sect1">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="makefile.variables"></a>15.2.�<code class="filename">Makefile</code> variables</h2></div></div></div>
+<a name="makefile.variables"></a>15.2. <code class="filename">Makefile</code> variables</h2></div></div></div>
<p><code class="filename">Makefile</code> variables contain strings that
can be processed using the five operators <code class="code">=</code>,
<code class="code">+=</code>, <code class="code">?=</code>, <code class="code">:=</code> and
@@ -5781,7 +5781,7 @@ correct:
interpreted as delimiters, just like in <a class="citerefentry" href="//man.NetBSD.org/NetBSD-10.1/sh.1"><span class="citerefentry"><span class="refentrytitle">sh</span>(1)</span></a>.</p>
<div class="sect2">
<div class="titlepage"><div><div><h3 class="title">
-<a name="makefile.variables.names"></a>15.2.1.�Naming conventions</h3></div></div></div>
+<a name="makefile.variables.names"></a>15.2.1. Naming conventions</h3></div></div></div>
<div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; ">
<li class="listitem"><p>All variable names starting with an underscore
are reserved for use by the pkgsrc infrastructure. They shall
@@ -5797,10 +5797,10 @@ correct:
</div>
<div class="sect1">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="makefile.code"></a>15.3.�Code snippets</h2></div></div></div>
+<a name="makefile.code"></a>15.3. Code snippets</h2></div></div></div>
<div class="sect2">
<div class="titlepage"><div><div><h3 class="title">
-<a name="adding-to-list"></a>15.3.1.�Adding things to a list</h3></div></div></div>
+<a name="adding-to-list"></a>15.3.1. Adding things to a list</h3></div></div></div>
<p>When adding a string that possibly contains whitespace or quotes to
a list (example 1), it must be quoted using the <code class="code">:Q</code>
modifier.</p>
@@ -5817,7 +5817,7 @@ LIST+= ${ANOTHER_LIST} # 2
</div>
<div class="sect2">
<div class="titlepage"><div><div><h3 class="title">
-<a name="echo-literal"></a>15.3.2.�Echoing a string exactly as-is</h3></div></div></div>
+<a name="echo-literal"></a>15.3.2. Echoing a string exactly as-is</h3></div></div></div>
<p>Echoing a string containing special characters needs special
work.</p>
<pre class="programlisting">
@@ -5847,7 +5847,7 @@ when adding elements to the list.</p>
</div>
<div class="sect2">
<div class="titlepage"><div><div><h3 class="title">
-<a name="cflags-gnu-configure"></a>15.3.3.�Passing <code class="varname">CFLAGS</code> to GNU configure scripts</h3></div></div></div>
+<a name="cflags-gnu-configure"></a>15.3.3. Passing <code class="varname">CFLAGS</code> to GNU configure scripts</h3></div></div></div>
<p>When passing <code class="varname">CFLAGS</code> or similar variables to a
GNU-style configure script (especially those that call other configure
scripts), it must not have leading or trailing whitespace, since
@@ -5871,7 +5871,7 @@ space.</p>
</div>
<div class="sect2">
<div class="titlepage"><div><div><h3 class="title">
-<a name="empty-variables"></a>15.3.4.�Handling possibly empty variables</h3></div></div></div>
+<a name="empty-variables"></a>15.3.4. Handling possibly empty variables</h3></div></div></div>
<p>When a possibly empty variable is used in a shell program, it may
lead to a syntax error.</p>
<pre class="programlisting">
@@ -5911,7 +5911,7 @@ the following code: <code class="code">$
</div>
<div class="sect2">
<div class="titlepage"><div><div><h3 class="title">
-<a name="makefile.yesno"></a>15.3.5.�Testing yes/no variables in conditions</h3></div></div></div>
+<a name="makefile.yesno"></a>15.3.5. Testing yes/no variables in conditions</h3></div></div></div>
<p>When a variable can have the values <code class="literal">yes</code> or
<code class="literal">no</code>, use the following pattern to test the variable:</p>
<pre class="programlisting">
@@ -5930,7 +5930,7 @@ lowercase, allowing for the values <code
</div>
<div class="chapter">
<div class="titlepage"><div><div><h2 class="title">
-<a name="options"></a>Chapter�16.�Options handling</h2></div></div></div>
+<a name="options"></a>Chapter 16. Options handling</h2></div></div></div>
<div class="toc">
<p><b>Table of Contents</b></p>
<dl class="toc">
@@ -5976,7 +5976,7 @@ that depend on non-free dependencies (es
almost always be split if feasible.</p>
<div class="sect1">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="global-default-options"></a>16.1.�Global default options</h2></div></div></div>
+<a name="global-default-options"></a>16.1. Global default options</h2></div></div></div>
<p>Global default options are listed in
<code class="varname">PKG_DEFAULT_OPTIONS</code>, which is a list of the options
that should be built into every package if that option is supported.
@@ -5984,7 +5984,7 @@ This variable should be set in <a class=
</div>
<div class="sect1">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="converting-to-options"></a>16.2.�Converting packages to use <code class="filename">bsd.options.mk</code>
+<a name="converting-to-options"></a>16.2. Converting packages to use <code class="filename">bsd.options.mk</code>
</h2></div></div></div>
<p>The following example shows how
<code class="filename">bsd.options.mk</code> should be used
@@ -6074,17 +6074,17 @@ fail if no option from the set is select
build options which are enabled by default.</p></li>
<li class="listitem"><p><code class="varname">PKG_OPTIONS_LEGACY_VARS</code> is a list
of
-<span class="quote">“<span class="quote"><em class="replaceable"><code>USE_VARIABLE</code></em>:<em class="replaceable"><code>option</code></em></span>”</span>
+<span class="quote">“<span class="quote"><em class="replaceable"><code>USE_VARIABLE</code></em>:<em class="replaceable"><code>option</code></em></span>”</span>
pairs that map legacy <a class="link" href="#mk.conf"><code class="filename">mk.conf</code></a> variables to
their option counterparts. Pairs should be added with
-<span class="quote">“<span class="quote">+=</span>”</span> to keep the listing of global legacy variables. A
+<span class="quote">“<span class="quote">+=</span>”</span> to keep the listing of global legacy variables. A
warning will be issued if the user uses a legacy
variable.</p></li>
<li class="listitem"><p><code class="varname">PKG_OPTIONS_LEGACY_OPTS</code> is a list
of
-<span class="quote">“<span class="quote"><em class="replaceable"><code>old-option</code></em>:<em class="replaceable"><code>new-option</code></em></span>”</span>
+<span class="quote">“<span class="quote"><em class="replaceable"><code>old-option</code></em>:<em class="replaceable"><code>new-option</code></em></span>”</span>
pairs that map options that have been renamed to their new
-counterparts. Pairs should be added with <span class="quote">“<span class="quote">+=</span>”</span> to keep
+counterparts. Pairs should be added with <span class="quote">“<span class="quote">+=</span>”</span> to keep
the listing of global legacy options. A warning will be issued if
the user uses a legacy option.</p></li>
<li class="listitem"><p><code class="varname">PKG_LEGACY_OPTIONS</code> is a list of
@@ -6123,7 +6123,7 @@ whether it is listed in <code class="var
</div>
<div class="sect1">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="option-names"></a>16.3.�Option Names</h2></div></div></div>
+<a name="option-names"></a>16.3. Option Names</h2></div></div></div>
<p>Options that enable similar features in different packages (like
optional support for a library) should use a common name in all
packages that support it (like the name of the library). If another
@@ -6135,19 +6135,19 @@ optional feature, should use a name pref
<code class="varname"><em class="replaceable"><code>pkgname</code></em>-</code>.</p>
<p>If a group of related packages share an optional feature
specific to that group, prefix it with the name of the
-<span class="quote">“<span class="quote">main</span>”</span> package
+<span class="quote">“<span class="quote">main</span>”</span> package
(e. g. <code class="varname">djbware-errno-hack</code>).</p>
<p>For new options, add a line to
<code class="filename">mk/defaults/options.description</code>. Lines have two
fields, separated by tab. The first field is the option name, the
second its description. The description should be a whole sentence
(starting with an uppercase letter and ending with a period) that
-describes what enabling the option does. E. g. <span class="quote">“<span class="quote">Enable ispell
-support.</span>”</span> The file is sorted by option names.</p>
+describes what enabling the option does. E. g. <span class="quote">“<span class="quote">Enable ispell
+support.</span>”</span> The file is sorted by option names.</p>
</div>
<div class="sect1">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="option-build"></a>16.4.�Determining the options of dependencies</h2></div></div></div>
+<a name="option-build"></a>16.4. Determining the options of dependencies</h2></div></div></div>
<p>When writing <a class="link" href="#buildlink3.mk"><code class="filename">buildlink3.mk</code></a> files, it is often necessary to list
different dependencies based on the options with which the package was
built. For querying these options, the file
@@ -6171,7 +6171,7 @@ details.</p>
</div>
<div class="chapter">
<div class="titlepage"><div><div><h2 class="title">
-<a name="tools"></a>Chapter�17.�Tools needed for building or running</h2></div></div></div>
+<a name="tools"></a>Chapter 17. Tools needed for building or running</h2></div></div></div>
<div class="toc">
<p><b>Table of Contents</b></p>
<dl class="toc">
@@ -6201,7 +6201,7 @@ yacc) or a better sed.</p>
<span class="command"><strong>make show-tools</strong></span>.</p>
<div class="sect1">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="pkgsrc-tools"></a>17.1.�Tools for pkgsrc builds</h2></div></div></div>
+<a name="pkgsrc-tools"></a>17.1. Tools for pkgsrc builds</h2></div></div></div>
<p>The default set of tools used by pkgsrc is defined in
<code class="filename">bsd.pkg.mk</code>. This includes standard Unix tools,
such as: <span class="command"><strong>cat</strong></span>, <span class="command"><strong>awk</strong></span>,
@@ -6214,7 +6214,7 @@ to define the tools needed.</p>
</div>
<div class="sect1">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="package-tools"></a>17.2.�Tools needed by packages</h2></div></div></div>
+<a name="package-tools"></a>17.2. Tools needed by packages</h2></div></div></div>
<p>In the following examples, the :run means that it is needed at
run-time (and becomes a DEPENDS).
The default is a build dependency which can be set with
@@ -6226,7 +6226,7 @@ USE_TOOLS+= gmake perl:run pkg-confi
<p>When using the tools framework, a
<code class="varname">TOOLS_PATH.foo</code> variable is defined
which contains the full path to the appropriate tool. For example,
-<code class="varname">TOOLS_PATH.bash</code> could be <span class="quote">“<span class="quote">/bin/bash</span>”</span>
+<code class="varname">TOOLS_PATH.bash</code> could be <span class="quote">“<span class="quote">/bin/bash</span>”</span>
on Linux systems.</p>
<p>If you always need a pkgsrc version of the
tool at run-time, then just use <code class="varname">DEPENDS</code> instead.
@@ -6234,7 +6234,7 @@ tool at run-time, then just use <code cl
</div>
<div class="sect1">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="platform-tools"></a>17.3.�Tools provided by platforms</h2></div></div></div>
+<a name="platform-tools"></a>17.3. Tools provided by platforms</h2></div></div></div>
<p>When improving or porting pkgsrc to a new platform, have a look
at (or create) the corresponding platform specific make file fragment under
<code class="filename">pkgsrc/mk/tools/tools.${OPSYS}.mk</code> which defines
@@ -6252,7 +6252,7 @@ TOOLS_PLATFORM.true?= true
</div>
<div class="chapter">
<div class="titlepage"><div><div><h2 class="title">
-<a name="buildlink"></a>Chapter�18.�Buildlink methodology</h2></div></div></div>
+<a name="buildlink"></a>Chapter 18. Buildlink methodology</h2></div></div></div>
<div class="toc">
<p><b>Table of Contents</b></p>
<dl class="toc">
@@ -6294,9 +6294,9 @@ TOOLS_PLATFORM.true?= true
software.</p>
<div class="sect1">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="converting-to-buildlink3"></a>18.1.�Converting packages to use buildlink3</h2></div></div></div>
+<a name="converting-to-buildlink3"></a>18.1. Converting packages to use buildlink3</h2></div></div></div>
<p>The process of converting packages to use the buildlink3
- framework (<span class="quote">“<span class="quote">bl3ifying</span>”</span>) is fairly straightforward.
+ framework (<span class="quote">“<span class="quote">bl3ifying</span>”</span>) is fairly straightforward.
The things to keep in mind are:</p>
<div class="orderedlist"><ol class="orderedlist" type="1">
<li class="listitem"><p>Ensure that the build always calls the wrapper scripts
@@ -6308,7 +6308,7 @@ TOOLS_PLATFORM.true?= true
the package Makefile, e.g. Java VMs, standalone shells,
etc., because the code to symlink files into
<code class="filename">${BUILDLINK_DIR}</code> looks for files
- relative to <span class="quote">“<span class="quote">pkg_info -qp <em class="replaceable"><code>pkgname</code></em></span>”</span>.
+ relative to <span class="quote">“<span class="quote">pkg_info -qp <em class="replaceable"><code>pkgname</code></em></span>”</span>.
</p></li>
<li class="listitem"><p>Remember that <span class="emphasis"><em>only</em></span> the
<code class="filename">buildlink3.mk</code> files that you list in a
@@ -6349,8 +6349,8 @@ BUILDLINK_API_DEPENDS.foo+= foo>=1.
<li class="listitem"><p><code class="filename">motif.buildlink3.mk</code> checks for a
system-provided Motif installation or adds a dependency on
<a href="https://cdn.NetBSD.org/pub/pkgsrc/current/pkgsrc/x11/lesstif/index.html" target="_top"><code class="filename">x11/lesstif</code></a> or <a
href="https://cdn.NetBSD.org/pub/pkgsrc/current/pkgsrc/x11/motif/index.html" target="_top"><code class="filename">x11/motif</code></a>. The user can set
- <code class="varname">MOTIF_TYPE</code> to <span class="quote">“<span class="quote">dt</span>”</span>,
- <span class="quote">“<span class="quote">lesstif</span>”</span> or <span class="quote">“<span class="quote">motif</span>”</span>
+ <code class="varname">MOTIF_TYPE</code> to <span class="quote">“<span class="quote">dt</span>”</span>,
+ <span class="quote">“<span class="quote">lesstif</span>”</span> or <span class="quote">“<span class="quote">motif</span>”</span>
to choose which Motif version will be used.</p></li>
<li class="listitem"><p><code class="filename">readline.buildlink3.mk</code> checks for a
system-provided GNU readline or editline (libedit) installation,
@@ -6381,7 +6381,7 @@ BUILDLINK_API_DEPENDS.foo+= foo>=1.
</div>
<div class="sect1">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="creating-buildlink3.mk"></a>18.2.�Writing <code class="filename">buildlink3.mk</code> files</h2></div></div></div>
+<a name="creating-buildlink3.mk"></a>18.2. Writing <code class="filename">buildlink3.mk</code> files</h2></div></div></div>
<a name="buildlink3.mk"></a><p>A package's <code class="filename">buildlink3.mk</code> file is
included by Makefiles to indicate the need to compile and link
against header files and libraries provided by the package. A
@@ -6401,7 +6401,7 @@ BUILDLINK_API_DEPENDS.foo+= foo>=1.
</pre>
<div class="sect2">
<div class="titlepage"><div><div><h3 class="title">
-<a name="anatomy-of-bl3"></a>18.2.1.�Anatomy of a buildlink3.mk file</h3></div></div></div>
+<a name="anatomy-of-bl3"></a>18.2.1. Anatomy of a buildlink3.mk file</h3></div></div></div>
<p>The following real-life example
<code class="filename">buildlink3.mk</code> is taken
from <code class="filename">pkgsrc/graphics/tiff</code>:</p>
@@ -6447,7 +6447,7 @@ BUILDLINK_TREE+= -tiff
<em class="replaceable"><code>pkg</code></em>. The build dependency is
selected by setting
<code class="varname">BUILDLINK_DEPMETHOD.<em class="replaceable"><code>pkg</code></em></code>
- to <span class="quote">“<span class="quote">build</span>”</span>. By default, the full dependency is
+ to <span class="quote">“<span class="quote">build</span>”</span>. By default, the full dependency is
used.</p></li>
<li class="listitem"><p><code class="varname">BUILDLINK_INCDIRS.<em class="replaceable"><code>pkg</code></em></code>
and
@@ -6455,12 +6455,12 @@ BUILDLINK_TREE+= -tiff
(not shown above) are lists of subdirectories of
<code class="filename">${BUILDLINK_PREFIX.<em class="replaceable"><code>pkg</code></em>}</code>
to add to the header and library search paths. These
- default to <span class="quote">“<span class="quote">include</span>”</span> and <span class="quote">“<span class="quote">lib</span>”</span>
+ default to <span class="quote">“<span class="quote">include</span>”</span> and <span class="quote">“<span class="quote">lib</span>”</span>
respectively.</p></li>
<li class="listitem"><p><code class="varname">BUILDLINK_CPPFLAGS.<em class="replaceable"><code>pkg</code></em></code>
(not shown above) is the list of preprocessor flags to add
to <code class="varname">CPPFLAGS</code>, which are passed on to the
- configure and build phases. The <span class="quote">“<span class="quote">-I</span>”</span> option
+ configure and build phases. The <span class="quote">“<span class="quote">-I</span>”</span> option
should be avoided and instead be handled using
<code class="varname">BUILDLINK_INCDIRS.<em class="replaceable"><code>pkg</code></em></code> as
above.</p></li>
@@ -6543,7 +6543,7 @@ BUILDLINK_TREE+= -tiff
</div>
<div class="sect2">
<div class="titlepage"><div><div><h3 class="title">
-<a name="updating-buildlink-depends"></a>18.2.2.�Updating
+<a name="updating-buildlink-depends"></a>18.2.2. Updating
<code class="varname">BUILDLINK_API_DEPENDS.<em class="replaceable"><code>pkg</code></em></code>
and
<code class="varname">BUILDLINK_ABI_DEPENDS.<em class="replaceable"><code>pkg</code></em></code>
@@ -6584,7 +6584,7 @@ BUILDLINK_TREE+= -tiff
uniquely identify the packages built against the new ABI. The
<a href="https://cdn.NetBSD.org/pub/pkgsrc/current/pkgsrc/pkgtools/revbump/index.html" target="_top"><code class="filename">pkgtools/revbump</code></a> package can
help with these updates.</p>
-<p>See <a class="xref" href="#dependencies" title="21.1.5.�Handling dependencies">Section�21.1.5, “Handling dependencies”</a> for more information
+<p>See <a class="xref" href="#dependencies" title="21.1.5. Handling dependencies">Section 21.1.5, “Handling dependencies”</a> for more information
about dependencies on other packages, including the
<code class="varname">BUILDLINK_API_DEPENDS</code> definitions.</p>
<p>Please take careful consideration before adjusting
@@ -6606,7 +6606,7 @@ BUILDLINK_TREE+= -tiff
</div>
<div class="sect1">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="writing-builtin.mk"></a>18.3.�Writing <code class="filename">builtin.mk</code> files</h2></div></div></div>
+<a name="writing-builtin.mk"></a>18.3. Writing <code class="filename">builtin.mk</code> files</h2></div></div></div>
<p>Some packages in pkgsrc install headers and libraries that
coincide with headers and libraries present in the base system.
Aside from a <code class="filename">buildlink3.mk</code> file, these
@@ -6619,7 +6619,7 @@ BUILDLINK_TREE+= -tiff
<div class="orderedlist"><ol class="orderedlist" type="1">
<li class="listitem"><p>It should set
<code class="varname">USE_BUILTIN.<em class="replaceable"><code>pkg</code></em></code>
- to either <span class="quote">“<span class="quote">yes</span>”</span> or <span class="quote">“<span class="quote">no</span>”</span>
+ to either <span class="quote">“<span class="quote">yes</span>”</span> or <span class="quote">“<span class="quote">no</span>”</span>
after it is included.</p></li>
<li class="listitem"><p>It should <span class="emphasis"><em>not</em></span> override any
<code class="varname">USE_BUILTIN.<em class="replaceable"><code>pkg</code></em></code>
@@ -6631,7 +6631,7 @@ BUILDLINK_TREE+= -tiff
</ol></div>
<div class="sect2">
<div class="titlepage"><div><div><h3 class="title">
-<a name="anatomy-of-builtin.mk"></a>18.3.1.�Anatomy of a <code class="filename">builtin.mk</code> file</h3></div></div></div>
+<a name="anatomy-of-builtin.mk"></a>18.3.1. Anatomy of a <code class="filename">builtin.mk</code> file</h3></div></div></div>
<p>The following is the recommended template for builtin.mk
files:</p>
<pre class="programlisting">
@@ -6676,7 +6676,7 @@ CHECK_BUILTIN.foo?= no
depending on if <em class="replaceable"><code>pkg</code></em> really exists
in the base system. This should not be a base system software
with similar functionality to <em class="replaceable"><code>pkg</code></em>;
- it should only be <span class="quote">“<span class="quote">yes</span>”</span> if the actual package is
+ it should only be <span class="quote">“<span class="quote">yes</span>”</span> if the actual package is
included as part of the base system. This variable is only
used internally within the <code class="filename">builtin.mk</code>
file.</p>
@@ -6685,7 +6685,7 @@ CHECK_BUILTIN.foo?= no
to the version of <em class="replaceable"><code>pkg</code></em> in the base
system if it exists (if
<code class="varname">IS_BUILTIN.<em class="replaceable"><code>pkg</code></em></code>
- is <span class="quote">“<span class="quote">yes</span>”</span>). This variable is only used internally
+ is <span class="quote">“<span class="quote">yes</span>”</span>). This variable is only used internally
within the <code class="filename">builtin.mk</code> file.</p>
<p>The third section sets
<code class="varname">USE_BUILTIN.<em class="replaceable"><code>pkg</code></em></code>
@@ -6702,9 +6702,9 @@ CHECK_BUILTIN.foo?= no
<span class="emphasis"><em>must</em></span> be set to the correct value by the
end of the <code class="filename">builtin.mk</code> file. Note that
<code class="varname">USE_BUILTIN.<em class="replaceable"><code>pkg</code></em></code>
- may be <span class="quote">“<span class="quote">yes</span>”</span> even if
+ may be <span class="quote">“<span class="quote">yes</span>”</span> even if
<code class="varname">IS_BUILTIN.<em class="replaceable"><code>pkg</code></em></code>
- is <span class="quote">“<span class="quote">no</span>”</span> because we may make the determination
+ is <span class="quote">“<span class="quote">no</span>”</span> because we may make the determination
that the built-in version of the software is similar enough to
be used as a replacement.</p>
<p>The last section is guarded by
@@ -6720,7 +6720,7 @@ CHECK_BUILTIN.foo?= no
</div>
<div class="chapter">
<div class="titlepage"><div><div><h2 class="title">
-<a name="plist"></a>Chapter�19.�PLIST issues</h2></div></div></div>
+<a name="plist"></a>Chapter 19. PLIST issues</h2></div></div></div>
<div class="toc">
<p><b>Table of Contents</b></p>
<dl class="toc">
@@ -6736,7 +6736,7 @@ CHECK_BUILTIN.foo?= no
</dl>
</div>
<p>The <code class="filename">PLIST</code> file contains a package's
- <span class="quote">“<span class="quote">packing list</span>”</span>, i.e. a list of files that belong to
+ <span class="quote">“<span class="quote">packing list</span>”</span>, i.e. a list of files that belong to
the package (relative to the <code class="filename">${PREFIX}</code>
directory it's been installed in) plus some additional statements
- see the <a class="citerefentry" href="//man.NetBSD.org/NetBSD-10.1/pkg_create.1"><span class="citerefentry"><span class="refentrytitle">pkg_create</span>(1)</span></a> man page for a full list.
@@ -6745,7 +6745,7 @@ CHECK_BUILTIN.foo?= no
below!).</p>
<div class="sect1">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="rcs-id"></a>19.1.�RCS ID</h2></div></div></div>
+<a name="rcs-id"></a>19.1. RCS ID</h2></div></div></div>
<p>Be sure to add a RCS ID line as the first thing in any
<code class="filename">PLIST</code> file you write:</p>
<pre class="programlisting">
@@ -6757,15 +6757,15 @@ adding the RCS ID the space should be om
</div>
<div class="sect1">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="automatic-plist-generation"></a>19.2.�Semi-automatic <code class="filename">PLIST</code> generation</h2></div></div></div>
+<a name="automatic-plist-generation"></a>19.2. Semi-automatic <code class="filename">PLIST</code> generation</h2></div></div></div>
<p>You can use the <span class="command"><strong>make print-PLIST</strong></span> command
to output a PLIST that matches any new files since the package
- was extracted. See <a class="xref" href="#build.helpful-targets" title="13.17.�Other helpful targets">Section�13.17, “Other helpful targets”</a> for
+ was extracted. See <a class="xref" href="#build.helpful-targets" title="13.17. Other helpful targets">Section 13.17, “Other helpful targets”</a> for
more information on this target.</p>
</div>
<div class="sect1">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="print-PLIST"></a>19.3.�Tweaking output of <span class="command"><strong>make print-PLIST</strong></span>
+<a name="print-PLIST"></a>19.3. Tweaking output of <span class="command"><strong>make print-PLIST</strong></span>
</h2></div></div></div>
<p>The <code class="varname">PRINT_PLIST_AWK</code> variable takes a set
of AWK patterns and actions that are used to filter the output of
@@ -6785,7 +6785,7 @@ PRINT_PLIST_AWK+= /^libdata\/foo/
</div>
<div class="sect1">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="plist.misc"></a>19.4.�Variable substitution in PLIST</h2></div></div></div>
+<a name="plist.misc"></a>19.4. Variable substitution in PLIST</h2></div></div></div>
<p>A number of variables are substituted automatically in
PLISTs when a package is installed on a system. This includes the
following variables:</p>
@@ -6797,7 +6797,7 @@ PRINT_PLIST_AWK+= /^libdata\/foo/
pathnames where they install their files. To handle this
case, PLIST will be preprocessed before actually used, and
the symbol
- <span class="quote">“<span class="quote"><code class="varname">${MACHINE_ARCH}</code></span>”</span> will be
+ <span class="quote">“<span class="quote"><code class="varname">${MACHINE_ARCH}</code></span>”</span> will be
replaced by what <span class="command"><strong>uname -p</strong></span> gives. The
same is done if the string
<code class="varname">${MACHINE_GNU_ARCH}</code> is embedded in
@@ -6806,7 +6806,7 @@ PRINT_PLIST_AWK+= /^libdata\/foo/
<div class="note" style="margin-left: 0.5in; margin-right: 0.5in;">
<h3 class="title">Legacy note</h3>
<p>There used to be a symbol
- <span class="quote">“<span class="quote"><code class="varname">$ARCH</code></span>”</span> that
+ <span class="quote">“<span class="quote"><code class="varname">$ARCH</code></span>”</span> that
was replaced by the output of <span class="command"><strong>uname
-m</strong></span>, but that's no longer supported and has
been removed.</p>
@@ -6819,9 +6819,9 @@ PRINT_PLIST_AWK+= /^libdata\/foo/
<code class="filename">PLIST</code>:
</p>
<div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; ">
-<li class="listitem"><p><code class="varname">${OPSYS}</code> - output of <span class="quote">“<span class="quote"><span class="command"><strong>uname
-s</strong></span></span>”</span></p></li>
-<li class="listitem"><p><code class="varname">${LOWER_OPSYS}</code> - lowercase common name (eg. <span class="quote">“<span class="quote">solaris</span>”</span>)</p></li>
-<li class="listitem"><p><code class="varname">${OS_VERSION}</code> - <span class="quote">“<span class="quote"><span class="command"><strong>uname
-r</strong></span></span>”</span></p></li>
+<li class="listitem"><p><code class="varname">${OPSYS}</code> - output of <span class="quote">“<span class="quote"><span class="command"><strong>uname -s</strong></span></span>”</span></p></li>
+<li class="listitem"><p><code class="varname">${LOWER_OPSYS}</code> - lowercase common name (eg. <span class="quote">“<span class="quote">solaris</span>”</span>)</p></li>
+<li class="listitem"><p><code class="varname">${OS_VERSION}</code> - <span class="quote">“<span class="quote"><span class="command"><strong>uname -r</strong></span></span>”</span></p></li>
</ul></div>
</dd>
</dl></div>
@@ -6831,23 +6831,23 @@ well as searching the <code class="filen
<code class="varname">PLIST_SUBST</code> should help.</p>
<p>If you want to change other variables not listed above, you
can add variables and their expansions to this variable in the
- following way, similar to <code class="varname">MESSAGE_SUBST</code> (see <a class="xref" href="#components.optional" title="12.5.�Optional files">Section�12.5, “Optional
files”</a>):</p>
+ following way, similar to <code class="varname">MESSAGE_SUBST</code> (see <a class="xref" href="#components.optional" title="12.5. Optional files">Section 12.5, “Optional files”</a>):</p>
<pre class="programlisting">
PLIST_SUBST+= SOMEVAR="somevalue"
</pre>
-<p>This replaces all occurrences of <span class="quote">“<span class="quote">${SOMEVAR}</span>”</span>
+<p>This replaces all occurrences of <span class="quote">“<span class="quote">${SOMEVAR}</span>”</span>
in the <code class="filename">PLIST</code> with
- <span class="quote">“<span class="quote">somevalue</span>”</span>.</p>
+ <span class="quote">“<span class="quote">somevalue</span>”</span>.</p>
<p>The <code class="varname">PLIST_VARS</code> variable can be used to simplify
the common case of conditionally including some
<code class="filename">PLIST</code> entries. It can be done by adding
<code class="literal"><code class="varname">PLIST_VARS</code>+=foo</code> and
setting the corresponding <code class="varname">PLIST.foo</code> variable
to <code class="literal">yes</code> if the entry should be included.
- This will substitute <span class="quote">“<span class="quote"><code class="varname">${PLIST.foo}</code></span>”</span>
+ This will substitute <span class="quote">“<span class="quote"><code class="varname">${PLIST.foo}</code></span>”</span>
in the <code class="filename">PLIST</code> with either
- <span class="quote">“<span class="quote"><code class="literal">""</code></span>”</span> or
- <span class="quote">“<span class="quote"><code class="literal">"@comment "</code></span>”</span>.
+ <span class="quote">“<span class="quote"><code class="literal">""</code></span>”</span> or
+ <span class="quote">“<span class="quote"><code class="literal">"@comment "</code></span>”</span>.
For example, in <code class="filename">Makefile</code>:</p>
<pre class="programlisting">
PLIST_VARS+= foo
@@ -6870,11 +6870,11 @@ adding the RCS ID the space should be om
</div>
<div class="sect1">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="manpage-compression"></a>19.5.�Man page compression</h2></div></div></div>
+<a name="manpage-compression"></a>19.5. Man page compression</h2></div></div></div>
<p>Man pages should be installed in compressed form if
<code class="varname">MANZ</code> is set (in <code class="filename">bsd.own.mk</code>),
and uncompressed otherwise. To handle this in the
- <code class="filename">PLIST</code> file, the suffix <span class="quote">“<span class="quote">.gz</span>”</span> is
+ <code class="filename">PLIST</code> file, the suffix <span class="quote">“<span class="quote">.gz</span>”</span> is
appended/removed automatically for man pages according to
<code class="varname">MANZ</code> and <code class="varname">MANCOMPRESSED</code> being set
or not, see above for details. This modification of the
@@ -6883,7 +6883,7 @@ adding the RCS ID the space should be om
</div>
<div class="sect1">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="using-PLIST_SRC"></a>19.6.�Changing PLIST source with <code class="varname">PLIST_SRC</code>
+<a name="using-PLIST_SRC"></a>19.6. Changing PLIST source with <code class="varname">PLIST_SRC</code>
</h2></div></div></div>
<p>To use one or more files as source for the <code class="filename">PLIST</code> used
in generating the binary package, set the variable
@@ -6894,7 +6894,7 @@ adding the RCS ID the space should be om
</div>
<div class="sect1">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="platform-specific-plist"></a>19.7.�Platform-specific and differing PLISTs</h2></div></div></div>
+<a name="platform-specific-plist"></a>19.7. Platform-specific and differing PLISTs</h2></div></div></div>
<p>Some packages decide to install a different set of files based on
the operating system being used. These differences can be
automatically handled by using the following files:</p>
@@ -6908,7 +6908,7 @@ adding the RCS ID the space should be om
</div>
<div class="sect1">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="build-plist"></a>19.8.�Build-specific PLISTs</h2></div></div></div>
+<a name="build-plist"></a>19.8. Build-specific PLISTs</h2></div></div></div>
<p>Some packages decide to generate hard-to-guess file names
during installation that are hard to wire down.</p>
<p>In such cases, you can set the
@@ -6926,8 +6926,8 @@ GENERATE_PLIST+= ${ECHO} bin/${DI
</div>
<div class="sect1">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="faq.common-dirs"></a>19.9.�Sharing directories between packages</h2></div></div></div>
-<p>A <span class="quote">“<span class="quote">shared directory</span>”</span> is a directory where
+<a name="faq.common-dirs"></a>19.9. Sharing directories between packages</h2></div></div></div>
+<p>A <span class="quote">“<span class="quote">shared directory</span>”</span> is a directory where
multiple (and unrelated) packages install files. These
directories were problematic because you had to add special
tricks in the PLIST to conditionally remove them, or have some
@@ -6953,7 +6953,7 @@ GENERATE_PLIST+= ${ECHO} bin/${DI
</div>
<div class="chapter">
<div class="titlepage"><div><div><h2 class="title">
-<a name="pkginstall"></a>Chapter�20.�The pkginstall framework</h2></div></div></div>
+<a name="pkginstall"></a>Chapter 20. The pkginstall framework</h2></div></div></div>
<div class="toc">
<p><b>Table of Contents</b></p>
<dl class="toc">
@@ -7002,7 +7002,7 @@ described above is by means of the insta
automatically generated by pkginstall.</p>
<div class="sect1">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="files-and-dirs-outside-prefix"></a>20.1.�Files and directories outside the installation prefix</h2></div></div></div>
+<a name="files-and-dirs-outside-prefix"></a>20.1. Files and directories outside the installation prefix</h2></div></div></div>
<p>As you already know, the <code class="filename">PLIST</code> file holds a list
of files and directories that belong to a package. The names used in it
are relative to the installation prefix (<code class="filename">${PREFIX}</code>),
@@ -7035,7 +7035,7 @@ and directories based on variables set i
these variables.</p>
<div class="sect2">
<div class="titlepage"><div><div><h3 class="title">
-<a name="dirs-outside-prefix"></a>20.1.1.�Directory manipulation</h3></div></div></div>
+<a name="dirs-outside-prefix"></a>20.1.1. Directory manipulation</h3></div></div></div>
<p>The following variables can be set to request the creation of
directories anywhere in the file system:</p>
<div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; ">
@@ -7068,7 +7068,7 @@ MAKE_DIRS_PERMS+= ${VARBASE}/foo/p
</div>
<div class="sect2">
<div class="titlepage"><div><div><h3 class="title">
-<a name="files-outside-prefix"></a>20.1.2.�File manipulation</h3></div></div></div>
+<a name="files-outside-prefix"></a>20.1.2. File manipulation</h3></div></div></div>
<p>Creating non-empty files outside the installation prefix is tricky
because the <code class="filename">PLIST</code> forces all files to be inside it.
To overcome this problem, the only solution is to extract the file in a
@@ -7099,9 +7099,9 @@ REQD_FILES_PERMS+= ${PREFIX}/share/
<code class="varname">REQD_FILES_PERMS</code> respectively. The difference
is that these variables are specifically intended for handling
configuration files, for which additional conventions and
- constraints apply. See <a class="xref" href="#conf-files" title="20.2.�Configuration files">Section�20.2, “Configuration files”</a> for further
+ constraints apply. See <a class="xref" href="#conf-files" title="20.2. Configuration files">Section 20.2, “Configuration files”</a> for further
discussion. Note in particular that while handling of
- configuration files can be disabled by the user (see <a class="xref" href="#conf-files-disable" title="20.2.5.�Disabling handling of configuration files">Section�20.2.5, “Disabling
handling of configuration files”</a>), this setting does not affect
+ configuration files can be disabled by the user (see <a class="xref" href="#conf-files-disable" title="20.2.5. Disabling handling of configuration files">Section 20.2.5, “Disabling handling of
configuration files”</a>), this setting does not affect
<code class="varname">REQD_FILES</code> and
<code class="varname">REQD_FILES_PERMS</code>.</p></li>
</ul></div>
@@ -7111,7 +7111,7 @@ REQD_FILES_PERMS+= ${PREFIX}/share/
</div>
<div class="sect1">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="conf-files"></a>20.2.�Configuration files</h2></div></div></div>
+<a name="conf-files"></a>20.2. Configuration files</h2></div></div></div>
<p>There are two principles that govern the handling of
configuration files in pkgsrc: first, the user's configuration must
not be lost or overwritten by upgrades or reinstallations; and second,
@@ -7146,7 +7146,7 @@ and document other relevant knobs availa
infrastructure.</p>
<div class="sect2">
<div class="titlepage"><div><div><h3 class="title">
-<a name="conf-files-sysconfdir"></a>20.2.1.�How <code class="varname">PKG_SYSCONFDIR</code> is set</h3></div></div></div>
+<a name="conf-files-sysconfdir"></a>20.2.1. How <code class="varname">PKG_SYSCONFDIR</code> is set</h3></div></div></div>
<p>As said before, the <code class="varname">PKG_SYSCONFDIR</code> variable
specifies where configuration files shall be installed. Its contents are
set based upon the following variables:</p>
@@ -7195,14 +7195,14 @@ following:</p>
</ol></div>
<p>It is worth mentioning that <code class="filename">${PKG_SYSCONFDIR}</code> is
automatically added to <code class="filename">OWN_DIRS</code>. This causes it
-to be automatically created if needed. See <a class="xref" href="#dirs-outside-prefix" title="20.1.1.�Directory manipulation">Section�20.1.1, “Directory manipulation”</a> for further
details. This does not apply to
+to be automatically created if needed. See <a class="xref" href="#dirs-outside-prefix" title="20.1.1. Directory manipulation">Section 20.1.1, “Directory manipulation”</a> for further details. This
does not apply to
subdirectories of <code class="filename">${PKG_SYSCONFDIR}</code>; they must be manually
created with <code class="varname">OWN_DIRS</code> or
<code class="varname">MAKE_DIRS</code>.</p>
</div>
<div class="sect2">
<div class="titlepage"><div><div><h3 class="title">
-<a name="conf-files-configure"></a>20.2.2.�Telling the software where configuration files are</h3></div></div></div>
+<a name="conf-files-configure"></a>20.2.2. Telling the software where configuration files are</h3></div></div></div>
<p>Given that pkgsrc (and users!) expect configuration files to be in a
known place, you need to teach each package where to install its files. In
some cases you will have to patch the package Makefiles to achieve it. If
@@ -7220,7 +7220,7 @@ first glance.</p>
</div>
<div class="sect2">
<div class="titlepage"><div><div><h3 class="title">
-<a name="conf-files-patching"></a>20.2.3.�Patching installation</h3></div></div></div>
+<a name="conf-files-patching"></a>20.2.3. Patching installation</h3></div></div></div>
<p>As discussed above, <span class="strong"><strong>packages themselves must not
touch the contents of <code class="filename">${PKG_SYSCONFDIR}</code>
directly</strong></span>. Bad news is that many software installation scripts
@@ -7245,13 +7245,13 @@ outside it.</p>
</div>
<div class="sect2">
<div class="titlepage"><div><div><h3 class="title">
-<a name="conf-files-declare"></a>20.2.4.�Declaring configuration files</h3></div></div></div>
+<a name="conf-files-declare"></a>20.2.4. Declaring configuration files</h3></div></div></div>
<p>Once the required configuration files are in place (i.e., under the
examples hierarchy), the pkginstall framework can use them as reference copies
during the package installation to update what is in
<code class="filename">${PKG_SYSCONFDIR}</code>. To achieve this, the variables
<code class="varname">CONF_FILES</code> and <code class="varname">CONF_FILES_PERMS</code> are
-used. Check out <a class="xref" href="#files-outside-prefix" title="20.1.2.�File manipulation">Section�20.1.2, “File manipulation”</a> for further
+used. Check out <a class="xref" href="#files-outside-prefix" title="20.1.2. File manipulation">Section 20.1.2, “File manipulation”</a> for further
information about their syntax and their purpose. Here is an example,
taken from the <a href="https://cdn.NetBSD.org/pub/pkgsrc/current/pkgsrc/mail/mutt/index.html" target="_top"><code class="filename">mail/mutt</code></a> package:</p>
<pre class="programlisting">
@@ -7272,7 +7272,7 @@ INSTALL_MAKE_FLAGS= ${MAKE_FLAGS} sy
</div>
<div class="sect2">
<div class="titlepage"><div><div><h3 class="title">
-<a name="conf-files-disable"></a>20.2.5.�Disabling handling of configuration files</h3></div></div></div>
+<a name="conf-files-disable"></a>20.2.5. Disabling handling of configuration files</h3></div></div></div>
<p>The automatic copying of config files can be toggled by setting the
environment variable <code class="varname">PKG_CONFIG</code> prior to package
installation.</p>
@@ -7280,10 +7280,10 @@ installation.</p>
</div>
<div class="sect1">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="rcd-scripts"></a>20.3.�System startup scripts</h2></div></div></div>
+<a name="rcd-scripts"></a>20.3. System startup scripts</h2></div></div></div>
<p>System startup scripts are special files because they must be
installed in a place known by the underlying OS, usually outside the
-installation prefix. Therefore, the same rules described in <a class="xref" href="#files-and-dirs-outside-prefix" title="20.1.�Files and directories outside the installation prefix">Section�20.1,
“Files and directories outside the installation prefix”</a> apply, and the same solutions
+installation prefix. Therefore, the same rules described in <a class="xref" href="#files-and-dirs-outside-prefix" title="20.1. Files and directories outside the installation prefix">Section 20.1,
“Files and directories outside the installation prefix”</a> apply, and the same solutions
can be used. However, pkginstall provides a special mechanism to handle
these files.</p>
<p>In order to provide system startup scripts, the package has
@@ -7318,7 +7318,7 @@ script in an automated fashion:</p>
</ol></div>
<div class="sect2">
<div class="titlepage"><div><div><h3 class="title">
-<a name="rcd-scripts-disable"></a>20.3.1.�Disabling handling of system startup scripts</h3></div></div></div>
+<a name="rcd-scripts-disable"></a>20.3.1. Disabling handling of system startup scripts</h3></div></div></div>
<p>The automatic copying of config files can be toggled by setting the
environment variable <code class="varname">PKG_RCD_SCRIPTS</code> prior to package
installation. Note that the scripts will be always copied inside the
@@ -7328,7 +7328,7 @@ matter what the value of this variable i
</div>
<div class="sect1">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="users-and-groups"></a>20.4.�System users and groups</h2></div></div></div>
+<a name="users-and-groups"></a>20.4. System users and groups</h2></div></div></div>
<p>If a package needs to create special users and/or groups during
installation, it can do so by using the pkginstall framework.</p>
<p>Users can be created by adding entries to the
@@ -7366,7 +7366,7 @@ final installation scripts.</p>
</div>
<div class="sect1">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="shells"></a>20.5.�System shells</h2></div></div></div>
+<a name="shells"></a>20.5. System shells</h2></div></div></div>
<p>Packages that install system shells should register them in the shell
database, <code class="filename">/etc/shells</code>, to make things easier to the
administrator. This must be done from the installation scripts to keep
@@ -7381,7 +7381,7 @@ PKG_SHELL= ${PREFIX}/bin/zsh
</pre>
<div class="sect2">
<div class="titlepage"><div><div><h3 class="title">
-<a name="shells-disable"></a>20.5.1.�Disabling shell registration</h3></div></div></div>
+<a name="shells-disable"></a>20.5.1. Disabling shell registration</h3></div></div></div>
<p>The automatic registration of shell interpreters can be disabled by
the administrator by setting the <code class="filename">PKG_REGISTER_SHELLS</code>
environment variable to <code class="literal">NO</code>.</p>
@@ -7389,15 +7389,15 @@ environment variable to <code class="lit
</div>
<div class="sect1">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="fonts"></a>20.6.�Fonts</h2></div></div></div>
+<a name="fonts"></a>20.6. Fonts</h2></div></div></div>
<p>Packages that install X11 fonts should update the database files
that index the fonts within each fonts directory. This can easily be
accomplished within the pkginstall framework.</p>
<p>When a package installs X11 fonts, it must list the directories in
which 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">“<span class="quote">ttf</span>”</span>,
-<span class="quote">“<span class="quote">type1</span>”</span> or <span class="quote">“<span class="quote">x11</span>”</span>. This will add hooks to the
+where <em class="replaceable"><code>type</code></em> can be one of <span class="quote">“<span class="quote">ttf</span>”</span>,
+<span class="quote">“<span class="quote">type1</span>”</span> or <span class="quote">“<span class="quote">x11</span>”</span>. This will add hooks to the
installation scripts to run the appropriate commands to update the fonts
database files within each of those directories. For convenience, if the
directory path is relative, it is taken to be relative to the package's
@@ -7407,7 +7407,7 @@ FONTS_DIRS.ttf= ${PREFIX}/share/fonts/X1
</pre>
<div class="sect2">
<div class="titlepage"><div><div><h3 class="title">
-<a name="fonts-disable"></a>20.6.1.�Disabling automatic update of the fonts databases</h3></div></div></div>
+<a name="fonts-disable"></a>20.6.1. Disabling automatic update of the fonts databases</h3></div></div></div>
<p>The automatic update of fonts databases can be disabled by
the administrator by setting the <code class="filename">PKG_UPDATE_FONTS_DB</code>
environment variable to <code class="literal">NO</code>.</p>
@@ -7416,7 +7416,7 @@ environment variable to <code class="lit
</div>
<div class="chapter">
<div class="titlepage"><div><div><h2 class="title">
-<a name="fixes"></a>Chapter�21.�Making your package work</h2></div></div></div>
+<a name="fixes"></a>Chapter 21. Making your package work</h2></div></div></div>
<div class="toc">
<p><b>Table of Contents</b></p>
<dl class="toc">
@@ -7463,7 +7463,7 @@ environment variable to <code class="lit
<dt><span class="sect2"><a href="#fixes.build.cpp">21.5.1. Compiling C and C++ code conditionally</a></span></dt>
<dt><span class="sect2"><a href="#compiler-bugs">21.5.2. How to handle compiler bugs</a></span></dt>
<dt><span class="sect2"><a href="#fixes.build.header">21.5.3. No such file or directory</a></span></dt>
-<dt><span class="sect2"><a href="#undefined-reference">21.5.4. Undefined reference to <span class="quote">“<span class="quote">...</span>”</span></a></span></dt>
+<dt><span class="sect2"><a href="#undefined-reference">21.5.4. Undefined reference to <span class="quote">“<span class="quote">...</span>”</span></a></span></dt>
<dt><span class="sect2"><a href="#out-of-memory">21.5.5. Running out of memory</a></span></dt>
</dl></dd>
<dt><span class="sect1"><a href="#fixes.install">21.6. The <span class="emphasis"><em>install</em></span> phase</a></span></dt>
@@ -7493,7 +7493,7 @@ environment variable to <code class="lit
</div>
<div class="sect1">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="general-operation"></a>21.1.�General operation</h2></div></div></div>
+<a name="general-operation"></a>21.1. General operation</h2></div></div></div>
<p>One appealing feature of pkgsrc is that it runs on many
different platforms. As a result, it is important to ensure,
where possible, that packages in pkgsrc are portable. This
@@ -7501,7 +7501,7 @@ environment variable to <code class="lit
attention to while working on pkgsrc.</p>
<div class="sect2">
<div class="titlepage"><div><div><h3 class="title">
-<a name="pulling-vars-from-etc-mk.conf"></a>21.1.1.�How to pull in user-settable variables from <a class="link" href="#mk.conf"><code class="filename">mk.conf</code></a>
+<a name="pulling-vars-from-etc-mk.conf"></a>21.1.1. How to pull in user-settable variables from <a class="link" href="#mk.conf"><code class="filename">mk.conf</code></a>
</h3></div></div></div>
<p>The pkgsrc user can configure pkgsrc by overriding several
variables in the file pointed to by <code class="varname">MAKECONF</code>,
@@ -7529,7 +7529,7 @@ environment variable to <code class="lit
</div>
<div class="sect2">
<div class="titlepage"><div><div><h3 class="title">
-<a name="user-interaction"></a>21.1.2.�User interaction</h3></div></div></div>
+<a name="user-interaction"></a>21.1.2. User interaction</h3></div></div></div>
<p>Occasionally, packages require interaction from the user,
and this can be in a number of ways:</p>
<div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; ">
@@ -7554,7 +7554,7 @@ INTERACTIVE_STAGE= configure instal
</div>
<div class="sect2">
<div class="titlepage"><div><div><h3 class="title">
-<a name="handling-licenses"></a>21.1.3.�Handling licenses</h3></div></div></div>
+<a name="handling-licenses"></a>21.1.3. Handling licenses</h3></div></div></div>
<p>Authors of software can choose the licence under which software
can be copied. The Free Software Foundation has declared some
licenses "Free", and the Open Source Initiative has a definition of
@@ -7626,7 +7626,7 @@ ACCEPTABLE_LICENSES+=xv-license
tag.</p>
<div class="sect3">
<div class="titlepage"><div><div><h4 class="title">
-<a name="new-license"></a>21.1.3.1.�Adding a package with a new license</h4></div></div></div>
+<a name="new-license"></a>21.1.3.1. Adding a package with a new license</h4></div></div></div>
<p>When adding a package with a new license, the following steps
are required:</p>
<div class="orderedlist"><ol class="orderedlist" type="1">
@@ -7652,7 +7652,7 @@ ACCEPTABLE_LICENSES+=xv-license
</div>
<div class="sect3">
<div class="titlepage"><div><div><h4 class="title">
-<a name="change-license"></a>21.1.3.2.�Change to the license</h4></div></div></div>
+<a name="change-license"></a>21.1.3.2. Change to the license</h4></div></div></div>
<p>When the license changes (in a way other than formatting),
make sure that the new license has a different name (e.g.,
append the version number if it exists, or the date). Just
@@ -7666,7 +7666,7 @@ ACCEPTABLE_LICENSES+=xv-license
</div>
<div class="sect2">
<div class="titlepage"><div><div><h3 class="title">
-<a name="restricted-packages"></a>21.1.4.�Restricted packages</h3></div></div></div>
+<a name="restricted-packages"></a>21.1.4. Restricted packages</h3></div></div></div>
<p>Some licenses restrict how software may be re-distributed.
By declaring the restrictions, package tools can
automatically refrain from e.g. placing binary packages on FTP
@@ -7735,7 +7735,7 @@ ACCEPTABLE_LICENSES+=xv-license
</div>
<div class="sect2">
<div class="titlepage"><div><div><h3 class="title">
-<a name="dependencies"></a>21.1.5.�Handling dependencies</h3></div></div></div>
+<a name="dependencies"></a>21.1.5. Handling dependencies</h3></div></div></div>
<p>Your package may depend on some other package being present,
and there are various ways of expressing this dependency.
pkgsrc supports the <code class="varname">DEPENDS</code>,
@@ -7745,14 +7745,14 @@ ACCEPTABLE_LICENSES+=xv-license
<code class="varname">USE_TOOLS</code> definition, as well as dependencies
via <code class="filename">buildlink3.mk</code>, which is the preferred way
to handle dependencies, and which uses the variables named above.
- See <a class="xref" href="#buildlink" title="Chapter�18.�Buildlink methodology">Chapter�18, <i>Buildlink methodology</i></a> for more information.</p>
+ See <a class="xref" href="#buildlink" title="Chapter 18. Buildlink methodology">Chapter 18, <i>Buildlink methodology</i></a> for more information.</p>
<p>The basic difference is that the <code class="varname">DEPENDS</code>
definition registers that pre-requisite in the binary package so it
will be pulled in when the binary package is later installed, whilst
the <code class="varname">BUILD_DEPENDS</code>, <code class="varname">TOOL_DEPENDS</code>,
and <code class="varname">TEST_DEPENDS</code> definitions do not, marking a
dependency that is only needed for building or testing the resulting
- package. See also <a class="xref" href="#creating" title="Chapter�14.�Creating a new pkgsrc package from scratch">Chapter�14, <i>Creating a new pkgsrc package from scratch</i></a> for more
information.</p>
+ package. See also <a class="xref" href="#creating" title="Chapter 14. Creating a new pkgsrc package from scratch">Chapter 14, <i>Creating a new pkgsrc package from scratch</i></a> for more
information.</p>
<p>This means that if you only need a package present whilst
you are building or testing, it should be noted as a
<code class="varname">TOOL_DEPENDS</code>,
@@ -7770,7 +7770,7 @@ ACCEPTABLE_LICENSES+=xv-license
<pre class="programlisting">
<pre-req-package-name>:../../<category>/<pre-req-package>
</pre>
-<p>Please note that the <span class="quote">“<span class="quote">pre-req-package-name</span>”</span>
+<p>Please note that the <span class="quote">“<span class="quote">pre-req-package-name</span>”</span>
may include any of the wildcard version numbers recognized by
<a class="citerefentry" href="//man.NetBSD.org/NetBSD-10.1/pkg_info.1"><span class="citerefentry"><span class="refentrytitle">pkg_info</span>(1)</span></a>.</p>
<div class="orderedlist"><ol class="orderedlist" type="1">
@@ -7823,7 +7823,7 @@ DEPENDS+= tex-latex-bin-[0-9]*:..
</li>
<li class="listitem"><p>If your package includes a test suite that has extra
dependencies only required for this purpose (frequently this
- can be run as a <span class="quote">“<span class="quote">make test</span>”</span> target), use the
+ can be run as a <span class="quote">“<span class="quote">make test</span>”</span> target), use the
<code class="varname">TEST_DEPENDS</code> variable.</p></li>
<li class="listitem">
<p>You can use wildcards in package dependencies. Note that
@@ -7831,10 +7831,10 @@ DEPENDS+= tex-latex-bin-[0-9]*:..
packages. The dependency is checked when installing the binary
package and any package which matches the pattern will be
used. Wildcard dependencies should be used with care.</p>
-<p>The <span class="quote">“<span class="quote">-[0-9]*</span>”</span> should be used instead of
- <span class="quote">“<span class="quote">-*</span>”</span> to avoid potentially ambiguous matches
- such as <span class="quote">“<span class="quote">tk-postgresql</span>”</span> matching a
- <span class="quote">“<span class="quote">tk-*</span>”</span> <code class="varname">DEPENDS</code>.</p>
+<p>The <span class="quote">“<span class="quote">-[0-9]*</span>”</span> should be used instead of
+ <span class="quote">“<span class="quote">-*</span>”</span> to avoid potentially ambiguous matches
+ such as <span class="quote">“<span class="quote">tk-postgresql</span>”</span> matching a
+ <span class="quote">“<span class="quote">tk-*</span>”</span> <code class="varname">DEPENDS</code>.</p>
<p>Wildcards can also be used to specify that a package
will only build against a certain minimum version of a
pre-requisite:</p>
@@ -7855,7 +7855,7 @@ BUILDLINK_API_DEPENDS.jpeg+= jpeg>
.include "../../graphics/jpeg/buildlink3.mk"
</pre>
<p>For security fixes, please update the package
- vulnerabilities file. See <a class="xref" href="#security-handling" title="21.1.9.�Handling packages with security problems">Section�21.1.9, “Handling packages with security
problems”</a> for more
+ vulnerabilities file. See <a class="xref" href="#security-handling" title="21.1.9. Handling packages with security problems">Section 21.1.9, “Handling packages with security problems”</a> for
more
information.</p>
</li>
</ol></div>
@@ -7868,7 +7868,7 @@ BUILDLINK_API_DEPENDS.jpeg+= jpeg>
</div>
<div class="sect2">
<div class="titlepage"><div><div><h3 class="title">
-<a name="conflicts"></a>21.1.6.�Handling conflicts with other packages</h3></div></div></div>
+<a name="conflicts"></a>21.1.6. Handling conflicts with other packages</h3></div></div></div>
<p>Your package may conflict with other packages users might
already have installed on their system, e.g., if your package
installs the same set of files as another package in the pkgsrc
@@ -7901,7 +7901,7 @@ CONFLICTS= libXaw3d-[0-9]*
</div>
<div class="sect2">
<div class="titlepage"><div><div><h3 class="title">
-<a name="not-building-packages"></a>21.1.7.�Packages that cannot or should not be built</h3></div></div></div>
+<a name="not-building-packages"></a>21.1.7. Packages that cannot or should not be built</h3></div></div></div>
<p>There are several reasons why a package might be
instructed to not build under certain circumstances. If the
package builds and runs on most platforms, the exceptions
@@ -7928,7 +7928,7 @@ CONFLICTS= libXaw3d-[0-9]*
backwards compatible with other versions of the OS, and should be
uploaded to a version specific directory on the FTP server. Mark
these packages by setting <code class="varname">OSVERSION_SPECIFIC</code> to
- <span class="quote">“<span class="quote">yes</span>”</span>. This variable is not currently used by any of
+ <span class="quote">“<span class="quote">yes</span>”</span>. This variable is not currently used by any of
the package system internals, but may be used in the
future.</p>
<p>If the package should be skipped (for example, because it
@@ -7940,18 +7940,18 @@ CONFLICTS= libXaw3d-[0-9]*
</div>
<div class="sect2">
<div class="titlepage"><div><div><h3 class="title">
-<a name="undeletable-packages"></a>21.1.8.�Packages which should not be deleted, once installed</h3></div></div></div>
+<a name="undeletable-packages"></a>21.1.8. Packages which should not be deleted, once installed</h3></div></div></div>
<p>To ensure that a package may not be deleted, once it has been
installed, the <code class="varname">PKG_PRESERVE</code> definition should
be set in the package Makefile. This will be carried into any
binary package that is made from this pkgsrc entry. A
- <span class="quote">“<span class="quote">preserved</span>”</span> package will
+ <span class="quote">“<span class="quote">preserved</span>”</span> package will
not be deleted using <a class="citerefentry" href="//man.NetBSD.org/NetBSD-10.1/pkg_delete.1"><span class="citerefentry"><span class="refentrytitle">pkg_delete</span>(1)</span></a> unless the
- <span class="quote">“<span class="quote">-f</span>”</span> option is used.</p>
+ <span class="quote">“<span class="quote">-f</span>”</span> option is used.</p>
</div>
<div class="sect2">
<div class="titlepage"><div><div><h3 class="title">
-<a name="security-handling"></a>21.1.9.�Handling packages with security problems</h3></div></div></div>
+<a name="security-handling"></a>21.1.9. Handling packages with security problems</h3></div></div></div>
<p>When a vulnerability is found, this should be noted in
<code class="filename">pkgsrc/doc/pkg-vulnerabilities</code>.
Entries in that file consist of three parts:</p>
@@ -7965,15 +7965,15 @@ CONFLICTS= libXaw3d-[0-9]*
problems due unrelated <code class="varname">PKGREVISION</code> bumps not
related to security fixes. Lower bounds can be added too, using
'>' or '>='. For example,
- <span class="quote">“<span class="quote"><code class="literal">foo>=1<1.2</code></span>”</span> would mark
+ <span class="quote">“<span class="quote"><code class="literal">foo>=1<1.2</code></span>”</span> would mark
versions 1.0 (included) to 1.2 (excluded) of
- <span class="quote">“<span class="quote"><code class="literal">foo</code></span>”</span> as affected by the security
+ <span class="quote">“<span class="quote"><code class="literal">foo</code></span>”</span> as affected by the security
issue.</p>
<p>Entries should always be added at the bottom of the file.</p>
<p>When fixing packages, please modify the upper bound of the
corresponding entry. To continue the previous example, if a fix
was backported to version 1.1nb2, change the previous pattern to
- <span class="quote">“<span class="quote"><code class="literal">foo>=1<1.1nb2</code></span>”</span>.</p>
+ <span class="quote">“<span class="quote"><code class="literal">foo>=1<1.1nb2</code></span>”</span>.</p>
<p>To locally test a package version pattern against a
<code class="varname">PKGNAME</code> you can use the <span class="command"><strong>pkg_admin
pmatch</strong></span> command.</p>
@@ -7996,21 +7996,21 @@ CONFLICTS= libXaw3d-[0-9]*
</div>
<div class="sect2">
<div class="titlepage"><div><div><h3 class="title">
-<a name="bumping-pkgrevision"></a>21.1.10.�How to handle incrementing versions when fixing an existing package</h3></div></div></div>
+<a name="bumping-pkgrevision"></a>21.1.10. How to handle incrementing versions when fixing an existing package</h3></div></div></div>
<p>When making fixes to an existing package it can be useful
to change the version number in <code class="varname">PKGNAME</code>. To
avoid conflicting with future versions by the original author, a
- <span class="quote">“<span class="quote">nb1</span>”</span>, <span class="quote">“<span class="quote">nb2</span>”</span>, ... suffix can be used
+ <span class="quote">“<span class="quote">nb1</span>”</span>, <span class="quote">“<span class="quote">nb2</span>”</span>, ... suffix can be used
on package versions by setting <code class="varname">PKGREVISION=1</code>
- (2, ...). The <span class="quote">“<span class="quote">nb</span>”</span> is treated like a
- <span class="quote">“<span class="quote">.</span>”</span> by the package tools. e.g.</p>
+ (2, ...). The <span class="quote">“<span class="quote">nb</span>”</span> is treated like a
+ <span class="quote">“<span class="quote">.</span>”</span> by the package tools. e.g.</p>
<pre class="programlisting">
DISTNAME= foo-17.42
PKGREVISION= 9
</pre>
<p>will result in a <code class="varname">PKGNAME</code> of
- <span class="quote">“<span class="quote">foo-17.42nb9</span>”</span>. If you want to use the original
- value of <code class="varname">PKGNAME</code> without the <span class="quote">“<span class="quote">nbX</span>”</span>
+ <span class="quote">“<span class="quote">foo-17.42nb9</span>”</span>. If you want to use the original
+ value of <code class="varname">PKGNAME</code> without the <span class="quote">“<span class="quote">nbX</span>”</span>
suffix, e.g. for setting <code class="varname">DIST_SUBDIR</code>, use
<code class="varname">PKGNAME_NOREV</code>.</p>
<p>When a new release of the package is released, the
@@ -8057,7 +8057,7 @@ DISTNAME= foo-17.43
</div>
<div class="sect2">
<div class="titlepage"><div><div><h3 class="title">
-<a name="fixes.subst"></a>21.1.11.�Substituting variable text in the package files (the SUBST framework)</h3></div></div></div>
+<a name="fixes.subst"></a>21.1.11. Substituting variable text in the package files (the SUBST framework)</h3></div></div></div>
<p>When you want to replace the same text in multiple files, or
multiple times in the same file, it is cumbersome to maintain a patch
file for this. This is where the SUBST framework steps in. It provides an
@@ -8111,7 +8111,7 @@ remain after this, have a look at
<code class="filename">mk/subst.mk</code>.</p>
<div class="sect3">
<div class="titlepage"><div><div><h4 class="title">
-<a name="fixes.subst.when"></a>21.1.11.1.�Choosing the time where the substitutions happen</h4></div></div></div>
+<a name="fixes.subst.when"></a>21.1.11.1. Choosing the time where the substitutions happen</h4></div></div></div>
<p>The <code class="varname">SUBST_STAGE.*</code> is one of
{pre,do,post}-{extract,patch,configure,build,test,install}. Of these,
<code class="literal">pre-configure</code> is used most often, by far. The most
@@ -8186,7 +8186,7 @@ substitutions in this stage.</p></dd>
</div>
<div class="sect3">
<div class="titlepage"><div><div><h4 class="title">
-<a name="fixes.subst.where"></a>21.1.11.2.�Choosing the files where the substitutions happen</h4></div></div></div>
+<a name="fixes.subst.where"></a>21.1.11.2. Choosing the files where the substitutions happen</h4></div></div></div>
<p>The <code class="varname">SUBST_FILES.*</code> variable contains a list of
filename patterns. These patterns are relative to
<code class="varname">WRKSRC</code> since that is where most substitutions happen.
@@ -8227,7 +8227,7 @@ command to generate the list of filename
</div>
<div class="sect3">
<div class="titlepage"><div><div><h4 class="title">
-<a name="fixes.subst.what"></a>21.1.11.3.�Choosing what to substitute</h4></div></div></div>
+<a name="fixes.subst.what"></a>21.1.11.3. Choosing what to substitute</h4></div></div></div>
<p>In most cases, the substitutions are given using one or more
<a class="citerefentry" href="//man.NetBSD.org/NetBSD-10.1/sed.1"><span class="citerefentry"><span class="refentrytitle">sed</span>(1)</span></a> commands, like this:</p>
<pre class="programlisting">
@@ -8267,7 +8267,7 @@ converted to UNIX-style line endings.</p
</div>
<div class="sect3">
<div class="titlepage"><div><div><h4 class="title">
-<a name="fixes.subst.other"></a>21.1.11.4.�Other SUBST variables</h4></div></div></div>
+<a name="fixes.subst.other"></a>21.1.11.4. Other SUBST variables</h4></div></div></div>
<p>When a SUBST block is applied during a package build, a message is
logged. The default message is fine for most purposes but can be
overridden by setting <code class="literal">SUBST_MESSAGE.*</code> to an individual
@@ -8277,10 +8277,10 @@ message.</p>
</div>
<div class="sect1">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="fixes.fetch"></a>21.2.�The <span class="emphasis"><em>fetch</em></span> phase</h2></div></div></div>
+<a name="fixes.fetch"></a>21.2. The <span class="emphasis"><em>fetch</em></span> phase</h2></div></div></div>
<div class="sect2">
<div class="titlepage"><div><div><h3 class="title">
-<a name="no-plain-download"></a>21.2.1.�Packages whose distfiles aren't available for plain downloading</h3></div></div></div>
+<a name="no-plain-download"></a>21.2.1. Packages whose distfiles aren't available for plain downloading</h3></div></div></div>
<p>If you need to download from a dynamic URL you can set
<code class="varname">DYNAMIC_MASTER_SITES</code> and a <span class="command"><strong>make
fetch</strong></span> will call <code class="filename">files/getsite.sh</code>
@@ -8301,7 +8301,7 @@ FETCH_MESSAGE+= "manually from "${MASTER
</div>
<div class="sect2">
<div class="titlepage"><div><div><h3 class="title">
-<a name="modified-distfiles-same-name"></a>21.2.2.�How to handle modified distfiles with the 'old' name</h3></div></div></div>
+<a name="modified-distfiles-same-name"></a>21.2.2. How to handle modified distfiles with the 'old' name</h3></div></div></div>
<p>Sometimes authors of a software package make some
modifications after the software was released, and they put up a
new distfile without changing the package's version number. If a
@@ -8318,7 +8318,7 @@ FETCH_MESSAGE+= "manually from "${MASTER
python or ruby packages, where <code class="varname">PKGNAME</code> includes
a variable prefix). All <code class="varname">DISTFILES</code> and
<code class="varname">PATCHFILES</code> for this package will be put in that
- subdirectory of the local distfiles directory. (See <a class="xref" href="#bumping-pkgrevision" title="21.1.10.�How to handle incrementing versions when fixing an existing
package">Section�21.1.10, “How to handle incrementing versions when fixing an existing package”</a> for more details.) In case this
+ subdirectory of the local distfiles directory. (See <a class="xref" href="#bumping-pkgrevision" title="21.1.10. How to handle incrementing versions when fixing an existing package">Section
21.1.10, “How to handle incrementing versions when fixing an existing package”</a> for more details.) In case this
happens more often, <code class="varname">PKGNAME</code> can be used (thus
including the <code class="filename">nbX</code> suffix) or a date stamp can
be appended, like
@@ -8340,14 +8340,14 @@ FETCH_MESSAGE+= "manually from "${MASTER
</div>
<div class="sect2">
<div class="titlepage"><div><div><h3 class="title">
-<a name="build.fetch.github"></a>21.2.3.�Packages hosted on github.com</h3></div></div></div>
+<a name="build.fetch.github"></a>21.2.3. Packages hosted on github.com</h3></div></div></div>
<p>Helper methods exist for packages hosted on github.com which
will often have distfile names that clash with other packages, for
example <code class="filename">1.0.tar.gz</code>. Use one of the three recipes
from below:</p>
<div class="sect3">
<div class="titlepage"><div><div><h4 class="title">
-<a name="build.fetch.github.tag"></a>21.2.3.1.�Fetch based on a tagged release</h4></div></div></div>
+<a name="build.fetch.github.tag"></a>21.2.3.1. Fetch based on a tagged release</h4></div></div></div>
<p>If your distfile URL looks similar to
<code class="literal">https://github.com/username/example/archive/v1.0.zip</code>,
then you are packaging a tagged release.</p>
@@ -8364,7 +8364,7 @@ EXTRACT_SUFX= .zip
</div>
<div class="sect3">
<div class="titlepage"><div><div><h4 class="title">
-<a name="build.fetch.github.commit.prerelease"></a>21.2.3.2.�Fetch based on a specific commit before the first release</h4></div></div></div>
+<a name="build.fetch.github.commit.prerelease"></a>21.2.3.2. Fetch based on a specific commit before the first release</h4></div></div></div>
<p>If your distfile looks similar to
<code class="literal">https://github.com/username/example/archive/988881adc9fc3655077dc2d4d757d480b5ea0e11</code> and is from a commit before the first
release, then set the package version to 0.0.0.N, where N is the number
@@ -8381,7 +8381,7 @@ GITHUB_TAG= 988881adc9fc3655077dc2d4
</div>
<div class="sect3">
<div class="titlepage"><div><div><h4 class="title">
-<a name="build.fetch.github.commit.postrelease"></a>21.2.3.3.�Fetch based on a specific commit after a release</h4></div></div></div>
+<a name="build.fetch.github.commit.postrelease"></a>21.2.3.3. Fetch based on a specific commit after a release</h4></div></div></div>
<p>If your distfile looks similar to
<code class="literal">https://github.com/username/example/archive/988881adc9fc3655077dc2d4d757d480b5ea0e11</code> and is from a commit after a release,
then include the last release version and the commit count since that
@@ -8404,7 +8404,7 @@ GITHUB_TAG= 988881adc9fc3655077dc2d4
</div>
<div class="sect3">
<div class="titlepage"><div><div><h4 class="title">
-<a name="build.fetch.github.release"></a>21.2.3.4.�Fetch based on release</h4></div></div></div>
+<a name="build.fetch.github.release"></a>21.2.3.4. Fetch based on release</h4></div></div></div>
<p>If your distfile URL looks similar to
<code class="literal">https://github.com/username/example/releases/download/rel-1.6/offensive-1.6.zip</code>,
then you are packaging a release.</p>
@@ -8421,10 +8421,10 @@ EXTRACT_SUFX= .zip
</div>
<div class="sect1">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="fixes.configure"></a>21.3.�The <span class="emphasis"><em>configure</em></span> phase</h2></div></div></div>
+<a name="fixes.configure"></a>21.3. The <span class="emphasis"><em>configure</em></span> phase</h2></div></div></div>
<div class="sect2">
<div class="titlepage"><div><div><h3 class="title">
-<a name="fixes.libtool"></a>21.3.1.�Shared libraries - libtool</h3></div></div></div>
+<a name="fixes.libtool"></a>21.3.1. Shared libraries - libtool</h3></div></div></div>
<p>pkgsrc supports many different machines, with different
object formats like a.out and ELF, and varying abilities to do
shared library and dynamic loading at all. To accompany this,
@@ -8433,7 +8433,7 @@ EXTRACT_SUFX= .zip
pretty annoying especially if you don't have all the machines
at your hand to test things. The
<a href="https://cdn.NetBSD.org/pub/pkgsrc/current/pkgsrc/devel/libtool/index.html" target="_top"><code class="filename">devel/libtool</code></a> pkg
- can help here, as it just <span class="quote">“<span class="quote">knows</span>”</span> how to build
+ can help here, as it just <span class="quote">“<span class="quote">knows</span>”</span> how to build
both static and dynamic libraries from a set of source files,
thus being platform-independent.</p>
<p>Here's how to use libtool in a package in seven simple
@@ -8441,16 +8441,16 @@ EXTRACT_SUFX= .zip
<div class="orderedlist"><ol class="orderedlist" type="1">
<li class="listitem"><p>Add <code class="varname">USE_LIBTOOL=yes</code> to the package
Makefile.</p></li>
-<li class="listitem"><p>For library objects, use <span class="quote">“<span class="quote">${LIBTOOL} --mode=compile
- ${CC}</span>”</span> in place of <span class="quote">“<span class="quote">${CC}</span>”</span>. You could even
+<li class="listitem"><p>For library objects, use <span class="quote">“<span class="quote">${LIBTOOL} --mode=compile
+ ${CC}</span>”</span> in place of <span class="quote">“<span class="quote">${CC}</span>”</span>. You could even
add it to the definition of <code class="varname">CC</code>, if only
libraries are being built in a given Makefile. This one command
will build both PIC and non-PIC library objects, so you need not
have separate shared and non-shared library rules.</p></li>
<li class="listitem">
<p>For the linking of the library, remove any
- <span class="quote">“<span class="quote">ar</span>”</span>, <span class="quote">“<span class="quote">ranlib</span>”</span>, and <span class="quote">“<span
class="quote">ld
- -Bshareable</span>”</span> commands, and instead use:</p>
+ <span class="quote">“<span class="quote">ar</span>”</span>, <span class="quote">“<span class="quote">ranlib</span>”</span>, and <span class="quote">“<span class="quote">ld
+ -Bshareable</span>”</span> commands, and instead use:</p>
<pre class="programlisting">
${LIBTOOL} --mode=link \
${CC} -o ${.TARGET:.a=.la} \
@@ -8466,7 +8466,7 @@ ${LIBTOOL} --mode=link \
<code class="filename">.a</code>,
<code class="filename">.so.major.minor</code>, and ELF symlinks (if
necessary) in the build directory. Be sure to include
- <span class="quote">“<span class="quote">-version-info</span>”</span>, especially when major and
+ <span class="quote">“<span class="quote">-version-info</span>”</span>, especially when major and
minor are zero, as libtool will otherwise strip off the
shared library version.</p>
<p>From the libtool manual:</p>
@@ -8488,15 +8488,15 @@ AGE' to `CURRENT'.
If two libraries have identical CURRENT and AGE numbers, then the
dynamic linker chooses the library with the greater REVISION number.
</pre>
-<p>The <span class="quote">“<span class="quote">-release</span>”</span> option will produce
+<p>The <span class="quote">“<span class="quote">-release</span>”</span> option will produce
different results for a.out and ELF (excluding symlinks)
in only one case. An ELF library of the form
- <span class="quote">“<span class="quote">libfoo-release.so.<span class="emphasis"><em>x</em></span>.<span class="emphasis"><em>y</em></span></span>”</span>
+ <span class="quote">“<span class="quote">libfoo-release.so.<span class="emphasis"><em>x</em></span>.<span class="emphasis"><em>y</em></span></span>”</span>
will have a symlink of
- <span class="quote">“<span class="quote">libfoo.so.<span class="emphasis"><em>x</em></span>.<span class="emphasis"><em>y</em></span></span>”</span>
+ <span class="quote">“<span class="quote">libfoo.so.<span class="emphasis"><em>x</em></span>.<span class="emphasis"><em>y</em></span></span>”</span>
on an a.out platform. This is handled
automatically.</p>
-<p>The <span class="quote">“<span class="quote">-rpath argument</span>”</span> is the install
+<p>The <span class="quote">“<span class="quote">-rpath argument</span>”</span> is the install
directory of the library being built.</p>
<p>In the <code class="filename">PLIST</code>, include only the
<code class="filename">.la</code> file, the other files will be
@@ -8505,8 +8505,8 @@ dynamic linker chooses the library with
<li class="listitem">
<p>When linking shared object (<code class="filename">.so</code>)
files, i.e. files that are loaded via <a class="citerefentry" href="//man.NetBSD.org/NetBSD-10.1/dlopen.3"><span class="citerefentry"><span class="refentrytitle">dlopen</span>(3)</span></a>,
NOT
- shared libraries, use <span class="quote">“<span class="quote">-module
- -avoid-version</span>”</span> to prevent them getting version
+ shared libraries, use <span class="quote">“<span class="quote">-module
+ -avoid-version</span>”</span> to prevent them getting version
tacked on.</p>
<p>The <code class="filename">PLIST</code> file gets the
<code class="filename">foo.so</code> entry.</p>
@@ -8514,11 +8514,11 @@ dynamic linker chooses the library with
<li class="listitem">
<p>When linking programs that depend on these libraries
<span class="emphasis"><em>before</em></span> they are installed, preface
- the <a class="citerefentry" href="//man.NetBSD.org/NetBSD-10.1/cc.1"><span class="citerefentry"><span class="refentrytitle">cc</span>(1)</span></a> or <a class="citerefentry"
href="//man.NetBSD.org/NetBSD-10.1/ld.1"><span class="citerefentry"><span class="refentrytitle">ld</span>(1)</span></a> line with <span class="quote">“<span class="quote">${LIBTOOL}
- --mode=link</span>”</span>, and it will find the correct
+ the <a class="citerefentry" href="//man.NetBSD.org/NetBSD-10.1/cc.1"><span class="citerefentry"><span class="refentrytitle">cc</span>(1)</span></a> or <a class="citerefentry"
href="//man.NetBSD.org/NetBSD-10.1/ld.1"><span class="citerefentry"><span class="refentrytitle">ld</span>(1)</span></a> line with <span class="quote">“<span class="quote">${LIBTOOL}
+ --mode=link</span>”</span>, and it will find the correct
libraries (static or shared), but please be aware that
libtool will not allow you to specify a relative path in
- -L (such as <span class="quote">“<span class="quote">-L../somelib</span>”</span>), because it
+ -L (such as <span class="quote">“<span class="quote">-L../somelib</span>”</span>), because it
expects you to change that argument to be the
<code class="filename">.la</code> file. e.g.</p>
<pre class="programlisting">
@@ -8532,8 +8532,8 @@ ${LIBTOOL} --mode=link ${CC} -o <em clas
</li>
<li class="listitem">
<p>When installing libraries, preface the <a class="citerefentry" href="//man.NetBSD.org/NetBSD-10.1/install.1"><span class="citerefentry"><span class="refentrytitle">install</span>(1)</span></a>
- or <a class="citerefentry" href="//man.NetBSD.org/NetBSD-10.1/cp.1"><span class="citerefentry"><span class="refentrytitle">cp</span>(1)</span></a> command with <span
class="quote">“<span class="quote">${LIBTOOL}
- --mode=install</span>”</span>, and change the library name to
+ or <a class="citerefentry" href="//man.NetBSD.org/NetBSD-10.1/cp.1"><span class="citerefentry"><span class="refentrytitle">cp</span>(1)</span></a> command with <span class="quote">“<span
class="quote">${LIBTOOL}
+ --mode=install</span>”</span>, and change the library name to
<code class="filename">.la</code>. e.g.</p>
<pre class="programlisting">
${LIBTOOL} --mode=install ${BSD_INSTALL_LIB} ${SOMELIB:.a=.la} ${PREFIX}/lib
@@ -8549,7 +8549,7 @@ ${LIBTOOL} --mode=install ${BSD_INSTALL_
</div>
<div class="sect2">
<div class="titlepage"><div><div><h3 class="title">
-<a name="using-libtool"></a>21.3.2.�Using libtool on GNU packages that already support libtool</h3></div></div></div>
+<a name="using-libtool"></a>21.3.2. Using libtool on GNU packages that already support libtool</h3></div></div></div>
<p>Add <code class="varname">USE_LIBTOOL=yes</code> to the
package Makefile. This will override the package's own libtool
in most cases. For older libtool using packages, libtool is
@@ -8558,8 +8558,8 @@ ${LIBTOOL} --mode=install ${BSD_INSTALL_
configure; find work*/ -name libtool</strong></span>.</p>
<p><code class="varname">LIBTOOL_OVERRIDE</code> specifies which libtool
scripts, relative to <code class="varname">WRKSRC</code>, to override. By
- default, it is set to <span class="quote">“<span class="quote">libtool */libtool
- */*/libtool</span>”</span>. If this does not match the location of the
+ default, it is set to <span class="quote">“<span class="quote">libtool */libtool
+ */*/libtool</span>”</span>. If this does not match the location of the
package's libtool script(s), set it as appropriate.</p>
<p>If you do not need <code class="filename">*.a</code> static
libraries built and installed, then use
@@ -8590,7 +8590,7 @@ ${LIBTOOL} --mode=install ${BSD_INSTALL_
</div>
<div class="sect2">
<div class="titlepage"><div><div><h3 class="title">
-<a name="autoconf-automake"></a>21.3.3.�GNU Autoconf/Automake</h3></div></div></div>
+<a name="autoconf-automake"></a>21.3.3. GNU Autoconf/Automake</h3></div></div></div>
<p>If a package needs GNU autoconf or automake to be executed
to regenerate the
<code class="filename">configure</code>
@@ -8624,7 +8624,7 @@ pre-configure:
</div>
<div class="sect2">
<div class="titlepage"><div><div><h3 class="title">
-<a name="meson"></a>21.3.4.�Meson / ninja</h3></div></div></div>
+<a name="meson"></a>21.3.4. Meson / ninja</h3></div></div></div>
<p>Packages using Meson to configure need to include:
</p>
@@ -8652,21 +8652,21 @@ MESON_ARGS+= -Dx11=false
</div>
<div class="sect2">
<div class="titlepage"><div><div><h3 class="title">
-<a name="endian"></a>21.3.5.�Determining the endianness</h3></div></div></div>
+<a name="endian"></a>21.3.5. Determining the endianness</h3></div></div></div>
<p>To determine the endianness of the target platform,
have a look at <code class="filename">mk/endian.mk</code>.</p>
</div>
</div>
<div class="sect1">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="programming-languages"></a>21.4.�Programming languages</h2></div></div></div>
+<a name="programming-languages"></a>21.4. Programming languages</h2></div></div></div>
<div class="sect2">
<div class="titlepage"><div><div><h3 class="title">
-<a name="basic-programming-languages"></a>21.4.1.�C, C++, and Fortran</h3></div></div></div>
+<a name="basic-programming-languages"></a>21.4.1. C, C++, and Fortran</h3></div></div></div>
<p>Compilers for the C and C++ languages come with
the NetBSD base system. By default, pkgsrc assumes that a package
is written in C and will hide all other compilers (via the wrapper
- framework, see <a class="xref" href="#buildlink" title="Chapter�18.�Buildlink methodology">Chapter�18, <i>Buildlink methodology</i></a>).</p>
+ framework, see <a class="xref" href="#buildlink" title="Chapter 18. Buildlink methodology">Chapter 18, <i>Buildlink methodology</i></a>).</p>
<p>To declare which languages should be made available through
pkgsrc's compiler wrappers, use
the <code class="varname">USE_LANGUAGES</code> variable. Allowed values
@@ -8677,7 +8677,7 @@ c, c++, fortran, fortran77, java, objc,
</pre>
<p>
(and any combination). The default is
- <span class="quote">“<span class="quote">c</span>”</span>. Packages using GNU configure scripts, even if
+ <span class="quote">“<span class="quote">c</span>”</span>. Packages using GNU configure scripts, even if
written in C++, usually need a C compiler for the configure
phase.</p>
<p>To declare which features a package requires from the
@@ -8728,7 +8728,7 @@ gnu++03, gnu++11, gnu++14, gnu++17, gnu+
</div>
<div class="sect2">
<div class="titlepage"><div><div><h3 class="title">
-<a name="java-programming-language"></a>21.4.2.�Java</h3></div></div></div>
+<a name="java-programming-language"></a>21.4.2. Java</h3></div></div></div>
<p>If a program is written in Java, use the Java framework in
pkgsrc. The package must include
<code class="filename">../../mk/java-vm.mk</code>. This Makefile fragment
@@ -8736,16 +8736,16 @@ gnu++03, gnu++11, gnu++14, gnu++17, gnu+
<div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; ">
<li class="listitem"><p><code class="varname">USE_JAVA</code> defines if a build
dependency on the JDK is added. If
- <code class="varname">USE_JAVA</code> is set to <span class="quote">“<span class="quote">run</span>”</span>, then
+ <code class="varname">USE_JAVA</code> is set to <span class="quote">“<span class="quote">run</span>”</span>, then
there is only a runtime dependency on the JDK. The default is
- <span class="quote">“<span class="quote">yes</span>”</span>, which also adds a build dependency on the
+ <span class="quote">“<span class="quote">yes</span>”</span>, which also adds a build dependency on the
JDK.</p></li>
<li class="listitem"><p>Set <code class="varname">USE_JAVA2</code> to declare that
a package needs a Java2 implementation. The supported values
- are <span class="quote">“<span class="quote">yes</span>”</span>, <span class="quote">“<span class="quote">1.4</span>”</span>, and
- <span class="quote">“<span class="quote">1.5</span>”</span>. <span class="quote">“<span class="quote">yes</span>”</span> accepts any Java2
- implementation, <span class="quote">“<span class="quote">1.4</span>”</span> insists on versions 1.4 or
- above, and <span class="quote">“<span class="quote">1.5</span>”</span> only accepts versions 1.5 or
+ are <span class="quote">“<span class="quote">yes</span>”</span>, <span class="quote">“<span class="quote">1.4</span>”</span>, and
+ <span class="quote">“<span class="quote">1.5</span>”</span>. <span class="quote">“<span class="quote">yes</span>”</span> accepts any Java2
+ implementation, <span class="quote">“<span class="quote">1.4</span>”</span> insists on versions 1.4 or
+ above, and <span class="quote">“<span class="quote">1.5</span>”</span> only accepts versions 1.5 or
above. This variable is not set by default.</p></li>
<li class="listitem"><p><code class="varname">PKG_JAVA_HOME</code> is
automatically set to the runtime location of the used Java
@@ -8757,7 +8757,7 @@ gnu++03, gnu++11, gnu++14, gnu++17, gnu+
</div>
<div class="sect2">
<div class="titlepage"><div><div><h3 class="title">
-<a name="go-programming-language"></a>21.4.3.�Go</h3></div></div></div>
+<a name="go-programming-language"></a>21.4.3. Go</h3></div></div></div>
<p>If a program is written in Go and has any dependencies on
other Go modules, have the package include
<code class="filename">../../lang/go/go-module.mk</code>.</p>
@@ -8775,7 +8775,7 @@ gnu++03, gnu++11, gnu++14, gnu++17, gnu+
</div>
<div class="sect2">
<div class="titlepage"><div><div><h3 class="title">
-<a name="rust-programming-language"></a>21.4.4.�Rust</h3></div></div></div>
+<a name="rust-programming-language"></a>21.4.4. Rust</h3></div></div></div>
<p>If a program is written in Rust and uses Cargo to build,
have the package include
<code class="filename">../../lang/rust/cargo.mk</code>.</p>
@@ -8793,9 +8793,9 @@ gnu++03, gnu++11, gnu++14, gnu++17, gnu+
</div>
<div class="sect2">
<div class="titlepage"><div><div><h3 class="title">
-<a name="perl-scripts"></a>21.4.5.�Packages containing Perl scripts</h3></div></div></div>
+<a name="perl-scripts"></a>21.4.5. Packages containing Perl scripts</h3></div></div></div>
<p>If your package contains interpreted Perl scripts, add
- <span class="quote">“<span class="quote">perl</span>”</span> to the <code class="varname">USE_TOOLS</code> variable
+ <span class="quote">“<span class="quote">perl</span>”</span> to the <code class="varname">USE_TOOLS</code> variable
and set <code class="varname">REPLACE_PERL</code> to ensure that the proper
interpreter path is set. <code class="varname">REPLACE_PERL</code> should
contain a list of scripts, relative to <code class="varname">WRKSRC</code>,
@@ -8804,15 +8804,15 @@ gnu++03, gnu++11, gnu++14, gnu++17, gnu+
replaced with the full path to the Perl executable.</p>
<p>If a particular version of Perl is needed, set the
<code class="varname">PERL5_REQD</code> variable to the version number. The
- default is <span class="quote">“<span class="quote">5.0</span>”</span>.</p>
-<p>See <a class="xref" href="#perl-modules" title="21.6.6.�Packages installing Perl modules">Section�21.6.6, “Packages installing Perl modules”</a> for information
+ default is <span class="quote">“<span class="quote">5.0</span>”</span>.</p>
+<p>See <a class="xref" href="#perl-modules" title="21.6.6. Packages installing Perl modules">Section 21.6.6, “Packages installing Perl modules”</a> for information
about handling Perl modules.</p>
<p>There is also the <code class="varname">REPLACE_PERL6</code> variable
for the language now known as Raku.</p>
</div>
<div class="sect2">
<div class="titlepage"><div><div><h3 class="title">
-<a name="shell-scripts"></a>21.4.6.�Packages containing shell scripts</h3></div></div></div>
+<a name="shell-scripts"></a>21.4.6. Packages containing shell scripts</h3></div></div></div>
<p><code class="varname">REPLACE_SH</code>,
<code class="varname">REPLACE_BASH</code>, <code class="varname">REPLACE_CSH</code>,
and <code class="varname">REPLACE_KSH</code> can be used to replace shell
@@ -8827,7 +8827,7 @@ gnu++03, gnu++11, gnu++14, gnu++17, gnu+
</div>
<div class="sect2">
<div class="titlepage"><div><div><h3 class="title">
-<a name="other-programming-languages"></a>21.4.7.�Other programming languages</h3></div></div></div>
+<a name="other-programming-languages"></a>21.4.7. Other programming languages</h3></div></div></div>
<p>There are further similar REPLACE variables available, e.g.,
<code class="varname">REPLACE_AWK</code> for packages containing awk scripts,
and <code class="varname">REPLACE_R</code> for R. These two, like the others
@@ -8840,7 +8840,7 @@ gnu++03, gnu++11, gnu++14, gnu++17, gnu+
<code class="filename">lang/python/application.mk</code>. For other languages,
consult the mk files found within their specific directories (the
naming convention varies), or check the list found in
- <a class="xref" href="#help-topics" title="Appendix�E.�Help topics">Appendix�E, <i>Help topics</i></a>.</p>
+ <a class="xref" href="#help-topics" title="Appendix E. Help topics">Appendix E, <i>Help topics</i></a>.</p>
<p>Currently, special handling for other languages varies
in pkgsrc. If a compiler package provides a
<code class="filename">buildlink3.mk</code> file, include that, otherwise
@@ -8850,7 +8850,7 @@ gnu++03, gnu++11, gnu++14, gnu++17, gnu+
</div>
<div class="sect1">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="fixes.build"></a>21.5.�The <span class="emphasis"><em>build</em></span> phase</h2></div></div></div>
+<a name="fixes.build"></a>21.5. The <span class="emphasis"><em>build</em></span> phase</h2></div></div></div>
<p>The most common failures when building a package are that
some platforms do not provide certain header files, functions or
libraries, or they provide the functions in a library that the
@@ -8859,7 +8859,7 @@ gnu++03, gnu++11, gnu++14, gnu++17, gnu+
use the missing functions or provides a replacement function.</p>
<div class="sect2">
<div class="titlepage"><div><div><h3 class="title">
-<a name="fixes.build.cpp"></a>21.5.1.�Compiling C and C++ code conditionally</h3></div></div></div>
+<a name="fixes.build.cpp"></a>21.5.1. Compiling C and C++ code conditionally</h3></div></div></div>
<p>If a package already comes with a GNU configure script, the
preferred way to fix the build failure is to change the
configure script, not the code. In the other cases, you can
@@ -8879,7 +8879,7 @@ gnu++03, gnu++11, gnu++14, gnu++17, gnu+
does not define it. Use <code class="varname">__sun</code> instead.</p>
<div class="sect3">
<div class="titlepage"><div><div><h4 class="title">
-<a name="fixes.build.cpp.os"></a>21.5.1.1.�C preprocessor macros to identify the operating system</h4></div></div></div>
+<a name="fixes.build.cpp.os"></a>21.5.1.1. C preprocessor macros to identify the operating system</h4></div></div></div>
<p>To distinguish between specific NetBSD versions,
you should use the following code.</p>
<pre class="programlisting">
@@ -8923,7 +8923,7 @@ Solaris sun, __sun
</div>
<div class="sect3">
<div class="titlepage"><div><div><h4 class="title">
-<a name="fixes.build.cpp.arch"></a>21.5.1.2.�C preprocessor macros to identify the hardware architecture</h4></div></div></div>
+<a name="fixes.build.cpp.arch"></a>21.5.1.2. C preprocessor macros to identify the hardware architecture</h4></div></div></div>
<pre class="programlisting">
i386 i386, __i386, __i386__
x86-64 __amd64__, __x86_64__
@@ -8935,7 +8935,7 @@ PowerPC __powerpc
</div>
<div class="sect3">
<div class="titlepage"><div><div><h4 class="title">
-<a name="fixes.build.cpp.compiler"></a>21.5.1.3.�C preprocessor macros to identify the compiler</h4></div></div></div>
+<a name="fixes.build.cpp.compiler"></a>21.5.1.3. C preprocessor macros to identify the compiler</h4></div></div></div>
<pre class="programlisting">
GCC __GNUC__ (major version), __GNUC_MINOR__
MIPSpro _COMPILER_VERSION (0x741 for MIPSpro 7.41)
@@ -8946,7 +8946,7 @@ SunPro C++ __SUNPRO_CC (0x580 for Sun C
</div>
<div class="sect2">
<div class="titlepage"><div><div><h3 class="title">
-<a name="compiler-bugs"></a>21.5.2.�How to handle compiler bugs</h3></div></div></div>
+<a name="compiler-bugs"></a>21.5.2. How to handle compiler bugs</h3></div></div></div>
<p>Some source files trigger bugs in the compiler, based on
combinations of compiler version and architecture and almost
always relation to optimisation being enabled. Common symptoms
@@ -8964,7 +8964,7 @@ SunPro C++ __SUNPRO_CC (0x580 for Sun C
</div>
<div class="sect2">
<div class="titlepage"><div><div><h3 class="title">
-<a name="fixes.build.header"></a>21.5.3.�No such file or directory</h3></div></div></div>
+<a name="fixes.build.header"></a>21.5.3. No such file or directory</h3></div></div></div>
<p>Compilation sometimes fails with an error message like this:</p>
<pre class="programlisting">
.../x11/gtk3/work/gtk+-3.24.12/gdk/gdktypes.h:35:10:
@@ -8974,7 +8974,7 @@ SunPro C++ __SUNPRO_CC (0x580 for Sun C
header, which is described in the following sections.</p>
<div class="sect3">
<div class="titlepage"><div><div><h4 class="title">
-<a name="fixes.build.header.bl3"></a>21.5.3.1.�Headers from other packages</h4></div></div></div>
+<a name="fixes.build.header.bl3"></a>21.5.3.1. Headers from other packages</h4></div></div></div>
<p>If the header name looks like it comes from a different package,
that other package should be included via the buildlink3
framework.</p>
@@ -9018,7 +9018,7 @@ header.</p>
</div>
<div class="sect3">
<div class="titlepage"><div><div><h4 class="title">
-<a name="fixes.build.header.gen"></a>21.5.3.2.�Headers generated during the build</h4></div></div></div>
+<a name="fixes.build.header.gen"></a>21.5.3.2. Headers generated during the build</h4></div></div></div>
<p>If the name of the header seems to come from the package itself,
and if the build is run with parallel jobs, the package may have some
undeclared dependencies between the <code class="filename">.c</code> and the
@@ -9049,7 +9049,7 @@ message and the contents of your <a clas
</div>
<div class="sect3">
<div class="titlepage"><div><div><h4 class="title">
-<a name="fixes.build.header.symlink"></a>21.5.3.3.�Symlinks</h4></div></div></div>
+<a name="fixes.build.header.symlink"></a>21.5.3.3. Symlinks</h4></div></div></div>
<p>Pkgsrc does not work reliably if any of
<code class="varname">LOCALBASE</code>, <code class="varname">VARBASE</code> or
<code class="varname">WRKDIR</code> contains a symlink. Since 2019Q2, the pkgsrc
@@ -9062,7 +9062,7 @@ the actual cause.</p>
</div>
<div class="sect3">
<div class="titlepage"><div><div><h4 class="title">
-<a name="fixes.build.header.stale"></a>21.5.3.4.�Stale working directories</h4></div></div></div>
+<a name="fixes.build.header.stale"></a>21.5.3.4. Stale working directories</h4></div></div></div>
<p>When building a hierarchy of packages, it may happen that one
package is built and then pkgsrc is updated. This situation can provoke
various hard to diagnose build errors. To clean up the situation:</p>
@@ -9076,7 +9076,7 @@ that directory as well.</p>
</div>
<div class="sect3">
<div class="titlepage"><div><div><h4 class="title">
-<a name="fixes.build.header.misc"></a>21.5.3.5.�Other possible reasons</h4></div></div></div>
+<a name="fixes.build.header.misc"></a>21.5.3.5. Other possible reasons</h4></div></div></div>
<p>On platforms other than BSD, third-party packages are installed in
<code class="filename">/usr/include</code>, together with the base system. This
means that pkgsrc cannot distinguish between headers provided by the base
@@ -9088,14 +9088,14 @@ may happen that some files are manually
reason, run <span class="command"><strong>pkg_admin check</strong></span>.</p>
<p>It may help to run <span class="command"><strong>pkg_admin rebuild-tree</strong></span> to
check/fix dependencies.</p>
-<p>If all of the above doesn't help, see <a class="xref" href="#help-user" title="Chapter�2.�Getting help">Chapter�2, <i>Getting help</i></a>
+<p>If all of the above doesn't help, see <a class="xref" href="#help-user" title="Chapter 2. Getting help">Chapter 2, <i>Getting help</i></a>
for contact information. Be prepared to describe what you have tried so
far and what any error messages were.</p>
</div>
</div>
<div class="sect2">
<div class="titlepage"><div><div><h3 class="title">
-<a name="undefined-reference"></a>21.5.4.�Undefined reference to <span class="quote">“<span class="quote">...</span>”</span>
+<a name="undefined-reference"></a>21.5.4. Undefined reference to <span class="quote">“<span class="quote">...</span>”</span>
</h3></div></div></div>
<p>This error message often means that a package did not
link to a shared library it needs. The following functions are
@@ -9158,7 +9158,7 @@ far and what any error messages were.</p
bmake</strong></span>.</p>
<div class="sect3">
<div class="titlepage"><div><div><h4 class="title">
-<a name="undefined-reference-sunpro"></a>21.5.4.1.�The SunPro compiler and inline functions</h4></div></div></div>
+<a name="undefined-reference-sunpro"></a>21.5.4.1. The SunPro compiler and inline functions</h4></div></div></div>
<p>When you are using the SunPro compiler, there is another
possibility. That compiler cannot handle the following code:</p>
<pre class="programlisting">
@@ -9183,7 +9183,7 @@ of functions.</p>
</div>
<div class="sect3">
<div class="titlepage"><div><div><h4 class="title">
-<a name="undefined-reference-atomic"></a>21.5.4.2.�Missing atomic functions</h4></div></div></div>
+<a name="undefined-reference-atomic"></a>21.5.4.2. Missing atomic functions</h4></div></div></div>
<p>When building for older machine architectures (e.g., i386, PowerPC),
builds may fail because the package expects modern 64-bit atomic functions
which the underlying hardware either doesn't support, or will only support
@@ -9193,16 +9193,16 @@ of functions.</p>
</div>
<div class="sect2">
<div class="titlepage"><div><div><h3 class="title">
-<a name="out-of-memory"></a>21.5.5.�Running out of memory</h3></div></div></div>
+<a name="out-of-memory"></a>21.5.5. Running out of memory</h3></div></div></div>
<p>Sometimes packages fail to build because the compiler runs
into an operating system specific soft limit. With the
<code class="varname">UNLIMIT_RESOURCES</code> variable pkgsrc can be told
to unlimit the resources. The allowed values are any combination of
- <span class="quote">“<span class="quote">cputime</span>”</span>,
- <span class="quote">“<span class="quote">datasize</span>”</span>,
- <span class="quote">“<span class="quote">memorysize</span>”</span>,
- <span class="quote">“<span class="quote">stacksize</span>”</span> and
- <span class="quote">“<span class="quote">virtualsize</span>”</span>.
+ <span class="quote">“<span class="quote">cputime</span>”</span>,
+ <span class="quote">“<span class="quote">datasize</span>”</span>,
+ <span class="quote">“<span class="quote">memorysize</span>”</span>,
+ <span class="quote">“<span class="quote">stacksize</span>”</span> and
+ <span class="quote">“<span class="quote">virtualsize</span>”</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
@@ -9211,10 +9211,10 @@ of functions.</p>
</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>
+<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>
+<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
@@ -9224,20 +9224,20 @@ ${INSTALL_DATA_DIR} ${PREFIX}/dir1
${INSTALL_DATA_DIR} ${PREFIX}/dir2
</pre>
<p>Instead of running the <span class="command"><strong>install</strong></span> commands
- directly, you can also append <span class="quote">“<span class="quote"><code class="literal">dir1
- dir2</code></span>”</span> to the <code class="varname">INSTALLATION_DIRS</code>
+ directly, you can also append <span class="quote">“<span class="quote"><code class="literal">dir1
+ dir2</code></span>”</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>
+<a name="where-to-install-documentation"></a>21.6.2. Where to install documentation</h3></div></div></div>
<p>In general, documentation should be installed into
<code class="filename">${PREFIX}/share/doc/${PKGBASE}</code> or
<code class="filename">${PREFIX}/share/doc/${PKGNAME_NOREV}</code> (the latter
includes the version number of the package).</p>
<p>Many modern packages using GNU autoconf allow to set the
directory where HTML documentation is installed with the
- <span class="quote">“<span class="quote">--with-html-dir</span>”</span> option. Sometimes using this flag is
+ <span class="quote">“<span class="quote">--with-html-dir</span>”</span> option. Sometimes using this flag is
needed because otherwise the documentation ends up in
<code class="filename">${PREFIX}/share/doc/html</code> or other places. In
pkgsrc, the HTML documentation should go into the package-specific
@@ -9254,13 +9254,13 @@ ${INSTALL_DATA_DIR} ${PREFIX}/dir2
<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">“<span class="quote">--with-html-dir=${PREFIX}/share/doc</span>”</span>.
+ <span class="quote">“<span class="quote">--with-html-dir=${PREFIX}/share/doc</span>”</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>
+<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
@@ -9304,18 +9304,18 @@ SPECIAL_PERMS+= ${PREFIX}/bin/mo
</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>
+<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">“<span class="quote">destdir</span>”</span>) or the package can
- install as non-root user (<span class="quote">“<span class="quote">user-destdir</span>”</span>).</p>
+ install as root (<span class="quote">“<span class="quote">destdir</span>”</span>) or the package can
+ install as non-root user (<span class="quote">“<span class="quote">user-destdir</span>”</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">“<span class="quote">destdir</span>”</span> or <span class="quote">“<span class="quote">user-destdir</span>”</span>.
+ set to <span class="quote">“<span class="quote">destdir</span>”</span> or <span class="quote">“<span class="quote">user-destdir</span>”</span>.
By default <code class="varname">PKG_DESTDIR_SUPPORT</code>
- is set to <span class="quote">“<span class="quote">user-destdir</span>”</span> to help catching more
+ is set to <span class="quote">“<span class="quote">user-destdir</span>”</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>
@@ -9333,7 +9333,7 @@ SPECIAL_PERMS+= ${PREFIX}/bin/mo
</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>
+<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
@@ -9349,7 +9349,7 @@ REPLACE_FILES.tcl= # list of tcl sc
</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>
+<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
@@ -9389,7 +9389,7 @@ PERL5_PACKLIST= auto/Pg/.packlist
</div>
<div class="sect2">
<div class="titlepage"><div><div><h3 class="title">
-<a name="faq.pkg-config-files"></a>21.6.7.�Packages installing pkg-config files</h3></div></div></div>
+<a name="faq.pkg-config-files"></a>21.6.7. Packages installing pkg-config files</h3></div></div></div>
<p>Some packages, usually those providing libraries, install
pkg-config files so that their headers and libraries can easily be
found. The file names end with <code class="filename">.pc</code>.</p>
@@ -9413,28 +9413,28 @@ PKGCONFIG_OVERRIDE_STAGE= post-bui
</div>
<div class="sect2">
<div class="titlepage"><div><div><h3 class="title">
-<a name="faq.info-files"></a>21.6.8.�Packages installing info files</h3></div></div></div>
+<a name="faq.info-files"></a>21.6.8. Packages installing info files</h3></div></div></div>
<p>Some packages install info files or use the
- <span class="quote">“<span class="quote">makeinfo</span>”</span> or <span class="quote">“<span class="quote">install-info</span>”</span>
+ <span class="quote">“<span class="quote">makeinfo</span>”</span> or <span class="quote">“<span class="quote">install-info</span>”</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">“<span class="quote">install-info</span>”</span> command used for the info
+ file. The <span class="quote">“<span class="quote">install-info</span>”</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">“<span class="quote">info</span>”</span> and can be overridden by the user.</p>
+ <span class="quote">“<span class="quote">info</span>”</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">“<span class="quote">makeinfo</span>”</span> command
- at build time must add <span class="quote">“<span class="quote">makeinfo</span>”</span> to
+<p>A package which needs the <span class="quote">“<span class="quote">makeinfo</span>”</span> command
+ at build time must add <span class="quote">“<span class="quote">makeinfo</span>”</span> to
<code class="varname">USE_TOOLS</code> in its Makefile. If a minimum
- version of the <span class="quote">“<span class="quote">makeinfo</span>”</span> command is needed it
+ version of the <span class="quote">“<span class="quote">makeinfo</span>”</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
@@ -9460,15 +9460,15 @@ PKGCONFIG_OVERRIDE_STAGE= post-bui
</div>
<div class="sect2">
<div class="titlepage"><div><div><h3 class="title">
-<a name="manpages"></a>21.6.9.�Packages installing man pages</h3></div></div></div>
+<a name="manpages"></a>21.6.9. 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">“<span class="quote"><code class="filename">man</code></span>”</span>. Another often-used value
- is <span class="quote">“<span class="quote"><code class="filename">share/man</code></span>”</span>.</p>
+ <span class="quote">“<span class="quote"><code class="filename">man</code></span>”</span>. Another often-used value
+ is <span class="quote">“<span class="quote"><code class="filename">share/man</code></span>”</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>
@@ -9481,23 +9481,23 @@ PKGCONFIG_OVERRIDE_STAGE= post-bui
<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">“<span class="quote">yes</span>”</span>, by default will use the
+ <span class="quote">“<span class="quote">yes</span>”</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">“<span class="quote">no</span>”</span>.
+ to <span class="quote">“<span class="quote">no</span>”</span>.
Or if the <code class="filename">./configure</code> script uses
a non-standard use of --mandir, you can set
<code class="varname">GNU_CONFIGURE_MANDIR</code> as needed.</p>
-<p>See <a class="xref" href="#manpage-compression" title="19.5.�Man page compression">Section�19.5, “Man page compression”</a> for
+<p>See <a class="xref" href="#manpage-compression" title="19.5. Man page compression">Section 19.5, “Man page compression”</a> for
information on installation of compressed manual pages.</p>
</div>
<div class="sect2">
<div class="titlepage"><div><div><h3 class="title">
-<a name="x11-fonts"></a>21.6.10.�Packages installing X11 fonts</h3></div></div></div>
+<a name="x11-fonts"></a>21.6.10. 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
@@ -9505,7 +9505,7 @@ PKGCONFIG_OVERRIDE_STAGE= post-bui
<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">“<span class="quote">ttf</span>”</span>, <span class="quote">“<span class="quote">type1</span>”</span> or <span class="quote">“<span
class="quote">x11</span>”</span>.
+ <span class="quote">“<span class="quote">ttf</span>”</span>, <span class="quote">“<span class="quote">type1</span>”</span> or <span class="quote">“<span class="quote">x11</span>”</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;
@@ -9514,7 +9514,7 @@ PKGCONFIG_OVERRIDE_STAGE= post-bui
</div>
<div class="sect2">
<div class="titlepage"><div><div><h3 class="title">
-<a name="sgml-xml-data"></a>21.6.11.�Packages installing SGML or XML data</h3></div></div></div>
+<a name="sgml-xml-data"></a>21.6.11. 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>
@@ -9542,7 +9542,7 @@ PKGCONFIG_OVERRIDE_STAGE= post-bui
</div>
<div class="sect2">
<div class="titlepage"><div><div><h3 class="title">
-<a name="mime-database"></a>21.6.12.�Packages installing extensions to the MIME database</h3></div></div></div>
+<a name="mime-database"></a>21.6.12. 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
@@ -9572,7 +9572,7 @@ PKGCONFIG_OVERRIDE_STAGE= post-bui
</div>
<div class="sect2">
<div class="titlepage"><div><div><h3 class="title">
-<a name="intltool"></a>21.6.13.�Packages using intltool</h3></div></div></div>
+<a name="intltool"></a>21.6.13. 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,
@@ -9583,7 +9583,7 @@ PKGCONFIG_OVERRIDE_STAGE= post-bui
</div>
<div class="sect2">
<div class="titlepage"><div><div><h3 class="title">
-<a name="startup-scripts"></a>21.6.14.�Packages installing startup scripts</h3></div></div></div>
+<a name="startup-scripts"></a>21.6.14. Packages installing startup scripts</h3></div></div></div>
<p>If a package contains an rc.d script, it won't be copied into
the startup directory (<code class="filename">/etc/rc.d</code>) by default,
but you can enable copying by setting the option
@@ -9599,7 +9599,7 @@ PKGCONFIG_OVERRIDE_STAGE= post-bui
</div>
<div class="sect2">
<div class="titlepage"><div><div><h3 class="title">
-<a name="tex-packages"></a>21.6.15.�Packages installing TeX modules</h3></div></div></div>
+<a name="tex-packages"></a>21.6.15. 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>
@@ -9638,7 +9638,7 @@ PKGCONFIG_OVERRIDE_STAGE= post-bui
</div>
<div class="sect2">
<div class="titlepage"><div><div><h3 class="title">
-<a name="emulation-packages"></a>21.6.16.�Packages supporting running binaries in
+<a name="emulation-packages"></a>21.6.16. 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
@@ -9655,7 +9655,7 @@ PKGCONFIG_OVERRIDE_STAGE= post-bui
</div>
<div class="sect2">
<div class="titlepage"><div><div><h3 class="title">
-<a name="hicolor-theme"></a>21.6.17.�Packages installing hicolor icons</h3></div></div></div>
+<a name="hicolor-theme"></a>21.6.17. Packages installing hicolor icons</h3></div></div></div>
<p>If a package installs images under the
<code class="filename">share/icons/hicolor</code> and/or updates the
<code class="filename">share/icons/hicolor/icon-theme.cache</code>
@@ -9677,7 +9677,7 @@ PKGCONFIG_OVERRIDE_STAGE= post-bui
</div>
<div class="sect2">
<div class="titlepage"><div><div><h3 class="title">
-<a name="desktop-files"></a>21.6.18.�Packages installing desktop files</h3></div></div></div>
+<a name="desktop-files"></a>21.6.18. 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
@@ -9696,7 +9696,7 @@ PKGCONFIG_OVERRIDE_STAGE= post-bui
</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>
+<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
@@ -9710,7 +9710,7 @@ PKGCONFIG_OVERRIDE_STAGE= post-bui
</div>
<div class="chapter">
<div class="titlepage"><div><div><h2 class="title">
-<a name="gnome"></a>Chapter�22.�GNOME packaging and porting</h2></div></div></div>
+<a name="gnome"></a>Chapter 22. GNOME packaging and porting</h2></div></div></div>
<div class="toc">
<p><b>Table of Contents</b></p>
<dl class="toc">
@@ -9743,7 +9743,7 @@ provides instructions on how to manage t
important information regarding their internals.</p>
<div class="sect1">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="meta-packages"></a>22.1.�Meta packages</h2></div></div></div>
+<a name="meta-packages"></a>22.1. Meta packages</h2></div></div></div>
<p>pkgsrc includes three GNOME-related meta packages:</p>
<div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; ">
<li class="listitem"><p><a href="https://cdn.NetBSD.org/pub/pkgsrc/current/pkgsrc/meta-pkgs/gnome-base/index.html" target="_top"><code class="filename">meta-pkgs/gnome-base</code></a>: Provides
@@ -9777,7 +9777,7 @@ change it to alphabetical sorting!</em><
</div>
<div class="sect1">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="new-package"></a>22.2.�Packaging a GNOME application</h2></div></div></div>
+<a name="new-package"></a>22.2. Packaging a GNOME application</h2></div></div></div>
<p>Almost all GNOME applications are written in C and use a common
set of tools as their build system. Things get different with the new
bindings to other languages (such as Python), but the following will
@@ -9844,7 +9844,7 @@ solution is given. After applying the s
<span class="emphasis"><em>regenerate the package's file list</em></span> with
<span class="command"><strong>make print-PLIST</strong></span> and ensure it is correct.</p>
<div class="table">
-<a name="plist-handling"></a><p class="title"><b>Table�22.1.�PLIST handling for GNOME packages</b></p>
+<a name="plist-handling"></a><p class="title"><b>Table 22.1. PLIST handling for GNOME packages</b></p>
<div class="table-contents"><table class="table" summary="PLIST handling for GNOME packages" border="1">
<colgroup>
<col>
@@ -9859,18 +9859,18 @@ solution is given. After applying the s
<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.17.�Packages installing hicolor icons">Section�21.6.17, “Packages installing hicolor icons”</a>.</td>
+<td>See <a class="xref" href="#hicolor-theme" title="21.6.17. Packages installing hicolor icons">Section 21.6.17, “Packages installing hicolor icons”</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.12.�Packages installing extensions to the MIME database">Section�21.6.12, “Packages installing extensions to the MIME
database”</a>.</td>
+<td>See <a class="xref" href="#mime-database" title="21.6.12. Packages installing extensions to the MIME database">Section 21.6.12, “Packages installing extensions to the MIME database”</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.18.�Packages installing desktop files">Section�21.6.18, “Packages installing desktop files”</a>.</td>
+<td>See <a class="xref" href="#desktop-files" title="21.6.18. Packages installing desktop files">Section 21.6.18, “Packages installing desktop files”</a>.</td>
</tr>
</tbody>
</table></div>
@@ -9879,7 +9879,7 @@ solution is given. After applying the s
</div>
<div class="sect1">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="full-update"></a>22.3.�Updating GNOME to a newer version</h2></div></div></div>
+<a name="full-update"></a>22.3. Updating GNOME to a newer version</h2></div></div></div>
<p>When seeing GNOME as a whole, there are two kinds of
updates:</p>
<div class="variablelist"><dl class="variablelist">
@@ -9968,11 +9968,11 @@ followed:</p>
</div>
<div class="sect1">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="patching"></a>22.4.�Patching guidelines</h2></div></div></div>
+<a name="patching"></a>22.4. Patching guidelines</h2></div></div></div>
<p>GNOME is a very big component in pkgsrc which approaches 100
packages. Please, it is very important that you always, always,
<span class="strong"><strong>always</strong></span> feed back any portability
-fixes you do to a GNOME package to the mainstream developers (see <a class="xref" href="#components.patches.feedback" title="12.3.5.�Feedback to the author">Section�12.3.5, “Feedback to the
author”</a>). This is the only way to get
+fixes you do to a GNOME package to the mainstream developers (see <a class="xref" href="#components.patches.feedback" title="12.3.5. Feedback to the author">Section 12.3.5, “Feedback to the
author”</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
@@ -9989,13 +9989,13 @@ issues. While the FreeBSD GNOME people
GNOME to their operating system, the official GNOME sources are now
plagued by conditionals that check for <code class="varname">__FreeBSD__</code>
and similar macros. This hurts portability. Please see our patching
-guidelines (<a class="xref" href="#components.patches.guidelines" title="12.3.4.�Patching guidelines">Section�12.3.4, “Patching guidelines”</a>) for more
+guidelines (<a class="xref" href="#components.patches.guidelines" title="12.3.4. Patching guidelines">Section 12.3.4, “Patching guidelines”</a>) for more
details.</p>
</div>
</div>
<div class="chapter">
<div class="titlepage"><div><div><h2 class="title">
-<a name="submit"></a>Chapter�23.�Submitting and Committing</h2></div></div></div>
+<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">
@@ -10011,25 +10011,25 @@ details.</p>
</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>
+<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
+ 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>
+<a name="submitting-your-package"></a>23.2. Submitting source packages (for non-NetBSD-developers)</h2></div></div></div>
<p>Firstly, you can import new packages into
- pkgsrc-wip (<span class="quote">“<span class="quote">pkgsrc work-in-progress</span>”</span>); see the
+ pkgsrc-wip (<span class="quote">“<span class="quote">pkgsrc work-in-progress</span>”</span>); see the
homepage at <a class="ulink" href="https://pkgsrc.org/wip/" target="_top">https://pkgsrc.org/wip/</a>
for details.</p>
<p>Next, check that your package is complete, compiles and
- runs well; see <a class="xref" href="#creating" title="Chapter�14.�Creating a new pkgsrc package from scratch">Chapter�14, <i>Creating a new pkgsrc package from scratch</i></a> and the rest
of this
+ runs well; see <a class="xref" href="#creating" title="Chapter 14. Creating a new pkgsrc package from scratch">Chapter 14, <i>Creating a new pkgsrc package from scratch</i></a> and the rest
of this
document. Run the <a href="https://cdn.NetBSD.org/pub/pkgsrc/current/pkgsrc/pkgtools/pkglint/index.html" target="_top"><code class="filename">pkgtools/pkglint</code></a>
tool and fix any errors that appear.</p>
<p>Finally, send a report to the pkgsrc bug tracking system,
@@ -10042,14 +10042,14 @@ builds)</i></a>.</p>
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">“<span class="quote">pkg</span>”</span>, the synopsis should include the package name
+ <span class="quote">“<span class="quote">pkg</span>”</span>, the synopsis should include the package name
and version number, and the description field should contain a
short description of your package (contents of the COMMENT
variable or DESCR file are OK).</p>
</div>
<div class="sect1">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="general-notes-for-changes"></a>23.3.�General notes when adding, updating, or removing packages</h2></div></div></div>
+<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
@@ -10088,7 +10088,7 @@ builds)</i></a>.</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>
+<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 practice when using these tools is to
make the first line of a commit message function as a summary that
@@ -10124,19 +10124,19 @@ mk/bsd.pkg.mk: enable SSP by default on
</pre>
<p>
</p>
-<p>Commit messages are final: no <span class="quote">“<span class="quote">cvs admin</span>”</span> is
+<p>Commit messages are final: no <span class="quote">“<span class="quote">cvs admin</span>”</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>
+<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">“<span class="quote">cvs add</span>”</span> the files.
+<p>When the package is finished, <span class="quote">“<span class="quote">cvs add</span>”</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">“<span class="quote">cvs status</span>”</span>. An example:</p>
+you can check by running <span class="quote">“<span class="quote">cvs status</span>”</span>. An example:</p>
<pre class="programlisting">
<code class="prompt">$</code> cd .../pkgsrc/category
<code class="prompt">$</code> cvs add pkgname
@@ -10156,12 +10156,12 @@ you can check by running <span class="qu
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">“<span class="quote">cvs import</span>”</span> was suggested, but it was
-much easier to get wrong than <span class="quote">“<span class="quote">cvs add</span>”</span>.</p>
+<p>Previously, <span class="quote">“<span class="quote">cvs import</span>”</span> was suggested, but it was
+much easier to get wrong than <span class="quote">“<span class="quote">cvs add</span>”</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>
+<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>
@@ -10185,7 +10185,7 @@ much easier to get wrong than <span clas
</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>
+<a name="renaming-package"></a>23.7. Renaming a package in pkgsrc</h2></div></div></div>
<p>Renaming packages is not recommended.</p>
<p>When renaming packages, be sure to fix any references to the old name
in other Makefiles, options, buildlink files, etc.</p>
@@ -10201,7 +10201,7 @@ much easier to get wrong than <span clas
SUPERSEDES+= p5-IO-Compress-Zlib<2.017
SUPERSEDES+= optcomp-[0-9]*
</pre>
-<p>Note that <span class="quote">“<span class="quote">successor</span>”</span> in the
+<p>Note that <span class="quote">“<span class="quote">successor</span>”</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
@@ -10209,7 +10209,7 @@ SUPERSEDES+= optcomp-[0-9]*
</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>
+<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>
@@ -10222,8 +10222,8 @@ SUPERSEDES+= optcomp-[0-9]*
<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">“<span class="quote">../package</span>”</span>
-instead of <span class="quote">“<span class="quote">../../category/package</span>”</span>.</p></li>
+<code class="varname">DEPENDS</code> paths that just did <span class="quote">“<span class="quote">../package</span>”</span>
+instead of <span class="quote">“<span class="quote">../../category/package</span>”</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
@@ -10257,7 +10257,7 @@ place.</p></li>
</div>
<div class="chapter">
<div class="titlepage"><div><div><h2 class="title">
-<a name="policies"></a>Chapter�24.�pkgsrc Policies</h2></div></div></div>
+<a name="policies"></a>Chapter 24. pkgsrc Policies</h2></div></div></div>
<div class="toc">
<p><b>Table of Contents</b></p>
<dl class="toc">
@@ -10270,7 +10270,7 @@ place.</p></li>
</div>
<div class="sect1">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="stability"></a>24.1.�Packages for which updating is restricted</h2></div></div></div>
+<a name="stability"></a>24.1. Packages for which updating is restricted</h2></div></div></div>
<p>In the past, some packages have caused more package failures than others, and we'd like to reduce this in the future.</p>
<p>For this reason, pkgsrc-pmc marks some packages with <code class="varname">POLICY_UPDATE_LIMITED</code>. The possible values currently are:
</p>
@@ -10282,7 +10282,7 @@ place.</p></li>
<code class="filename">pkglint</code> will warn when committing updates to these packages.</p>
<div class="sect2">
<div class="titlepage"><div><div><h3 class="title">
-<a name="stability.abi"></a>24.1.1.�Limited Updates - ABI</h3></div></div></div>
+<a name="stability.abi"></a>24.1.1. Limited Updates - ABI</h3></div></div></div>
<p>Before committing non-micro version updates to packages marked
with <code class="varname">POLICY_UPDATE_LIMITED=abi</code>, a limited bulk
build of <a href="https://cdn.NetBSD.org/pub/pkgsrc/current/pkgsrc/meta-pkgs/bulk-test-${PACKAGE}/index.html" target="_top"><code class="filename">meta-pkgs/bulk-test-${PACKAGE}</code></a> needs
to be run
@@ -10305,7 +10305,7 @@ place.</p></li>
</div>
<div class="sect2">
<div class="titlepage"><div><div><h3 class="title">
-<a name="stability.bootstrap"></a>24.1.2.�Limited Updates - Bootstrap</h3></div></div></div>
+<a name="stability.bootstrap"></a>24.1.2. Limited Updates - Bootstrap</h3></div></div></div>
<p>When updating packages used in the bootstrap, i.e. marked with
<code class="varname">POLICY_UPDATE_LIMITED=bootstrap</code>, test the
bootstrap process and preferably some basic packages and send the
@@ -10317,7 +10317,7 @@ place.</p></li>
</div>
<div class="chapter">
<div class="titlepage"><div><div><h2 class="title">
-<a name="devfaq"></a>Chapter�25.�Frequently Asked Questions</h2></div></div></div>
+<a name="devfaq"></a>Chapter 25. 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,
@@ -10437,8 +10437,8 @@ What shall I do?</a>
<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">“<span class="quote">wrapper</span>”</span> phase and later. To
- <span class="quote">“<span class="quote">simulate</span>”</span> the wrapper phase, append
+ available in the <span class="quote">“<span class="quote">wrapper</span>”</span> phase and later. To
+ <span class="quote">“<span class="quote">simulate</span>”</span> the wrapper phase, append
<span class="command"><strong>PKG_PHASE=wrapper</strong></span> to the above
command.</p></td>
</tr>
@@ -10527,8 +10527,8 @@ What shall I do?</a>
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">“<span class="quote">implicitly
- documented</span>”</span>, that is the documentation exists only in the
+<li class="listitem"><p>Some parts of pkgsrc are only <span class="quote">“<span class="quote">implicitly
+ documented</span>”</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
@@ -10573,7 +10573,7 @@ anyway.</p>
</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>
+<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
@@ -10620,7 +10620,7 @@ anyway.</p>
</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>
+<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">
@@ -10650,7 +10650,7 @@ anyway.</p>
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>
+<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.
@@ -10661,7 +10661,7 @@ anyway.</p>
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">“<span class="quote">yes</span>”</span>. All these variables may be
+ effectively mean <span class="quote">“<span class="quote">yes</span>”</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:
@@ -10681,7 +10681,7 @@ anyway.</p>
</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>
+<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
@@ -10690,7 +10690,7 @@ anyway.</p>
<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">“<span class="quote">know</span>”</span>
+ <code class="varname">DISTFILES</code>, the packages <span class="quote">“<span class="quote">know</span>”</span>
the default value and just define it as in the following
example.</p>
<pre class="programlisting">
@@ -10699,16 +10699,16 @@ DISTFILES= ${DISTNAME}${EXTRACT_SUF
<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">“<span class="quote"><code class="literal">c</code></span>”</span>) is so short that it
+ value (<span class="quote">“<span class="quote"><code class="literal">c</code></span>”</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>
+<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>
+<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>
@@ -10750,7 +10750,7 @@ CFLAGS+= -Wall
</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>
+<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>
@@ -10758,7 +10758,7 @@ CFLAGS+= -Wall
</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>
+<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
@@ -10767,14 +10767,14 @@ CFLAGS+= -Wall
</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>
+<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>
+<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—after
@@ -10808,7 +10808,7 @@ CFLAGS+= -Wall
</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>
+<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
@@ -10820,7 +10820,7 @@ CFLAGS+= -Wall
</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>
+<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.
@@ -10835,7 +10835,7 @@ CFLAGS+= -Wall
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>
+<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
@@ -10860,7 +10860,7 @@ CFLAGS+= -Wall
</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>
+<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
@@ -10893,7 +10893,7 @@ CFLAGS+= -Wall
</div>
<div class="chapter">
<div class="titlepage"><div><div><h2 class="title">
-<a name="regression"></a>Chapter�27.�Regression tests</h2></div></div></div>
+<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">
@@ -10915,7 +10915,7 @@ CFLAGS+= -Wall
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>
+<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/index.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
@@ -10923,7 +10923,7 @@ CFLAGS+= -Wall
</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>
+<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
@@ -10932,9 +10932,9 @@ CFLAGS+= -Wall
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>
+<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">“<span class="quote">set -e</span>”</span> mode, they don't stop at the
+ are called in <span class="quote">“<span class="quote">set -e</span>”</span> mode, they don't stop at the
first failing command. See <a class="ulink" href="https://stackoverflow.com/q/4072984" target="_top">this Stack Overflow
question</a> for details.</p>
<div class="variablelist"><dl class="variablelist">
@@ -10980,7 +10980,7 @@ check_result() {
</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>
+<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>
@@ -11011,7 +11011,7 @@ output_require "^[[:alpha:]+[[:space:]][
</div>
<div class="chapter">
<div class="titlepage"><div><div><h2 class="title">
-<a name="porting"></a>Chapter�28.�Porting pkgsrc</h2></div></div></div>
+<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>
@@ -11022,7 +11022,7 @@ output_require "^[[:alpha:]+[[:space:]][
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>
+<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>
@@ -11056,7 +11056,7 @@ output_require "^[[:alpha:]+[[:space:]][
</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>
+<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">
@@ -11077,10 +11077,10 @@ output_require "^[[:alpha:]+[[:space:]][
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>
+<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>
+<a name="example-Makefile"></a>A.1.1. Makefile</h3></div></div></div>
<pre class="programlisting">
# $NetBSD$
#
@@ -11101,7 +11101,7 @@ INFO_FILES= yes
</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>
+<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="//man.NetBSD.org/NetBSD-10.1/yacc.1"><span class="citerefentry"><span
class="refentrytitle">yacc</span>(1)</span></a> is part
@@ -11110,7 +11110,7 @@ of the NetBSD source tree is beyond me.
</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>
+<a name="example-plist"></a>A.1.3. PLIST</h3></div></div></div>
<pre class="programlisting">
@comment $NetBSD$
bin/bison
@@ -11121,7 +11121,7 @@ share/bison.hairy
</div>
<div class="sect2">
<div class="titlepage"><div><div><h3 class="title">
-<a name="checking-package-with-pkglint"></a>A.1.4.�Checking a package with pkglint</h3></div></div></div>
+<a name="checking-package-with-pkglint"></a>A.1.4. Checking a package with pkglint</h3></div></div></div>
<p>The NetBSD package system comes with
<a href="https://cdn.NetBSD.org/pub/pkgsrc/current/pkgsrc/pkgtools/pkglint/index.html" target="_top"><code class="filename">pkgtools/pkglint</code></a>
which helps to check the contents of these
@@ -11144,7 +11144,7 @@ WARN: PLIST:5: "share/bison.hairy" shoul
</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>
+<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>
@@ -11152,7 +11152,7 @@ WARN: PLIST:5: "share/bison.hairy" shoul
<code class="prompt">#</code> <strong class="userinput"><code>cd bison</code></strong>
<code class="prompt">#</code> <strong class="userinput"><code>mkdir patches</code></strong></pre>
<p>Create <code class="filename">Makefile</code>, <code class="filename">DESCR</code> and
- <code class="filename">PLIST</code> (see <a class="xref" href="#components" title="Chapter�12.�Package components - files, directories and contents">Chapter�12, <i>Package components - files,
directories and contents</i></a>)
+ <code class="filename">PLIST</code> (see <a class="xref" href="#components" title="Chapter 12. Package components - files, directories and contents">Chapter 12, <i>Package components - files,
directories and contents</i></a>)
then continue with fetching the distfile:</p>
<pre class="screen"><code class="prompt">#</code> <strong class="userinput"><code>make fetch</code></strong>
>> bison-1.25.tar.gz doesn't seem to exist on this system.
@@ -11253,7 +11253,7 @@ Creating gzip'd tar ball in '/u/pkgsrc/l
</div>
<div class="appendix">
<div class="titlepage"><div><div><h1 class="title">
-<a name="hardening"></a>Appendix�B.�Security hardening</h1></div></div></div>
+<a name="hardening"></a>Appendix B. Security hardening</h1></div></div></div>
<div class="toc">
<p><b>Table of Contents</b></p>
<dl class="toc">
@@ -11302,13 +11302,13 @@ notice and address these problems.
</p>
<div class="sect1">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="hardening.mechanisms"></a>B.1.�Mechanisms</h2></div></div></div>
+<a name="hardening.mechanisms"></a>B.1. Mechanisms</h2></div></div></div>
<div class="sect2">
<div class="titlepage"><div><div><h3 class="title">
-<a name="hardening.mechanisms.enabled"></a>B.1.1.�Enabled by default</h3></div></div></div>
+<a name="hardening.mechanisms.enabled"></a>B.1.1. Enabled by default</h3></div></div></div>
<div class="sect3">
<div class="titlepage"><div><div><h4 class="title">
-<a name="hardening.mechanisms.enabled.fortify"></a>B.1.1.1.�PKGSRC_USE_FORTIFY</h4></div></div></div>
+<a name="hardening.mechanisms.enabled.fortify"></a>B.1.1.1. PKGSRC_USE_FORTIFY</h4></div></div></div>
<p>
This allows substitute wrappers to be used for some commonly used
library functions that do not have built-in bounds checking - but
@@ -11327,7 +11327,7 @@ Two mitigation levels are available:
</div>
<div class="sect3">
<div class="titlepage"><div><div><h4 class="title">
-<a name="hardening.mechanisms.enabled.ssp"></a>B.1.1.2.�PKGSRC_USE_SSP</h4></div></div></div>
+<a name="hardening.mechanisms.enabled.ssp"></a>B.1.1.2. PKGSRC_USE_SSP</h4></div></div></div>
<p>
This enables a stack-smashing protection mitigation. It is done by adding a
guard variable to functions with vulnerable objects. The guards are initialized
@@ -11362,7 +11362,7 @@ for unsafe programming languages, such a
</div>
<div class="sect3">
<div class="titlepage"><div><div><h4 class="title">
-<a name="hardening.mechanisms.enabled.pie"></a>B.1.1.3.�PKGSRC_MKPIE</h4></div></div></div>
+<a name="hardening.mechanisms.enabled.pie"></a>B.1.1.3. PKGSRC_MKPIE</h4></div></div></div>
<p>
This requests the creation of PIE (Position Independent Executables) for all
executables. The PIE mechanism is normally used for shared libraries, so that
@@ -11384,7 +11384,7 @@ Currently, this means NetBSD on x86, ARM
</div>
<div class="sect3">
<div class="titlepage"><div><div><h4 class="title">
-<a name="hardening.mechanisms.enabled.relro"></a>B.1.1.4.�PKGSRC_USE_RELRO</h4></div></div></div>
+<a name="hardening.mechanisms.enabled.relro"></a>B.1.1.4. PKGSRC_USE_RELRO</h4></div></div></div>
<p>
This also makes the exploitation of some security vulnerabilities more
difficult in some cases.
@@ -11415,10 +11415,10 @@ More details can be found here:
</div>
<div class="sect2">
<div class="titlepage"><div><div><h3 class="title">
-<a name="hardening.mechanisms.disabled"></a>B.1.2.�Not enabled by default</h3></div></div></div>
+<a name="hardening.mechanisms.disabled"></a>B.1.2. Not enabled by default</h3></div></div></div>
<div class="sect3">
<div class="titlepage"><div><div><h4 class="title">
-<a name="hardening.mechanisms.disabled.repro"></a>B.1.2.1.�PKGSRC_MKREPRO</h4></div></div></div>
+<a name="hardening.mechanisms.disabled.repro"></a>B.1.2.1. PKGSRC_MKREPRO</h4></div></div></div>
<p>
With this option, pkgsrc will try to build packages reproducibly. This allows
packages built from the same tree and with the same options, to produce
@@ -11438,7 +11438,7 @@ More work likely needs to be done before
</div>
<div class="sect3">
<div class="titlepage"><div><div><h4 class="title">
-<a name="hardening.mechanisms.disabled.stackcheck"></a>B.1.2.2.�PKGSRC_USE_STACK_CHECK</h4></div></div></div>
+<a name="hardening.mechanisms.disabled.stackcheck"></a>B.1.2.2. PKGSRC_USE_STACK_CHECK</h4></div></div></div>
<p>
This uses <code class="literal">-fstack-check</code> with GCC for
another stack protection mitigation.
@@ -11453,13 +11453,13 @@ multi-threaded programs.
</div>
<div class="sect1">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="hardening.caveats"></a>B.2.�Caveats</h2></div></div></div>
+<a name="hardening.caveats"></a>B.2. Caveats</h2></div></div></div>
<div class="sect2">
<div class="titlepage"><div><div><h3 class="title">
-<a name="hardening.caveats.pie"></a>B.2.1.�Problems with PKGSRC_MKPIE</h3></div></div></div>
+<a name="hardening.caveats.pie"></a>B.2.1. Problems with PKGSRC_MKPIE</h3></div></div></div>
<div class="sect3">
<div class="titlepage"><div><div><h4 class="title">
-<a name="hardening.caveats.pie.build"></a>B.2.1.1.�Packages failing to build</h4></div></div></div>
+<a name="hardening.caveats.pie.build"></a>B.2.1.1. Packages failing to build</h4></div></div></div>
<p>
A number of packages may fail to build with this option enabled. The
failures are often related to the absence of the <code class="literal">-fPIC</code>
@@ -11470,7 +11470,7 @@ actually support it.
</p>
<div class="sect4">
<div class="titlepage"><div><div><h5 class="title">
-<a name="hardening.caveats.pie.build.fix"></a>B.2.1.1.1.�How to fix</h5></div></div></div>
+<a name="hardening.caveats.pie.build.fix"></a>B.2.1.1.1. How to fix</h5></div></div></div>
<p>
These instructions are meant as a reference only; they likely need to be adapted
for many packages individually.
@@ -11493,7 +11493,7 @@ MAKE_FLAGS+= LOCAL_LDFLAGS=${LDFLAGS:Q}
</div>
<div class="sect3">
<div class="titlepage"><div><div><h4 class="title">
-<a name="hardening.caveats.pie.crash"></a>B.2.1.2.�Run-time crashes</h4></div></div></div>
+<a name="hardening.caveats.pie.crash"></a>B.2.1.2. Run-time crashes</h4></div></div></div>
<p>
Some programs may fail to run, or crash at random times once built as PIE. Two
scenarios are essentially possible. This is nearly always due to a bug in
@@ -11502,7 +11502,7 @@ the program being exposed due to ASLR.
</div>
<div class="sect3">
<div class="titlepage"><div><div><h4 class="title">
-<a name="hardening.caveats.pie.disable"></a>B.2.1.3.�Disabling PKGSRC_MKPIE on a per-package basis</h4></div></div></div>
+<a name="hardening.caveats.pie.disable"></a>B.2.1.3. Disabling PKGSRC_MKPIE on a per-package basis</h4></div></div></div>
<p>
Ideally, packages should be fixed for compatibility with MKPIE.
However, in some cases this is very difficult, due to complex build systems,
@@ -11518,10 +11518,10 @@ To disable <code class="varname">PKGSRC_
</div>
<div class="sect2">
<div class="titlepage"><div><div><h3 class="title">
-<a name="hardening.caveats.fortify"></a>B.2.2.�Problems with PKGSRC_USE_FORTIFY</h3></div></div></div>
+<a name="hardening.caveats.fortify"></a>B.2.2. Problems with PKGSRC_USE_FORTIFY</h3></div></div></div>
<div class="sect3">
<div class="titlepage"><div><div><h4 class="title">
-<a name="hardening.caveats.fortify.build"></a>B.2.2.1.�Packages failing to build</h4></div></div></div>
+<a name="hardening.caveats.fortify.build"></a>B.2.2.1. Packages failing to build</h4></div></div></div>
<p>
This feature makes use of pre-processing directives to look for hardened,
alternative implementations of essential library calls. Some programs may fail
@@ -11531,7 +11531,7 @@ portable, or otherwise abusing definitio
</div>
<div class="sect3">
<div class="titlepage"><div><div><h4 class="title">
-<a name="hardening.caveats.fortify.crash"></a>B.2.2.2.�Run-time crashes</h4></div></div></div>
+<a name="hardening.caveats.fortify.crash"></a>B.2.2.2. Run-time crashes</h4></div></div></div>
<p>
This feature may cause some programs to crash, usually indicating an
actual bug in the program. The fix will typically involve patching the
@@ -11540,7 +11540,7 @@ original program's source code.
</div>
<div class="sect3">
<div class="titlepage"><div><div><h4 class="title">
-<a name="hardening.caveats.fortify.opt"></a>B.2.2.3.�Optimization is required</h4></div></div></div>
+<a name="hardening.caveats.fortify.opt"></a>B.2.2.3. Optimization is required</h4></div></div></div>
<p>
At least in the case of GCC, FORTIFY will only be applied if optimization is
applied while compiling. This means that the <code class="varname">CFLAGS</code> should
@@ -11551,7 +11551,7 @@ may require specific optimization levels
</div>
<div class="sect3">
<div class="titlepage"><div><div><h4 class="title">
-<a name="hardening.caveats.fortify.disable"></a>B.2.2.4.�Disabling FORTIFY on a per-package basis</h4></div></div></div>
+<a name="hardening.caveats.fortify.disable"></a>B.2.2.4. Disabling FORTIFY on a per-package basis</h4></div></div></div>
<div class="note" style="margin-left: 0.5in; margin-right: 0.5in;">
<h3 class="title">Note</h3>
<p>FORTIFY should not be disabled to work around runtime crashes in
@@ -11571,10 +11571,10 @@ FORTIFY_SUPPORTED= no
</div>
<div class="sect2">
<div class="titlepage"><div><div><h3 class="title">
-<a name="hardening.caveats.relro"></a>B.2.3.�Problems with PKGSRC_USE_RELRO</h3></div></div></div>
+<a name="hardening.caveats.relro"></a>B.2.3. Problems with PKGSRC_USE_RELRO</h3></div></div></div>
<div class="sect3">
<div class="titlepage"><div><div><h4 class="title">
-<a name="hardening.caveats.relro.performance"></a>B.2.3.1.�Performance impact</h4></div></div></div>
+<a name="hardening.caveats.relro.performance"></a>B.2.3.1. Performance impact</h4></div></div></div>
<p>
For better protection, full RELRO requires every symbol to be resolved when the
program starts, rather than simply when required at run-time. This will have
@@ -11590,7 +11590,7 @@ cases for big programs.
</div>
<div class="sect3">
<div class="titlepage"><div><div><h4 class="title">
-<a name="hardening.caveats.relro.crash"></a>B.2.3.2.�Run-time crashes</h4></div></div></div>
+<a name="hardening.caveats.relro.crash"></a>B.2.3.2. Run-time crashes</h4></div></div></div>
<p>
Some programs handle plug-ins and dependencies in a way that conflicts with
RELRO: for instance, with an initialization routine listing any other plug-in
@@ -11602,7 +11602,7 @@ drivers. Partial RELRO can be applied in
</div>
<div class="sect3">
<div class="titlepage"><div><div><h4 class="title">
-<a name="hardening.caveats.relro.disable"></a>B.2.3.3.�Disabling RELRO on a per-package basis</h4></div></div></div>
+<a name="hardening.caveats.relro.disable"></a>B.2.3.3. Disabling RELRO on a per-package basis</h4></div></div></div>
<p>
To disable RELRO on a per-package basis, set the following
in the package's <code class="filename">Makefile</code>
@@ -11619,10 +11619,10 @@ setting <code class="varname">RELRO_SUPP
</div>
<div class="sect2">
<div class="titlepage"><div><div><h3 class="title">
-<a name="hardening.caveats.ssp"></a>B.2.4.�Problems with PKGSRC_USE_SSP</h3></div></div></div>
+<a name="hardening.caveats.ssp"></a>B.2.4. Problems with PKGSRC_USE_SSP</h3></div></div></div>
<div class="sect3">
<div class="titlepage"><div><div><h4 class="title">
-<a name="hardening.caveats.ssp.build"></a>B.2.4.1.�Packages failing to build</h4></div></div></div>
+<a name="hardening.caveats.ssp.build"></a>B.2.4.1. Packages failing to build</h4></div></div></div>
<p>
The stack-smashing protection provided by this option does not work for some
programs. The most common situation in which this happens is when the program
@@ -11631,7 +11631,7 @@ allocates variables on the stack, with t
</div>
<div class="sect3">
<div class="titlepage"><div><div><h4 class="title">
-<a name="hardening.caveats.ssp.crash"></a>B.2.4.2.�Run-time crashes</h4></div></div></div>
+<a name="hardening.caveats.ssp.crash"></a>B.2.4.2. Run-time crashes</h4></div></div></div>
<p>
Again, this feature may cause some programs to crash via a
<code class="varname">SIGABRT</code>, usually indicating an actual bug in the program.
@@ -11665,7 +11665,7 @@ calling the _chk() (SSP) function.
</div>
<div class="sect3">
<div class="titlepage"><div><div><h4 class="title">
-<a name="hardening.caveats.ssp.performance"></a>B.2.4.3.�Performance impact</h4></div></div></div>
+<a name="hardening.caveats.ssp.performance"></a>B.2.4.3. Performance impact</h4></div></div></div>
<p>
The compiler emits extra code when using this feature: a check for buffer
overflows is performed when entering and exiting functions, requiring an extra
@@ -11681,7 +11681,7 @@ avoid using this feature, or using libra
</div>
<div class="sect3">
<div class="titlepage"><div><div><h4 class="title">
-<a name="hardening.caveats.ssp.disable"></a>B.2.4.4.�Disabling SSP on a per-package basis</h4></div></div></div>
+<a name="hardening.caveats.ssp.disable"></a>B.2.4.4. Disabling SSP on a per-package basis</h4></div></div></div>
<div class="note" style="margin-left: 0.5in; margin-right: 0.5in;">
<h3 class="title">Note</h3>
<p>SSP should not be disabled to work around runtime crashes in
@@ -11701,7 +11701,7 @@ SSP_SUPPORTED= no
</div>
<div class="sect1">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="hardening.audit"></a>B.3.�Auditing the system</h2></div></div></div>
+<a name="hardening.audit"></a>B.3. Auditing the system</h2></div></div></div>
<p>
The illusion of security is worse than having no security at all. This section
lists a number of ways to ensure the security features requested are actually
@@ -11713,7 +11713,7 @@ These instructions were obtained and tes
</p>
<div class="sect2">
<div class="titlepage"><div><div><h3 class="title">
-<a name="hardening.audit.pie"></a>B.3.1.�Checking for PIE</h3></div></div></div>
+<a name="hardening.audit.pie"></a>B.3.1. Checking for PIE</h3></div></div></div>
<p>
The ELF executable type in use changes for binaries built as PIE; without:
</p>
@@ -11732,7 +11732,7 @@ The latter result is then what is expect
</div>
<div class="sect2">
<div class="titlepage"><div><div><h3 class="title">
-<a name="hardening.audit.relropartial"></a>B.3.2.�Checking for partial RELRO</h3></div></div></div>
+<a name="hardening.audit.relropartial"></a>B.3.2. Checking for partial RELRO</h3></div></div></div>
<p>
The following command should list a section called RELRO:
</p>
@@ -11752,7 +11752,7 @@ This check is now performed automaticall
</div>
<div class="sect2">
<div class="titlepage"><div><div><h3 class="title">
-<a name="hardening.audit.relrofull"></a>B.3.3.�Checking for full RELRO</h3></div></div></div>
+<a name="hardening.audit.relrofull"></a>B.3.3. Checking for full RELRO</h3></div></div></div>
<p>
The dynamic loader will apply RELRO immediately when detecting the presence of
the <code class="varname">BIND_NOW</code> flag:
@@ -11776,7 +11776,7 @@ This check is now performed automaticall
</div>
<div class="sect2">
<div class="titlepage"><div><div><h3 class="title">
-<a name="hardening.audit.ssp"></a>B.3.4.�Checking for SSP</h3></div></div></div>
+<a name="hardening.audit.ssp"></a>B.3.4. Checking for SSP</h3></div></div></div>
<div class="note" style="margin-left: 0.5in; margin-right: 0.5in;">
<h3 class="title">Note</h3>
<p>
@@ -11807,7 +11807,7 @@ This check is now performed automaticall
</div>
<div class="appendix">
<div class="titlepage"><div><div><h1 class="title">
-<a name="logs"></a>Appendix�C.�Build logs</h1></div></div></div>
+<a name="logs"></a>Appendix C. Build logs</h1></div></div></div>
<div class="toc">
<p><b>Table of Contents</b></p>
<dl class="toc">
@@ -11817,7 +11817,7 @@ This check is now performed automaticall
</div>
<div class="sect1">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="logs.building"></a>C.1.�Building figlet</h2></div></div></div>
+<a name="logs.building"></a>C.1. Building figlet</h2></div></div></div>
<pre class="screen"><code class="prompt">#</code> <strong class="userinput"><code>make</code></strong>
===> Checking for vulnerabilities in figlet-2.2.1nb2
=> figlet221.tar.gz doesn't seem to exist on this system.
@@ -11909,7 +11909,7 @@ cp figlet.6 /usr/pkg/man/man6
</div>
<div class="sect1">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="logs.package"></a>C.2.�Packaging figlet</h2></div></div></div>
+<a name="logs.package"></a>C.2. Packaging figlet</h2></div></div></div>
<pre class="screen"><code class="prompt">#</code> <strong class="userinput"><code>make package</code></strong>
===> Checking for vulnerabilities in figlet-2.2.1nb2
===> Packaging figlet-2.2.1nb2
@@ -11922,7 +11922,7 @@ Registering depends:.
</div>
<div class="appendix">
<div class="titlepage"><div><div><h1 class="title">
-<a name="ftp-layout"></a>Appendix�D.�Directory layout of the pkgsrc FTP server</h1></div></div></div>
+<a name="ftp-layout"></a>Appendix D. Directory layout of the pkgsrc FTP server</h1></div></div></div>
<div class="toc">
<p><b>Table of Contents</b></p>
<dl class="toc">
@@ -11946,7 +11946,7 @@ source packages</a></span></dt>
explained below.</p>
<div class="sect1">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="ftp-distfiles"></a>D.1.�<code class="filename">distfiles</code>: The distributed source files</h2></div></div></div>
+<a name="ftp-distfiles"></a>D.1. <code class="filename">distfiles</code>: The distributed source files</h2></div></div></div>
<p>The directory <code class="filename">distfiles</code> contains lots
of archive files from all pkgsrc packages, which are mirrored
here. The subdirectories are called after their package names
@@ -11956,13 +11956,13 @@ source packages</a></span></dt>
</div>
<div class="sect1">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="ftp-misc"></a>D.2.�<code class="filename">misc</code>: Miscellaneous things</h2></div></div></div>
+<a name="ftp-misc"></a>D.2. <code class="filename">misc</code>: Miscellaneous things</h2></div></div></div>
<p>This directory contains things that individual pkgsrc
developers find worth publishing.</p>
</div>
<div class="sect1">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="ftp-packages"></a>D.3.�<code class="filename">packages</code>: Binary packages</h2></div></div></div>
+<a name="ftp-packages"></a>D.3. <code class="filename">packages</code>: Binary packages</h2></div></div></div>
<p>This directory contains binary packages for the various
platforms that are supported by pkgsrc.
Each subdirectory is of the form <em class="replaceable"><code>OPSYS</code></em>/<em class="replaceable"><code>ARCH</code></em>/<em class="replaceable"><code>OSVERSION_TAG</code></em>. The
meaning of these variables is:</p>
@@ -12000,18 +12000,18 @@ source packages</a></span></dt>
</div>
<div class="sect1">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="ftp-reports"></a>D.4.�<code class="filename">reports</code>: Bulk build reports</h2></div></div></div>
+<a name="ftp-reports"></a>D.4. <code class="filename">reports</code>: Bulk build reports</h2></div></div></div>
<p>Here are the reports from bulk builds, for those who want
to fix packages that didn't build on some of the platforms. The
- structure of subdirectories should look like the one in <a class="xref" href="#ftp-packages" title="D.3.�packages: Binary packages">Section�D.3, “<code class="filename">packages</code>:
Binary packages”</a>.</p>
+ structure of subdirectories should look like the one in <a class="xref" href="#ftp-packages" title="D.3. packages: Binary packages">Section D.3, “<code class="filename">packages</code>:
Binary packages”</a>.</p>
</div>
<div class="sect1">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="ftp-source"></a>D.5.�<code class="filename">current</code>,
+<a name="ftp-source"></a>D.5. <code class="filename">current</code>,
<code class="filename">stable</code>,
<code class="filename">pkgsrc-20<em class="replaceable"><code>xx</code></em>Q<em class="replaceable"><code>y</code></em></code>:
source packages</h2></div></div></div>
-<p>These directories contain the <span class="quote">“<span class="quote">real</span>”</span> pkgsrc,
+<p>These directories contain the <span class="quote">“<span class="quote">real</span>”</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>,
@@ -12047,7 +12047,7 @@ source packages</h2></div></div></div>
</div>
<div class="appendix">
<div class="titlepage"><div><div><h1 class="title">
-<a name="help-topics"></a>Appendix�E.�Help topics</h1></div></div></div>
+<a name="help-topics"></a>Appendix E. Help topics</h1></div></div></div>
<p>
The following list contains all help topics that are available
when running <span class="command"><strong>bmake help topic=:index</strong></span>.
@@ -12855,11 +12855,7 @@ source packages</h2></div></div></div>
</tr>
<tr>
<td>GNU_CONFIGURE_STRICT</td>
-<td>GODEP_REDIRECTS</td>
-</tr>
-<tr>
<td>GO_BUILD_PATTERN</td>
-<td>GO_DEPS</td>
</tr>
<tr>
<td>GO_DIST_BASE</td>
@@ -13807,911 +13803,915 @@ source packages</h2></div></div></div>
</tr>
<tr>
<td>PYSOABISUFFIX</td>
-<td>PYTHON_FOR_BUILD_ONLY</td>
+<td>PYTHON_27_ACCEPTED</td>
</tr>
<tr>
+<td>PYTHON_FOR_BUILD_ONLY</td>
<td>PYTHON_SELF_CONFLICT</td>
-<td>PYTHON_VERSION</td>
</tr>
<tr>
+<td>PYTHON_VERSION</td>
<td>PYTHON_VERSIONED_DEPENDENCIES</td>
-<td>PYTHON_VERSIONS_ACCEPTED</td>
</tr>
<tr>
+<td>PYTHON_VERSIONS_ACCEPTED</td>
<td>PYTHON_VERSIONS_INCOMPATIBLE</td>
-<td>PYTHON_VERSION_DEFAULT</td>
</tr>
<tr>
+<td>PYTHON_VERSION_DEFAULT</td>
<td>PYTHON_VERSION_REQD</td>
-<td>PYVERSSUFFIX</td>
</tr>
<tr>
+<td>PYVERSSUFFIX</td>
<td>QMAILDIR</td>
-<td>QMAIL_ALIAS_USER</td>
</tr>
<tr>
+<td>QMAIL_ALIAS_USER</td>
<td>QMAIL_DAEMON_USER</td>
-<td>QMAIL_LOG_USER</td>
</tr>
<tr>
+<td>QMAIL_LOG_USER</td>
<td>QMAIL_NOFILES_GROUP</td>
-<td>QMAIL_PASSWD_USER</td>
</tr>
<tr>
+<td>QMAIL_PASSWD_USER</td>
<td>QMAIL_QMAIL_GROUP</td>
-<td>QMAIL_QUEUE_DIR</td>
</tr>
<tr>
+<td>QMAIL_QUEUE_DIR</td>
<td>QMAIL_QUEUE_EXTRA</td>
-<td>QMAIL_QUEUE_USER</td>
</tr>
<tr>
+<td>QMAIL_QUEUE_USER</td>
<td>QMAIL_REMOTE_USER</td>
-<td>QMAIL_ROOT_USER</td>
</tr>
<tr>
+<td>QMAIL_ROOT_USER</td>
<td>QMAIL_SEND_USER</td>
-<td>QORE_LATEST_MODULE_API</td>
</tr>
<tr>
+<td>QORE_LATEST_MODULE_API</td>
<td>QORE_MODULE_API</td>
-<td>QORE_MODULE_DIR</td>
</tr>
<tr>
+<td>QORE_MODULE_DIR</td>
<td>QORE_USER_MODULE_DIR</td>
-<td>QORE_VERSION</td>
</tr>
<tr>
+<td>QORE_VERSION</td>
<td>QPOPPER_FAC</td>
-<td>QPOPPER_SPOOL_DIR</td>
</tr>
<tr>
+<td>QPOPPER_SPOOL_DIR</td>
<td>QPOPPER_USER</td>
-<td>RAKE_NAME</td>
</tr>
<tr>
+<td>RAKE_NAME</td>
<td>RASMOL_DEPTH</td>
-<td>RCD_DIR</td>
</tr>
<tr>
+<td>RCD_DIR</td>
<td>RCD_ORDER</td>
-<td>RCD_SCRIPTS</td>
</tr>
<tr>
+<td>RCD_SCRIPTS</td>
<td>RCD_SCRIPTS_DIR</td>
-<td>RCD_SCRIPTS_EXAMPLEDIR</td>
</tr>
<tr>
+<td>RCD_SCRIPTS_EXAMPLEDIR</td>
<td>RCD_SCRIPTS_MODE</td>
-<td>RCD_SCRIPTS_SHELL</td>
</tr>
<tr>
+<td>RCD_SCRIPTS_SHELL</td>
<td>RCD_SCRIPT_SRC</td>
-<td>RCD_SUBR</td>
</tr>
<tr>
+<td>RCD_SUBR</td>
<td>RDOC</td>
-<td>READLINE_DEFAULT</td>
</tr>
<tr>
+<td>READLINE_DEFAULT</td>
<td>READLINE_TYPE</td>
-<td>REAL_ROOT_GROUP</td>
</tr>
<tr>
+<td>REAL_ROOT_GROUP</td>
<td>REAL_ROOT_USER</td>
-<td>RECURSIVE_MAKE</td>
</tr>
<tr>
+<td>RECURSIVE_MAKE</td>
<td>RELAY_CTRL_DIR</td>
-<td>RELRO_SUPPORTED</td>
</tr>
<tr>
+<td>RELRO_SUPPORTED</td>
<td>REPLACE_AWK</td>
-<td>REPLACE_BASH</td>
</tr>
<tr>
+<td>REPLACE_BASH</td>
<td>REPLACE_CSH</td>
-<td>REPLACE_KSH</td>
</tr>
<tr>
+<td>REPLACE_KSH</td>
<td>REPLACE_LUA</td>
-<td>REPLACE_NODEJS</td>
</tr>
<tr>
+<td>REPLACE_NODEJS</td>
<td>REPLACE_OCTAVE</td>
-<td>REPLACE_PERL</td>
</tr>
<tr>
+<td>REPLACE_PERL</td>
<td>REPLACE_PERL6</td>
-<td>REPLACE_PHP</td>
</tr>
<tr>
+<td>REPLACE_PHP</td>
<td>REPLACE_PYTHON</td>
-<td>REPLACE_QORE</td>
</tr>
<tr>
+<td>REPLACE_QORE</td>
<td>REPLACE_R</td>
-<td>REPLACE_RUBY</td>
</tr>
<tr>
+<td>REPLACE_RUBY</td>
<td>REPLACE_RUBY_DIRS</td>
-<td>REPLACE_RUBY_PAT</td>
</tr>
<tr>
+<td>REPLACE_RUBY_PAT</td>
<td>REPLACE_SH</td>
-<td>REPLACE_TEXLUA</td>
</tr>
<tr>
+<td>REPLACE_TEXLUA</td>
<td>REPLACE_TOOL_PYTHON</td>
-<td>REPLACE_WISH</td>
</tr>
<tr>
+<td>REPLACE_WISH</td>
<td>REQD_DIRS</td>
-<td>REQD_DIRS_PERMS</td>
</tr>
<tr>
+<td>REQD_DIRS_PERMS</td>
<td>REQD_FILES</td>
-<td>REQD_FILES_MODE</td>
</tr>
<tr>
+<td>REQD_FILES_MODE</td>
<td>REQD_FILES_PERMS</td>
-<td>RESOLV_AUTO_VARS</td>
</tr>
<tr>
+<td>RESOLV_AUTO_VARS</td>
<td>RESOLV_LDFLAGS</td>
-<td>RESOLV_LIBS</td>
</tr>
<tr>
+<td>RESOLV_LIBS</td>
<td>RM</td>
-<td>ROCKSPEC_NAME</td>
</tr>
<tr>
+<td>ROCKSPEC_NAME</td>
<td>ROCKSPEC_SPECFILE</td>
-<td>ROOT_CMD</td>
</tr>
<tr>
+<td>ROOT_CMD</td>
<td>ROOT_GROUP</td>
-<td>ROOT_USER</td>
</tr>
<tr>
+<td>ROOT_USER</td>
<td>RPCGEN</td>
-<td>RPM</td>
</tr>
<tr>
+<td>RPM</td>
<td>RPM2PKG_PLIST</td>
-<td>RPM2PKG_PREFIX</td>
</tr>
<tr>
+<td>RPM2PKG_PREFIX</td>
<td>RPM2PKG_STAGE</td>
-<td>RPM2PKG_STRIP</td>
</tr>
<tr>
+<td>RPM2PKG_STRIP</td>
<td>RPM2PKG_SUBPREFIX</td>
-<td>RPMFILES</td>
</tr>
<tr>
+<td>RPMFILES</td>
<td>RPMIGNOREPATH</td>
-<td>RPM_DB_PREFIX</td>
</tr>
<tr>
+<td>RPM_DB_PREFIX</td>
<td>RSSH_CVS_PATH</td>
-<td>RSSH_RDIST_PATH</td>
</tr>
<tr>
+<td>RSSH_RDIST_PATH</td>
<td>RSSH_RSYNC_PATH</td>
-<td>RSSH_SCP_PATH</td>
</tr>
<tr>
+<td>RSSH_SCP_PATH</td>
<td>RSSH_SFTP_SERVER_PATH</td>
-<td>RUBY</td>
</tr>
<tr>
+<td>RUBY</td>
<td>RUBYGEM</td>
-<td>RUBYGEM_MANPAGES</td>
</tr>
<tr>
+<td>RUBYGEM_MANPAGES</td>
<td>RUBYGEM_NAME</td>
-<td>RUBYGEM_OPTIONS</td>
</tr>
<tr>
+<td>RUBYGEM_OPTIONS</td>
<td>RUBYGEM_USE_MANPAGES</td>
-<td>RUBYGEM_VERBOSE</td>
</tr>
<tr>
+<td>RUBYGEM_VERBOSE</td>
<td>RUBY_ABI_VERSION</td>
-<td>RUBY_ARCH</td>
</tr>
<tr>
+<td>RUBY_ARCH</td>
<td>RUBY_ARCHINC</td>
-<td>RUBY_ARCHLIB</td>
</tr>
<tr>
+<td>RUBY_ARCHLIB</td>
<td>RUBY_BASE</td>
-<td>RUBY_BASERIDIR</td>
</tr>
<tr>
+<td>RUBY_BASERIDIR</td>
<td>RUBY_BUILD_DOCUMENT</td>
-<td>RUBY_DLEXT</td>
</tr>
<tr>
+<td>RUBY_DLEXT</td>
<td>RUBY_DOC</td>
-<td>RUBY_DYNAMIC_DIRS</td>
</tr>
<tr>
+<td>RUBY_DYNAMIC_DIRS</td>
<td>RUBY_EG</td>
-<td>RUBY_ENCODING_ARG</td>
</tr>
<tr>
+<td>RUBY_ENCODING_ARG</td>
<td>RUBY_EXTCONF</td>
-<td>RUBY_EXTCONF_CHECK</td>
</tr>
<tr>
+<td>RUBY_EXTCONF_CHECK</td>
<td>RUBY_EXTCONF_DEBUG</td>
-<td>RUBY_EXTCONF_MAKEFILE</td>
</tr>
<tr>
+<td>RUBY_EXTCONF_MAKEFILE</td>
<td>RUBY_GEM_ARCH</td>
-<td>RUBY_GEM_BASE</td>
</tr>
<tr>
+<td>RUBY_GEM_BASE</td>
<td>RUBY_INC</td>
-<td>RUBY_LIB</td>
</tr>
<tr>
+<td>RUBY_LIB</td>
<td>RUBY_LIB_BASE</td>
-<td>RUBY_NAME</td>
</tr>
<tr>
+<td>RUBY_NAME</td>
<td>RUBY_NOVERSION</td>
-<td>RUBY_PKGPREFIX</td>
</tr>
<tr>
+<td>RUBY_PKGPREFIX</td>
<td>RUBY_RAILS</td>
-<td>RUBY_RAILS61_VERSION</td>
</tr>
<tr>
+<td>RUBY_RAILS61_VERSION</td>
<td>RUBY_RAILS70_VERSION</td>
-<td>RUBY_RAILS71_VERSION</td>
</tr>
<tr>
+<td>RUBY_RAILS71_VERSION</td>
<td>RUBY_RAILS72_VERSION</td>
-<td>RUBY_RAILS80_VERSION</td>
</tr>
<tr>
+<td>RUBY_RAILS80_VERSION</td>
<td>RUBY_RAILS_ACCEPTED</td>
-<td>RUBY_RAILS_DEFAULT</td>
</tr>
<tr>
+<td>RUBY_RAILS_DEFAULT</td>
<td>RUBY_RAILS_REQD</td>
-<td>RUBY_RAILS_STRICT_DEP</td>
</tr>
<tr>
+<td>RUBY_RAILS_STRICT_DEP</td>
<td>RUBY_RIDIR</td>
-<td>RUBY_SETUP</td>
</tr>
<tr>
+<td>RUBY_SETUP</td>
<td>RUBY_SHLIB</td>
-<td>RUBY_SHLIBALIAS</td>
</tr>
<tr>
+<td>RUBY_SHLIBALIAS</td>
<td>RUBY_SHLIBVER</td>
-<td>RUBY_SIMPLE_INSTALL</td>
</tr>
<tr>
+<td>RUBY_SIMPLE_INSTALL</td>
<td>RUBY_SITEARCHLIB</td>
-<td>RUBY_SITELIB</td>
</tr>
<tr>
+<td>RUBY_SITELIB</td>
<td>RUBY_SITELIB_BASE</td>
-<td>RUBY_SITERIDIR</td>
</tr>
<tr>
+<td>RUBY_SITERIDIR</td>
<td>RUBY_SLEXT</td>
-<td>RUBY_SRCDIR</td>
</tr>
<tr>
+<td>RUBY_SRCDIR</td>
<td>RUBY_STATICLIB</td>
-<td>RUBY_SUFFIX</td>
</tr>
<tr>
+<td>RUBY_SUFFIX</td>
<td>RUBY_SYSRIDIR</td>
-<td>RUBY_USE_PTHREAD</td>
</tr>
<tr>
+<td>RUBY_USE_PTHREAD</td>
<td>RUBY_VENDORARCHLIB</td>
-<td>RUBY_VENDORLIB</td>
</tr>
<tr>
+<td>RUBY_VENDORLIB</td>
<td>RUBY_VENDORLIB_BASE</td>
-<td>RUBY_VER</td>
</tr>
<tr>
+<td>RUBY_VER</td>
<td>RUBY_VERSION</td>
-<td>RUBY_VERSIONS_ACCEPTED</td>
</tr>
<tr>
+<td>RUBY_VERSIONS_ACCEPTED</td>
<td>RUBY_VERSIONS_INCOMPATIBLE</td>
-<td>RUBY_VERSION_DEFAULT</td>
</tr>
<tr>
+<td>RUBY_VERSION_DEFAULT</td>
<td>RUBY_VERSION_REQD</td>
-<td>RUBY_VER_DIR</td>
</tr>
<tr>
+<td>RUBY_VER_DIR</td>
<td>RUN</td>
-<td>RUN_LDCONFIG</td>
</tr>
<tr>
+<td>RUN_LDCONFIG</td>
<td>RUST_TYPE</td>
-<td>SCO</td>
</tr>
<tr>
+<td>SCO</td>
<td>SCREWS_GROUP</td>
-<td>SCREWS_USER</td>
</tr>
<tr>
+<td>SCREWS_USER</td>
<td>SCRIPTS_ENV</td>
-<td>SCROLLKEEPER_DATADIR</td>
</tr>
<tr>
+<td>SCROLLKEEPER_DATADIR</td>
<td>SCROLLKEEPER_REBUILDDB</td>
-<td>SCROLLKEEPER_UPDATEDB</td>
</tr>
<tr>
+<td>SCROLLKEEPER_UPDATEDB</td>
<td>SDIST_PAWD</td>
-<td>SDL12_TYPE</td>
</tr>
<tr>
+<td>SDL12_TYPE</td>
<td>SERIAL_DEVICES</td>
-<td>SETGIDGAME</td>
</tr>
<tr>
+<td>SETGIDGAME</td>
<td>SETGID_GAMES_PERMS</td>
-<td>SETUID_ROOT_PERMS</td>
</tr>
<tr>
+<td>SETUID_ROOT_PERMS</td>
<td>SH</td>
-<td>SHLIB_EXT</td>
</tr>
<tr>
+<td>SHAIRPORT_GROUP</td>
+<td>SHAIRPORT_USER</td>
+</tr>
+<tr>
+<td>SHLIB_EXT</td>
<td>SHORTNAME</td>
-<td>SIGN_PACKAGES</td>
</tr>
<tr>
+<td>SIGN_PACKAGES</td>
<td>SILC_CLIENT_WITH_PERL</td>
-<td>SITE_SPECIFIC_PKGS</td>
</tr>
<tr>
+<td>SITE_SPECIFIC_PKGS</td>
<td>SKIP_DEPENDS</td>
-<td>SMF_INSTANCES</td>
</tr>
<tr>
+<td>SMF_INSTANCES</td>
<td>SMF_MANIFEST</td>
-<td>SMF_METHODS</td>
</tr>
<tr>
+<td>SMF_METHODS</td>
<td>SMF_METHOD_SHELL</td>
-<td>SMF_METHOD_SRC</td>
</tr>
<tr>
+<td>SMF_METHOD_SRC</td>
<td>SMF_NAME</td>
-<td>SMF_PREFIX</td>
</tr>
<tr>
+<td>SMF_PREFIX</td>
<td>SMF_SRCDIR</td>
-<td>SNIPROXY_GROUP</td>
</tr>
<tr>
+<td>SNIPROXY_GROUP</td>
<td>SNIPROXY_USER</td>
-<td>SOURCE_BUFFSIZE</td>
</tr>
<tr>
+<td>SOURCE_BUFFSIZE</td>
<td>SPECIAL_PERMS</td>
-<td>SPECIFIC_PKGS</td>
</tr>
<tr>
+<td>SPECIFIC_PKGS</td>
<td>SSH_SUID</td>
-<td>SSLCERTBUNDLE</td>
</tr>
<tr>
+<td>SSLCERTBUNDLE</td>
<td>SSLCERTS</td>
-<td>SSLDIR</td>
</tr>
<tr>
+<td>SSLDIR</td>
<td>SSLKEYS</td>
-<td>SSP_SUPPORTED</td>
</tr>
<tr>
+<td>SSP_SUPPORTED</td>
<td>SSYNC_PAWD</td>
-<td>STEP_MSG</td>
</tr>
<tr>
+<td>STEP_MSG</td>
<td>STRIP</td>
-<td>STRIP_DBG</td>
</tr>
<tr>
+<td>STRIP_DBG</td>
<td>STRIP_DEBUG</td>
-<td>STRIP_DEBUG_SUPPORTED</td>
</tr>
<tr>
+<td>STRIP_DEBUG_SUPPORTED</td>
<td>STRIP_FILES_SKIP</td>
-<td>SU</td>
</tr>
<tr>
+<td>SU</td>
<td>SUBDIR</td>
-<td>SUBST</td>
</tr>
<tr>
+<td>SUBST</td>
<td>SUBST_CLASSES</td>
-<td>SUBST_FILES</td>
</tr>
<tr>
+<td>SUBST_FILES</td>
<td>SUBST_FILTER_CMD</td>
-<td>SUBST_MESSAGE</td>
</tr>
<tr>
+<td>SUBST_MESSAGE</td>
<td>SUBST_NOOP_OK</td>
-<td>SUBST_SED</td>
</tr>
<tr>
+<td>SUBST_SED</td>
<td>SUBST_SHOW_DIFF</td>
-<td>SUBST_SKIP_TEXT_CHECK</td>
</tr>
<tr>
+<td>SUBST_SKIP_TEXT_CHECK</td>
<td>SUBST_STAGE</td>
-<td>SUBST_VARS</td>
</tr>
<tr>
+<td>SUBST_VARS</td>
<td>SUNWSPROBASE</td>
-<td>SUSE_PREFER</td>
</tr>
<tr>
+<td>SUSE_PREFER</td>
<td>SU_CMD</td>
-<td>SVN_EXTRACTDIR</td>
</tr>
<tr>
+<td>SVN_EXTRACTDIR</td>
<td>SVN_REPO</td>
-<td>SVN_REPOSITORIES</td>
</tr>
<tr>
+<td>SVN_REPOSITORIES</td>
<td>SVN_REVISION</td>
-<td>SYSCONFBASE</td>
</tr>
<tr>
+<td>SYSCONFBASE</td>
<td>TARGET_MACHINE_ARCH</td>
-<td>TBL</td>
</tr>
<tr>
+<td>TBL</td>
<td>TERMCAP_TYPE</td>
-<td>TERMINFO_DEFAULT</td>
</tr>
<tr>
+<td>TERMINFO_DEFAULT</td>
<td>TERMINFO_TYPE</td>
-<td>TEST</td>
</tr>
<tr>
+<td>TEST</td>
<td>TEST_DEPENDS</td>
-<td>TEST_DIRS</td>
</tr>
<tr>
+<td>TEST_DIRS</td>
<td>TEST_ENV</td>
-<td>TEST_ENV_SHELL</td>
</tr>
<tr>
+<td>TEST_ENV_SHELL</td>
<td>TEST_MAKE_CMD</td>
-<td>TEST_MAKE_FLAGS</td>
</tr>
<tr>
+<td>TEST_MAKE_FLAGS</td>
<td>TEST_TARGET</td>
-<td>TEXLIVE_IGNORE_PATTERNS</td>
</tr>
<tr>
+<td>TEXLIVE_IGNORE_PATTERNS</td>
<td>TEXLIVE_REV</td>
-<td>TEXLIVE_UNVERSIONED</td>
</tr>
<tr>
+<td>TEXLIVE_UNVERSIONED</td>
<td>TEXMFSITE</td>
-<td>TEX_FORMATS</td>
</tr>
<tr>
+<td>TEX_FORMATS</td>
<td>TEX_HYPHEN_DAT</td>
-<td>TEX_HYPHEN_DEF</td>
</tr>
<tr>
+<td>TEX_HYPHEN_DEF</td>
<td>TEX_TEXMF_DIRS</td>
-<td>THTTPD_LOG_FACILITY</td>
</tr>
<tr>
+<td>THTTPD_LOG_FACILITY</td>
<td>TINYDYN_USER</td>
-<td>TLS</td>
</tr>
<tr>
+<td>TLS</td>
<td>TLSWRAPPER_CHROOT</td>
-<td>TO</td>
</tr>
<tr>
+<td>TO</td>
<td>TOOLDIR</td>
-<td>TOOLS_ALIASES</td>
</tr>
<tr>
+<td>TOOLS_ALIASES</td>
<td>TOOLS_ALWAYS_WRAP</td>
-<td>TOOLS_ARGS</td>
</tr>
<tr>
+<td>TOOLS_ARGS</td>
<td>TOOLS_BROKEN</td>
-<td>TOOLS_CMD</td>
</tr>
<tr>
+<td>TOOLS_CMD</td>
<td>TOOLS_CMDLINE_SED</td>
-<td>TOOLS_CREATE</td>
</tr>
<tr>
+<td>TOOLS_CREATE</td>
<td>TOOLS_CROSS_DESTDIR</td>
-<td>TOOLS_DIR</td>
</tr>
<tr>
+<td>TOOLS_DIR</td>
<td>TOOLS_FAIL</td>
-<td>TOOLS_GNU_MISSING</td>
</tr>
<tr>
+<td>TOOLS_GNU_MISSING</td>
<td>TOOLS_LDCONFIG</td>
-<td>TOOLS_NOOP</td>
</tr>
<tr>
+<td>TOOLS_NOOP</td>
<td>TOOLS_PATH</td>
-<td>TOOLS_SCRIPT</td>
</tr>
<tr>
+<td>TOOLS_SCRIPT</td>
<td>TOOLS_USE_CROSS_COMPILE</td>
-<td>TOOL_DEPENDS</td>
</tr>
<tr>
+<td>TOOL_DEPENDS</td>
<td>TTF_FONTDIR</td>
-<td>TTF_FONTS_DIR</td>
</tr>
<tr>
+<td>TTF_FONTS_DIR</td>
<td>TYPE</td>
-<td>UAC_REQD_EXECS</td>
</tr>
<tr>
+<td>UAC_REQD_EXECS</td>
<td>UCSPI_SSL_GROUP</td>
-<td>UCSPI_SSL_USER</td>
</tr>
<tr>
+<td>UCSPI_SSL_USER</td>
<td>UNBOUND_GROUP</td>
-<td>UNBOUND_LOG_FACILITY</td>
</tr>
<tr>
+<td>UNBOUND_LOG_FACILITY</td>
<td>UNBOUND_USER</td>
-<td>UNLIMIT_RESOURCES</td>
</tr>
<tr>
+<td>UNLIMIT_RESOURCES</td>
<td>UNPRIVILEGED</td>
-<td>UNPRIVILEGED_GROUP</td>
</tr>
<tr>
+<td>UNPRIVILEGED_GROUP</td>
<td>UNPRIVILEGED_GROUPS</td>
-<td>UNPRIVILEGED_USER</td>
</tr>
<tr>
+<td>UNPRIVILEGED_USER</td>
<td>UNWRAP_FILES</td>
-<td>UNWRAP_PATTERNS</td>
</tr>
<tr>
+<td>UNWRAP_PATTERNS</td>
<td>UPDATE_GEMSPEC</td>
-<td>UPDATE_TARGET</td>
</tr>
<tr>
+<td>UPDATE_TARGET</td>
<td>URI</td>
-<td>USERGROUP_PHASE</td>
</tr>
<tr>
+<td>USERGROUP_PHASE</td>
<td>USERPPP_GROUP</td>
-<td>USER_SPECIFIC_PKGS</td>
</tr>
<tr>
+<td>USER_SPECIFIC_PKGS</td>
<td>USE_ABI_DEPENDS</td>
-<td>USE_ADA_FEATURES</td>
</tr>
<tr>
+<td>USE_ADA_FEATURES</td>
<td>USE_APR</td>
-<td>USE_BSD_MAKEFILE</td>
</tr>
<tr>
+<td>USE_BSD_MAKEFILE</td>
<td>USE_BUILTIN</td>
-<td>USE_CC_FEATURES</td>
</tr>
<tr>
+<td>USE_CC_FEATURES</td>
<td>USE_CROSS_COMPILE</td>
-<td>USE_CURSES</td>
</tr>
<tr>
+<td>USE_CURSES</td>
<td>USE_CWRAPPERS</td>
-<td>USE_CXX_FEATURES</td>
</tr>
<tr>
+<td>USE_CXX_FEATURES</td>
<td>USE_DB185</td>
-<td>USE_FEATURES</td>
</tr>
<tr>
+<td>USE_FEATURES</td>
<td>USE_GAMESGROUP</td>
-<td>USE_GCC_RUNTIME</td>
</tr>
<tr>
+<td>USE_GCC_RUNTIME</td>
<td>USE_IMAKE</td>
-<td>USE_INDIRECT_DEPENDS</td>
</tr>
<tr>
+<td>USE_INDIRECT_DEPENDS</td>
<td>USE_JAVA</td>
-<td>USE_JAVA2</td>
</tr>
<tr>
+<td>USE_JAVA2</td>
<td>USE_LANGUAGES</td>
-<td>USE_LIBTOOL</td>
</tr>
<tr>
+<td>USE_LIBTOOL</td>
<td>USE_NATIVE_GCC</td>
-<td>USE_NETBSD_REPO</td>
</tr>
<tr>
+<td>USE_NETBSD_REPO</td>
<td>USE_PKGSRC_GCC</td>
-<td>USE_PKGSRC_GCC_RUNTIME</td>
</tr>
<tr>
+<td>USE_PKGSRC_GCC_RUNTIME</td>
<td>USE_PKGTASKS</td>
-<td>USE_PKG_ADMIN_DIGEST</td>
</tr>
<tr>
+<td>USE_PKG_ADMIN_DIGEST</td>
<td>USE_RUBY_EXTCONF</td>
-<td>USE_RUBY_INSTALL</td>
</tr>
<tr>
+<td>USE_RUBY_INSTALL</td>
<td>USE_RUBY_SETUP</td>
-<td>USE_RUBY_SETUP_PKG</td>
</tr>
<tr>
+<td>USE_RUBY_SETUP_PKG</td>
<td>USE_TMPFILES</td>
-<td>USE_TOOLS</td>
</tr>
<tr>
+<td>USE_TOOLS</td>
<td>UUCP_GROUP</td>
-<td>UUCP_USER</td>
</tr>
<tr>
+<td>UUCP_USER</td>
<td>VARBASE</td>
-<td>VARNAME</td>
</tr>
<tr>
+<td>VARNAME</td>
<td>VIM_EXTRA_OPTS</td>
-<td>WARNING_MSG</td>
</tr>
<tr>
+<td>WARNING_MSG</td>
<td>WCALC_CGIDIR</td>
-<td>WCALC_CGIPATH</td>
</tr>
<tr>
+<td>WCALC_CGIPATH</td>
<td>WCALC_HTMLDIR</td>
-<td>WCALC_HTMLPATH</td>
</tr>
<tr>
+<td>WCALC_HTMLPATH</td>
<td>WDM_MANAGERS</td>
-<td>WRAPPER_CC</td>
</tr>
<tr>
+<td>WRAPPER_CC</td>
<td>WRAPPER_REORDER_CMDS</td>
-<td>WRKDIR</td>
</tr>
<tr>
+<td>WRKDIR</td>
<td>WRKDIR_BASENAME</td>
-<td>WRKDIR_LOCKTYPE</td>
</tr>
<tr>
+<td>WRKDIR_LOCKTYPE</td>
<td>WRKLOG</td>
-<td>WRKOBJDIR</td>
</tr>
<tr>
+<td>WRKOBJDIR</td>
<td>WRKSRC</td>
-<td>X10_PORT</td>
</tr>
<tr>
+<td>X10_PORT</td>
<td>X11</td>
-<td>X11BASE</td>
</tr>
<tr>
+<td>X11BASE</td>
<td>X11_PKGSRCDIR</td>
-<td>X11_TYPE</td>
</tr>
<tr>
+<td>X11_TYPE</td>
<td>X509_CERTIFICATE</td>
-<td>X509_KEY</td>
</tr>
<tr>
+<td>X509_KEY</td>
<td>XAW_TYPE</td>
-<td>XLOCK_DEFAULT_MODE</td>
</tr>
<tr>
+<td>XLOCK_DEFAULT_MODE</td>
<td>XMKMF</td>
-<td>XMKMF_FLAGS</td>
</tr>
<tr>
+<td>XMKMF_FLAGS</td>
<td>XXX</td>
-<td>XXXX</td>
</tr>
<tr>
+<td>XXXX</td>
<td>YES</td>
-<td>ZSH_STATIC</td>
</tr>
<tr>
+<td>ZSH_STATIC</td>
<td>__stdc__</td>
-<td>_vargroups</td>
</tr>
<tr>
+<td>_vargroups</td>
<td>accept</td>
-<td>acquire-localbase-lock</td>
</tr>
<tr>
+<td>acquire-localbase-lock</td>
<td>acquire-lock</td>
-<td>add</td>
</tr>
<tr>
+<td>add</td>
<td>added</td>
-<td>administrator</td>
</tr>
<tr>
+<td>administrator</td>
<td>alloca</td>
-<td>alternatives</td>
</tr>
<tr>
+<td>alternatives</td>
<td>aslr</td>
-<td>asprintf</td>
</tr>
<tr>
+<td>asprintf</td>
<td>atlas</td>
-<td>autoconf</td>
</tr>
<tr>
+<td>autoconf</td>
<td>automake</td>
-<td>autoreconf</td>
</tr>
<tr>
+<td>autoreconf</td>
<td>awk</td>
-<td>barrier</td>
</tr>
<tr>
+<td>barrier</td>
<td>bash</td>
-<td>big-endian</td>
</tr>
<tr>
+<td>big-endian</td>
<td>bin-install</td>
-<td>bind</td>
</tr>
<tr>
+<td>bind</td>
<td>binpkg-list</td>
-<td>blas</td>
</tr>
<tr>
+<td>blas</td>
<td>bootstrap-depends</td>
-<td>broken</td>
</tr>
<tr>
+<td>broken</td>
<td>broken_on_platform</td>
-<td>bsd</td>
</tr>
<tr>
+<td>bsd</td>
<td>bsd.prog.mk</td>
-<td>build</td>
</tr>
<tr>
+<td>build</td>
<td>build-env</td>
-<td>buildlink-directories</td>
</tr>
<tr>
+<td>buildlink-directories</td>
<td>buildlink-oss-soundcard-h</td>
-<td>built-in</td>
</tr>
<tr>
+<td>built-in</td>
<td>builtin</td>
-<td>c</td>
</tr>
<tr>
+<td>c</td>
<td>c++</td>
-<td>ccache</td>
</tr>
<tr>
+<td>ccache</td>
<td>cce</td>
-<td>cdefs</td>
</tr>
<tr>
+<td>cdefs</td>
<td>ceil</td>
-<td>changes</td>
</tr>
<tr>
+<td>changes</td>
<td>changes-entry</td>
-<td>changes-entry-noupdate</td>
</tr>
<tr>
+<td>changes-entry-noupdate</td>
<td>check</td>
-<td>check-clean</td>
</tr>
<tr>
+<td>check-clean</td>
<td>check-files</td>
-<td>check-files-clean</td>
</tr>
<tr>
+<td>check-files-clean</td>
<td>check-hackage</td>
-<td>check-vulnerable</td>
</tr>
<tr>
+<td>check-vulnerable</td>
<td>checksum</td>
-<td>checksum-phase</td>
</tr>
<tr>
+<td>checksum-phase</td>
<td>clean</td>
-<td>clean-depends</td>
</tr>
<tr>
+<td>clean-depends</td>
<td>cleandir</td>
-<td>commit</td>
</tr>
<tr>
+<td>commit</td>
<td>commit-changes-entry</td>
-<td>compact</td>
</tr>
<tr>
+<td>compact</td>
<td>compiler</td>
-<td>conf</td>
</tr>
<tr>
+<td>conf</td>
<td>config.guess</td>
-<td>config.sub</td>
</tr>
<tr>
+<td>config.sub</td>
<td>configuration</td>
-<td>configure</td>
</tr>
<tr>
+<td>configure</td>
<td>configure-env</td>
-<td>configure-help</td>
</tr>
<tr>
+<td>configure-help</td>
<td>configure_args</td>
-<td>connect</td>
</tr>
<tr>
+<td>connect</td>
<td>cos</td>
-<td>cpe</td>
</tr>
<tr>
+<td>cpe</td>
<td>cputime</td>
-<td>create-usergroup</td>
</tr>
<tr>
+<td>create-usergroup</td>
<td>csh</td>
-<td>ctf</td>
</tr>
<tr>
+<td>ctf</td>
<td>cvs</td>
-<td>debug</td>
</tr>
<tr>
+<td>debug</td>
<td>debug-barrier</td>
-<td>declaration</td>
</tr>
<tr>
+<td>declaration</td>
<td>declare</td>
-<td>defined</td>
</tr>
<tr>
+<td>defined</td>
<td>depend</td>
-<td>dependencies</td>
</tr>
<tr>
+<td>dependencies</td>
<td>depends</td>
-<td>depends-checksum</td>
</tr>
<tr>
+<td>depends-checksum</td>
<td>depends-fetch</td>
-<td>deps</td>
</tr>
<tr>
<td>describe</td>
@@ -14846,219 +14846,215 @@ source packages</h2></div></div></div>
<td>go</td>
</tr>
<tr>
-<td>go-deps</td>
<td>golang</td>
-</tr>
-<tr>
<td>guess-license</td>
-<td>hashbang</td>
</tr>
<tr>
+<td>hashbang</td>
<td>heimdal</td>
-<td>help</td>
</tr>
<tr>
+<td>help</td>
<td>hg</td>
-<td>imake</td>
</tr>
<tr>
+<td>imake</td>
<td>in-tree</td>
-<td>increment</td>
</tr>
<tr>
+<td>increment</td>
<td>indirect</td>
-<td>inet_aton</td>
</tr>
<tr>
+<td>inet_aton</td>
<td>install</td>
-<td>install-env</td>
</tr>
<tr>
+<td>install-env</td>
<td>interp</td>
-<td>interpreter</td>
</tr>
<tr>
+<td>interpreter</td>
<td>intl</td>
-<td>ip4</td>
</tr>
<tr>
+<td>ip4</td>
<td>ip6</td>
-<td>ipv4</td>
</tr>
<tr>
+<td>ipv4</td>
<td>ipv6</td>
-<td>iso</td>
</tr>
<tr>
+<td>iso</td>
<td>kerberos</td>
-<td>krb</td>
</tr>
<tr>
+<td>krb</td>
<td>krb5</td>
-<td>ksh</td>
</tr>
<tr>
+<td>ksh</td>
<td>lapack</td>
-<td>latex</td>
</tr>
<tr>
+<td>latex</td>
<td>libiconv</td>
-<td>libintl_bindtextdomain</td>
</tr>
<tr>
+<td>libintl_bindtextdomain</td>
<td>libintl_gettext</td>
-<td>libintl_textdomain</td>
</tr>
<tr>
+<td>libintl_textdomain</td>
<td>libnbcompat</td>
-<td>libs</td>
</tr>
<tr>
+<td>libs</td>
<td>libtool</td>
-<td>licence</td>
</tr>
<tr>
+<td>licence</td>
<td>license</td>
-<td>lintl</td>
</tr>
<tr>
+<td>lintl</td>
<td>little-endian</td>
-<td>lock</td>
</tr>
<tr>
+<td>lock</td>
<td>locking</td>
-<td>lua</td>
</tr>
<tr>
+<td>lua</td>
<td>lvalue</td>
-<td>machine_endian</td>
</tr>
<tr>
+<td>machine_endian</td>
<td>make</td>
-<td>makedistinfo</td>
</tr>
<tr>
+<td>makedistinfo</td>
<td>makepatchsum</td>
-<td>makesum</td>
</tr>
<tr>
+<td>makesum</td>
<td>mdi</td>
-<td>memory</td>
</tr>
<tr>
+<td>memory</td>
<td>mercurial</td>
-<td>meta</td>
</tr>
<tr>
+<td>meta</td>
<td>meta-package</td>
-<td>meta_package</td>
</tr>
<tr>
+<td>meta_package</td>
<td>mit-krb5</td>
-<td>mk.conf</td>
</tr>
<tr>
+<td>mk.conf</td>
<td>mkl</td>
-<td>mount</td>
</tr>
<tr>
+<td>mount</td>
<td>move</td>
-<td>moved</td>
</tr>
<tr>
+<td>moved</td>
<td>mprotect</td>
-<td>mps</td>
</tr>
<tr>
+<td>mps</td>
<td>mremap</td>
-<td>native</td>
</tr>
<tr>
+<td>native</td>
<td>nb</td>
-<td>nbcompat</td>
</tr>
<tr>
+<td>nbcompat</td>
<td>netlib</td>
-<td>network</td>
</tr>
<tr>
+<td>network</td>
<td>node</td>
-<td>node.js</td>
</tr>
<tr>
+<td>node.js</td>
<td>nodejs</td>
-<td>obstack</td>
</tr>
<tr>
+<td>obstack</td>
<td>obstack_ptr_grow</td>
-<td>occurs</td>
</tr>
<tr>
+<td>occurs</td>
<td>only</td>
-<td>openblas</td>
</tr>
<tr>
+<td>openblas</td>
<td>options</td>
-<td>options.mk</td>
</tr>
<tr>
+<td>options.mk</td>
<td>order</td>
-<td>override</td>
</tr>
<tr>
+<td>override</td>
<td>override-intltool</td>
-<td>override-message-intltool</td>
</tr>
<tr>
+<td>override-message-intltool</td>
<td>package</td>
-<td>parallel</td>
</tr>
<tr>
+<td>parallel</td>
<td>path</td>
-<td>pax</td>
</tr>
<tr>
+<td>pax</td>
<td>paxctl</td>
-<td>pbulk-index</td>
</tr>
<tr>
+<td>pbulk-index</td>
<td>pc</td>
-<td>perl</td>
</tr>
<tr>
+<td>perl</td>
<td>perl5</td>
-<td>perms</td>
</tr>
<tr>
+<td>perms</td>
<td>php</td>
-<td>pkg-build-options</td>
</tr>
<tr>
+<td>pkg-build-options</td>
<td>pkg-config</td>
-<td>pkg_build_options</td>
</tr>
<tr>
+<td>pkg_build_options</td>
<td>pkgsrc</td>
-<td>platform</td>
</tr>
<tr>
+<td>platform</td>
<td>plist</td>
-<td>post-extract</td>
</tr>
<tr>
+<td>post-extract</td>
<td>post-fetch</td>
-<td>post-wrapper</td>
</tr>
<tr>
+<td>post-wrapper</td>
<td>pre-build-checks-hook</td>
-<td>pre-configure-checks-hook</td>
</tr>
<tr>
+<td>pre-configure-checks-hook</td>
<td>pre-extract</td>
-<td>pre-fetch</td>
</tr>
<tr>
-<td>print-go-deps</td>
+<td>pre-fetch</td>
<td>print-plist</td>
</tr>
<tr>
@@ -15267,13 +15263,13 @@ source packages</h2></div></div></div>
</tr>
<tr>
<td>wrkdir</td>
-<td>�</td>
+<td> </td>
</tr>
</table>
</div>
<div class="appendix">
<div class="titlepage"><div><div><h1 class="title">
-<a name="editing"></a>Appendix�F.�Editing guidelines for the pkgsrc guide</h1></div></div></div>
+<a name="editing"></a>Appendix F. Editing guidelines for the pkgsrc guide</h1></div></div></div>
<div class="toc">
<p><b>Table of Contents</b></p>
<dl class="toc">
@@ -15285,7 +15281,7 @@ source packages</h2></div></div></div>
guide itself.</p>
<div class="sect1">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="targets"></a>F.1.�Make targets</h2></div></div></div>
+<a name="targets"></a>F.1. Make targets</h2></div></div></div>
<p>The pkgsrc guide's source code is stored in
<code class="filename">pkgsrc/doc/guide/files</code>, and several files
are created from it:</p>
@@ -15301,7 +15297,7 @@ source packages</h2></div></div></div>
</div>
<div class="sect1">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="procedure"></a>F.2.�Procedure</h2></div></div></div>
+<a name="procedure"></a>F.2. Procedure</h2></div></div></div>
<p>The procedure to edit the pkgsrc guide is:</p>
<div class="procedure"><ol class="procedure" type="1">
<li class="step"><p>Make sure you have checked out the htdocs repository
Index: pkgsrc/doc/pkgsrc.txt
diff -u pkgsrc/doc/pkgsrc.txt:1.382 pkgsrc/doc/pkgsrc.txt:1.383
--- pkgsrc/doc/pkgsrc.txt:1.382 Wed Jul 2 16:30:34 2025
+++ pkgsrc/doc/pkgsrc.txt Sun Dec 21 11:17:54 2025
@@ -12,7 +12,7 @@ Hubert Feyrer
The pkgsrc Developers
-Copyright 1994-2025 The NetBSD Foundation, Inc
+Copyright 1994-2025 The NetBSD Foundation, Inc
$NetBSD: pkgsrc.xml,v 1.45 2025/04/17 22:00:11 wiz Exp $
@@ -107,16 +107,16 @@ I. The pkgsrc user's guide
10.7. How to fetch files from HTTPS sites
10.8. How do I tell make fetch to do passive FTP?
10.9. How to fetch all distfiles at once
- 10.10. What does "Don't know how to make /usr/share/tmac/tmac.andoc"
+ 10.10. What does Don't know how to make /usr/share/tmac/tmac.andoc
mean?
- 10.11. What does "Could not find bsd.own.mk" mean?
+ 10.11. What does Could not find bsd.own.mk mean?
10.12. Using 'sudo' or `priv` with pkgsrc
10.13. How do I change the location of configuration files?
10.14. Automated security checks
10.15. Why do some packages ignore my CFLAGS?
10.16. A package does not build. What shall I do?
- 10.17. What does "Makefile appears to contain unresolved cvs/rcs/???
- merge conflicts" mean?
+ 10.17. What does Makefile appears to contain unresolved cvs/rcs/???
+ merge conflicts mean?
II. The pkgsrc developer's guide
11. Getting help
12. Package components - files, directories and contents
@@ -254,7 +254,7 @@ II. The pkgsrc developer's guide
21.5.1. Compiling C and C++ code conditionally
21.5.2. How to handle compiler bugs
21.5.3. No such file or directory
- 21.5.4. Undefined reference to "..."
+ 21.5.4. Undefined reference to ...
21.5.5. Running out of memory
21.6. The install phase
21.6.1. Creating needed directories
@@ -357,7 +357,7 @@ List of Tables
12.1. Patching examples
22.1. PLIST handling for GNOME packages
-Chapter 1. What is pkgsrc?
+Chapter 1. What is pkgsrc?
Table of Contents
@@ -369,7 +369,7 @@ Table of Contents
1.3.1. Roles involved in pkgsrc
1.4. Typography
-1.1. Introduction
+1.1. Introduction
There is a lot of software freely available for Unix-based systems, which is
usually available in form of the source code. Before such software can be used,
@@ -388,12 +388,12 @@ pkgsrc currently contains several thousa
* meta-pkgs/kde4 - The K Desktop Environment
-? just to name a few.
+ just to name a few.
pkgsrc has built-in support for handling varying dependencies, such as pthreads
and X11, and extended features such as IPv6 support on a range of platforms.
-1.1.1. Why pkgsrc?
+1.1.1. Why pkgsrc?
pkgsrc provides the following key features:
@@ -427,7 +427,7 @@ pkgsrc provides the following key featur
The following principles are basic to pkgsrc:
- * "It should only work if it's right." -- That means, if a package contains
+ * It should only work if it's right. That means, if a package contains
bugs, it's better to find them and to complain about them rather than to
just install the package and hope that it works. There are numerous checks
in pkgsrc that try to find such bugs: static analysis tools (pkgtools/
@@ -435,11 +435,11 @@ The following principles are basic to pk
post-installation checks (installed files, references to shared libraries,
script interpreters).
- * "If it works, it should work everywhere" -- Like NetBSD has been ported to
+ * If it works, it should work everywhere Like NetBSD has been ported to
many hardware architectures, pkgsrc has been ported to many operating
systems. Care is taken that packages behave the same on all platforms.
-1.1.2. Supported platforms
+1.1.2. Supported platforms
pkgsrc consists of both a source distribution and a binary distribution for
these operating systems. After retrieving the required source or binaries, you
@@ -449,13 +449,13 @@ pkgsrc was derived from FreeBSD's ports
NetBSD only. Since then, pkgsrc has grown a lot, and now supports the following
platforms:
-Table 1.1. Platforms supported by pkgsrc
+Table 1.1. Platforms supported by pkgsrc
+-----------------------------------------------------------------------------+
| Platform | Date Support | Notes |
| | Added | |
|-------------------------------------+---------------+-----------------------|
-|NetBSD | Aug 1997 | |
+|NetBSD | Aug 1997 | |
|-------------------------------------+---------------+-----------------------|
|Solaris | Mar 1999 |README.Solaris |
|-------------------------------------+---------------+-----------------------|
@@ -477,7 +477,7 @@ Table 1.1. Platforms supported by pkgsrc
|Interix (Microsoft Windows Services | Mar 2004 |Removed from pkgsrc Apr|
|for Unix) | | 2025 |
|-------------------------------------+---------------+-----------------------|
-|DragonFlyBSD | Oct 2004 | |
+|DragonFlyBSD | Oct 2004 | |
|-------------------------------------+---------------+-----------------------|
|OSF/1 | Nov 2004 |README.OSF1 |
|-------------------------------------+---------------+-----------------------|
@@ -500,7 +500,7 @@ Table 1.1. Platforms supported by pkgsrc
+-----------------------------------------------------------------------------+
-1.2. Overview
+1.2. Overview
This document is divided into three parts. The first, The pkgsrc user's guide,
describes how one can use one of the packages in the Package Collection, either
@@ -513,9 +513,9 @@ how pkgsrc is implemented.
This document is available in various formats: HTML, PDF, PS, TXT.
-1.3. Terminology
+1.3. Terminology
-There has been a lot of talk about "ports", "packages", etc. so far. Here is a
+There has been a lot of talk about ports , packages , etc. so far. Here is a
description of all the terminology used within this document.
Package
@@ -527,7 +527,7 @@ Package
The NetBSD package system
- This is the former name of "pkgsrc". It is part of the NetBSD operating
+ This is the former name of pkgsrc . It is part of the NetBSD operating
system and can be bootstrapped to run on non-NetBSD operating systems as
well. It handles building (compiling), installing, and removing of
packages.
@@ -543,7 +543,7 @@ Distfile
Port
This is the term used by FreeBSD and OpenBSD people for what we call a
- package. In NetBSD terminology, "port" refers to a different architecture.
+ package. In NetBSD terminology, port refers to a different architecture.
Precompiled/binary package
@@ -552,7 +552,7 @@ Precompiled/binary package
architecture without the need to recompile. Packages are usually generated
in /usr/pkgsrc/packages; there is also an archive on ftp.NetBSD.org.
- Sometimes, this is referred to by the term "package" too, especially in the
+ Sometimes, this is referred to by the term package too, especially in the
context of precompiled packages.
Program
@@ -561,40 +561,40 @@ Program
the files in the distfile by the actions defined in the corresponding
package.
-1.3.1. Roles involved in pkgsrc
+1.3.1. Roles involved in pkgsrc
pkgsrc users
The pkgsrc users are people who use the packages provided by pkgsrc.
Typically they are system administrators. The people using the software
- that is inside the packages (maybe called "end users") are not covered by
+ that is inside the packages (maybe called end users ) are not covered by
the pkgsrc guide.
There are two kinds of pkgsrc users: Some only want to install pre-built
binary packages. Others build the pkgsrc packages from source, either for
installing them directly or for building binary packages themselves. For
- pkgsrc users Part I, "The pkgsrc user's guide" should provide all necessary
+ pkgsrc users Part I, The pkgsrc user's guide should provide all necessary
documentation.
package maintainers
- A package maintainer creates packages as described in Part II, "The pkgsrc
- developer's guide".
+ A package maintainer creates packages as described in Part II, The pkgsrc
+ developer's guide .
infrastructure developers
These people are involved in all those files that live in the mk/ directory
- and below. Only these people should need to read through Part III, "The
- pkgsrc infrastructure internals", though others might be curious, too.
+ and below. Only these people should need to read through Part III, The
+ pkgsrc infrastructure internals , though others might be curious, too.
-1.4. Typography
+1.4. Typography
When giving examples for commands, shell prompts are used to show if the
-command should/can be issued as root, or if "normal" user privileges are
+command should/can be issued as root, or if normal user privileges are
sufficient. We use a # for root's shell prompt, a % for users' shell prompt,
assuming they use the C-shell or tcsh and a $ for Bourne shell and derivatives.
-Part I. The pkgsrc user's guide
+Part I. The pkgsrc user's guide
Table of Contents
@@ -669,27 +669,27 @@ Table of Contents
10.7. How to fetch files from HTTPS sites
10.8. How do I tell make fetch to do passive FTP?
10.9. How to fetch all distfiles at once
- 10.10. What does "Don't know how to make /usr/share/tmac/tmac.andoc" mean?
- 10.11. What does "Could not find bsd.own.mk" mean?
+ 10.10. What does Don't know how to make /usr/share/tmac/tmac.andoc mean?
+ 10.11. What does Could not find bsd.own.mk mean?
10.12. Using 'sudo' or `priv` with pkgsrc
10.13. How do I change the location of configuration files?
10.14. Automated security checks
10.15. Why do some packages ignore my CFLAGS?
10.16. A package does not build. What shall I do?
- 10.17. What does "Makefile appears to contain unresolved cvs/rcs/??? merge
- conflicts" mean?
+ 10.17. What does Makefile appears to contain unresolved cvs/rcs/??? merge
+ conflicts mean?
-Chapter 2. Getting help
+Chapter 2. Getting help
To get help when using pkgsrc, the definitive source is this document, the
pkgsrc guide. If you don't find anything here, there are alternatives:
* The built-in pkgsrc help, which is available after bootstrapping pkgsrc.
- Run bmake help topic=? to get help for any topic, such as a variable name
+ Run bmake help topic= to get help for any topic, such as a variable name
like BUILD_DEFS, a make target like do-build, a missing C or C++ function
like strcasecmp or any other topic.
- The available help topics are listed in Appendix E, Help topics.
+ The available help topics are listed in Appendix E, Help topics.
* To see the value of a single variable, run bmake show-var VARNAME=X.
@@ -704,7 +704,7 @@ pkgsrc guide. If you don't find anything
a specialized chat program such as XChat. Pick any user name and join the
channel #pkgsrc.
-Chapter 3. Where to get pkgsrc and how to keep it up-to-date
+Chapter 3. Where to get pkgsrc and how to keep it up-to-date
Table of Contents
@@ -723,13 +723,13 @@ contain white-space or other characters
shell and some other programs. A safe bet is to use only letters, digits,
underscores and dashes.
-3.1. Getting pkgsrc for the first time
+3.1. Getting pkgsrc for the first time
Before you download any pkgsrc files, you should decide whether you want the
current branch or the stable branch. The latter is forked on a quarterly basis
from the current branch and only gets modified for security updates. The names
of the stable branches are built from the year and the quarter, for example
-2025Q2.
+2025Q4.
The second step is to decide how you want to download pkgsrc. You can get it as
a tar file or via CVS. Both ways are described here.
@@ -737,12 +737,12 @@ a tar file or via CVS. Both ways are des
Note that tar archive contains CVS working copy. Thus you can switch to using
CVS at any later time.
-3.1.1. As tar archive
+3.1.1. As tar archive
The primary download location for all pkgsrc files is https://cdn.NetBSD.org/
pub/pkgsrc/ or ftp://ftp.NetBSD.org/pub/pkgsrc/ (it points to the same
location). There are a number of subdirectories for different purposes, which
-are described in detail in Appendix D, Directory layout of the pkgsrc FTP
+are described in detail in Appendix D, Directory layout of the pkgsrc FTP
server.
The tar archive for the current branch is in the directory current and is
@@ -753,12 +753,12 @@ published at pkgsrc.tar.bz2 and pkgsrc.t
You can fetch the same files using FTP.
-The tar file for the stable branch 2025Q2 is in the directory pkgsrc-2025Q2 and
+The tar file for the stable branch 2025Q4 is in the directory pkgsrc-2025Q4 and
is also called pkgsrc.tar.gz.
To download the latest pkgsrc stable tarball, run:
-$ ftp ftp://ftp.NetBSD.org/pub/pkgsrc/pkgsrc-2025Q2/pkgsrc.tar.gz
+$ ftp ftp://ftp.NetBSD.org/pub/pkgsrc/pkgsrc-2025Q4/pkgsrc.tar.gz
If you prefer, you can also fetch it using "wget", "curl", or your web browser.
@@ -773,11 +773,11 @@ To download pkgsrc-current, run:
$ ftp ftp://ftp.NetBSD.org/pub/pkgsrc/current/pkgsrc.tar.gz
-3.1.2. Via anonymous CVS
+3.1.2. Via anonymous CVS
To fetch a specific pkgsrc stable branch, run:
-$ cd /usr && cvs -q -z2 -d anoncvs%anoncvs.NetBSD.org@localhost:/cvsroot checkout -r pkgsrc-2025Q2 -P pkgsrc
+$ cd /usr && cvs -q -z2 -d anoncvs%anoncvs.NetBSD.org@localhost:/cvsroot checkout -r pkgsrc-2025Q4 -P pkgsrc
This will create the directory pkgsrc/ in your /usr/ directory and all the
package source will be stored under /usr/pkgsrc/.
@@ -815,13 +815,13 @@ diff -upN
rdiff -u
release -d
-3.2. Keeping pkgsrc up-to-date
+3.2. Keeping pkgsrc up-to-date
The preferred way to keep pkgsrc up-to-date is via CVS (which also works if you
have first installed it via a tar file). It saves bandwidth and hard disk
activity, compared to downloading the tar file again.
-3.2.1. Via tar files
+3.2.1. Via tar files
Warning
@@ -835,14 +835,14 @@ strongly recommended.
Note that by default the distfiles and the binary packages are saved in the
pkgsrc tree, so don't forget to rescue them before updating. You can also
configure pkgsrc to store distfiles and packages in directories outside the
-pkgsrc tree by setting the DISTDIR and PACKAGES variables. See Chapter 6,
+pkgsrc tree by setting the DISTDIR and PACKAGES variables. See Chapter 6,
Configuring pkgsrc for the details.
To update pkgsrc from a tar file, download the tar file as explained above.
Then, make sure that you have not made any changes to the files in the pkgsrc
directory. Remove the pkgsrc directory and extract the new tar file. Done.
-3.2.2. Via CVS
+3.2.2. Via CVS
To update pkgsrc via CVS, change to the pkgsrc directory and run cvs:
@@ -853,34 +853,34 @@ described above. E.g.:
$ cd /usr/pkgsrc && env CVS_RSH=ssh cvs up -dP
-3.2.2.1. Switching between different pkgsrc branches
+3.2.2.1. Switching between different pkgsrc branches
When updating pkgsrc, the CVS program keeps track of the branch you selected.
But if you, for whatever reason, want to switch from the stable branch to the
-current one, you can do it by adding the option "-A" after the "update"
-keyword. To switch from the current branch back to the stable branch, add the "
--rpkgsrc-2025Q2" option.
+current one, you can do it by adding the option -A after the update
+keyword. To switch from the current branch back to the stable branch, add the
+-rpkgsrc-2025Q4 option.
-3.2.2.2. What happens to my changes when updating?
+3.2.2.2. What happens to my changes when updating?
When you update pkgsrc, the CVS program will only touch those files that are
registered in the CVS repository. That means that any packages that you created
on your own will stay unmodified. If you change files that are managed by CVS,
later updates will try to merge your changes with those that have been done by
-others. See the CVS manual, chapter "update" for details.
+others. See the CVS manual, chapter update for details.
-Chapter 4. Using pkgsrc on systems other than NetBSD
+Chapter 4. Using pkgsrc on systems other than NetBSD
Table of Contents
4.1. Binary distribution
4.2. Bootstrapping pkgsrc
-4.1. Binary distribution
+4.1. Binary distribution
-See Section 5.1, "Using binary packages".
+See Section 5.1, Using binary packages .
-4.2. Bootstrapping pkgsrc
+4.2. Bootstrapping pkgsrc
pkgsrc can be bootstrapped for use in two different modes: privileged and
unprivileged one. In unprivileged mode in contrast to privileged one all
@@ -895,7 +895,7 @@ Installing the bootstrap kit from source
# ./bootstrap
-To bootstrap in unprivileged mode pass "--unprivileged" flag to bootstrap
+To bootstrap in unprivileged mode pass --unprivileged flag to bootstrap
By default, in privileged mode pkgsrc uses /usr/pkg for prefix where programs
will be installed in, and /usr/pkg/pkgdb for the package database directory
@@ -903,13 +903,13 @@ where pkgsrc will do its internal bookke
packages install their persistent data. In unprivileged mode pkgsrc uses ~/pkg
for prefix, ~/pkg/pkgdb for the package database, and ~/pkg/var for varbase.
-You can change default layout using command-line arguments. Run "./bootstrap
---help" to get details.
+You can change default layout using command-line arguments. Run ./bootstrap
+--help to get details.
Note
The bootstrap installs a bmake tool. Use this bmake when building via pkgsrc.
-For examples in this guide, use bmake instead of "make".
+For examples in this guide, use bmake instead of make .
Note
@@ -917,7 +917,7 @@ It is possible to bootstrap multiple ins
directories. Use bmake corresponding to the installation you're working with to
build and install packages.
-Chapter 5. Using pkgsrc
+Chapter 5. Using pkgsrc
Table of Contents
@@ -937,11 +937,11 @@ Table of Contents
Basically, there are two ways of using pkgsrc. The first is to only install the
package tools and to use binary packages that someone else has prepared. This
-is the "pkg" in pkgsrc. The second way is to install the "src" of pkgsrc, too.
+is the pkg in pkgsrc. The second way is to install the src of pkgsrc, too.
Then you are able to build your own packages, and you can still use binary
packages from someone else.
-5.1. Using binary packages
+5.1. Using binary packages
On the cdn.NetBSD.org site and mirrors, there are collections of binary
packages, ready to be installed. These binary packages have been built using
@@ -956,9 +956,9 @@ the default settings for the directories
If you cannot use these directories for whatever reasons (maybe because you're
not root), you cannot use these binary packages, but have to build the packages
-yourself, which is explained in Section 4.2, "Bootstrapping pkgsrc".
+yourself, which is explained in Section 4.2, Bootstrapping pkgsrc .
-5.1.1. Finding binary packages
+5.1.1. Finding binary packages
To install binary packages, you first need to know from where to get them. The
first place where you should look is on the main pkgsrc CDN in the directory /
@@ -966,7 +966,7 @@ pub/pkgsrc/packages.
This directory contains binary packages for multiple platforms. First, select
your operating system. Then, select your hardware architecture, and in the
-third step, the OS version and the "version" of pkgsrc.
+third step, the OS version and the version of pkgsrc.
In this directory, you may find a file called bootstrap.tar.gz which contains
the package management tools. If the file is missing, it is likely that your
@@ -974,7 +974,7 @@ operating system already provides those
in the / directory. It will create the directories /usr/pkg (containing the
tools for managing binary packages and the database of installed packages).
-5.1.2. Installing binary packages
+5.1.2. Installing binary packages
In the directory from the last section, there is a subdirectory called All/,
which contains all the binary packages that are available for the platform,
@@ -1009,7 +1009,7 @@ installed, too, assuming they are presen
After you've installed packages, be sure to have /usr/pkg/bin and /usr/pkg/sbin
in your PATH so you can actually start the just installed program.
-5.1.3. Updating packages
+5.1.3. Updating packages
To update binary packages, it is recommended that you use pkgin upgrade. This
will compare the remote package repository to your locally installed packages
@@ -1019,7 +1019,7 @@ Note that pkgsrc is released as quarterl
newer quarterly branch of pkgsrc, you may need to adjust the repository in /usr
/pkg/etc/pkgin/repositories.conf.
-5.1.4. Deinstalling packages
+5.1.4. Deinstalling packages
To deinstall a package, it does not matter whether it was installed from source
code or from a binary package. Neither the pkgin or the pkg_delete command need
@@ -1028,13 +1028,13 @@ to know.
To delete a package, you can just run pkgin remove package-name. The package
name can be given with or without version number.
-5.1.5. Getting information about installed packages
+5.1.5. Getting information about installed packages
The pkg_info shows information about installed packages or binary package
files. As with other management tools, it works with packages installed from
source or binaries.
-5.1.6. Checking for security vulnerabilities in installed packages
+5.1.6. Checking for security vulnerabilities in installed packages
The pkgsrc Security Team and Packages Groups maintain a list of known
vulnerabilities to packages which are (or have been) included in pkgsrc. The
@@ -1086,9 +1086,9 @@ check_pkg_vulnerabilities=YES
see daily.conf(5) and security.conf(5) for more details.
-5.1.7. Finding if newer versions of your installed packages are in pkgsrc
+5.1.7. Finding if newer versions of your installed packages are in pkgsrc
-Install pkgtools/lintpkgsrc and run lintpkgsrc with the "-i" argument to check
+Install pkgtools/lintpkgsrc and run lintpkgsrc with the -i argument to check
if any packages are stale, e.g.
% lintpkgsrc -i
@@ -1096,11 +1096,11 @@ if any packages are stale, e.g.
Version mismatch: 'tcsh' 6.09.00 vs 6.10.00
-5.1.8. Other administrative functions
+5.1.8. Other administrative functions
The pkg_admin executes various administrative functions on the package system.
-5.2. Building packages from source
+5.2. Building packages from source
After obtaining pkgsrc, the pkgsrc directory now contains a set of packages,
organized into categories. You can browse the online index of packages, or run
@@ -1113,17 +1113,17 @@ use multiple different LOCALBASE definit
chroot is an exception).
The rest of this chapter assumes that the package is already in pkgsrc. If it
-is not, see Part II, "The pkgsrc developer's guide" for instructions how to
+is not, see Part II, The pkgsrc developer's guide for instructions how to
create your own packages.
-5.2.1. Requirements
+5.2.1. Requirements
To build packages from source, you need a working C compiler. On NetBSD, you
-need to install the "comp" and the "text" distribution sets. If you want to
-build X11-related packages, the "xbase" and "xcomp" distribution sets are
+need to install the comp and the text distribution sets. If you want to
+build X11-related packages, the xbase and xcomp distribution sets are
required, too.
-5.2.2. Fetching distfiles
+5.2.2. Fetching distfiles
The first step for building a package is downloading the distfiles (i.e. the
unmodified source). If they have not yet been downloaded, pkgsrc will fetch
@@ -1166,7 +1166,7 @@ which will output and run a set of shell
into the distfiles directory. You can also choose to download the files
manually.
-5.2.3. How to build and install
+5.2.3. How to build and install
Once the software has downloaded, any patches will be applied, then it will be
compiled for you. This may take some time depending on your computer, and how
@@ -1175,7 +1175,7 @@ many other packages the software depends
Note
If using bootstrap or pkgsrc on a non-NetBSD system, use the pkgsrc bmake
-command instead of "make" in the examples in this guide.
+command instead of make in the examples in this guide.
For example, type
@@ -1211,7 +1211,7 @@ allow your program to compile, you can t
Taking the figlet utility as an example, we can install it on our system by
-building as shown in Appendix C, Build logs.
+building as shown in Appendix C, Build logs.
The program is installed under the default root of the packages tree - /usr/
pkg. Should this not conform to your tastes, set the LOCALBASE variable in your
@@ -1230,7 +1230,7 @@ be set there by default. Environment var
mk.conf to save having to remember to set them each time you want to use
pkgsrc.
-Occasionally, people want to "look under the covers" to see what is going on
+Occasionally, people want to look under the covers to see what is going on
when a package is building or being installed. This may be for debugging
purposes, or out of simple curiosity. A number of utility values have been
added to help with this.
@@ -1240,8 +1240,8 @@ added to help with this.
make patch PKG_DEBUG_LEVEL=2
- will show all the commands that are invoked, up to and including the "patch
- " stage.
+ will show all the commands that are invoked, up to and including the patch
+ stage.
2. If you want to know the value of a certain make(1) definition, then the
VARNAME definition should be used, in conjunction with the show-var target.
@@ -1269,7 +1269,7 @@ miserably. Note also that precompiled bi
the default LOCALBASE of /usr/pkg, and that you should not install any if you
use a non-standard LOCALBASE.
-Chapter 6. Configuring pkgsrc
+Chapter 6. Configuring pkgsrc
Table of Contents
@@ -1295,7 +1295,7 @@ The whole pkgsrc configuration is done b
that you can define all kinds of variables, and no special error checking (for
example for spelling mistakes) takes place.
-6.1. General configuration
+6.1. General configuration
The following variables apply to all pkgsrc packages. A complete list of the
variables that can be configured by the user is available in mk/defaults/
@@ -1304,7 +1304,7 @@ mk.conf, together with some comments tha
* LOCALBASE: Where packages will be installed. The default is /usr/pkg. Do
not mix binary packages with different LOCALBASEs!
- * CROSSBASE: Where "cross" category packages will be installed. The default
+ * CROSSBASE: Where cross category packages will be installed. The default
is ${LOCALBASE}/cross.
* X11BASE: Where X11 is installed on the system. The default is /usr/X11R7.
@@ -1325,7 +1325,7 @@ mk.conf, together with some comments tha
{DIST_SUBDIR}/.
* BINPKG_SITES: List of sites carrying binary pkgs. rel and arch are replaced
- with OS release ("2.0", etc.) and architecture ("mipsel", etc.).
+ with OS release ( 2.0 , etc.) and architecture ( mipsel , etc.).
* ACCEPTABLE_LICENSES: List of acceptable licenses. License names are
case-sensitive. Whenever you try to build a package whose license is not in
@@ -1333,7 +1333,7 @@ mk.conf, together with some comments tha
simple enough, the error message will include specific instructions on how
to change this variable.
-6.2. Variables affecting the build process
+6.2. Variables affecting the build process
* PACKAGES: The top level directory for the binary packages. The default is $
{PKGSRCDIR}/packages.
@@ -1343,17 +1343,17 @@ mk.conf, together with some comments tha
(see below). This is useful for building packages on several architectures,
then ${PKGSRCDIR} can be NFS-mounted while ${WRKOBJDIR} is local to every
architecture. (It should be noted that PKGSRCDIR should not be set by the
- user -- it is an internal definition which refers to the root of the pkgsrc
+ user it is an internal definition which refers to the root of the pkgsrc
tree. It is possible to have many pkgsrc tree instances.)
* LOCALPATCHES: Directory for local patches that aren't part of pkgsrc. See
- Section 12.3, "patches/*" for more information.
+ Section 12.3, patches/* for more information.
* PKGMAKECONF: Location of the mk.conf file used by a package's BSD-style
Makefile. If this is not set, MAKECONF is set to /dev/null to avoid picking
up settings used by builds in /usr/src.
-6.3. Preferences for native or pkgsrc software
+6.3. Preferences for native or pkgsrc software
Whenever a package depends on a package that has a builtin.mk file, the
dependent package can either use the built-in (native) version from the base
@@ -1361,16 +1361,16 @@ system or the pkgsrc-provided version. T
still possible to build the pkgsrc package devel/pcre++ even when other
packages depend on the native pcre++ version instead.
-To force using the pkgsrc-provided version for a particular package, define "
-PREFER_PKGSRC = package-ID" in mk.conf. To force using the native package,
-define "PREFER_NATIVE = package-ID". In both cases, the package-ID is the one
+To force using the pkgsrc-provided version for a particular package, define
+PREFER_PKGSRC = package-ID in mk.conf. To force using the native package,
+define PREFER_NATIVE = package-ID . In both cases, the package-ID is the one
from the buildlink3.mk of the package. In most cases, this ID is the same as
the directory name of the package, but for example, devel/pcre++ has the
-package ID "pcrexx".
+package ID pcrexx .
For the packages that are not listed by their package ID, pkgsrc uses the
-pkgsrc-provided version if PREFER_PKGSRC contains the word "yes". Otherwise, if
-PREFER_NATIVE contains the word "yes", pkgsrc uses the native version. For
+pkgsrc-provided version if PREFER_PKGSRC contains the word yes . Otherwise, if
+PREFER_NATIVE contains the word yes , pkgsrc uses the native version. For
example, to require using the pkgsrc-provided versions for all but the most
basic bits on a NetBSD system, you can set:
@@ -1393,7 +1393,7 @@ these variables after bootstrap, you nee
those whose preference has been changed. This is not trivial and should be
avoided.
-When using pkgsrc on Linux systems, there is high risk of "leakage", where
+When using pkgsrc on Linux systems, there is high risk of leakage , where
programs installed by pkgsrc may inadvertently use a command or library not
installed by pkgsrc, e.g. those installed by yum or apt. Such foreign
dependencies may be installed, removed, or upgraded to a version incompatible
@@ -1404,12 +1404,12 @@ related Linux systems, yum packages are
eventually they may become too outdated for use by pkgsrc. Even intentionally
using foreign dependencies, not considered leakage, can lead to these problems,
so it is generally discouraged. In order to minimize such problems,
-PREFER_PKGSRC defaults to "yes" on Linux systems. This ensures that pkgsrc is
+PREFER_PKGSRC defaults to yes on Linux systems. This ensures that pkgsrc is
aware of any changes to dependency packages and can rebuild or upgrade the
entire dependency tree as needed. This default can be overridden by setting
---prefer-pkgsrc to a list of packages and --prefer-native to "yes".
+--prefer-pkgsrc to a list of packages and --prefer-native to yes .
-6.4. Variables affecting the installation process
+6.4. Variables affecting the installation process
* PKGSRC_KEEP_BIN_PKGS: By default, binary packages of built packages are
preserved in ${PACKAGES}/All. Setting this variable to "no" prevents this.
@@ -1450,9 +1450,9 @@ Then, as a simple user
$ make clean
-6.5. Selecting and configuring the compiler
+6.5. Selecting and configuring the compiler
-6.5.1. Selecting the compiler
+6.5.1. Selecting the compiler
By default, pkgsrc will use GCC to build packages. This may be overridden by
setting the following variables in /etc/mk.conf:
@@ -1488,10 +1488,10 @@ PKGSRC_COMPILER:
+ xlc: IBM's XL C/C++ compiler suite
- The default is "gcc". You can use ccache and/or distcc with an appropriate
- PKGSRC_COMPILER setting, e.g. "ccache gcc". This variable should always be
+ The default is gcc . You can use ccache and/or distcc with an appropriate
+ PKGSRC_COMPILER setting, e.g. ccache gcc . This variable should always be
terminated with a value for a real compiler. Note that only one real
- compiler should be listed (e.g. "sunpro gcc" is not allowed).
+ compiler should be listed (e.g. sunpro gcc is not allowed).
GCC_REQD:
@@ -1513,18 +1513,18 @@ GFORTRAN_VERSION:
If PKGSRC_FORTRAN= gfortran is used, this option specifies which version to
use.
-6.5.2. Additional flags to the compiler (CFLAGS)
+6.5.2. Additional flags to the compiler (CFLAGS)
If you wish to set the CFLAGS variable, please make sure to use the += operator
instead of the = operator:
CFLAGS+= -your -flags
-Using CFLAGS= (i.e. without the "+") may lead to problems with packages that
+Using CFLAGS= (i.e. without the + ) may lead to problems with packages that
need to add their own flags. You may want to take a look at the devel/cpuflags
package if you're interested in optimization specifically for the current CPU.
-6.5.3. Additional flags to the linker (LDFLAGS)
+6.5.3. Additional flags to the linker (LDFLAGS)
If you want to pass flags to the linker, both in the configure step and the
build step, you can do this in two ways. Either set LDFLAGS or LIBS. The
@@ -1536,7 +1536,7 @@ settings, use the += operator:
LDFLAGS+= -your -linkerflags
-6.6. Developer/advanced settings
+6.6. Developer/advanced settings
* PKG_DEVELOPER: Run some sanity checks that package developers want:
@@ -1554,7 +1554,7 @@ LDFLAGS+= -your -linkerflags
invocation, and the value 2 will display both the shell commands before
their invocation, as well as their actual execution progress with set -x.
-6.7. Selecting Build Options
+6.7. Selecting Build Options
Some packages have build time options, usually to select between different
dependencies, enable optional support for big dependencies or enable
@@ -1579,7 +1579,7 @@ The following variables can be defined i
enable for a package: PKG_DEFAULT_OPTIONS, which can be used to select or
disable options for all packages that support them, and PKG_OPTIONS.pkgbase,
which can be used to select or disable options specifically for package pkgbase
-. Options listed in these variables are selected, options preceded by "-" are
+. Options listed in these variables are selected, options preceded by - are
disabled. A few examples:
$ grep "PKG.*OPTION" mk.conf
@@ -1617,14 +1617,14 @@ automatically. A warning is issued to pr
the options framework directly. Support for the legacy variables will be
removed eventually.
-Chapter 7. Creating binary packages
+Chapter 7. Creating binary packages
Table of Contents
7.1. Building a single binary package
7.2. Settings for creation of binary packages
-7.1. Building a single binary package
+7.1. Building a single binary package
Once you have built and installed a package, you can create a binary package
which can be installed on another system with pkg_add(1). This saves having to
@@ -1641,17 +1641,17 @@ $ make package
This will build your package (if not already done) and package it into a binary
package. You can then use the pkg_* tools to manipulate it. Binary packages are
created in PACKAGES, which defaults to /usr/pkgsrc/packages, in the form of a
-compressed tar file. See Section C.2, "Packaging figlet" for a continuation of
+compressed tar file. See Section C.2, Packaging figlet for a continuation of
the above misc/figlet example.
-See Chapter 23, Submitting and Committing for information on how to submit such
+See Chapter 23, Submitting and Committing for information on how to submit such
a binary package.
-7.2. Settings for creation of binary packages
+7.2. Settings for creation of binary packages
-See Section 13.17, "Other helpful targets".
+See Section 13.17, Other helpful targets .
-Chapter 8. Creating binary packages for everything in pkgsrc (bulk builds)
+Chapter 8. Creating binary packages for everything in pkgsrc (bulk builds)
Table of Contents
@@ -1682,14 +1682,14 @@ onto production systems. There is a way
the bulk build system, or pbulk ("p" stands for "parallel"). This chapter
describes how to set it up.
-8.1. Preparations
+8.1. Preparations
First of all, you have to decide whether you build all packages or a limited
set of them. Full bulk builds usually consume a lot more resources, both space
and time, than builds for some practical sets of packages. A number of
particularly heavy packages exist that are not actually interesting to a wide
audience. (The approximate resource consumption for a full bulk build is given
-in section Section 8.3, "Requirements of a full bulk build".) For limited bulk
+in section Section 8.3, Requirements of a full bulk build .) For limited bulk
builds you need to make a list of packages you want to build. Note that all
their dependencies will be built, so you don't need to track them manually.
@@ -1702,7 +1702,7 @@ effect this makes sure that bulk builds
There have been numerous cases where certain packages tried to install files
outside the LOCALBASE or wanted to edit some files in /etc.
-8.2. Running a bulk build
+8.2. Running a bulk build
Running a bulk build works roughly as follows:
@@ -1711,7 +1711,7 @@ Running a bulk build works roughly as fo
* Then, build each of the packages from a clean installation directory using
the infrastructure.
-8.2.1. Configuration
+8.2.1. Configuration
To simplify configuration, we provide the helper script mk/pbulk/pbulk.sh.
@@ -1775,7 +1775,7 @@ replicate the target system, including t
(each node is an IP address that must be accessible over SSH without a
password).
-8.3. Requirements of a full bulk build
+8.3. Requirements of a full bulk build
A complete bulk build requires lots of disk space. Some of the disk space can
be read-only, some other must be writable. Some can be on remote filesystems
@@ -1794,14 +1794,14 @@ others must survive a sudden reboot.
* 5 GB for temporary files (read-write, local, temporary)
-8.4. Bulk build variants
+8.4. Bulk build variants
To ensure that pkgsrc packages work in different configurations, it makes sense
to run non-default bulk builds from time to time. This section lists some ideas
for bulk builds that intentionally let packages fail if they don't follow the
pkgsrc style.
-8.4.1. Detect unknown configure options
+8.4.1. Detect unknown configure options
Add the following line to mk.conf.
@@ -1811,7 +1811,7 @@ When a package fails this additional che
configure option was valid for an older version of the package but does not
apply anymore. In that case, just remove it.
-8.4.2. Detect classes of bugs by forcing compiler warnings
+8.4.2. Detect classes of bugs by forcing compiler warnings
The job of a compiler is not restricted to producing executable code, most
compilers also detect typical programming mistakes. The pkgsrc compiler
@@ -1857,7 +1857,7 @@ collected above.
Patches that are not essential for the package to work should only be reported
upstream but not committed to pkgsrc, to make future updates easier.
-8.4.3. Force compiler options only in the build phase
+8.4.3. Force compiler options only in the build phase
When adding custom compiler flags via CFLAGS, these apply to all phases of the
package build process. Especially in the configure phase, adding -Werror leads
@@ -1926,10 +1926,10 @@ options, but the corresponding lines sta
options.
Building packages using this setup variant and fixing the resulting bugs is the
-same as in Section 8.4.2, "Detect classes of bugs by forcing compiler warnings"
+same as in Section 8.4.2, Detect classes of bugs by forcing compiler warnings
.
-8.4.4. Use custom directories
+8.4.4. Use custom directories
Some directories like PREFIX, VARBASE, PKG_SYSCONFDIR, PKGMANDIR, PKG_INFODIR
can be configured in pkgsrc. Set these to arbitrary paths during bootstrap or
@@ -1941,7 +1941,7 @@ VARBASE= /a-random-uuid
PKGMANDIR= a-random-uuid
PKG_INFODIR= a-random-uuid
-8.4.5. Turn warnings into errors
+8.4.5. Turn warnings into errors
When building a package, warnings are typically ignored since they just flow by
and do not cause the build to fail immediately. To find these warnings,
@@ -1957,14 +1957,14 @@ If a package suggests to add USE_TOOLS+=
whether the package actually needs Perl. If it does, add USE_TOOLS+=perl to the
package Makefile, and if it doesn't, add TOOLS_BROKEN+=perl.
-8.4.6. Reject packages for which pkglint reports errors
+8.4.6. Reject packages for which pkglint reports errors
Using pkglint as part of the regular build process is mostly a waste of time.
If you want to fix some of the warnings, just run pkglint recursively on the
whole pkgsrc tree. This will take a few minutes (up to 10), which is much
faster than a complete bulk build.
-8.4.7. Reject packages that contain forbidden strings
+8.4.7. Reject packages that contain forbidden strings
To ensure that the binary packages don't contain references to the build
directory, there is already CHECK_WRKREF. If that variable includes the item
@@ -1979,7 +1979,7 @@ CHECK_WRKREF_EXTRA_DIRS+= @[A-Z][A
The above patterns will probably generate many false positives, therefore the
results need to be taken with a grain of salt.
-8.4.8. Reject packages whose self-test fails
+8.4.8. Reject packages whose self-test fails
To run the test suites that come with each package, add this line to mk.conf.
@@ -1990,7 +1990,7 @@ build with this, it will often abort in
scanned for their dependencies since there are cyclic dependencies. There is
still a lot to do in this area.
-8.4.9. Reject packages that use undefined shell variables
+8.4.9. Reject packages that use undefined shell variables
To catch typos in the shell snippets from the Makefile fragments, add the -u
flag to most of the commands by adding this line to mk.conf.
@@ -2003,7 +2003,7 @@ error message the command sh -ceu '$unde
See mk/misc/common.mk for the existing definition.
-8.4.10. Turn off verbose logging
+8.4.10. Turn off verbose logging
The build logs of a package are often quite long. This allows error messages or
other interesting details to hide between the noise. To make the actual error
@@ -2015,7 +2015,7 @@ MAKE_FLAGS+= -s
The -s option works for both GNU Make and BSD Make. On exotic platforms with
their own make, it may be a little different.
-8.5. Creating a multiple CD-ROM packages collection
+8.5. Creating a multiple CD-ROM packages collection
After your pkgsrc bulk-build has completed, you may wish to create a CD-ROM set
of the resulting binary packages to assist in installing packages on other
@@ -2023,7 +2023,7 @@ machines. The pkgtools/cdpack package pr
ISO 9660 images. cdpack arranges the packages on the CD-ROMs in a way that
keeps all the dependencies for a given package on the same CD as that package.
-8.5.1. Example of cdpack
+8.5.1. Example of cdpack
Complete documentation for cdpack is found in the cdpack(1) man page. The
following short example assumes that the binary packages are left in /usr/
@@ -2055,7 +2055,7 @@ Now create the images:
Each image will contain README, COPYING, and bin/myscript in their root
directories.
-Chapter 9. Directory layout of the installed files
+Chapter 9. Directory layout of the installed files
Table of Contents
@@ -2089,8 +2089,8 @@ PKG_DBDIR= ${HOME}/pkg/pkgd
What these four directories are for, and what they look like is explained
below.
- * LOCALBASE corresponds to the /usr directory in the base system. It is the "
- main" directory where the files are installed and contains the well-known
+ * LOCALBASE corresponds to the /usr directory in the base system. It is the
+ main directory where the files are installed and contains the well-known
subdirectories like bin, include, lib, share and sbin.
* VARBASE corresponds to /var in the base system. Some programs (especially
@@ -2099,7 +2099,7 @@ below.
* PKG_SYSCONFDIR corresponds to /etc in the base system. It contains
configuration files of the packages, as well as pkgsrc's mk.conf itself.
-9.1. File system layout in ${LOCALBASE}
+9.1. File system layout in ${LOCALBASE}
The following directories exist in a typical pkgsrc installation in $
{LOCALBASE}.
@@ -2176,7 +2176,7 @@ var (the usual location of ${VARBASE})
Contains files that may be modified after installation.
-9.2. File system layout in ${VARBASE}
+9.2. File system layout in ${VARBASE}
db/pkg (the usual location of ${PKG_DBDIR})
@@ -2194,7 +2194,7 @@ run
Contains informational files about daemons that are currently running.
-Chapter 10. Frequently Asked Questions
+Chapter 10. Frequently Asked Questions
Table of Contents
@@ -2207,21 +2207,21 @@ Table of Contents
10.7. How to fetch files from HTTPS sites
10.8. How do I tell make fetch to do passive FTP?
10.9. How to fetch all distfiles at once
-10.10. What does "Don't know how to make /usr/share/tmac/tmac.andoc" mean?
-10.11. What does "Could not find bsd.own.mk" mean?
+10.10. What does Don't know how to make /usr/share/tmac/tmac.andoc mean?
+10.11. What does Could not find bsd.own.mk mean?
10.12. Using 'sudo' or `priv` with pkgsrc
10.13. How do I change the location of configuration files?
10.14. Automated security checks
10.15. Why do some packages ignore my CFLAGS?
10.16. A package does not build. What shall I do?
-10.17. What does "Makefile appears to contain unresolved cvs/rcs/??? merge
- conflicts" mean?
+10.17. What does Makefile appears to contain unresolved cvs/rcs/??? merge
+ conflicts mean?
This section contains hints, tips & tricks on special things in pkgsrc that we
didn't find a better place for in the previous chapters, and it contains items
for both pkgsrc users and developers.
-10.1. Are there any mailing lists for pkg-related discussion?
+10.1. Are there any mailing lists for pkg-related discussion?
The following mailing lists may be of interest to pkgsrc users:
@@ -2248,7 +2248,7 @@ To subscribe, do:
Archives for all these mailing lists are available from https://
mail-index.NetBSD.org/.
-10.2. Utilities for package management (pkgtools)
+10.2. Utilities for package management (pkgtools)
The directory pkgsrc/pkgtools contains a number of useful utilities for both
users and developers of pkgsrc. This section attempts only to make the reader
@@ -2316,10 +2316,10 @@ Utilities for people maintaining pkgsrc
* pkgtools/libkver: Spoof kernel version for chrooted cross builds.
-10.3. How to use pkgsrc as non-root
+10.3. How to use pkgsrc as non-root
To install packages from source as a non-root user, download pkgsrc as
-described in Chapter 3, Where to get pkgsrc and how to keep it up-to-date, cd
+described in Chapter 3, Where to get pkgsrc and how to keep it up-to-date, cd
into that directory and run the command ./bootstrap/bootstrap --unprivileged.
This will install the binary part of pkgsrc to ~/pkg and put the pkgsrc
@@ -2327,7 +2327,7 @@ configuration mk.conf into ~/pkg/etc.
For more details, see mk/unprivileged.mk.
-10.4. How to resume transfers when fetching distfiles?
+10.4. How to resume transfers when fetching distfiles?
By default, resuming transfers in pkgsrc is disabled, but you can enable this
feature by adding the option PKG_RESUME_TRANSFERS=YES into mk.conf. If, during
@@ -2345,7 +2345,7 @@ like:
FETCH_USING= wget
-10.5. How can I install/use modular X.org from pkgsrc?
+10.5. How can I install/use modular X.org from pkgsrc?
If you want to use modular X.org from pkgsrc instead of your system's own X11
(/usr/X11R6, /usr/openwin, ...) you will have to add the following line into
@@ -2353,30 +2353,30 @@ mk.conf:
X11_TYPE=modular
-10.6. How to fetch files from behind a firewall
+10.6. How to fetch files from behind a firewall
If you are sitting behind a firewall which does not allow direct connections to
Internet hosts (i.e. non-NAT), you may specify the relevant proxy hosts. This
is done using an environment variable in the form of a URL, e.g. in Amdahl, the
-machine "orpheus.amdahl.com" is one of the firewalls, and it uses port 80 as
+machine orpheus.amdahl.com is one of the firewalls, and it uses port 80 as
the proxy port number. So the proxy environment variables are:
ftp_proxy=ftp://orpheus.amdahl.com:80/
http_proxy=http://orpheus.amdahl.com:80/
-10.7. How to fetch files from HTTPS sites
+10.7. How to fetch files from HTTPS sites
Some fetch tools are not prepared to support HTTPS by default (for example, the
one in NetBSD 6.0), or the one installed by the pkgsrc bootstrap (to avoid an
openssl dependency that low in the dependency graph).
-Usually you won't notice, because distribution files are mirrored weekly to "
-ftp.NetBSD.org", but that might not be often enough if you are following
-pkgsrc-current. In that case, set FETCH_USING in your mk.conf file to "curl" or
-"wget", which are both compiled with HTTPS support by default. Of course, these
+Usually you won't notice, because distribution files are mirrored weekly to
+ftp.NetBSD.org , but that might not be often enough if you are following
+pkgsrc-current. In that case, set FETCH_USING in your mk.conf file to curl or
+ wget , which are both compiled with HTTPS support by default. Of course, these
tools need to be installed before you can use them this way.
-10.8. How do I tell make fetch to do passive FTP?
+10.8. How do I tell make fetch to do passive FTP?
This depends on which utility is used to retrieve distfiles. From bsd.pkg.mk,
FETCH_CMD is assigned the first available command from the following list:
@@ -2393,7 +2393,7 @@ following to your mk.conf file: PASSIVE_
Having that option present will prevent /usr/bin/ftp from falling back to
active transfers.
-10.9. How to fetch all distfiles at once
+10.9. How to fetch all distfiles at once
You would like to download all the distfiles in a single batch from work or
university, where you can't run a make fetch. There is an archive of distfiles
@@ -2428,17 +2428,17 @@ everything by running:
% make fetch NO_SKIP=yes
-10.10. What does "Don't know how to make /usr/share/tmac/tmac.andoc" mean?
+10.10. What does Don't know how to make /usr/share/tmac/tmac.andoc mean?
When compiling the pkgtools/pkg_install package, you get the error from make
that it doesn't know how to make /usr/share/tmac/tmac.andoc? This indicates
-that you don't have installed the "text" set (nroff, ...) from the NetBSD base
+that you don't have installed the text set (nroff, ...) from the NetBSD base
distribution on your machine. It is recommended to do that to format man pages.
In the case of the pkgtools/pkg_install package, you can get away with setting
NOMAN=YES either in the environment or in mk.conf.
-10.11. What does "Could not find bsd.own.mk" mean?
+10.11. What does Could not find bsd.own.mk mean?
You didn't install the compiler set, comp.tgz, when you installed your NetBSD
machine. Please get and install it, by extracting it in /:
@@ -2449,7 +2449,7 @@ machine. Please get and install it, by e
comp.tgz is part of every NetBSD release. Get the one that corresponds to your
release (determine via uname -r).
-10.12. Using 'sudo' or `priv` with pkgsrc
+10.12. Using 'sudo' or `priv` with pkgsrc
When installing packages as non-root user and using the just-in-time su(1)
feature of pkgsrc, it can become annoying to type in the root password for each
@@ -2467,7 +2467,7 @@ Note the -E flag; that tells sudo to pre
the bin-install target will fail when building a package with a non-default
python version.
-10.13. How do I change the location of configuration files?
+10.13. How do I change the location of configuration files?
As the system administrator, you can choose where configuration files are
installed. The default settings make all these files go into ${PREFIX}/etc or
@@ -2487,7 +2487,7 @@ of PKGBASE.
Note that after changing these settings, you must rebuild and reinstall any
affected packages.
-10.14. Automated security checks
+10.14. Automated security checks
Please be aware that there can often be bugs in third-party software, and some
of these bugs can leave a machine vulnerable to exploitation by attackers. In
@@ -2508,14 +2508,14 @@ following two tools (installed as part o
by output to stdout, including a description of the type of vulnerability,
and a URL containing more information.
-Use of these tools is strongly recommended! See Section 5.1.6, "Checking for
-security vulnerabilities in installed packages" for instructions on how to
+Use of these tools is strongly recommended! See Section 5.1.6, Checking for
+security vulnerabilities in installed packages for instructions on how to
automate checking and reporting.
If this database is installed, pkgsrc builds will use it to perform a security
check before building any package.
-10.15. Why do some packages ignore my CFLAGS?
+10.15. Why do some packages ignore my CFLAGS?
When you add your own preferences to the CFLAGS variable in your mk.conf, these
flags are passed in environment variables to the ./configure scripts and to
@@ -2525,7 +2525,7 @@ by overriding them in the Makefiles of t
Currently there is no solution to this problem. If you really need the package
to use your CFLAGS you should run make patch in the package directory and then
inspect any Makefile and Makefile.in for whether they define CFLAGS explicitly.
-Usually you can remove these lines. But be aware that some "smart" programmers
+Usually you can remove these lines. But be aware that some smart programmers
write so bad code that it only works for the specific combination of CFLAGS
they have chosen.
@@ -2544,7 +2544,7 @@ command lines (the lines starting with [
compiler (the lines starting with <.>). If the flag is missing from the actual
compiler command, it must have been removed by the pkgsrc compiler wrappers.
-10.16. A package does not build. What shall I do?
+10.16. A package does not build. What shall I do?
1. Make sure that your copy of pkgsrc is consistent. A case that occurs often
is that people only update pkgsrc in parts, because of performance reasons.
@@ -2552,19 +2552,19 @@ compiler command, it must have been remo
there are sometimes changes that only work when the whole pkgsrc tree is
updated.
- 2. Make sure that you don't have any CVS conflicts. Search for "<<<<<<" or "
- >>>>>>" in all your pkgsrc files.
+ 2. Make sure that you don't have any CVS conflicts. Search for <<<<<< or
+ >>>>>> in all your pkgsrc files.
3. Make sure that you don't have old copies of the packages extracted. Run
make clean clean-depends to verify this.
4. If you are a package developer who wants to invest some work, have a look
- at Chapter 21, Making your package work.
+ at Chapter 21, Making your package work.
5. If the problem still exists, write a mail to the pkgsrc-users mailing list.
-10.17. What does "Makefile appears to contain unresolved cvs/rcs/??? merge
-conflicts" mean?
+10.17. What does Makefile appears to contain unresolved cvs/rcs/??? merge
+conflicts mean?
You have modified a file from pkgsrc, and someone else has modified that same
file afterwards in the CVS repository. Both changes are in the same region of
@@ -2576,10 +2576,10 @@ Have a look at that file, and if you don
can remove that file and run cvs -q update -dP in that directory to download
the current version.
-Part II. The pkgsrc developer's guide
+Part II. The pkgsrc developer's guide
This part of the book deals with creating and modifying packages. It starts
-with a "HOWTO"-like guide on creating a new package. The remaining chapters are
+with a HOWTO -like guide on creating a new package. The remaining chapters are
more like a reference manual for pkgsrc.
Table of Contents
@@ -2719,7 +2719,7 @@ Table of Contents
21.5.1. Compiling C and C++ code conditionally
21.5.2. How to handle compiler bugs
21.5.3. No such file or directory
- 21.5.4. Undefined reference to "..."
+ 21.5.4. Undefined reference to ...
21.5.5. Running out of memory
21.6. The install phase
21.6.1. Creating needed directories
@@ -2761,17 +2761,17 @@ Table of Contents
24.1.2. Limited Updates - Bootstrap
25. Frequently Asked Questions
-Chapter 11. Getting help
+Chapter 11. Getting help
To get help when developing pkgsrc, the definitive source is this document, the
pkgsrc guide. If you don't find anything here, there are alternatives:
* The built-in pkgsrc help, which is available after bootstrapping pkgsrc.
- Run bmake help topic=? to get help for any topic, such as a variable name
+ Run bmake help topic= to get help for any topic, such as a variable name
like BUILD_DEFS, a make target like do-build, a missing C or C++ function
like strcasecmp or any other topic.
- The available help topics are listed in Appendix E, Help topics.
+ The available help topics are listed in Appendix E, Help topics.
* To see the value of a single variable, run bmake show-var VARNAME=X.
@@ -2786,7 +2786,7 @@ pkgsrc guide. If you don't find anything
a specialized chat program such as XChat. Pick any user name and join the
channel #pkgsrc.
-Chapter 12. Package components - files, directories and contents
+Chapter 12. Package components - files, directories and contents
Table of Contents
@@ -2809,7 +2809,7 @@ Table of Contents
Whenever you're preparing a package, there are a number of files involved which
are described in the following sections.
-12.1. Makefile
+12.1. Makefile
Building, installation and creation of a binary package are all controlled by
the package's Makefile. The Makefile describes various things about a package,
@@ -2851,7 +2851,7 @@ mostly historical and has no further mea
converters games mbone print x11
* MASTER_SITES, DYNAMIC_MASTER_SITES, DIST_SUBDIR, EXTRACT_SUFX and DISTFILES
- are discussed in detail in Section 13.5, "The fetch phase".
+ are discussed in detail in Section 13.5, The fetch phase .
The second section contains information about separately downloaded patches, if
any.
@@ -2902,7 +2902,7 @@ The third section contains the following
package name).
* LICENSE indicates the license(s) applicable for the package. See
- Section 21.1.3, "Handling licenses" for further details.
+ Section 21.1.3, Handling licenses for further details.
Other variables that affect the build:
@@ -2934,12 +2934,12 @@ Please pay attention to the following go
package. For packages using BSD-style makefiles which honor MANZ, there is
MANCOMPRESSED_IF_MANZ.
- * Replace /usr/local with "${PREFIX}" in all files (see patches, below).
+ * Replace /usr/local with ${PREFIX} in all files (see patches, below).
- * If the package installs any info files, see Section 21.6.8, "Packages
- installing info files".
+ * If the package installs any info files, see Section 21.6.8, Packages
+ installing info files .
-12.2. distinfo
+12.2. distinfo
The distinfo file contains the message digest, or checksum, of each distfile
needed for the package. This ensures that the distfiles retrieved from the
@@ -2949,7 +2949,7 @@ protected using two different message di
as well as the file size.
The distinfo file also contains the checksums for all the patches found in the
-patches directory (see Section 12.3, "patches/*"). These checksums ensure that
+patches directory (see Section 12.3, patches/* ). These checksums ensure that
patches are only applied intentionally and that they don't accidentally change,
e.g. when merging different changes together. They also make sure that new
patches are actually added to CVS and old ones are removed. Too see whether the
@@ -2962,7 +2962,7 @@ example lang/openjdk8. These are kept in
be taken when upgrading such a package to ensure distfile information is not
lost.
-12.3. patches/*
+12.3. patches/*
Some packages don't work out-of-the box on the various platforms that are
supported by pkgsrc. These packages need to be patched to make them work. The
@@ -2971,7 +2971,7 @@ patch files can be found in the patches/
In the patch phase, these patches are applied to the files in WRKSRC directory
after extracting them, in alphabetic order.
-12.3.1. Structure of a single patch file
+12.3.1. Structure of a single patch file
The patch-* files should be in diff -bu format, and apply without a fuzz to
avoid problems. (To force patches to apply with fuzz you can set
@@ -2995,7 +2995,7 @@ application can make some use of the pat
the upstream developers, since we generally want that they accept our patches,
so we have less work in the future.
-12.3.2. Creating patch files
+12.3.2. Creating patch files
One important thing to mention is to pay attention that no RCS IDs get stored
in the patch files, as these will cause problems when later checked into the
@@ -3011,8 +3011,8 @@ patchdiff. The files in patches are repl
if you want to take all the changes.
When you have finished a package, remember to generate the checksums for the
-patch files by using the make makepatchsum command, see Section 12.2,
-"distinfo".
+patch files by using the make makepatchsum command, see Section 12.2,
+ distinfo .
When adding a patch that corrects a problem in the distfile (rather than e.g.
enforcing pkgsrc's view of where man pages should go), send the patch as a bug
@@ -3032,7 +3032,7 @@ if a patch now applies at different line
as-is, there's no need to update it, as that also unnecessarily complicates the
patch history.
-12.3.3. Sources where the patch files come from
+12.3.3. Sources where the patch files come from
If you want to share patches between multiple packages in pkgsrc, e.g. because
they use the same distfiles, set PATCHDIR to the path where the patch files can
@@ -3045,14 +3045,14 @@ listed in PATCHFILES.
If it is desired to store any patches that should not be committed into pkgsrc,
they can be kept outside the pkgsrc tree in the $LOCALPATCHES directory. The
-directory tree there is expected to have the same "category/package" structure
+directory tree there is expected to have the same category/package structure
as pkgsrc, and patches are expected to be stored inside these dirs (also known
as $LOCALPATCHES/$PKGPATH). For example, if you want to keep a private patch
for pkgsrc/graphics/png, keep it in $LOCALPATCHES/graphics/png/mypatch. All
files in the named directory are expected to be patch files, and they are
applied after pkgsrc patches are applied.
-12.3.4. Patching guidelines
+12.3.4. Patching guidelines
When fixing a portability issue in the code do not use preprocessor magic to
check for the current operating system nor platform. Doing so hurts portability
@@ -3063,7 +3063,7 @@ The general rule to follow is: instead o
application is being built on, check for the specific features you need. For
example, instead of assuming that kqueue is available under NetBSD and using
the __NetBSD__ macro to conditionalize kqueue support, add a check that detects
-kqueue itself -- yes, this generally involves patching the configure script.
+kqueue itself yes, this generally involves patching the configure script.
There is absolutely nothing that prevents some OSes from adopting interfaces
from other OSes (e.g. Linux implementing kqueue), something that the above
checks cannot take into account.
@@ -3076,7 +3076,7 @@ doesn't work unless it is right!
Some typical examples:
-Table 12.1. Patching examples
+Table 12.1. Patching examples
+-------------------------------------------------------------------------------------------+
| Where | Incorrect | Correct |
@@ -3103,7 +3103,7 @@ Table 12.1. Patching examples
+-------------------------------------------------------------------------------------------+
-12.3.5. Feedback to the author
+12.3.5. Feedback to the author
Always, always, always feed back any portability fixes or improvements you do
to a package to the mainstream developers. This is the only way to get their
@@ -3123,7 +3123,7 @@ patch comment.
Support the idea of free software!
-12.4. Other mandatory files
+12.4. Other mandatory files
DESCR
@@ -3137,12 +3137,12 @@ PLIST
This file governs the files that are installed on your system: all the
binaries, manual pages, etc. There are other directives which may be
entered in this file, to control the creation and deletion of directories,
- and the location of inserted files. See Chapter 19, PLIST issues for more
+ and the location of inserted files. See Chapter 19, PLIST issues for more
information.
-12.5. Optional files
+12.5. Optional files
-12.5.1. Files affecting the binary package
+12.5.1. Files affecting the binary package
INSTALL
@@ -3150,14 +3150,14 @@ INSTALL
extraction and before files are moved in place, the second time after the
files to install are moved in place. This can be used to do any custom
procedures not possible with @exec commands in PLIST. See pkg_add(1) and
- pkg_create(1) for more information. See also Section 20.1, "Files and
- directories outside the installation prefix". Please note that you can
+ pkg_create(1) for more information. See also Section 20.1, Files and
+ directories outside the installation prefix . Please note that you can
modify variables in it easily by using FILES_SUBST in the package's
Makefile:
FILES_SUBST+= SOMEVAR="somevalue"
- replaces "@SOMEVAR@" with "somevalue" in the INSTALL. By default,
+ replaces "@SOMEVAR@" with somevalue in the INSTALL. By default,
substitution is performed for PREFIX, LOCALBASE, X11BASE, VARBASE, and a
few others, type make help topic=FILES_SUBST for a complete list.
@@ -3201,7 +3201,7 @@ MESSAGE
MESSAGE_SUBST+= SOMEVAR="somevalue"
- replaces "${SOMEVAR}" with "somevalue" in MESSAGE. By default, substitution
+ replaces "${SOMEVAR}" with somevalue in MESSAGE. By default, substitution
is performed for PKGNAME, PKGBASE, PREFIX, LOCALBASE, X11BASE,
PKG_SYSCONFDIR, ROOT_GROUP, and ROOT_USER.
@@ -3218,7 +3218,7 @@ ALTERNATIVES
Each line of the file contains two filenames, first the wrapper and then
the alternative provided by the package. Both paths are relative to PREFIX.
-12.5.2. Files affecting the build process
+12.5.2. Files affecting the build process
Makefile.common
@@ -3231,7 +3231,7 @@ Makefile.common
buildlink3.mk
This file contains the dependency information for the buildlink3 framework
- (see Chapter 18, Buildlink methodology).
+ (see Chapter 18, Buildlink methodology).
hacks.mk
@@ -3242,11 +3242,11 @@ hacks.mk
options.mk
This file contains the code for the package-specific options (see
- Chapter 16, Options handling) that can be selected by the user. If a
+ Chapter 16, Options handling) that can be selected by the user. If a
package has only one or two options, it is equally acceptable to put the
code directly into the Makefile.
-12.5.3. Files affecting nothing at all
+12.5.3. Files affecting nothing at all
README*
@@ -3258,7 +3258,7 @@ TODO
This file contains things that need to be done to make the package even
better.
-12.6. work*
+12.6. work*
When you type make, the distribution files are unpacked into the directory
denoted by WRKDIR. It can be removed by running make clean. Besides the
@@ -3266,18 +3266,18 @@ sources, this directory is also used to
directory gets removed completely on clean. The default is ${.CURDIR}/work or $
{.CURDIR}/work.${MACHINE_ARCH} if OBJMACHINE is set.
-12.7. files/*
+12.7. files/*
If you have any files that you wish to be placed in the package prior to
configuration or building, you can place these files here and use a ${CP}
-command in the "post-extract" target to achieve this.
+command in the post-extract target to achieve this.
If you want to share files in this way with other packages, set the FILESDIR
variable to point to the other package's files directory, e.g.:
FILESDIR= ../../editors/xemacs/files
-Chapter 13. The build process
+Chapter 13. The build process
Table of Contents
@@ -3301,7 +3301,7 @@ Table of Contents
13.16. Cleaning up
13.17. Other helpful targets
-13.1. Introduction
+13.1. Introduction
This chapter gives a detailed description on how a package is built. Building a
package is separated into different phases (for example fetch, build, install),
@@ -3323,7 +3323,7 @@ To get more details about what is happen
PKG_VERBOSE variable, or the PATCH_DEBUG variable if you are just interested in
more details about the patch step.
-13.2. Program location
+13.2. Program location
Before outlining the process performed by the NetBSD package system in the next
section, here's a brief discussion on where programs are installed, and which
@@ -3333,24 +3333,24 @@ The automatic variable PREFIX indicates
shall be installed. It is usually set to LOCALBASE (/usr/pkg), or CROSSBASE for
pkgs in the cross category. The value of PREFIX needs to be put into the
various places in the program's source where paths to these files are encoded.
-See Section 12.3, "patches/*" and Section 21.3.1, "Shared libraries - libtool"
+See Section 12.3, patches/* and Section 21.3.1, Shared libraries - libtool
for more details.
When choosing which of these variables to use, follow the following rules:
* PREFIX always points to the location where the current pkg will be
- installed. When referring to a pkg's own installation path, use "${PREFIX}"
+ installed. When referring to a pkg's own installation path, use ${PREFIX}
.
* LOCALBASE is where all pkgs are installed. If you need to construct a -I or
-L argument to the compiler to find includes and libraries installed by
- another pkg, use "${LOCALBASE}". The name LOCALBASE stems from FreeBSD,
+ another pkg, use ${LOCALBASE} . The name LOCALBASE stems from FreeBSD,
which installed all packages in /usr/local. As pkgsrc leaves /usr/local for
the system administrator, this variable is a misnomer.
* X11BASE is where the actual X11 distribution (from xsrc, etc.) is
installed. When looking for standard X11 includes (not those installed by a
- package), use "${X11BASE}".
+ package), use ${X11BASE} .
* X11-based packages using imake must set USE_IMAKE to be installed correctly
under LOCALBASE.
@@ -3359,7 +3359,7 @@ When choosing which of these variables t
the exception that manual pages go into ${PREFIX}/man, not ${PREFIX}/share/
man.
-13.3. Directories used during the build process
+13.3. Directories used during the build process
When building a package, various directories are used to store source files,
temporary files, pkgsrc-internal files, and so on. These directories are
@@ -3411,7 +3411,7 @@ created in the pkgsrc entry's directory.
pkgsrc trees behave in a read-only manner, then the value of
CREATE_WRKDIR_SYMLINK should be set to no.
-13.4. Running a phase
+13.4. Running a phase
You can run a particular phase by typing make phase, where phase is the name of
the phase. This will automatically run all phases that are required for this
@@ -3419,13 +3419,13 @@ phase. The default phase is build, that
parameters in a package directory, the package will be built, but not
installed.
-13.5. The fetch phase
+13.5. The fetch phase
The first step in building a package is to fetch the distribution files
(distfiles) from the sites that are providing them. This is the task of the
fetch phase.
-13.5.1. What to fetch and where to get it from
+13.5.1. What to fetch and where to get it from
In simple cases, MASTER_SITES defines all URLs from where the distfile, whose
name is derived from the DISTNAME variable, is fetched. The more complicated
@@ -3509,7 +3509,7 @@ MASTER_SITES= ${MASTER_SITE_SOURCEFORG
Note the trailing slash after the subdirectory name.
-13.5.2. How are the files fetched?
+13.5.2. How are the files fetched?
The fetch phase makes sure that all the distfiles exist in a local directory
(DISTDIR, which can be set by the pkgsrc user). If the files do not exist, they
@@ -3529,10 +3529,10 @@ The example above is for FETCH_USING=cus
The distfiles mirror run by the NetBSD Foundation uses the mirror-distfiles
target to mirror the distfiles, if they are freely distributable. Packages
-setting NO_SRC_ON_FTP (usually to "${RESTRICTED}") will not have their
+setting NO_SRC_ON_FTP (usually to ${RESTRICTED} ) will not have their
distfiles mirrored.
-13.6. The checksum phase
+13.6. The checksum phase
After the distfile(s) are fetched, their checksum is generated and compared
with the checksums stored in the distinfo file. If the checksums don't match,
@@ -3540,7 +3540,7 @@ the build is aborted. This is to ensure
and that the distfile wasn't changed, e.g. by some malign force, deliberately
changed distfiles on the master distribution site or network lossage.
-13.7. The extract phase
+13.7. The extract phase
When the distfiles are present on the local system, they need to be extracted,
as they usually come in the form of some compressed archive format.
@@ -3574,25 +3574,25 @@ file that is going to be extracted.
And if that still does not suffice, you can override the do-extract target in
the package Makefile.
-13.8. The patch phase
+13.8. The patch phase
After extraction, all the patches named by the PATCHFILES, those present in the
patches subdirectory of the package as well as in $LOCALPATCHES/$PKGPATH (e.g.
/usr/local/patches/graphics/png) are applied. Patchfiles ending in .Z or .gz
are uncompressed before they are applied, files ending in .orig or .rej are
ignored. Any special options to patch(1) can be handed in PATCH_DIST_ARGS. See
-Section 12.3, "patches/*" for more details.
+Section 12.3, patches/* for more details.
By default patch(1) is given special arguments to make it fail if the expected
text from the patch context is not found in the patched file. If that happens,
fix the patch file by comparing it with the actual text in the file to be
patched.
-13.9. The tools phase
+13.9. The tools phase
-This is covered in Chapter 17, Tools needed for building or running.
+This is covered in Chapter 17, Tools needed for building or running.
-13.10. The wrapper phase
+13.10. The wrapper phase
This phase creates wrapper programs for the compilers and linkers. The
following variables can be used to tweak the wrappers.
@@ -3618,7 +3618,7 @@ WRAPPER_REORDER_CMDS
A list of reordering commands. A reordering command has the form reorder:l:
lib1:lib2. It ensures that that -llib1 occurs before -llib2.
-13.11. The configure phase
+13.11. The configure phase
Most pieces of software need information on the header files, system calls, and
library routines which are available on the platform they run on. The process
@@ -3627,8 +3627,8 @@ automated. In most cases, a script is su
invocation results in generation of header files, Makefiles, etc.
If the package contains a configure script, this can be invoked by setting
-HAS_CONFIGURE to "yes". If the configure script is a GNU autoconf script, you
-should set GNU_CONFIGURE to "yes" instead.
+HAS_CONFIGURE to yes . If the configure script is a GNU autoconf script, you
+should set GNU_CONFIGURE to yes instead.
In the do-configure stage, a rough equivalent of the following command is run.
See mk/configure/configure.mk, target do-configure-script for the exact
@@ -3640,10 +3640,10 @@ definition.
${CONFIG_SHELL} ${CONFIGURE_SCRIPT} ${CONFIGURE_ARGS}
.endfor
-CONFIGURE_DIRS (default: ".") is a list of pathnames relative to WRKSRC. In
+CONFIGURE_DIRS (default: . ) is a list of pathnames relative to WRKSRC. In
each of these directories, the configure script is run with the environment
CONFIGURE_ENV and arguments CONFIGURE_ARGS. The variables CONFIGURE_ENV,
-CONFIGURE_SCRIPT (default: "./configure") and CONFIGURE_ARGS may all be changed
+CONFIGURE_SCRIPT (default: ./configure ) and CONFIGURE_ARGS may all be changed
by the package.
If the program uses the Perl way of configuration (mainly Perl modules, but not
@@ -3652,7 +3652,7 @@ module.mk. To set any parameter for Make
(e.g., MAKE_PARAMS+=foo=bar
If the program uses an Imakefile for configuration, the appropriate steps can
-be invoked by setting USE_IMAKE to "yes". If you only need xmkmf, add it to
+be invoked by setting USE_IMAKE to yes . If you only need xmkmf, add it to
USE_TOOLS. You can add variables to xmkmf's environment by adding them to the
SCRIPTS_ENV variable.
@@ -3663,16 +3663,16 @@ to cmake by adding them to the CMAKE_CON
add arguments only for particular stages, you can use the CMAKE_CONFIGURE_ARGS,
CMAKE_BUILD_ARGS, and CMAKE_INSTALL_ARGS variables. You can set the
CONFIGURE_DIRS variable to the directories in which CMake should be run,
-relative to WRKSRC. This defaults to to ".".
+relative to WRKSRC. This defaults to to . .
Any package using the now-deprecated USE_CMAKE=yes should be converted.
Essentially, replace with an include of ../../devel/cmake/build.mk, prune
creation of a build directory and settings to use it, and check/fix settings
that intend to perform the build in a subdirectory.
-If there is no configure step at all, set NO_CONFIGURE to "yes".
+If there is no configure step at all, set NO_CONFIGURE to yes .
-13.12. The build phase
+13.12. The build phase
For building a package, a rough equivalent of the following code is executed;
see mk/build/build.mk, target do-build for the exact definition.
@@ -3685,22 +3685,22 @@ see mk/build/build.mk, target do-build f
${BUILD_TARGET}
.endfor
-BUILD_DIRS (default: ".") is a list of pathnames relative to WRKSRC. In each of
+BUILD_DIRS (default: . ) is a list of pathnames relative to WRKSRC. In each of
these directories, MAKE_PROGRAM is run with the environment MAKE_ENV and
arguments BUILD_MAKE_FLAGS. The variables MAKE_ENV, BUILD_MAKE_FLAGS, MAKE_FILE
and BUILD_TARGET may all be changed by the package.
-The default value of MAKE_PROGRAM is "gmake" if USE_TOOLS contains "gmake", "
-make" otherwise. The default value of MAKE_FILE is "Makefile", and BUILD_TARGET
-defaults to "all".
+The default value of MAKE_PROGRAM is gmake if USE_TOOLS contains gmake ,
+make otherwise. The default value of MAKE_FILE is Makefile , and BUILD_TARGET
+defaults to all .
-If there is no build step at all, set NO_BUILD to "yes".
+If there is no build step at all, set NO_BUILD to yes .
-13.13. The test phase
+13.13. The test phase
[TODO]
-13.14. The install phase
+13.14. The install phase
Once the build stage has completed, the final step is to install the software
in public directories, so users can access the programs and files.
@@ -3718,8 +3718,8 @@ against the files-to-be-installed, see m
.endfor
The variable's meanings are analogous to the ones in the build phase.
-INSTALL_DIRS defaults to BUILD_DIRS. INSTALL_TARGET is "install" by default,
-plus "install.man" if USE_IMAKE is defined and NO_INSTALL_MANPAGES is not
+INSTALL_DIRS defaults to BUILD_DIRS. INSTALL_TARGET is install by default,
+plus install.man if USE_IMAKE is defined and NO_INSTALL_MANPAGES is not
defined.
In the install phase, the following variables are useful. They are all
@@ -3794,9 +3794,9 @@ INSTALLATION_DIRS
directories here.
In the rare cases that a package shouldn't install anything, set NO_INSTALL to
-"yes". This is mostly relevant for packages in the regress category.
+ yes . This is mostly relevant for packages in the regress category.
-13.15. The package phase
+13.15. The package phase
Once the install stage has completed, a binary package of the installed files
can be built. These binary packages can be used for quick installation without
@@ -3806,18 +3806,18 @@ By default, the binary packages are crea
created in ${PACKAGES}/category, one for each category in the CATEGORIES
variable. PACKAGES defaults to pkgsrc/packages.
-13.16. Cleaning up
+13.16. Cleaning up
Once you're finished with a package, you can clean the work directory by
running make clean. If you want to clean the work directories of all
dependencies too, use make clean-depends.
-13.17. Other helpful targets
+13.17. Other helpful targets
pre/post-*
For any of the main targets described in the previous section (configure,
- build, install, etc.), two auxiliary targets exist with "pre-" and "post-"
+ build, install, etc.), two auxiliary targets exist with pre- and post-
used as a prefix for the main target's name. These targets are invoked
before and after the main target is called, allowing extra configuration or
installation steps be performed from a package's Makefile, for example,
@@ -3841,10 +3841,10 @@ reinstall
If you did a make install and you noticed some file was not installed
properly, you can repeat the installation with this target, which will
- ignore the "already installed" flag.
+ ignore the already installed flag.
This is the default value of DEPENDS_TARGET except in the case of make
- update and make package, where the defaults are "package" and "update",
+ update and make package, where the defaults are package and update ,
respectively.
deinstall
@@ -3862,8 +3862,8 @@ deinstall
Remove all packages that require (depend on) the given package. This
can be used to remove any packages that may have been pulled in by a
given package, e.g. if make deinstall DEINSTALLDEPENDS=1 is done in
- pkgsrc/x11/kde, this is likely to remove whole KDE. Works by adding "-R
- " to the pkg_delete(1) command line.
+ pkgsrc/x11/kde, this is likely to remove whole KDE. Works by adding -R
+ to the pkg_delete(1) command line.
bin-install
@@ -3892,7 +3892,7 @@ update
performing a series of make deinstall and make install (or whatever
UPDATE_TARGET is set to) for these packages.
- You can use the "update" target to resume package updating in case a
+ You can use the update target to resume package updating in case a
previous make update was interrupted for some reason. However, in this
case, make sure you don't call make clean or otherwise remove the list of
dependent packages in WRKDIR. Otherwise, you lose the ability to
@@ -3909,29 +3909,29 @@ update
UPDATE_TARGET
Install target to recursively use for the updated package and the
- dependent packages. Defaults to DEPENDS_TARGET if set, "install"
- otherwise for make update. Other good targets are "package" or "
- bin-install". Do not set this to "update" or you will get stuck in an
+ dependent packages. Defaults to DEPENDS_TARGET if set, install
+ otherwise for make update. Other good targets are package or
+ bin-install . Do not set this to update or you will get stuck in an
endless loop!
NOCLEAN
Don't clean up after updating. Useful if you want to leave the work
sources of the updated packages around for inspection or other
- purposes. Be sure you eventually clean up the source tree (see the "
- clean-update" target below) or you may run into troubles with old
+ purposes. Be sure you eventually clean up the source tree (see the
+ clean-update target below) or you may run into troubles with old
source code still lying around on your next make or make update.
REINSTALL
Deinstall each package before installing (making DEPENDS_TARGET). This
- may be necessary if the "clean-update" target (see below) was called
+ may be necessary if the clean-update target (see below) was called
after interrupting a running make update.
DEPENDS_TARGET
Allows you to disable recursion and hardcode the target for packages.
- The default is "update" for the update target, facilitating a recursive
+ The default is update for the update target, facilitating a recursive
update of prerequisite packages. Only set DEPENDS_TARGET if you want to
disable recursive updates. Use UPDATE_TARGET instead to just set a
specific target for each package to be installed during make update
@@ -4026,7 +4026,7 @@ readme-all
cdrom-readme
- This is very much the same as the "readme" target (see above), but is to be
+ This is very much the same as the readme target (see above), but is to be
used when generating a pkgsrc tree to be written to a CD-ROM. This target
also produces index.html files, and can be made to refer to URLs based on
CDROM_PKG_URL_HOST and CDROM_PKG_URL_DIR.
@@ -4051,8 +4051,8 @@ show-pkgsrc-dir
package can be built and installed. This may not be the same directory as
the one from which the package was installed. This target is intended to be
used by people who may wish to upgrade many packages on a single host, and
- can be invoked from the top-level pkgsrc Makefile by using the "
- show-host-specific-pkgs" target.
+ can be invoked from the top-level pkgsrc Makefile by using the
+ show-host-specific-pkgs target.
show-installed-depends
@@ -4077,7 +4077,7 @@ check-shlibs
print-PLIST
- After a "make install" from a new or upgraded pkg, this prints out an
+ After a make install from a new or upgraded pkg, this prints out an
attempt to generate a new PLIST from a find -newer work/.extract_done. An
attempt is made to care for shared libs etc., but it is strongly
recommended to review the result before putting it into PLIST. On upgrades,
@@ -4086,33 +4086,33 @@ print-PLIST
If the package installs files via tar(1) or other methods that don't update
file access times, be sure to add these files manually to your PLIST, as
- the "find -newer" command used by this target won't catch them!
+ the find -newer command used by this target won't catch them!
- See Section 19.3, "Tweaking output of make print-PLIST" for more
+ See Section 19.3, Tweaking output of make print-PLIST for more
information on this target.
rebuild
If you did a make build and you noticed some further modifications of
sources are needed, you can repeat the build with this target, which will
- ignore the "already built" flag. This target is helpful while working with
+ ignore the already built flag. This target is helpful while working with
patches.
repackage
If you did a make package and you noticed some further modifications of
sources are needed, you can repeat the package with this target, which will
- ignore the "already packaged" flag. This target is helpful while working
+ ignore the already packaged flag. This target is helpful while working
with patches, PLIST* files etc.
retest
If you did a make test and you noticed some further modifications of
sources are needed, you can repeat the test with this target, which will
- ignore the "already tested" flag. This target is helpful while working with
+ ignore the already tested flag. This target is helpful while working with
patches.
-Chapter 14. Creating a new pkgsrc package from scratch
+Chapter 14. Creating a new pkgsrc package from scratch
Table of Contents
@@ -4183,12 +4183,12 @@ package involves only a few steps.
.include "../../mk/bsd.pkg.mk"
6. Run pkglint to see what things still need to be done to make your package a
- "good" one. If you don't know what pkglint's warnings want to tell you, try
+ good one. If you don't know what pkglint's warnings want to tell you, try
pkglint --explain or pkglint -e, which outputs additional explanations.
7. In many cases the package is not yet ready to build. You can find
- instructions for the most common cases in the next section, Section 14.1,
- "Common types of packages". After you have followed the instructions over
+ instructions for the most common cases in the next section, Section 14.1,
+ Common types of packages . After you have followed the instructions over
there, you can hopefully continue here.
8. Run bmake clean to clean the working directory from the extracted files.
@@ -4197,7 +4197,7 @@ package involves only a few steps.
you edited the Makefile.
9. Now, run bmake to build the package. For the various things that can go
- wrong in this phase, consult Chapter 21, Making your package work.
+ wrong in this phase, consult Chapter 21, Making your package work.
If the extracted files from the package need to be fixed, run multiple
rounds of these commands:
@@ -4229,12 +4229,12 @@ package involves only a few steps.
15. Run pkglint to see if there's anything left to do.
-16. Commit the package to pkgsrc-wip or main pkgsrc; see Chapter 23, Submitting
+16. Commit the package to pkgsrc-wip or main pkgsrc; see Chapter 23, Submitting
and Committing.
-14.1. Common types of packages
+14.1. Common types of packages
-14.1.1. Python modules and programs
+14.1.1. Python modules and programs
Python modules and programs packages are easily created using a set of
predefined variables.
@@ -4252,8 +4252,8 @@ that projects can use. Thus inclusion of
are defined as TOOL_DEPENDS. Whatever the project specifically requires as
packaging tools must be defined in the package Makefile.
-The package directory should be called "py-software" and PKGNAME should be set
-to "${PYPKGPREFIX}-${DISTNAME}", e.g.
+The package directory should be called py-software and PKGNAME should be set
+to ${PYPKGPREFIX}-${DISTNAME} , e.g.
DISTNAME= foopymodule-1.2.10
PKGNAME= ${PYPKGPREFIX}-${DISTNAME}
@@ -4261,14 +4261,14 @@ PKGNAME= ${PYPKGPREFIX}-${DISTNAME}
For software in PyPi, the name should match what PyPi specifies for "pip
install software".
-If it is an application, include "../../lang/python/application.mk". In order
+If it is an application, include ../../lang/python/application.mk . In order
to correctly set the path to the Python interpreter, use the REPLACE_PYTHON
variable and set it to the list of files (paths relative to WRKSRC) that must
be corrected. For example:
REPLACE_PYTHON= *.py
-14.1.2. R packages
+14.1.2. R packages
Simple R packages from CRAN are handled automatically by R2pkg, which is
available in pkgtools/R2pkg. Individual packages (and optionally their
@@ -4278,13 +4278,13 @@ file as part of each R package on CRAN.
information and creates or updates a package in the canonical form. The
resulting package should be reviewed for correctness.
-14.1.3. TeXlive packages
+14.1.3. TeXlive packages
TeXlive packages from CTAN are handled automatically by texlive2pkg, which is
available in pkgtools/texlive2pkg.
-If the TeXlive package name is not known, it may be useful to search CTAN. A "
-Contained in" field on the package page typically identifies the basename of
+If the TeXlive package name is not known, it may be useful to search CTAN. A
+Contained in field on the package page typically identifies the basename of
the package file in the TeXlive archive.
If the TeXlive package name is known, download the files from the TeXlive
@@ -4308,15 +4308,15 @@ with the following command in each packa
make upload-distfiles
-14.2. Examples
+14.2. Examples
-14.2.1. How the www/nvu package came into pkgsrc
+14.2.1. How the www/nvu package came into pkgsrc
-14.2.1.1. The initial package
+14.2.1.1. The initial package
-Looking at the file pkgsrc/doc/TODO, I saw that the "nvu" package has not yet
+Looking at the file pkgsrc/doc/TODO, I saw that the nvu package has not yet
been imported into pkgsrc. As the description says it has to do with the web,
-the obvious choice for the category is "www".
+the obvious choice for the category is www .
$ mkdir www/nvu
$ cd www/nvu
@@ -4327,7 +4327,7 @@ URL to the url2pkg program:
$ url2pkg http://cvs.nvu.com/download/nvu-1.0-sources.tar.bz2
My editor popped up, and I added a PKGNAME line below the DISTNAME line, as the
-package name should not have the word "sources" in it. I also filled in the
+package name should not have the word sources in it. I also filled in the
MAINTAINER, HOMEPAGE and COMMENT fields. Then the package Makefile looked like
that:
@@ -4373,7 +4373,7 @@ Remember to correct CATEGORIES, HOMEPAGE
Good luck! (See pkgsrc/doc/pkgsrc.txt for some more help :-)
-14.2.1.2. Fixing all kinds of problems to make the package work
+14.2.1.2. Fixing all kinds of problems to make the package work
Now that the package has been extracted, let's see what's inside it. The
package has a README.txt, but that only says something about mozilla, so it's
@@ -4395,9 +4395,9 @@ WARNING: Please add USE_TOOLS+=perl to t
[...]
That worked quite well. So I opened the package Makefile in my editor, and
-since it already has a USE_TOOLS line, I just appended "perl" to it. Since the
+since it already has a USE_TOOLS line, I just appended perl to it. Since the
dependencies of the package have changed now, and since a perl wrapper is
-automatically installed in the "tools" phase, I need to build the package from
+automatically installed in the tools phase, I need to build the package from
scratch.
$ bmake clean
@@ -4408,7 +4408,7 @@ $ bmake
GNU Make. You will not be able to build Mozilla without GNU Make.
[...]
-So I added "gmake" to the USE_TOOLS line and tried again (from scratch).
+So I added gmake to the USE_TOOLS line and tried again (from scratch).
[...]
checking for GTK - version >= 1.2.0... no
@@ -4431,7 +4431,7 @@ The first try was definitely too broad.
which is very good. But there is one pitfall with GNOME packages. Before GNOME
2 had been released, there were already many GNOME 1 packages in pkgsrc. To be
able to continue to use these packages, the GNOME 2 packages were imported as
-separate packages, and their names usually have a "2" appended. So I checked
+separate packages, and their names usually have a 2 appended. So I checked
whether this was the case here, and indeed it was.
Since the GTK2 package has a buildlink3.mk file, adding the dependency is very
@@ -4455,7 +4455,7 @@ checking for GTK - version >= 1.2.0... n
configure: error: Test for GTK failed.
[...]
-In this particular case, the assumption that "every package prefers GNOME 2"
+In this particular case, the assumption that every package prefers GNOME 2
had been wrong. The first of the lines above told me that this package really
wanted to have the GNOME 1 version of GTK. If the package had looked for GTK2,
it would have looked for pkg-config instead of gtk-config. So I changed the x11
@@ -4496,7 +4496,7 @@ looked up in www/seamonkey which patch f
copied them to the patches directory. Then I retried, fixed the patches so that
they applied cleanly and retried again. This time, everything worked.
-14.2.1.3. Installing the package
+14.2.1.3. Installing the package
$ bmake CHECK_FILES=no install
[...]
@@ -4504,7 +4504,7 @@ $ bmake print-PLIST >PLIST
$ bmake deinstall
$ bmake install
-Chapter 15. Programming in Makefiles
+Chapter 15. Programming in Makefiles
Table of Contents
@@ -4531,7 +4531,7 @@ necessary to quote all variables correct
This chapter describes some patterns that appear quite often in Makefiles,
including the pitfalls that come along with them.
-15.1. Caveats
+15.1. Caveats
* When you are creating a file as a target of a rule, always write the data
to a temporary file first and finally rename that file. Otherwise there
@@ -4559,7 +4559,7 @@ including the pitfalls that come along w
pressing Ctrl+C. This does not happen when one of the commands fails (like
false(1) above).
-15.2. Makefile variables
+15.2. Makefile variables
Makefile variables contain strings that can be processed using the five
operators =, +=, ?=, := and !=, which are described in the make(1) man page.
@@ -4582,7 +4582,7 @@ words, others operate on the string as a
words, double quotes and single quotes are interpreted as delimiters, just like
in sh(1).
-15.2.1. Naming conventions
+15.2.1. Naming conventions
* All variable names starting with an underscore are reserved for use by the
pkgsrc infrastructure. They shall not be used by packages.
@@ -4593,9 +4593,9 @@ in sh(1).
* All list variables should have a plural name, such as PKG_OPTIONS or
DISTFILES.
-15.3. Code snippets
+15.3. Code snippets
-15.3.1. Adding things to a list
+15.3.1. Adding things to a list
When adding a string that possibly contains whitespace or quotes to a list
(example 1), it must be quoted using the :Q modifier.
@@ -4610,7 +4610,7 @@ ANOTHER_LIST= a=b c=d
LIST+= ${STRING:Q} # 1
LIST+= ${ANOTHER_LIST} # 2
-15.3.2. Echoing a string exactly as-is
+15.3.2. Echoing a string exactly as-is
Echoing a string containing special characters needs special work.
@@ -4639,7 +4639,7 @@ doesn't make a difference, but other pro
In example 4, the EXAMPLE_ENV does not need to be quoted because the quoting
has already been done when adding elements to the list.
-15.3.3. Passing CFLAGS to GNU configure scripts
+15.3.3. Passing CFLAGS to GNU configure scripts
When passing CFLAGS or similar variables to a GNU-style configure script
(especially those that call other configure scripts), it must not have leading
@@ -4660,7 +4660,7 @@ all:
In this example, CPPFLAGS has both leading and trailing whitespace because the
+= operator always adds a space.
-15.3.4. Handling possibly empty variables
+15.3.4. Handling possibly empty variables
When a possibly empty variable is used in a shell program, it may lead to a
syntax error.
@@ -4700,7 +4700,7 @@ single or double quotes.
To have a shell command test whether a make variable is empty, use the
following code: ${TEST} -z ${POSSIBLY_EMPTY:Q}"".
-15.3.5. Testing yes/no variables in conditions
+15.3.5. Testing yes/no variables in conditions
When a variable can have the values yes or no, use the following pattern to
test the variable:
@@ -4715,7 +4715,7 @@ variable is guaranteed to be defined, th
The :tl modifier converts the variable value to lowercase, allowing for the
values yes, Yes, YES.
-Chapter 16. Options handling
+Chapter 16. Options handling
Table of Contents
@@ -4759,13 +4759,13 @@ A further consideration is licensing. No
non-free dependencies (especially plugins) should almost always be split if
feasible.
-16.1. Global default options
+16.1. Global default options
Global default options are listed in PKG_DEFAULT_OPTIONS, which is a list of
the options that should be built into every package if that option is
supported. This variable should be set in mk.conf.
-16.2. Converting packages to use bsd.options.mk
+16.2. Converting packages to use bsd.options.mk
The following example shows how bsd.options.mk should be used by the
hypothetical ``wibble'' package, either in the package Makefile, or in a file,
@@ -4845,14 +4845,14 @@ supported by the package, and any defaul
6. PKG_SUGGESTED_OPTIONS is a list of build options which are enabled by
default.
- 7. PKG_OPTIONS_LEGACY_VARS is a list of "USE_VARIABLE:option" pairs that map
+ 7. PKG_OPTIONS_LEGACY_VARS is a list of USE_VARIABLE:option pairs that map
legacy mk.conf variables to their option counterparts. Pairs should be
- added with "+=" to keep the listing of global legacy variables. A warning
+ added with += to keep the listing of global legacy variables. A warning
will be issued if the user uses a legacy variable.
- 8. PKG_OPTIONS_LEGACY_OPTS is a list of "old-option:new-option" pairs that map
+ 8. PKG_OPTIONS_LEGACY_OPTS is a list of old-option:new-option pairs that map
options that have been renamed to their new counterparts. Pairs should be
- added with "+=" to keep the listing of global legacy options. A warning
+ added with += to keep the listing of global legacy options. A warning
will be issued if the user uses a legacy option.
9. PKG_LEGACY_OPTIONS is a list of options implied by deprecated variables
@@ -4883,7 +4883,7 @@ PKG_OPTIONS:
.if !empty(PKG_OPTIONS:Moption)
-16.3. Option Names
+16.3. Option Names
Options that enable similar features in different packages (like optional
support for a library) should use a common name in all packages that support it
@@ -4895,16 +4895,16 @@ another (unrelated) package has the same
should use a name prefixed with pkgname-.
If a group of related packages share an optional feature specific to that
-group, prefix it with the name of the "main" package (e. g.
+group, prefix it with the name of the main package (e. g.
djbware-errno-hack).
For new options, add a line to mk/defaults/options.description. Lines have two
fields, separated by tab. The first field is the option name, the second its
description. The description should be a whole sentence (starting with an
uppercase letter and ending with a period) that describes what enabling the
-option does. E. g. "Enable ispell support." The file is sorted by option names.
+option does. E. g. Enable ispell support. The file is sorted by option names.
-16.4. Determining the options of dependencies
+16.4. Determining the options of dependencies
When writing buildlink3.mk files, it is often necessary to list different
dependencies based on the options with which the package was built. For
@@ -4923,7 +4923,7 @@ PKG_BUILD_OPTIONS.libpurple to the build
which can then be queried like PKG_OPTIONS in the options.mk file. See the file
pkg-build-options.mk for more details.
-Chapter 17. Tools needed for building or running
+Chapter 17. Tools needed for building or running
Table of Contents
@@ -4950,7 +4950,7 @@ package may need GNU awk, bison (instead
The tools used by a package can be listed by running make show-tools.
-17.1. Tools for pkgsrc builds
+17.1. Tools for pkgsrc builds
The default set of tools used by pkgsrc is defined in bsd.pkg.mk. This includes
standard Unix tools, such as: cat, awk, chmod, test, and so on. These can be
@@ -4959,7 +4959,7 @@ seen by running: make show-var VARNAME=U
If a package needs a specific program to build then the USE_TOOLS variable can
be used to define the tools needed.
-17.2. Tools needed by packages
+17.2. Tools needed by packages
In the following examples, the :run means that it is needed at run-time (and
becomes a DEPENDS). The default is a build dependency which can be set with
@@ -4970,12 +4970,12 @@ USE_TOOLS+= gmake perl:run pkg-confi
When using the tools framework, a TOOLS_PATH.foo variable is defined which
contains the full path to the appropriate tool. For example, TOOLS_PATH.bash
-could be "/bin/bash" on Linux systems.
+could be /bin/bash on Linux systems.
If you always need a pkgsrc version of the tool at run-time, then just use
DEPENDS instead.
-17.3. Tools provided by platforms
+17.3. Tools provided by platforms
When improving or porting pkgsrc to a new platform, have a look at (or create)
the corresponding platform specific make file fragment under pkgsrc/mk/tools/
@@ -4989,7 +4989,7 @@ TOOLS_PLATFORM.bzcat?= /usr/bin
TOOLS_PLATFORM.true?= true # shell builtin
-Chapter 18. Buildlink methodology
+Chapter 18. Buildlink methodology
Table of Contents
@@ -5020,9 +5020,9 @@ note that the normal system header and l
lib, etc., are always searched -- buildlink3 is designed to insulate the
package build from non-system-supplied software.
-18.1. Converting packages to use buildlink3
+18.1. Converting packages to use buildlink3
-The process of converting packages to use the buildlink3 framework ("bl3ifying"
+The process of converting packages to use the buildlink3 framework ( bl3ifying
) is fairly straightforward. The things to keep in mind are:
1. Ensure that the build always calls the wrapper scripts instead of the
@@ -5032,7 +5032,7 @@ The process of converting packages to us
2. Don't override PREFIX from within the package Makefile, e.g. Java VMs,
standalone shells, etc., because the code to symlink files into $
- {BUILDLINK_DIR} looks for files relative to "pkg_info -qp pkgname".
+ {BUILDLINK_DIR} looks for files relative to pkg_info -qp pkgname .
3. Remember that only the buildlink3.mk files that you list in a package's
Makefile are added as dependencies for that package.
@@ -5067,8 +5067,8 @@ issues:
implementation.
* motif.buildlink3.mk checks for a system-provided Motif installation or adds
- a dependency on x11/lesstif or x11/motif. The user can set MOTIF_TYPE to "
- dt", "lesstif" or "motif" to choose which Motif version will be used.
+ a dependency on x11/lesstif or x11/motif. The user can set MOTIF_TYPE to
+ dt , lesstif or motif to choose which Motif version will be used.
* readline.buildlink3.mk checks for a system-provided GNU readline or
editline (libedit) installation, or adds a dependency on devel/readline,
@@ -5093,7 +5093,7 @@ issues:
The comments in those buildlink3.mk files provide a more complete description
of how to use them properly.
-18.2. Writing buildlink3.mk files
+18.2. Writing buildlink3.mk files
A package's buildlink3.mk file is included by Makefiles to indicate the need to
compile and link against header files and libraries provided by the package. A
@@ -5109,7 +5109,7 @@ following command will generate a good s
% createbuildlink >buildlink3.mk
-18.2.1. Anatomy of a buildlink3.mk file
+18.2.1. Anatomy of a buildlink3.mk file
The following real-life example buildlink3.mk is taken from pkgsrc/graphics/
tiff:
@@ -5145,16 +5145,16 @@ dependency on pkg is added. Several impo
* BUILDLINK_DEPMETHOD.pkg (not shown above) controls whether we use
BUILD_DEPENDS or DEPENDS to add the dependency on pkg. The build dependency
- is selected by setting BUILDLINK_DEPMETHOD.pkg to "build". By default, the
+ is selected by setting BUILDLINK_DEPMETHOD.pkg to build . By default, the
full dependency is used.
* BUILDLINK_INCDIRS.pkg and BUILDLINK_LIBDIRS.pkg (not shown above) are lists
of subdirectories of ${BUILDLINK_PREFIX.pkg} to add to the header and
- library search paths. These default to "include" and "lib" respectively.
+ library search paths. These default to include and lib respectively.
* BUILDLINK_CPPFLAGS.pkg (not shown above) is the list of preprocessor flags
to add to CPPFLAGS, which are passed on to the configure and build phases.
- The "-I" option should be avoided and instead be handled using
+ The -I option should be avoided and instead be handled using
BUILDLINK_INCDIRS.pkg as above.
The following variables are all optionally defined within this second section
@@ -5207,7 +5207,7 @@ included:
pulls in the X libraries, so they will show up in the ldd output, while on
others (like OS X) it won't. ldd output can thus only be used as a hint.
-18.2.2. Updating BUILDLINK_API_DEPENDS.pkg and BUILDLINK_ABI_DEPENDS.pkg in
+18.2.2. Updating BUILDLINK_API_DEPENDS.pkg and BUILDLINK_ABI_DEPENDS.pkg in
buildlink3.mk files
Both variables set lower bounds for a version of this package. The two
@@ -5236,7 +5236,7 @@ versions of the packages that use the ne
PKGREVISIONs uniquely identify the packages built against the new ABI. The
pkgtools/revbump package can help with these updates.
-See Section 21.1.5, "Handling dependencies" for more information about
+See Section 21.1.5, Handling dependencies for more information about
dependencies on other packages, including the BUILDLINK_API_DEPENDS
definitions.
@@ -5252,7 +5252,7 @@ Note there is also the distinction that
of ABI dependencies using the USE_ABI_DEPENDS variable, but there is no
equivalent option for API dependencies.
-18.3. Writing builtin.mk files
+18.3. Writing builtin.mk files
Some packages in pkgsrc install headers and libraries that coincide with
headers and libraries present in the base system. Aside from a buildlink3.mk
@@ -5262,7 +5262,7 @@ software is appropriate.
The only requirements of a builtin.mk file for pkg are:
- 1. It should set USE_BUILTIN.pkg to either "yes" or "no" after it is included.
+ 1. It should set USE_BUILTIN.pkg to either yes or no after it is included.
2. It should not override any USE_BUILTIN.pkg which is already set before the
builtin.mk file is included.
@@ -5270,7 +5270,7 @@ The only requirements of a builtin.mk fi
3. It should be written to allow multiple inclusion. This is very important
and takes careful attention to Makefile coding.
-18.3.1. Anatomy of a builtin.mk file
+18.3.1. Anatomy of a builtin.mk file
The following is the recommended template for builtin.mk files:
@@ -5312,12 +5312,12 @@ CHECK_BUILTIN.foo?= no
The first section sets IS_BUILTIN.pkg depending on if pkg really exists in the
base system. This should not be a base system software with similar
-functionality to pkg; it should only be "yes" if the actual package is included
+functionality to pkg; it should only be yes if the actual package is included
as part of the base system. This variable is only used internally within the
builtin.mk file.
The second section sets BUILTIN_PKG.pkg to the version of pkg in the base
-system if it exists (if IS_BUILTIN.pkg is "yes"). This variable is only used
+system if it exists (if IS_BUILTIN.pkg is yes ). This variable is only used
internally within the builtin.mk file.
The third section sets USE_BUILTIN.pkg and is required in all builtin.mk files.
@@ -5326,7 +5326,7 @@ software is adequate to satisfy the depe
BUILDLINK_API_DEPENDS.pkg. This is typically done by comparing BUILTIN_PKG.pkg
against each of the dependencies in BUILDLINK_API_DEPENDS.pkg. USE_BUILTIN.pkg
must be set to the correct value by the end of the builtin.mk file. Note that
-USE_BUILTIN.pkg may be "yes" even if IS_BUILTIN.pkg is "no" because we may make
+USE_BUILTIN.pkg may be yes even if IS_BUILTIN.pkg is no because we may make
the determination that the built-in version of the software is similar enough
to be used as a replacement.
@@ -5335,7 +5335,7 @@ the value of USE_BUILTIN.pkg set in the
includes, e.g., adding additional dependency restrictions and listing
additional files to symlink into ${BUILDLINK_DIR} (via BUILDLINK_FILES.pkg).
-Chapter 19. PLIST issues
+Chapter 19. PLIST issues
Table of Contents
@@ -5349,13 +5349,13 @@ Table of Contents
19.8. Build-specific PLISTs
19.9. Sharing directories between packages
-The PLIST file contains a package's "packing list", i.e. a list of files that
+The PLIST file contains a package's packing list , i.e. a list of files that
belong to the package (relative to the ${PREFIX} directory it's been installed
in) plus some additional statements - see the pkg_create(1) man page for a full
list. This chapter addresses some issues that need attention when dealing with
the PLIST file (or files, see below!).
-19.1. RCS ID
+19.1. RCS ID
Be sure to add a RCS ID line as the first thing in any PLIST file you write:
@@ -5365,13 +5365,13 @@ An artificial space has been added betwe
here to prevent CVS expanding to the filename of the guide. When adding the RCS
ID the space should be omitted.
-19.2. Semi-automatic PLIST generation
+19.2. Semi-automatic PLIST generation
You can use the make print-PLIST command to output a PLIST that matches any new
-files since the package was extracted. See Section 13.17, "Other helpful
-targets" for more information on this target.
+files since the package was extracted. See Section 13.17, Other helpful
+targets for more information on this target.
-19.3. Tweaking output of make print-PLIST
+19.3. Tweaking output of make print-PLIST
The PRINT_PLIST_AWK variable takes a set of AWK patterns and actions that are
used to filter the output of print-PLIST. You can append any chunk of AWK
@@ -5386,7 +5386,7 @@ The PRINT_PLIST_AWK transformations are
directory list are sorted. EARLY_PRINT_PLIST_AWK is like PRINT_PLIST_AWK except
it operates before the file list and directory list are sorted.
-19.4. Variable substitution in PLIST
+19.4. Variable substitution in PLIST
A number of variables are substituted automatically in PLISTs when a package is
installed on a system. This includes the following variables:
@@ -5396,14 +5396,14 @@ ${MACHINE_ARCH}, ${MACHINE_GNU_ARCH}
Some packages like emacs and perl embed information about which
architecture they were built on into the pathnames where they install their
files. To handle this case, PLIST will be preprocessed before actually
- used, and the symbol "${MACHINE_ARCH}" will be replaced by what uname -p
+ used, and the symbol ${MACHINE_ARCH} will be replaced by what uname -p
gives. The same is done if the string ${MACHINE_GNU_ARCH} is embedded in
PLIST somewhere - use this on packages that have GNU autoconf-created
configure scripts.
Legacy note
- There used to be a symbol "$ARCH" that was replaced by the output of uname
+ There used to be a symbol $ARCH that was replaced by the output of uname
-m, but that's no longer supported and has been removed.
${OPSYS}, ${LOWER_OPSYS}, ${OS_VERSION}
@@ -5411,11 +5411,11 @@ ${OPSYS}, ${LOWER_OPSYS}, ${OS_VERSION}
Some packages want to embed the OS name and version into some paths. To do
this, use these variables in the PLIST:
- + ${OPSYS} - output of "uname -s"
+ + ${OPSYS} - output of uname -s
- + ${LOWER_OPSYS} - lowercase common name (eg. "solaris")
+ + ${LOWER_OPSYS} - lowercase common name (eg. solaris )
- + ${OS_VERSION} - "uname -r"
+ + ${OS_VERSION} - uname -r
For a list of values which are replaced by default, the output of make help
topic=PLIST_SUBST as well as searching the pkgsrc/mk directory with grep for
@@ -5423,17 +5423,17 @@ PLIST_SUBST should help.
If you want to change other variables not listed above, you can add variables
and their expansions to this variable in the following way, similar to
-MESSAGE_SUBST (see Section 12.5, "Optional files"):
+MESSAGE_SUBST (see Section 12.5, Optional files ):
PLIST_SUBST+= SOMEVAR="somevalue"
-This replaces all occurrences of "${SOMEVAR}" in the PLIST with "somevalue".
+This replaces all occurrences of ${SOMEVAR} in the PLIST with somevalue .
The PLIST_VARS variable can be used to simplify the common case of
conditionally including some PLIST entries. It can be done by adding
PLIST_VARS+=foo and setting the corresponding PLIST.foo variable to yes if the
-entry should be included. This will substitute "${PLIST.foo}" in the PLIST with
-either """" or ""@comment "". For example, in Makefile:
+entry should be included. This will substitute ${PLIST.foo} in the PLIST with
+either "" or "@comment " . For example, in Makefile:
PLIST_VARS+= foo
.if condition
@@ -5453,22 +5453,22 @@ An artificial space has been added betwe
here to prevent CVS expanding to the filename of the guide. When adding the RCS
ID the space should be omitted.
-19.5. Man page compression
+19.5. Man page compression
Man pages should be installed in compressed form if MANZ is set (in
bsd.own.mk), and uncompressed otherwise. To handle this in the PLIST file, the
-suffix ".gz" is appended/removed automatically for man pages according to MANZ
+suffix .gz is appended/removed automatically for man pages according to MANZ
and MANCOMPRESSED being set or not, see above for details. This modification of
the PLIST file is done on a copy of it, not PLIST itself.
-19.6. Changing PLIST source with PLIST_SRC
+19.6. Changing PLIST source with PLIST_SRC
To use one or more files as source for the PLIST used in generating the binary
package, set the variable PLIST_SRC to the names of that file(s). The files are
later concatenated using cat(1), and the order of things is important. The
default for PLIST_SRC is ${PKGDIR}/PLIST.
-19.7. Platform-specific and differing PLISTs
+19.7. Platform-specific and differing PLISTs
Some packages decide to install a different set of files based on the operating
system being used. These differences can be automatically handled by using the
@@ -5484,7 +5484,7 @@ following files:
* PLIST.common_end
-19.8. Build-specific PLISTs
+19.8. Build-specific PLISTs
Some packages decide to generate hard-to-guess file names during installation
that are hard to wire down.
@@ -5499,9 +5499,9 @@ GENERATE_PLIST+= ${ECHO} bin/${DI
which will append something like bin/xemacs-21.4.23-54e8ea71.dmp to the PLIST.
-19.9. Sharing directories between packages
+19.9. Sharing directories between packages
-A "shared directory" is a directory where multiple (and unrelated) packages
+A shared directory is a directory where multiple (and unrelated) packages
install files. These directories were problematic because you had to add
special tricks in the PLIST to conditionally remove them, or have some
centralized package handle them.
@@ -5517,7 +5517,7 @@ installation as usual, and also add an e
or take a look at MAKE_DIRS and OWN_DIRS.
-Chapter 20. The pkginstall framework
+Chapter 20. The pkginstall framework
Table of Contents
@@ -5565,7 +5565,7 @@ itself could be unavailable). Therefore,
items described above is by means of the installation scripts, which are
automatically generated by pkginstall.
-20.1. Files and directories outside the installation prefix
+20.1. Files and directories outside the installation prefix
As you already know, the PLIST file holds a list of files and directories that
belong to a package. The names used in it are relative to the installation
@@ -5594,7 +5594,7 @@ scripts to abstract the manipulation of
variables set in the package's Makefile. The rest of this section describes
these variables.
-20.1.1. Directory manipulation
+20.1.1. Directory manipulation
The following variables can be set to request the creation of directories
anywhere in the file system:
@@ -5619,7 +5619,7 @@ anywhere in the file system:
The difference between the two is exactly the same as their non-PERMS
counterparts.
-20.1.2. File manipulation
+20.1.2. File manipulation
Creating non-empty files outside the installation prefix is tricky because the
PLIST forces all files to be inside it. To overcome this problem, the only
@@ -5645,16 +5645,16 @@ installation prefix:
* CONF_FILES and CONF_FILES_PERMS have the same syntax as REQD_FILES and
REQD_FILES_PERMS respectively. The difference is that these variables are
specifically intended for handling configuration files, for which
- additional conventions and constraints apply. See Section 20.2,
- "Configuration files" for further discussion. Note in particular that while
+ additional conventions and constraints apply. See Section 20.2,
+ Configuration files for further discussion. Note in particular that while
handling of configuration files can be disabled by the user (see
- Section 20.2.5, "Disabling handling of configuration files"), this setting
+ Section 20.2.5, Disabling handling of configuration files ), this setting
does not affect REQD_FILES and REQD_FILES_PERMS.
To install an empty file, one can use these macros and /dev/null as the
reference file.
-20.2. Configuration files
+20.2. Configuration files
There are two principles that govern the handling of configuration files in
pkgsrc: first, the user's configuration must not be lost or overwritten by
@@ -5685,7 +5685,7 @@ never discarded.)
The following sections describe how to make these things happen and document
other relevant knobs available in the pkgsrc infrastructure.
-20.2.1. How PKG_SYSCONFDIR is set
+20.2.1. How PKG_SYSCONFDIR is set
As said before, the PKG_SYSCONFDIR variable specifies where configuration files
shall be installed. Its contents are set based upon the following variables:
@@ -5726,11 +5726,11 @@ basically the following:
It is worth mentioning that ${PKG_SYSCONFDIR} is automatically added to
OWN_DIRS. This causes it to be automatically created if needed. See
-Section 20.1.1, "Directory manipulation" for further details. This does not
+Section 20.1.1, Directory manipulation for further details. This does not
apply to subdirectories of ${PKG_SYSCONFDIR}; they must be manually created
with OWN_DIRS or MAKE_DIRS.
-20.2.2. Telling the software where configuration files are
+20.2.2. Telling the software where configuration files are
Given that pkgsrc (and users!) expect configuration files to be in a known
place, you need to teach each package where to install its files. In some cases
@@ -5745,7 +5745,7 @@ files, not where they will be installed.
to specify the latter, as seen in the next section, although the combination is
rather confusing at first glance.
-20.2.3. Patching installation
+20.2.3. Patching installation
As discussed above, packages themselves must not touch the contents of $
{PKG_SYSCONFDIR} directly. Bad news is that many software installation scripts
@@ -5767,13 +5767,13 @@ INSTALL_MAKE_FLAGS= ${MAKE_FLAGS} sy
Note that the EGDIR variable, though commonly used for this purpose, is local
to that package and has no meaning outside it.
-20.2.4. Declaring configuration files
+20.2.4. Declaring configuration files
Once the required configuration files are in place (i.e., under the examples
hierarchy), the pkginstall framework can use them as reference copies during
the package installation to update what is in ${PKG_SYSCONFDIR}. To achieve
this, the variables CONF_FILES and CONF_FILES_PERMS are used. Check out
-Section 20.1.2, "File manipulation" for further information about their syntax
+Section 20.1.2, File manipulation for further information about their syntax
and their purpose. Here is an example, taken from the mail/mutt package:
EGDIR= ${PREFIX}/share/examples/mutt
@@ -5790,17 +5790,17 @@ CONF_FILES= ${EGDIR}/Muttrc
INSTALLATION_DIRS+= ${EGDIR}
INSTALL_MAKE_FLAGS= ${MAKE_FLAGS} sysconfdir=${EGDIR}
-20.2.5. Disabling handling of configuration files
+20.2.5. Disabling handling of configuration files
The automatic copying of config files can be toggled by setting the environment
variable PKG_CONFIG prior to package installation.
-20.3. System startup scripts
+20.3. System startup scripts
System startup scripts are special files because they must be installed in a
place known by the underlying OS, usually outside the installation prefix.
-Therefore, the same rules described in Section 20.1, "Files and directories
-outside the installation prefix" apply, and the same solutions can be used.
+Therefore, the same rules described in Section 20.1, Files and directories
+outside the installation prefix apply, and the same solutions can be used.
However, pkginstall provides a special mechanism to handle these files.
In order to provide system startup scripts, the package has to:
@@ -5827,14 +5827,14 @@ automated fashion:
3. Add code to the installation scripts to copy the startup script from the
examples hierarchy into the system-wide startup scripts directory.
-20.3.1. Disabling handling of system startup scripts
+20.3.1. Disabling handling of system startup scripts
The automatic copying of config files can be toggled by setting the environment
variable PKG_RCD_SCRIPTS prior to package installation. Note that the scripts
will be always copied inside the examples hierarchy, ${PREFIX}/share/examples/
rc.d/, no matter what the value of this variable is.
-20.4. System users and groups
+20.4. System users and groups
If a package needs to create special users and/or groups during installation,
it can do so by using the pkginstall framework.
@@ -5863,7 +5863,7 @@ the phase before which the users and gro
numeric UIDs and GIDs of the created users and groups are automatically
hardcoded into the final installation scripts.
-20.5. System shells
+20.5. System shells
Packages that install system shells should register them in the shell database,
/etc/shells, to make things easier to the administrator. This must be done from
@@ -5877,20 +5877,20 @@ shells/zsh:
PKG_SHELL= ${PREFIX}/bin/zsh
-20.5.1. Disabling shell registration
+20.5.1. Disabling shell registration
The automatic registration of shell interpreters can be disabled by the
administrator by setting the PKG_REGISTER_SHELLS environment variable to NO.
-20.6. Fonts
+20.6. Fonts
Packages that install X11 fonts should update the database files that index the
fonts within each fonts directory. This can easily be accomplished within the
pkginstall framework.
When a package installs X11 fonts, it must list the directories in which fonts
-are installed in the FONTS_DIRS.type variables, where type can be one of "ttf",
-"type1" or "x11". This will add hooks to the installation scripts to run the
+are installed in the FONTS_DIRS.type variables, where type can be one of ttf ,
+ type1 or x11 . This will add hooks to the installation scripts to run the
appropriate commands to update the fonts database files within each of those
directories. For convenience, if the directory path is relative, it is taken to
be relative to the package's installation prefix. Consider the following
@@ -5898,12 +5898,12 @@ example, taken from fonts/dbz-ttf:
FONTS_DIRS.ttf= ${PREFIX}/share/fonts/X11/TTF
-20.6.1. Disabling automatic update of the fonts databases
+20.6.1. Disabling automatic update of the fonts databases
The automatic update of fonts databases can be disabled by the administrator by
setting the PKG_UPDATE_FONTS_DB environment variable to NO.
-Chapter 21. Making your package work
+Chapter 21. Making your package work
Table of Contents
@@ -5943,7 +5943,7 @@ Table of Contents
21.5.1. Compiling C and C++ code conditionally
21.5.2. How to handle compiler bugs
21.5.3. No such file or directory
- 21.5.4. Undefined reference to "..."
+ 21.5.4. Undefined reference to ...
21.5.5. Running out of memory
21.6. The install phase
21.6.1. Creating needed directories
@@ -5966,14 +5966,14 @@ Table of Contents
21.6.18. Packages installing desktop files
21.7. Marking packages as having problems
-21.1. General operation
+21.1. General operation
One appealing feature of pkgsrc is that it runs on many different platforms. As
a result, it is important to ensure, where possible, that packages in pkgsrc
are portable. This chapter mentions some particular details you should pay
attention to while working on pkgsrc.
-21.1.1. How to pull in user-settable variables from mk.conf
+21.1.1. How to pull in user-settable variables from mk.conf
The pkgsrc user can configure pkgsrc by overriding several variables in the
file pointed to by MAKECONF, which is mk.conf by default. When you want to use
@@ -5994,7 +5994,7 @@ Note
To check whether a variable can be used at load time, run pkglint -Wall on your
package.
-21.1.2. User interaction
+21.1.2. User interaction
Occasionally, packages require interaction from the user, and this can be in a
number of ways:
@@ -6018,7 +6018,7 @@ INTERACTIVE_STAGE= configure instal
The user can then decide to skip this package by setting the BATCH variable.
Packages that require interaction are also excluded from bulk builds.
-21.1.3. Handling licenses
+21.1.3. Handling licenses
Authors of software can choose the licence under which software can be copied.
The Free Software Foundation has declared some licenses "Free", and the Open
@@ -6079,7 +6079,7 @@ Another problem with such usage is that
pkgsrc to proceed for a single package without also telling pkgsrc to proceed
for all packages with that tag.
-21.1.3.1. Adding a package with a new license
+21.1.3.1. Adding a package with a new license
When adding a package with a new license, the following steps are required:
@@ -6096,7 +6096,7 @@ When adding a package with a new license
2. The license text should be added to pkgsrc/licenses for displaying. A list
of known licenses can be seen in this directory.
-21.1.3.2. Change to the license
+21.1.3.2. Change to the license
When the license changes (in a way other than formatting), make sure that the
new license has a different name (e.g., append the version number if it exists,
@@ -6106,7 +6106,7 @@ under the new licenses. The higher-level
licenses for reasonableness; the only test is a mechanistic test of whether a
particular text has been approved by either of two bodies (FSF or OSI).
-21.1.4. Restricted packages
+21.1.4. Restricted packages
Some licenses restrict how software may be re-distributed. By declaring the
restrictions, package tools can automatically refrain from e.g. placing binary
@@ -6161,20 +6161,20 @@ not distributable and cannot be obtained
branch. Packages with manual/interactive fetch must have a maintainer and it is
his/her responsibility to ensure this.
-21.1.5. Handling dependencies
+21.1.5. Handling dependencies
Your package may depend on some other package being present, and there are
various ways of expressing this dependency. pkgsrc supports the DEPENDS,
BUILD_DEPENDS, TOOL_DEPENDS, and TEST_DEPENDS definitions, the USE_TOOLS
definition, as well as dependencies via buildlink3.mk, which is the preferred
way to handle dependencies, and which uses the variables named above. See
-Chapter 18, Buildlink methodology for more information.
+Chapter 18, Buildlink methodology for more information.
The basic difference is that the DEPENDS definition registers that
pre-requisite in the binary package so it will be pulled in when the binary
package is later installed, whilst the BUILD_DEPENDS, TOOL_DEPENDS, and
TEST_DEPENDS definitions do not, marking a dependency that is only needed for
-building or testing the resulting package. See also Chapter 14, Creating a new
+building or testing the resulting package. See also Chapter 14, Creating a new
pkgsrc package from scratch for more information.
This means that if you only need a package present whilst you are building or
@@ -6188,7 +6188,7 @@ definition is:
<pre-req-package-name>:../../<category>/<pre-req-package>
-Please note that the "pre-req-package-name" may include any of the wildcard
+Please note that the pre-req-package-name may include any of the wildcard
version numbers recognized by pkg_info(1).
1. If your package needs another package's binaries or libraries to build and
@@ -6225,7 +6225,7 @@ version numbers recognized by pkg_info(1
DEPENDS+= tex-latex-bin-[0-9]*:../../print/tex-latex-bin
7. If your package includes a test suite that has extra dependencies only
- required for this purpose (frequently this can be run as a "make test"
+ required for this purpose (frequently this can be run as a make test
target), use the TEST_DEPENDS variable.
8. You can use wildcards in package dependencies. Note that such wildcard
@@ -6233,8 +6233,8 @@ version numbers recognized by pkg_info(1
checked when installing the binary package and any package which matches
the pattern will be used. Wildcard dependencies should be used with care.
- The "-[0-9]*" should be used instead of "-*" to avoid potentially ambiguous
- matches such as "tk-postgresql" matching a "tk-*" DEPENDS.
+ The -[0-9]* should be used instead of -* to avoid potentially ambiguous
+ matches such as tk-postgresql matching a tk-* DEPENDS.
Wildcards can also be used to specify that a package will only build
against a certain minimum version of a pre-requisite:
@@ -6253,7 +6253,7 @@ version numbers recognized by pkg_info(1
.include "../../graphics/jpeg/buildlink3.mk"
For security fixes, please update the package vulnerabilities file. See
- Section 21.1.9, "Handling packages with security problems" for more
+ Section 21.1.9, Handling packages with security problems for more
information.
If your package needs files from another package to build, add the relevant
@@ -6261,7 +6261,7 @@ distribution files to DISTFILES, so they
the print/ghostscript package for an example. (It relies on the jpeg sources
being present in source form during the build.)
-21.1.6. Handling conflicts with other packages
+21.1.6. Handling conflicts with other packages
Your package may conflict with other packages users might already have
installed on their system, e.g., if your package installs the same set of files
@@ -6289,7 +6289,7 @@ is known that packages conflict with eac
exported in pkg_summary(5) files and consumed by binary package managers to
inform users that packages cannot be installed onto the target system.
-21.1.7. Packages that cannot or should not be built
+21.1.7. Packages that cannot or should not be built
There are several reasons why a package might be instructed to not build under
certain circumstances. If the package builds and runs on most platforms, the
@@ -6310,7 +6310,7 @@ Some packages are tightly bound to a spe
e.g. LKMs or sysutils/lsof. Such binary packages are not backwards compatible
with other versions of the OS, and should be uploaded to a version specific
directory on the FTP server. Mark these packages by setting OSVERSION_SPECIFIC
-to "yes". This variable is not currently used by any of the package system
+to yes . This variable is not currently used by any of the package system
internals, but may be used in the future.
If the package should be skipped (for example, because it provides
@@ -6318,15 +6318,15 @@ functionality already provided by the sy
descriptive message. If the package should fail because some preconditions are
not met, set PKG_FAIL_REASON to a descriptive message.
-21.1.8. Packages which should not be deleted, once installed
+21.1.8. Packages which should not be deleted, once installed
To ensure that a package may not be deleted, once it has been installed, the
PKG_PRESERVE definition should be set in the package Makefile. This will be
-carried into any binary package that is made from this pkgsrc entry. A "
-preserved" package will not be deleted using pkg_delete(1) unless the "-f"
+carried into any binary package that is made from this pkgsrc entry. A
+preserved package will not be deleted using pkg_delete(1) unless the -f
option is used.
-21.1.9. Handling packages with security problems
+21.1.9. Handling packages with security problems
When a vulnerability is found, this should be noted in pkgsrc/doc/
pkg-vulnerabilities. Entries in that file consist of three parts:
@@ -6340,14 +6340,14 @@ pkg-vulnerabilities. Entries in that fil
For the package version pattern please always use `<' to mark an upper bound
(not `<='!). This will avoid possible problems due unrelated PKGREVISION bumps
not related to security fixes. Lower bounds can be added too, using '>' or '>=
-'. For example, "foo>=1<1.2" would mark versions 1.0 (included) to 1.2
-(excluded) of "foo" as affected by the security issue.
+'. For example, foo>=1<1.2 would mark versions 1.0 (included) to 1.2
+(excluded) of foo as affected by the security issue.
Entries should always be added at the bottom of the file.
When fixing packages, please modify the upper bound of the corresponding entry.
To continue the previous example, if a fix was backported to version 1.1nb2,
-change the previous pattern to "foo>=1<1.1nb2".
+change the previous pattern to foo>=1<1.1nb2 .
To locally test a package version pattern against a PKGNAME you can use the
pkg_admin pmatch command.
@@ -6372,19 +6372,19 @@ a weekly cron job.
In case a security issue is disputed, please contact
pkgsrc-security%NetBSD.org@localhost.
-21.1.10. How to handle incrementing versions when fixing an existing package
+21.1.10. How to handle incrementing versions when fixing an existing package
When making fixes to an existing package it can be useful to change the version
number in PKGNAME. To avoid conflicting with future versions by the original
-author, a "nb1", "nb2", ... suffix can be used on package versions by setting
-PKGREVISION=1 (2, ...). The "nb" is treated like a "." by the package tools.
+author, a nb1 , nb2 , ... suffix can be used on package versions by setting
+PKGREVISION=1 (2, ...). The nb is treated like a . by the package tools.
e.g.
DISTNAME= foo-17.42
PKGREVISION= 9
-will result in a PKGNAME of "foo-17.42nb9". If you want to use the original
-value of PKGNAME without the "nbX" suffix, e.g. for setting DIST_SUBDIR, use
+will result in a PKGNAME of foo-17.42nb9 . If you want to use the original
+value of PKGNAME without the nbX suffix, e.g. for setting DIST_SUBDIR, use
PKGNAME_NOREV.
When a new release of the package is released, the PKGREVISION should be
@@ -6421,7 +6421,7 @@ Examples of changes that do merit an inc
PKGREVISION must also be incremented when dependencies have ABI changes.
-21.1.11. Substituting variable text in the package files (the SUBST framework)
+21.1.11. Substituting variable text in the package files (the SUBST framework)
When you want to replace the same text in multiple files, or multiple times in
the same file, it is cumbersome to maintain a patch file for this. This is
@@ -6470,7 +6470,7 @@ show-all-subst. If something doesn't wor
package, which detects several typical mistakes surrounding the SUBST blocks.
For any questions that might remain after this, have a look at mk/subst.mk.
-21.1.11.1. Choosing the time where the substitutions happen
+21.1.11.1. Choosing the time where the substitutions happen
The SUBST_STAGE.* is one of {pre,do,post}-
{extract,patch,configure,build,test,install}. Of these, pre-configure is used
@@ -6541,7 +6541,7 @@ pre-install
user names, these belong in pre-configure instead. There are only few
legitimate use cases for applying substitutions in this stage.
-21.1.11.2. Choosing the files where the substitutions happen
+21.1.11.2. Choosing the files where the substitutions happen
The SUBST_FILES.* variable contains a list of filename patterns. These patterns
are relative to WRKSRC since that is where most substitutions happen. A typical
@@ -6580,7 +6580,7 @@ expected), it will complain about these
SUBST blocks that use a shell command to generate the list of filename patterns
often need to set SUBST_NOOP_OK.* to yes.
-21.1.11.3. Choosing what to substitute
+21.1.11.3. Choosing what to substitute
In most cases, the substitutions are given using one or more sed(1) commands,
like this:
@@ -6617,15 +6617,15 @@ This is used for the few remaining packa
Windows-style line endings that need to be converted to UNIX-style line
endings.
-21.1.11.4. Other SUBST variables
+21.1.11.4. Other SUBST variables
When a SUBST block is applied during a package build, a message is logged. The
default message is fine for most purposes but can be overridden by setting
SUBST_MESSAGE.* to an individual message.
-21.2. The fetch phase
+21.2. The fetch phase
-21.2.1. Packages whose distfiles aren't available for plain downloading
+21.2.1. Packages whose distfiles aren't available for plain downloading
If you need to download from a dynamic URL you can set DYNAMIC_MASTER_SITES and
a make fetch will call files/getsite.sh with the name of each file to download
@@ -6641,7 +6641,7 @@ FETCH_MESSAGE= "Please download the fil
FETCH_MESSAGE+= " "${DISTFILES:Q}
FETCH_MESSAGE+= "manually from "${MASTER_SITES:Q}"."
-21.2.2. How to handle modified distfiles with the 'old' name
+21.2.2. How to handle modified distfiles with the 'old' name
Sometimes authors of a software package make some modifications after the
software was released, and they put up a new distfile without changing the
@@ -6656,8 +6656,8 @@ Then, the correct way to work around thi
directory name, usually based on PKGNAME_NOREV (but take care with python or
ruby packages, where PKGNAME includes a variable prefix). All DISTFILES and
PATCHFILES for this package will be put in that subdirectory of the local
-distfiles directory. (See Section 21.1.10, "How to handle incrementing versions
-when fixing an existing package" for more details.) In case this happens more
+distfiles directory. (See Section 21.1.10, How to handle incrementing versions
+when fixing an existing package for more details.) In case this happens more
often, PKGNAME can be used (thus including the nbX suffix) or a date stamp can
be appended, like ${PKGNAME_NOREV}-YYYYMMDD.
@@ -6673,13 +6673,13 @@ installed package is different. Furtherm
seems appropriate telling them that changing distfiles after releases without
changing the file names is not good practice.
-21.2.3. Packages hosted on github.com
+21.2.3. Packages hosted on github.com
Helper methods exist for packages hosted on github.com which will often have
distfile names that clash with other packages, for example 1.0.tar.gz. Use one
of the three recipes from below:
-21.2.3.1. Fetch based on a tagged release
+21.2.3.1. Fetch based on a tagged release
If your distfile URL looks similar to https://github.com/username/example/
archive/v1.0.zip, then you are packaging a tagged release.
@@ -6693,7 +6693,7 @@ EXTRACT_SUFX= .zip
Here, DISTNAME combined with use of GITHUB_TAG leads the file fetching
infrastructure to save the resulting file locally as example-1.0.zip.
-21.2.3.2. Fetch based on a specific commit before the first release
+21.2.3.2. Fetch based on a specific commit before the first release
If your distfile looks similar to https://github.com/username/example/archive/
988881adc9fc3655077dc2d4d757d480b5ea0e11 and is from a commit before the first
@@ -6707,7 +6707,7 @@ MASTER_SITES= ${MASTER_SITE_GITHUB:=us
#GITHUB_PROJECT= example # can be omitted if same as DISTNAME
GITHUB_TAG= 988881adc9fc3655077dc2d4d757d480b5ea0e11
-21.2.3.3. Fetch based on a specific commit after a release
+21.2.3.3. Fetch based on a specific commit after a release
If your distfile looks similar to https://github.com/username/example/archive/
988881adc9fc3655077dc2d4d757d480b5ea0e11 and is from a commit after a release,
@@ -6725,7 +6725,7 @@ MASTER_SITES= ${MASTER_SITE_GITHUB:=us
#GITHUB_PROJECT= example # can be omitted if same as DISTNAME
GITHUB_TAG= 988881adc9fc3655077dc2d4d757d480b5ea0e11
-21.2.3.4. Fetch based on release
+21.2.3.4. Fetch based on release
If your distfile URL looks similar to https://github.com/username/example/
releases/download/rel-1.6/offensive-1.6.zip, then you are packaging a release.
@@ -6737,16 +6737,16 @@ GITHUB_PROJECT= example
GITHUB_RELEASE= rel-${PKGVERSION_NOREV} # usually just set this to ${DISTNAME}
EXTRACT_SUFX= .zip
-21.3. The configure phase
+21.3. The configure phase
-21.3.1. Shared libraries - libtool
+21.3.1. Shared libraries - libtool
pkgsrc supports many different machines, with different object formats like
a.out and ELF, and varying abilities to do shared library and dynamic loading
at all. To accompany this, varying commands and options have to be passed to
the compiler, linker, etc. to get the Right Thing, which can be pretty annoying
especially if you don't have all the machines at your hand to test things. The
-devel/libtool pkg can help here, as it just "knows" how to build both static
+devel/libtool pkg can help here, as it just knows how to build both static
and dynamic libraries from a set of source files, thus being
platform-independent.
@@ -6754,14 +6754,14 @@ Here's how to use libtool in a package i
1. Add USE_LIBTOOL=yes to the package Makefile.
- 2. For library objects, use "${LIBTOOL} --mode=compile ${CC}" in place of "$
- {CC}". You could even add it to the definition of CC, if only libraries are
+ 2. For library objects, use ${LIBTOOL} --mode=compile ${CC} in place of $
+ {CC} . You could even add it to the definition of CC, if only libraries are
being built in a given Makefile. This one command will build both PIC and
non-PIC library objects, so you need not have separate shared and
non-shared library rules.
- 3. For the linking of the library, remove any "ar", "ranlib", and "ld
- -Bshareable" commands, and instead use:
+ 3. For the linking of the library, remove any ar , ranlib , and ld
+ -Bshareable commands, and instead use:
${LIBTOOL} --mode=link \
${CC} -o ${.TARGET:.a=.la} \
@@ -6772,7 +6772,7 @@ Here's how to use libtool in a package i
Note that the library is changed to have a .la extension, and the objects
are changed to have a .lo extension. Change OBJS as necessary. This
automatically creates all of the .a, .so.major.minor, and ELF symlinks (if
- necessary) in the build directory. Be sure to include "-version-info",
+ necessary) in the build directory. Be sure to include -version-info ,
especially when major and minor are zero, as libtool will otherwise strip
off the shared library version.
@@ -6795,27 +6795,27 @@ Here's how to use libtool in a package i
If two libraries have identical CURRENT and AGE numbers, then the
dynamic linker chooses the library with the greater REVISION number.
- The "-release" option will produce different results for a.out and ELF
- (excluding symlinks) in only one case. An ELF library of the form "
- libfoo-release.so.x.y" will have a symlink of "libfoo.so.x.y" on an a.out
+ The -release option will produce different results for a.out and ELF
+ (excluding symlinks) in only one case. An ELF library of the form
+ libfoo-release.so.x.y will have a symlink of libfoo.so.x.y on an a.out
platform. This is handled automatically.
- The "-rpath argument" is the install directory of the library being built.
+ The -rpath argument is the install directory of the library being built.
In the PLIST, include only the .la file, the other files will be added
automatically.
4. When linking shared object (.so) files, i.e. files that are loaded via
- dlopen(3), NOT shared libraries, use "-module -avoid-version" to prevent
+ dlopen(3), NOT shared libraries, use -module -avoid-version to prevent
them getting version tacked on.
The PLIST file gets the foo.so entry.
5. When linking programs that depend on these libraries before they are
- installed, preface the cc(1) or ld(1) line with "${LIBTOOL} --mode=link",
+ installed, preface the cc(1) or ld(1) line with ${LIBTOOL} --mode=link ,
and it will find the correct libraries (static or shared), but please be
aware that libtool will not allow you to specify a relative path in -L
- (such as "-L../somelib"), because it expects you to change that argument to
+ (such as -L../somelib ), because it expects you to change that argument to
be the .la file. e.g.
${LIBTOOL} --mode=link ${CC} -o someprog -L../somelib -lsomelib
@@ -6826,8 +6826,8 @@ Here's how to use libtool in a package i
and it will do the right thing with the libraries.
- 6. When installing libraries, preface the install(1) or cp(1) command with "$
- {LIBTOOL} --mode=install", and change the library name to .la. e.g.
+ 6. When installing libraries, preface the install(1) or cp(1) command with $
+ {LIBTOOL} --mode=install , and change the library name to .la. e.g.
${LIBTOOL} --mode=install ${BSD_INSTALL_LIB} ${SOMELIB:.a=.la} ${PREFIX}/lib
@@ -6837,7 +6837,7 @@ Here's how to use libtool in a package i
7. In your PLIST, include only the .la file (this is a change from previous
behaviour).
-21.3.2. Using libtool on GNU packages that already support libtool
+21.3.2. Using libtool on GNU packages that already support libtool
Add USE_LIBTOOL=yes to the package Makefile. This will override the package's
own libtool in most cases. For older libtool using packages, libtool is made by
@@ -6845,7 +6845,7 @@ ltconfig script during the do-configure
location by doing make configure; find work*/ -name libtool.
LIBTOOL_OVERRIDE specifies which libtool scripts, relative to WRKSRC, to
-override. By default, it is set to "libtool */libtool */*/libtool". If this
+override. By default, it is set to libtool */libtool */*/libtool . If this
does not match the location of the package's libtool script(s), set it as
appropriate.
@@ -6871,7 +6871,7 @@ in some circumstances. Some of the more
The function lt_dlinit() should be called and the macro
LTDL_SET_PRELOADED_SYMBOLS included in executables.
-21.3.3. GNU Autoconf/Automake
+21.3.3. GNU Autoconf/Automake
If a package needs GNU autoconf or automake to be executed to regenerate the
configure script and Makefile.in makefile templates from configure.ac and
@@ -6895,7 +6895,7 @@ automake sequence. This is prevented by
stage. If this causes problems with your package you can set AUTOMAKE_OVERRIDE=
NO in the package Makefile.
-21.3.4. Meson / ninja
+21.3.4. Meson / ninja
Packages using Meson to configure need to include:
@@ -6912,25 +6912,25 @@ CONFIGURE_ARGS:
MESON_ARGS+= -Dx11=false
-21.3.5. Determining the endianness
+21.3.5. Determining the endianness
To determine the endianness of the target platform, have a look at mk/
endian.mk.
-21.4. Programming languages
+21.4. Programming languages
-21.4.1. C, C++, and Fortran
+21.4.1. C, C++, and Fortran
Compilers for the C and C++ languages come with the NetBSD base system. By
default, pkgsrc assumes that a package is written in C and will hide all other
-compilers (via the wrapper framework, see Chapter 18, Buildlink methodology).
+compilers (via the wrapper framework, see Chapter 18, Buildlink methodology).
To declare which languages should be made available through pkgsrc's compiler
wrappers, use the USE_LANGUAGES variable. Allowed values currently are:
c, c++, fortran, fortran77, java, objc, obj-c++, and ada.
-(and any combination). The default is "c". Packages using GNU configure
+(and any combination). The default is c . Packages using GNU configure
scripts, even if written in C++, usually need a C compiler for the configure
phase.
@@ -6964,26 +6964,26 @@ gnu++03, gnu++11, gnu++14, gnu++17, gnu+
Note at present these variables only affect use of GCC and Clang.
-21.4.2. Java
+21.4.2. Java
If a program is written in Java, use the Java framework in pkgsrc. The package
must include ../../mk/java-vm.mk. This Makefile fragment provides the following
variables:
* USE_JAVA defines if a build dependency on the JDK is added. If USE_JAVA is
- set to "run", then there is only a runtime dependency on the JDK. The
- default is "yes", which also adds a build dependency on the JDK.
+ set to run , then there is only a runtime dependency on the JDK. The
+ default is yes , which also adds a build dependency on the JDK.
* Set USE_JAVA2 to declare that a package needs a Java2 implementation. The
- supported values are "yes", "1.4", and "1.5". "yes" accepts any Java2
- implementation, "1.4" insists on versions 1.4 or above, and "1.5" only
+ supported values are yes , 1.4 , and 1.5 . yes accepts any Java2
+ implementation, 1.4 insists on versions 1.4 or above, and 1.5 only
accepts versions 1.5 or above. This variable is not set by default.
* PKG_JAVA_HOME is automatically set to the runtime location of the used Java
implementation dependency. It may be used to set JAVA_HOME to a good value
if the program needs this variable to be defined.
-21.4.3. Go
+21.4.3. Go
If a program is written in Go and has any dependencies on other Go modules,
have the package include ../../lang/go/go-module.mk.
@@ -6995,7 +6995,7 @@ have the package include ../../lang/go/g
3. Incorporate these modules in distinfo with make makesum.
-21.4.4. Rust
+21.4.4. Rust
If a program is written in Rust and uses Cargo to build, have the package
include ../../lang/rust/cargo.mk.
@@ -7007,23 +7007,23 @@ include ../../lang/rust/cargo.mk.
3. Incorporate these modules in distinfo with make makesum.
-21.4.5. Packages containing Perl scripts
+21.4.5. Packages containing Perl scripts
-If your package contains interpreted Perl scripts, add "perl" to the USE_TOOLS
+If your package contains interpreted Perl scripts, add perl to the USE_TOOLS
variable and set REPLACE_PERL to ensure that the proper interpreter path is
set. REPLACE_PERL should contain a list of scripts, relative to WRKSRC, that
you want adjusted. Every occurrence of */bin/perl in a she-bang line will be
replaced with the full path to the Perl executable.
If a particular version of Perl is needed, set the PERL5_REQD variable to the
-version number. The default is "5.0".
+version number. The default is 5.0 .
-See Section 21.6.6, "Packages installing Perl modules" for information about
+See Section 21.6.6, Packages installing Perl modules for information about
handling Perl modules.
There is also the REPLACE_PERL6 variable for the language now known as Raku.
-21.4.6. Packages containing shell scripts
+21.4.6. Packages containing shell scripts
REPLACE_SH, REPLACE_BASH, REPLACE_CSH, and REPLACE_KSH can be used to replace
shell she-bangs in files. Please use the appropriate one, preferring REPLACE_SH
@@ -7032,7 +7032,7 @@ to WRKSRC, that you want adjusted. Every
she-bang line will be replaced with the full path to the shell executable. When
using REPLACE_BASH, don't forget to add bash to USE_TOOLS.
-21.4.7. Other programming languages
+21.4.7. Other programming languages
There are further similar REPLACE variables available, e.g., REPLACE_AWK for
packages containing awk scripts, and REPLACE_R for R. These two, like the
@@ -7042,13 +7042,13 @@ within their own dedicated part of the t
lang/php/replace.mk, and REPLACE_PYTHON is actioned in lang/python/
application.mk. For other languages, consult the mk files found within their
specific directories (the naming convention varies), or check the list found in
-Appendix E, Help topics.
+Appendix E, Help topics.
Currently, special handling for other languages varies in pkgsrc. If a compiler
package provides a buildlink3.mk file, include that, otherwise just add a
(build) dependency on the appropriate compiler package.
-21.5. The build phase
+21.5. The build phase
The most common failures when building a package are that some platforms do not
provide certain header files, functions or libraries, or they provide the
@@ -7056,7 +7056,7 @@ functions in a library that the original
around this, you can rewrite the source code in most cases so that it does not
use the missing functions or provides a replacement function.
-21.5.1. Compiling C and C++ code conditionally
+21.5.1. Compiling C and C++ code conditionally
If a package already comes with a GNU configure script, the preferred way to
fix the build failure is to change the configure script, not the code. In the
@@ -7073,7 +7073,7 @@ the compiler that is used. For example,
code on Solaris, don't use __sun__, as the SunPro compiler does not define it.
Use __sun instead.
-21.5.1.1. C preprocessor macros to identify the operating system
+21.5.1.1. C preprocessor macros to identify the operating system
To distinguish between specific NetBSD versions, you should use the following
code.
@@ -7115,7 +7115,7 @@ NetBSD __NetBSD__
OpenBSD __OpenBSD__
Solaris sun, __sun
-21.5.1.2. C preprocessor macros to identify the hardware architecture
+21.5.1.2. C preprocessor macros to identify the hardware architecture
i386 i386, __i386, __i386__
x86-64 __amd64__, __x86_64__
@@ -7124,14 +7124,14 @@ MIPS __mips
SPARC sparc, __sparc
PowerPC __powerpc
-21.5.1.3. C preprocessor macros to identify the compiler
+21.5.1.3. C preprocessor macros to identify the compiler
GCC __GNUC__ (major version), __GNUC_MINOR__
MIPSpro _COMPILER_VERSION (0x741 for MIPSpro 7.41)
SunPro __SUNPRO_C (0x570 for Sun C 5.7)
SunPro C++ __SUNPRO_CC (0x580 for Sun C++ 5.8)
-21.5.2. How to handle compiler bugs
+21.5.2. How to handle compiler bugs
Some source files trigger bugs in the compiler, based on combinations of
compiler version and architecture and almost always relation to optimisation
@@ -7146,7 +7146,7 @@ technology has matured. If you still nee
workaround, please do so in the file hacks.mk and describe the symptom and
compiler version as detailed as possible.
-21.5.3. No such file or directory
+21.5.3. No such file or directory
Compilation sometimes fails with an error message like this:
@@ -7156,7 +7156,7 @@ Compilation sometimes fails with an erro
The proper way to fix this problem depends on the type of the header, which is
described in the following sections.
-21.5.3.1. Headers from other packages
+21.5.3.1. Headers from other packages
If the header name looks like it comes from a different package, that other
package should be included via the buildlink3 framework.
@@ -7195,7 +7195,7 @@ interactive, realistic environment inclu
and environment variables. From there, try to compile some simple example
programs that use the header.
-21.5.3.2. Headers generated during the build
+21.5.3.2. Headers generated during the build
If the name of the header seems to come from the package itself, and if the
build is run with parallel jobs, the package may have some undeclared
@@ -7222,7 +7222,7 @@ MAKE_JOBS_SAFE=no bmake clean build
If that succeeds, file a bug report against the pkgsrc package, including the
exact error message and the contents of your mk.conf file.
-21.5.3.3. Symlinks
+21.5.3.3. Symlinks
Pkgsrc does not work reliably if any of LOCALBASE, VARBASE or WRKDIR contains a
symlink. Since 2019Q2, the pkgsrc bootstrap program prevents installing pkgsrc
@@ -7232,7 +7232,7 @@ symlinks though.
The "No such file or directory" error messages are a typical symptom of
symlinks, and it's quite difficult to find out that this is the actual cause.
-21.5.3.4. Stale working directories
+21.5.3.4. Stale working directories
When building a hierarchy of packages, it may happen that one package is built
and then pkgsrc is updated. This situation can provoke various hard to diagnose
@@ -7245,7 +7245,7 @@ wrong directory.)
If you have set WRKOBJDIR in mk.conf, remove that directory as well.
-21.5.3.5. Other possible reasons
+21.5.3.5. Other possible reasons
On platforms other than BSD, third-party packages are installed in /usr/
include, together with the base system. This means that pkgsrc cannot
@@ -7259,11 +7259,11 @@ pkg_admin check.
It may help to run pkg_admin rebuild-tree to check/fix dependencies.
-If all of the above doesn't help, see Chapter 2, Getting help for contact
+If all of the above doesn't help, see Chapter 2, Getting help for contact
information. Be prepared to describe what you have tried so far and what any
error messages were.
-21.5.4. Undefined reference to "..."
+21.5.4. Undefined reference to ...
This error message often means that a package did not link to a shared library
it needs. The following functions are known to cause this error message over
@@ -7290,7 +7290,7 @@ and over.
To fix these linker errors, it is often sufficient to add LIBS.OperatingSystem+
= -lfoo to the package Makefile and then run bmake clean; bmake.
-21.5.4.1. The SunPro compiler and inline functions
+21.5.4.1. The SunPro compiler and inline functions
When you are using the SunPro compiler, there is another possibility. That
compiler cannot handle the following code:
@@ -7312,26 +7312,26 @@ It generates the code for inline_func ev
code then refers to extern_func, which can usually not be resolved. To solve
this problem you can try to tell the package to disable inlining of functions.
-21.5.4.2. Missing atomic functions
+21.5.4.2. Missing atomic functions
When building for older machine architectures (e.g., i386, PowerPC), builds may
fail because the package expects modern 64-bit atomic functions which the
underlying hardware either doesn't support, or will only support with specific
compiler flags. This is generally handled via inclusion of mk/atomic64.mk.
-21.5.5. Running out of memory
+21.5.5. Running out of memory
Sometimes packages fail to build because the compiler runs into an operating
system specific soft limit. With the UNLIMIT_RESOURCES variable pkgsrc can be
-told to unlimit the resources. The allowed values are any combination of "
-cputime", "datasize", "memorysize", "stacksize" and "virtualsize". Setting this
+told to unlimit the resources. The allowed values are any combination of
+cputime , datasize , memorysize , stacksize and virtualsize . Setting this
variable is similar to running the shell builtin ulimit command to raise the
maximum data segment size or maximum stack size of a process, respectively, to
their hard limits.
-21.6. The install phase
+21.6. The install phase
-21.6.1. Creating needed directories
+21.6.1. Creating needed directories
The BSD-compatible install supplied with some operating systems cannot create
more than one directory at a time. As such, you should call ${INSTALL_*_DIR}
@@ -7340,18 +7340,18 @@ like this:
${INSTALL_DATA_DIR} ${PREFIX}/dir1
${INSTALL_DATA_DIR} ${PREFIX}/dir2
-Instead of running the install commands directly, you can also append "dir1
-dir2" to the INSTALLATION_DIRS variable, which will automatically do the right
+Instead of running the install commands directly, you can also append dir1
+dir2 to the INSTALLATION_DIRS variable, which will automatically do the right
thing.
-21.6.2. Where to install documentation
+21.6.2. Where to install documentation
In general, documentation should be installed into ${PREFIX}/share/doc/$
{PKGBASE} or ${PREFIX}/share/doc/${PKGNAME_NOREV} (the latter includes the
version number of the package).
Many modern packages using GNU autoconf allow to set the directory where HTML
-documentation is installed with the "--with-html-dir" option. Sometimes using
+documentation is installed with the --with-html-dir option. Sometimes using
this flag is needed because otherwise the documentation ends up in ${PREFIX}/
share/doc/html or other places. In pkgsrc, the HTML documentation should go
into the package-specific directory, just like any other documentation.
@@ -7363,10 +7363,10 @@ can be recognized from files ending in .
acceptable to install such files in ${PREFIX}/share/doc/${PKGBASE} or ${PREFIX}
/share/doc/${PKGNAME}; the .devhelp* file must be directly in that directory
then, no additional subdirectory level is allowed in this case. This is usually
-achieved by using "--with-html-dir=${PREFIX}/share/doc". ${PREFIX}/share/
+achieved by using --with-html-dir=${PREFIX}/share/doc . ${PREFIX}/share/
gtk-doc is preferred though.)
-21.6.3. Installing highscore files
+21.6.3. Installing highscore files
Certain packages, most of them in the games category, install a score file that
allows all users on the system to record their highscores. In order for this to
@@ -7399,16 +7399,16 @@ A package should therefore never hard co
but rely on *_PERMS as described above or alternatively on INSTALL_GAME,
INSTALL_GAME_DATA and INSTALL_GAME_DIR to set these correctly.
-21.6.4. Adding DESTDIR support to packages
+21.6.4. Adding DESTDIR support to packages
DESTDIR support means that a package installs into a staging directory, not the
final location of the files. Then a binary package is created which can be used
for installation as usual. There are two ways: Either the package must install
-as root ("destdir") or the package can install as non-root user ("user-destdir"
+as root ( destdir ) or the package can install as non-root user ( user-destdir
).
- * PKG_DESTDIR_SUPPORT has to be set to "destdir" or "user-destdir". By
- default PKG_DESTDIR_SUPPORT is set to "user-destdir" to help catching more
+ * PKG_DESTDIR_SUPPORT has to be set to destdir or user-destdir . By
+ default PKG_DESTDIR_SUPPORT is set to user-destdir to help catching more
potential packaging problems. If bsd.prefs.mk is included in the Makefile,
PKG_DESTDIR_SUPPORT needs to be set before the inclusion.
@@ -7421,7 +7421,7 @@ as root ("destdir") or the package can i
* In general, packages should support UNPRIVILEGED to be able to use DESTDIR.
-21.6.5. Packages with hardcoded paths to other interpreters
+21.6.5. Packages with hardcoded paths to other interpreters
Your package may also contain scripts with hardcoded paths to other
interpreters besides (or as well as) Perl. To correct the full pathname to the
@@ -7434,7 +7434,7 @@ REPLACE.tcl.new= ${PREFIX}/bin/tc
REPLACE_FILES.tcl= # list of tcl scripts which need to be fixed,
# relative to ${WRKSRC}, just as in REPLACE_PERL
-21.6.6. Packages installing Perl modules
+21.6.6. Packages installing Perl modules
Makefiles of packages providing perl5 modules should include the Makefile
fragment ../../lang/perl5/module.mk. It provides a do-configure target for the
@@ -7458,7 +7458,7 @@ PERL5_, e.g. PERL5_INSTALLARCHLIB and ma
have a packlist. These variables are also substituted for in the PLIST as
uppercase prefixed with PERL5_SUB_.
-21.6.7. Packages installing pkg-config files
+21.6.7. Packages installing pkg-config files
Some packages, usually those providing libraries, install pkg-config files so
that their headers and libraries can easily be found. The file names end with
@@ -7480,23 +7480,23 @@ PKGCONFIG_OVERRIDE+= output/m
PKGCONFIG_OVERRIDE_STAGE= post-build
-21.6.8. Packages installing info files
+21.6.8. Packages installing info files
-Some packages install info files or use the "makeinfo" or "install-info"
+Some packages install info files or use the makeinfo or install-info
commands. INFO_FILES should be defined in the package Makefile so that INSTALL
and DEINSTALL scripts will be generated to handle registration of the info
-files in the Info directory file. The "install-info" command used for the info
+files in the Info directory file. The install-info command used for the info
files registration is either provided by the system, or by a special purpose
package automatically added as dependency if needed.
PKGINFODIR is the directory under ${PREFIX} where info files are primarily
-located. PKGINFODIR defaults to "info" and can be overridden by the user.
+located. PKGINFODIR defaults to info and can be overridden by the user.
The info files for the package should be listed in the package PLIST; however
any split info files need not be listed.
-A package which needs the "makeinfo" command at build time must add "makeinfo"
-to USE_TOOLS in its Makefile. If a minimum version of the "makeinfo" command is
+A package which needs the makeinfo command at build time must add makeinfo
+to USE_TOOLS in its Makefile. If a minimum version of the makeinfo command is
needed it should be noted with the TEXINFO_REQD variable in the package
Makefile. By default, a minimum version of 3.12 is required. If the system does
not provide a makeinfo command or if it does not match the required minimum, a
@@ -7515,13 +7515,13 @@ message. The script overriding makeinfo
value of TEXINFO_REQD either runs the appropriate makeinfo command or exit on
error.
-21.6.9. Packages installing man pages
+21.6.9. Packages installing man pages
All packages that install manual pages should install them into the same
directory, so that there is one common place to look for them. In pkgsrc, this
place is ${PREFIX}/${PKGMANDIR}, and this expression should be used in
-packages. The default for PKGMANDIR is "man". Another often-used value is "
-share/man".
+packages. The default for PKGMANDIR is man . Another often-used value is
+share/man .
Note
@@ -7531,33 +7531,33 @@ The PLIST files can just use man/ as the
file entries, and the pkgsrc framework will convert as needed. In all other
places, the correct PKGMANDIR must be used.
-Packages that are configured with GNU_CONFIGURE set as "yes", by default will
+Packages that are configured with GNU_CONFIGURE set as yes , by default will
use the ./configure --mandir switch to set where the man pages should be
installed. The path is GNU_CONFIGURE_MANDIR which defaults to ${PREFIX}/$
{PKGMANDIR}.
Packages that use GNU_CONFIGURE but do not use --mandir, can set
-CONFIGURE_HAS_MANDIR to "no". Or if the ./configure script uses a non-standard
+CONFIGURE_HAS_MANDIR to no . Or if the ./configure script uses a non-standard
use of --mandir, you can set GNU_CONFIGURE_MANDIR as needed.
-See Section 19.5, "Man page compression" for information on installation of
+See Section 19.5, Man page compression for information on installation of
compressed manual pages.
-21.6.10. Packages installing X11 fonts
+21.6.10. Packages installing X11 fonts
If a package installs font files, you will need to rebuild the fonts database
in the directory where they get installed at installation and deinstallation
time. This can be automatically done by using the pkginstall framework.
You can list the directories where fonts are installed in the FONTS_DIRS.type
-variables, where type can be one of "ttf", "type1" or "x11". Also make sure
+variables, where type can be one of ttf , type1 or x11 . Also make sure
that the database file fonts.dir is not listed in the PLIST.
Note that you should not create new directories for fonts; instead use the
standard ones to avoid that the user needs to manually configure his X server
to find them.
-21.6.11. Packages installing SGML or XML data
+21.6.11. Packages installing SGML or XML data
If a package installs SGML or XML data files that need to be registered in
system-wide catalogs (like DTDs, sub-catalogs, etc.), you need to take some
@@ -7583,7 +7583,7 @@ extra steps:
(specifically, arguments recognized by the 'add' action). Note that you
will normally not use this variable.
-21.6.12. Packages installing extensions to the MIME database
+21.6.12. Packages installing extensions to the MIME database
If a package provides extensions to the MIME database by installing .xml files
inside ${PREFIX}/share/mime/packages, you need to take some extra steps to
@@ -7604,7 +7604,7 @@ ensure that the database is kept consist
3. Remove any share/mime/* directories from the PLIST. They will be handled by
the shared-mime-info package.
-21.6.13. Packages using intltool
+21.6.13. Packages using intltool
If a package uses intltool during its build, add intltool to the USE_TOOLS,
which forces it to use the intltool package provided by pkgsrc, instead of the
@@ -7614,7 +7614,7 @@ This tracks intltool's build-time depend
version; this way, the package benefits of any bug fixes that may have appeared
since it was released.
-21.6.14. Packages installing startup scripts
+21.6.14. Packages installing startup scripts
If a package contains an rc.d script, it won't be copied into the startup
directory (/etc/rc.d) by default, but you can enable copying by setting the
@@ -7626,7 +7626,7 @@ removed only if they have not been modif
Note that this alone does not enable the service: It must still be added to /
etc/rc.conf.
-21.6.15. Packages installing TeX modules
+21.6.15. Packages installing TeX modules
If a package installs TeX packages into the texmf tree, the ls-R database of
the tree needs to be updated.
@@ -7652,7 +7652,7 @@ into ${PREFIX}/share/texmf-dist, not ${P
3. Make sure that none of ls-R databases are included in PLIST, as they will
be removed only by the kpathsea package.
-21.6.16. Packages supporting running binaries in emulation
+21.6.16. Packages supporting running binaries in emulation
There are some packages that provide libraries and executables for running
binaries from a one operating system on a different one (if the latter supports
@@ -7666,7 +7666,7 @@ linker. Since the standard dynamic linke
packages, because the libraries used by the emulation are not in the standard
directories.
-21.6.17. Packages installing hicolor icons
+21.6.17. Packages installing hicolor icons
If a package installs images under the share/icons/hicolor and/or updates the
share/icons/hicolor/icon-theme.cache database, you need to take some extra
@@ -7683,7 +7683,7 @@ that the cache database is rebuilt:
The best way to verify that the PLIST is correct with respect to the last two
points is to regenerate it using make print-PLIST.
-21.6.18. Packages installing desktop files
+21.6.18. Packages installing desktop files
If a package installs .desktop files under share/applications and these include
MIME information (MimeType key), you need to take extra steps to ensure that
@@ -7697,7 +7697,7 @@ they are registered into the MIME databa
The best way to verify that the PLIST is correct with respect to the last point
is to regenerate it using make print-PLIST.
-21.7. Marking packages as having problems
+21.7. Marking packages as having problems
In some cases one does not have the time to solve a problem immediately. In
this case, one can plainly mark a package as broken. For this, one just sets
@@ -7707,7 +7707,7 @@ be shown this message, and the build wil
BROKEN packages are removed from pkgsrc in irregular intervals.
-Chapter 22. GNOME packaging and porting
+Chapter 22. GNOME packaging and porting
Table of Contents
@@ -7738,7 +7738,7 @@ helping our GNOME porting and packaging
how to manage the existing packages and some important information regarding
their internals.
-22.1. Meta packages
+22.1. Meta packages
pkgsrc includes three GNOME-related meta packages:
@@ -7767,7 +7767,7 @@ updates: a package may depend on other p
listed after it. It is very important to keep this order to ease updates so...
do not change it to alphabetical sorting!
-22.2. Packaging a GNOME application
+22.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
@@ -7822,26 +7822,26 @@ directories or files. For each of them,
After applying the solution be sure to regenerate the package's file list with
make print-PLIST and ensure it is correct.
-Table 22.1. PLIST handling for GNOME packages
+Table 22.1. PLIST handling for GNOME packages
+-----------------------------------------------------------------------------+
| If the package... | Then... |
|-------------------------------------------+---------------------------------|
-|Installs icons under the share/icons/ |See Section 21.6.17, "Packages |
-|hicolor hierarchy or updates share/icons/ |installing hicolor icons". |
+|Installs icons under the share/icons/ |See Section 21.6.17, Packages |
+|hicolor hierarchy or updates share/icons/ |installing hicolor icons . |
|hicolor/icon-theme.cache. | |
|-------------------------------------------+---------------------------------|
-| |See Section 21.6.12, "Packages |
+| |See Section 21.6.12, Packages |
|Installs files under share/mime/packages. |installing extensions to the MIME|
-| |database". |
+| |database . |
|-------------------------------------------+---------------------------------|
-|Installs .desktop files under share/ |See Section 21.6.18, "Packages |
-|applications and these include MIME |installing desktop files". |
+|Installs .desktop files under share/ |See Section 21.6.18, Packages |
+|applications and these include MIME |installing desktop files . |
|information. | |
+-----------------------------------------------------------------------------+
-22.3. Updating GNOME to a newer version
+22.3. Updating GNOME to a newer version
When seeing GNOME as a whole, there are two kinds of updates:
@@ -7918,12 +7918,12 @@ In order to update the GNOME components
package updates and all the corresponding changes to the doc/CHANGES-<YEAR>
and pkgsrc/doc/TODO files.
-22.4. Patching guidelines
+22.4. Patching guidelines
GNOME is a very big component in pkgsrc which approaches 100 packages. Please,
it is very important that you always, always, always feed back any portability
fixes you do to a GNOME package to the mainstream developers (see
-Section 12.3.5, "Feedback to the author"). This is the only way to get their
+Section 12.3.5, Feedback to the author ). This is the only way to get their
attention on portability issues and to ensure that future versions can be built
out-of-the box on NetBSD. The less custom patches in pkgsrc, the easier further
updates are. Those developers in charge of issuing major GNOME updates will be
@@ -7941,10 +7941,10 @@ Also, please avoid using preprocessor ma
the FreeBSD GNOME people are doing a great job in porting GNOME to their
operating system, the official GNOME sources are now plagued by conditionals
that check for __FreeBSD__ and similar macros. This hurts portability. Please
-see our patching guidelines (Section 12.3.4, "Patching guidelines") for more
+see our patching guidelines (Section 12.3.4, Patching guidelines ) for more
details.
-Chapter 23. Submitting and Committing
+Chapter 23. Submitting and Committing
Table of Contents
@@ -7957,22 +7957,22 @@ Table of Contents
23.7. Renaming a package in pkgsrc
23.8. Moving a package in pkgsrc
-23.1. Submitting binary packages
+23.1. Submitting binary packages
Our policy is that we accept binaries only from pkgsrc developers to guarantee
that the packages don't contain any trojan horses etc. This is not to annoy
anyone but rather to protect our users! You're still free to put up your
home-made binary packages and tell the world where to get them. NetBSD
-developers doing bulk builds and wanting to upload them please see Chapter 8,
+developers doing bulk builds and wanting to upload them please see Chapter 8,
Creating binary packages for everything in pkgsrc (bulk builds).
-23.2. Submitting source packages (for non-NetBSD-developers)
+23.2. Submitting source packages (for non-NetBSD-developers)
-Firstly, you can import new packages into pkgsrc-wip ("pkgsrc work-in-progress"
+Firstly, you can import new packages into pkgsrc-wip ( pkgsrc work-in-progress
); see the homepage at https://pkgsrc.org/wip/ for details.
Next, check that your package is complete, compiles and runs well; see
-Chapter 14, Creating a new pkgsrc package from scratch and the rest of this
+Chapter 14, Creating a new pkgsrc package from scratch and the rest of this
document. Run the pkgtools/pkglint tool and fix any errors that appear.
Finally, send a report to the pkgsrc bug tracking system, either with the
@@ -7981,12 +7981,12 @@ www.NetBSD.org/support/send-pr.html, whi
link to a form where you can submit packages. The sysutils/gtk-send-pr package
is also available as a substitute for either of the above two tools.
-In the form of the problem report, the category should be "pkg", the synopsis
+In the form of the problem report, the category should be pkg , the synopsis
should include the package name and version number, and the description field
should contain a short description of your package (contents of the COMMENT
variable or DESCR file are OK).
-23.3. General notes when adding, updating, or removing packages
+23.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
@@ -8014,7 +8014,7 @@ commit-changes-entry! If you are not usi
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.
-23.4. Commit Messages
+23.4. Commit Messages
For several years, there have been mirrors of pkgsrc in fossil, git, and hg.
Standard practice when using these tools is to make the first line of a commit
@@ -8044,18 +8044,18 @@ mk/bsd.pkg.mk: enable SSP by default on
(rationale)
-Commit messages are final: no "cvs admin" is allowed on the pkgsrc repository
+Commit messages are final: no cvs admin is allowed on the pkgsrc repository
to change commit messages.
-23.5. Committing: Adding a package to CVS
+23.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
+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:
+by running cvs status . An example:
$ cd .../pkgsrc/category
$ cvs add pkgname
@@ -8075,10 +8075,10 @@ so people reading the mailing lists know
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".
+Previously, cvs import was suggested, but it was much easier to get wrong
+than cvs add .
-23.6. Updating a package to a newer version
+23.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
@@ -8103,7 +8103,7 @@ which pkgsrc is used. Please use your ju
pkgsrc, and bear in mind that stability is to be preferred above new and
possibly untested features.
-23.7. Renaming a package in pkgsrc
+23.7. Renaming a package in pkgsrc
Renaming packages is not recommended.
@@ -8117,11 +8117,11 @@ renames. The new package would be an exa
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
+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.
-23.8. Moving a package in pkgsrc
+23.8. Moving a package in pkgsrc
It is preferred that packages are not renamed or moved, but if needed please
follow these steps.
@@ -8136,8 +8136,8 @@ follow these steps.
and use that for further work.
- 3. Fix CATEGORIES and any DEPENDS paths that just did "../package" instead of
- "../../category/package".
+ 3. Fix CATEGORIES and any DEPENDS paths that just did ../package instead of
+ ../../category/package .
4. In the modified package's Makefile, consider setting PREV_PKGPATH to the
previous category/package pathname. The PREV_PKGPATH can be used by tools
@@ -8169,7 +8169,7 @@ follow these steps.
(and any packages from step 5, of course).
-Chapter 24. pkgsrc Policies
+Chapter 24. pkgsrc Policies
Table of Contents
@@ -8177,7 +8177,7 @@ Table of Contents
24.1.1. Limited Updates - ABI
24.1.2. Limited Updates - Bootstrap
-24.1. Packages for which updating is restricted
+24.1. Packages for which updating is restricted
In the past, some packages have caused more package failures than others, and
we'd like to reduce this in the future.
@@ -8192,7 +8192,7 @@ possible values currently are:
pkglint will warn when committing updates to these packages.
-24.1.1. Limited Updates - ABI
+24.1.1. Limited Updates - ABI
Before committing non-micro version updates to packages marked with
POLICY_UPDATE_LIMITED=abi, a limited bulk build of meta-pkgs/bulk-test-$
@@ -8211,7 +8211,7 @@ Depending on the result, pkgsrc-pmc then
The decision to wait for packages can be revisited.
-24.1.2. Limited Updates - Bootstrap
+24.1.2. Limited Updates - Bootstrap
When updating packages used in the bootstrap, i.e. marked with
POLICY_UPDATE_LIMITED=bootstrap, test the bootstrap process and preferably some
@@ -8219,7 +8219,7 @@ basic packages and send the patch to the
tested on other platforms as well. Give at least two weeks for feedback and
testing by others.
-Chapter 25. Frequently Asked Questions
+Chapter 25. 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
@@ -8271,8 +8271,8 @@ pkgsrc-users mailing list.
25.4. Why does make show-var VARNAME=BUILDLINK_PREFIX.foo say it's empty?
- For optimization reasons, some variables are only available in the "
- wrapper" phase and later. To "simulate" the wrapper phase, append
+ 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.
25.5. What does ${MASTER_SITE_SOURCEFORGE:=package/} mean? I don't understand
@@ -8329,7 +8329,7 @@ pkgsrc-users mailing list.
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
+ * 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
@@ -8344,14 +8344,14 @@ pkgsrc-users mailing list.
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.
+ * Browse pkgsrc/doc/TODO it contains a list of suggested new packages
+ and a list of cleanups and enhancements for pkgsrc that would be nice
+ to have.
* Review packages for which review was requested on the tech-pkg
mailing list.
-Part III. The pkgsrc infrastructure internals
+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
@@ -8380,7 +8380,7 @@ Table of Contents
28. Porting pkgsrc
28.1. Porting pkgsrc to a new operating system
-Chapter 26. Design of the pkgsrc infrastructure
+Chapter 26. Design of the pkgsrc infrastructure
Table of Contents
@@ -8401,7 +8401,7 @@ The pkgsrc infrastructure consists of ma
fragment needs a properly specified interface. This chapter explains how such
an interface looks like.
-26.1. The meaning of variable definitions
+26.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
@@ -8411,7 +8411,7 @@ 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
+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
@@ -8428,26 +8428,26 @@ Note
These conventions are currently not applied consistently to the complete pkgsrc
infrastructure.
-26.2. Avoiding problems before they arise
+26.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
+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
+value ( c ) is so short that it doesn't stand out. Nevertheless it is mentioned
in many files.
-26.3. Variable evaluation
+26.3. Variable evaluation
-26.3.1. At load time
+26.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
@@ -8482,30 +8482,30 @@ paragraph, the -Wall is appended to the
appear in CONFIGURE_ARGS. In actual code, the three paragraphs from above
typically occur in completely unrelated files.
-26.3.2. At runtime
+26.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.
-26.4. How can variables be specified?
+26.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.
-26.5. Designing interfaces for Makefile fragments
+26.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.
-26.5.1. Procedures with parameters
+26.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
+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.
@@ -8529,7 +8529,7 @@ Examples for procedures are mk/bsd.optio
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.
-26.5.2. Actions taken on behalf of parameters
+26.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
@@ -8538,7 +8538,7 @@ explicitly.
An example for action files is mk/subst.mk.
-26.6. The order in which files are loaded
+26.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
@@ -8550,7 +8550,7 @@ the files are loaded matters.
This section describes at which point the various files are loaded and gives
reasons for that order.
-26.6.1. The order in bsd.prefs.mk
+26.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.
@@ -8570,7 +8570,7 @@ As the last steps, some essential variab
system flavor are loaded, as well as the variables that have been cached in
earlier phases of a package build.
-26.6.2. The order in bsd.pkg.mk
+26.6.2. The order in bsd.pkg.mk
First, bsd.prefs.mk is loaded.
@@ -8597,7 +8597,7 @@ execution, though the actual order shoul
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
+Chapter 27. Regression tests
Table of Contents
@@ -8613,23 +8613,23 @@ changes from breaking anything, a suite
with every important part of the pkgsrc infrastructure. This chapter describes
how regression tests work in pkgsrc and how you can add new tests.
-27.1. Running the regression tests
+27.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.
-27.2. Adding a new regression test
+27.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.
-27.2.1. Overridable functions
+27.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
+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
@@ -8669,7 +8669,7 @@ do_cleanup
This function cleans everything up after the test has been run. By default
it does nothing.
-27.2.2. Helper functions
+27.2.2. Helper functions
regress_fail message...
@@ -8695,7 +8695,7 @@ output_prohibit regex...
() does not match the extended regular expression. If any of the regular
expressions matches, the test will fail.
-Chapter 28. Porting pkgsrc
+Chapter 28. Porting pkgsrc
Table of Contents
@@ -8705,7 +8705,7 @@ The pkgsrc system has already been porte
architectures and compilers. This chapter explains the necessary steps to make
pkgsrc even more portable.
-28.1. Porting pkgsrc to a new operating system
+28.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:
@@ -8735,7 +8735,7 @@ mk/tools/tools.MyOS.mk
Now, you should be able to build some basic packages, like lang/perl5, shells/
bash.
-Appendix A. A simple example package: bison
+Appendix A. A simple example package: bison
Table of Contents
@@ -8751,9 +8751,9 @@ and picked GNU bison. Quite why someone
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. files
-A.1.1. Makefile
+A.1.1. Makefile
# $NetBSD$
#
@@ -8771,13 +8771,13 @@ INFO_FILES= yes
.include "../../mk/bsd.pkg.mk"
-A.1.2. DESCR
+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
+A.1.3. PLIST
@comment $NetBSD$
bin/bison
@@ -8785,7 +8785,7 @@ man/man1/bison.1.gz
share/bison.simple
share/bison.hairy
-A.1.4. Checking a package with pkglint
+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
@@ -8804,7 +8804,7 @@ WARN: PLIST:5: "share/bison.hairy" shoul
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
+A.2. Steps for building, installing, packaging
Create the directory where the package lives, plus any auxiliary directories:
@@ -8813,7 +8813,7 @@ Create the directory where the package l
# cd bison
# mkdir patches
-Create Makefile, DESCR and PLIST (see Chapter 12, Package components - files,
+Create Makefile, DESCR and PLIST (see Chapter 12, Package components - files,
directories and contents) then continue with fetching the distfile:
# make fetch
@@ -8919,7 +8919,7 @@ Now that you don't need the source and o
# make clean
===> Cleaning for bison-1.25
-Appendix B. Security hardening
+Appendix B. Security hardening
Table of Contents
@@ -8953,11 +8953,11 @@ For each mechanism, see the Caveats sect
might go wrong at compile time and at run time, and how to notice and address
these problems.
-B.1. Mechanisms
+B.1. Mechanisms
-B.1.1. Enabled by default
+B.1.1. Enabled by default
-B.1.1.1. PKGSRC_USE_FORTIFY
+B.1.1.1. PKGSRC_USE_FORTIFY
This allows substitute wrappers to be used for some commonly used library
functions that do not have built-in bounds checking - but could in some cases.
@@ -8970,7 +8970,7 @@ Two mitigation levels are available:
"strong" has been enabled by default since pkgsrc-2017Q3.
-B.1.1.2. PKGSRC_USE_SSP
+B.1.1.2. PKGSRC_USE_SSP
This enables a stack-smashing protection mitigation. It is done by adding a
guard variable to functions with vulnerable objects. The guards are initialized
@@ -9001,7 +9001,7 @@ More details can be found here:
* Buffer overflow protection on Wikipedia
-B.1.1.3. PKGSRC_MKPIE
+B.1.1.3. PKGSRC_MKPIE
This requests the creation of PIE (Position Independent Executables) for all
executables. The PIE mechanism is normally used for shared libraries, so that
@@ -9018,7 +9018,7 @@ PIE. Currently, this means NetBSD on x86
PKGSRC_MKPIE was enabled by default after the pkgsrc-2021Q3 branch.
-B.1.1.4. PKGSRC_USE_RELRO
+B.1.1.4. PKGSRC_USE_RELRO
This also makes the exploitation of some security vulnerabilities more
difficult in some cases.
@@ -9040,9 +9040,9 @@ More details can be found here:
* Hardening ELF binaries using Relocation Read-Only (RELRO)
-B.1.2. Not enabled by default
+B.1.2. Not enabled by default
-B.1.2.1. PKGSRC_MKREPRO
+B.1.2.1. PKGSRC_MKREPRO
With this option, pkgsrc will try to build packages reproducibly. This allows
packages built from the same tree and with the same options, to produce
@@ -9057,7 +9057,7 @@ More details can be found here:
More work likely needs to be done before pkgsrc is fully reproducible.
-B.1.2.2. PKGSRC_USE_STACK_CHECK
+B.1.2.2. PKGSRC_USE_STACK_CHECK
This uses -fstack-check with GCC for another stack protection mitigation.
@@ -9065,18 +9065,18 @@ It asks the compiler to generate code ve
stack. According to GCC's manual page, this is really only useful for
multi-threaded programs.
-B.2. Caveats
+B.2. Caveats
-B.2.1. Problems with PKGSRC_MKPIE
+B.2.1. Problems with PKGSRC_MKPIE
-B.2.1.1. Packages failing to build
+B.2.1.1. Packages failing to build
A number of packages may fail to build with this option enabled. The failures
are often related to the absence of the -fPIC compilation flag when building
libraries or executables (or ideally -fPIE in the latter case). This flag is
added to the CFLAGS already, but requires the package to actually support it.
-B.2.1.1.1. How to fix
+B.2.1.1.1. How to fix
These instructions are meant as a reference only; they likely need to be
adapted for many packages individually.
@@ -9091,13 +9091,13 @@ For packages using Imakefiles:
MAKE_FLAGS+= CCOPTIONS=${CFLAGS:Q}
MAKE_FLAGS+= LOCAL_LDFLAGS=${LDFLAGS:Q}
-B.2.1.2. Run-time crashes
+B.2.1.2. Run-time crashes
Some programs may fail to run, or crash at random times once built as PIE. Two
scenarios are essentially possible. This is nearly always due to a bug in the
program being exposed due to ASLR.
-B.2.1.3. Disabling PKGSRC_MKPIE on a per-package basis
+B.2.1.3. Disabling PKGSRC_MKPIE on a per-package basis
Ideally, packages should be fixed for compatibility with MKPIE. However, in
some cases this is very difficult, due to complex build systems, packages using
@@ -9107,29 +9107,29 @@ mechanisms.
To disable PKGSRC_MKPIE on a per-package basis, set MKPIE_SUPPORTED= no in the
package's Makefile before bsd.prefs.mk is included.
-B.2.2. Problems with PKGSRC_USE_FORTIFY
+B.2.2. Problems with PKGSRC_USE_FORTIFY
-B.2.2.1. Packages failing to build
+B.2.2.1. Packages failing to build
This feature makes use of pre-processing directives to look for hardened,
alternative implementations of essential library calls. Some programs may fail
to build as a result; this usually happens for those trying too hard to be
portable, or otherwise abusing definitions in the standard library.
-B.2.2.2. Run-time crashes
+B.2.2.2. Run-time crashes
This feature may cause some programs to crash, usually indicating an actual bug
in the program. The fix will typically involve patching the original program's
source code.
-B.2.2.3. Optimization is required
+B.2.2.3. Optimization is required
At least in the case of GCC, FORTIFY will only be applied if optimization is
applied while compiling. This means that the CFLAGS should also contain -O, -O2
or another optimization level. This cannot easily be applied globally, as some
packages may require specific optimization levels.
-B.2.2.4. Disabling FORTIFY on a per-package basis
+B.2.2.4. Disabling FORTIFY on a per-package basis
Note
@@ -9141,9 +9141,9 @@ Makefile before bsd.prefs.mk is included
FORTIFY_SUPPORTED= no
-B.2.3. Problems with PKGSRC_USE_RELRO
+B.2.3. Problems with PKGSRC_USE_RELRO
-B.2.3.1. Performance impact
+B.2.3.1. Performance impact
For better protection, full RELRO requires every symbol to be resolved when the
program starts, rather than simply when required at run-time. This will have
@@ -9155,7 +9155,7 @@ run-time are affected when loading the p
The impact is not expected to be noticeable on modern hardware, except in some
cases for big programs.
-B.2.3.2. Run-time crashes
+B.2.3.2. Run-time crashes
Some programs handle plug-ins and dependencies in a way that conflicts with
RELRO: for instance, with an initialization routine listing any other plug-in
@@ -9164,7 +9164,7 @@ initialization routine can run, and the
them directly and abort as a result. Unfortunately, this is how Xorg loads its
drivers. Partial RELRO can be applied instead in this case.
-B.2.3.3. Disabling RELRO on a per-package basis
+B.2.3.3. Disabling RELRO on a per-package basis
To disable RELRO on a per-package basis, set the following in the package's
Makefile before bsd.prefs.mk is included:
@@ -9174,15 +9174,15 @@ RELRO_SUPPORTED= no
It is also possible to at most enable partial RELRO, by setting RELRO_SUPPORTED
to partial.
-B.2.4. Problems with PKGSRC_USE_SSP
+B.2.4. Problems with PKGSRC_USE_SSP
-B.2.4.1. Packages failing to build
+B.2.4.1. Packages failing to build
The stack-smashing protection provided by this option does not work for some
programs. The most common situation in which this happens is when the program
allocates variables on the stack, with the size determined at run-time.
-B.2.4.2. Run-time crashes
+B.2.4.2. Run-time crashes
Again, this feature may cause some programs to crash via a SIGABRT, usually
indicating an actual bug in the program.
@@ -9204,7 +9204,7 @@ Rebuilding the package via:
and inspecting the backtrace of the coredump via the debugger should point out
the problematic call by inspecting the frame calling the _chk() (SSP) function.
-B.2.4.3. Performance impact
+B.2.4.3. Performance impact
The compiler emits extra code when using this feature: a check for buffer
overflows is performed when entering and exiting functions, requiring an extra
@@ -9216,7 +9216,7 @@ The impact is not expected to be noticea
programs with a hard requirement to run at the fastest possible speed should
avoid using this feature, or using libraries built with this feature.
-B.2.4.4. Disabling SSP on a per-package basis
+B.2.4.4. Disabling SSP on a per-package basis
Note
@@ -9228,7 +9228,7 @@ Makefile before bsd.prefs.mk is included
SSP_SUPPORTED= no
-B.3. Auditing the system
+B.3. Auditing the system
The illusion of security is worse than having no security at all. This section
lists a number of ways to ensure the security features requested are actually
@@ -9237,7 +9237,7 @@ effective.
These instructions were obtained and tested on a system derived from NetBSD 7
(amd64). YMMV.
-B.3.1. Checking for PIE
+B.3.1. Checking for PIE
The ELF executable type in use changes for binaries built as PIE; without:
@@ -9251,7 +9251,7 @@ $ file /path/to/pie/bin/ary
The latter result is then what is expected.
-B.3.2. Checking for partial RELRO
+B.3.2. Checking for partial RELRO
The following command should list a section called RELRO:
@@ -9266,7 +9266,7 @@ Program Header:
This check is now performed automatically if PKG_DEVELOPER is set and RELRO is
enabled.
-B.3.3. Checking for full RELRO
+B.3.3. Checking for full RELRO
The dynamic loader will apply RELRO immediately when detecting the presence of
the BIND_NOW flag:
@@ -9284,7 +9284,7 @@ This has to be combined with partial REL
This check is now performed automatically (where supported) if PKG_DEVELOPER is
set.
-B.3.4. Checking for SSP
+B.3.4. Checking for SSP
Note
@@ -9304,14 +9304,14 @@ This is an indicator that the program wa
This check is now performed automatically (where supported) if PKG_DEVELOPER is
set and SSP is enabled.
-Appendix C. Build logs
+Appendix C. Build logs
Table of Contents
C.1. Building figlet
C.2. Packaging figlet
-C.1. Building figlet
+C.1. Building figlet
# make
===> Checking for vulnerabilities in figlet-2.2.1nb2
@@ -9402,7 +9402,7 @@ cp figlet.6 /usr/pkg/man/man6
===> Registering installation for figlet-2.2.1nb2
#
-C.2. Packaging figlet
+C.2. Packaging figlet
# make package
===> Checking for vulnerabilities in figlet-2.2.1nb2
@@ -9413,7 +9413,7 @@ Using SrcDir value of /usr/pkg
Registering depends:.
#
-Appendix D. Directory layout of the pkgsrc FTP server
+Appendix D. Directory layout of the pkgsrc FTP server
Table of Contents
@@ -9430,7 +9430,7 @@ different, but inside this directory, ev
matter on which server you are. This directory contains some subdirectories,
which are explained below.
-D.1. distfiles: The distributed source files
+D.1. distfiles: The distributed source files
The directory distfiles contains lots of archive files from all pkgsrc
packages, which are mirrored here. The subdirectories are called after their
@@ -9438,12 +9438,12 @@ package names and are used when the dist
explicitly contain a version number or are otherwise too generic (for example
release.tar.gz).
-D.2. misc: Miscellaneous things
+D.2. misc: Miscellaneous things
This directory contains things that individual pkgsrc developers find worth
publishing.
-D.3. packages: Binary packages
+D.3. packages: Binary packages
This directory contains binary packages for the various platforms that are
supported by pkgsrc. Each subdirectory is of the form OPSYS/ARCH/OSVERSION_TAG.
@@ -9474,15 +9474,15 @@ In each of these directories, there is a
specific platform. It has a directory called All which contains all binary
packages.
-D.4. reports: Bulk build reports
+D.4. reports: Bulk build reports
Here are the reports from bulk builds, for those who want to fix packages that
didn't build on some of the platforms. The structure of subdirectories should
-look like the one in Section D.3, "packages: Binary packages".
+look like the one in Section D.3, packages: Binary packages .
-D.5. current, stable, pkgsrc-20xxQy: source packages
+D.5. current, stable, pkgsrc-20xxQy: source packages
-These directories contain the "real" pkgsrc, that is the files that define how
+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
@@ -9504,7 +9504,7 @@ branch of the CVS repository. In these d
called pkgsrc-20xxQy.tar.{bz,gz,xz}, which contains the state of pkgsrc when it
was branched.
-Appendix E. Help topics
+Appendix E. Help topics
The following list contains all help topics that are available when running
bmake help topic=:index.
@@ -9709,8 +9709,7 @@ GIT_TAG GNA
GNU GNU_CONFIGURE
GNU_CONFIGURE_ICONV GNU_CONFIGURE_INFODIR
GNU_CONFIGURE_MANDIR GNU_CONFIGURE_QUIET
-GNU_CONFIGURE_STRICT GODEP_REDIRECTS
-GO_BUILD_PATTERN GO_DEPS
+GNU_CONFIGURE_STRICT GO_BUILD_PATTERN
GO_DIST_BASE GO_EXTRA_MOD_DIRS
GO_MODULE_EXTRACT GO_MODULE_FILES
GO_SRCPATH GROUP_SPECIFIC_PKGS
@@ -9947,233 +9946,234 @@ PTHREAD_AUTO_VARS PTH
PTHREAD_LDFLAGS PTHREAD_LIBS
PTHREAD_OPTS PTHREAD_TYPE
PVM_SSH PYPKGPREFIX
-PYSOABISUFFIX PYTHON_FOR_BUILD_ONLY
-PYTHON_SELF_CONFLICT PYTHON_VERSION
-PYTHON_VERSIONED_DEPENDENCIES PYTHON_VERSIONS_ACCEPTED
-PYTHON_VERSIONS_INCOMPATIBLE PYTHON_VERSION_DEFAULT
-PYTHON_VERSION_REQD PYVERSSUFFIX
-QMAILDIR QMAIL_ALIAS_USER
-QMAIL_DAEMON_USER QMAIL_LOG_USER
-QMAIL_NOFILES_GROUP QMAIL_PASSWD_USER
-QMAIL_QMAIL_GROUP QMAIL_QUEUE_DIR
-QMAIL_QUEUE_EXTRA QMAIL_QUEUE_USER
-QMAIL_REMOTE_USER QMAIL_ROOT_USER
-QMAIL_SEND_USER QORE_LATEST_MODULE_API
-QORE_MODULE_API QORE_MODULE_DIR
-QORE_USER_MODULE_DIR QORE_VERSION
-QPOPPER_FAC QPOPPER_SPOOL_DIR
-QPOPPER_USER RAKE_NAME
-RASMOL_DEPTH RCD_DIR
-RCD_ORDER RCD_SCRIPTS
-RCD_SCRIPTS_DIR RCD_SCRIPTS_EXAMPLEDIR
-RCD_SCRIPTS_MODE RCD_SCRIPTS_SHELL
-RCD_SCRIPT_SRC RCD_SUBR
-RDOC READLINE_DEFAULT
-READLINE_TYPE REAL_ROOT_GROUP
-REAL_ROOT_USER RECURSIVE_MAKE
-RELAY_CTRL_DIR RELRO_SUPPORTED
-REPLACE_AWK REPLACE_BASH
-REPLACE_CSH REPLACE_KSH
-REPLACE_LUA REPLACE_NODEJS
-REPLACE_OCTAVE REPLACE_PERL
-REPLACE_PERL6 REPLACE_PHP
-REPLACE_PYTHON REPLACE_QORE
-REPLACE_R REPLACE_RUBY
-REPLACE_RUBY_DIRS REPLACE_RUBY_PAT
-REPLACE_SH REPLACE_TEXLUA
-REPLACE_TOOL_PYTHON REPLACE_WISH
-REQD_DIRS REQD_DIRS_PERMS
-REQD_FILES REQD_FILES_MODE
-REQD_FILES_PERMS RESOLV_AUTO_VARS
-RESOLV_LDFLAGS RESOLV_LIBS
-RM ROCKSPEC_NAME
-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_MANPAGES
-RUBYGEM_NAME RUBYGEM_OPTIONS
-RUBYGEM_USE_MANPAGES RUBYGEM_VERBOSE
-RUBY_ABI_VERSION RUBY_ARCH
-RUBY_ARCHINC RUBY_ARCHLIB
-RUBY_BASE RUBY_BASERIDIR
-RUBY_BUILD_DOCUMENT RUBY_DLEXT
-RUBY_DOC RUBY_DYNAMIC_DIRS
-RUBY_EG RUBY_ENCODING_ARG
-RUBY_EXTCONF RUBY_EXTCONF_CHECK
-RUBY_EXTCONF_DEBUG RUBY_EXTCONF_MAKEFILE
-RUBY_GEM_ARCH RUBY_GEM_BASE
-RUBY_INC RUBY_LIB
-RUBY_LIB_BASE RUBY_NAME
-RUBY_NOVERSION RUBY_PKGPREFIX
-RUBY_RAILS RUBY_RAILS61_VERSION
-RUBY_RAILS70_VERSION RUBY_RAILS71_VERSION
-RUBY_RAILS72_VERSION RUBY_RAILS80_VERSION
-RUBY_RAILS_ACCEPTED RUBY_RAILS_DEFAULT
-RUBY_RAILS_REQD RUBY_RAILS_STRICT_DEP
-RUBY_RIDIR RUBY_SETUP
-RUBY_SHLIB RUBY_SHLIBALIAS
-RUBY_SHLIBVER RUBY_SIMPLE_INSTALL
-RUBY_SITEARCHLIB RUBY_SITELIB
-RUBY_SITELIB_BASE RUBY_SITERIDIR
-RUBY_SLEXT RUBY_SRCDIR
-RUBY_STATICLIB RUBY_SUFFIX
-RUBY_SYSRIDIR RUBY_USE_PTHREAD
-RUBY_VENDORARCHLIB RUBY_VENDORLIB
-RUBY_VENDORLIB_BASE RUBY_VER
-RUBY_VERSION RUBY_VERSIONS_ACCEPTED
-RUBY_VERSIONS_INCOMPATIBLE RUBY_VERSION_DEFAULT
-RUBY_VERSION_REQD RUBY_VER_DIR
-RUN RUN_LDCONFIG
-RUST_TYPE SCO
-SCREWS_GROUP SCREWS_USER
-SCRIPTS_ENV SCROLLKEEPER_DATADIR
-SCROLLKEEPER_REBUILDDB SCROLLKEEPER_UPDATEDB
-SDIST_PAWD SDL12_TYPE
-SERIAL_DEVICES SETGIDGAME
-SETGID_GAMES_PERMS SETUID_ROOT_PERMS
-SH SHLIB_EXT
-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 SSLCERTBUNDLE
-SSLCERTS SSLDIR
-SSLKEYS SSP_SUPPORTED
-SSYNC_PAWD STEP_MSG
-STRIP STRIP_DBG
-STRIP_DEBUG STRIP_DEBUG_SUPPORTED
-STRIP_FILES_SKIP SU
-SUBDIR SUBST
-SUBST_CLASSES SUBST_FILES
-SUBST_FILTER_CMD SUBST_MESSAGE
-SUBST_NOOP_OK SUBST_SED
-SUBST_SHOW_DIFF SUBST_SKIP_TEXT_CHECK
-SUBST_STAGE SUBST_VARS
-SUNWSPROBASE SUSE_PREFER
-SU_CMD SVN_EXTRACTDIR
-SVN_REPO SVN_REPOSITORIES
-SVN_REVISION SYSCONFBASE
-TARGET_MACHINE_ARCH TBL
-TERMCAP_TYPE TERMINFO_DEFAULT
-TERMINFO_TYPE TEST
-TEST_DEPENDS TEST_DIRS
-TEST_ENV TEST_ENV_SHELL
-TEST_MAKE_CMD TEST_MAKE_FLAGS
-TEST_TARGET TEXLIVE_IGNORE_PATTERNS
-TEXLIVE_REV TEXLIVE_UNVERSIONED
-TEXMFSITE TEX_FORMATS
-TEX_HYPHEN_DAT TEX_HYPHEN_DEF
-TEX_TEXMF_DIRS THTTPD_LOG_FACILITY
-TINYDYN_USER TLS
-TLSWRAPPER_CHROOT TO
-TOOLDIR TOOLS_ALIASES
-TOOLS_ALWAYS_WRAP TOOLS_ARGS
-TOOLS_BROKEN TOOLS_CMD
-TOOLS_CMDLINE_SED TOOLS_CREATE
-TOOLS_CROSS_DESTDIR TOOLS_DIR
-TOOLS_FAIL TOOLS_GNU_MISSING
-TOOLS_LDCONFIG TOOLS_NOOP
-TOOLS_PATH TOOLS_SCRIPT
-TOOLS_USE_CROSS_COMPILE TOOL_DEPENDS
-TTF_FONTDIR TTF_FONTS_DIR
-TYPE UAC_REQD_EXECS
-UCSPI_SSL_GROUP UCSPI_SSL_USER
-UNBOUND_GROUP UNBOUND_LOG_FACILITY
-UNBOUND_USER UNLIMIT_RESOURCES
-UNPRIVILEGED UNPRIVILEGED_GROUP
-UNPRIVILEGED_GROUPS UNPRIVILEGED_USER
-UNWRAP_FILES UNWRAP_PATTERNS
-UPDATE_GEMSPEC UPDATE_TARGET
-URI USERGROUP_PHASE
-USERPPP_GROUP USER_SPECIFIC_PKGS
-USE_ABI_DEPENDS USE_ADA_FEATURES
-USE_APR USE_BSD_MAKEFILE
-USE_BUILTIN USE_CC_FEATURES
-USE_CROSS_COMPILE USE_CURSES
-USE_CWRAPPERS USE_CXX_FEATURES
-USE_DB185 USE_FEATURES
-USE_GAMESGROUP USE_GCC_RUNTIME
-USE_IMAKE USE_INDIRECT_DEPENDS
-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_TMPFILES USE_TOOLS
-UUCP_GROUP UUCP_USER
-VARBASE VARNAME
-VIM_EXTRA_OPTS WARNING_MSG
-WCALC_CGIDIR WCALC_CGIPATH
-WCALC_HTMLDIR WCALC_HTMLPATH
-WDM_MANAGERS WRAPPER_CC
-WRAPPER_REORDER_CMDS WRKDIR
-WRKDIR_BASENAME WRKDIR_LOCKTYPE
-WRKLOG WRKOBJDIR
-WRKSRC X10_PORT
-X11 X11BASE
-X11_PKGSRCDIR X11_TYPE
-X509_CERTIFICATE X509_KEY
-XAW_TYPE XLOCK_DEFAULT_MODE
-XMKMF XMKMF_FLAGS
-XXX XXXX
-YES ZSH_STATIC
-__stdc__ _vargroups
-accept acquire-localbase-lock
-acquire-lock add
-added administrator
-alloca alternatives
-aslr asprintf
-atlas autoconf
-automake autoreconf
-awk barrier
-bash big-endian
-bin-install bind
-binpkg-list blas
-bootstrap-depends broken
-broken_on_platform bsd
-bsd.prog.mk build
-build-env buildlink-directories
-buildlink-oss-soundcard-h built-in
-builtin c
-c++ ccache
-cce cdefs
-ceil changes
-changes-entry changes-entry-noupdate
-check check-clean
-check-files check-files-clean
-check-hackage check-vulnerable
-checksum checksum-phase
-clean clean-depends
-cleandir commit
-commit-changes-entry compact
-compiler conf
-config.guess config.sub
-configuration configure
-configure-env configure-help
-configure_args connect
-cos cpe
-cputime create-usergroup
-csh ctf
-cvs debug
-debug-barrier declaration
-declare defined
-depend dependencies
-depends depends-checksum
-depends-fetch deps
+PYSOABISUFFIX PYTHON_27_ACCEPTED
+PYTHON_FOR_BUILD_ONLY PYTHON_SELF_CONFLICT
+PYTHON_VERSION PYTHON_VERSIONED_DEPENDENCIES
+PYTHON_VERSIONS_ACCEPTED PYTHON_VERSIONS_INCOMPATIBLE
+PYTHON_VERSION_DEFAULT PYTHON_VERSION_REQD
+PYVERSSUFFIX QMAILDIR
+QMAIL_ALIAS_USER QMAIL_DAEMON_USER
+QMAIL_LOG_USER QMAIL_NOFILES_GROUP
+QMAIL_PASSWD_USER QMAIL_QMAIL_GROUP
+QMAIL_QUEUE_DIR QMAIL_QUEUE_EXTRA
+QMAIL_QUEUE_USER QMAIL_REMOTE_USER
+QMAIL_ROOT_USER QMAIL_SEND_USER
+QORE_LATEST_MODULE_API QORE_MODULE_API
+QORE_MODULE_DIR QORE_USER_MODULE_DIR
+QORE_VERSION QPOPPER_FAC
+QPOPPER_SPOOL_DIR QPOPPER_USER
+RAKE_NAME RASMOL_DEPTH
+RCD_DIR RCD_ORDER
+RCD_SCRIPTS RCD_SCRIPTS_DIR
+RCD_SCRIPTS_EXAMPLEDIR RCD_SCRIPTS_MODE
+RCD_SCRIPTS_SHELL RCD_SCRIPT_SRC
+RCD_SUBR RDOC
+READLINE_DEFAULT READLINE_TYPE
+REAL_ROOT_GROUP REAL_ROOT_USER
+RECURSIVE_MAKE RELAY_CTRL_DIR
+RELRO_SUPPORTED REPLACE_AWK
+REPLACE_BASH REPLACE_CSH
+REPLACE_KSH REPLACE_LUA
+REPLACE_NODEJS REPLACE_OCTAVE
+REPLACE_PERL REPLACE_PERL6
+REPLACE_PHP REPLACE_PYTHON
+REPLACE_QORE REPLACE_R
+REPLACE_RUBY REPLACE_RUBY_DIRS
+REPLACE_RUBY_PAT REPLACE_SH
+REPLACE_TEXLUA REPLACE_TOOL_PYTHON
+REPLACE_WISH REQD_DIRS
+REQD_DIRS_PERMS REQD_FILES
+REQD_FILES_MODE REQD_FILES_PERMS
+RESOLV_AUTO_VARS RESOLV_LDFLAGS
+RESOLV_LIBS RM
+ROCKSPEC_NAME 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_MANPAGES RUBYGEM_NAME
+RUBYGEM_OPTIONS RUBYGEM_USE_MANPAGES
+RUBYGEM_VERBOSE RUBY_ABI_VERSION
+RUBY_ARCH RUBY_ARCHINC
+RUBY_ARCHLIB RUBY_BASE
+RUBY_BASERIDIR RUBY_BUILD_DOCUMENT
+RUBY_DLEXT RUBY_DOC
+RUBY_DYNAMIC_DIRS RUBY_EG
+RUBY_ENCODING_ARG RUBY_EXTCONF
+RUBY_EXTCONF_CHECK RUBY_EXTCONF_DEBUG
+RUBY_EXTCONF_MAKEFILE RUBY_GEM_ARCH
+RUBY_GEM_BASE RUBY_INC
+RUBY_LIB RUBY_LIB_BASE
+RUBY_NAME RUBY_NOVERSION
+RUBY_PKGPREFIX RUBY_RAILS
+RUBY_RAILS61_VERSION RUBY_RAILS70_VERSION
+RUBY_RAILS71_VERSION RUBY_RAILS72_VERSION
+RUBY_RAILS80_VERSION RUBY_RAILS_ACCEPTED
+RUBY_RAILS_DEFAULT RUBY_RAILS_REQD
+RUBY_RAILS_STRICT_DEP RUBY_RIDIR
+RUBY_SETUP RUBY_SHLIB
+RUBY_SHLIBALIAS RUBY_SHLIBVER
+RUBY_SIMPLE_INSTALL RUBY_SITEARCHLIB
+RUBY_SITELIB RUBY_SITELIB_BASE
+RUBY_SITERIDIR RUBY_SLEXT
+RUBY_SRCDIR RUBY_STATICLIB
+RUBY_SUFFIX RUBY_SYSRIDIR
+RUBY_USE_PTHREAD RUBY_VENDORARCHLIB
+RUBY_VENDORLIB RUBY_VENDORLIB_BASE
+RUBY_VER RUBY_VERSION
+RUBY_VERSIONS_ACCEPTED RUBY_VERSIONS_INCOMPATIBLE
+RUBY_VERSION_DEFAULT RUBY_VERSION_REQD
+RUBY_VER_DIR RUN
+RUN_LDCONFIG RUST_TYPE
+SCO SCREWS_GROUP
+SCREWS_USER SCRIPTS_ENV
+SCROLLKEEPER_DATADIR SCROLLKEEPER_REBUILDDB
+SCROLLKEEPER_UPDATEDB SDIST_PAWD
+SDL12_TYPE SERIAL_DEVICES
+SETGIDGAME SETGID_GAMES_PERMS
+SETUID_ROOT_PERMS SH
+SHAIRPORT_GROUP SHAIRPORT_USER
+SHLIB_EXT 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
+SSLCERTBUNDLE SSLCERTS
+SSLDIR SSLKEYS
+SSP_SUPPORTED SSYNC_PAWD
+STEP_MSG STRIP
+STRIP_DBG STRIP_DEBUG
+STRIP_DEBUG_SUPPORTED STRIP_FILES_SKIP
+SU SUBDIR
+SUBST SUBST_CLASSES
+SUBST_FILES SUBST_FILTER_CMD
+SUBST_MESSAGE SUBST_NOOP_OK
+SUBST_SED SUBST_SHOW_DIFF
+SUBST_SKIP_TEXT_CHECK SUBST_STAGE
+SUBST_VARS SUNWSPROBASE
+SUSE_PREFER SU_CMD
+SVN_EXTRACTDIR SVN_REPO
+SVN_REPOSITORIES SVN_REVISION
+SYSCONFBASE TARGET_MACHINE_ARCH
+TBL TERMCAP_TYPE
+TERMINFO_DEFAULT TERMINFO_TYPE
+TEST TEST_DEPENDS
+TEST_DIRS TEST_ENV
+TEST_ENV_SHELL TEST_MAKE_CMD
+TEST_MAKE_FLAGS TEST_TARGET
+TEXLIVE_IGNORE_PATTERNS TEXLIVE_REV
+TEXLIVE_UNVERSIONED TEXMFSITE
+TEX_FORMATS TEX_HYPHEN_DAT
+TEX_HYPHEN_DEF TEX_TEXMF_DIRS
+THTTPD_LOG_FACILITY TINYDYN_USER
+TLS TLSWRAPPER_CHROOT
+TO TOOLDIR
+TOOLS_ALIASES TOOLS_ALWAYS_WRAP
+TOOLS_ARGS TOOLS_BROKEN
+TOOLS_CMD TOOLS_CMDLINE_SED
+TOOLS_CREATE TOOLS_CROSS_DESTDIR
+TOOLS_DIR TOOLS_FAIL
+TOOLS_GNU_MISSING TOOLS_LDCONFIG
+TOOLS_NOOP TOOLS_PATH
+TOOLS_SCRIPT TOOLS_USE_CROSS_COMPILE
+TOOL_DEPENDS TTF_FONTDIR
+TTF_FONTS_DIR TYPE
+UAC_REQD_EXECS UCSPI_SSL_GROUP
+UCSPI_SSL_USER UNBOUND_GROUP
+UNBOUND_LOG_FACILITY UNBOUND_USER
+UNLIMIT_RESOURCES UNPRIVILEGED
+UNPRIVILEGED_GROUP UNPRIVILEGED_GROUPS
+UNPRIVILEGED_USER UNWRAP_FILES
+UNWRAP_PATTERNS UPDATE_GEMSPEC
+UPDATE_TARGET URI
+USERGROUP_PHASE USERPPP_GROUP
+USER_SPECIFIC_PKGS USE_ABI_DEPENDS
+USE_ADA_FEATURES USE_APR
+USE_BSD_MAKEFILE USE_BUILTIN
+USE_CC_FEATURES USE_CROSS_COMPILE
+USE_CURSES USE_CWRAPPERS
+USE_CXX_FEATURES USE_DB185
+USE_FEATURES USE_GAMESGROUP
+USE_GCC_RUNTIME USE_IMAKE
+USE_INDIRECT_DEPENDS 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_TMPFILES
+USE_TOOLS UUCP_GROUP
+UUCP_USER VARBASE
+VARNAME VIM_EXTRA_OPTS
+WARNING_MSG WCALC_CGIDIR
+WCALC_CGIPATH WCALC_HTMLDIR
+WCALC_HTMLPATH WDM_MANAGERS
+WRAPPER_CC WRAPPER_REORDER_CMDS
+WRKDIR WRKDIR_BASENAME
+WRKDIR_LOCKTYPE WRKLOG
+WRKOBJDIR WRKSRC
+X10_PORT X11
+X11BASE X11_PKGSRCDIR
+X11_TYPE X509_CERTIFICATE
+X509_KEY XAW_TYPE
+XLOCK_DEFAULT_MODE XMKMF
+XMKMF_FLAGS XXX
+XXXX YES
+ZSH_STATIC __stdc__
+_vargroups accept
+acquire-localbase-lock acquire-lock
+add added
+administrator alloca
+alternatives aslr
+asprintf atlas
+autoconf automake
+autoreconf awk
+barrier bash
+big-endian bin-install
+bind binpkg-list
+blas bootstrap-depends
+broken broken_on_platform
+bsd bsd.prog.mk
+build build-env
+buildlink-directories buildlink-oss-soundcard-h
+built-in builtin
+c c++
+ccache cce
+cdefs ceil
+changes changes-entry
+changes-entry-noupdate check
+check-clean check-files
+check-files-clean check-hackage
+check-vulnerable checksum
+checksum-phase clean
+clean-depends cleandir
+commit commit-changes-entry
+compact compiler
+conf config.guess
+config.sub configuration
+configure configure-env
+configure-help configure_args
+connect cos
+cpe cputime
+create-usergroup csh
+ctf cvs
+debug debug-barrier
+declaration declare
+defined depend
+dependencies depends
+depends-checksum depends-fetch
describe destdir
disable distclean
distfiles distinfo
@@ -10207,60 +10207,59 @@ gettext git
github gitlab
glob gnu
gnu_configure_strict go
-go-deps golang
-guess-license hashbang
-heimdal help
-hg imake
-in-tree increment
-indirect inet_aton
-install install-env
-interp interpreter
-intl ip4
-ip6 ipv4
-ipv6 iso
-kerberos krb
-krb5 ksh
-lapack latex
-libiconv libintl_bindtextdomain
-libintl_gettext libintl_textdomain
-libnbcompat libs
-libtool licence
-license lintl
-little-endian lock
-locking lua
-lvalue machine_endian
-make makedistinfo
-makepatchsum makesum
-mdi memory
-mercurial meta
-meta-package meta_package
-mit-krb5 mk.conf
-mkl mount
-move moved
-mprotect mps
-mremap native
-nb nbcompat
-netlib network
-node node.js
-nodejs obstack
-obstack_ptr_grow occurs
-only openblas
-options options.mk
-order override
-override-intltool override-message-intltool
-package parallel
-path pax
-paxctl pbulk-index
-pc perl
-perl5 perms
-php pkg-build-options
-pkg-config pkg_build_options
-pkgsrc platform
-plist post-extract
-post-fetch post-wrapper
-pre-build-checks-hook pre-configure-checks-hook
-pre-extract pre-fetch
-print-go-deps print-plist
+golang guess-license
+hashbang heimdal
+help hg
+imake in-tree
+increment indirect
+inet_aton install
+install-env interp
+interpreter intl
+ip4 ip6
+ipv4 ipv6
+iso kerberos
+krb krb5
+ksh lapack
+latex libiconv
+libintl_bindtextdomain libintl_gettext
+libintl_textdomain libnbcompat
+libs libtool
+licence license
+lintl little-endian
+lock locking
+lua lvalue
+machine_endian make
+makedistinfo makepatchsum
+makesum mdi
+memory mercurial
+meta meta-package
+meta_package mit-krb5
+mk.conf mkl
+mount move
+moved mprotect
+mps mremap
+native nb
+nbcompat netlib
+network node
+node.js nodejs
+obstack obstack_ptr_grow
+occurs only
+openblas options
+options.mk order
+override override-intltool
+override-message-intltool package
+parallel path
+pax paxctl
+pbulk-index pc
+perl perl5
+perms php
+pkg-build-options pkg-config
+pkg_build_options pkgsrc
+platform plist
+post-extract post-fetch
+post-wrapper pre-build-checks-hook
+pre-configure-checks-hook pre-extract
+pre-fetch print-plist
print-summary-data privileged-install-hook
pypi python
r readme-all
@@ -10312,9 +10311,9 @@ warn war
warnings warnx
wattr_off wattr_on
work wrapper
-wrkdir
+wrkdir
-Appendix F. Editing guidelines for the pkgsrc guide
+Appendix F. Editing guidelines for the pkgsrc guide
Table of Contents
@@ -10323,7 +10322,7 @@ F.2. Procedure
This section contains information on editing the pkgsrc guide itself.
-F.1. Make targets
+F.1. Make targets
The pkgsrc guide's source code is stored in pkgsrc/doc/guide/files, and several
files are created from it:
@@ -10340,7 +10339,7 @@ files are created from it:
* https://www.NetBSD.org/docs/pkgsrc/pkgsrc.ps: PostScript version of the
pkgsrc guide.
-F.2. Procedure
+F.2. Procedure
The procedure to edit the pkgsrc guide is:
Home |
Main Index |
Thread Index |
Old Index