pkgsrc/doc/pkgsrc.html

11380 lines
451 KiB
HTML

<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta name="generator" content=
"HTML Tidy for NetBSD (vers 1st August 2004), see www.w3.org" />
<meta http-equiv="Content-Type" content=
"text/html; charset=us-ascii" />
<title>The pkgsrc guide</title>
<link rel="stylesheet" href="/NetBSD.css" type="text/css" />
<meta name="generator" content=
"DocBook XSL Stylesheets V1.67.0" />
<meta name="description" content=
"Information about using the NetBSD package system (pkgsrc) from both a user view for installing packages as well as from a pkgsrc developers' view for creating new packages." />
</head>
<body bgcolor="white" text="black" link="#0000FF" vlink="#840084"
alink="#0000FF">
<div class="book" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h1 class="title"><a name="id2458392" id=
"id2458392"></a>The pkgsrc guide</h1>
</div>
<div>
<h2 class="subtitle">Documentation on the NetBSD packages
system</h2>
</div>
<div>
<div class="authorgroup">
<div class="author">
<h3 class="author"><span class=
"firstname">Alistair</span> <span class=
"surname">Crooks</span></h3>
<div class="affiliation">
<div class="address">
<p><code class="email">&lt;<a href=
"mailto:agc@NetBSD.org">agc@NetBSD.org</a>&gt;</code></p>
</div>
</div>
</div>
<div class="author">
<h3 class="author"><span class=
"firstname">Hubert</span> <span class=
"surname">Feyrer</span></h3>
<div class="affiliation">
<div class="address">
<p><code class="email">&lt;<a href=
"mailto:hubertf@NetBSD.org">hubertf@NetBSD.org</a>&gt;</code></p>
</div>
</div>
</div>
<h3 class="corpauthor">The pkgsrc Developers</h3>
</div>
</div>
<div>
<p class="copyright">Copyright &#169; 1994-2004 The
NetBSD Foundation, Inc</p>
</div>
<div>
<p class="pubdate">$NetBSD: pkgsrc.xml,v 1.3 2004/10/22
00:24:48 hubertf Exp $</p>
</div>
<div>
<div class="abstract">
<p class="title"><b>Abstract</b></p>
<p>Information about using the NetBSD package system
(pkgsrc) from both a user view for installing packages
as well as from a pkgsrc developers' view for creating
new packages.</p>
</div>
</div>
</div>
<hr />
</div>
<div class="toc">
<p><b>Table of Contents</b></p>
<dl>
<dt><span class="chapter"><a href="#introduction">1.
Introduction</a></span></dt>
<dd>
<dl>
<dt><span class="sect1"><a href="#id2514274">1.1.
Introduction</a></span></dt>
<dt><span class="sect1"><a href="#overview">1.2.
Overview</a></span></dt>
<dt><span class="sect1"><a href="#terminology">1.3.
Terminology</a></span></dt>
<dt><span class="sect1"><a href="#typography">1.4.
Typography</a></span></dt>
</dl>
</dd>
<dt><span class="part"><a href="#users-guide">I. The pkgsrc
user's guide</a></span></dt>
<dd>
<dl>
<dt><span class="chapter"><a href="#getting">2. Where
to get pkgsrc</a></span></dt>
<dd>
<dl>
<dt><span class="sect1"><a href="#id2514852">2.1.
As tar file</a></span></dt>
<dt><span class="sect1"><a href="#id2514868">2.2.
Via SUP</a></span></dt>
<dt><span class="sect1"><a href="#id2514968">2.3.
Via CVS</a></span></dt>
</dl>
</dd>
<dt><span class="chapter"><a href="#platforms">3. Using
pkgsrc on systems other than NetBSD</a></span></dt>
<dd>
<dl>
<dt><span class="sect1"><a href="#id2515078">3.1.
Bootstrapping pkgsrc</a></span></dt>
<dt><span class="sect1"><a href="#id2515253">3.2.
Platform specific notes</a></span></dt>
<dd>
<dl>
<dt><span class="sect2"><a href=
"#id2515259">3.2.1. Darwin (Mac OS
X)</a></span></dt>
<dt><span class="sect2"><a href=
"#id2515558">3.2.2. FreeBSD</a></span></dt>
<dt><span class="sect2"><a href=
"#id2515660">3.2.3. Interix</a></span></dt>
<dt><span class="sect2"><a href=
"#id2515751">3.2.4. IRIX</a></span></dt>
<dt><span class="sect2"><a href=
"#id2516278">3.2.5. OpenBSD</a></span></dt>
<dt><span class="sect2"><a href=
"#id2516390">3.2.6. Solaris</a></span></dt>
</dl>
</dd>
</dl>
</dd>
<dt><span class="chapter"><a href="#using">4. Using
pkgsrc</a></span></dt>
<dd>
<dl>
<dt><span class="sect1"><a href=
"#getting-started">4.1. Working with binary
packages</a></span></dt>
<dd>
<dl>
<dt><span class="sect2"><a href=
"#id2516526">4.1.1. Where to get binary
packages</a></span></dt>
<dt><span class="sect2"><a href=
"#id2516567">4.1.2. How to use binary
packages</a></span></dt>
<dt><span class="sect2"><a href=
"#id2516633">4.1.3. A word of
warning</a></span></dt>
</dl>
</dd>
<dt><span class="sect1"><a href="#id2516645">4.2.
Building packages from source</a></span></dt>
<dd>
<dl>
<dt><span class="sect2"><a href=
"#id2516723">4.2.1.
Requirements</a></span></dt>
<dt><span class="sect2"><a href=
"#id2516743">4.2.2. Fetching
distfiles</a></span></dt>
<dt><span class="sect2"><a href=
"#id2516864">4.2.3. How to build and
install</a></span></dt>
<dt><span class="sect2"><a href=
"#id2517180">4.2.4. Selecting the
compiler</a></span></dt>
</dl>
</dd>
</dl>
</dd>
<dt><span class="chapter"><a href="#binary">5. Creating
binary packages</a></span></dt>
<dd>
<dl>
<dt><span class="sect1"><a href="#id2517335">5.1.
Building a single binary package</a></span></dt>
<dt><span class="sect1"><a href="#id2517822">5.2.
Settings for creation of binary
packages</a></span></dt>
<dt><span class="sect1"><a href="#bulkbuild">5.3.
Doing a bulk build of all packages</a></span></dt>
<dd>
<dl>
<dt><span class="sect2"><a href=
"#binary.configuration">5.3.1.
Configuration</a></span></dt>
<dt><span class="sect2"><a href=
"#id2517962">5.3.2. Other environmental
considerations</a></span></dt>
<dt><span class="sect2"><a href=
"#id2518003">5.3.3. Operation</a></span></dt>
<dt><span class="sect2"><a href=
"#id2583267">5.3.4. What it
does</a></span></dt>
<dt><span class="sect2"><a href=
"#id2583392">5.3.5. Disk space
requirements</a></span></dt>
<dt><span class="sect2"><a href=
"#id2583418">5.3.6. Setting up a sandbox for
chroot'ed builds</a></span></dt>
<dt><span class="sect2"><a href=
"#id2583811">5.3.7. Building a partial set of
packages</a></span></dt>
<dt><span class="sect2"><a href=
"#bulk-upload">5.3.8. Uploading results of a
bulk build</a></span></dt>
</dl>
</dd>
<dt><span class="sect1"><a href="#id2584227">5.4.
Creating a multiple CD-ROM packages
collection</a></span></dt>
<dd>
<dl>
<dt><span class="sect2"><a href=
"#id2584310">5.4.1. Example of
cdpack</a></span></dt>
</dl>
</dd>
</dl>
</dd>
<dt><span class="chapter"><a href="#faq">6. Frequently
Asked Questions</a></span></dt>
<dd>
<dl>
<dt><span class="sect1"><a href="#id2584502">6.1.
Is there a mailing list for pkg-related
discussion?</a></span></dt>
<dt><span class="sect1"><a href="#id2584600">6.2.
Where's the pkgviews documentation?</a></span></dt>
<dt><span class="sect1"><a href=
"#faq-pkgtools">6.3. Utilities for package
management (pkgtools)</a></span></dt>
<dt><span class="sect1"><a href="#id2584853">6.4.
How to use pkgsrc as non-root</a></span></dt>
<dt><span class="sect1"><a href="#id2584865">6.5.
How to resume transfers when fetching
distfiles?</a></span></dt>
<dt><span class="sect1"><a href="#id2584907">6.6.
How can I install/use XFree86 from
pkgsrc?</a></span></dt>
<dt><span class="sect1"><a href="#id2584935">6.7.
How can I install/use X.org from
pkgsrc?</a></span></dt>
<dt><span class="sect1"><a href="#id2584963">6.8.
How to fetch files from behind a
firewall</a></span></dt>
<dt><span class="sect1"><a href="#id2584977">6.9.
How do I tell <span><strong class="command">make
fetch</strong></span> to do passive
FTP?</a></span></dt>
<dt><span class="sect1"><a href="#id2585028">6.10.
How to fetch all distfiles at once</a></span></dt>
<dt><span class="sect1"><a href="#id2585168">6.11.
What does &#8220;<span class="quote">Don't know how
to make /usr/share/tmac/tmac.andoc</span>&#8221;
mean?</a></span></dt>
<dt><span class="sect1"><a href="#id2585206">6.12.
What does &#8220;<span class="quote">Could not find
bsd.own.mk</span>&#8221; mean?</a></span></dt>
<dt><span class="sect1"><a href="#id2585264">6.13.
Using 'sudo' with pkgsrc</a></span></dt>
<dt><span class="sect1"><a href="#faq.conf">6.14.
Configuration files handling and
placement</a></span></dt>
<dt><span class="sect1"><a href=
"#audit-packages">6.15. Automated security
checks</a></span></dt>
</dl>
</dd>
</dl>
</dd>
<dt><span class="part"><a href="#developers-guide">II. The
pkgsrc developer's guide</a></span></dt>
<dd>
<dl>
<dt><span class="chapter"><a href="#components">7.
Package components - files, directories and
contents</a></span></dt>
<dd>
<dl>
<dt><span class="sect1"><a href=
"#components.Makefile">7.1. <code class=
"filename">Makefile</code></a></span></dt>
<dt><span class="sect1"><a href=
"#components.distinfo">7.2. <code class=
"filename">distinfo</code></a></span></dt>
<dt><span class="sect1"><a href=
"#components.patches">7.3.
patches/*</a></span></dt>
<dt><span class="sect1"><a href="#id2586445">7.4.
Other mandatory files</a></span></dt>
<dt><span class="sect1"><a href=
"#components.optional">7.5. Optional
files</a></span></dt>
<dt><span class="sect1"><a href="#id2586640">7.6.
<code class="filename">work*</code></a></span></dt>
<dt><span class="sect1"><a href="#id2586727">7.7.
<code class=
"filename">files/*</code></a></span></dt>
</dl>
</dd>
<dt><span class="chapter"><a href="#plist">8. PLIST
issues</a></span></dt>
<dd>
<dl>
<dt><span class="sect1"><a href="#id2586781">8.1.
RCS ID</a></span></dt>
<dt><span class="sect1"><a href="#id2586796">8.2.
Semi-automatic <code class="filename">PLIST</code>
generation</a></span></dt>
<dt><span class="sect1"><a href="#print-PLIST">8.3.
Tweaking output of <span><strong class=
"command">make
print-PLIST</strong></span></a></span></dt>
<dt><span class="sect1"><a href="#plist.misc">8.4.
Variable substitution in PLIST</a></span></dt>
<dt><span class="sect1"><a href="#id2587186">8.5.
Manpage-compression</a></span></dt>
<dt><span class="sect1"><a href="#id2587227">8.6.
Changing PLIST source with <code class=
"varname">PLIST_SRC</code></a></span></dt>
<dt><span class="sect1"><a href="#id2587244">8.7.
Platform specific and differing
PLISTs</a></span></dt>
<dt><span class="sect1"><a href=
"#faq.common-dirs">8.8. Sharing directories between
packages</a></span></dt>
</dl>
</dd>
<dt><span class="chapter"><a href="#buildlink">9.
Buildlink methodology</a></span></dt>
<dd>
<dl>
<dt><span class="sect1"><a href="#id2587653">9.1.
Converting packages to use
buildlink3</a></span></dt>
<dt><span class="sect1"><a href="#id2587844">9.2.
Writing <code class="filename">buildlink3.mk</code>
files</a></span></dt>
<dd>
<dl>
<dt><span class="sect2"><a href=
"#id2587913">9.2.1. Anatomy of a buildlink3.mk
file</a></span></dt>
<dt><span class="sect2"><a href=
"#id2588354">9.2.2. Updating <code class=
"varname">BUILDLINK_DEPENDS.<em class=
"replaceable"><code>pkg</code></em></code> in
<code class="filename">buildlink3.mk</code>
files</a></span></dt>
</dl>
</dd>
<dt><span class="sect1"><a href="#id2588433">9.3.
Writing <code class="filename">builtin.mk</code>
files</a></span></dt>
<dd>
<dl>
<dt><span class="sect2"><a href=
"#id2588582">9.3.1. Anatomy of a <code class=
"filename">builtin.mk</code>
file</a></span></dt>
<dt><span class="sect2"><a href=
"#id2588877">9.3.2. Global preferences for
native or pkgsrc software</a></span></dt>
</dl>
</dd>
</dl>
</dd>
<dt><span class="chapter"><a href="#options">10.
Options handling</a></span></dt>
<dd>
<dl>
<dt><span class="sect1"><a href="#id2588950">10.1.
Global default options</a></span></dt>
<dt><span class="sect1"><a href="#id2588965">10.2.
Converting packages to use <code class=
"filename">bsd.options.mk</code></a></span></dt>
</dl>
</dd>
<dt><span class="chapter"><a href="#build">11. The
build process</a></span></dt>
<dd>
<dl>
<dt><span class="sect1"><a href=
"#build.prefix">11.1. Program
location</a></span></dt>
<dt><span class="sect1"><a href="#id2589573">11.2.
Main targets</a></span></dt>
<dt><span class="sect1"><a href=
"#build.helpful-targets">11.3. Other helpful
targets</a></span></dt>
</dl>
</dd>
<dt><span class="chapter"><a href="#fixes">12. Notes on
fixes for packages</a></span></dt>
<dd>
<dl>
<dt><span class="sect1"><a href="#id2590973">12.1.
General operation</a></span></dt>
<dd>
<dl>
<dt><span class="sect2"><a href=
"#id2590977">12.1.1. How to pull in variables
from /etc/mk.conf</a></span></dt>
<dt><span class="sect2"><a href=
"#id2591128">12.1.2. Restricted
packages</a></span></dt>
<dt><span class="sect2"><a href=
"#dependencies">12.1.3. Handling
dependencies</a></span></dt>
<dt><span class="sect2"><a href=
"#id2591643">12.1.4. Handling conflicts with
other packages</a></span></dt>
<dt><span class="sect2"><a href=
"#id2591762">12.1.5. Packages that cannot or
should not be built</a></span></dt>
<dt><span class="sect2"><a href=
"#id2591787">12.1.6. Packages which should not
be deleted, once installed</a></span></dt>
<dt><span class="sect2"><a href=
"#security-handling">12.1.7. Handling packages
with security problems</a></span></dt>
<dt><span class="sect2"><a href=
"#id2591879">12.1.8. How to handle compiler
bugs</a></span></dt>
<dt><span class="sect2"><a href=
"#id2591901">12.1.9. How to handle incrementing
versions when fixing an existing
package</a></span></dt>
<dt><span class="sect2"><a href=
"#id2591950">12.1.10. Portability of
packages</a></span></dt>
</dl>
</dd>
<dt><span class="sect1"><a href="#id2591975">12.2.
Possible downloading issues</a></span></dt>
<dd>
<dl>
<dt><span class="sect2"><a href=
"#id2591978">12.2.1. Packages whose distfiles
aren't available for plain
downloading</a></span></dt>
<dt><span class="sect2"><a href=
"#id2592109">12.2.2. How to handle modified
distfiles with the 'old' name</a></span></dt>
</dl>
</dd>
<dt><span class="sect1"><a href="#id2592121">12.3.
Configuration gotchas</a></span></dt>
<dd>
<dl>
<dt><span class="sect2"><a href=
"#fixes.libtool">12.3.1. Shared libraries -
libtool</a></span></dt>
<dt><span class="sect2"><a href=
"#id2592529">12.3.2. Using libtool on GNU
packages that already support
libtool</a></span></dt>
<dt><span class="sect2"><a href=
"#id2592613">12.3.3. GNU
Autoconf/Automake</a></span></dt>
</dl>
</dd>
<dt><span class="sect1"><a href="#id2592726">12.4.
Building considerations</a></span></dt>
<dd>
<dl>
<dt><span class="sect2"><a href=
"#id2592729">12.4.1. CPP
defines</a></span></dt>
</dl>
</dd>
<dt><span class="sect1"><a href="#id2592759">12.5.
Package specific actions</a></span></dt>
<dd>
<dl>
<dt><span class="sect2"><a href=
"#id2592762">12.5.1. Package configuration
files</a></span></dt>
<dt><span class="sect2"><a href=
"#id2592933">12.5.2. User
interaction</a></span></dt>
<dt><span class="sect2"><a href=
"#id2593046">12.5.3. Handling
licenses</a></span></dt>
<dt><span class="sect2"><a href=
"#id2593197">12.5.4. Creating an account from a
package</a></span></dt>
<dt><span class="sect2"><a href=
"#id2593328">12.5.5. Installing score
files</a></span></dt>
<dt><span class="sect2"><a href=
"#id2593371">12.5.6. Packages providing login
shells</a></span></dt>
<dt><span class="sect2"><a href=
"#id2593429">12.5.7. Packages containing perl
scripts</a></span></dt>
<dt><span class="sect2"><a href=
"#id2593447">12.5.8. Packages with hardcoded
paths to other interpreters</a></span></dt>
<dt><span class="sect2"><a href=
"#id2593468">12.5.9. Packages installing perl
modules</a></span></dt>
<dt><span class="sect2"><a href=
"#faq.info-files">12.5.10. Packages installing
info files</a></span></dt>
<dt><span class="sect2"><a href=
"#id2593688">12.5.11. Packages installing
GConf2 data files</a></span></dt>
<dt><span class="sect2"><a href=
"#id2593788">12.5.12. Packages installing
scrollkeeper data files</a></span></dt>
<dt><span class="sect2"><a href=
"#id2593840">12.5.13. Packages installing X11
fonts</a></span></dt>
<dt><span class="sect2"><a href=
"#id2593886">12.5.14. Packages installing GTK2
modules</a></span></dt>
<dt><span class="sect2"><a href=
"#id2593956">12.5.15. Packages installing SGML
or XML data</a></span></dt>
<dt><span class="sect2"><a href=
"#id2594076">12.5.16. Packages installing
extensions to the MIME database</a></span></dt>
<dt><span class="sect2"><a href=
"#id2594283">12.5.17. Packages using
intltool</a></span></dt>
</dl>
</dd>
<dt><span class="sect1"><a href="#id2594297">12.6.
Feedback to the author</a></span></dt>
</dl>
</dd>
<dt><span class="chapter"><a href="#debug">13.
Debugging</a></span></dt>
<dt><span class="chapter"><a href="#submit">14.
Submitting and Committing</a></span></dt>
<dd>
<dl>
<dt><span class="sect1"><a href="#id2594827">14.1.
Submitting your packages</a></span></dt>
<dt><span class="sect1"><a href="#id2594878">14.2.
Committing: Importing a package into
CVS</a></span></dt>
<dt><span class="sect1"><a href="#id2594941">14.3.
Updating a package to a newer
version</a></span></dt>
<dt><span class="sect1"><a href="#id2594961">14.4.
Moving a package in pkgsrc</a></span></dt>
</dl>
</dd>
</dl>
</dd>
<dt><span class="appendix"><a href="#examples">A. A simple
example package: bison</a></span></dt>
<dd>
<dl>
<dt><span class="sect1"><a href="#id2595255">A.1.
files</a></span></dt>
<dd>
<dl>
<dt><span class="sect2"><a href="#id2595258">A.1.1.
Makefile</a></span></dt>
<dt><span class="sect2"><a href="#id2595266">A.1.2.
DESCR</a></span></dt>
<dt><span class="sect2"><a href="#id2595281">A.1.3.
PLIST</a></span></dt>
<dt><span class="sect2"><a href="#id2595288">A.1.4.
Checking a package with <span><strong class=
"command">pkglint</strong></span></a></span></dt>
</dl>
</dd>
<dt><span class="sect1"><a href="#id2595329">A.2. Steps
for building, installing, packaging</a></span></dt>
</dl>
</dd>
<dt><span class="appendix"><a href="#logs">B. Build
logs</a></span></dt>
<dd>
<dl>
<dt><span class="sect1"><a href="#logs.building">B.1.
Building figlet</a></span></dt>
<dt><span class="sect1"><a href="#logs.package">B.2.
Packaging figlet</a></span></dt>
</dl>
</dd>
<dt><span class="appendix"><a href="#ftp-layout">C. Layout
of the FTP server's package archive</a></span></dt>
<dt><span class="appendix"><a href="#editing">D. Editing
guidelines for the pkgsrc guide</a></span></dt>
<dd>
<dl>
<dt><span class="sect1"><a href="#id2595975">D.1.
Targets</a></span></dt>
<dt><span class="sect1"><a href="#id2596387">D.2.
Procedure</a></span></dt>
</dl>
</dd>
</dl>
</div>
<div class="chapter" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h2 class="title"><a name="introduction" id=
"introduction"></a>Chapter&nbsp;1.&nbsp;Introduction</h2>
</div>
</div>
</div>
<div class="toc">
<p><b>Table of Contents</b></p>
<dl>
<dt><span class="sect1"><a href="#id2514274">1.1.
Introduction</a></span></dt>
<dt><span class="sect1"><a href="#overview">1.2.
Overview</a></span></dt>
<dt><span class="sect1"><a href="#terminology">1.3.
Terminology</a></span></dt>
<dt><span class="sect1"><a href="#typography">1.4.
Typography</a></span></dt>
</dl>
</div>
<div class="sect1" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h2 class="title" style="clear: both"><a name=
"id2514274" id=
"id2514274"></a>1.1.&nbsp;Introduction</h2>
</div>
</div>
</div>
<p>There is a lot of software freely available for Unix
based systems, which usually runs on NetBSD and other
Unix-flavoured systems, too, sometimes with some
modifications. The NetBSD Packages Collection (pkgsrc)
incorporates any such changes necessary to make that
software run, and makes the installation (and
de-installation) of the software package easy by means of a
single command.</p>
<p>Once the software has been built, it is manipulated with
the <span><strong class="command">pkg_*</strong></span>
tools so that installation and de-installation, printing of
an inventory of all installed packages and retrieval of
one-line comments or more verbose descriptions are all
simple.</p>
<p>pkgsrc currently contains several thousand packages,
including:</p>
<div class="itemizedlist">
<ul type="disc">
<li>
<p><a xmlns=
"http://www.w3.org/TR/xhtml1/transitional" href=
"ftp://ftp.NetBSD.org/pub/NetBSD/packages/pkgsrc/www/apache/README.html"
class="pkgname">www/apache</a> - The Apache web
server</p>
</li>
<li>
<p><a xmlns=
"http://www.w3.org/TR/xhtml1/transitional" href=
"ftp://ftp.NetBSD.org/pub/NetBSD/packages/pkgsrc/www/mozilla/README.html"
class="pkgname">www/mozilla</a> - The Mozilla web
browser</p>
</li>
<li>
<p><a xmlns=
"http://www.w3.org/TR/xhtml1/transitional" href=
"ftp://ftp.NetBSD.org/pub/NetBSD/packages/pkgsrc/meta-pkgs/gnome/README.html"
class="pkgname">meta-pkgs/gnome</a> - The GNOME
Desktop Environment</p>
</li>
<li>
<p><a xmlns=
"http://www.w3.org/TR/xhtml1/transitional" href=
"ftp://ftp.NetBSD.org/pub/NetBSD/packages/pkgsrc/meta-pkgs/kde3/README.html"
class="pkgname">meta-pkgs/kde3</a> - The K Desktop
Environment</p>
</li>
</ul>
</div>
<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>
<p>pkgsrc was derived from FreeBSD's ports system, and
initially developed for NetBSD only. Since then, pkgsrc has
grown a lot, and now supports the following platforms:</p>
<div class="itemizedlist">
<ul type="disc">
<li>
<p><a href="http://developer.apple.com/darwin/"
target="_top">Darwin</a> (<a href=
"http://www.apple.com/macosx/" target="_top">Mac OS
X</a>)</p>
</li>
<li>
<p><a href="http://www.DragonFlyBSD.org/" target=
"_top">DragonFlyBSD</a></p>
</li>
<li>
<p><a href="http://www.FreeBSD.org/" target=
"_top">FreeBSD</a></p>
</li>
<li>
<p>Microsoft Windows, via <a href=
"http://www.microsoft.com/windows/sfu/" target=
"_top">Interix</a></p>
</li>
<li>
<p><a href="http://www.sgi.com/software/irix6.5/"
target="_top">IRIX</a></p>
</li>
<li>
<p><a href="http://www.linux.org/" target=
"_top">Linux</a></p>
</li>
<li>
<p><a href="http://www.NetBSD.org/" target=
"_top">NetBSD</a> (of course)</p>
</li>
<li>
<p><a href="http://www.openbsd.org/" target=
"_top">OpenBSD</a></p>
</li>
<li>
<p><a href="http://www.sun.com/solaris/" target=
"_top">Solaris</a></p>
</li>
</ul>
</div>
</div>
<div class="sect1" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h2 class="title" style="clear: both"><a name=
"overview" id="overview"></a>1.2.&nbsp;Overview</h2>
</div>
</div>
</div>
<p>This document is divided into two parts. The first,
<a href="#users-guide" title=
"Part&nbsp;I.&nbsp;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 href=
"#developers-guide" title=
"Part&nbsp;II.&nbsp;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.</p>
<p>This document is available in various formats:</p>
<div class="itemizedlist">
<ul type="disc">
<li>
<p><a href="index.html" target="_top">HTML</a></p>
</li>
<li>
<p><a href="pkgsrc.pdf" target="_top">PDF</a></p>
</li>
<li>
<p><a href="pkgsrc.ps" target="_top">PS</a></p>
</li>
<li>
<p><a href="pkgsrc.txt" target="_top">TXT</a></p>
</li>
</ul>
</div>
</div>
<div class="sect1" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h2 class="title" style="clear: both"><a name=
"terminology" id=
"terminology"></a>1.3.&nbsp;Terminology</h2>
</div>
</div>
</div>
<p>There has been a lot of talk about &#8220;<span class=
"quote">ports</span>&#8221;, &#8220;<span class=
"quote">packages</span>&#8221;, etc. so far. Here is a
description of all the terminology used within this
document.</p>
<div class="variablelist">
<dl>
<dt><span class="term">Package</span></dt>
<dd>
<p>A set of files and building instructions that
describe what's necessary to build a certain piece of
software using pkgsrc. Packages are traditionally
stored under <code class=
"filename">/usr/pkgsrc</code>.</p>
</dd>
<dt><span class="term">The NetBSD package
system</span></dt>
<dd>
<p>This is the former name of &#8220;<span class=
"quote">pkgsrc</span>&#8221;. It is part of the
NetBSD operating system and can be bootstrap to run
on non-NetBSD operating systems as well. It handles
building (compiling), installing, and removing of
packages.</p>
</dd>
<dt><span class="term">Distfile</span></dt>
<dd>
<p>This term describes the file or files that are
provided by the author of the piece of software to
distribute his work. All the changes necessary to
build on NetBSD are reflected in the corresponding
package. Usually the distfile is in the form of a
compressed tar-archive, but other types are possible,
too. Distfiles are usually stored below <code class=
"filename">/usr/pkgsrc/distfiles</code>.</p>
</dd>
<dt><span class="term">Port</span></dt>
<dd>
<p>This is the term used by FreeBSD and OpenBSD
people for what we call a package. In NetBSD
terminology, &#8220;<span class=
"quote">port</span>&#8221; refers to a different
architecture.</p>
</dd>
<dt><span class="term">Precompiled/binary
package</span></dt>
<dd>
<p>A set of binaries built with pkgsrc from a
distfile and stuffed together in a single
<code class="filename">.tgz</code> file so it can be
installed on machines of the same machine
architecture without the need to recompile. Packages
are usually generated in <code class=
"filename">/usr/pkgsrc/packages</code>; there is also
an archive on <a href=
"ftp://ftp.NetBSD.org/pub/NetBSD/packages/" target=
"_top">ftp.NetBSD.org</a>.</p>
<p>Sometimes, this is referred to by the term
&#8220;<span class="quote">package</span>&#8221; too,
especially in the context of precompiled
packages.</p>
</dd>
<dt><span class="term">Program</span></dt>
<dd>
<p>The piece of software to be installed which will
be constructed from all the files in the Distfile by
the actions defined in the corresponding package.</p>
</dd>
</dl>
</div>
</div>
<div class="sect1" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h2 class="title" style="clear: both"><a name=
"typography" id=
"typography"></a>1.4.&nbsp;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 &#8220;<span class="quote">normal</span>&#8221; user
privileges are sufficient. We use a <code class=
"prompt">#</code> for root's shell prompt, and a
<code class="prompt">$</code> for users' shell prompt,
assuming they use the C-shell or tcsh.</p>
</div>
</div>
<div class="part" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h1 class="title"><a name="users-guide" id=
"users-guide"></a>The pkgsrc user's guide</h1>
</div>
</div>
</div>
<div class="toc">
<p><b>Table of Contents</b></p>
<dl>
<dt><span class="chapter"><a href="#getting">2. Where to
get pkgsrc</a></span></dt>
<dd>
<dl>
<dt><span class="sect1"><a href="#id2514852">2.1. As
tar file</a></span></dt>
<dt><span class="sect1"><a href="#id2514868">2.2. Via
SUP</a></span></dt>
<dt><span class="sect1"><a href="#id2514968">2.3. Via
CVS</a></span></dt>
</dl>
</dd>
<dt><span class="chapter"><a href="#platforms">3. Using
pkgsrc on systems other than NetBSD</a></span></dt>
<dd>
<dl>
<dt><span class="sect1"><a href="#id2515078">3.1.
Bootstrapping pkgsrc</a></span></dt>
<dt><span class="sect1"><a href="#id2515253">3.2.
Platform specific notes</a></span></dt>
<dd>
<dl>
<dt><span class="sect2"><a href=
"#id2515259">3.2.1. Darwin (Mac OS
X)</a></span></dt>
<dt><span class="sect2"><a href=
"#id2515558">3.2.2. FreeBSD</a></span></dt>
<dt><span class="sect2"><a href=
"#id2515660">3.2.3. Interix</a></span></dt>
<dt><span class="sect2"><a href=
"#id2515751">3.2.4. IRIX</a></span></dt>
<dt><span class="sect2"><a href=
"#id2516278">3.2.5. OpenBSD</a></span></dt>
<dt><span class="sect2"><a href=
"#id2516390">3.2.6. Solaris</a></span></dt>
</dl>
</dd>
</dl>
</dd>
<dt><span class="chapter"><a href="#using">4. Using
pkgsrc</a></span></dt>
<dd>
<dl>
<dt><span class="sect1"><a href=
"#getting-started">4.1. Working with binary
packages</a></span></dt>
<dd>
<dl>
<dt><span class="sect2"><a href=
"#id2516526">4.1.1. Where to get binary
packages</a></span></dt>
<dt><span class="sect2"><a href=
"#id2516567">4.1.2. How to use binary
packages</a></span></dt>
<dt><span class="sect2"><a href=
"#id2516633">4.1.3. A word of
warning</a></span></dt>
</dl>
</dd>
<dt><span class="sect1"><a href="#id2516645">4.2.
Building packages from source</a></span></dt>
<dd>
<dl>
<dt><span class="sect2"><a href=
"#id2516723">4.2.1. Requirements</a></span></dt>
<dt><span class="sect2"><a href=
"#id2516743">4.2.2. Fetching
distfiles</a></span></dt>
<dt><span class="sect2"><a href=
"#id2516864">4.2.3. How to build and
install</a></span></dt>
<dt><span class="sect2"><a href=
"#id2517180">4.2.4. Selecting the
compiler</a></span></dt>
</dl>
</dd>
</dl>
</dd>
<dt><span class="chapter"><a href="#binary">5. Creating
binary packages</a></span></dt>
<dd>
<dl>
<dt><span class="sect1"><a href="#id2517335">5.1.
Building a single binary package</a></span></dt>
<dt><span class="sect1"><a href="#id2517822">5.2.
Settings for creation of binary
packages</a></span></dt>
<dt><span class="sect1"><a href="#bulkbuild">5.3.
Doing a bulk build of all packages</a></span></dt>
<dd>
<dl>
<dt><span class="sect2"><a href=
"#binary.configuration">5.3.1.
Configuration</a></span></dt>
<dt><span class="sect2"><a href=
"#id2517962">5.3.2. Other environmental
considerations</a></span></dt>
<dt><span class="sect2"><a href=
"#id2518003">5.3.3. Operation</a></span></dt>
<dt><span class="sect2"><a href=
"#id2583267">5.3.4. What it does</a></span></dt>
<dt><span class="sect2"><a href=
"#id2583392">5.3.5. Disk space
requirements</a></span></dt>
<dt><span class="sect2"><a href=
"#id2583418">5.3.6. Setting up a sandbox for
chroot'ed builds</a></span></dt>
<dt><span class="sect2"><a href=
"#id2583811">5.3.7. Building a partial set of
packages</a></span></dt>
<dt><span class="sect2"><a href=
"#bulk-upload">5.3.8. Uploading results of a bulk
build</a></span></dt>
</dl>
</dd>
<dt><span class="sect1"><a href="#id2584227">5.4.
Creating a multiple CD-ROM packages
collection</a></span></dt>
<dd>
<dl>
<dt><span class="sect2"><a href=
"#id2584310">5.4.1. Example of
cdpack</a></span></dt>
</dl>
</dd>
</dl>
</dd>
<dt><span class="chapter"><a href="#faq">6. Frequently
Asked Questions</a></span></dt>
<dd>
<dl>
<dt><span class="sect1"><a href="#id2584502">6.1. Is
there a mailing list for pkg-related
discussion?</a></span></dt>
<dt><span class="sect1"><a href="#id2584600">6.2.
Where's the pkgviews documentation?</a></span></dt>
<dt><span class="sect1"><a href="#faq-pkgtools">6.3.
Utilities for package management
(pkgtools)</a></span></dt>
<dt><span class="sect1"><a href="#id2584853">6.4. How
to use pkgsrc as non-root</a></span></dt>
<dt><span class="sect1"><a href="#id2584865">6.5. How
to resume transfers when fetching
distfiles?</a></span></dt>
<dt><span class="sect1"><a href="#id2584907">6.6. How
can I install/use XFree86 from
pkgsrc?</a></span></dt>
<dt><span class="sect1"><a href="#id2584935">6.7. How
can I install/use X.org from pkgsrc?</a></span></dt>
<dt><span class="sect1"><a href="#id2584963">6.8. How
to fetch files from behind a firewall</a></span></dt>
<dt><span class="sect1"><a href="#id2584977">6.9. How
do I tell <span><strong class="command">make
fetch</strong></span> to do passive
FTP?</a></span></dt>
<dt><span class="sect1"><a href="#id2585028">6.10.
How to fetch all distfiles at once</a></span></dt>
<dt><span class="sect1"><a href="#id2585168">6.11.
What does &#8220;<span class="quote">Don't know how
to make /usr/share/tmac/tmac.andoc</span>&#8221;
mean?</a></span></dt>
<dt><span class="sect1"><a href="#id2585206">6.12.
What does &#8220;<span class="quote">Could not find
bsd.own.mk</span>&#8221; mean?</a></span></dt>
<dt><span class="sect1"><a href="#id2585264">6.13.
Using 'sudo' with pkgsrc</a></span></dt>
<dt><span class="sect1"><a href="#faq.conf">6.14.
Configuration files handling and
placement</a></span></dt>
<dt><span class="sect1"><a href=
"#audit-packages">6.15. Automated security
checks</a></span></dt>
</dl>
</dd>
</dl>
</div>
<div class="chapter" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h2 class="title"><a name="getting" id=
"getting"></a>Chapter&nbsp;2.&nbsp;Where to get
pkgsrc</h2>
</div>
</div>
</div>
<div class="toc">
<p><b>Table of Contents</b></p>
<dl>
<dt><span class="sect1"><a href="#id2514852">2.1. As
tar file</a></span></dt>
<dt><span class="sect1"><a href="#id2514868">2.2. Via
SUP</a></span></dt>
<dt><span class="sect1"><a href="#id2514968">2.3. Via
CVS</a></span></dt>
</dl>
</div>
<p>There are three ways to get pkgsrc. Either as a tar
file, via SUP, or via CVS. All three ways are described
here.</p>
<div class="sect1" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h2 class="title" style="clear: both"><a name=
"id2514852" id="id2514852"></a>2.1.&nbsp;As tar
file</h2>
</div>
</div>
</div>
<p>To get pkgsrc going, you need to get the pkgsrc.tar.gz
file from <a href=
"ftp://ftp.NetBSD.org/pub/NetBSD/NetBSD-current/tar_files/pkgsrc.tar.gz"
target="_top">ftp.NetBSD.org</a> and unpack it into
<code class="filename">/usr/pkgsrc</code>.</p>
</div>
<div class="sect1" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h2 class="title" style="clear: both"><a name=
"id2514868" id="id2514868"></a>2.2.&nbsp;Via
SUP</h2>
</div>
</div>
</div>
<p>As an alternative to the tar file, you can get pkgsrc
via the Software Update Protocol, SUP. To do so, make
sure your supfile has a line</p>
<pre class="programlisting">
release=pkgsrc
</pre>
<p>in it, see the examples in <code class=
"filename">/usr/share/examples/supfiles</code>, and that
the <code class="filename">/usr/pkgsrc</code> directory
exists. Then, simply run <span><strong class=
"command">sup -v <em class=
"replaceable"><code>/path/to/your/supfile</code></em></strong></span>.</p>
</div>
<div class="sect1" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h2 class="title" style="clear: both"><a name=
"id2514968" id="id2514968"></a>2.3.&nbsp;Via
CVS</h2>
</div>
</div>
</div>
<p>To get pkgsrc via CVS, make sure you have
&#8220;<span class="quote">cvs</span>&#8221; installed.
If not present on your system, it can be found as
precompiled binary on ftp.NetBSD.org. To do an initial
(full) checkout of pkgsrc, do the following steps:</p>
<pre class="screen">
<code class="prompt">%</code> <strong class=
"userinput"><code>setenv CVSROOT anoncvs@anoncvs.NetBSD.org:/cvsroot</code></strong>
<code class="prompt">%</code> <strong class=
"userinput"><code>setenv CVS_RSH ssh</code></strong>
<code class="prompt">%</code> <strong class=
"userinput"><code>cd /usr</code></strong>
<code class="prompt">%</code> <strong class=
"userinput"><code>cvs checkout -P pkgsrc</code></strong>
</pre>
<p>This will create the <code class=
"filename">pkgsrc</code> directory in your <code class=
"filename">/usr</code>, and all the package source will
be stored under <code class=
"filename">/usr/pkgsrc</code>. To update pkgsrc after the
initial checkout, make sure you have <code class=
"varname">CVS_RSH</code> set as above, then do:</p>
<pre class="screen">
<code class="prompt">%</code> <strong class=
"userinput"><code>cd /usr/pkgsrc</code></strong>
<code class="prompt">%</code> <strong class=
"userinput"><code>cvs -q update -dP</code></strong>
</pre>
<p>Please also note that it is possible to have multiple
copies of the pkgsrc hierarchy in use at any one time -
all work is done relatively within the pkgsrc tree.</p>
</div>
</div>
<div class="chapter" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h2 class="title"><a name="platforms" id=
"platforms"></a>Chapter&nbsp;3.&nbsp;Using pkgsrc on
systems other than NetBSD</h2>
</div>
</div>
</div>
<div class="toc">
<p><b>Table of Contents</b></p>
<dl>
<dt><span class="sect1"><a href="#id2515078">3.1.
Bootstrapping pkgsrc</a></span></dt>
<dt><span class="sect1"><a href="#id2515253">3.2.
Platform specific notes</a></span></dt>
<dd>
<dl>
<dt><span class="sect2"><a href="#id2515259">3.2.1.
Darwin (Mac OS X)</a></span></dt>
<dt><span class="sect2"><a href="#id2515558">3.2.2.
FreeBSD</a></span></dt>
<dt><span class="sect2"><a href="#id2515660">3.2.3.
Interix</a></span></dt>
<dt><span class="sect2"><a href="#id2515751">3.2.4.
IRIX</a></span></dt>
<dt><span class="sect2"><a href="#id2516278">3.2.5.
OpenBSD</a></span></dt>
<dt><span class="sect2"><a href="#id2516390">3.2.6.
Solaris</a></span></dt>
</dl>
</dd>
</dl>
</div>
<div class="sect1" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h2 class="title" style="clear: both"><a name=
"id2515078" id=
"id2515078"></a>3.1.&nbsp;Bootstrapping pkgsrc</h2>
</div>
</div>
</div>
<p>For Operating Systems other than NetBSD, we provide a
bootstrap kit to build the required tools to use pkgsrc
on your platform. Besides support for native NetBSD,
pkgsrc and the bootstrap kit have support for the
following operating systems:</p>
<div class="itemizedlist">
<ul type="disc">
<li>
<p>Darwin (Mac OS X)</p>
</li>
<li>
<p>FreeBSD</p>
</li>
<li>
<p>Interix (Windows 2000, XP, 2003)</p>
</li>
<li>
<p>IRIX</p>
</li>
<li>
<p>Linux</p>
</li>
<li>
<p>OpenBSD</p>
</li>
<li>
<p>Solaris</p>
</li>
</ul>
</div>
<p>Support for other platforms is under development.</p>
<p>Installing the bootstrap kit should be as simple
as:</p>
<pre class="screen">
<code class="prompt">#</code> <strong class=
"userinput"><code>env CVS_RSH=ssh cvs -d anoncvs@anoncvs.NetBSD.org:/cvsroot checkout pkgsrc</code></strong>
<code class="prompt">#</code> <strong class=
"userinput"><code>cd pkgsrc/bootstrap</code></strong>
<code class="prompt">#</code> <strong class=
"userinput"><code>./bootstrap</code></strong>
</pre>
<p>See <a href="#getting" title=
"Chapter&nbsp;2.&nbsp;Where to get pkgsrc">Chapter 2,
<i>Where to get pkgsrc</i></a> for other ways to get
pkgsrc before bootstrapping. The given
<span><strong class="command">bootstrap</strong></span>
command will use the defaults of <code class=
"filename">/usr/pkg</code> for the <span class=
"emphasis"><em>prefix</em></span> where programs will be
installed in, and <code class=
"filename">/var/db/pkg</code> for the package database
directory where pkgsrc will do it's internal bookkeeping.
However, these can also be set using command-line
parameters.</p>
<p>Binary packages for the pkgsrc tools and an initial
set of packages is available for supported platforms. An
up-to-date list of these can be found on <a href=
"http://www.pkgsrc.org/" target=
"_top">www.pkgsrc.org</a>.</p>
</div>
<div class="sect1" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h2 class="title" style="clear: both"><a name=
"id2515253" id="id2515253"></a>3.2.&nbsp;Platform
specific notes</h2>
</div>
</div>
</div>
<p>Here are some platform-specific notes you should be
aware of.</p>
<div class="sect2" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h3 class="title"><a name="id2515259" id=
"id2515259"></a>3.2.1.&nbsp;Darwin (Mac OS
X)</h3>
</div>
</div>
</div>
<p>Darwin 5.x and 6.x are supported. There are two
methods of using pkgsrc on Mac OS X, by using a
<a href="#platform.osx-image" title=
"3.2.1.1.&nbsp;Using a disk image">disk image</a>, or a
<a href="#platform.osx-ufs" title=
"3.2.1.2.&nbsp;Using a UFS partition">UFS
partition</a>.</p>
<p>Before you start, you will need to download and
install the Mac OS X Developer Tools from Apple's
Developer Connection. See <a href=
"http://developer.apple.com/macosx/" target=
"_top">http://developer.apple.com/macosx/</a> for
details. Also, make sure you install X11 for Mac OS X
and the X11 SDK from <a href=
"http://www.apple.com/macosx/x11/download/" target=
"_top">http://www.apple.com/macosx/x11/download/</a> if
you intend to build packages that use the X11 Window
System.</p>
<p>If you already have a UFS partition, or have a spare
partition that you can format as UFS, it is recommended
to use that instead of the disk image. It'll be
somewhat faster and will mount automatically at boot
time, where you must manually mount a disk image.</p>
<div class="note" style=
"margin-left: 0.5in; margin-right: 0.5in;">
<h3 class="title">Note</h3>
<p>You cannot use a HFS+ file system for pkgsrc,
because pkgsrc currently requires the filesystem to
be case-sensitive, and HFS+ is not.</p>
</div>
<div class="sect3" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h4 class="title"><a name="platform.osx-image"
id="platform.osx-image"></a>3.2.1.1.&nbsp;Using
a disk image</h4>
</div>
</div>
</div>
<p>Create the disk image:</p>
<pre class="screen">
<code class="prompt">#</code> <strong class=
"userinput"><code>cd pkgsrc/bootstrap</code></strong>
<code class="prompt">#</code> <strong class=
"userinput"><code>./ufsdiskimage create ~/Documents/NetBSD 512</code></strong> # megabytes - season to taste
<code class="prompt">#</code> <strong class=
"userinput"><code>./ufsdiskimage mount ~/Documents/NetBSD</code></strong>
<code class="prompt">#</code> <strong class=
"userinput"><code>sudo chown `id -u`:`id -g` /Volumes/NetBSD</code></strong>
</pre>
<p>That's it!</p>
</div>
<div class="sect3" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h4 class="title"><a name="platform.osx-ufs"
id="platform.osx-ufs"></a>3.2.1.2.&nbsp;Using a
UFS partition</h4>
</div>
</div>
</div>
<p>By default, <code class="filename">/usr</code>
will be on your root file system, normally HFS+. It
is possible to use the default <span class=
"emphasis"><em>prefix</em></span> of <code class=
"filename">/usr/pkg</code> by symlinking <code class=
"filename">/usr/pkg</code> to a directory on a UFS
file system. Obviously, another symlink is required
if you want to place the package database directory
outside the <span class=
"emphasis"><em>prefix</em></span>. e.g.</p>
<pre class="screen">
<code class="prompt">#</code> <strong class=
"userinput"><code>./bootstrap --pkgdbdir=/usr/pkg/pkgdb --pkgsrcdir=/Volumes/ufs/pkgsrc</code></strong>
</pre>
<p>If you created your partitions at the time of
installing Mac OS X and formatted the target
partition as UFS, it should automatically mount on
<code class="filename">/Volumes/&lt;volume
name&gt;</code> when the machine boots. If you are
(re)formatting a partition as UFS, you need to ensure
that the partition map correctly reflects
&#8220;<span class="quote">Apple_UFS</span>&#8221;
and not &#8220;<span class=
"quote">Apple_HFS</span>&#8221;.</p>
<p>The problem is that none of the disk tools will
let you touch a disk that is booted from. You can
unmount the partition, but even if you newfs it, the
partition type will be incorrect and the automounter
won't mount it. It can be mounted manually, but it
won't appear in Finder.</p>
<p>You'll need to boot off of the OS X Installation
(User) CD. When the Installation program starts, go
up to the menu and select Disk Utility. Now, you will
be able to select the partition you want to be UFS,
and Format it Apple UFS. Quit the Disk Utility, quit
the installer which will reboot your machine. The new
UFS file system will appear in Finder.</p>
<p>Be aware that the permissions on the new file
system will be writable by root only.</p>
<p>This note is as of 10.2 (Jaguar) and applies to
earlier versions. Hopefully Apple will fix Disk
Utility in 10.3 (Panther).</p>
</div>
</div>
<div class="sect2" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h3 class="title"><a name="id2515558" id=
"id2515558"></a>3.2.2.&nbsp;FreeBSD</h3>
</div>
</div>
</div>
<p>FreeBSD 4.7 and 5.0 have been tested and are
supported, other versions may work.</p>
<p>Care should be taken so that the tools that this kit
installs do not conflict with the FreeBSD userland
tools. There are several steps:</p>
<div class="orderedlist">
<ol type="1">
<li>
<p>FreeBSD stores its ports pkg database in
<code class="filename">/var/db/pkg</code>. It is
therefore recommended that you choose a different
location (e.g. <code class=
"filename">/usr/pkgdb</code>) by using the
--pkgdbdir option to the bootstrap script.</p>
</li>
<li>
<p>If you do not intend to use the FreeBSD ports
tools, it's probably a good idea to move them out
of the way to avoid confusion, e.g.</p>
<pre class="screen">
<code class="prompt">#</code> <strong class=
"userinput"><code>cd /usr/sbin</code></strong>
<code class="prompt">#</code> <strong class=
"userinput"><code>mv pkg_add pkg_add.orig</code></strong>
<code class="prompt">#</code> <strong class=
"userinput"><code>mv pkg_create pkg_create.orig</code></strong>
<code class="prompt">#</code> <strong class=
"userinput"><code>mv pkg_delete pkg_delete.orig</code></strong>
<code class="prompt">#</code> <strong class=
"userinput"><code>mv pkg_info pkg_info.orig</code></strong>
</pre>
</li>
<li>
<p>An example <code class=
"filename">/etc/mk.conf</code> file will be
placed in <code class=
"filename">/etc/mk.conf.example</code> file when
you use the bootstrap script.</p>
</li>
</ol>
</div>
</div>
<div class="sect2" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h3 class="title"><a name="id2515660" id=
"id2515660"></a>3.2.3.&nbsp;Interix</h3>
</div>
</div>
</div>
<p>Interix is a POSIX compatible subsystem for the
Windows NT kernel, providing a Unix-like environment
with a tighter kernel integration than available with
Cygwin. It is part of the Windows Services for Unix
package, available for free for any licensed copy of
Windows 2000, XP, or 2003. SFU can be downloaded from
<a href="http://www.microsoft.com/windows/sfu/" target=
"_top">http://www.microsoft.com/windows/sfu/</a>.</p>
<p>Services for Unix 3.5, current as of this writing,
has been tested. 3.0 or 3.1 may work, but are not
officially supported. (The main difference in 3.0/3.1
is lack of pthreads.)</p>
<div class="sect3" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h4 class="title"><a name=
"platform.interix-sfu-install" id=
"platform.interix-sfu-install"></a>3.2.3.1.&nbsp;When
installing Interix/SFU</h4>
</div>
</div>
</div>
<p>At an absolute minimum, the following packages
must be installed from the Windows Services for Unix
3.5 distribution in order to use pkgsrc:</p>
<div class="itemizedlist">
<ul type="disc">
<li>
<p>Utilities -&gt; Base Utilities</p>
</li>
<li>
<p>Interix GNU Components -&gt; (all)</p>
</li>
<li>
<p>Remote Connectivity</p>
</li>
<li>
<p>Interix SDK</p>
</li>
</ul>
</div>
<p>When using pkgsrc on Interix, DO NOT install the
Utilities subcomponent "UNIX Perl". That is Perl 5.6
without shared module support, installed to
/usr/local, and will only cause confusion. Instead,
install Perl 5.8 from pkgsrc (or from a binary
package).</p>
<p>The Remote Connectivity subcomponent "Windows
Remote Shell Service" does not need to be installed,
but Remote Connectivity itself should be installed in
order to have a working inetd.</p>
<p>Finally, during installation you may be asked
whether to enable setuid behavior for Interix
programs, and whether to make pathnames default to
case-sensitive. Setuid should be enabled, and
case-sensitivity MUST be enabled. (Without
case-sensitivity, a large number of packages
including perl will not build.)</p>
</div>
<div class="sect3" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h4 class="title"><a name=
"platform.interix-sfu-postinstall" id=
"platform.interix-sfu-postinstall"></a>3.2.3.2.&nbsp;What
to do if Interix/SFU is already installed</h4>
</div>
</div>
</div>
<p>If SFU is already installed and you wish to alter
these settings to work with pkgsrc, note the
following things.</p>
<div class="itemizedlist">
<ul type="disc">
<li>
<p>To uninstall UNIX Perl, use Add/Remove
Programs, select Microsoft Windows Services for
UNIX, then click Change. In the installer,
choose Add or Remove, then uncheck
Utilities-&gt;UNIX Perl.</p>
</li>
<li>
<p>To enable case-sensitivity for the
filesystem, run REGEDIT.EXE, and change the
following registry key:</p>
<p>
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session
Manager\kernel</p>
<p>Set the DWORD value "obcaseinsensitive" to
0; then reboot.</p>
</li>
<li>
<p>To enable setuid binaries (optional), run
REGEDIT.EXE, and change the following registry
key:</p>
<p>
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Services
for UNIX</p>
<p>Set the DWORD value "EnableSetuidBinaries"
to 1; then reboot.</p>
</li>
</ul>
</div>
</div>
<div class="sect3" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h4 class="title"><a name=
"platform.interix-notes" id=
"platform.interix-notes"></a>3.2.3.3.&nbsp;Important
notes for using pkgsrc</h4>
</div>
</div>
</div>
<p>The package imanager (either the pkgsrc "su" user,
or the user running "pkg_add") must be a member of
the local Administrators group. Such a user must also
be used to run the bootstrap. This is slightly
relaxed from the normal pkgsrc requirement of
"root".</p>
<p>The package manager should use a umask of 002.
"make install" will automatically complain if this is
not the case. This ensures that directories written
in /var/db/pkg are Administrators-group
writeable.</p>
<p>The popular Interix binary packages from
http://www.interopsystems.com/ use an older version
of pkgsrc's pkg_* tools. Ideally, these should NOT be
used in conjunction with pkgsrc. If you choose to use
them at the same time as the pkgsrc packages, ensure
that you use the proper pkg_* tools for each type of
binary package.</p>
</div>
</div>
<div class="sect2" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h3 class="title"><a name="id2515751" id=
"id2515751"></a>3.2.4.&nbsp;IRIX</h3>
</div>
</div>
</div>
<p>You will need a working C compiler, either gcc or
SGI's MIPS and MIPSpro compiler (cc/c89). Please set
the <code class="varname">CC</code> environment
variable according to your preference. If you do not
have a license for the MIPSpro compiler suite, you can
download a gcc tardist file from <a href=
"http://freeware.sgi.com/" target=
"_top">http://freeware.sgi.com/</a>.</p>
<p>Please note that you will need IRIX 6.5.17 or
higher, as this is the earliest version of IRIX
providing support for if_indextoname(3),
if_nametoindex(3), etc.</p>
<p>At this point in time, pkgsrc only supports one ABI.
That is, you can not switch between the old 32-bit ABI,
the new 32-bit ABI and the 64-bit ABI. If you start out
using "abi=n32", that's what all your packages will be
built with.</p>
<p>Therefore, please make sure that you have no
conflicting <code class="varname">CFLAGS</code> in your
environment or the <code class=
"filename">/etc/mk.conf</code>. Particularly, make sure
that you do not try to link n32 object files with lib64
or vice versa. Check your <code class=
"filename">/etc/compiler.defaults</code>!</p>
<p>If you have the actual pkgsrc tree mounted via NFS
from a different host, please make sure to set
<code class="varname">WRKOBJDIR</code> to a local
directory, as it appears that IRIX linker occasionally
runs into issues when trying to link over a network
mounted filesystem.</p>
<p>The bootstrapping process should set all the right
options for programs such as imake(1), but you may want
to set some options depending on your local setup.
Please see <code class=
"filename">pkgsrc/mk/defaults/mk.conf</code> and, of
course, your compilers man pages for details.</p>
</div>
<div class="sect2" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h3 class="title"><a name="id2516278" id=
"id2516278"></a>3.2.5.&nbsp;OpenBSD</h3>
</div>
</div>
</div>
<p>OpenBSD 3.0 and 3.2 are tested and supported.</p>
<p>Care should be taken so that the tools that this kit
installs do not conflict with the OpenBSD userland
tools. There are several steps:</p>
<div class="orderedlist">
<ol type="1">
<li>
<p>OpenBSD stores its ports pkg database in
<code class="filename">/var/db/pkg</code>. It is
therefore recommended that you choose a different
location (e.g. <code class=
"filename">/usr/pkgdb</code>) by using the
--pkgdbdir option to the bootstrap script.</p>
</li>
<li>
<p>If you do not intend to use the OpenBSD ports
tools, it's probably a good idea to move them out
of the way to avoid confusion, e.g.</p>
<pre class="screen">
<code class="prompt">#</code> <strong class=
"userinput"><code>cd /usr/sbin</code></strong>
<code class="prompt">#</code> <strong class=
"userinput"><code>mv pkg_add pkg_add.orig</code></strong>
<code class="prompt">#</code> <strong class=
"userinput"><code>mv pkg_create pkg_create.orig</code></strong>
<code class="prompt">#</code> <strong class=
"userinput"><code>mv pkg_delete pkg_delete.orig</code></strong>
<code class="prompt">#</code> <strong class=
"userinput"><code>mv pkg_info pkg_info.orig</code></strong>
</pre>
</li>
<li>
<p>An example <code class=
"filename">/etc/mk.conf</code> file will be
placed in <code class=
"filename">/etc/mk.conf.example</code> file when
you use the bootstrap script. OpenBSD's make
program uses <code class=
"filename">/etc/mk.conf</code> as well. You can
work around this by enclosing all the pkgsrc
specific parts of the file with:</p>
<pre class="programlisting">
.ifdef BSD_PKG_MK
# pkgsrc stuff, e.g. insert defaults/mk.conf or similar here
.else
# OpenBSD stuff
.endif
</pre>
</li>
</ol>
</div>
</div>
<div class="sect2" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h3 class="title"><a name="id2516390" id=
"id2516390"></a>3.2.6.&nbsp;Solaris</h3>
</div>
</div>
</div>
<p>Solaris 2.6 through 9 are supported on both x86 and
sparc. You will need a working C compiler. Both gcc
2.95.3 and Sun WorkShop 5 have been tested.</p>
<p>The following packages are required on Solaris 8 for
the bootstrap process and to build packages.</p>
<div class="itemizedlist">
<ul type="disc">
<li>
<p>SUNWsprot</p>
</li>
<li>
<p>SUNWarc</p>
</li>
<li>
<p>SUNWbtool</p>
</li>
<li>
<p>SUNWtoo</p>
</li>
<li>
<p>SUNWlibm</p>
</li>
</ul>
</div>
<p>Please note the use of GNU binutils on Solaris is
<span class="emphasis"><em>not</em></span>
supported.</p>
<div class="sect3" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h4 class="title"><a name="id2516421" id=
"id2516421"></a>3.2.6.1.&nbsp;If you are using
gcc</h4>
</div>
</div>
</div>
<p>It makes life much simpler if you only use the
same gcc consistently for building all packages.</p>
<p>It is recommended that an external gcc be used
only for bootstrapping, then either build gcc from
<a xmlns="http://www.w3.org/TR/xhtml1/transitional"
href=
"ftp://ftp.NetBSD.org/pub/NetBSD/packages/pkgsrc/lang/gcc/README.html"
class="pkgname">lang/gcc</a> or install a binary gcc
package, then remove gcc used during
bootstrapping.</p>
<p>Binary packages of gcc can be found through
<a href=
"http://www.sun.com/bigadmin/common/freewareSearch.html"
target=
"_top">http://www.sun.com/bigadmin/common/freewareSearch.html</a>.</p>
</div>
<div class="sect3" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h4 class="title"><a name="id2516442" id=
"id2516442"></a>3.2.6.2.&nbsp;If you are using
Sun WorkShop</h4>
</div>
</div>
</div>
<p>You will need at least the following packages
installed (from WorkShop 5.0)</p>
<div class="itemizedlist">
<ul type="disc">
<li>
<p>SPROcc - Sun WorkShop Compiler C 5.0</p>
</li>
<li>
<p>SPROcpl - Sun WorkShop Compiler C++ 5.0</p>
</li>
<li>
<p>SPROild - Sun WorkShop Incremental
Linker</p>
</li>
<li>
<p>SPROlang - Sun WorkShop Compilers common
components</p>
</li>
</ul>
</div>
<p>You should set <code class="varname">CC</code>,
<code class="varname">CXX</code> and optionally,
<code class="varname">CPP</code> in <code class=
"filename">/etc/mk.conf</code>, eg.</p>
<pre class="programlisting">
CC= cc
CXX= CC
CPP= /usr/ccs/lib/cpp
</pre>
<p>You may also want to build 64-bit binaries,
eg.</p>
<pre class="programlisting">
CFLAGS= -xtarget=ultra -xarch=v9
</pre>
<p>Whichever compiler you use, please ensure the
compiler tools and your $prefix are in your
<code class="varname">PATH</code>. This includes
<code class="filename">/usr/ccs/{bin,lib}</code> and
eg. <code class=
"filename">/usr/pkg/{bin,sbin}</code>.</p>
</div>
</div>
</div>
</div>
<div class="chapter" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h2 class="title"><a name="using" id=
"using"></a>Chapter&nbsp;4.&nbsp;Using pkgsrc</h2>
</div>
</div>
</div>
<div class="toc">
<p><b>Table of Contents</b></p>
<dl>
<dt><span class="sect1"><a href="#getting-started">4.1.
Working with binary packages</a></span></dt>
<dd>
<dl>
<dt><span class="sect2"><a href="#id2516526">4.1.1.
Where to get binary packages</a></span></dt>
<dt><span class="sect2"><a href="#id2516567">4.1.2.
How to use binary packages</a></span></dt>
<dt><span class="sect2"><a href="#id2516633">4.1.3.
A word of warning</a></span></dt>
</dl>
</dd>
<dt><span class="sect1"><a href="#id2516645">4.2.
Building packages from source</a></span></dt>
<dd>
<dl>
<dt><span class="sect2"><a href="#id2516723">4.2.1.
Requirements</a></span></dt>
<dt><span class="sect2"><a href="#id2516743">4.2.2.
Fetching distfiles</a></span></dt>
<dt><span class="sect2"><a href="#id2516864">4.2.3.
How to build and install</a></span></dt>
<dt><span class="sect2"><a href="#id2517180">4.2.4.
Selecting the compiler</a></span></dt>
</dl>
</dd>
</dl>
</div>
<div class="sect1" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h2 class="title" style="clear: both"><a name=
"getting-started" id=
"getting-started"></a>4.1.&nbsp;Working with binary
packages</h2>
</div>
</div>
</div>
<p>This section describes how to find, retrieve and
install a precompiled binary package that someone else
already prepared for your type of machine.</p>
<div class="sect2" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h3 class="title"><a name="id2516526" id=
"id2516526"></a>4.1.1.&nbsp;Where to get binary
packages</h3>
</div>
</div>
</div>
<p>Precompiled packages are stored on ftp.NetBSD.org
and its mirrors in the directory <code class=
"filename">/pub/NetBSD/packages</code> for anonymous
FTP access. Please pick the right subdirectory there as
indicated by <span><strong class="command">uname
-p</strong></span>. In that directory, there is a
subdirectory for each category plus a subdirectory
<code class="filename">All</code> which includes the
actual binaries in <code class="filename">.tgz</code>
files. The category subdirectories use symbolic links
to those files (this is the same directory layout as in
<code class=
"filename">/usr/pkgsrc/packages</code>).</p>
<p>This same directory layout applies for CDROM
distributions, only that the directory may be rooted
somewhere else, probably somewhere below <code class=
"filename">/cdrom</code>. Please consult your CDROMs
documentation for the exact location.</p>
</div>
<div class="sect2" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h3 class="title"><a name="id2516567" id=
"id2516567"></a>4.1.2.&nbsp;How to use binary
packages</h3>
</div>
</div>
</div>
<p>If you have the files on a CDROM or downloaded them
to your hard disk, youcan install them with the
following command (be sure to<span><strong class=
"command">su</strong></span> to root first):</p>
<pre class="screen">
<code class="prompt">#</code> <strong class=
"userinput"><code>pkg_add /path/to/package.tgz</code></strong>
</pre>
<p>If you have FTP access and you don't want to
download the packages via FTP prior to installation,
you can do this automatically by giving
<span><strong class="command">pkg_add</strong></span>
an FTP URL:</p>
<pre class="screen">
<code class="prompt">#</code> <strong class=
"userinput"><code>pkg_add ftp://ftp.NetBSD.org/pub/NetBSD/packages/&lt;OSvers&gt;/&lt;arch&gt;/All/package.tgz</code></strong>
</pre>
<p>If there is any doubt, the uname utility can be used
to determine the &lt;OSvers&gt;, and &lt;arch&gt; by
running <span><strong class="command">uname
-rp</strong></span>.</p>
<p>Also note that any prerequisite packages needed to
run the package in question will be installed, too,
assuming they are present where you install from.</p>
<p>After you've installed packages, be sure to have
<code class="filename">/usr/pkg/bin</code> in your
<code class="varname">PATH</code> so you can actually
start the just installed program.</p>
</div>
<div class="sect2" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h3 class="title"><a name="id2516633" id=
"id2516633"></a>4.1.3.&nbsp;A word of
warning</h3>
</div>
</div>
</div>
<p>Please pay very careful attention to the warnings
expressed in the <a href=
"http://netbsd.gw.com/cgi-bin/man-cgi?pkg_add+1+NetBSD-current">
<span class="citerefentry"><span class=
"refentrytitle">pkg_add</span>(1)</span></a> manual
page about the inherent dangers of installing binary
packages which you did not create yourself, and the
security holes that can be introduced onto your system
by indiscriminate adding of such files.</p>
</div>
</div>
<div class="sect1" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h2 class="title" style="clear: both"><a name=
"id2516645" id="id2516645"></a>4.2.&nbsp;Building
packages from source</h2>
</div>
</div>
</div>
<p>This assumes that the package is already in pkgsrc. If
it is not, see <a href="#developers-guide" title=
"Part&nbsp;II.&nbsp;The pkgsrc developer's guide">Part&nbsp;II,
&#8220;The pkgsrc developer's guide&#8221;</a>.</p>
<div class="sect2" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h3 class="title"><a name="id2516723" id=
"id2516723"></a>4.2.1.&nbsp;Requirements</h3>
</div>
</div>
</div>
<p>To build packages from source on a NetBSD system the
&#8220;<span class="quote">comp</span>&#8221; and the
&#8220;<span class="quote">text</span>&#8221;
distribution sets must be installed. If you want to
build X11 related packages the &#8220;<span class=
"quote">xbase</span>&#8221; and &#8220;<span class=
"quote">xcomp</span>&#8221; distribution sets are
required, too.</p>
</div>
<div class="sect2" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h3 class="title"><a name="id2516743" id=
"id2516743"></a>4.2.2.&nbsp;Fetching
distfiles</h3>
</div>
</div>
</div>
<p>The distfile (i.e. the unmodified source) must exist
on your system for the packages system to be able to
build it. If it does not exist, pkgsrc will use
<a href="http://netbsd.gw.com/cgi-bin/man-cgi?ftp+1+NetBSD-current">
<span class="citerefentry"><span class=
"refentrytitle">ftp</span>(1)</span></a> to fetch it
automatically.</p>
<p>You can overwrite some of the major distribution
sites to fit to sites that are close to your own. Have
a look at <code class=
"filename">pkgsrc/mk/defaults/mk.conf</code> to find
some examples - in particular, look for the
<code class="varname">MASTER_SORT</code>, <code class=
"varname">MASTER_SORT_REGEX</code> and <code class=
"varname">INET_COUNTRY</code> definitions. This may
save some of your bandwidth and time.</p>
<p>You can change these settings either in your shell's
environment, or, if you want to keep the settings, by
editing the <code class="filename">/etc/mk.conf</code>
file, and adding the definitions there.</p>
<p>If you don't have a permanent Internet connection
and you want to know which files to download,
<span><strong class="command">make
fetch-list</strong></span> will tell you what you'll
need. Put these distfiles into <code class=
"filename">/usr/pkgsrc/distfiles</code>.</p>
</div>
<div class="sect2" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h3 class="title"><a name="id2516864" id=
"id2516864"></a>4.2.3.&nbsp;How to build and
install</h3>
</div>
</div>
</div>
<p>Assuming that the distfile has been fetched (see
previous section), become root and change into the
relevant directory and running <span><strong class=
"command">make</strong></span>. For example, type</p>
<pre class="screen">
<code class="prompt">%</code> <strong class=
"userinput"><code>cd misc/figlet</code></strong>
<code class="prompt">%</code> <strong class=
"userinput"><code>make</code></strong>
</pre>
<p>at the shell prompt to build the various components
of the package, and</p>
<pre class="screen">
<code class="prompt">#</code> <strong class=
"userinput"><code>make install</code></strong>
</pre>
<p>to install the various components into the correct
places on your system. Installing the package on your
system requires you to be root. However, pkgsrc has a
<span class="emphasis"><em>just-in-time-su</em></span>
feature, which allows you to only become root for the
actual installation step</p>
<p>Taking the figlet utility as an example, we can
install it on our system by building as shown in
<a href="#logs" title=
"Appendix&nbsp;B.&nbsp;Build logs">Appendix B, <i>Build
logs</i></a>.</p>
<p>The program is installed under the default root of
the packages tree - <code class=
"filename">/usr/pkg</code>. Should this not conform to
your tastes, set the <code class=
"varname">LOCALBASE</code> variable in your
environment, and it will use that value as the root of
your packages tree. So, to use <code class=
"filename">/usr/local</code>, set <code class=
"varname">LOCALBASE=/usr/local</code> in your
environment. Please note that you should use a
directory which is dedicated to packages and not shared
with other programs (ie, do not try and use
<code class="varname">LOCALBASE=/usr</code>). Also, you
should not try to add any of your own files or
directories (such as <code class=
"filename">src/</code>, <code class=
"filename">obj/</code>, or <code class=
"filename">pkgsrc/</code>) below the <code class=
"varname">LOCALBASE</code> tree. This is to prevent
possible conflicts between programs and other files
installed by the package system and whatever else may
have been installed there.</p>
<p>Some packages look in <code class=
"filename">/etc/mk.conf</code> to alter some
configuration options at build time. Have a look at
<code class=
"filename">pkgsrc/mk/defaults/mk.conf</code> to get an
overview of what will be set there by default.
Environment variables such as <code class=
"varname">LOCALBASE</code> can be set in <code class=
"filename">/etc/mk.conf</code> to save having to
remember to set them each time you want to use
pkgsrc.</p>
<p>Occasionally, people want to &#8220;<span class=
"quote">look under the covers</span>&#8221; to see what
is going on when a package is building or being
installed. This may be for debugging purposes, or out
of simple curiosity. A number of utility values have
been added to help with this.</p>
<div class="orderedlist">
<ol type="1">
<li>
<p>If you invoke the <a href=
"http://netbsd.gw.com/cgi-bin/man-cgi?make+1+NetBSD-current">
<span class="citerefentry"><span class=
"refentrytitle">make</span>(1)</span></a> command
with <code class=
"varname">PKG_DEBUG_LEVEL=2</code>, then a huge
amount of information will be displayed. For
example,</p>
<pre class="screen">
<strong class=
"userinput"><code>make patch PKG_DEBUG_LEVEL=2</code></strong>
</pre>
<p>will show all the commands that are invoked,
up to and including the &#8220;<span class=
"quote">patch</span>&#8221; stage.</p>
</li>
<li>
<p>If you want to know the value of a certain
make(1) definition, then the <code class=
"varname">VARNAME</code> definition should be
used, in conjunction with the show-var target.
e.g. to show the expansion of the <a href=
"http://netbsd.gw.com/cgi-bin/man-cgi?make+1+NetBSD-current">
<span class="citerefentry"><span class=
"refentrytitle">make</span>(1)</span></a>
variable <code class=
"varname">DISTFILES</code>:</p>
<pre class="screen">
<code class="prompt">%</code> <strong class=
"userinput"><code>make show-var VARNAME=LOCALBASE</code></strong>
/usr/pkg
<code class="prompt">%</code>
</pre>
</li>
</ol>
</div>
<p>If you want to install a binary package that you've
either created yourself (see next section), that you
put into pkgsrc/packages manually or that is located on
a remote FTP server, you can use the "bin-install"
target. This target will install a binary package - if
available - via <a href=
"http://netbsd.gw.com/cgi-bin/man-cgi?pkg_add+1+NetBSD-current">
<span class="citerefentry"><span class=
"refentrytitle">pkg_add</span>(1)</span></a>, else do a
<span><strong class="command">make
package</strong></span>. The list of remote FTP sites
searched is kept in the variable <code class=
"varname">BINPKG_SITES</code>, which defaults to
ftp.NetBSD.org. Any flags that should be added to
<a href=
"http://netbsd.gw.com/cgi-bin/man-cgi?pkg_add+1+NetBSD-current">
<span class="citerefentry"><span class=
"refentrytitle">pkg_add</span>(1)</span></a> can be put
into <code class="varname">BIN_INSTALL_FLAGS</code>.
See <code class=
"filename">pkgsrc/mk/defaults/mk.conf</code> for more
details.</p>
<p>A final word of warning: If you setup a system that
has a non-standard setting for <code class=
"varname">LOCALBASE</code>, be sure to set that before
any packages are installed, as you can not use several
directories for the same purpose. Doing so will result
in pkgsrc not being able to properly detect your
installed packages, and fail miserably. Note also that
precompiled binary packages are usually built with the
default <code class="varname">LOCALBASE</code> of
<code class="filename">/usr/pkg</code>, and that you
should <span class="emphasis"><em>not</em></span>
install any if you use a non-standard <code class=
"varname">LOCALBASE</code>.</p>
</div>
<div class="sect2" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h3 class="title"><a name="id2517180" id=
"id2517180"></a>4.2.4.&nbsp;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>
<dt><span class="term"><code class=
"varname">PKGSRC_COMPILER</code>:</span></dt>
<dd>
<p>This is a list of values specifying the chain
of compilers to invoke when building packages.
Valid values are:</p>
<div class="itemizedlist">
<ul type="disc">
<li>
<p><code class="varname">distcc</code>:
distributed C/C++ (chainable)</p>
</li>
<li>
<p><code class="varname">ccache</code>:
compiler cache (chainable)</p>
</li>
<li>
<p><code class="varname">gcc</code>: GNU
C/C++ Compiler</p>
</li>
<li>
<p><code class="varname">mipspro</code>:
Silicon Graphics, Inc. MIPSpro
(n32/n64)</p>
</li>
<li>
<p><code class="varname">mipspro</code>:
Silicon Graphics, Inc. MIPSpro (o32)</p>
</li>
<li>
<p><code class="varname">sunpro</code>:
Microsystems, Inc. WorkShip/Forte/Sun ONE
Studio</p>
</li>
</ul>
</div>
<p>The default is &#8220;<span class=
"quote"><code class=
"varname">gcc</code></span>&#8221;. 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.
&#8220;<span class="quote"><code class=
"varname">ccache gcc</code></span>&#8221;. This
variable should always be terminated with a value
for a real compiler.</p>
</dd>
<dt><span class="term"><code class=
"varname">GCC_REQD</code>:</span></dt>
<dd>
<p>This specifies the minimum version of GCC to
use when building packages. If the system GCC
doesn't satisfy this requirement, then pkgsrc
will build and install one of the GCC packages to
use instead.</p>
</dd>
</dl>
</div>
</div>
</div>
</div>
<div class="chapter" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h2 class="title"><a name="binary" id=
"binary"></a>Chapter&nbsp;5.&nbsp;Creating binary
packages</h2>
</div>
</div>
</div>
<div class="toc">
<p><b>Table of Contents</b></p>
<dl>
<dt><span class="sect1"><a href="#id2517335">5.1.
Building a single binary package</a></span></dt>
<dt><span class="sect1"><a href="#id2517822">5.2.
Settings for creation of binary
packages</a></span></dt>
<dt><span class="sect1"><a href="#bulkbuild">5.3. Doing
a bulk build of all packages</a></span></dt>
<dd>
<dl>
<dt><span class="sect2"><a href=
"#binary.configuration">5.3.1.
Configuration</a></span></dt>
<dt><span class="sect2"><a href="#id2517962">5.3.2.
Other environmental considerations</a></span></dt>
<dt><span class="sect2"><a href="#id2518003">5.3.3.
Operation</a></span></dt>
<dt><span class="sect2"><a href="#id2583267">5.3.4.
What it does</a></span></dt>
<dt><span class="sect2"><a href="#id2583392">5.3.5.
Disk space requirements</a></span></dt>
<dt><span class="sect2"><a href="#id2583418">5.3.6.
Setting up a sandbox for chroot'ed
builds</a></span></dt>
<dt><span class="sect2"><a href="#id2583811">5.3.7.
Building a partial set of packages</a></span></dt>
<dt><span class="sect2"><a href=
"#bulk-upload">5.3.8. Uploading results of a bulk
build</a></span></dt>
</dl>
</dd>
<dt><span class="sect1"><a href="#id2584227">5.4.
Creating a multiple CD-ROM packages
collection</a></span></dt>
<dd>
<dl>
<dt><span class="sect2"><a href="#id2584310">5.4.1.
Example of cdpack</a></span></dt>
</dl>
</dd>
</dl>
</div>
<div class="sect1" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h2 class="title" style="clear: both"><a name=
"id2517335" id="id2517335"></a>5.1.&nbsp;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 href=
"http://netbsd.gw.com/cgi-bin/man-cgi?pkg_add+1+NetBSD-current">
<span class="citerefentry"><span class=
"refentrytitle">pkg_add</span>(1)</span></a> This saves
having to build the same package on a group of hosts and
wasting CPU time. It also provides a simple means for
others to install your package, should you distribute
it.</p>
<p>To create a binary package, change into the
appropriate directory in pkgsrc, and run
<span><strong class="command">make
package</strong></span>:</p>
<pre class="screen">
<code class="prompt">#</code> <strong class=
"userinput"><code>cd misc/figlet</code></strong>
<code class="prompt">#</code> <strong class=
"userinput"><code>make package</code></strong>
</pre>
<p>This will build and install your package (if not
already done), and then build a binary package from what
was installed. You can then use the <span><strong class=
"command">pkg_*</strong></span> tools to manipulate it.
Binary packages are created by default in <code class=
"filename">/usr/pkgsrc/packages</code>, in the form of a
gzipped tar file. See <a href="#logs.package" title=
"B.2.&nbsp;Packaging figlet">Section B.2,
&#8220;Packaging figlet&#8221;</a> for a continuation of
the above <a xmlns=
"http://www.w3.org/TR/xhtml1/transitional" href=
"ftp://ftp.NetBSD.org/pub/NetBSD/packages/pkgsrc/misc/figlet/README.html"
class="pkgname">misc/figlet</a> example.</p>
<p>See <a href="#submit" title=
"Chapter&nbsp;14.&nbsp;Submitting and Committing">Chapter
14, <i>Submitting and Committing</i></a> for information
on how to submit such a binary package.</p>
</div>
<div class="sect1" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h2 class="title" style="clear: both"><a name=
"id2517822" id="id2517822"></a>5.2.&nbsp;Settings
for creation of binary packages</h2>
</div>
</div>
</div>
<p>See <a href="#build.helpful-targets" title=
"11.3.&nbsp;Other helpful targets">Section&nbsp;11.3,
&#8220;Other helpful targets&#8221;</a>.</p>
</div>
<div class="sect1" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h2 class="title" style="clear: both"><a name=
"bulkbuild" id="bulkbuild"></a>5.3.&nbsp;Doing a
bulk build of all packages</h2>
</div>
</div>
</div>
<p>If you want to get a full set of precompiled binary
packages, this section describes how to get them. Beware
that the bulk build will remove all currently installed
packages from your system! Having a FTP server configured
either on the machine doing the bulk builds or on a
nearby NFS server can help to make the packages available
to everyone. See <a href=
"http://netbsd.gw.com/cgi-bin/man-cgi?ftpd+8+NetBSD-current">
<span class="citerefentry"><span class=
"refentrytitle">ftpd</span>(8)</span></a> for more
information. If you use a remote NFS server's storage, be
sure to not actually compile on NFS storage, as this
slows things down a lot.</p>
<div class="sect2" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h3 class="title"><a name="binary.configuration"
id=
"binary.configuration"></a>5.3.1.&nbsp;Configuration</h3>
</div>
</div>
</div>
<div class="sect3" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h4 class="title"><a name="binary.mk.conf" id=
"binary.mk.conf"></a>5.3.1.1.&nbsp;/etc/mk.conf</h4>
</div>
</div>
</div>
<p>You may want to set things in <code class=
"filename">/etc/mk.conf</code>. Look at <code class=
"filename">pkgsrc/mk/defaults/mk.conf</code> for
details of the default settings. You will want to
ensure that <code class=
"varname">ACCEPTABLE_LICENSES</code> meet your local
policy. As used in this example, <code class=
"varname">_ACCEPTABLE=yes</code> accepts <span class=
"emphasis"><em>all</em></span> licenses.</p>
<pre class="programlisting">
PACKAGES?= ${_PKGSRCDIR}/packages/${MACHINE_ARCH}
WRKOBJDIR?= /usr/tmp/pkgsrc # build here instead of in pkgsrc
BSDSRCDIR= /usr/src
BSDXSRCDIR= /usr/xsrc # for x11/xservers
OBJHOSTNAME?= yes # use work.`hostname`
FAILOVER_FETCH= yes # insist on the correct checksum
PKG_DEVELOPER?= yes
_ACCEPTABLE= yes
</pre>
</div>
<div class="sect3" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h4 class="title"><a name="id2517886" id=
"id2517886"></a>5.3.1.2.&nbsp;<code class=
"filename">build.conf</code></h4>
</div>
</div>
</div>
<p>In <code class="filename">pkgsrc/mk/bulk</code>,
copy <code class="filename">build.conf-example</code>
to <code class="filename">build.conf</code> and edit
it, following the comments in that file. This is the
config file that determines where log files are
generated after the build, where to mail the build
report to, where your pkgsrc tree is located and
which user to <a href=
"http://netbsd.gw.com/cgi-bin/man-cgi?su+8+NetBSD-current">
<span class="citerefentry"><span class=
"refentrytitle">su</span>(8)</span></a> to to do a
<span><strong class="command">cvs
update</strong></span>.</p>
</div>
<div class="sect3" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h4 class="title"><a name="id2517923" id=
"id2517923"></a>5.3.1.3.&nbsp;<code class=
"filename">pre-build.local</code></h4>
</div>
</div>
</div>
<p>It is possible to configure the bulk build to
perform certain site specific tasks at the end of the
pre-build stage. If the file <code class=
"filename">pre-build.local</code> exists in
<code class="filename">/usr/pkgsrc/mk/bulk</code> it
will be executed (as a sh(1) script) at the end of
the usual pre-build stage. An example use of
<code class="filename">pre-build.local</code> is to
have the line:</p>
<pre class="screen">
<code class="prompt">#</code> <strong class=
"userinput"><code>echo "I do not have enough disk space to build this pig." \
&gt; pkgsrc/games/crafty-book-enormous/$BROKENF</code></strong>
</pre>
<p>to prevent the system from trying to build a
particular package which requires nearly 3 GB of disk
space.</p>
</div>
</div>
<div class="sect2" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h3 class="title"><a name="id2517962" id=
"id2517962"></a>5.3.2.&nbsp;Other environmental
considerations</h3>
</div>
</div>
</div>
<p>As <code class="filename">/usr/pkg</code> will be
completely deleted at the start of bulk builds, make
sure your login shell is placed somewhere else. Either
drop it into <code class=
"filename">/usr/local/bin</code> (and adjust your login
shell in the passwd file), or (re-)install it via
<a href=
"http://netbsd.gw.com/cgi-bin/man-cgi?pkg_add+1+NetBSD-current">
<span class="citerefentry"><span class=
"refentrytitle">pkg_add</span>(1)</span></a> from
<code class="filename">/etc/rc.local</code>, so you can
login after a reboot (remember that your current
process won't die if the package is removed, you just
can't start any new instances of the shell any more).
Also, if you use NetBSD earlier than 1.5, or you still
want to use the pkgsrc version of ssh for some reason,
be sure to install ssh before starting it from
<code class="filename">rc.local</code>:</p>
<pre class="programlisting">
( cd /usr/pkgsrc/security/ssh ; make bulk-install )
if [ -f /usr/pkg/etc/rc.d/sshd ]; then
/usr/pkg/etc/rc.d/sshd
fi
</pre>
<p>Not doing so will result in you being not able to
log in via ssh after the bulk build is finished or if
the machine gets rebooted or crashes. You have been
warned! :)</p>
</div>
<div class="sect2" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h3 class="title"><a name="id2518003" id=
"id2518003"></a>5.3.3.&nbsp;Operation</h3>
</div>
</div>
</div>
<p>Make sure you don't need any of the packages still
installed.</p>
<div class="warning" style=
"margin-left: 0.5in; margin-right: 0.5in;">
<h3 class="title">Warning</h3>
<p>During the bulk build, <span class=
"emphasis"><em>all packages will be
removed!</em></span></p>
</div>
<p>Be sure to remove all other things that might
interfere with builds, like some libs installed in
<code class="filename">/usr/local</code>, etc. then
become root and type:</p>
<pre class="screen">
<code class="prompt">#</code> <strong class=
"userinput"><code>cd /usr/pkgsrc</code></strong>
<code class="prompt">#</code> <strong class=
"userinput"><code>sh mk/bulk/build</code></strong>
</pre>
<p>If for some reason your last build didn't complete
(power failure, system panic, ...), you can continue it
by running:</p>
<pre class="screen">
<code class="prompt">#</code> <strong class=
"userinput"><code>sh mk/bulk/build restart</code></strong>
</pre>
<p>At the end of the bulk build, you will get a summary
via mail, and find build logs in the directory
specified by <code class="varname">FTP</code> in the
<code class="filename">build.conf</code> file.</p>
</div>
<div class="sect2" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h3 class="title"><a name="id2583267" id=
"id2583267"></a>5.3.4.&nbsp;What it does</h3>
</div>
</div>
</div>
<p>The bulk builds consist of three steps:</p>
<div class="variablelist">
<dl>
<dt><span class="term">1. pre-build</span></dt>
<dd>
<p>The script updates your pkgsrc tree via
(anon)cvs, then cleans out any broken distfiles,
and removes all packages installed.</p>
</dd>
<dt><span class="term">2. the bulk
build</span></dt>
<dd>
<p>This is basically &#8220;<span class=
"quote">make bulk-package</span>&#8221; with an
optimised order in which packages will be built.
Packages that don't require other packages will
be built first, and packages with many
dependencies will be built later.</p>
</dd>
<dt><span class="term">3. post-build</span></dt>
<dd>
<p>Generates a report that's placed in the
directory specified in the <code class=
"filename">build.conf</code> file named
<code class="filename">broken.html</code>, a
short version of that report will also be mailed
to the build's admin.</p>
</dd>
</dl>
</div>
<p>During the build, a list of broken packages will be
compiled in <code class=
"filename">/usr/pkgsrc/.broken</code> (or <code class=
"filename">.../.broken.${MACHINE}</code> if
<code class="varname">OBJMACHINE</code> is set),
individual build logs of broken builds can be found in
the package's directory. These files are used by the
bulk-targets to mark broken builds to not waste time
trying to rebuild them, and they can be used to debug
these broken package builds later.</p>
</div>
<div class="sect2" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h3 class="title"><a name="id2583392" id=
"id2583392"></a>5.3.5.&nbsp;Disk space
requirements</h3>
</div>
</div>
</div>
<p>Currently, roughly the following requirements are
valid for NetBSD 2.0/i386:</p>
<div class="itemizedlist">
<ul type="disc">
<li>
<p>10 GB - distfiles (NFS ok)</p>
</li>
<li>
<p>8 GB - full set of all binaries (NFS ok)</p>
</li>
<li>
<p>5 GB - temp space for compiling (local disk
recommended)</p>
</li>
</ul>
</div>
<p>Note that all pkgs will be de-installed as soon as
they are turned into a binary package, and that sources
are removed, so there is no excessively huge demand to
disk space. Afterwards, if the package is needed again,
it will be installed via <a href=
"http://netbsd.gw.com/cgi-bin/man-cgi?pkg_add+1+NetBSD-current">
<span class="citerefentry"><span class=
"refentrytitle">pkg_add</span>(1)</span></a> instead of
building again, so there are no cycles wasted by
recompiling.</p>
</div>
<div class="sect2" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h3 class="title"><a name="id2583418" id=
"id2583418"></a>5.3.6.&nbsp;Setting up a sandbox
for chroot'ed builds</h3>
</div>
</div>
</div>
<p>If you don't want all the packages nuked from a
machine (rendering it useless for anything but pkg
compiling), there is the possibility of doing the pkg
bulk build inside a chroot environment.</p>
<p>The first step is to set up a chroot sandbox, e.g.
<code class="filename">/usr/sandbox</code>. This can be
done by using null mounts, or manually.</p>
<p>There is a shell script called <code class=
"filename">pkgsrc/mk/bulk/mksandbox</code> which will
set up the sandbox environment using null mounts. It
will also create a script called <code class=
"filename">sandbox</code> in the root of the sandbox
environment, which will allow the null mounts to be
activated using the <span><strong class=
"command">sandbox mount</strong></span> command and
deactivated using the <span><strong class=
"command">sandbox umount</strong></span> command.</p>
<p>To set up a sandbox environment by hand, after
extracting all the sets from a NetBSD installation or
doing a <span><strong class="command">make distribution
DESTDIR=/usr/sandbox</strong></span> in <code class=
"filename">/usr/src/etc</code>, be sure the following
items are present and properly configured:</p>
<div class="procedure">
<ol type="1">
<li>
<p>Kernel</p>
<pre class="screen">
<code class="prompt">#</code> <strong class=
"userinput"><code>cp /netbsd /usr/sandbox</code></strong>
</pre>
</li>
<li>
<p><code class="filename">/dev/*</code></p>
<pre class="screen">
<code class="prompt">#</code> <strong class=
"userinput"><code>cd /usr/sandbox/dev ; sh MAKEDEV all</code></strong>
</pre>
</li>
<li>
<p><code class="filename">/etc/resolv.conf</code>
(for <a xmlns=
"http://www.w3.org/TR/xhtml1/transitional" href=
"ftp://ftp.NetBSD.org/pub/NetBSD/packages/pkgsrc/security/smtpd/README.html"
class="pkgname">security/smtpd</a> and mail):</p>
<pre class="screen">
<code class="prompt">#</code> <strong class=
"userinput"><code>cp /etc/resolv.conf /usr/sandbox/etc</code></strong>
</pre>
</li>
<li>
<p>Working(!) mail config (hostname,
sendmail.cf):</p>
<pre class="screen">
<code class="prompt">#</code> <strong class=
"userinput"><code>cp /etc/mail/sendmail.cf /usr/sandbox/etc/mail</code></strong>
</pre>
</li>
<li>
<p><code class="filename">/etc/localtime</code>
(for <a xmlns=
"http://www.w3.org/TR/xhtml1/transitional" href=
"ftp://ftp.NetBSD.org/pub/NetBSD/packages/pkgsrc/security/smtpd/README.html"
class="pkgname">security/smtpd</a>):</p>
<pre class="screen">
<code class="prompt">#</code> <strong class=
"userinput"><code>ln -sf /usr/share/zoneinfo/UTC /usr/sandbox/etc/localtime</code></strong>
</pre>
</li>
<li>
<p><code class="filename">/usr/src</code> (system
sources, for <a xmlns=
"http://www.w3.org/TR/xhtml1/transitional" href=
"ftp://ftp.NetBSD.org/pub/NetBSD/packages/pkgsrc/sysutils/aperture/README.html"
class="pkgname">sysutils/aperture</a>, <a xmlns=
"http://www.w3.org/TR/xhtml1/transitional" href=
"ftp://ftp.NetBSD.org/pub/NetBSD/packages/pkgsrc/net/ppp-mppe/README.html"
class="pkgname">net/ppp-mppe</a>):</p>
<pre class="screen">
<code class="prompt">#</code> <strong class=
"userinput"><code>ln -s ../disk1/cvs .</code></strong>
<code class="prompt">#</code> <strong class=
"userinput"><code>ln -s cvs/src-1.6 src</code></strong>
</pre>
</li>
<li>
<p>Create <code class=
"filename">/var/db/pkg</code> (not part of
default install):</p>
<pre class="screen">
<code class="prompt">#</code> <strong class=
"userinput"><code>mkdir /usr/sandbox/var/db/pkg</code></strong>
</pre>
</li>
<li>
<p>Create <code class="filename">/usr/pkg</code>
(not part of default install):</p>
<pre class="screen">
<code class="prompt">#</code> <strong class=
"userinput"><code>mkdir /usr/sandbox/usr/pkg</code></strong>
</pre>
</li>
<li>
<p>Checkout pkgsrc via cvs into <code class=
"filename">/usr/sandbox/usr/pkgsrc</code>:</p>
<pre class="screen">
<code class="prompt">#</code> <strong class=
"userinput"><code>cd /usr/sandbox/usr</code></strong>
<code class="prompt">#</code> <strong class=
"userinput"><code>cvs -d anoncvs@anoncvs.NetBSD.org:/cvsroot checkout -d -P pkgsrc</code></strong>
</pre>
<p>Do not mount/link this to the copy of your
pkgsrc tree you do development in, as this will
likely cause problems!</p>
</li>
<li>
<p>Make <code class=
"filename">/usr/sandbox/usr/pkgsrc/packages</code>
and <code class="filename">.../distfiles</code>
point somewhere appropriate. NFS- and/or
nullfs-mounts may come in handy!</p>
</li>
<li>
<p>Edit <code class=
"filename">/etc/mk.conf</code>, see <a href=
"#binary.mk.conf" title=
"5.3.1.1.&nbsp;/etc/mk.conf">Section&nbsp;5.3.1.1,
&#8220;/etc/mk.conf&#8221;</a>.</p>
</li>
<li>
<p>Adjust <code class=
"filename">mk/bulk/build.conf</code> to suit your
needs.</p>
</li>
<li>
<p>If you have set <code class=
"varname">CVS_USER</code> in <code class=
"filename">build.conf</code>, make sure that
account exists and can do a <span><strong class=
"command">cvs ${CVS_FLAGS} update</strong></span>
properly!</p>
</li>
</ol>
</div>
<p>When the chroot sandbox is setup, you can start the
build with the following steps:</p>
<pre class="screen">
<code class="prompt">#</code> <strong class=
"userinput"><code>cd /usr/sandbox/usr/pkgsrc</code></strong>
<code class="prompt">#</code> <strong class=
"userinput"><code>sh mk/bulk/do-sandbox-build</code></strong>
</pre>
<p>This will just jump inside the sandbox and start
building. At the end of the build, mail will be sent
with the results of the build. Created binary pkgs will
be in <code class=
"filename">/usr/sandbox/usr/pkgsrc/packages</code>
(wherever that points/mounts to/from).</p>
</div>
<div class="sect2" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h3 class="title"><a name="id2583811" id=
"id2583811"></a>5.3.7.&nbsp;Building a partial
set of packages</h3>
</div>
</div>
</div>
<p>In addition to building a complete set of all
packages in pkgsrc, the <code class=
"filename">pkgsrc/mk/bulk/build</code> script may be
used to build a subset of the packages contained in
pkgsrc. By setting defining <code class=
"varname">SPECIFIC_PKGS</code> in <code class=
"filename">/etc/mk.conf</code>, the variables</p>
<div class="itemizedlist">
<ul type="disc">
<li>
<p>SITE_SPECIFIC_PKGS</p>
</li>
<li>
<p>HOST_SPECIFIC_PKGS</p>
</li>
<li>
<p>GROUP_SPECIFIC_PKGS</p>
</li>
<li>
<p>USER_SPECIFIC_PKGS</p>
</li>
</ul>
</div>
<p>will define the set of packages which should be
built. The bulk build code will also include any
packages which are needed as dependencies for the
explicitly listed packages.</p>
<p>One use of this is to do a bulk build with
<code class="varname">SPECIFIC_PKGS</code> in a chroot
sandbox periodically to have a complete set of the
binary packages needed for your site available without
the overhead of building extra packages that are not
needed.</p>
</div>
<div class="sect2" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h3 class="title"><a name="bulk-upload" id=
"bulk-upload"></a>5.3.8.&nbsp;Uploading results
of a bulk build</h3>
</div>
</div>
</div>
<p>This section describes how pkgsrc developers can
upload binary pkgs built by bulk builds to
ftp.NetBSD.org.</p>
<p>First, make sure that you have <code class=
"varname">RSYNC_DST</code> set properly in your
<code class="filename">mk/bulk/build.conf</code> file,
i.e. adjust it to something like one of the
following:</p>
<pre class="screen">
RSYNC_DST=$CVS_USER@ftp.NetBSD.org:/pub/NetBSD/packages/pkgsrc-200xQy/NetBSD-a.b.c/arch/upload
</pre>
<p>Please use appropviate values for "pkgsrc-200xQ4",
"NetBSD-a.b.c" and "arch" here. If your login on
ftp.NetBSD.org is different from <code class=
"varname">CVS_USER</code>, write your login directly
into the variable, e.g. my local account is "feyrer",
but for my login "hubertf", I use:</p>
<pre class="screen">
RSYNC_DST=hubertf@ftp.NetBSD.org:/pub/NetBSD/packages/pkgsrc-200xQy/NetBSD-a.b.c/arch/upload
</pre>
<p>A separate <code class="filename">upload</code>
directory is used here to allow "closing" the directory
during upload. To do so, run the following command on
ftp.NetBSD.org next:</p>
<pre class="screen">
nbftp% <strong class=
"userinput"><code>mkdir -p -m 750 /pub/NetBSD/packages/pkgsrc-200xQy/NetBSD-a.b.c/arch/upload</code></strong>
</pre>
<p>Please note that <code class=
"filename">/pub/NetBSD/packages</code> is only
appropriate for packages for the NetBSD operating
system. Binary packages for other operating systems
should go into <code class=
"filename">/pub/pkgsrc</code>.</p>
<p>Before uploading the binary pkgs, ssh authentication
needs to be setup next. This example shows how to setup
temporary keys for the root account <span class=
"emphasis"><em>inside the sandbox</em></span> (assuming
that no keys should be present there usually):</p>
<pre class="screen">
<code class="prompt">#</code> <strong class=
"userinput"><code>chroot /usr/sandbox</code></strong>
chroot-<code class="prompt">#</code> <strong class=
"userinput"><code>rm $HOME/.ssh/id-dsa*</code></strong>
chroot-<code class="prompt">#</code> <strong class=
"userinput"><code>ssh-keygen -t dsa</code></strong>
chroot-<code class="prompt">#</code> <strong class=
"userinput"><code>cat $HOME/.ssh/id-dsa.pub</code></strong>
</pre>
<p>Now take the output of <code class=
"filename">id-dsa.pub</code> and append it to your
<code class="filename">~/.ssh/authorized_keys</code>
file on ftp.netBSD.org. You can remove the key after
the upload is done!</p>
<p>Next, test if your ssh connection really works:</p>
<pre class="screen">
chroot-<code class="prompt">#</code> <strong class=
"userinput"><code>ssh ftp.NetBSD.org date</code></strong>
</pre>
<p>Use "-l yourNetBSDlogin" here as appropriate!</p>
<p>Now after all this works, you can exit the sandbox
and start the upload:</p>
<pre class="screen">
chroot-<code class="prompt">#</code> <strong class=
"userinput"><code>exit</code></strong>
<code class="prompt">#</code> <strong class=
"userinput"><code>cd /usr/sandbox/usr/pkgsrc</code></strong>
<code class="prompt">#</code> <strong class=
"userinput"><code>sh mk/bulk/do-sandbox-upload</code></strong>
</pre>
<p>The upload process may take quite some time. Use
"ls" or "du" on the FTP server to monitor progress of
the upload.</p>
<p>After the upload has ended, first thing is to revoke
ssh access:</p>
<pre class="screen">
nbftp% <strong class=
"userinput"><code>vi ~/.ssh/authorized_keys</code></strong>
Gdd:x!
</pre>
<p>Use whatever is needed to remove the key you've
entered before! Last, move the uploaded packages out of
the <code class="filename">upload</code> directory to
have them accessible to everyone:</p>
<pre class="screen">
nbftp% <strong class=
"userinput"><code>cd /pub/NetBSD/packages/pkgsrc-200xQy/NetBSD-a.b.c/arch</code></strong>
nbftp% <strong class=
"userinput"><code>mv upload/* .</code></strong>
nbftp% <strong class="userinput"><code>rmdir upload</code></strong>
nbftp% <strong class="userinput"><code>chmod 755 .</code></strong>
</pre>
</div>
</div>
<div class="sect1" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h2 class="title" style="clear: both"><a name=
"id2584227" id="id2584227"></a>5.4.&nbsp;Creating a
multiple CD-ROM packages collection</h2>
</div>
</div>
</div>
<p>After your pkgsrc bulk-build has completed, you may
wish to create a CD-ROM set of the resulting binary
packages to assist in installing packages on other
machines. The <a xmlns=
"http://www.w3.org/TR/xhtml1/transitional" href=
"ftp://ftp.NetBSD.org/pub/NetBSD/packages/pkgsrc/pkgtools/cdpack/README.html"
class="pkgname">pkgtools/cdpack</a> package provides a
simple tool for creating the ISO 9660 images.
<span><strong class="command">cdpack</strong></span>
arranges the packages on the CD-ROMs in a way that keeps
all the dependencies for given package on the same CD as
that package.</p>
<div class="sect2" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h3 class="title"><a name="id2584310" id=
"id2584310"></a>5.4.1.&nbsp;Example of
cdpack</h3>
</div>
</div>
</div>
<p>Complete documentation for cdpack is found in the
cdpack(1) manpage. The following short example assumes
that the binary packages are left in <code class=
"filename">/usr/pkgsrc/packages/All</code> and that
sufficient disk space exists in <code class=
"filename">/u2</code> to hold the ISO 9660 images.</p>
<pre class="screen">
<code class="prompt">#</code> <strong class=
"userinput"><code>mkdir /u2/images</code></strong>
<code class="prompt">#</code> <strong class=
"userinput"><code>pkg_add /usr/pkgsrc/packages/All/cdpack</code></strong>
<code class="prompt">#</code> <strong class=
"userinput"><code>cdpack /usr/pkgsrc/packages/All /u2/images</code></strong>
</pre>
<p>If you wish to include a common set of files
(<code class="filename">COPYRIGHT</code>, <code class=
"filename">README</code>, etc.) on each CD in the
collection, then you need to create a directory which
contains these files. e.g.</p>
<pre class="screen">
<code class="prompt">#</code> <strong class=
"userinput"><code>mkdir /tmp/common</code></strong>
<code class="prompt">#</code> <strong class=
"userinput"><code>echo "This is a README" &gt; /tmp/common/README</code></strong>
<code class="prompt">#</code> <strong class=
"userinput"><code>echo "Another file" &gt; /tmp/common/COPYING</code></strong>
<code class="prompt">#</code> <strong class=
"userinput"><code>mkdir /tmp/common/bin</code></strong>
<code class="prompt">#</code> <strong class=
"userinput"><code>echo "#!/bin/sh" &gt; /tmp/common/bin/myscript</code></strong>
<code class="prompt">#</code> <strong class=
"userinput"><code>echo "echo Hello world" &gt;&gt; /tmp/common/bin/myscript</code></strong>
<code class="prompt">#</code> <strong class=
"userinput"><code>chmod 755 /tmp/common/bin/myscript</code></strong>
</pre>
<p>Now create the images:</p>
<pre class="screen">
<code class="prompt">#</code> <strong class=
"userinput"><code>cdpack -x /tmp/common /usr/pkgsrc/packages/All /u2/images</code></strong>
</pre>
<p>Each image will contain <code class=
"filename">README</code>, <code class=
"filename">COPYING</code>, and <code class=
"filename">bin/myscript</code> in their root
directories.</p>
</div>
</div>
</div>
<div class="chapter" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h2 class="title"><a name="faq" id=
"faq"></a>Chapter&nbsp;6.&nbsp;Frequently Asked
Questions</h2>
</div>
</div>
</div>
<div class="toc">
<p><b>Table of Contents</b></p>
<dl>
<dt><span class="sect1"><a href="#id2584502">6.1. Is
there a mailing list for pkg-related
discussion?</a></span></dt>
<dt><span class="sect1"><a href="#id2584600">6.2.
Where's the pkgviews documentation?</a></span></dt>
<dt><span class="sect1"><a href="#faq-pkgtools">6.3.
Utilities for package management
(pkgtools)</a></span></dt>
<dt><span class="sect1"><a href="#id2584853">6.4. How
to use pkgsrc as non-root</a></span></dt>
<dt><span class="sect1"><a href="#id2584865">6.5. How
to resume transfers when fetching
distfiles?</a></span></dt>
<dt><span class="sect1"><a href="#id2584907">6.6. How
can I install/use XFree86 from pkgsrc?</a></span></dt>
<dt><span class="sect1"><a href="#id2584935">6.7. How
can I install/use X.org from pkgsrc?</a></span></dt>
<dt><span class="sect1"><a href="#id2584963">6.8. How
to fetch files from behind a firewall</a></span></dt>
<dt><span class="sect1"><a href="#id2584977">6.9. How
do I tell <span><strong class="command">make
fetch</strong></span> to do passive
FTP?</a></span></dt>
<dt><span class="sect1"><a href="#id2585028">6.10. How
to fetch all distfiles at once</a></span></dt>
<dt><span class="sect1"><a href="#id2585168">6.11. What
does &#8220;<span class="quote">Don't know how to make
/usr/share/tmac/tmac.andoc</span>&#8221;
mean?</a></span></dt>
<dt><span class="sect1"><a href="#id2585206">6.12. What
does &#8220;<span class="quote">Could not find
bsd.own.mk</span>&#8221; mean?</a></span></dt>
<dt><span class="sect1"><a href="#id2585264">6.13.
Using 'sudo' with pkgsrc</a></span></dt>
<dt><span class="sect1"><a href="#faq.conf">6.14.
Configuration files handling and
placement</a></span></dt>
<dt><span class="sect1"><a href="#audit-packages">6.15.
Automated security checks</a></span></dt>
</dl>
</div>
<p>This section contains hints, tips &amp; tricks on
special things in pkgsrc that we didn't find a better place
for in the previous chapters, and it contains items for
both pkgsrc users and developers.</p>
<div class="sect1" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h2 class="title" style="clear: both"><a name=
"id2584502" id="id2584502"></a>6.1.&nbsp;Is there a
mailing list for pkg-related discussion?</h2>
</div>
</div>
</div>
<p>Yes, <code class="email">&lt;<a href=
"mailto:tech-pkg@NetBSD.org">tech-pkg@NetBSD.org</a>&gt;</code>
is the list for discussing package related issues. To
subscribe do:</p>
<pre class="programlisting">
<code class=
"prompt">%</code> echo subscribe tech-pkg | mail majordomo@NetBSD.org
</pre>
<p>An archive of the list is available at <a href=
"http://mail-index.NetBSD.org/tech-pkg/" target=
"_top">http://mail-index.NetBSD.org/tech-pkg/</a>.</p>
</div>
<div class="sect1" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h2 class="title" style="clear: both"><a name=
"id2584600" id="id2584600"></a>6.2.&nbsp;Where's
the pkgviews documentation?</h2>
</div>
</div>
</div>
<p>Pkgviews is tightly integrated with buildlink. You can
find a pkgviews User's guide in <code class=
"filename">pkgsrc/mk/buildlink3/PKGVIEWS_UG</code>.</p>
</div>
<div class="sect1" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h2 class="title" style="clear: both"><a name=
"faq-pkgtools" id=
"faq-pkgtools"></a>6.3.&nbsp;Utilities for package
management (pkgtools)</h2>
</div>
</div>
</div>
<p>The <code class="filename">pkgsrc/pkgtools</code>
directory pkgtools contains a number of useful utilities
for both users and developers of pkgsrc. This section
attempts only to make the reader aware of the utilities
and when they might be useful, and not to duplicate the
documentation that comes with each package.</p>
<p>Utilities used by pkgsrc (automatically installed when
needed):</p>
<div class="itemizedlist">
<ul type="disc">
<li>
<p><a xmlns=
"http://www.w3.org/TR/xhtml1/transitional" href=
"ftp://ftp.NetBSD.org/pub/NetBSD/packages/pkgsrc/pkgtools/x11-links/README.html"
class="pkgname">pkgtools/x11-links</a>: symlinks
for use by buildlink</p>
</li>
</ul>
</div>
<p>OS tool augmentation (automatically installed when
needed):</p>
<div class="itemizedlist">
<ul type="disc">
<li>
<p><a xmlns=
"http://www.w3.org/TR/xhtml1/transitional" href=
"ftp://ftp.NetBSD.org/pub/NetBSD/packages/pkgsrc/pkgtools/digest/README.html"
class="pkgname">pkgtools/digest</a>: calculates
SHA1 checksums (and other kinds)</p>
</li>
<li>
<p><a xmlns=
"http://www.w3.org/TR/xhtml1/transitional" href=
"ftp://ftp.NetBSD.org/pub/NetBSD/packages/pkgsrc/pkgtools/libnbcompat/README.html"
class="pkgname">pkgtools/libnbcompat</a>: compat
library for pkg tools</p>
</li>
<li>
<p><a xmlns=
"http://www.w3.org/TR/xhtml1/transitional" href=
"ftp://ftp.NetBSD.org/pub/NetBSD/packages/pkgsrc/pkgtools/mtree/README.html"
class="pkgname">pkgtools/mtree</a>: installed on
non-BSD systems due to lack of native mtree</p>
</li>
<li>
<p><a xmlns=
"http://www.w3.org/TR/xhtml1/transitional" href=
"ftp://ftp.NetBSD.org/pub/NetBSD/packages/pkgsrc/pkgtools/pkg_install/README.html"
class="pkgname">pkgtools/pkg_install</a>:
up-to-date replacement for /usr/sbin/pkg_install,
or for use on operating systems where pkg_install
is not present</p>
</li>
</ul>
</div>
<p>Utilities used by pkgsrc (not automatically
installed):</p>
<div class="itemizedlist">
<ul type="disc">
<li>
<p><a xmlns=
"http://www.w3.org/TR/xhtml1/transitional" href=
"ftp://ftp.NetBSD.org/pub/NetBSD/packages/pkgsrc/pkgtools/pkg_tarup/README.html"
class="pkgname">pkgtools/pkg_tarup</a>: create a
binary package from an already-installed package.
used by 'make replace' to save the old package</p>
</li>
<li>
<p><a xmlns=
"http://www.w3.org/TR/xhtml1/transitional" href=
"ftp://ftp.NetBSD.org/pub/NetBSD/packages/pkgsrc/pkgtools/dfdisk/README.html"
class="pkgname">pkgtools/dfdisk</a>: adds extra
functionality to pkgsrc, allowing it to fetch
distfiles from multiple locations. It currently
supports the following methods: multiple CD-ROMs
and network FTP/HTTP connections.</p>
</li>
<li>
<p><a xmlns=
"http://www.w3.org/TR/xhtml1/transitional" href=
"ftp://ftp.NetBSD.org/pub/NetBSD/packages/pkgsrc/pkgtools/xpkgwedge/README.html"
class="pkgname">pkgtools/xpkgwedge</a>: put X11
packages someplace else (enabled by default)</p>
</li>
<li>
<p><a xmlns=
"http://www.w3.org/TR/xhtml1/transitional" href=
"ftp://ftp.NetBSD.org/pub/NetBSD/packages/pkgsrc/devel/cpuflags/README.html"
class="pkgname">devel/cpuflags</a>: will determine
the best compiler flags to optimise code for your
current CPU and compiler.</p>
</li>
</ul>
</div>
<p>Utilities for keeping track of installed packages,
being up to date, etc:</p>
<div class="itemizedlist">
<ul type="disc">
<li>
<p><a xmlns=
"http://www.w3.org/TR/xhtml1/transitional" href=
"ftp://ftp.NetBSD.org/pub/NetBSD/packages/pkgsrc/pkgtools/pkg_chk/README.html"
class="pkgname">pkgtools/pkg_chk</a>: installs
pkg_chk, which reports on packages whose installed
versions do not match the latest pkgsrc entries</p>
</li>
<li>
<p><a xmlns=
"http://www.w3.org/TR/xhtml1/transitional" href=
"ftp://ftp.NetBSD.org/pub/NetBSD/packages/pkgsrc/pkgtools/pkgdep/README.html"
class="pkgname">pkgtools/pkgdep</a>: makes
dependency graphs of packages, to aid in choosing a
strategy for updating</p>
</li>
<li>
<p><a xmlns=
"http://www.w3.org/TR/xhtml1/transitional" href=
"ftp://ftp.NetBSD.org/pub/NetBSD/packages/pkgsrc/pkgtools/pkgdepgraph/README.html"
class="pkgname">pkgtools/pkgdepgraph</a>: make
graph from above (uses graphviz)</p>
</li>
<li>
<p><a xmlns=
"http://www.w3.org/TR/xhtml1/transitional" href=
"ftp://ftp.NetBSD.org/pub/NetBSD/packages/pkgsrc/pkgtools/pkglint/README.html"
class="pkgname">pkgtools/pkglint</a>: This provides
two distinct abilities: check a pkgsrc entry for
correctness (pkglint) check for and remove
out-of-date distfiles and binary packages
(lintpkgsrc)</p>
</li>
<li>
<p><a xmlns=
"http://www.w3.org/TR/xhtml1/transitional" href=
"ftp://ftp.NetBSD.org/pub/NetBSD/packages/pkgsrc/pkgtools/pkgsurvey/README.html"
class="pkgname">pkgtools/pkgsurvey</a>: report what
packages you have installed</p>
</li>
</ul>
</div>
<p>Utilities for people maintaining or creating
individual packages:</p>
<div class="itemizedlist">
<ul type="disc">
<li>
<p><a xmlns=
"http://www.w3.org/TR/xhtml1/transitional" href=
"ftp://ftp.NetBSD.org/pub/NetBSD/packages/pkgsrc/pkgtools/pkgdiff/README.html"
class="pkgname">pkgtools/pkgdiff</a>: automate
making and maintaining patches for a package
(includes pkgdiff, pkgvi, mkpatches, ...)</p>
</li>
<li>
<p><a xmlns=
"http://www.w3.org/TR/xhtml1/transitional" href=
"ftp://ftp.NetBSD.org/pub/NetBSD/packages/pkgsrc/pkgtools/rpm2pkg/README.html"
class="pkgname">pkgtools/rpm2pkg</a>, <a xmlns=
"http://www.w3.org/TR/xhtml1/transitional" href=
"ftp://ftp.NetBSD.org/pub/NetBSD/packages/pkgsrc/pkgtools/url2pkg/README.html"
class="pkgname">pkgtools/url2pkg</a>: aids in
converting to pkgsrc</p>
</li>
<li>
<p><a xmlns=
"http://www.w3.org/TR/xhtml1/transitional" href=
"ftp://ftp.NetBSD.org/pub/NetBSD/packages/pkgsrc/pkgtools/gensolpkg/README.html"
class="pkgname">pkgtools/gensolpkg</a>: convert
pkgsrc to a Solaris package</p>
</li>
</ul>
</div>
<p>Utilities for people maintaining pkgsrc (or more
obscure pkg utilities)</p>
<div class="itemizedlist">
<ul type="disc">
<li>
<p><a xmlns=
"http://www.w3.org/TR/xhtml1/transitional" href=
"ftp://ftp.NetBSD.org/pub/NetBSD/packages/pkgsrc/pkgtools/pkgconflict/README.html"
class="pkgname">pkgtools/pkgconflict</a>: find
packages that conflict but aren't marked as
such</p>
</li>
<li>
<p><a xmlns=
"http://www.w3.org/TR/xhtml1/transitional" href=
"ftp://ftp.NetBSD.org/pub/NetBSD/packages/pkgsrc/pkgtools/pkg_comp/README.html"
class="pkgname">pkgtools/pkg_comp</a>: build
packages in a chrooted area</p>
</li>
<li>
<p><a xmlns=
"http://www.w3.org/TR/xhtml1/transitional" href=
"ftp://ftp.NetBSD.org/pub/NetBSD/packages/pkgsrc/pkgtools/libkver/README.html"
class="pkgname">pkgtools/libkver</a>: spoof kernel
version for chrooted cross builds</p>
</li>
</ul>
</div>
</div>
<div class="sect1" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h2 class="title" style="clear: both"><a name=
"id2584853" id="id2584853"></a>6.4.&nbsp;How to use
pkgsrc as non-root</h2>
</div>
</div>
</div>
<p>If you want to use pkgsrc as non-root user, you can
set some variables to make pkgsrc work under these
conditions. Please see <a href=
"http://mail-index.NetBSD.org/tech-pkg/2003/09/27/0023.html"
target="_top">this message</a> for more details.</p>
</div>
<div class="sect1" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h2 class="title" style="clear: both"><a name=
"id2584865" id="id2584865"></a>6.5.&nbsp;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 <code class="filename">/etc/mk.conf</code>. If,
during a fetch step, an incomplete distfile is found,
pkgsrc will try to resume it.</p>
<p>You can also use a different program than the default
ftp(1) by changing the <code class=
"varname">FETCH_CMD</code> variable. Don't forget to set
<code class="varname">FETCH_RESUME_ARGS</code> and
<code class="varname">FETCH_OUTPUT_ARGS</code> if you are
not using default values.</p>
<p>For example, if you want to use <code class=
"filename">wget</code> to resume downloads, you'll have
to use something like:</p>
<pre class="programlisting">
FETCH_CMD=wget
.if defined(FETCH_CMD) &amp;&amp; ${FETCH_CMD} == "wget"
FETCH_BEFORE_ARGS=--passive-ftp
FETCH_RESUME_ARGS=-c
FETCH_OUTPUT_ARGS=-O
.endif
</pre>
</div>
<div class="sect1" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h2 class="title" style="clear: both"><a name=
"id2584907" id="id2584907"></a>6.6.&nbsp;How can I
install/use XFree86 from pkgsrc?</h2>
</div>
</div>
</div>
<p>If you want to use XFree86 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 <code class=
"filename">/etc/mk.conf</code>:</p>
<pre class="programlisting">
X11_TYPE=XFree86
</pre>
</div>
<div class="sect1" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h2 class="title" style="clear: both"><a name=
"id2584935" id="id2584935"></a>6.7.&nbsp;How can I
install/use X.org from pkgsrc?</h2>
</div>
</div>
</div>
<p>If you want to use 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 <code class=
"filename">/etc/mk.conf</code>:</p>
<pre class="programlisting">
X11_TYPE=xorg
</pre>
</div>
<div class="sect1" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h2 class="title" style="clear: both"><a name=
"id2584963" id="id2584963"></a>6.8.&nbsp;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 &#8220;<span class=
"quote">orpheus.amdahl.com</span>&#8221; is one of the
firewalls, and it uses port 80 as the proxy port number.
So the proxy environment variables are:</p>
<pre class="programlisting">
ftp_proxy=ftp://orpheus.amdahl.com:80/
http_proxy=http://orpheus.amdahl.com:80/
</pre>
</div>
<div class="sect1" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h2 class="title" style="clear: both"><a name=
"id2584977" id="id2584977"></a>6.9.&nbsp;How do I
tell <span><strong class="command">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>
<pre class="programlisting">
${LOCALBASE}/bin/ftp
/usr/bin/ftp
</pre>
<p>On a default NetBSD installation, this will be
<code class="filename">/usr/bin/ftp</code>, which
automatically tries passive connections first, and falls
back to active connections if the server refuses to do
passive. For the other tools, add the following to your
<code class="filename">/etc/mk.conf</code> file:
<code class="varname">PASSIVE_FETCH=1</code>.</p>
<p>Having that option present will prevent <code class=
"filename">/usr/bin/ftp</code> from falling back to
active transfers.</p>
</div>
<div class="sect1" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h2 class="title" style="clear: both"><a name=
"id2585028" id="id2585028"></a>6.10.&nbsp;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><strong class="command">make
fetch</strong></span>. There is an archive of distfiles
on <a href=
"ftp://ftp.NetBSD.org/pub/NetBSD/packages/distfiles/"
target="_top">ftp.NetBSD.org</a>, but downloading the
entire directory may not be appropriate.</p>
<p>The answer here is to do a <span><strong class=
"command">make fetch-list</strong></span> in <code class=
"filename">/usr/pkgsrc</code> or one of it's
subdirectories, carry the resulting list to your machine
at work/school and use it there If you don't have a
NetBSD-compatible ftp(1) (like lukemftp) at work, don't
forget to set <code class="varname">FETCH_CMD</code> to
something that fetches a URL:</p>
<p>At home:</p>
<pre class="screen">
<code class="prompt">%</code> <strong class=
"userinput"><code>cd /usr/pkgsrc</code></strong>
<code class="prompt">%</code> <strong class=
"userinput"><code>make fetch-list FETCH_CMD=wget DISTDIR=/tmp/distfiles &gt;/tmp/fetch.sh</code></strong>
<code class="prompt">%</code> <strong class=
"userinput"><code>scp /tmp/fetch.sh work:/tmp</code></strong>
</pre>
<p>At work:</p>
<pre class="screen">
<code class="prompt">%</code> <strong class=
"userinput"><code>sh /tmp/fetch.sh</code></strong>
</pre>
<p>then tar up <code class=
"filename">/tmp/distfiles</code> and take it home.</p>
<p>If you have a machine running NetBSD, and you want to
get <span class="emphasis"><em>all</em></span> distfiles
(even ones that aren't for your machine architecture),
you can do so by using the above-mentioned
<span><strong class="command">make
fetch-list</strong></span> approach, or fetch the
distfiles directly by running:</p>
<pre class="screen">
<code class="prompt">%</code> <strong class=
"userinput"><code>make mirror-distfiles</code></strong>
</pre>
<p>If you even decide to ignore <code class=
"varname">NO_{SRC,BIN}_ON_{FTP,CDROM}</code>, then you
can get everything by running:</p>
<pre class="screen">
<code class="prompt">%</code> <strong class=
"userinput"><code>make fetch NO_SKIP=yes</code></strong>
</pre>
</div>
<div class="sect1" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h2 class="title" style="clear: both"><a name=
"id2585168" id="id2585168"></a>6.11.&nbsp;What does
&#8220;<span class="quote">Don't know how to make
/usr/share/tmac/tmac.andoc</span>&#8221; mean?</h2>
</div>
</div>
</div>
<p>When compiling the <a xmlns=
"http://www.w3.org/TR/xhtml1/transitional" href=
"ftp://ftp.NetBSD.org/pub/NetBSD/packages/pkgsrc/pkgtools/pkg_install/README.html"
class="pkgname">pkgtools/pkg_install</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
&#8220;<span class="quote">text</span>&#8221; set on your
machine (nroff, ...). It is recommended to do that to
format manpages.</p>
<p>In the case of the <a xmlns=
"http://www.w3.org/TR/xhtml1/transitional" href=
"ftp://ftp.NetBSD.org/pub/NetBSD/packages/pkgsrc/pkgtools/pkg_install/README.html"
class="pkgname">pkgtools/pkg_install</a> package, you can
get away with setting <code class=
"varname">NOMAN=YES</code> either in the environment or
in <code class="filename">/etc/mk.conf</code>.</p>
</div>
<div class="sect1" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h2 class="title" style="clear: both"><a name=
"id2585206" id="id2585206"></a>6.12.&nbsp;What does
&#8220;<span class="quote">Could not find
bsd.own.mk</span>&#8221; 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 it and install it, by
extracting it in <code class="filename">/</code>:</p>
<pre class="screen">
<code class="prompt">#</code> <strong class=
"userinput"><code>cd /</code></strong>
<code class="prompt">#</code> <strong class=
"userinput"><code>tar --unlink -zxvpf .../comp.tgz</code></strong>
</pre>
<p><code class="filename">comp.tgz</code> is part of
every NetBSD release. Get the one that corresponds to
your release (determine via <span><strong class=
"command">uname -r</strong></span>).</p>
</div>
<div class="sect1" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h2 class="title" style="clear: both"><a name=
"id2585264" id="id2585264"></a>6.13.&nbsp;Using
'sudo' with pkgsrc</h2>
</div>
</div>
</div>
<p>When installing packages as non-root user and using
the just-in-time su(1) feature of pkgsrc, it can become
annoying to type in the root password for each required
package installed. To avoid this, the sudo package can be
used, which does password caching over a limited time. To
use it, install sudo (either as binary package or from
<a xmlns="http://www.w3.org/TR/xhtml1/transitional" href=
"ftp://ftp.NetBSD.org/pub/NetBSD/packages/pkgsrc/security/sudo/README.html"
class="pkgname">security/sudo</a>) and then put the
following into your <code class=
"filename">/etc/mk.conf</code>:</p>
<pre class="programlisting">
.if exists(/usr/pkg/bin/sudo)
SU_CMD=/usr/pkg/bin/sudo /bin/sh -c
.endif
</pre>
</div>
<div class="sect1" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h2 class="title" style="clear: both"><a name=
"faq.conf" id=
"faq.conf"></a>6.14.&nbsp;Configuration files
handling and placement</h2>
</div>
</div>
</div>
<p>The global variable <code class=
"varname">PKG_SYSCONFBASE</code> (and some others) can be
set by the system administrator in <code class=
"filename">/etc/mk.conf</code> to define the place where
configuration files get installed. Therefore, packages
must be adapted to support this feature. Keep in mind
that you should only install files that are strictly
necessary in the configuration directory, files that can
go to <code class="filename">$PREFIX/share</code> should
go there.</p>
<p>We will take a look at available variables first
(<code class="filename">bsd.pkg.mk</code> contains more
information). <code class="varname">PKG_SYSCONFDIR</code>
is where the configuration files for a package may be
found (that is, the full path, e.g. <code class=
"filename">/etc</code> or <code class=
"filename">/usr/pkg/etc</code>). This value may be
customized in various ways:</p>
<div class="orderedlist">
<ol type="1">
<li>
<p><code class="varname">PKG_SYSCONFBASE</code> is
the main config directory under which all package
configuration files are to be found. Users will
typically want to set it to <code class=
"filename">/etc</code>, or accept the default
location of <code class=
"filename">$PREFIX/etc</code>.</p>
</li>
<li>
<p><code class="varname">PKG_SYSCONFSUBDIR</code>
is the subdirectory of <code class=
"varname">PKG_SYSCONFBASE</code> under which the
configuration files for a particular package may be
found. Defaults to <code class=
"varname">${SYSCONFBASE}</code>.</p>
</li>
<li>
<p><code class="varname">PKG_SYSCONFVAR</code> is
the special suffix used to distinguish any
overriding values for a particular package (see
next item). It defaults to <code class=
"varname">${PKGBASE}</code>, but for a collection
of related packages that should all have the same
<code class="varname">PKG_SYSCONFDIR</code> value,
it can be set in each of the package Makefiles to a
common value.</p>
</li>
<li>
<p><code class=
"varname">PKG_SYSCONFDIR.${PKG_SYSCONFVAR}</code>
overrides the value of <code class=
"varname">${PKG_SYSCONFDIR}</code> for packages
with the same value for <code class=
"varname">PKG_SYSCONFVAR</code>.</p>
<p>As an example, all the various KDE packages may
want to set <code class=
"varname">PKG_SYSCONFVAR</code> to
&#8220;<span class="quote">kde</span>&#8221; so
admins can set <code class=
"varname">PKG_SYSCONFDIR.kde</code> in <code class=
"filename">/etc/mk.conf</code> to define where to
install KDE config files.</p>
</li>
</ol>
</div>
<p>Programs' configuration directory should be defined
during the configure stage. Packages that use GNU
autoconf can usually do this by using the
&#8220;<span class="quote">--sysconfdir</span>&#8221;
parameter, but this brings some problems as we will see
now. When you change this pathname in packages, you
should not allow them to install files in that directory
directly. Instead they need to install those files under
<code class="filename">share/examples/${PKGNAME}</code>
so <code class="filename">PLIST</code> can register
them.</p>
<p>Once you have the required configuration files in
place (under the <code class=
"filename">share/examples</code> directory) the variable
<code class="varname">CONF_FILES</code> should be set to
copy them into <code class=
"varname">PKG_SYSCONFDIR</code>. The contents of this
variable is formed by pairs of filenames; the first
element of the pair specifies the file inside the
examples directory (registered by <code class=
"filename">PLIST</code>) and the second element specifies
the target file. This is done this way to allow binary
packages to place files in the right directory using
<code class="filename">INSTALL</code>/<code class=
"filename">DEINSTALL</code> scripts which are created
automatically. The package <code class=
"filename">Makefile</code> must also set <code class=
"varname">USE_PKGINSTALL=YES</code> to use these
automatically generated scripts. 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>
<p>Here is an example, taken from mail/mutt/Makefile:</p>
<pre class="programlisting">
EGDIR= ${PREFIX}/share/doc/mutt/samples
CONF_FILES= ${EGDIR}/Muttrc ${PKG_SYSCONFDIR}/Muttrc
</pre>
<p>As you can see, this package installs configuration
files inside <code class="varname">EGDIR</code>, which
are registered by <code class="filename">PLIST</code>.
After that, the variable <code class=
"varname">CONF_FILES</code> lists the installed file
first and then the target file. Users will also get an
automatic message when files are installed using this
method.</p>
</div>
<div class="sect1" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h2 class="title" style="clear: both"><a name=
"audit-packages" id=
"audit-packages"></a>6.15.&nbsp;Automated security
checks</h2>
</div>
</div>
</div>
<p>Please be aware that there can often be bugs in
third-party software, and some of these bugs can leave a
machine vulnerable to exploitation by attackers. In an
effort to lessen the exposure, the NetBSD packages team
maintains a database of known-exploits to packages which
have at one time been included in pkgsrc. The database
can be downloaded automatically, and a security audit of
all packages installed on a system can take place. To do
this, install the <a xmlns=
"http://www.w3.org/TR/xhtml1/transitional" href=
"ftp://ftp.NetBSD.org/pub/NetBSD/packages/pkgsrc/security/audit-packages/README.html"
class="pkgname">security/audit-packages</a> package. It
has two components:</p>
<div class="orderedlist">
<ol type="1">
<li>
<p>&#8220;<span class=
"quote">download-vulnerability-list</span>&#8221;,
an easy way to download a list of the security
vulnerabilities information. This list is kept up
to date by the NetBSD security officer and the
NetBSD packages team, and is distributed from the
NetBSD ftp server:</p>
<p><a href=
"ftp://ftp.NetBSD.org/pub/NetBSD/packages/distfiles/pkg-vulnerabilities"
target=
"_top">ftp://ftp.NetBSD.org/pub/NetBSD/packages/distfiles/pkg-vulnerabilities</a></p>
</li>
<li>
<p>&#8220;<span class=
"quote">audit-packages</span>&#8221;, an easy way
to audit the current machine, checking each
vulnerability which is known. If a vulnerable
package is installed, it will be shown by output to
stdout, including a description of the type of
vulnerability, and a URL containing more
information.</p>
</li>
</ol>
</div>
<p>Use of the audit-packages package is strongly
recommended!</p>
<p>The following message is displayed as part of the
audit-packages installation procedure:</p>
<pre class="screen">
===========================================================================
$NetBSD: faq.xml,v 1.4 2005/01/11 16:05:20 wiz Exp $
You may wish to have the vulnerabilities file downloaded daily so that
it remains current. This may be done by adding an appropriate entry
to the root users crontab(5) entry. For example the entry
# download vulnerabilities file
0 3 * * * ${PREFIX}/sbin/download-vulnerability-list &gt;/dev/null 2&gt;&amp;1
will update the vulnerability list every day at 3AM. You may wish to do
this more often than once a day.
In addition, you may wish to run the package audit from the daily
security script. This may be accomplished by adding the following
lines to /etc/security.local
if [ -x ${PREFIX}/sbin/audit-packages ]; then
${PREFIX}/sbin/audit-packages
fi
===========================================================================
</pre>
</div>
</div>
</div>
<div class="part" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h1 class="title"><a name="developers-guide" id=
"developers-guide"></a>The pkgsrc developer's
guide</h1>
</div>
</div>
</div>
<div class="toc">
<p><b>Table of Contents</b></p>
<dl>
<dt><span class="chapter"><a href="#components">7.
Package components - files, directories and
contents</a></span></dt>
<dd>
<dl>
<dt><span class="sect1"><a href=
"#components.Makefile">7.1. <code class=
"filename">Makefile</code></a></span></dt>
<dt><span class="sect1"><a href=
"#components.distinfo">7.2. <code class=
"filename">distinfo</code></a></span></dt>
<dt><span class="sect1"><a href=
"#components.patches">7.3. patches/*</a></span></dt>
<dt><span class="sect1"><a href="#id2586445">7.4.
Other mandatory files</a></span></dt>
<dt><span class="sect1"><a href=
"#components.optional">7.5. Optional
files</a></span></dt>
<dt><span class="sect1"><a href="#id2586640">7.6.
<code class="filename">work*</code></a></span></dt>
<dt><span class="sect1"><a href="#id2586727">7.7.
<code class="filename">files/*</code></a></span></dt>
</dl>
</dd>
<dt><span class="chapter"><a href="#plist">8. PLIST
issues</a></span></dt>
<dd>
<dl>
<dt><span class="sect1"><a href="#id2586781">8.1. RCS
ID</a></span></dt>
<dt><span class="sect1"><a href="#id2586796">8.2.
Semi-automatic <code class="filename">PLIST</code>
generation</a></span></dt>
<dt><span class="sect1"><a href="#print-PLIST">8.3.
Tweaking output of <span><strong class="command">make
print-PLIST</strong></span></a></span></dt>
<dt><span class="sect1"><a href="#plist.misc">8.4.
Variable substitution in PLIST</a></span></dt>
<dt><span class="sect1"><a href="#id2587186">8.5.
Manpage-compression</a></span></dt>
<dt><span class="sect1"><a href="#id2587227">8.6.
Changing PLIST source with <code class=
"varname">PLIST_SRC</code></a></span></dt>
<dt><span class="sect1"><a href="#id2587244">8.7.
Platform specific and differing
PLISTs</a></span></dt>
<dt><span class="sect1"><a href=
"#faq.common-dirs">8.8. Sharing directories between
packages</a></span></dt>
</dl>
</dd>
<dt><span class="chapter"><a href="#buildlink">9.
Buildlink methodology</a></span></dt>
<dd>
<dl>
<dt><span class="sect1"><a href="#id2587653">9.1.
Converting packages to use buildlink3</a></span></dt>
<dt><span class="sect1"><a href="#id2587844">9.2.
Writing <code class="filename">buildlink3.mk</code>
files</a></span></dt>
<dd>
<dl>
<dt><span class="sect2"><a href=
"#id2587913">9.2.1. Anatomy of a buildlink3.mk
file</a></span></dt>
<dt><span class="sect2"><a href=
"#id2588354">9.2.2. Updating <code class=
"varname">BUILDLINK_DEPENDS.<em class=
"replaceable"><code>pkg</code></em></code> in
<code class="filename">buildlink3.mk</code>
files</a></span></dt>
</dl>
</dd>
<dt><span class="sect1"><a href="#id2588433">9.3.
Writing <code class="filename">builtin.mk</code>
files</a></span></dt>
<dd>
<dl>
<dt><span class="sect2"><a href=
"#id2588582">9.3.1. Anatomy of a <code class=
"filename">builtin.mk</code> file</a></span></dt>
<dt><span class="sect2"><a href=
"#id2588877">9.3.2. Global preferences for native
or pkgsrc software</a></span></dt>
</dl>
</dd>
</dl>
</dd>
<dt><span class="chapter"><a href="#options">10. Options
handling</a></span></dt>
<dd>
<dl>
<dt><span class="sect1"><a href="#id2588950">10.1.
Global default options</a></span></dt>
<dt><span class="sect1"><a href="#id2588965">10.2.
Converting packages to use <code class=
"filename">bsd.options.mk</code></a></span></dt>
</dl>
</dd>
<dt><span class="chapter"><a href="#build">11. The build
process</a></span></dt>
<dd>
<dl>
<dt><span class="sect1"><a href="#build.prefix">11.1.
Program location</a></span></dt>
<dt><span class="sect1"><a href="#id2589573">11.2.
Main targets</a></span></dt>
<dt><span class="sect1"><a href=
"#build.helpful-targets">11.3. Other helpful
targets</a></span></dt>
</dl>
</dd>
<dt><span class="chapter"><a href="#fixes">12. Notes on
fixes for packages</a></span></dt>
<dd>
<dl>
<dt><span class="sect1"><a href="#id2590973">12.1.
General operation</a></span></dt>
<dd>
<dl>
<dt><span class="sect2"><a href=
"#id2590977">12.1.1. How to pull in variables
from /etc/mk.conf</a></span></dt>
<dt><span class="sect2"><a href=
"#id2591128">12.1.2. Restricted
packages</a></span></dt>
<dt><span class="sect2"><a href=
"#dependencies">12.1.3. Handling
dependencies</a></span></dt>
<dt><span class="sect2"><a href=
"#id2591643">12.1.4. Handling conflicts with
other packages</a></span></dt>
<dt><span class="sect2"><a href=
"#id2591762">12.1.5. Packages that cannot or
should not be built</a></span></dt>
<dt><span class="sect2"><a href=
"#id2591787">12.1.6. Packages which should not be
deleted, once installed</a></span></dt>
<dt><span class="sect2"><a href=
"#security-handling">12.1.7. Handling packages
with security problems</a></span></dt>
<dt><span class="sect2"><a href=
"#id2591879">12.1.8. How to handle compiler
bugs</a></span></dt>
<dt><span class="sect2"><a href=
"#id2591901">12.1.9. How to handle incrementing
versions when fixing an existing
package</a></span></dt>
<dt><span class="sect2"><a href=
"#id2591950">12.1.10. Portability of
packages</a></span></dt>
</dl>
</dd>
<dt><span class="sect1"><a href="#id2591975">12.2.
Possible downloading issues</a></span></dt>
<dd>
<dl>
<dt><span class="sect2"><a href=
"#id2591978">12.2.1. Packages whose distfiles
aren't available for plain
downloading</a></span></dt>
<dt><span class="sect2"><a href=
"#id2592109">12.2.2. How to handle modified
distfiles with the 'old' name</a></span></dt>
</dl>
</dd>
<dt><span class="sect1"><a href="#id2592121">12.3.
Configuration gotchas</a></span></dt>
<dd>
<dl>
<dt><span class="sect2"><a href=
"#fixes.libtool">12.3.1. Shared libraries -
libtool</a></span></dt>
<dt><span class="sect2"><a href=
"#id2592529">12.3.2. Using libtool on GNU
packages that already support
libtool</a></span></dt>
<dt><span class="sect2"><a href=
"#id2592613">12.3.3. GNU
Autoconf/Automake</a></span></dt>
</dl>
</dd>
<dt><span class="sect1"><a href="#id2592726">12.4.
Building considerations</a></span></dt>
<dd>
<dl>
<dt><span class="sect2"><a href=
"#id2592729">12.4.1. CPP defines</a></span></dt>
</dl>
</dd>
<dt><span class="sect1"><a href="#id2592759">12.5.
Package specific actions</a></span></dt>
<dd>
<dl>
<dt><span class="sect2"><a href=
"#id2592762">12.5.1. Package configuration
files</a></span></dt>
<dt><span class="sect2"><a href=
"#id2592933">12.5.2. User
interaction</a></span></dt>
<dt><span class="sect2"><a href=
"#id2593046">12.5.3. Handling
licenses</a></span></dt>
<dt><span class="sect2"><a href=
"#id2593197">12.5.4. Creating an account from a
package</a></span></dt>
<dt><span class="sect2"><a href=
"#id2593328">12.5.5. Installing score
files</a></span></dt>
<dt><span class="sect2"><a href=
"#id2593371">12.5.6. Packages providing login
shells</a></span></dt>
<dt><span class="sect2"><a href=
"#id2593429">12.5.7. Packages containing perl
scripts</a></span></dt>
<dt><span class="sect2"><a href=
"#id2593447">12.5.8. Packages with hardcoded
paths to other interpreters</a></span></dt>
<dt><span class="sect2"><a href=
"#id2593468">12.5.9. Packages installing perl
modules</a></span></dt>
<dt><span class="sect2"><a href=
"#faq.info-files">12.5.10. Packages installing
info files</a></span></dt>
<dt><span class="sect2"><a href=
"#id2593688">12.5.11. Packages installing GConf2
data files</a></span></dt>
<dt><span class="sect2"><a href=
"#id2593788">12.5.12. Packages installing
scrollkeeper data files</a></span></dt>
<dt><span class="sect2"><a href=
"#id2593840">12.5.13. Packages installing X11
fonts</a></span></dt>
<dt><span class="sect2"><a href=
"#id2593886">12.5.14. Packages installing GTK2
modules</a></span></dt>
<dt><span class="sect2"><a href=
"#id2593956">12.5.15. Packages installing SGML or
XML data</a></span></dt>
<dt><span class="sect2"><a href=
"#id2594076">12.5.16. Packages installing
extensions to the MIME database</a></span></dt>
<dt><span class="sect2"><a href=
"#id2594283">12.5.17. Packages using
intltool</a></span></dt>
</dl>
</dd>
<dt><span class="sect1"><a href="#id2594297">12.6.
Feedback to the author</a></span></dt>
</dl>
</dd>
<dt><span class="chapter"><a href="#debug">13.
Debugging</a></span></dt>
<dt><span class="chapter"><a href="#submit">14.
Submitting and Committing</a></span></dt>
<dd>
<dl>
<dt><span class="sect1"><a href="#id2594827">14.1.
Submitting your packages</a></span></dt>
<dt><span class="sect1"><a href="#id2594878">14.2.
Committing: Importing a package into
CVS</a></span></dt>
<dt><span class="sect1"><a href="#id2594941">14.3.
Updating a package to a newer version</a></span></dt>
<dt><span class="sect1"><a href="#id2594961">14.4.
Moving a package in pkgsrc</a></span></dt>
</dl>
</dd>
</dl>
</div>
<div class="chapter" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h2 class="title"><a name="components" id=
"components"></a>Chapter&nbsp;7.&nbsp;Package
components - files, directories and contents</h2>
</div>
</div>
</div>
<div class="toc">
<p><b>Table of Contents</b></p>
<dl>
<dt><span class="sect1"><a href=
"#components.Makefile">7.1. <code class=
"filename">Makefile</code></a></span></dt>
<dt><span class="sect1"><a href=
"#components.distinfo">7.2. <code class=
"filename">distinfo</code></a></span></dt>
<dt><span class="sect1"><a href=
"#components.patches">7.3. patches/*</a></span></dt>
<dt><span class="sect1"><a href="#id2586445">7.4. Other
mandatory files</a></span></dt>
<dt><span class="sect1"><a href=
"#components.optional">7.5. Optional
files</a></span></dt>
<dt><span class="sect1"><a href="#id2586640">7.6.
<code class="filename">work*</code></a></span></dt>
<dt><span class="sect1"><a href="#id2586727">7.7.
<code class="filename">files/*</code></a></span></dt>
</dl>
</div>
<p>Whenever you're preparing a package, there are a number
of files involved which are described in the following
sections.</p>
<div class="sect1" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h2 class="title" style="clear: both"><a name=
"components.Makefile" id=
"components.Makefile"></a>7.1.&nbsp;<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>.</p>
<p>There is a <code class="filename">Makefile</code> for
each package. This file includes the standard
<code class="filename">bsd.pkg.mk</code> file (referenced
as <code class="filename">../../mk/bsd.pkg.mk</code>),
which sets all the definitions and actions necessary for
the package to compile and install itself. The mandatory
variables are the <code class="varname">DISTNAME</code>
which specifies the base name of the distribution file to
be downloaded from the site on the Internet, <code class=
"varname">MASTER_SITES</code> which specifies that site,
<code class="varname">CATEGORIES</code> which denotes the
categories into which the package falls, <code class=
"varname">PKGNAME</code> which is the name of the
package, the <code class="varname">MAINTAINER</code>'s
name, and the <code class="varname">COMMENT</code>
variable, which should contain a one-line description of
the package (the package name should not appear, it will
be added automatically). The maintainer variable is there
so that anyone who quibbles with the (always completely
correct) decisions taken by the guy who maintains the
package can complain vigorously, or send chocolate as a
sign of appreciation.</p>
<p>The <code class="varname">MASTER_SITES</code> may be
set to one of the predefined sites:</p>
<pre class="programlisting">
${MASTER_SITE_APACHE}
${MASTER_SITE_DEBIAN}
${MASTER_SITE_GNOME}
${MASTER_SITE_GNU}
${MASTER_SITE_GNUSTEP}
${MASTER_SITE_IFARCHIVE}
${MASTER_SITE_MOZILLA}
${MASTER_SITE_PERL_CPAN}
${MASTER_SITE_SOURCEFORGE}
${MASTER_SITE_SUNSITE}
${MASTER_SITE_R_CRAN}
${MASTER_SITE_SUSE}
${MASTER_SITE_TEX_CTAN}
${MASTER_SITE_XCONTRIB}
${MASTER_SITE_XEMACS}
</pre>
<p>If one of these predefined sites is chosen, you may
require the ability to specify a subdirectory of that
site. Since these macros may expand to more than one
actual site, you <span class=
"emphasis"><em>must</em></span> use the following
construct to specify a subdirectory:</p>
<pre class="programlisting">
${MASTER_SITE_GNU:=subdirectory/name/}
${MASTER_SITE_SOURCEFORGE:=project_name/}
</pre>
<p>Note the trailing slash after the subdirectory
name.</p>
<div class="note" style=
"margin-left: 0.5in; margin-right: 0.5in;">
<h3 class="title">Note</h3>
<p><code class="varname">MASTER_SITE_SUBDIR</code> has
been deprecated and <span class="emphasis"><em>should
no longer be used</em></span>.</p>
</div>
<p>If the package has multiple <code class=
"varname">DISTFILES</code> or multiple <code class=
"varname">PATCHFILES</code> from different sites, set
<code class="varname">SITES_foo</code> to a list of URI's
where file &#8220;<span class="quote">foo</span>&#8221;
may be found. &#8220;<span class=
"quote">foo</span>&#8221; includes the suffix, e.g.</p>
<pre class="programlisting">
DISTFILES= ${DISTNAME}${EXTRACT_SUFX}
DISTFILES+= foo-file.tar.gz
SITES_foo-file.tar.gz=http://www.somewhere.com/somehow/ \
http://www.somewhereelse.com/mirror/somehow/
</pre>
<p>Note that the normal default setting of <code class=
"varname">DISTFILES</code> must be made explicit if you
want to add to it (rather than replace it), as you
usually would.</p>
<p>Currently the following values are available for
<code class="varname">CATEGORIES</code>. If more than one
is used, they need to be separated by spaces:</p>
<pre class="programlisting">
archivers cross geography meta-pkgs security
audio databases graphics misc shells
benchmarks devel ham multimedia sysutils
biology editors inputmethod net textproc
cad emulators lang news time
chat finance mail parallel wm
comms fonts math pkgtools www
converters games mbone print x11
</pre>
<p>Please pay attention to the following gotchas:</p>
<div class="itemizedlist">
<ul type="disc">
<li>
<p>Add <code class="varname">MANCOMPRESSED</code>
if manpages are installed in compressed form by the
package; see comment in <code class=
"filename">bsd.pkg.mk</code>.</p>
</li>
<li>
<p>Replace <code class="filename">/usr/local</code>
with &#8220;<span class=
"quote">${PREFIX}</span>&#8221; in all files (see
patches, below).</p>
</li>
<li>
<p>If the package installs any info files, see
<a href="#faq.info-files" title=
"12.5.10.&nbsp;Packages installing info files">Section
12.5.10, &#8220;Packages installing info
files&#8221;</a>.</p>
</li>
<li>
<p>Set <code class="varname">MAINTAINER</code> to
be yourself. If you really can't maintain the
package for future updates, set it to <code class=
"email">&lt;<a href=
"mailto:tech-pkg@NetBSD.org">tech-pkg@NetBSD.org</a>&gt;</code>.</p>
</li>
<li>
<p>If a home page for the software in question
exists, add the variable <code class=
"varname">HOMEPAGE</code> right after <code class=
"varname">MAINTAINER</code>. The value of this
variable should be the URL for the home page.</p>
</li>
<li>
<p>Be sure to set the <code class=
"varname">COMMENT</code> variable to a short
description of the package, not containing the
pkg's name.</p>
</li>
</ul>
</div>
</div>
<div class="sect1" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h2 class="title" style="clear: both"><a name=
"components.distinfo" id=
"components.distinfo"></a>7.2.&nbsp;<code class=
"filename">distinfo</code></h2>
</div>
</div>
</div>
<p>Most important, the mandatory message digest, or
checksum, of all the distfiles needed for the package to
compile, confirming they match the original file
distributed by the author. This ensures that the distfile
retrieved from the Internet has not been corrupted during
transfer or altered by a malign force to introduce a
security hole. It is generated using the
<span><strong class="command">make
makesum</strong></span> command. The digest algorithm
used was, at one stage, md5, but that was felt lacking
compared to sha1, and so sha1 is now the default
algorithm. The distfile size is also generated and stored
in new distinfo files. The <a xmlns=
"http://www.w3.org/TR/xhtml1/transitional" href=
"ftp://ftp.NetBSD.org/pub/NetBSD/packages/pkgsrc/pkgtools/digest/README.html"
class="pkgname">pkgtools/digest</a> utility calculates
all of the digests in the distinfo file, and it provides
various different algorithms. At the current time, the
algorithms provided are: <span class=
"emphasis"><em>md5</em></span>, <span class=
"emphasis"><em>rmd160</em></span>, <span class=
"emphasis"><em>sha1</em></span>, <span class=
"emphasis"><em>sha256</em></span>, <span class=
"emphasis"><em>sha384</em></span> and <span class=
"emphasis"><em>sha512</em></span>.</p>
<p>Some packages have different sets of distfiles on a
per architecture basis, for example <a xmlns=
"http://www.w3.org/TR/xhtml1/transitional" href=
"ftp://ftp.NetBSD.org/pub/NetBSD/packages/pkgsrc/www/navigator/README.html"
class="pkgname">www/navigator</a>). These are kept in the
same distinfo file and care should be taken when
upgrading such a package to ensure distfile information
is not lost.</p>
<p>The message digest/checksum for all the official
patches found in the <code class=
"filename">patches/</code> directory (see <a href=
"#components.patches" title=
"7.3.&nbsp;patches/*">Section&nbsp;7.3,
&#8220;patches/*&#8221;</a>) for the package is also
stored in the <code class="filename">distinfo</code>
file. This is a message digest/checksum of all lines in
the patch file except the NetBSD RCS Id. This file is
generated by invoking <span><strong class="command">make
makepatchsum</strong></span> (or <span><strong class=
"command">make mps</strong></span> if you're in a
hurry).</p>
</div>
<div class="sect1" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h2 class="title" style="clear: both"><a name=
"components.patches" id=
"components.patches"></a>7.3.&nbsp;patches/*</h2>
</div>
</div>
</div>
<p>This directory contains files that are used by the
<a href=
"http://netbsd.gw.com/cgi-bin/man-cgi?patch+1+NetBSD-current">
<span class="citerefentry"><span class=
"refentrytitle">patch</span>(1)</span></a> command to
modify the sources as distributed in the distribution
file into a form that will compile and run perfectly on
NetBSD. The files are applied successively in alphabetic
order (as returned by a shell &#8220;<span class=
"quote">patches/patch-*</span>&#8221; glob expansion), so
<code class="filename">patch-aa</code> is applied before
<code class="filename">patch-ab</code>, etc.</p>
<p>The <code class="filename">patch-*</code> files should
be in <span><strong class="command">diff
-bu</strong></span> format, and apply without a fuzz to
avoid problems. (To force patches to apply with fuzz you
can set <code class=
"varname">PATCH_FUZZ_FACTOR=-F2</code>). Furthermore, do
not put changes for more than one file into a single
patch-file, as this will make future modifications more
difficult.</p>
<p>Similar, a file should be patched at most once, not
several times by several different patches. If a file
needs several patches, they should be combined into one
file.</p>
<p>One important thing to mention is to pay attention
that no RCS IDs get stored in the patch files, as these
will cause problems when later checked into the NetBSD
CVS tree. Use the <span><strong class=
"command">pkgdiff</strong></span> from the <a xmlns=
"http://www.w3.org/TR/xhtml1/transitional" href=
"ftp://ftp.NetBSD.org/pub/NetBSD/packages/pkgsrc/pkgtools/pkgdiff/README.html"
class="pkgname">pkgtools/pkgdiff</a> package to avoid
these problems.</p>
<p>For even more automation, we recommend using
<span><strong class="command">mkpatches</strong></span>
from the same package to make a whole set of patches. You
just have to backup files before you edit them to
<code class="filename">filename.orig</code>, e.g. with
<span><strong class="command">cp -p filename
filename.orig</strong></span> or, easier, by using
<span><strong class="command">pkgvi</strong></span> again
from the same package. If you upgrade a package this way,
you can easily compare the new set of patches with the
previously existing one with <span><strong class=
"command">patchdiff</strong></span>.</p>
<p>When you have finished a package, remember to generate
the checksums for the patch files by using the
<span><strong class="command">make
makepatchsum</strong></span> command, see <a href=
"#components.distinfo" title=
"7.2.&nbsp;distinfo">Section&nbsp;7.2,
&#8220;<code class="filename">distinfo</code>&#8221;</a>.</p>
<p>Patch files that are distributed by the author or
other maintainers can be listed in <code class=
"varname">$PATCHFILES</code>.</p>
<p>If it is desired to store any patches that should not
be committed into pkgsrc, they can be kept outside the
pkgsrc tree in the <code class=
"filename">$LOCALPATCHES</code> directory. The directory
tree there is expected to have the same
&#8220;<span class="quote">category/package</span>&#8221;
structure as pkgsrc, and patches are expected to be
stored inside these dirs (also known as <code class=
"filename">$LOCALPATCHES/$PKGPATH</code>). For example if
you want to keep a private patch for <code class=
"filename">pkgsrc/graphics/png</code>, keep it in
<code class=
"filename">$LOCALPATCHES/graphics/png/mypatch</code>. All
files in the named directory are expected to be patch
files, and <span class="emphasis"><em>they are applied
after pkgsrc patches are applied</em></span>.</p>
</div>
<div class="sect1" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h2 class="title" style="clear: both"><a name=
"id2586445" id="id2586445"></a>7.4.&nbsp;Other
mandatory files</h2>
</div>
</div>
</div>
<div class="variablelist">
<dl>
<dt><span class="term"><code class=
"filename">DESCR</code></span></dt>
<dd>
<p>A multi-line description of the piece of
software. This should include any credits where
they are due. Please bear in mind that others do
not share your sense of humour (or spelling
idiosyncrasies), and that others will read
everything that you write here.</p>
</dd>
<dt><span class="term"><code class=
"filename">PLIST</code></span></dt>
<dd>
<p>This file governs the files that are installed
on your system: all the binaries, manual pages,
etc. There are other directives which may be
entered in this file, to control the creation and
deletion of directories, and the location of
inserted files. See <a href="#plist" title=
"Chapter&nbsp;8.&nbsp;PLIST issues">Chapter&nbsp;8,
<i>PLIST issues</i></a> for more information.</p>
</dd>
</dl>
</div>
</div>
<div class="sect1" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h2 class="title" style="clear: both"><a name=
"components.optional" id=
"components.optional"></a>7.5.&nbsp;Optional
files</h2>
</div>
</div>
</div>
<div class="variablelist">
<dl>
<dt><span class="term"><code class=
"filename">INSTALL</code></span></dt>
<dd>
<p>This shell script is invoked twice by <a href=
"http://netbsd.gw.com/cgi-bin/man-cgi?pkg_add+1+NetBSD-current">
<span class="citerefentry"><span class=
"refentrytitle">pkg_add</span>(1)</span></a>. First
time after package extraction and before files are
moved in place, the second time after the files to
install are moved in place. This can be used to do
any custom procedures not possible with @exec
commands in <code class="filename">PLIST</code>.
See <a href=
"http://netbsd.gw.com/cgi-bin/man-cgi?pkg_add+1+NetBSD-current">
<span class="citerefentry"><span class=
"refentrytitle">pkg_add</span>(1)</span></a> and
<a href=
"http://netbsd.gw.com/cgi-bin/man-cgi?pkg_create+1+NetBSD-current">
<span class="citerefentry"><span class=
"refentrytitle">pkg_create</span>(1)</span></a> for
more information.</p>
</dd>
<dt><span class="term"><code class=
"filename">DEINSTALL</code></span></dt>
<dd>
<p>This script is executed before and after any
files are removed. It is this script's
responsibility to clean up any additional messy
details around the package's installation, since
all pkg_delete knows is how to delete the files
created in the original distribution. See <a href=
"http://netbsd.gw.com/cgi-bin/man-cgi?pkg_delete+1+NetBSD-current">
<span class="citerefentry"><span class=
"refentrytitle">pkg_delete</span>(1)</span></a> and
<a href=
"http://netbsd.gw.com/cgi-bin/man-cgi?pkg_create+1+NetBSD-current">
<span class="citerefentry"><span class=
"refentrytitle">pkg_create</span>(1)</span></a> for
more information.</p>
</dd>
<dt><span class="term"><code class=
"filename">MESSAGE</code></span></dt>
<dd>
<p>Display this file after installation of the
package. Useful for things like legal notices on
almost-free software and hints for updating config
files after installing modules for apache, PHP etc.
Please note that you can modify variables in it
easily by using <code class=
"varname">MESSAGE_SUBST</code> in the package's
<code class="filename">Makefile</code>:</p>
<pre class="programlisting">
MESSAGE_SUBST+= SOMEVAR="somevalue"
</pre>
<p>replaces "${SOMEVAR}" with &#8220;<span class=
"quote">somevalue</span>&#8221; in <code class=
"filename">MESSAGE</code>.</p>
</dd>
</dl>
</div>
</div>
<div class="sect1" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h2 class="title" style="clear: both"><a name=
"id2586640" id=
"id2586640"></a>7.6.&nbsp;<code class=
"filename">work*</code></h2>
</div>
</div>
</div>
<p>When you type <span><strong class=
"command">make</strong></span> the distribution files are
unpacked into this directory. It can be removed by
running <span><strong class="command">make
clean</strong></span>. Besides the sources, this
directory is also used to keep various timestamp
files.</p>
<p>If a package doesn't create a subdirectory for itself
(like GNU software does, for instance), but extracts
itself in the current directory, you should set
<code class="varname">WRKSRC</code> accordingly, e.g.
<a xmlns="http://www.w3.org/TR/xhtml1/transitional" href=
"ftp://ftp.NetBSD.org/pub/NetBSD/packages/pkgsrc/editors/sam/README.html"
class="pkgname">editors/sam</a> again, but the quick
answer is:</p>
<pre class="programlisting">
WRKSRC= ${WRKDIR}
</pre>
<p>Please note that the old <code class=
"varname">NO_WRKSUBDIR</code> has been deprecated and
should not be used. Also, if your package doesn't create
a subdir with the name of <code class=
"varname">DISTNAME</code> but some different name, set
<code class="varname">WRKSRC</code> to point to the
proper name in <code class="filename">${WRKDIR}</code>.
See <a xmlns="http://www.w3.org/TR/xhtml1/transitional"
href=
"ftp://ftp.NetBSD.org/pub/NetBSD/packages/pkgsrc/lang/tcl/README.html"
class="pkgname">lang/tcl</a> and <a xmlns=
"http://www.w3.org/TR/xhtml1/transitional" href=
"ftp://ftp.NetBSD.org/pub/NetBSD/packages/pkgsrc/x11/tk/README.html"
class="pkgname">x11/tk</a> for examples, and here is
another one:</p>
<pre class="programlisting">
WRKSRC= ${WRKDIR}/${DISTNAME}/unix
</pre>
<p>The name of the working directory created by pkgsrc is
<code class="filename">work</code> by default. If the
same pkgsrc tree should be used on several different
platforms, the variable <code class=
"varname">OBJMACHINE</code> can be set in /etc/mk.conf to
attach the platform to the directory name, e.g.
<code class="filename">work.i386</code> or <code class=
"filename">work.sparc</code>.</p>
</div>
<div class="sect1" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h2 class="title" style="clear: both"><a name=
"id2586727" id=
"id2586727"></a>7.7.&nbsp;<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 could
place these files here and use a &#8220;<span class=
"quote">${CP}</span>&#8221; command in the
&#8220;<span class="quote">pre-configure</span>&#8221;
target to achieve this. Alternatively, you could simply
diff the file against <code class=
"filename">/dev/null</code> and use the patch mechanism
to manage the creation of this file.</p>
</div>
</div>
<div class="chapter" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h2 class="title"><a name="plist" id=
"plist"></a>Chapter&nbsp;8.&nbsp;PLIST issues</h2>
</div>
</div>
</div>
<div class="toc">
<p><b>Table of Contents</b></p>
<dl>
<dt><span class="sect1"><a href="#id2586781">8.1. RCS
ID</a></span></dt>
<dt><span class="sect1"><a href="#id2586796">8.2.
Semi-automatic <code class="filename">PLIST</code>
generation</a></span></dt>
<dt><span class="sect1"><a href="#print-PLIST">8.3.
Tweaking output of <span><strong class="command">make
print-PLIST</strong></span></a></span></dt>
<dt><span class="sect1"><a href="#plist.misc">8.4.
Variable substitution in PLIST</a></span></dt>
<dt><span class="sect1"><a href="#id2587186">8.5.
Manpage-compression</a></span></dt>
<dt><span class="sect1"><a href="#id2587227">8.6.
Changing PLIST source with <code class=
"varname">PLIST_SRC</code></a></span></dt>
<dt><span class="sect1"><a href="#id2587244">8.7.
Platform specific and differing PLISTs</a></span></dt>
<dt><span class="sect1"><a href="#faq.common-dirs">8.8.
Sharing directories between packages</a></span></dt>
</dl>
</div>
<p>The <code class="filename">PLIST</code> file contains a
package's &#8220;<span class="quote">packing
list</span>&#8221;, 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 href=
"http://netbsd.gw.com/cgi-bin/man-cgi?pkg_create+1+NetBSD-current">
<span class="citerefentry"><span class=
"refentrytitle">pkg_create</span>(1)</span></a> manpage for
a full list. This chapter addresses some issues that need
attention when dealing with the <code class=
"filename">PLIST</code> file (or files, see below!).</p>
<div class="sect1" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h2 class="title" style="clear: both"><a name=
"id2586781" id="id2586781"></a>8.1.&nbsp;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">
@comment $NetBSD$
</pre>
</div>
<div class="sect1" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h2 class="title" style="clear: both"><a name=
"id2586796" id=
"id2586796"></a>8.2.&nbsp;Semi-automatic
<code class="filename">PLIST</code> generation</h2>
</div>
</div>
</div>
<p>You can use the <span><strong class="command">make
print-PLIST</strong></span> command to output a PLIST
that matches any new files since the package was
extracted. See <a href="#build.helpful-targets" title=
"11.3.&nbsp;Other helpful targets">Section&nbsp;11.3,
&#8220;Other helpful targets&#8221;</a> for more
information on this target.</p>
</div>
<div class="sect1" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h2 class="title" style="clear: both"><a name=
"print-PLIST" id=
"print-PLIST"></a>8.3.&nbsp;Tweaking output of
<span><strong class="command">make
print-PLIST</strong></span></h2>
</div>
</div>
</div>
<p>If you have used any of the *-dirs packages, as
explained in <a href="#faq.common-dirs" title=
"8.8.&nbsp;Sharing directories between packages">Section&nbsp;8.8,
&#8220;Sharing directories between packages&#8221;</a>,
you may have noticed that <span><strong class=
"command">make print-PLIST</strong></span> outputs a set
of <code class="varname">@comment</code>s instead of real
<code class="varname">@dirrm</code> lines. You can also
do this for specific directories and files, so that the
results of that command are very close to reality. This
helps <span class="emphasis"><em>a lot</em></span> during
the update of packages.</p>
<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 print-PLIST. You can
<span class="emphasis"><em>append</em></span> any chunk
of AWK scripting you like to it, but be careful with
quoting.</p>
<p>For example, to get all files inside the <code class=
"filename">libdata/foo</code> directory removed from the
resulting PLIST:</p>
<pre class="programlisting">
PRINT_PLIST_AWK+= /^libdata\/foo/ { next; }
</pre>
<p>And to get all the <code class="varname">@dirrm</code>
lines referring to a specific (shared) directory
converted to <code class="varname">@comment</code>s:</p>
<pre class="programlisting">
PRINT_PLIST_AWK+= /^@dirrm share\/specific/ { print "@comment " $$0; next; }
</pre>
</div>
<div class="sect1" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h2 class="title" style="clear: both"><a name=
"plist.misc" id="plist.misc"></a>8.4.&nbsp;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>
<div class="variablelist">
<dl>
<dt><span class="term"><code class=
"varname">${MACHINE_ARCH}</code>, <code class=
"varname">${MACHINE_GNU_ARCH}</code></span></dt>
<dd>
<p>Some packages like emacs and perl embed
information about which architecture they were
built on into the pathnames where they install
their file. To handle this case, PLIST will be
preprocessed before actually used, and the symbol
&#8220;<span class="quote"><code class=
"varname">${MACHINE_ARCH}</code></span>&#8221; will
be replaced by what <span><strong class=
"command">uname -p</strong></span> gives. The same
is done if the string <code class=
"varname">${MACHINE_GNU_ARCH}</code> is embedded in
PLIST somewhere - use this on packages that have
GNU autoconf created configure scripts.</p>
<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 &#8220;<span class=
"quote"><code class=
"varname">$ARCH</code></span>&#8221; that was
replaced by the output of <span><strong class=
"command">uname -m</strong></span>, but that's no
longer supported and has been removed.</p>
</div>
</dd>
<dt><span class="term"><code class=
"varname">${OPSYS}</code>, <code class=
"varname">${LOWER_OPSYS}</code>, <code class=
"varname">${OS_VERSION}</code></span></dt>
<dd>
<p>Some packages want to embed the OS name and
version into some paths. To do this, use these
variables in the <code class=
"filename">PLIST</code>:</p>
<div class="itemizedlist">
<ul type="disc">
<li>
<p><code class="varname">${OPSYS}</code> -
output of &#8220;<span class=
"quote"><span><strong class="command">uname
-s</strong></span></span>&#8221;</p>
</li>
<li>
<p><code class=
"varname">${LOWER_OPSYS}</code> - lowercase
common name (eg. &#8220;<span class=
"quote">solaris</span>&#8221;)</p>
</li>
<li>
<p><code class="varname">${OS_VERSION}</code>
- &#8220;<span class=
"quote"><span><strong class="command">uname
-r</strong></span></span>&#8221;</p>
</li>
</ul>
</div>
</dd>
<dt><span class="term"><code class=
"varname">${PKGLOCALEDIR}</code></span></dt>
<dd>
<p>Packages that install locale files should list
them in the PLIST as &#8220;<span class=
"quote">${PKGLOCALEDIR}/locale/de/LC_MESSAGES/...</span>&#8221;
instead of &#8220;<span class=
"quote">share/locale/de/LC_MESSAGES/...</span>&#8221;.
This properly handles the fact that different
operating systems expect locale files to be either
in <code class="filename">share</code> or
<code class="filename">lib</code> by default.</p>
</dd>
</dl>
</div>
<p>For a complete list of values which are replaced by
default, please look in <code class=
"filename">bsd.pkg.mk</code> (and search for <span class=
"emphasis"><em>PLIST_SUBST</em></span>).</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 href=
"#components.optional" title=
"7.5.&nbsp;Optional files">Section&nbsp;7.5,
&#8220;Optional files&#8221;</a>):</p>
<pre class="programlisting">
PLIST_SUBST+= SOMEVAR="somevalue"
</pre>
<p>This replaces all occurrences of &#8220;<span class=
"quote">${SOMEVAR}</span>&#8221; in the PLIST with
&#8220;<span class="quote">somevalue</span>&#8221;.</p>
</div>
<div class="sect1" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h2 class="title" style="clear: both"><a name=
"id2587186" id=
"id2587186"></a>8.5.&nbsp;Manpage-compression</h2>
</div>
</div>
</div>
<p>Manpages 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
&#8220;<span class="quote">.gz</span>&#8221; is
appended/removed automatically for manpages 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 <code class=
"filename">PLIST</code> file is done on a copy of it, not
<code class="filename">PLIST</code> itself.</p>
</div>
<div class="sect1" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h2 class="title" style="clear: both"><a name=
"id2587227" id="id2587227"></a>8.6.&nbsp;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 <code class=
"varname">PLIST_SRC</code> to the names of that file(s).
The files are later concatenated using cat(1), and order
of things is important.</p>
</div>
<div class="sect1" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h2 class="title" style="clear: both"><a name=
"id2587244" id="id2587244"></a>8.7.&nbsp;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>
<div class="itemizedlist">
<ul type="disc">
<li>
<p><code class="filename">PLIST.common</code></p>
</li>
<li>
<p><code class="filename">PLIST.${OPSYS}</code></p>
</li>
<li>
<p><code class=
"filename">PLIST.common_end</code></p>
</li>
</ul>
</div>
<p>If <code class="filename">PLIST.${OPSYS}</code>
exists, these files are used instead of <code class=
"filename">PLIST</code>. This allows packages which
behave in this way to be handled gracefully. Manually
overriding <code class="varname">PLIST_SRC</code> for
other more exotic uses is also possible.</p>
</div>
<div class="sect1" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h2 class="title" style="clear: both"><a name=
"faq.common-dirs" id=
"faq.common-dirs"></a>8.8.&nbsp;Sharing directories
between packages</h2>
</div>
</div>
</div>
<p>A &#8220;<span class="quote">shared
directory</span>&#8221; is a directory where multiple
(and unrelated) packages install files. These directories
are problematic because you have to add special tricks in
the PLIST to conditionally remove them, or have some
centralized package handle them.</p>
<p>Within pkgsrc, you'll find both approaches. If a
directory is shared by a few unrelated packages, it's
often not worth to add an extra package to remove it.
Therefore, one simply does:</p>
<pre class="programlisting">
@unexec ${RMDIR} %D/path/to/shared/directory 2&gt;/dev/null || ${TRUE}
</pre>
<p>in the PLISTs of all affected packages, instead of the
regular "@dirrm" line.</p>
<p>However, if the directory is shared across many
packages, two different solutions are available:</p>
<div class="orderedlist">
<ol type="1">
<li>
<p>If the packages have a common dependency, the
directory can be removed in that. For example, see
<a xmlns="http://www.w3.org/TR/xhtml1/transitional"
href=
"ftp://ftp.NetBSD.org/pub/NetBSD/packages/pkgsrc/textproc/scrollkeeper/README.html"
class="pkgname">textproc/scrollkeeper</a>, which
removes the shared directory <code class=
"filename">share/omf</code>.</p>
</li>
<li>
<p>If the packages using the directory are not
related at all (they have no common dependencies),
a *-dirs package is used.</p>
</li>
</ol>
</div>
<p>From now on, we'll discuss the second solution. To get
an idea of the *-dirs packages available, issue:</p>
<pre class="programlisting">
<code class="prompt">%</code> cd .../pkgsrc
<code class="prompt">%</code> ls -d */*-dirs
</pre>
<p>Their use from other packages is very simple. The
<code class="varname">USE_DIRS</code> variable takes a
list of package names (without the &#8220;<span class=
"quote">-dirs</span>&#8221; part) together with the
required version number (always pick the latest one when
writting new packages).</p>
<p>For example, if a package installs files under
<code class="filename">share/applications</code>, it
should have the following line in it:</p>
<pre class="programlisting">
USE_DIRS+= xdg-1.1
</pre>
<p>After regenerating the PLIST using
<span><strong class="command">make
print-PLIST</strong></span>, you should get the right
(commented out) lines.</p>
<p>Note that, even if your package is using <code class=
"filename">$X11BASE</code>, it must not depend on the
*-x11-dirs packages. Just specify the name without that
part and pkgsrc (in particular, <code class=
"filename">mk/dirs.mk</code>) will take care of it.</p>
</div>
</div>
<div class="chapter" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h2 class="title"><a name="buildlink" id=
"buildlink"></a>Chapter&nbsp;9.&nbsp;Buildlink
methodology</h2>
</div>
</div>
</div>
<div class="toc">
<p><b>Table of Contents</b></p>
<dl>
<dt><span class="sect1"><a href="#id2587653">9.1.
Converting packages to use buildlink3</a></span></dt>
<dt><span class="sect1"><a href="#id2587844">9.2.
Writing <code class="filename">buildlink3.mk</code>
files</a></span></dt>
<dd>
<dl>
<dt><span class="sect2"><a href="#id2587913">9.2.1.
Anatomy of a buildlink3.mk file</a></span></dt>
<dt><span class="sect2"><a href="#id2588354">9.2.2.
Updating <code class=
"varname">BUILDLINK_DEPENDS.<em class=
"replaceable"><code>pkg</code></em></code> in
<code class="filename">buildlink3.mk</code>
files</a></span></dt>
</dl>
</dd>
<dt><span class="sect1"><a href="#id2588433">9.3.
Writing <code class="filename">builtin.mk</code>
files</a></span></dt>
<dd>
<dl>
<dt><span class="sect2"><a href="#id2588582">9.3.1.
Anatomy of a <code class=
"filename">builtin.mk</code> file</a></span></dt>
<dt><span class="sect2"><a href="#id2588877">9.3.2.
Global preferences for native or pkgsrc
software</a></span></dt>
</dl>
</dd>
</dl>
</div>
<p>Buildlink is a framework in pkgsrc that controls what
headers and libraries are seen by a package's configure and
build processes. This is implemented in a two step
process:</p>
<div class="orderedlist">
<ol type="1">
<li>
<p>Symlink headers and libraries for dependencies
into <code class="varname">BUILDLINK_DIR</code>,
which by default is a subdirectory of <code class=
"varname">WRKDIR</code>.</p>
</li>
<li>
<p>Create wrapper scripts that are used in place of
the normal compiler tools that translate <code class=
"option">-I${LOCALBASE}/include</code> and
<code class="option">-L${LOCALBASE}/lib</code> into
references to <code class=
"varname">BUILDLINK_DIR</code>. The wrapper scripts
also make native compiler on some operating systems
look like GCC, so that packages that expect GCC won't
require modifications to build with those native
compilers.</p>
</li>
</ol>
</div>
<p>This normalizes the environment in which a package is
built so that the package may be built consistently despite
what other software may be installed. Please note that the
normal system header and library paths, e.g. <code class=
"filename">/usr/include</code>, <code class=
"filename">/usr/lib</code>, etc., are always searched --
buildlink3 is designed to insulate the package build from
non-system-supplied software.</p>
<div class="sect1" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h2 class="title" style="clear: both"><a name=
"id2587653" id="id2587653"></a>9.1.&nbsp;Converting
packages to use buildlink3</h2>
</div>
</div>
</div>
<p>The process of converting packages to use the
buildlink3 framework (&#8220;<span class=
"quote">bl3ifying</span>&#8221;) is fairly
straightforward. The things to keep in mind are:</p>
<div class="orderedlist">
<ol type="1">
<li>
<p>Set <code class="varname">USE_BUILDLINK3</code>
to &#8220;<span class=
"quote">yes</span>&#8221;.</p>
</li>
<li>
<p>Ensure that the build always calls the wrapper
scripts instead of the actual toolchain. Some
packages are tricky, and the only way to know for
sure is the check <code class=
"filename">${WRKDIR}/.work.log</code> to see if the
wrappers are being invoked.</p>
</li>
<li>
<p>Don't override <code class=
"varname">PREFIX</code> from within 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 &#8220;<span class="quote">pkg_info -qp
<em class=
"replaceable"><code>pkgname</code></em></span>&#8221;.</p>
</li>
<li>
<p>Remember that <span class=
"emphasis"><em>only</em></span> the <code class=
"filename">buildlink3.mk</code> files that you list
in a package's Makefile are added as dependencies
for that package.</p>
</li>
</ol>
</div>
<p>If a dependency on a particular package is required
for its libraries and headers, then we replace:</p>
<pre class="programlisting">
DEPENDS+= foo&gt;=1.1.0:../../category/foo
</pre>
<p>with</p>
<pre class="programlisting">
.include "../../category/foo/buildlink3.mk"
</pre>
<p>There are several <code class=
"filename">buildlink3.mk</code> files in <code class=
"filename">pkgsrc/mk</code> that handle special package
issues:</p>
<div class="itemizedlist">
<ul type="disc">
<li>
<p><code class="filename">bdb.buildlink3.mk</code>
chooses either the native or a pkgsrc Berkeley DB
implementation based on the values of <code class=
"varname">BDB_ACCEPTED</code> and <code class=
"varname">BDB_DEFAULT</code>.</p>
</li>
<li>
<p><code class=
"filename">curses.buildlink3.mk</code> If the
system comes with neither Curses nor NCurses, this
will take care to install the <a xmlns=
"http://www.w3.org/TR/xhtml1/transitional" href=
"ftp://ftp.NetBSD.org/pub/NetBSD/packages/pkgsrc/devel/ncurses/README.html"
class="pkgname">devel/ncurses</a> package.</p>
</li>
<li>
<p><code class="filename">krb5.buildlink3.mk</code>
uses the value of <code class=
"varname">KRB5_ACCEPTED</code> to choose between
adding a dependency on Heimdal or MIT-krb5 for
packages that require a Kerberos 5
implementation.</p>
</li>
<li>
<p><code class=
"filename">motif.buildlink3.mk</code> checks for a
system-provided Motif installation or adds a
dependency on <a xmlns=
"http://www.w3.org/TR/xhtml1/transitional" href=
"ftp://ftp.NetBSD.org/pub/NetBSD/packages/pkgsrc/x11/lesstif/README.html"
class="pkgname">x11/lesstif</a> or <a xmlns=
"http://www.w3.org/TR/xhtml1/transitional" href=
"ftp://ftp.NetBSD.org/pub/NetBSD/packages/pkgsrc/x11/openmotif/README.html"
class="pkgname">x11/openmotif</a>;</p>
</li>
<li>
<p><code class=
"filename">ossaudio.buildlink3.mk</code> defines
several variables that may be used by packages that
use the Open Sound System (OSS) API;</p>
</li>
<li>
<p><code class=
"filename">pgsql.buildlink3.mk</code> will accept
either Postgres 7.3 or 7.4, whichever is found
installed. See the file for more information.</p>
</li>
<li>
<p><code class=
"filename">pthread.buildlink3.mk</code> uses the
value of <code class="varname">PTHREAD_OPTS</code>
and checks for native pthreads or adds a dependency
on <a xmlns=
"http://www.w3.org/TR/xhtml1/transitional" href=
"ftp://ftp.NetBSD.org/pub/NetBSD/packages/pkgsrc/devel/pth/README.html"
class="pkgname">devel/pth</a> as needed;</p>
</li>
<li>
<p><code class="filename">xaw.buildlink3.mk</code>
uses the value of <code class=
"varname">XAW_TYPE</code> to choose a particular
Athena widgets library.</p>
</li>
</ul>
</div>
<p>The comments in those <code class=
"filename">buildlink3.mk</code> files provide a more
complete description of how to use them properly.</p>
</div>
<div class="sect1" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h2 class="title" style="clear: both"><a name=
"id2587844" id="id2587844"></a>9.2.&nbsp;Writing
<code class="filename">buildlink3.mk</code>
files</h2>
</div>
</div>
</div>
<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 <code class="filename">buildlink3.mk</code>
file should always provide enough information to add the
correct type of dependency relationship and include any
other <code class="filename">buildlink3.mk</code> files
that it needs to find headers and libraries that it needs
in turn.</p>
<p>To generate an initial <code class=
"filename">buildlink3.mk</code> file for further editing,
Rene Hexel's <a xmlns=
"http://www.w3.org/TR/xhtml1/transitional" href=
"ftp://ftp.NetBSD.org/pub/NetBSD/packages/pkgsrc/pkgtools/createbuildlink/README.html"
class="pkgname">pkgtools/createbuildlink</a> package is
highly recommended. For most packages, the following
command will generate a good starting point for
<code class="filename">buildlink3.mk</code> files:</p>
<pre class="screen">
<code class="prompt">%</code> <strong class=
"userinput"><code>cd pkgsrc/<em class=
"replaceable"><code>category</code></em>/<em class=
"replaceable"><code>pkgdir</code></em>
<code class=
"prompt">%</code> createbuildlink -3 &gt;buildlink3.mk</code></strong>
</pre>
<div class="sect2" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h3 class="title"><a name="id2587913" id=
"id2587913"></a>9.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>
<pre class="programlisting">
# $NetBSD: buildlink3.mk,v 1.7 2004/03/18 09:12:12 jlam Exp $
BUILDLINK_DEPTH:= ${BUILDLINK_DEPTH}+
TIFF_BUILDLINK3_MK:= ${TIFF_BUILDLINK3_MK}+
.if !empty(BUILDLINK_DEPTH:M+)
BUILDLINK_DEPENDS+= tiff
.endif
BUILDLINK_PACKAGES:= ${BUILDLINK_PACKAGES:Ntiff}
BUILDLINK_PACKAGES+= tiff
.if !empty(TIFF_BUILDLINK3_MK:M+)
BUILDLINK_DEPENDS.tiff+= tiff&gt;=3.6.1
BUILDLINK_PKGSRCDIR.tiff?= ../../graphics/tiff
.endif # TIFF_BUILDLINK3_MK
.include "../../devel/zlib/buildlink3.mk"
.include "../../graphics/jpeg/buildlink3.mk"
BUILDLINK_DEPTH:= ${BUILDLINK_DEPTH:S/+$//}
</pre>
<p>The header and footer manipulate <code class=
"varname">BUILDLINK_DEPTH</code>, which is common
across all <code class="filename">buildlink3.mk</code>
files and is used to track at what depth we are
including <code class="filename">buildlink3.mk</code>
files.</p>
<p>The first section controls if the dependency on
<em class="replaceable"><code>pkg</code></em> is added.
<code class="varname">BUILDLINK_DEPENDS</code> is the
global list of packages for which dependencies are
added by buildlink3.</p>
<p>The second section advises pkgsrc that the
<code class="filename">buildlink3.mk</code> file for
<em class="replaceable"><code>pkg</code></em> has been
included at some point. <code class=
"varname">BUILDLINK_PACKAGES</code> is the global list
of packages for which <code class=
"filename">buildlink3.mk</code> files have been
included. It must <span class=
"emphasis"><em>always</em></span> be appended to within
a <code class="filename">buildlink3.mk</code> file.</p>
<p>The third section is protected from multiple
inclusion and controls how the dependency on <em class=
"replaceable"><code>pkg</code></em> is added. Several
important variables are set in the section:</p>
<div class="itemizedlist">
<ul type="disc">
<li>
<p><code class=
"varname">BUILDLINK_DEPENDS.<em class=
"replaceable"><code>pkg</code></em></code> is the
actual dependency recorded in the installed
package; this should always be set using
<span><strong class="command">+=</strong></span>
to ensure that we're appending to any
pre-existing list of values. This variable should
be set to the first version of the package that
had the last change in the major number of a
shared library or that had a major API
change.</p>
</li>
<li>
<p><code class=
"varname">BUILDLINK_PKGSRCDIR.<em class=
"replaceable"><code>pkg</code></em></code> is the
location of the <em class=
"replaceable"><code>pkg</code></em> pkgsrc
directory;</p>
</li>
<li>
<p><code class=
"varname">BUILDLINK_DEPMETHOD.<em class=
"replaceable"><code>pkg</code></em></code> (not
shown above) controls whether we use <code class=
"varname">BUILD_DEPENDS</code> or <code class=
"varname">DEPENDS</code> to add the dependency on
<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
&#8220;<span class="quote">build</span>&#8221;.
By default, the full dependency is used.</p>
</li>
<li>
<p><code class=
"varname">BUILDLINK_INCDIRS.<em class=
"replaceable"><code>pkg</code></em></code> and
<code class=
"varname">BUILDLINK_LIBDIRS.<em class="replaceable">
<code>pkg</code></em></code> (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 &#8220;<span class=
"quote">include</span>&#8221; and
&#8220;<span class="quote">lib</span>&#8221;
respectively.</p>
</li>
<li>
<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 &#8220;<span class=
"quote">-I</span>&#8221; 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>
</ul>
</div>
<p>The following variables are all optionally defined
within this second section (protected against multiple
inclusion) and control which package files are
symlinked into <code class=
"filename">${BUILDLINK_DIR}</code> and how their names
are transformed during the symlinking:</p>
<div class="itemizedlist">
<ul type="disc">
<li>
<p><code class=
"varname">BUILDLINK_FILES.<em class=
"replaceable"><code>pkg</code></em></code> (not
shown above) is a shell glob pattern relative to
<code class=
"filename">${BUILDLINK_PREFIX.<em class=
"replaceable"><code>pkg</code></em>}</code> to be
symlinked into <code class=
"filename">${BUILDLINK_DIR}</code>, e.g.
<code class="filename">include/*.h</code>.</p>
</li>
<li>
<p><code class=
"varname">BUILDLINK_FILES_CMD.<em class=
"replaceable"><code>pkg</code></em></code> (not
shown above) is a shell pipeline that outputs to
stdout a list of files relative to <code class=
"filename">${BUILDLINK_PREFIX.<em class=
"replaceable"><code>pkg</code></em>}</code>. The
resulting files are to be symlinked into
<code class="filename">${BUILDLINK_DIR}</code>.
By default, this takes the <code class=
"filename">+CONTENTS</code> of a <em class=
"replaceable"><code>pkg</code></em> and filters
it through <code class=
"varname">${BUILDLINK_CONTENTS_FILTER.<em class=
"replaceable"><code>pkg</code></em>}</code>.</p>
</li>
<li>
<p><code class=
"varname">BUILDLINK_CONTENTS_FILTER.<em class=
"replaceable"><code>pkg</code></em></code> (not
shown above) is a filter command that filters
<code class="filename">+CONTENTS</code> input
into a list of files relative to <code class=
"filename">${BUILDLINK_PREFIX.<em class=
"replaceable"><code>pkg</code></em>}</code> on
stdout. By default for overwrite packages,
<code class=
"varname">BUILDLINK_CONTENTS_FILTER.<em class=
"replaceable"><code>pkg</code></em></code>
outputs the contents of the <code class=
"filename">include</code> and <code class=
"filename">lib</code> directories in the package
<code class="filename">+CONTENTS</code>, and for
pkgviews packages, it outputs any libtool
archives in <code class="filename">lib</code>
directories.</p>
</li>
<li>
<p><code class=
"varname">BUILDLINK_TRANSFORM.<em class=
"replaceable"><code>pkg</code></em></code> (not
shown above) is a list of sed arguments used to
transform the name of the source filename into a
destination filename, e.g. <span><strong class=
"command">-e
"s|/curses.h|/ncurses.h|g"</strong></span>.</p>
</li>
</ul>
</div>
<p>The last section includes any <code class=
"filename">buildlink3.mk</code> needed for <em class=
"replaceable"><code>pkg</code></em>'s library
dependencies. Including these <code class=
"filename">buildlink3.mk</code> files means that the
headers and libraries for these dependencies are also
symlinked into <code class=
"filename">${BUILDLINK_DIR}</code> whenever the
<em class="replaceable"><code>pkg</code></em>
<code class="filename">buildlink3.mk</code> file is
included.</p>
</div>
<div class="sect2" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h3 class="title"><a name="id2588354" id=
"id2588354"></a>9.2.2. Updating <code class=
"varname">BUILDLINK_DEPENDS.<em class=
"replaceable"><code>pkg</code></em></code> in
<code class="filename">buildlink3.mk</code>
files</h3>
</div>
</div>
</div>
<p>There are two situations that require increasing the
dependency listed in <code class=
"varname">BUILDLINK_DEPENDS.<em class=
"replaceable"><code>pkg</code></em></code> after a
package update:</p>
<div class="orderedlist">
<ol type="1">
<li>
<p>if the sonames (major number of the library
version) of any installed shared libraries
change;</p>
</li>
<li>
<p>if the API or interface to the header files
change.</p>
</li>
</ol>
</div>
<p>In these cases, <code class=
"varname">BUILDLINK_DEPENDS.<em class=
"replaceable"><code>pkg</code></em></code> should be
adjusted to require at least the new package version.
In some cases, the packages that depend on this new
version may need their <code class=
"varname">PKGREVISION</code>s increased and, if they
have <code class="filename">buildlink3.mk</code> files,
their <code class=
"varname">BUILDLINK_DEPENDS.<em class="replaceable"><code>
pkg</code></em></code> adjusted, too. This is needed so
that binary packages made using it will require the
correct package dependency and not settle for an older
one which will not contain the necessary shared
libraries.</p>
<p>Please take careful consideration before adjusting
<code class="varname">BUILDLINK_DEPENDS.<em class=
"replaceable"><code>pkg</code></em></code> as we don't
want to cause unneeded package deletions and rebuilds.
In many cases, new versions of packages work just fine
with older dependencies. See <a href="#dependencies"
title="12.1.3.&nbsp;Handling dependencies">Section
12.1.3, &#8220;Handling dependencies&#8221;</a> and
<a href="#buildlink" title=
"Chapter&nbsp;9.&nbsp;Buildlink methodology">Chapter 9,
<i>Buildlink methodology</i></a> for more information
about dependencies on other packages, including the
<code class="varname">BUILDLINK_RECOMMENDED</code> and
<code class="varname">RECOMMENDED</code>
definitions.</p>
</div>
</div>
<div class="sect1" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h2 class="title" style="clear: both"><a name=
"id2588433" id="id2588433"></a>9.3.&nbsp;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 packages
should also include a <code class=
"filename">builtin.mk</code> file that includes the
necessary checks to decide whether using the built-in
software or the pkgsrc software is appropriate.</p>
<p>The only requirements of a builtin.mk file for
<em class="replaceable"><code>pkg</code></em> are:</p>
<div class="orderedlist">
<ol type="1">
<li>
<p>It should set <code class=
"varname">USE_BUILTIN.<em class=
"replaceable"><code>pkg</code></em></code> to
either &#8220;<span class="quote">yes</span>&#8221;
or &#8220;<span class="quote">no</span>&#8221;
after it is included.</p>
</li>
<li>
<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> which is
already set before the <code class=
"filename">builtin.mk</code> file is included.</p>
</li>
<li>
<p>It should be written to allow multiple
inclusion. This is <span class=
"emphasis"><em>very</em></span> important and takes
careful attention to <code class=
"filename">Makefile</code> coding.</p>
</li>
</ol>
</div>
<div class="sect2" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h3 class="title"><a name="id2588582" id=
"id2588582"></a>9.3.1.&nbsp;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">
.if !defined(IS_BUILTIN.foo)
#
# IS_BUILTIN.foo is set to "yes" or "no" depending on whether "foo"
# genuinely exists in the system or not.
#
IS_BUILTIN.foo?= no
# BUILTIN_PKG.foo should be set here if "foo" is built-in and its package
# version can be determined.
#
. if !empty(IS_BUILTIN.foo:M[yY][eE][sS])
BUILTIN_PKG.foo?= foo-1.0
. endif
.endif # IS_BUILTIN.foo
.if !defined(USE_BUILTIN.foo)
USE_BUILTIN.foo?= ${IS_BUILTIN.foo}
. if defined(BUILTIN_PKG.foo)
. for _depend_ in ${BUILDLINK_DEPENDS.foo}
. if !empty(USE_BUILTIN.foo:M[yY][eE][sS])
USE_BUILTIN.foo!= \
if ${PKG_ADMIN} pmatch '${_depend_}' ${BUILTIN_PKG.foo}; then \
${ECHO} "yes"; \
else \
${ECHO} "no"; \
fi
. endif
. endfor
. endif
.endif # USE_BUILTIN.foo
CHECK_BUILTIN.foo?= no
.if !empty(CHECK_BUILTIN.foo:M[nN][oO])
#
# Here we place code that depends on whether USE_BUILTIN.foo is set to
# "yes" or "no".
#
.endif # CHECK_BUILTIN.foo
</pre>
<p>The first section sets <code class=
"varname">IS_BUILTIN.<em class=
"replaceable"><code>pkg</code></em></code> 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 &#8220;<span class=
"quote">yes</span>&#8221; 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>
<p>The second section sets <code class=
"varname">BUILTIN_PKG.<em class=
"replaceable"><code>pkg</code></em></code> 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
&#8220;<span class="quote">yes</span>&#8221;). 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> and is
<span class="emphasis"><em>required</em></span> in all
<code class="filename">builtin.mk</code> files. The
code in this section must make the determination
whether the built-in software is adequate to satisfy
the dependencies listed in <code class=
"varname">BUILDLINK_DEPENDS.<em class=
"replaceable"><code>pkg</code></em></code>. This is
typically done by comparing <code class=
"varname">BUILTIN_PKG.<em class=
"replaceable"><code>pkg</code></em></code> against each
of the dependencies in <code class=
"varname">BUILDLINK_DEPENDS.<em class=
"replaceable"><code>pkg</code></em></code>.
<code class="varname">USE_BUILTIN.<em class=
"replaceable"><code>pkg</code></em></code> <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
&#8220;<span class="quote">yes</span>&#8221; even if
<code class="varname">IS_BUILTIN.<em class=
"replaceable"><code>pkg</code></em></code> is
&#8220;<span class="quote">no</span>&#8221; 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 <code class=
"varname">CHECK_BUILTIN.<em class=
"replaceable"><code>pkg</code></em></code>, and
includes code that uses the value of <code class=
"varname">USE_BUILTIN.<em class=
"replaceable"><code>pkg</code></em></code> set in the
previous section. This typically includes, e.g., adding
additional dependency restrictions and listing
additional files to symlink into <code class=
"filename">${BUILDLINK_DIR}</code> (via <code class=
"varname">BUILDLINK_FILES.<em class=
"replaceable"><code>pkg</code></em></code>).</p>
</div>
<div class="sect2" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h3 class="title"><a name="id2588877" id=
"id2588877"></a>9.3.2.&nbsp;Global preferences
for native or pkgsrc software</h3>
</div>
</div>
</div>
<p>When building packages, it's possible to choose
whether to set a global preference for using either the
built-in (native) version or the pkgsrc version of
software to satisfy a dependency. This is controlled by
setting <code class="varname">PREFER_PKGSRC</code> and
<code class="varname">PREFER_NATIVE</code>. These
variables take values of either &#8220;<span class=
"quote">yes</span>&#8221;, &#8220;<span class=
"quote">no</span>&#8221;, or a list of packages.
<code class="varname">PREFER_PKGSRC</code> tells pkgsrc
to use the pkgsrc versions of software, while
<code class="varname">PREFER_NATIVE</code> tells pkgsrc
to use the built-in versions. Preferences are
determined by the most specific instance of the package
in either <code class="varname">PREFER_PKGSRC</code> or
<code class="varname">PREFER_NATIVE</code>. If a
package is specified in neither or in both variables,
then <code class="varname">PREFER_PKGSRC</code> has
precedence over <code class=
"varname">PREFER_NATIVE</code>. For example, to require
using pkgsrc versions of software for all but the most
basic bits on a NetBSD system, you can set:</p>
<pre class="programlisting">
PREFER_PKGSRC= yes
PREFER_NATIVE= getopt skey tcp_wrappers
</pre>
<p>A package <span class=
"emphasis"><em>must</em></span> have a <code class=
"filename">builtin.mk</code> file to be listed in
<code class="varname">PREFER_NATIVE</code>, otherwise
it is simply ignored in that list.</p>
</div>
</div>
</div>
<div class="chapter" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h2 class="title"><a name="options" id=
"options"></a>Chapter&nbsp;10.&nbsp;Options
handling</h2>
</div>
</div>
</div>
<div class="toc">
<p><b>Table of Contents</b></p>
<dl>
<dt><span class="sect1"><a href="#id2588950">10.1.
Global default options</a></span></dt>
<dt><span class="sect1"><a href="#id2588965">10.2.
Converting packages to use <code class=
"filename">bsd.options.mk</code></a></span></dt>
</dl>
</div>
<p>Many packages have the ability to be built to support
different sets of features. <code class=
"filename">bsd.options.mk</code> is a framework in pkgsrc
that provides generic handling of those options that
determine different ways in which the packages can be
built. It's possible for the user to specify exactly which
sets of options will be built into a package or to allow a
set of global default options apply.</p>
<div class="sect1" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h2 class="title" style="clear: both"><a name=
"id2588950" id="id2588950"></a>10.1.&nbsp;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. This variable should be set in
<code class="filename">/etc/mk.conf</code>.</p>
</div>
<div class="sect1" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h2 class="title" style="clear: both"><a name=
"id2588965" id=
"id2588965"></a>10.2.&nbsp;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 use in a
package <code class="filename">Makefile</code>, or in a
file, e.g. <code class="filename">options.mk</code>, that
is included by the main package <code class=
"filename">Makefile</code>.</p>
<pre class="programlisting">
# Global and legacy options
.if defined(WIBBLE_USE_OPENLDAP) &amp;&amp; !empty(WIBBLE_USE_OPENLDAP:M[yY][eE][sS])
PKG_DEFAULT_OPTIONS+= ldap
.endif
.if defined(USE_SASL2) &amp;&amp; !empty(USE_SASL2:M[yY][eE][sS])
PKG_DEFAULT_OPTIONS+= sasl
.endif
PKG_OPTIONS_VAR= PKG_OPTIONS.wibble
PKG_SUPPORTED_OPTIONS= ldap sasl
#
# Default options for "wibble" package.
#
.if !defined(PKG_OPTIONS.wibble)
PKG_DEFAULT_OPTIONS+= sasl
endif
.include "../../mk/bsd.options.mk"
# Package-specific option-handling
###
### LDAP support
###
.if !empty(PKG_OPTIONS:Mldap)
. include "../../databases/openldap/buildlink3.mk"
CONFIGURE_ARGS+= --enable-ldap=${BUILDLINK_PREFIX.openldap}
.endif
###
### SASL authentication
###
.if !empty(PKG_OPTIONS:Msasl)
. include "../../security/cyrus-sasl2/buildlink3.mk"
CONFIGURE_ARGS+= --enable-sasl=${BUILDLINK_PREFIX.sasl}
.endif
</pre>
<p>The first section only exists if you are converting a
package that had its own ad-hoc options handling to use
<code class="filename">bsd.options.mk</code>. It converts
global or legacy options variables into an equivalent
<code class="varname">PKG_OPTIONS.<em class=
"replaceable"><code>pkg</code></em></code> value. These
sections will be removed over time as the old options are
in turn deprecated and removed.</p>
<p>The second section contains the information about
which build options are supported by the package, and any
default options settings if needed.</p>
<div class="orderedlist">
<ol type="1">
<li>
<p><code class="varname">PKG_OPTIONS_VAR</code> is
a list of the name of the <a href=
"http://netbsd.gw.com/cgi-bin/man-cgi?make+1+NetBSD-current">
<span class="citerefentry"><span class=
"refentrytitle">make</span>(1)</span></a> variables
that contain the options the user wishes to select.
The recommended value is &#8220;<span class=
"quote">PKG_OPTIONS.<em class=
"replaceable"><code>pkg</code></em></span>&#8221;
but any package-specific value may be used. This
variable should be set in a package Makefile.</p>
</li>
<li>
<p><code class=
"varname">PKG_SUPPORTED_OPTIONS</code> is a list of
build options supported by the package. This
variable should be set in a package Makefile.</p>
</li>
<li>
<p><code class="varname">${PKG_OPTIONS_VAR}</code>
(the variables named in <code class=
"varname">PKG_OPTIONS_VAR</code>) are variables
that list the selected build options and override
any default options given in <code class=
"varname">PKG_DEFAULT_OPTIONS</code>. If any of the
options begin with a &#8220;<span class=
"quote">-</span>&#8221;, then that option is always
removed from the selected build options, e.g.</p>
<pre class="programlisting">
PKG_DEFAULT_OPTIONS= kerberos ldap sasl
PKG_OPTIONS_VAR= WIBBLE_OPTIONS
WIBBLE_OPTIONS= ${PKG_DEFAULT_OPTIONS} -sasl
# implies PKG_OPTIONS == "kerberos ldap"
</pre>
<p>or</p>
<pre class="programlisting">
PKG_OPTIONS_VAR= WIBBLE_OPTIONS
WIBBLE_OPTIONS= kerberos -ldap ldap
# implies PKG_OPTIONS == "kerberos"
</pre>
<p>This variable should be set in <code class=
"filename">/etc/mk.conf</code>.</p>
</li>
</ol>
</div>
<p>After the inclusion of bsd.options.mk, the following
variables are set:</p>
<div class="itemizedlist">
<ul type="disc">
<li>
<p><code class="varname">PKG_OPTIONS</code>
contains the list of the selected build options,
properly filtered to remove unsupported and
duplicate options.</p>
</li>
</ul>
</div>
<p>The remaining sections contain the logic that is
specific to each option. There should be a check for
every option listed in <code class=
"varname">PKG_SUPPORTED_OPTIONS</code>, and there should
be clear documentation on what turning on the option will
do in the comments preceding each section. The correct
way to check for an option is to check whether it is
listed in <code class="varname">PKG_OPTIONS</code>.</p>
</div>
</div>
<div class="chapter" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h2 class="title"><a name="build" id=
"build"></a>Chapter&nbsp;11.&nbsp;The build
process</h2>
</div>
</div>
</div>
<div class="toc">
<p><b>Table of Contents</b></p>
<dl>
<dt><span class="sect1"><a href="#build.prefix">11.1.
Program location</a></span></dt>
<dt><span class="sect1"><a href="#id2589573">11.2. Main
targets</a></span></dt>
<dt><span class="sect1"><a href=
"#build.helpful-targets">11.3. Other helpful
targets</a></span></dt>
</dl>
</div>
<p>The basic steps for building a program are always the
same. First the program's source (<span class=
"emphasis"><em>distfile</em></span>) must be brought to the
local system and then extracted. After any patches to
compile properly on NetBSD are applied, the software can be
configured, then built (usually by compiling), and finally
the generated binaries, etc. can be put into place on the
system. These are exactly the steps performed by the NetBSD
package system, which is implemented as a series of targets
in a central Makefile, <code class=
"filename">pkgsrc/mk/bsd.pkg.mk</code>.</p>
<div class="sect1" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h2 class="title" style="clear: both"><a name=
"build.prefix" id=
"build.prefix"></a>11.1.&nbsp;Program location</h2>
</div>
</div>
</div>
<p>Before outlining the process performed by the NetBSD
package system in the next section, here's a brief
discussion on where programs are installed, and which
variables influence this.</p>
<p>The automatic variable <code class=
"varname">PREFIX</code> indicates where all files of the
final program shall be installed. It is usually set to
<code class="varname">LOCALBASE</code> (<code class=
"filename">/usr/pkg</code>), or <code class=
"varname">CROSSBASE</code> for pkgs in the
&#8220;<span class="quote">cross</span>&#8221; 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 href=
"#components.patches" title=
"7.3.&nbsp;patches/*">Section&nbsp;7.3,
&#8220;patches/*&#8221;</a> and <a href="#fixes.libtool"
title=
"12.3.1.&nbsp;Shared libraries - libtool">Section&nbsp;12.3.1,
&#8220;Shared libraries - libtool&#8221;</a> for more
details.</p>
<p>When choosing which of these variables to use, follow
the following rules:</p>
<div class="itemizedlist">
<ul type="disc">
<li>
<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 &#8220;<span class=
"quote">${PREFIX}</span>&#8221;.</p>
</li>
<li>
<p><code class="varname">LOCALBASE</code> is where
all non-X11 pkgs are installed. If you need to
construct a -I or -L argument to the compiler to
find includes and libraries installed by another
non-X11 pkg, use &#8220;<span class=
"quote">${LOCALBASE}</span>&#8221;.</p>
</li>
<li>
<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 pkg), use
&#8220;<span class=
"quote">${X11BASE}</span>&#8221;.</p>
</li>
<li>
<p>X11 based are special in that they may be
installed in either <code class=
"varname">X11BASE</code> or <code class=
"varname">LOCALBASE</code>.</p>
<p>Usually, X11 packages should be installed under
<code class="varname">LOCALBASE</code> whenever
possible. Note that you will need to set
<code class="varname">USE_X11</code> in them to
request the presence of X11 and to get the right
compilation flags.</p>
<p>Even though, there are some packages that cannot
be installed under <code class=
"varname">LOCALBASE</code>: those that come with
app-defaults files. These packages are special and
they must be placed under <code class=
"varname">X11BASE</code>. To accomplish this, set
either <code class="varname">USE_X11BASE</code> or
<code class="varname">USE_IMAKE</code> in your
package.</p>
<p>Some notes: <code class="varname">USE_X11</code>
and <code class="varname">USE_X11BASE</code> are
mutually exclusive. If you need to find includes or
libraries installed by a pkg that has <code class=
"varname">USE_IMAKE</code> or <code class=
"varname">USE_X11BASE</code> in its pkg
<code class="filename">Makefile</code>, you need to
use <span class="emphasis"><em>both</em></span>
<code class="filename">${X11BASE}</code> and
<code class="filename">${LOCALBASE}</code>. To
force installation of all X11 packages in
<code class="varname">LOCALBASE</code>, the
<a xmlns="http://www.w3.org/TR/xhtml1/transitional"
href=
"ftp://ftp.NetBSD.org/pub/NetBSD/packages/pkgsrc/pkgtools/xpkgwedge/README.html"
class="pkgname">pkgtools/xpkgwedge</a> is enabled
by default.</p>
</li>
<li>
<p><code class="varname">X11PREFIX</code> should be
used to refer to the installed location of an X11
package. <code class="varname">X11PREFIX</code>
will be set to <code class="varname">X11BASE</code>
if xpkgwedge is not installed, and to <code class=
"varname">LOCALBASE</code> if xpkgwedge is
installed.</p>
</li>
<li>
<p>If xpkgwedge is installed, it is possible to
have some packages installed in <code class=
"varname">X11BASE</code> and some in <code class=
"varname">LOCALBASE</code>. To determine the prefix
of an installed package, the <code class=
"varname">EVAL_PREFIX</code> definition can be
used. It takes pairs in the format
&#8220;<span class=
"quote">DIRNAME=&lt;package&gt;</span>&#8221;, and
the make(1) variable <code class=
"varname">DIRNAME</code> will be set to the prefix
of the installed package &lt;package&gt;, or
&#8220;<span class=
"quote">${X11PREFIX}</span>&#8221; if the package
is not installed.</p>
<p>This is best illustrated by example.</p>
<p>The following lines are taken from <code class=
"filename">pkgsrc/wm/scwm/Makefile</code>:</p>
<pre class="programlisting">
EVAL_PREFIX+= GTKDIR=gtk+
CONFIGURE_ARGS+= --with-guile-prefix=${LOCALBASE} \
--with-gtk-prefix="${GTKDIR}" \
--enable-multibyte
</pre>
<p>Specific defaults can be defined for the
packages evaluated using <code class=
"varname">EVAL_PREFIX</code>, by using a definition
of the form:</p>
<pre class="programlisting">
GTKDIR_DEFAULT= ${LOCALBASE}
</pre>
<p>where <code class="varname">GTKDIR</code>
corresponds to the first definition in the
<code class="varname">EVAL_PREFIX</code> pair.</p>
</li>
<li>
<p>Within <code class="filename">${PREFIX}</code>,
packages should install files according to hier(7),
with the exception that manual pages go into
<code class="filename">${PREFIX}/man</code>, not
<code class=
"filename">${PREFIX}/share/man</code>.</p>
</li>
</ul>
</div>
</div>
<div class="sect1" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h2 class="title" style="clear: both"><a name=
"id2589573" id="id2589573"></a>11.2.&nbsp;Main
targets</h2>
</div>
</div>
</div>
<p>The main targets used during the build process defined
in <code class="filename">bsd.pkg.mk</code> are:</p>
<div class="variablelist">
<dl>
<dt><span class="term">fetch</span></dt>
<dd>
<p>This will check if the file(s) given in the
variables <code class="varname">DISTFILES</code>
and <code class="varname">PATCHFILES</code> (as
defined in the package's Makefile) are present on
the local system in <code class=
"filename">/usr/pkgsrc/distfiles</code>. If they
are not present, an attempt will be made to fetch
them using commands of the form:</p>
<pre class="programlisting">
${FETCH_CMD} ${FETCH_BEFORE_ARGS} ${site}${file} ${FETCH_AFTER_ARGS}
</pre>
<p>where ${site} varies through several
possibilities in turn: first, <code class=
"varname">MASTER_SITE_OVERRIDE</code> is tried,
then the sites specified in either <code class=
"varname">SITES_file</code> if defined, else
<code class="varname">MASTER_SITES</code> or
<code class="varname">PATCH_SITES</code>, as
applies, then finally the value of <code class=
"varname">MASTER_SITE_BACKUP</code>. The order of
all except the first can be optionally sorted by
the user, via setting either <code class=
"varname">MASTER_SORT_AWK</code> or <code class=
"varname">MASTER_SORT_REGEX</code>.</p>
</dd>
<dt><span class="term">checksum</span></dt>
<dd>
<p>After the distfile(s) are fetched, their
checksum is generated and compared with the
checksums stored in the distinfo file. If the
checksums don't match, the build is aborted. This
is to ensure the same distfile is used for
building, and that the distfile wasn't changed,
e.g. by some malign force, deliberately changed
distfiles on the master distribution site or
network lossage.</p>
</dd>
<dt><span class="term">extract</span></dt>
<dd>
<p>When the distfiles are present on the local
system, they need to be extracted, as they are
usually in the form of some compressed archive
format, most commonly <code class=
"filename">.tar.gz</code>.</p>
<p>If only some of the distfiles need to be
uncompressed, the files to be uncompressed should
be put into <code class=
"varname">EXTRACT_ONLY</code>.</p>
<p>If the distfiles are not in <code class=
"filename">.tar.gz</code> format, they can be
extracted by setting either <code class=
"varname">EXTRACT_SUFX</code>, or <code class=
"varname">EXTRACT_CMD</code>, <code class=
"varname">EXTRACT_BEFORE_ARGS</code> and
<code class="varname">EXTRACT_AFTER_ARGS</code>. In
the former case, pkgsrc knows how to extract a
number of suffixes (<code class=
"filename">.tar.gz</code>, <code class=
"filename">.tgz</code>, <code class=
"filename">.tar.gz2</code>, <code class=
"filename">.tbz</code>, <code class=
"filename">.tar.Z</code>, <code class=
"filename">.tar</code>, <code class=
"filename">.shar.gz</code>, <code class=
"filename">.shar.bz2</code>, <code class=
"filename">.shar.Z</code>, <code class=
"filename">.shar</code>, <code class=
"filename">.Z</code>, <code class=
"filename">.bz2</code> and <code class=
"filename">.gz</code>; see the definition of the
various <code class="varname">DECOMPRESS_CMD</code>
variables <code class="filename">bsd.pkg.mk</code>
for a complete list). Here's an example on how to
use the other variables for a program that comes
with a compressed shell archive whose name ends in
<code class="filename">.msg.gz</code>:</p>
<pre class="programlisting">
EXTRACT_SUFX= .msg.gz
EXTRACT_CMD= zcat
EXTRACT_BEFORE_ARGS=
EXTRACT_AFTER_ARGS= |sh
</pre>
</dd>
<dt><span class="term">patch</span></dt>
<dd>
<p>After extraction, all the patches named by the
<code class="varname">PATCHFILES</code>, those
present in the patches subdirectory of the package
as well as in $LOCALPATCHES/$PKGPATH (e.g.
<code class=
"filename">/usr/local/patches/graphics/png</code>)
are applied. Patchfiles ending in <code class=
"filename">.Z</code> or <code class=
"filename">.gz</code> are uncompressed before they
are applied, files ending in <code class=
"filename">.orig</code> or <code class=
"filename">.rej</code> are ignored. Any special
options to patch(1) can be handed in <code class=
"varname">PATCH_DIST_ARGS</code>. See <a href=
"#components.patches" title=
"7.3.&nbsp;patches/*">Section&nbsp;7.3,
&#8220;patches/*&#8221;</a> for more details.</p>
<p>By default patch(1) is given special args to
make it fail if the patches apply with some lines
of fuzz. Please fix (regen) the patches so that
they apply cleanly. The rationale behind this is
that patches that don't apply cleanly may end up
being applied in the wrong place, and cause severe
harm there.</p>
</dd>
<dt><span class="term">configure</span></dt>
<dd>
<p>Most pieces of software need information on the
header files, system calls, and library routines
which are available in NetBSD. This is the process
known as configuration, and is usually automated.
In most cases, a script is supplied with the
source, and its invocation results in generation of
header files, Makefiles, etc.</p>
<p>If the program's distfile contains its own
configure script, this can be invoked by setting
<code class="varname">HAS_CONFIGURE</code>. If the
configure script is a GNU autoconf script,
<code class="varname">GNU_CONFIGURE</code> should
be specified instead. In either case, any arguments
to the configure script can be specified in the
<code class="varname">CONFIGURE_ARGS</code>
variable, and the configure script's name can be
set in <code class=
"varname">CONFIGURE_SCRIPT</code> if it differs
from the default &#8220;<span class=
"quote">configure</span>&#8221;. Here's an example
from the <a xmlns=
"http://www.w3.org/TR/xhtml1/transitional" href=
"ftp://ftp.NetBSD.org/pub/NetBSD/packages/pkgsrc/sysutils/top/README.html"
class="pkgname">sysutils/top</a> package:</p>
<pre class="programlisting">
HAS_CONFIGURE= yes
CONFIGURE_SCRIPT= Configure
CONFIGURE_ARGS+= netbsd13
</pre>
<p>If the program uses an Imakefile for
configuration, the appropriate steps can be invoked
by setting <code class="varname">USE_IMAKE</code>
to &#8220;<span class="quote">YES</span>&#8221;.
(If you only want the package installed in
<code class="varname">$X11PREFIX</code> but xmkmf
not being run, set <code class=
"varname">USE_X11BASE</code> instead!)</p>
</dd>
<dt><span class="term">build</span></dt>
<dd>
<p>Once configuration has taken place, the software
will be built by invoking <code class=
"varname">$MAKE_PROGRAM</code> on <code class=
"varname">$MAKEFILE</code> with <code class=
"varname">$BUILD_TARGET</code> as the target to
build. The default <code class=
"varname">MAKE_PROGRAM</code> is
&#8220;<span class="quote">gmake</span>&#8221; if
<code class="varname">USE_GNU_TOOLS</code> contains
&#8220;<span class="quote">make</span>&#8221;,
&#8220;<span class="quote">make</span>&#8221;
otherwise. <code class="varname">MAKEFILE</code> is
set to &#8220;<span class=
"quote">Makefile</span>&#8221; by default, and
<code class="varname">BUILD_TARGET</code> defaults
to &#8220;<span class="quote">all</span>&#8221;.
Any of these variables can be set in the package's
Makefile to change the default build process.</p>
</dd>
<dt><span class="term">install</span></dt>
<dd>
<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. As in the build-target, <code class=
"varname">$MAKE_PROGRAM</code> is invoked on
<code class="varname">$MAKEFILE</code> here, but
with the <code class=
"varname">$INSTALL_TARGET</code> instead, the
latter defaulting to &#8220;<span class=
"quote">install</span>&#8221; (plus
&#8220;<span class=
"quote">install.man</span>&#8221;, if <code class=
"varname">USE_IMAKE</code> is set).</p>
</dd>
</dl>
</div>
<p>If no target is specified, the default is
&#8220;<span class="quote">build</span>&#8221;. If a
subsequent stage is requested, all prior stages are made:
e.g. <span><strong class="command">make
build</strong></span> will also perform the equivalent
of:</p>
<pre class="programlisting">
make fetch
make checksum
make extract
make patch
make configure
make build
</pre>
</div>
<div class="sect1" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h2 class="title" style="clear: both"><a name=
"build.helpful-targets" id=
"build.helpful-targets"></a>11.3.&nbsp;Other
helpful targets</h2>
</div>
</div>
</div>
<div class="variablelist">
<dl>
<dt><span class="term">pre/post-*</span></dt>
<dd>
<p>For any of the main targets described in the
previous section, two auxiliary targets exist with
&#8220;<span class="quote">pre-</span>&#8221; and
&#8220;<span class="quote">post-</span>&#8221; used
as a prefix for the main target's name. These
targets are invoked before and after the main
target is called, allowing extra configuration or
installation steps be performed from a package's
Makefile, for example, which a program's configure
script or install target omitted.</p>
</dd>
<dt><span class="term">do-*</span></dt>
<dd>
<p>Should one of the main targets do the wrong
thing, and should there be no variable to fix this,
you can redefine it with the do-* target. (Note
that redefining the target itself instead of the
do-* target is a bad idea, as the pre-* and post-*
targets won't be called anymore, etc.) You will not
usually need to do this.</p>
</dd>
<dt><span class="term">reinstall</span></dt>
<dd>
<p>If you did a <span><strong class="command">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 &#8220;<span class="quote">already
installed</span>&#8221; flag.</p>
</dd>
<dt><span class="term">deinstall</span></dt>
<dd>
<p>This target does a pkg_delete(1) in the current
directory, effectively de-installing the package.
The following variables can be used to tune the
behaviour:</p>
<div class="variablelist">
<dl>
<dt><span class="term"><code class=
"varname">PKG_VERBOSE</code></span></dt>
<dd>
<p>Add a "-v" to the <a href=
"http://netbsd.gw.com/cgi-bin/man-cgi?pkg_delete+1+NetBSD-current">
<span class="citerefentry"><span class=
"refentrytitle">pkg_delete</span>(1)</span></a>
command.</p>
</dd>
<dt><span class="term"><code class=
"varname">DEINSTALLDEPENDS</code></span></dt>
<dd>
<p>Remove all packages that require (depend
on) the given package. This can be used to
remove any packages that may have been pulled
in by a given package, e.g. if
<span><strong class="command">make deinstall
DEINSTALLDEPENDS=1</strong></span> is done in
<code class="filename">pkgsrc/x11/kde</code>,
this is likely to remove whole KDE. Works by
adding &#8220;<span class=
"quote">-R</span>&#8221; to the <a href=
"http://netbsd.gw.com/cgi-bin/man-cgi?pkg_delete+1+NetBSD-current">
<span class="citerefentry"><span class=
"refentrytitle">pkg_delete</span>(1)</span></a>
command line.</p>
</dd>
</dl>
</div>
</dd>
<dt><span class="term">update</span></dt>
<dd>
<p>This target causes the current package to be
updated to the latest version. The package and all
depending packages first get de-installed, then
current versions of the corresponding packages get
compiled and installed. This is similar to manually
noting which packages are currently installed, then
performing a series of <span><strong class=
"command">make deinstall</strong></span> and
<span><strong class="command">make
install</strong></span> (or whatever <code class=
"varname">UPDATE_TARGET</code> is set to) for these
packages.</p>
<p>You can use the &#8220;<span class=
"quote">update</span>&#8221; target to resume
package updating in case a previous
<span><strong class="command">make
update</strong></span> was interrupted for some
reason. However, in this case, make sure you don't
call <span><strong class="command">make
clean</strong></span> or otherwise remove the list
of dependent packages in <code class=
"varname">WRKDIR</code>. Otherwise you lose the
ability to automatically update the current package
along with the dependent packages you have
installed.</p>
<p>Resuming an interrupted <span><strong class=
"command">make update</strong></span> will only
work as long as the package tree remains unchanged.
If the source code for one of the packages to be
updated has been changed, resuming
<span><strong class="command">make
update</strong></span> will most certainly
fail!</p>
<p>The following variables can be used either on
the command line or in <code class=
"filename">/etc/mk.conf</code> to alter the
behaviour of <span><strong class="command">make
update</strong></span>:</p>
<div class="variablelist">
<dl>
<dt><span class="term"><code class=
"varname">UPDATE_TARGET</code></span></dt>
<dd>
<p>Install target to recursively use for the
updated package and the dependent packages.
Defaults to <code class=
"varname">DEPENDS_TARGET</code> if set,
&#8220;<span class=
"quote">install</span>&#8221; otherwise for
<span><strong class="command">make
update</strong></span>. e.g.
<span><strong class="command">make update
UPDATE_TARGET=package</strong></span></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
&#8220;<span class=
"quote">clean-update</span>&#8221; target
below) or you may run into troubles with old
source code still lying around on your next
<span><strong class=
"command">make</strong></span> or
<span><strong class="command">make
update</strong></span>.</p>
</dd>
<dt><span class="term"><code class=
"varname">REINSTALL</code></span></dt>
<dd>
<p>Deinstall each package before installing
(making <code class=
"varname">DEPENDS_TARGET</code>). This may be
necessary if the &#8220;<span class=
"quote">clean-update</span>&#8221; target
(see below) was called after interrupting a
running <span><strong class="command">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 &#8220;<span class=
"quote">update</span>&#8221; for the update
target, facilitating a recursive update of
prerequisite packages. Only set <code class=
"varname">DEPENDS_TARGET</code> if you want
to disable recursive updates. Use
<code class="varname">UPDATE_TARGET</code>
instead to just set a specific target for
each package to be installed during
<span><strong class="command">make
update</strong></span> (see above).</p>
</dd>
</dl>
</div>
</dd>
<dt><span class="term">clean-update</span></dt>
<dd>
<p>Clean the source tree for all packages that
would get updated if <span><strong class=
"command">make update</strong></span> was called
from the current directory. This target should not
be used if the current package (or any of its
depending packages) have already been de-installed
(e.g., after calling <span><strong class=
"command">make update</strong></span>) or you may
lose some packages you intended to update. As a
rule of thumb: only use this target <span class=
"emphasis"><em>before</em></span> the first time
you run <span><strong class="command">make
update</strong></span> and only if you have a dirty
package tree (e.g., if you used <code class=
"varname">NOCLEAN</code>).</p>
<p>If you unsure about whether your tree is clean
you can either perform a <span><strong class=
"command">make clean</strong></span> at the top of
the tree, or use the following sequence of commands
from the directory of the package you want to
update (<span class=
"emphasis"><em>before</em></span> running
<span><strong class="command">make
update</strong></span> for the first time,
otherwise you lose all the packages you wanted to
update!):</p>
<pre class="screen">
<code class="prompt">#</code> <strong class=
"userinput"><code>make clean-update</code></strong>
<code class="prompt">#</code> <strong class=
"userinput"><code>make clean CLEANDEPENDS=YES</code></strong>
<code class="prompt">#</code> <strong class=
"userinput"><code>make update</code></strong>
</pre>
<p>The following variables can be used either on
the command line or in <code class=
"filename">/etc/mk.conf</code> to alter the
behaviour of <span><strong class="command">make
clean-update</strong></span>:</p>
<div class="variablelist">
<dl>
<dt><span class="term"><code class=
"varname">CLEAR_DIRLIST</code></span></dt>
<dd>
<p>After <span><strong class="command">make
clean</strong></span>, do not reconstruct the
list of directories to update for this
package. Only use this if
<span><strong class="command">make
update</strong></span> successfully installed
all packages you wanted to update. Normally,
this is done automatically on
<span><strong class="command">make
update</strong></span>, but may have been
suppressed by the <code class=
"varname">NOCLEAN</code> variable (see
above).</p>
</dd>
</dl>
</div>
</dd>
<dt><span class="term">info</span></dt>
<dd>
<p>This target invokes <a href=
"http://netbsd.gw.com/cgi-bin/man-cgi?pkg_info+1+NetBSD-current">
<span class="citerefentry"><span class=
"refentrytitle">pkg_info</span>(1)</span></a> for
the current package. You can use this to check
which version of a package is installed.</p>
</dd>
<dt><span class="term">readme</span></dt>
<dd>
<p>This target generates a <code class=
"filename">README.html</code> file, which can be
viewed using a browser such as <a xmlns=
"http://www.w3.org/TR/xhtml1/transitional" href=
"ftp://ftp.NetBSD.org/pub/NetBSD/packages/pkgsrc/www/mozilla/README.html"
class="pkgname">www/mozilla</a> or <a xmlns=
"http://www.w3.org/TR/xhtml1/transitional" href=
"ftp://ftp.NetBSD.org/pub/NetBSD/packages/pkgsrc/www/links/README.html"
class="pkgname">www/links</a>. The generated files
contain references to any packages which are in the
<code class="varname">PACKAGES</code> directory on
the local host. The generated files can be made to
refer to URLs based on <code class=
"varname">FTP_PKG_URL_HOST</code> and <code class=
"varname">FTP_PKG_URL_DIR</code>. For example, if I
wanted to generate <code class=
"filename">README.html</code> files which pointed
to binary packages on the local machine, in the
directory <code class=
"filename">/usr/packages</code>, set <code class=
"varname">FTP_PKG_URL_HOST=file://localhost</code>
and <code class=
"varname">FTP_PKG_URL_DIR=/usr/packages</code>. The
<code class="varname">${PACKAGES}</code> directory
and its subdirectories will be searched for all the
binary packages.</p>
</dd>
<dt><span class="term">readme-all</span></dt>
<dd>
<p>Use this target to create a file <code class=
"filename">README-all.html</code> which contains a
list of all packages currently available in the
NetBSD Packages Collection, together with the
category they belong to and a short description.
This file is compiled from the <code class=
"filename">pkgsrc/*/README.html</code> files, so be
sure to run this <span class=
"emphasis"><em>after</em></span> a
<span><strong class="command">make
readme</strong></span>.</p>
</dd>
<dt><span class="term">cdrom-readme</span></dt>
<dd>
<p>This is very much the same as the
&#8220;<span class="quote">readme</span>&#8221;
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">README.html</code> files, and can be
made to refer to URLs based on <code class=
"varname">CDROM_PKG_URL_HOST</code> and
<code class="varname">CDROM_PKG_URL_DIR</code>.</p>
</dd>
<dt><span class="term">show-distfiles</span></dt>
<dd>
<p>This target shows which distfiles and patchfiles
are needed to build the package. (<code class=
"varname">DISTFILES</code> and <code class=
"varname">PATCHFILES</code>, but not <code class=
"filename">patches/*</code>)</p>
</dd>
<dt><span class="term">show-downlevel</span></dt>
<dd>
<p>This target shows nothing if the package is not
installed. If a version of this package is
installed, but is not the version provided in this
version of pkgsrc, then a warning message is
displayed. This target can be used to show which of
your installed packages are downlevel, and so the
old versions can be deleted, and the current ones
added.</p>
</dd>
<dt><span class="term">show-pkgsrc-dir</span></dt>
<dd>
<p>This target shows the directory in the pkgsrc
hierarchy from which the package can be built and
installed. This may not be the same directory as
the one from which the package was installed. This
target is intended to be used by people who may
wish to upgrade many packages on a single host, and
can be invoked from the top-level pkgsrc Makefile
by using the &#8220;<span class=
"quote">show-host-specific-pkgs</span>&#8221;
target.</p>
</dd>
<dt><span class=
"term">show-installed-depends</span></dt>
<dd>
<p>This target shows which installed packages match
the current package's <code class=
"varname">DEPENDS</code>. Useful if out of date
dependencies are causing build problems.</p>
</dd>
<dt><span class="term">check-shlibs</span></dt>
<dd>
<p>After a package is installed, check all its
binaries and (on ELF platforms) shared libraries to
see if they find the shared libs they need. Run by
default if <code class=
"varname">PKG_DEVELOPER</code> is set in
<code class="filename">/etc/mk.conf</code>.</p>
</dd>
<dt><span class="term">print-PLIST</span></dt>
<dd>
<p>After a &#8220;<span class="quote">make
install</span>&#8221; from a new or upgraded pkg,
this prints out an attempt to generate a new
<code class="filename">PLIST</code> from a
<span><strong class="command">find -newer
work/.extract_done</strong></span>. An attempt is
made to care for shared libs etc., but it is
<span class="emphasis"><em>strongly</em></span>
recommended to review the result before putting it
into <code class="filename">PLIST</code>. On
upgrades, it's useful to diff the output of this
command against an already existing <code class=
"filename">PLIST</code> file.</p>
<p>If the package installs files via tar(1) 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
&#8220;<span class="quote">find
-newer</span>&#8221; command used by this target
won't catch them!</p>
<p>See <a href="#print-PLIST" title=
"8.3.&nbsp;Tweaking output of make print-PLIST">Section&nbsp;8.3,
&#8220;Tweaking output of <span><strong class=
"command">make
print-PLIST</strong></span>&#8221;</a> for more
information on this target.</p>
</dd>
<dt><span class="term">bulk-package</span></dt>
<dd>
<p>Used to do bulk builds. If an appropriate binary
package already exists, no action is taken. If not,
this target will compile, install and package it
(and it's depends, if <code class=
"varname">PKG_DEPENDS</code> is set properly. See
<a href="#binary.configuration" title=
"5.3.1.&nbsp;Configuration">Section&nbsp;5.3.1,
&#8220;Configuration&#8221;</a>. After creating the
binary package, the sources, the just-installed
package and it's required packages are removed,
preserving free disk space.</p>
<p><span class="emphasis"><em>Beware that this
target may deinstall all packages installed on a
system!</em></span></p>
</dd>
<dt><span class="term">bulk-install</span></dt>
<dd>
<p>Used during bulk-installs to install required
packages. If an upto-date binary package is
available, it will be installed via <a href=
"http://netbsd.gw.com/cgi-bin/man-cgi?pkg_add+1+NetBSD-current">
<span class="citerefentry"><span class=
"refentrytitle">pkg_add</span>(1)</span></a>. If
not, <span><strong class="command">make
bulk-package</strong></span> will be executed, but
the installed binary not be removed.</p>
<p>A binary package is considered
&#8220;<span class="quote">upto-date</span>&#8221;
to be installed via <a href=
"http://netbsd.gw.com/cgi-bin/man-cgi?pkg_add+1+NetBSD-current">
<span class="citerefentry"><span class=
"refentrytitle">pkg_add</span>(1)</span></a>
if:</p>
<div class="itemizedlist">
<ul type="disc">
<li>
<p>None of the package's files (<code class=
"filename">Makefile</code>, ...) were
modified since it was built.</p>
</li>
<li>
<p>None of the package's required (binary)
packages were modified since it was
built.</p>
</li>
</ul>
</div>
<p><span class="emphasis"><em>Beware that this
target may deinstall all packages installed on a
system!</em></span></p>
</dd>
</dl>
</div>
</div>
</div>
<div class="chapter" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h2 class="title"><a name="fixes" id=
"fixes"></a>Chapter&nbsp;12.&nbsp;Notes on fixes for
packages</h2>
</div>
</div>
</div>
<div class="toc">
<p><b>Table of Contents</b></p>
<dl>
<dt><span class="sect1"><a href="#id2590973">12.1.
General operation</a></span></dt>
<dd>
<dl>
<dt><span class="sect2"><a href=
"#id2590977">12.1.1. How to pull in variables from
/etc/mk.conf</a></span></dt>
<dt><span class="sect2"><a href=
"#id2591128">12.1.2. Restricted
packages</a></span></dt>
<dt><span class="sect2"><a href=
"#dependencies">12.1.3. Handling
dependencies</a></span></dt>
<dt><span class="sect2"><a href=
"#id2591643">12.1.4. Handling conflicts with other
packages</a></span></dt>
<dt><span class="sect2"><a href=
"#id2591762">12.1.5. Packages that cannot or should
not be built</a></span></dt>
<dt><span class="sect2"><a href=
"#id2591787">12.1.6. Packages which should not be
deleted, once installed</a></span></dt>
<dt><span class="sect2"><a href=
"#security-handling">12.1.7. Handling packages with
security problems</a></span></dt>
<dt><span class="sect2"><a href=
"#id2591879">12.1.8. How to handle compiler
bugs</a></span></dt>
<dt><span class="sect2"><a href=
"#id2591901">12.1.9. How to handle incrementing
versions when fixing an existing
package</a></span></dt>
<dt><span class="sect2"><a href=
"#id2591950">12.1.10. Portability of
packages</a></span></dt>
</dl>
</dd>
<dt><span class="sect1"><a href="#id2591975">12.2.
Possible downloading issues</a></span></dt>
<dd>
<dl>
<dt><span class="sect2"><a href=
"#id2591978">12.2.1. Packages whose distfiles
aren't available for plain
downloading</a></span></dt>
<dt><span class="sect2"><a href=
"#id2592109">12.2.2. How to handle modified
distfiles with the 'old' name</a></span></dt>
</dl>
</dd>
<dt><span class="sect1"><a href="#id2592121">12.3.
Configuration gotchas</a></span></dt>
<dd>
<dl>
<dt><span class="sect2"><a href=
"#fixes.libtool">12.3.1. Shared libraries -
libtool</a></span></dt>
<dt><span class="sect2"><a href=
"#id2592529">12.3.2. Using libtool on GNU packages
that already support libtool</a></span></dt>
<dt><span class="sect2"><a href=
"#id2592613">12.3.3. GNU
Autoconf/Automake</a></span></dt>
</dl>
</dd>
<dt><span class="sect1"><a href="#id2592726">12.4.
Building considerations</a></span></dt>
<dd>
<dl>
<dt><span class="sect2"><a href=
"#id2592729">12.4.1. CPP defines</a></span></dt>
</dl>
</dd>
<dt><span class="sect1"><a href="#id2592759">12.5.
Package specific actions</a></span></dt>
<dd>
<dl>
<dt><span class="sect2"><a href=
"#id2592762">12.5.1. Package configuration
files</a></span></dt>
<dt><span class="sect2"><a href=
"#id2592933">12.5.2. User
interaction</a></span></dt>
<dt><span class="sect2"><a href=
"#id2593046">12.5.3. Handling
licenses</a></span></dt>
<dt><span class="sect2"><a href=
"#id2593197">12.5.4. Creating an account from a
package</a></span></dt>
<dt><span class="sect2"><a href=
"#id2593328">12.5.5. Installing score
files</a></span></dt>
<dt><span class="sect2"><a href=
"#id2593371">12.5.6. Packages providing login
shells</a></span></dt>
<dt><span class="sect2"><a href=
"#id2593429">12.5.7. Packages containing perl
scripts</a></span></dt>
<dt><span class="sect2"><a href=
"#id2593447">12.5.8. Packages with hardcoded paths
to other interpreters</a></span></dt>
<dt><span class="sect2"><a href=
"#id2593468">12.5.9. Packages installing perl
modules</a></span></dt>
<dt><span class="sect2"><a href=
"#faq.info-files">12.5.10. Packages installing info
files</a></span></dt>
<dt><span class="sect2"><a href=
"#id2593688">12.5.11. Packages installing GConf2
data files</a></span></dt>
<dt><span class="sect2"><a href=
"#id2593788">12.5.12. Packages installing
scrollkeeper data files</a></span></dt>
<dt><span class="sect2"><a href=
"#id2593840">12.5.13. Packages installing X11
fonts</a></span></dt>
<dt><span class="sect2"><a href=
"#id2593886">12.5.14. Packages installing GTK2
modules</a></span></dt>
<dt><span class="sect2"><a href=
"#id2593956">12.5.15. Packages installing SGML or
XML data</a></span></dt>
<dt><span class="sect2"><a href=
"#id2594076">12.5.16. Packages installing
extensions to the MIME database</a></span></dt>
<dt><span class="sect2"><a href=
"#id2594283">12.5.17. Packages using
intltool</a></span></dt>
</dl>
</dd>
<dt><span class="sect1"><a href="#id2594297">12.6.
Feedback to the author</a></span></dt>
</dl>
</div>
<div class="sect1" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h2 class="title" style="clear: both"><a name=
"id2590973" id="id2590973"></a>12.1.&nbsp;General
operation</h2>
</div>
</div>
</div>
<div class="sect2" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h3 class="title"><a name="id2590977" id=
"id2590977"></a>12.1.1.&nbsp;How to pull in
variables from /etc/mk.conf</h3>
</div>
</div>
</div>
<p>The problem with package-defined variables that can
be overridden via <code class="varname">MAKECONF</code>
or <code class="filename">/etc/mk.conf</code> is that
<a href=
"http://netbsd.gw.com/cgi-bin/man-cgi?make+1+NetBSD-current">
<span class="citerefentry"><span class=
"refentrytitle">make</span>(1)</span></a> expands a
variable as it is used, but evaluates preprocessor like
statements (.if, .ifdef and .ifndef) as they are read.
So, to use any variable (which may be set in
<code class="filename">/etc/mk.conf</code>) in one of
the .if* statements, the file <code class=
"filename">/etc/mk.conf</code> must be included before
that .if* statement.</p>
<p>Rather than have a number of ad-hoc ways of
including <code class="filename">/etc/mk.conf</code>,
should it exist, or <code class=
"varname">MAKECONF</code>, should it exist, include the
<code class="filename">pkgsrc/mk/bsd.prefs.mk</code>
file in the package Makefile before any
preprocessor-like .if, .ifdef, or .ifndef
statements:</p>
<pre class="programlisting">
.include "../../mk/bsd.prefs.mk"
.if defined(USE_MENUS)
...
.endif
</pre>
<p>If you wish to set the <code class=
"varname">CFLAGS</code> variable in <code class=
"filename">/etc/mk.conf</code> please make sure to
use:</p>
<pre class="programlisting">
CFLAGS+= -your -flags
</pre>
<p>Using <code class="varname">CFLAGS=</code> (i.e.
without the &#8220;<span class="quote">+</span>&#8221;)
may lead to problems with packages that need to add
their own flags. Also, you may want to take a look at
the <a xmlns="http://www.w3.org/TR/xhtml1/transitional"
href=
"ftp://ftp.NetBSD.org/pub/NetBSD/packages/pkgsrc/devel/cpuflags/README.html"
class="pkgname">devel/cpuflags</a> package if you're
interested in optimization for the current CPU.</p>
</div>
<div class="sect2" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h3 class="title"><a name="id2591128" id=
"id2591128"></a>12.1.2.&nbsp;Restricted
packages</h3>
</div>
</div>
</div>
<p>Some licenses restrict how software may be
re-distributed. In order to satisfy these restrictions,
the package system defines five make variables that can
be set to note these restrictions:</p>
<div class="itemizedlist">
<ul type="disc">
<li>
<p><code class="varname">RESTRICTED</code></p>
<p>This variable should be set whenever a
restriction exists (regardless of its kind). Set
this variable to a string containing the reason
for the restriction.</p>
</li>
<li>
<p><code class=
"varname">NO_BIN_ON_CDROM</code></p>
<p>Binaries may not be placed on CD-ROM. Set this
variable to <code class=
"varname">${RESTRICTED}</code> whenever a binary
package may not be included on a CD-ROM.</p>
</li>
<li>
<p><code class="varname">NO_BIN_ON_FTP</code></p>
<p>Binaries may not be placed on an FTP server.
Set this variable to <code class=
"varname">${RESTRICTED}</code> whenever a binary
package may not not be made available on the
Internet.</p>
</li>
<li>
<p><code class=
"varname">NO_SRC_ON_CDROM</code></p>
<p>Distfiles may not be placed on CD-ROM. Set
this variable to <code class=
"varname">${RESTRICTED}</code> if re-distribution
of the source code or other distfile(s) is not
allowed on CD-ROMs.</p>
</li>
<li>
<p><code class="varname">NO_SRC_ON_FTP</code></p>
<p>Distfiles may not be placed on FTP. Set this
variable to <code class=
"varname">${RESTRICTED}</code> if re-distribution
of the source code or other distfile(s) via the
Internet is not allowed.</p>
</li>
</ul>
</div>
<p>Please note that the use of <code class=
"varname">NO_PACKAGE</code>, <code class=
"varname">IGNORE</code>, <code class=
"varname">NO_CDROM</code>, or other generic make
variables to denote restrictions is deprecated, because
they unconditionally prevent users from generating
binary packages!</p>
</div>
<div class="sect2" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h3 class="title"><a name="dependencies" id=
"dependencies"></a>12.1.3.&nbsp;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">BUILD_DEPENDS</code> and <code class=
"varname">DEPENDS</code> definitions, 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 href="#buildlink" title=
"Chapter&nbsp;9.&nbsp;Buildlink methodology">Chapter&nbsp;9,
<i>Buildlink methodology</i></a> for more
information.</p>
<p>The basic difference between the two variables is as
follows: 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> definition does not,
marking a dependency that is only needed for building
the package.</p>
<p>This means that if you only need a package present
whilst you are building, it should be noted as a
<code class="varname">BUILD_DEPENDS</code>.</p>
<p>The format for a <code class=
"varname">BUILD_DEPENDS</code> and a <code class=
"varname">DEPENDS</code> definition is:</p>
<pre class="programlisting">
&lt;pre-req-package-name&gt;:../../&lt;category&gt;/&lt;pre-req-package&gt;
</pre>
<p>Please note that the &#8220;<span class=
"quote">pre-req-package-name</span>&#8221; may include
any of the wildcard version numbers recognised by
<a href=
"http://netbsd.gw.com/cgi-bin/man-cgi?pkg_info+1+NetBSD-current">
<span class="citerefentry"><span class=
"refentrytitle">pkg_info</span>(1)</span></a>.</p>
<div class="orderedlist">
<ol type="1">
<li>
<p>If your package needs another package's
binaries or libraries to build or run, and if
that package has a <code class=
"filename">buildlink3.mk</code> file available,
use it:</p>
<pre class="programlisting">
.include "../../graphics/jpeg/buildlink3.mk"
</pre>
</li>
<li>
<p>If your package needs to use another package
to build itself and there is no <code class=
"filename">buildlink3.mk</code> file available,
use the <code class=
"varname">BUILD_DEPENDS</code> definition:</p>
<pre class="programlisting">
BUILD_DEPENDS+= autoconf-2.13:../../devel/autoconf
</pre>
</li>
<li>
<p>If your package needs a library with which to
link and again there is no <code class=
"filename">buildlink3.mk</code> file available,
this is specified using the <code class=
"varname">DEPENDS</code> definition. An example
of this is the <a xmlns=
"http://www.w3.org/TR/xhtml1/transitional" href=
"ftp://ftp.NetBSD.org/pub/NetBSD/packages/pkgsrc/print/lyx/README.html"
class="pkgname">print/lyx</a> package, which uses
the xpm library, version 3.4j to build:</p>
<pre class="programlisting">
DEPENDS+= xpm-3.4j:../../graphics/xpm
</pre>
<p>You can also use wildcards in package
dependences:</p>
<pre class="programlisting">
DEPENDS+= xpm-[0-9]*:../../graphics/xpm
</pre>
<p>Note that such wildcard dependencies are
retained when creating binary packages. The
dependency is checked when installing the binary
package and any package which matches the pattern
will be used. Wildcard dependencies should be
used with care.</p>
<p>The &#8220;<span class=
"quote">-[0-9]*</span>&#8221; should be used
instead of &#8220;<span class=
"quote">-*</span>&#8221; to avoid potentially
ambiguous matches such as &#8220;<span class=
"quote">tk-postgresql</span>&#8221; matching a
&#8220;<span class="quote">tk-*</span>&#8221;
<code class="varname">DEPENDS</code>.</p>
<p>Wildcards can also be used to specify that a
package will only build against a certain minimum
version of a pre-requisite:</p>
<pre class="programlisting">
DEPENDS+= tiff&gt;=3.5.4:../../graphics/tiff
</pre>
<p>This means that the package will build against
version 3.5.4 of the tiff library or newer. Such
a dependency may be warranted if, for example,
the API of the library has changed with version
3.5.4 and a package would not compile against an
earlier version of tiff.</p>
<p>Please note that such dependencies should only
be updated if a package requires a newer
pre-requisite, but not to denote recommendations
such as security updates or ABI changes that do
not prevent a package from building correctly.
Such recommendations can be expressed using
<code class="varname">RECOMMENDED</code>:</p>
<pre class="programlisting">
RECOMMENDED+= tiff&gt;=3.6.1:../../graphics/tiff
</pre>
<p>In addition to the above <code class=
"varname">DEPENDS</code> line, this denotes that
while a package will build against
tiff&gt;=3.5.4, at least version 3.6.1 is
recommended. <code class=
"varname">RECOMMENDED</code> entries will be
turned into dependencies unless explicitly
ignored (in which case a warning will be
printed). Packages that are built with
recommendations ignored may not be uploaded to
ftp.NetBSD.org by developers and should not be
used across different systems that may have
different versions of binary packages
installed.</p>
<p>For security fixes, please update the package
vulnerabilities file as well as setting
<code class="varname">RECOMMENDED</code>, see
<a href="#security-handling" title=
"12.1.7.&nbsp;Handling packages with security problems">
Section 12.1.7, &#8220;Handling packages with
security problems&#8221;</a> for more
information.</p>
</li>
<li>
<p>If your package needs some executable to be
able to run correctly and if there's agail no
<code class="filename">buildlink3.mk</code> file,
this is specified using the <code class=
"varname">DEPENDS</code> variable. The <a xmlns=
"http://www.w3.org/TR/xhtml1/transitional" href=
"ftp://ftp.NetBSD.org/pub/NetBSD/packages/pkgsrc/print/lyx/README.html"
class="pkgname">print/lyx</a> package needs to be
able to execute the latex binary from the teTeX
package when it runs, and that is specified:</p>
<pre class="programlisting">
DEPENDS+= teTeX-[0-9]*:../../print/teTeX
</pre>
<p>The comment about wildcard dependencies from
previous paragraph applies here, too.</p>
</li>
</ol>
</div>
<p>If your package needs files from another package to
build, see the first part of the &#8220;<span class=
"quote">do-configure</span>&#8221; target <a xmlns=
"http://www.w3.org/TR/xhtml1/transitional" href=
"ftp://ftp.NetBSD.org/pub/NetBSD/packages/pkgsrc/print/ghostscript5/README.html"
class="pkgname">print/ghostscript5</a> package (it
relies on the jpeg sources being present in source form
during the build):</p>
<pre class="programlisting">
if [ ! -e ${_PKGSRCDIR}/graphics/jpeg/${WRKDIR:T}/jpeg-6b ]; then \
cd ${_PKGSRCDIR}/../../graphics/jpeg &amp;&amp; ${MAKE} extract; \
fi
</pre>
<p>If you build any other packages that way, please
make sure the working files are deleted too when this
package's working files are cleaned up. The easiest way
to do so is by adding a pre-clean target:</p>
<pre class="programlisting">
pre-clean:
cd ${_PKGSRCDIR}/../../graphics/jpeg &amp;&amp; ${MAKE} clean
</pre>
<p>Please also note the <code class=
"varname">BUILD_USES_MSGFMT</code> and <code class=
"varname">BUILD_USES_GETTEXT_M4</code> definitions,
which are provided as convenience definitions. The
former works out whether msgfmt(1) is part of the base
system, and, if it isn't, installs the <a xmlns=
"http://www.w3.org/TR/xhtml1/transitional" href=
"ftp://ftp.NetBSD.org/pub/NetBSD/packages/pkgsrc/devel/gettext/README.html"
class="pkgname">devel/gettext</a> package. The latter
adds a build dependency on either an installed version
of an older gettext package, or if it isn't, installs
the <a xmlns="http://www.w3.org/TR/xhtml1/transitional"
href=
"ftp://ftp.NetBSD.org/pub/NetBSD/packages/pkgsrc/devel/gettext-m4/README.html"
class="pkgname">devel/gettext-m4</a> package.</p>
</div>
<div class="sect2" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h3 class="title"><a name="id2591643" id=
"id2591643"></a>12.1.4.&nbsp;Handling conflicts
with other packages</h3>
</div>
</div>
</div>
<p>Your package may conflict with other packages a user
might already have installed on his system, e.g. if
your package installs the same set of files like
another package in our pkgsrc tree.</p>
<p>In this case you can set <code class=
"varname">CONFLICTS</code> to a space separated list of
packages (including version string) your package
conflicts with.</p>
<p>For example <a xmlns=
"http://www.w3.org/TR/xhtml1/transitional" href=
"ftp://ftp.NetBSD.org/pub/NetBSD/packages/pkgsrc/x11/Xaw3d/README.html"
class="pkgname">x11/Xaw3d</a> and <a xmlns=
"http://www.w3.org/TR/xhtml1/transitional" href=
"ftp://ftp.NetBSD.org/pub/NetBSD/packages/pkgsrc/x11/Xaw-Xpm/README.html"
class="pkgname">x11/Xaw-Xpm</a> install provide the
same shared library, thus you set in <code class=
"filename">pkgsrc/x11/Xaw3d/Makefile</code>:</p>
<pre class="programlisting">
CONFLICTS= Xaw-Xpm-[0-9]*
</pre>
<p>and in <code class=
"filename">pkgsrc/x11/Xaw-Xpm/Makefile</code>:</p>
<pre class="programlisting">
CONFLICTS= Xaw3d-[0-9]*
</pre>
<p>Packages will automatically conflict with other
packages with the name prefix and a different version
string. &#8220;<span class=
"quote">Xaw3d-1.5</span>&#8221; e.g. will automatically
conflict with the older version &#8220;<span class=
"quote">Xaw3d-1.3</span>&#8221;.</p>
</div>
<div class="sect2" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h3 class="title"><a name="id2591762" id=
"id2591762"></a>12.1.5.&nbsp;Packages that cannot
or should not be built</h3>
</div>
</div>
</div>
<p>There are several reasons why a package might be
instructed to not build under certain circumstances. If
the package builds and runs on most platforms, the
exceptions should be noted with <code class=
"varname">NOT_FOR_PLATFORM</code>. If the package
builds and runs on a small handful of platforms, set
<code class="varname">ONLY_FOR_PLATFORM</code> instead.
If the package should be skipped (for example, because
it provides functionality already provided by the
system), set <code class=
"varname">PKG_SKIP_REASON</code> to a descriptive
message. If the package should fail because some
preconditions are not met, set <code class=
"varname">PKG_FAIL_REASON</code> to a descriptive
message.</p>
<p><code class="varname">IGNORE</code> is deprecated
because it didn't provide enough information to
determine whether the build should fail.</p>
</div>
<div class="sect2" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h3 class="title"><a name="id2591787" id=
"id2591787"></a>12.1.6.&nbsp;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
&#8220;<span class="quote">preserved</span>&#8221;
package will not be deleted using <a href=
"http://netbsd.gw.com/cgi-bin/man-cgi?pkg_delete+1+NetBSD-current">
<span class="citerefentry"><span class=
"refentrytitle">pkg_delete</span>(1)</span></a> unless
the &#8220;<span class="quote">-f</span>&#8221; option
is used.</p>
</div>
<div class="sect2" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h3 class="title"><a name="security-handling" id=
"security-handling"></a>12.1.7.&nbsp;Handling
packages with security problems</h3>
</div>
</div>
</div>
<p>When a vulnerability is found, this should be noted
in <code class=
"filename">localsrc/security/advisories/pkg-vulnerabilities</code>,
and after the commit of that file, it should be copied
to both <code class=
"filename">/pub/NetBSD/packages/distfiles/pkg-vulnerabilities</code>
and <code class=
"filename">/pub/NetBSD/packages/distfiles/vulnerabilities</code>
on ftp.NetBSD.org using <code class=
"filename">localsrc/security/advisories/Makefile</code>.
In addition, if a <code class=
"filename">buildlink3.mk</code> file exists for an
affected package, bumping <code class=
"varname">PKGREVISION</code> and creating a
corresponding <code class=
"varname">BUILDLINK_RECOMMENDED.<em class=
"replaceable"><code>pkg</code></em></code> entry should
be considered. See <a href="#buildlink" title=
"Chapter&nbsp;9.&nbsp;Buildlink methodology">Chapter&nbsp;9,
<i>Buildlink methodology</i></a> for more information
about writing <code class=
"filename">buildlink3.mk</code> files and <code class=
"varname">BUILDLINK_*</code> definitions.</p>
<p>Also, if the fix should be applied to the stable
pkgsrc branch, be sure to submit a pullup request!</p>
</div>
<div class="sect2" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h3 class="title"><a name="id2591879" id=
"id2591879"></a>12.1.8.&nbsp;How to handle
compiler bugs</h3>
</div>
</div>
</div>
<p>Some source files trigger bugs in the compiler,
based on combinations of compiler version and
architecture and almost always relation to optimisation
being enabled. Common symptoms are gcc internal errors
or never finishing compiling a file.</p>
<p>Typically a workaround involves testing the
<code class="varname">MACHINE_ARCH</code> and compiler
version, disabling optimisation for that
file/<code class="varname">MACHINE_ARCH</code>/compiler
combination, and documenting it in <code class=
"filename">pkgsrc/doc/HACKS</code>. See that file for a
number of examples!</p>
</div>
<div class="sect2" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h3 class="title"><a name="id2591901" id=
"id2591901"></a>12.1.9.&nbsp;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
&#8220;<span class="quote">nb1</span>&#8221;,
&#8220;<span class="quote">nb2</span>&#8221;, ...
suffix can be used on package versions by setting
<code class="varname">PKGREVISION=1</code> (2, ...).
The &#8220;<span class="quote">nb</span>&#8221; is
treated like a &#8220;<span class=
"quote">.</span>&#8221; by the pkg 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 &#8220;<span class=
"quote">foo-17.42nb9</span>&#8221;.</p>
<p>When a new release of the package is released, the
<code class="varname">PKGREVISION</code> should be
removed. e.g. on a new minor release of the above
package, things should be like:</p>
<pre class="programlisting">
DISTNAME= foo-17.43
</pre>
</div>
<div class="sect2" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h3 class="title"><a name="id2591950" id=
"id2591950"></a>12.1.10.&nbsp;Portability of
packages</h3>
</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. There are some particular details you should
pay attention to while working on pkgsrc.</p>
<div class="sect3" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h4 class="title"><a name="id2591956" id=
"id2591956"></a>12.1.10.1.&nbsp;${INSTALL},
${INSTALL_DATA_DIR}, ...</h4>
</div>
</div>
</div>
<p>The BSD-compatible <span><strong class=
"command">install</strong></span> supplied with some
operating systems will not perform more than one
operation at a time. As such, you should call
&#8220;<span class="quote">${INSTALL}</span>&#8221;,
etc. like this:</p>
<pre class="programlisting">
${INSTALL_DATA_DIR} ${PREFIX}/dir1
${INSTALL_DATA_DIR} ${PREFIX}/dir2
</pre>
</div>
</div>
</div>
<div class="sect1" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h2 class="title" style="clear: both"><a name=
"id2591975" id="id2591975"></a>12.2.&nbsp;Possible
downloading issues</h2>
</div>
</div>
</div>
<div class="sect2" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h3 class="title"><a name="id2591978" id=
"id2591978"></a>12.2.1.&nbsp;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><strong class="command">make
fetch</strong></span> will call <code class=
"filename">files/getsite.sh</code> with the name of
each file to download as an argument, expecting it to
output the URL of the directory from which to download
it. <a xmlns="http://www.w3.org/TR/xhtml1/transitional"
href=
"ftp://ftp.NetBSD.org/pub/NetBSD/packages/pkgsrc/graphics/ns-cult3d/README.html"
class="pkgname">graphics/ns-cult3d</a> is an example of
this usage.</p>
<p>If the download can't be automated, because the user
must submit personal information to apply for a
password, or must pay for the source, or whatever, you
can set <code class="varname">_FETCH_MESSAGE</code> to
a macro which displays a message explaining the
situation. <code class="varname">_FETCH_MESSAGE</code>
must be executable shell commands, not just a message.
(Generally, it executes <code class=
"varname">${ECHO}</code>). As of this writing, the
following packages use this: <a xmlns=
"http://www.w3.org/TR/xhtml1/transitional" href=
"ftp://ftp.NetBSD.org/pub/NetBSD/packages/pkgsrc/audio/realplayer/README.html"
class="pkgname">audio/realplayer</a>, <a xmlns=
"http://www.w3.org/TR/xhtml1/transitional" href=
"ftp://ftp.NetBSD.org/pub/NetBSD/packages/pkgsrc/cad/simian/README.html"
class="pkgname">cad/simian</a>, <a xmlns=
"http://www.w3.org/TR/xhtml1/transitional" href=
"ftp://ftp.NetBSD.org/pub/NetBSD/packages/pkgsrc/devel/ipv6socket/README.html"
class="pkgname">devel/ipv6socket</a>, <a xmlns=
"http://www.w3.org/TR/xhtml1/transitional" href=
"ftp://ftp.NetBSD.org/pub/NetBSD/packages/pkgsrc/emulators/vmware-module/README.html"
class="pkgname">emulators/vmware-module</a>, <a xmlns=
"http://www.w3.org/TR/xhtml1/transitional" href=
"ftp://ftp.NetBSD.org/pub/NetBSD/packages/pkgsrc/fonts/acroread-jpnfont/README.html"
class="pkgname">fonts/acroread-jpnfont</a>, <a xmlns=
"http://www.w3.org/TR/xhtml1/transitional" href=
"ftp://ftp.NetBSD.org/pub/NetBSD/packages/pkgsrc/sysutils/storage-manager/README.html"
class="pkgname">sysutils/storage-manager</a>, <a xmlns=
"http://www.w3.org/TR/xhtml1/transitional" href=
"ftp://ftp.NetBSD.org/pub/NetBSD/packages/pkgsrc/www/ap-aolserver/README.html"
class="pkgname">www/ap-aolserver</a>, <a xmlns=
"http://www.w3.org/TR/xhtml1/transitional" href=
"ftp://ftp.NetBSD.org/pub/NetBSD/packages/pkgsrc/www/openacs/README.html"
class="pkgname">www/openacs</a>. Try to be consistent
with them.</p>
</div>
<div class="sect2" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h3 class="title"><a name="id2592109" id=
"id2592109"></a>12.2.2.&nbsp;How to handle
modified distfiles with the 'old' name</h3>
</div>
</div>
</div>
<p>Sometimes authors of a software package make some
modifications after the software was released, and they
put up a new distfile without changing the package's
version number. If a package is already in pkgsrc at
that time, the md5 checksum will no longer match. The
correct way to work around this is to update the
package's md5 checksum to match the package on the
master site (beware, any mirrors may not be up to date
yet!), and to remove the old distfile from
ftp.NetBSD.org's <code class=
"filename">/pub/NetBSD/packages/distfiles</code>
directory. Furthermore, a mail to the package's author
seems appropriate making sure the distfile was really
updated on purpose, and that no trojan horse or so
crept in.</p>
</div>
</div>
<div class="sect1" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h2 class="title" style="clear: both"><a name=
"id2592121" id=
"id2592121"></a>12.3.&nbsp;Configuration
gotchas</h2>
</div>
</div>
</div>
<div class="sect2" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h3 class="title"><a name="fixes.libtool" id=
"fixes.libtool"></a>12.3.1.&nbsp;Shared libraries
- libtool</h3>
</div>
</div>
</div>
<p>pkgsrc supports many different machines, with
different object formats like a.out and ELF, and
varying abilities to do shared library and dynamic
loading at all. To accompany this, varying commands and
options have to be passed to the compiler, linker, etc.
to get the Right Thing, which can be pretty annoying
especially if you don't have all the machines at your
hand to test things. The <a xmlns=
"http://www.w3.org/TR/xhtml1/transitional" href=
"ftp://ftp.NetBSD.org/pub/NetBSD/packages/pkgsrc/devel/libtool/README.html"
class="pkgname">devel/libtool</a> pkg can help here, as
it just &#8220;<span class="quote">knows</span>&#8221;
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 pkg in seven simple
steps:</p>
<div class="orderedlist">
<ol type="1">
<li>
<p>Add <code class=
"varname">USE_LIBTOOL=yes</code> to the package
Makefile.</p>
</li>
<li>
<p>For library objects, use &#8220;<span class=
"quote">${LIBTOOL} --mode=compile
${CC}</span>&#8221; in place of
&#8220;<span class="quote">${CC}</span>&#8221;.
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>
<p>For the linking of the library, remove any
&#8220;<span class="quote">ar</span>&#8221;,
&#8220;<span class="quote">ranlib</span>&#8221;,
and &#8220;<span class="quote">ld
-Bshareable</span>&#8221; commands, and instead
use:</p>
<pre class="programlisting">
${LIBTOOL} --mode=link ${CC} -o ${.TARGET:.a=.la} ${OBJS:.o=.lo} -rpath ${PREFIX}/lib -version-info major:minor
</pre>
<p>Note that the library is changed to have a
<code class="filename">.la</code> extension, and
the objects are changed to have a <code class=
"filename">.lo</code> extension. Change
<code class="varname">OBJS</code> as necessary.
This automatically creates all of the
<code class="filename">.a</code>, <code class=
"filename">.so.major.minor</code>, and ELF
symlinks (if necessary) in the build directory.
Be sure to include &#8220;<span class=
"quote">-version-info</span>&#8221;, especially
when major and minor are zero, as libtool will
otherwise strip off the shared library
version.</p>
<p>From the libtool manual:</p>
<pre class="programlisting">
So, libtool library versions are described by three integers:
CURRENT
The most recent interface number that this library implements.
REVISION
The implementation number of the CURRENT interface.
AGE
The difference between the newest and oldest interfaces that this
library implements. In other words, the library implements all the
interface numbers in the range from number `CURRENT - AGE' to
`CURRENT'.
If two libraries have identical CURRENT and AGE numbers, then the
dynamic linker chooses the library with the greater REVISION number.
</pre>
<p>The &#8220;<span class=
"quote">-release</span>&#8221; option will
produce different results for a.out and ELF
(excluding symlinks) in only one case. An ELF
library of the form &#8220;<span class=
"quote">libfoo-release.so.<span class=
"emphasis"><em>x</em></span>.<span class=
"emphasis"><em>y</em></span></span>&#8221; will
have a symlink of &#8220;<span class=
"quote">libfoo.so.<span class=
"emphasis"><em>x</em></span>.<span class=
"emphasis"><em>y</em></span></span>&#8221; on an
a.out platform. This is handled
automatically.</p>
<p>The &#8220;<span class="quote">-rpath
argument</span>&#8221; is the install directory
of the library being built.</p>
<p>In the <code class="filename">PLIST</code>,
include all of the <code class=
"filename">.a</code>, <code class=
"filename">.la</code>, and <code class=
"filename">.so</code>, <code class=
"filename">.so.<em class=
"replaceable"><code>major</code></em></code> and
<code class="filename">.so.<em class=
"replaceable"><code>major</code></em>.<em class=
"replaceable"><code>minor</code></em></code>
files.</p>
</li>
<li>
<p>When linking shared object (<code class=
"filename">.so</code>) files, i.e. files that are
loaded via dlopen(3), NOT shared libraries, use
&#8220;<span class="quote">-module
-avoid-version</span>&#8221; to prevent them
getting version tacked on.</p>
<p>The <code class="filename">PLIST</code> file
gets the <code class="filename">foo.so</code>
entry.</p>
</li>
<li>
<p>When linking programs that depend on these
libraries <span class=
"emphasis"><em>before</em></span> they are
installed, preface the <a href=
"http://netbsd.gw.com/cgi-bin/man-cgi?cc+1+NetBSD-current">
<span class="citerefentry"><span class=
"refentrytitle">cc</span>(1)</span></a> or
<a href=
"http://netbsd.gw.com/cgi-bin/man-cgi?ld+1+NetBSD-current">
<span class="citerefentry"><span class=
"refentrytitle">ld</span>(1)</span></a> line with
&#8220;<span class="quote">${LIBTOOL}
--mode=link</span>&#8221;, 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
&#8220;<span class=
"quote">-L../somelib</span>&#8221;), because it
expects you to change that argument to be the
<code class="filename">.la</code> file. e.g.</p>
<pre class="programlisting">
${LIBTOOL} --mode=link ${CC} -o someprog -L../somelib -lsomelib
</pre>
<p>should be changed to:</p>
<pre class="programlisting">
${LIBTOOL} --mode=link ${CC} -o <em class=
"replaceable"><code>someprog</code></em> <em class=
"replaceable"><code>../somelib/somelib.la</code></em>
</pre>
<p>and it will do the right thing with the
libraries.</p>
</li>
<li>
<p>When installing libraries, preface the
<a href="http://netbsd.gw.com/cgi-bin/man-cgi?install+1+NetBSD-current">
<span class="citerefentry"><span class=
"refentrytitle">install</span>(1)</span></a> or
<a href=
"http://netbsd.gw.com/cgi-bin/man-cgi?cp+1+NetBSD-current">
<span class="citerefentry"><span class=
"refentrytitle">cp</span>(1)</span></a> command
with &#8220;<span class="quote">${LIBTOOL}
--mode=install</span>&#8221;, and change the
library name to <code class=
"filename">.la</code>. e.g.</p>
<pre class="programlisting">
${LIBTOOL} --mode=install ${BSD_INSTALL_DATA} ${SOMELIB:.a=.la} ${PREFIX}/lib
</pre>
<p>This will install the static <code class=
"filename">.a</code>, shared library, any needed
symlinks, and run <a href=
"http://netbsd.gw.com/cgi-bin/man-cgi?ldconfig+8+NetBSD-current">
<span class="citerefentry"><span class=
"refentrytitle">ldconfig</span>(8)</span></a>.</p>
</li>
<li>
<p>In your <code class="filename">PLIST</code>,
include all of the <code class=
"filename">.a</code>, <code class=
"filename">.la</code>, and <code class=
"filename">.so</code>, <code class=
"filename">.so.CURRENT</code> and <code class=
"filename">.so.CURRENT.REVISION</code> files
(this is a change from the previous
behaviour).</p>
</li>
</ol>
</div>
</div>
<div class="sect2" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h3 class="title"><a name="id2592529" id=
"id2592529"></a>12.3.2.&nbsp;Using libtool on GNU
packages that already support libtool</h3>
</div>
</div>
</div>
<p>Add <code class="varname">USE_LIBTOOL=yes</code> to
the package Makefile. This will override the package's
own libtool in most cases. For older libtool using
packages, libtool is made by ltconfig script during the
do-configure step; you can check the libtool script
location by doing <span><strong class="command">make
configure; find work*/ -name
libtool</strong></span>.</p>
<p><code class="varname">LIBTOOL_OVERRIDE</code>
specifies which libtool scripts, relative to
<code class="varname">WRKSRC</code>, to override. By
default, it is set to &#8220;<span class=
"quote">libtool */libtool */*/libtool</span>&#8221;. If
this does not match the location of the package's
libtool script(s), set it as appropriate.</p>
<p>If you do not need <code class="filename">*.a</code>
static libraries built and installed, then use
<code class="varname">SHLIBTOOL_OVERRIDE</code>
instead.</p>
<p>If your package makes use of the platform
independent library for loading dynamic shared objects,
that comes with libtool (libltdl), you should include
the libtool buildlink3.mk (and set <code class=
"varname">USE_BUILDLINK3=YES</code>).</p>
<p>Some packages use libtool incorrectly so that the
package may not work or build in some circumstances.
Some of the more common errors are:</p>
<div class="itemizedlist">
<ul type="disc">
<li>
<p>The inclusion of a shared object (-module) as
a dependent library in an executable or library.
This in itself isn't a problem if one of two
things has been done:</p>
<div class="orderedlist">
<ol type="1">
<li>
<p>The shared object is named correctly,
i.e. <code class=
"filename">libfoo.la</code>, not
<code class="filename">foo.la</code></p>
</li>
<li>
<p>The -dlopen option is used when linking
an executable.</p>
</li>
</ol>
</div>
</li>
<li>
<p>The use of libltdl without the correct calls
to initialisation routines. The function
lt_dlinit() should be called and the macro
<code class=
"varname">LTDL_SET_PRELOADED_SYMBOLS</code>
included in executables.</p>
</li>
</ul>
</div>
</div>
<div class="sect2" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h3 class="title"><a name="id2592613" id=
"id2592613"></a>12.3.3.&nbsp;GNU
Autoconf/Automake</h3>
</div>
</div>
</div>
<p>If a package needs GNU autoconf or automake to be
executed to regenerate the configure script and
Makefile.in makefile templates, then they should be
executed in a pre-configure target. Two Makefile
fragments are provided in <code class=
"filename">pkgsrc/mk/autoconf.mk</code> and
<code class="filename">pkgsrc/mk/automake.mk</code> to
help dealing with these tools. See comments in these
files for details.</p>
<p>For packages that need only autoconf:</p>
<pre class="programlisting">
AUTOCONF_REQD= 2.50 # if default version is not good enough
...
pre-configure:
cd ${WRKSRC}; ${AUTOCONF}
...
.include "../../mk/autoconf.mk"
</pre>
<p>and for packages that need automake and
autoconf:</p>
<pre class="programlisting">
AUTOMAKE_REQD= 1.7.1 # if default version is not good enough
...
pre-configure:
cd ${WRKSRC}; \
${ACLOCAL}; \
${AUTOHEADER}; \
${AUTOMAKE} -a --foreign -i; \
${AUTOCONF}
...
.include "../mk/automake.mk"
</pre>
<p>Packages which use GNU Automake will almost
certainly require GNU Make, but that's automatically
provided for you in <code class=
"filename">mk/automake.mk</code>.</p>
<p>There are times when the configure process makes
additional changes to the generated files, which then
causes the build process to try to re-execute the
automake sequence. This is prevented by touching
various files in the configure stage. If this causes
problems with your package you can set <code class=
"varname">AUTOMAKE_OVERRIDE=NO</code> in the package
Makefile.</p>
</div>
</div>
<div class="sect1" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h2 class="title" style="clear: both"><a name=
"id2592726" id="id2592726"></a>12.4.&nbsp;Building
considerations</h2>
</div>
</div>
</div>
<div class="sect2" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h3 class="title"><a name="id2592729" id=
"id2592729"></a>12.4.1.&nbsp;CPP defines</h3>
</div>
</div>
</div>
<p>To port an application to NetBSD, it's usually
necessary for the compiler to be able to judge the
system on which it's compiling, and we use definitions
so that the C pre-processor can do this.</p>
<p>To test whether you are working on a 4.4 BSD-derived
system, you should use the BSD definition, which is
defined in <code class=
"filename">&lt;sys/param.h&gt;</code> on said
systems.</p>
<pre class="programlisting">
#include &lt;sys/param.h&gt;
</pre>
<p>and then you can surround the BSD-specific parts of
your package's C/C++ code using this conditional:</p>
<pre class="programlisting">
#if (defined(BSD) &amp;&amp; BSD &gt;= 199306)
...
#endif
</pre>
<p>Please use the &#8220;<span class=
"quote">__NetBSD__</span>&#8221; definition sparingly -
it should only apply to features of NetBSD that are not
present in other 4.4-lite derived BSDs.</p>
</div>
</div>
<div class="sect1" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h2 class="title" style="clear: both"><a name=
"id2592759" id="id2592759"></a>12.5.&nbsp;Package
specific actions</h2>
</div>
</div>
</div>
<div class="sect2" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h3 class="title"><a name="id2592762" id=
"id2592762"></a>12.5.1.&nbsp;Package
configuration files</h3>
</div>
</div>
</div>
<p>Packages should be taught to look for their
configuration files in <code class=
"varname">${PKG_SYSCONFDIR}</code>, which is passed
through to the configure and build processes.
<code class="varname">PKG_SYSCONFDIR</code> may be
customized in various ways by setting other make
variables:</p>
<div class="itemizedlist">
<ul type="disc">
<li>
<p><code class="varname">PKG_SYSCONFBASE</code>
is the main config directory under which all
package configuration files are to be found. This
defaults to <code class=
"filename">${PREFIX}/etc</code>, but may be
overridden in <code class=
"filename">/etc/mk.conf</code>.</p>
</li>
<li>
<p><code class="varname">PKG_SYSCONFSUBDIR</code>
is the subdirectory of <code class=
"varname">PKG_SYSCONFBASE</code> under which the
configuration files for a particular package may
be found, e.g. the Apache configuration files may
all be found under the <code class=
"filename">httpd/</code> subdirectory of
<code class="varname">${PKG_SYSCONFBASE}</code>.
This should be set in the package Makefile.</p>
</li>
<li>
<p>By default, <code class=
"varname">PKG_SYSCONFDIR</code> is set to
<code class=
"varname">${PKG_SYSCONFBASE}/${PKG_SYSCONFSUBDIR}</code>,
but this may be overridden by setting
<code class="varname">PKG_SYSCONFDIR.${PKG_SYSCONFVAR}</code>
for a particular package, where <code class=
"varname">PKG_SYSCONFVAR</code> defaults to
<code class="varname">${PKGBASE}</code>. This is
not meant to be set by a package Makefile, but is
reserved for users who wish to override the
<code class="varname">PKG_SYSCONFDIR</code>
setting for a particular package with a special
location.</p>
</li>
</ul>
</div>
<p>The only variables that users should customize are
<code class="varname">PKG_SYSCONFBASE</code> and
<code class=
"varname">PKG_SYSCONFDIR.${PKG_SYSCONFVAR}</code>.
Users will typically want to set <code class=
"varname">PKG_SYSCONFBASE</code> to <code class=
"filename">/etc</code>, or to accept the default
location of <code class=
"filename">${PREFIX}/etc</code>.</p>
</div>
<div class="sect2" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h3 class="title"><a name="id2592933" id=
"id2592933"></a>12.5.2.&nbsp;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 type="disc">
<li>
<p>help in fetching the distfiles</p>
</li>
<li>
<p>help to configure the package before it is
built</p>
</li>
<li>
<p>help during the build process</p>
</li>
<li>
<p>help during the installation of a package</p>
</li>
</ul>
</div>
<p>The <code class="varname">INTERACTIVE_STAGE</code>
definition is provided to notify the pkgsrc mechanism
of an interactive stage which will be needed, and this
should be set in the package's <code class=
"filename">Makefile</code>. e.g.</p>
<pre class="programlisting">
INTERACTIVE_STAGE= build
</pre>
<p>Multiple interactive stages can be specified:</p>
<pre class="programlisting">
INTERACTIVE_STAGE= configure install
</pre>
</div>
<div class="sect2" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h3 class="title"><a name="id2593046" id=
"id2593046"></a>12.5.3.&nbsp;Handling
licenses</h3>
</div>
</div>
</div>
<p>A package may underly a license which the user has
or has not agreed to accept. Usually, packages that
underly well-known Open Source licenses (e.g. the GNU
Public License, GPL) won't have any special license
tags added in pkgsrc which require special action by
the user of such packages, but there are quite a number
of other licenses out there that pkgsrc users may not
be able to follow, for whatever reasons. For these
cases, pkgsrc contains a mechanism to note that a
package underlies a certain license, and the user has
to accept the license before the package can be
installed.</p>
<p>Placing a certain package under a certain license
works by setting the <code class=
"varname">LICENSE</code> variable to a string
identifying the license, e.g. in <a xmlns=
"http://www.w3.org/TR/xhtml1/transitional" href=
"ftp://ftp.NetBSD.org/pub/NetBSD/packages/pkgsrc/graphics/graphviz/README.html"
class="pkgname">graphics/graphviz</a>:</p>
<pre class="programlisting">
LICENSE= graphviz-license
</pre>
<p>When trying to build, the user will get a notice
that the package underlies a license which he hasn't
accepted (yet):</p>
<pre class="programlisting">
<code class="prompt">%</code> <strong class=
"userinput"><code>make</code></strong>
===&gt; graphviz-1.12 has an unacceptable license: graphviz-license.
===&gt; To build this package, add this line to your /etc/mk.conf:
===&gt; ACCEPTABLE_LICENSES+=graphviz-license
===&gt; To view the license, enter "/usr/bin/make show-license".
*** Error code 1
</pre>
<p>The license can be viewed with <span><strong class=
"command">make show-license</strong></span>, and if it
is considered appropriate, the line printed above can
be added to <code class="filename">/etc/mk.conf</code>
to indicate acceptance of the particular license:</p>
<pre class="programlisting">
ACCEPTABLE_LICENSES+=graphviz-license
</pre>
<p>When adding a package with a new license, the
license text should be added to <code class=
"filename">pkgsrc/licenses</code> for displaying. A
list of known licenses can be seen in this directory as
well as by looking at the list of (commented out)
<code class="varname">ACCEPTABLE_LICENSES</code>
variable settings in <code class=
"filename">pkgsrc/mk/defaults/mk.conf</code>.</p>
<p>Is there is a <span class=
"emphasis"><em>really</em></span> pressing need to
accept all licenses at once, like when trying to
download or mirror all distfiles or doing a bulk build
to test if all packages in pkgsrc build, this can be
done by setting <code class=
"varname">_ACCEPTABLE=yes</code>.</p>
</div>
<div class="sect2" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h3 class="title"><a name="id2593197" id=
"id2593197"></a>12.5.4.&nbsp;Creating an account
from a package</h3>
</div>
</div>
</div>
<p>There are two make variables used to control the
creation of package-specific groups and users at
pre-install time. The first is <code class=
"varname">PKG_GROUPS</code>, which is a list of
group[:groupid] elements, where the groupid is
optional. The second is <code class=
"varname">PKG_USERS</code>, which is a list of elements
of the form:</p>
<pre class="programlisting">
user:group[:[userid][:[description][:[home][:shell]]]]
</pre>
<p>where only the user and group are required, the rest
being optional. A simple example is:</p>
<pre class="programlisting">
PKG_GROUPS= foogroup
PKG_USERS= foouser:foogroup
</pre>
<p>A more complex example is that creates two groups
and two users is:</p>
<pre class="programlisting">
PKG_GROUPS= group1 group2:1005
PKG_USERS= first:group1::First\\ User \
second:group2::Second\\ User:/home/second:${SH}
</pre>
<p>By default, a new user will have home directory
<code class="filename">/nonexistent</code>, and login
shell <code class="filename">/sbin/nologin</code>
unless they are specified as part of the user
element.</p>
<p>The package <code class="filename">Makefile</code>
must also set <code class=
"varname">USE_PKGINSTALL=YES</code>. This will cause
the users and groups to be created at pre-install time,
and the admin will be prompted to remove them at
post-deinstall time. Automatic creation of the users
and groups can be toggled on and off by setting the
<code class="varname">PKG_CREATE_USERGROUP</code>
variable prior to package installation.</p>
</div>
<div class="sect2" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h3 class="title"><a name="id2593328" id=
"id2593328"></a>12.5.5.&nbsp;Installing score
files</h3>
</div>
</div>
</div>
<p>Certain packages, most of them in the games
category, install a score file that allows all users on
the system to record their highscores. In order for
this to work, the binaries need to be installed setgid
and the score files owned by the appropriate group
and/or owner (traditionally the "games" user/group).
The following variables, documented in more detail in
<code class="filename">mk/defaults/mk.conf</code>,
control this behaviour: <code class=
"varname">SETGIDGAME</code>, <code class=
"varname">GAMEDATAMODE</code>, <code class=
"varname">GAMEGRP</code>, <code class=
"varname">GAMEMODE</code>, <code class=
"varname">GAMEOWN</code>.</p>
<p>Note that per default, setgid installation of games
is disabled; setting <code class=
"varname">SETGIDGAME=YES</code> will set all the other
variables accordingly.</p>
<p>A package should therefor never hard code file
ownership or access permissions but rely on
<code class="varname">INSTALL_GAME</code> and
<code class="varname">INSTALL_GAME_DATA</code> to set
these correctly.</p>
</div>
<div class="sect2" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h3 class="title"><a name="id2593371" id=
"id2593371"></a>12.5.6.&nbsp;Packages providing
login shells</h3>
</div>
</div>
</div>
<p>If the purpose of the package is to provide a login
shell, the variable <code class=
"varname">PKG_SHELL</code> should contain the full
pathname of the shell executable installed by this
package. The package <code class=
"filename">Makefile</code> must also set <code class=
"varname">USE_PKGINSTALL=YES</code> to use the
automatically generated <code class=
"filename">INSTALL</code>/<code class=
"filename">DEINSTALL</code> scripts.</p>
<p>An example taken from shells/zsh:</p>
<pre class="programlisting">
USE_PKGINSTALL= YES
PKG_SHELL= ${PREFIX}/bin/zsh
</pre>
<p>The shell is registered into <code class=
"filename">/etc/shells</code> file automatically in the
post-install target by the generated <code class=
"filename">INSTALL</code> script and removed in the
deinstall target by the <code class=
"filename">DEINSTALL</code> script.</p>
</div>
<div class="sect2" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h3 class="title"><a name="id2593429" id=
"id2593429"></a>12.5.7.&nbsp;Packages containing
perl scripts</h3>
</div>
</div>
</div>
<p>If your package contains interpreted perl scripts,
set <code class="varname">REPLACE_PERL</code> to ensure
that the proper interpreter path is set. <code class=
"varname">REPLACE_PERL</code> should contain a list of
scripts, relative to <code class=
"varname">WRKSRC</code>, that you want adjusted.</p>
</div>
<div class="sect2" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h3 class="title"><a name="id2593447" id=
"id2593447"></a>12.5.8.&nbsp;Packages with
hardcoded paths to other interpreters</h3>
</div>
</div>
</div>
<p>Your package may also contain scripts with hardcoded
paths to other interpreters besides (or as well as)
perl. To correct the full pathname to the script
interpreter, you need to set the following definitions
in your <code class="filename">Makefile</code> (we
shall use <span><strong class=
"command">tclsh</strong></span> in this example):</p>
<pre class="programlisting">
REPLACE_INTERPRETER+= tcl
_REPLACE.tcl.old= .*/bin/tclsh
_REPLACE.tcl.new= ${PREFIX}/bin/tclsh
_REPLACE_FILES.tcl= ...list of tcl scripts which need to be fixed,
relative to ${WRKSRC}, just as in REPLACE_PERL
</pre>
</div>
<div class="sect2" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h3 class="title"><a name="id2593468" id=
"id2593468"></a>12.5.9.&nbsp;Packages installing
perl modules</h3>
</div>
</div>
</div>
<p>Makefiles of packages providing perl5 modules should
include the Makefile fragment <code class=
"filename">../../lang/perl5/module.mk</code>. It
provides a <span><strong class=
"command">do-configure</strong></span> target for the
standard perl configuration for such modules as well as
various hooks to tune this configuration. See comments
in this file for details.</p>
<p>Perl5 modules will install into different places
depending on the version of perl used during the build
process. To address this, pkgsrc will append lines to
the <code class="filename">PLIST</code> corresponding
to the files listed in the installed <code class=
"filename">.packlist</code> file generated by most
perl5 modules. This is invoked by defining <code class=
"varname">PERL5_PACKLIST</code> to a space-separated
list of paths to packlist files, e.g.:</p>
<pre class="programlisting">
PERL5_PACKLIST= ${PERL5_SITEARCH}/auto/Pg/.packlist
</pre>
<p>The variables <code class=
"varname">PERL5_SITELIB</code>, <code class=
"varname">PERL5_SITEARCH</code>, and <code class=
"varname">PERL5_ARCHLIB</code> represent the three
locations in which perl5 modules may be installed, and
may be used by perl5 packages that don't have a
packlist. These three variables are also substituted
for in the <code class="filename">PLIST</code>.</p>
</div>
<div class="sect2" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h3 class="title"><a name="faq.info-files" id=
"faq.info-files"></a>12.5.10.&nbsp;Packages
installing info files</h3>
</div>
</div>
</div>
<p>Some packages install info files or use the
&#8220;<span class="quote">makeinfo</span>&#8221; or
&#8220;<span class="quote">install-info</span>&#8221;
commands. Each of the info files:</p>
<div class="itemizedlist">
<ul type="disc">
<li>
<p>is considered to be installed in the directory
<code class=
"filename">${PREFIX}/${INFO_DIR}</code>,</p>
</li>
<li>
<p>is registered in the Info directory file
<code class=
"filename">${PREFIX}/${INFO_DIR}/dir</code>,</p>
</li>
<li>
<p>and must be listed as a filename in the
<code class="varname">INFO_FILES</code> variable
in the package Makefile.</p>
</li>
</ul>
</div>
<p><code class="varname">INFO_DIR</code> defaults to
&#8220;<span class="quote">info</span>&#8221; and can
be overridden in the package Makefile. <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 &#8220;<span class=
"quote">install-info</span>&#8221; 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>A package which needs the &#8220;<span class=
"quote">makeinfo</span>&#8221; command at build time
must define the variable <code class=
"varname">USE_MAKEINFO</code> in its Makefile. If a
minimum version of the &#8220;<span class=
"quote">makeinfo</span>&#8221; command is needed it
should be noted with the <code class=
"varname">TEXINFO_REQD</code> variable in the package
<code class="filename">Makefile</code>. By default, a
minimum version of 3.12 is required. If the system does
not provide a <span><strong class=
"command">makeinfo</strong></span> command or if it
does not match the required minimum, a build dependency
on the <a xmlns=
"http://www.w3.org/TR/xhtml1/transitional" href=
"ftp://ftp.NetBSD.org/pub/NetBSD/packages/pkgsrc/devel/gtexinfo/README.html"
class="pkgname">devel/gtexinfo</a> package will be
added automatically.</p>
<p>The build and installation process of the software
provided by the package should not use the
<span><strong class=
"command">install-info</strong></span> command as the
registration of info files is the task of the package
<code class="filename">INSTALL</code> script, and it
must use the appropriate <span><strong class=
"command">makeinfo</strong></span> command.</p>
<p>To achieve this goal the pkgsrc infrastructure
creates overriding scripts for the <span><strong class=
"command">install-info</strong></span> and
<span><strong class="command">makeinfo</strong></span>
commands in a directory listed early in <code class=
"varname">PATH</code>.</p>
<p>The script overriding <span><strong class=
"command">install-info</strong></span> has no effect
except the logging of a message. The script overriding
<span><strong class="command">makeinfo</strong></span>
logs a message and according to the value of
<code class="varname">USE_MAKEINFO</code> and
<code class="varname">TEXINFO_REQD</code> either run
the appropriate <span><strong class=
"command">makeinfo</strong></span> command or exit on
error.</p>
</div>
<div class="sect2" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h3 class="title"><a name="id2593688" id=
"id2593688"></a>12.5.11.&nbsp;Packages installing
GConf2 data files</h3>
</div>
</div>
</div>
<p>If a package installs <code class=
"filename">.schemas</code> or <code class=
"filename">.entries</code> files, used by GConf2, you
need to take some extra steps to make sure they get
registered in the database:</p>
<div class="orderedlist">
<ol type="1">
<li>
<p>Include <code class=
"filename">../../devel/GConf2/schemas.mk</code>
instead of its <code class=
"filename">buildlink3.mk</code> file. This takes
care of rebuilding the GConf2 database at
installation and deinstallation time, and tells
the package where to install GConf2 data files
using some standard configure arguments. It also
disallows any access to the database directly
from the package.</p>
</li>
<li>
<p>Ensure that the package installs its
<code class="filename">.schemas</code> files
under <code class=
"filename">${PREFIX}/share/gconf/schemas</code>.
If they get installed under <code class=
"filename">${PREFIX}/etc</code>, you will need to
manually patch the package.</p>
</li>
<li>
<p>Check the PLIST and remove any entries under
the etc/gconf directory, as they will be handled
automatically. See <a href="#faq.conf" title=
"6.14.&nbsp;Configuration files handling and placement">
Section&nbsp;6.14, &#8220;Configuration files
handling and placement&#8221;</a> for more
information.</p>
</li>
<li>
<p>Define the <code class=
"varname">GCONF2_SCHEMAS</code> variable in your
<code class="filename">Makefile</code> with a
list of all <code class=
"filename">.schemas</code> files installed by the
package, if any. Names must not contain any
directories in them.</p>
</li>
<li>
<p>Define the <code class=
"varname">GCONF2_ENTRIES</code> variable in your
<code class="filename">Makefile</code> with a
list of all <code class=
"filename">.entries</code> files installed by the
package, if any. Names must not contain any
directories in them.</p>
</li>
</ol>
</div>
</div>
<div class="sect2" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h3 class="title"><a name="id2593788" id=
"id2593788"></a>12.5.12.&nbsp;Packages installing
scrollkeeper data files</h3>
</div>
</div>
</div>
<p>If a package installs <code class=
"filename">.omf</code> files, used by scrollkeeper, you
need to take some extra steps to make sure they get
registered in the database:</p>
<div class="orderedlist">
<ol type="1">
<li>
<p>Include <code class=
"filename">../../textproc/scrollkeeper/omf.mk</code>
instead of its <code class=
"filename">buildlink3.mk</code> file. This takes
care of rebuilding the scrollkeeper database at
installation and deinstallation time, and
disallows any access to it directly from the
package.</p>
</li>
<li>
<p>Check the PLIST and remove any entries under
the <code class=
"filename">libdata/scrollkeeper</code> directory,
as they will be handled automatically.</p>
</li>
<li>
<p>Remove the <code class=
"filename">share/omf</code> directory from the
PLIST. It will be handled by scrollkeeper.</p>
</li>
</ol>
</div>
</div>
<div class="sect2" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h3 class="title"><a name="id2593840" id=
"id2593840"></a>12.5.13.&nbsp;Packages installing
X11 fonts</h3>
</div>
</div>
</div>
<p>If a package installs font files, you will need to
rebuild the fonts database in the directory where they
get installed at installation and deinstallation time.
This can be automatically done by using <code class=
"filename">mk/fonts.mk</code>, which you need to
include in your <code class=
"filename">Makefile</code>.</p>
<p>When the file is included, you can list the
directories where fonts are installed in the
<code class="varname">FONTS_<em class=
"replaceable"><code>type</code></em>_DIRS</code>
variables, where <em class=
"replaceable"><code>type</code></em> can be one of
&#8220;<span class="quote">TTF</span>&#8221;,
&#8220;<span class="quote">TYPE1</span>&#8221; or
&#8220;<span class="quote">X11</span>&#8221;. Also make
sure that the database file <code class=
"filename">fonts.dir</code> is not listed in the
PLIST.</p>
<p>Note that you should not create new directories for
fonts; instead use the standard ones to avoid that the
user needs to manually configure his X server to find
them.</p>
</div>
<div class="sect2" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h3 class="title"><a name="id2593886" id=
"id2593886"></a>12.5.14.&nbsp;Packages installing
GTK2 modules</h3>
</div>
</div>
</div>
<p>If a package installs gtk2 immodules or loaders, you
need to take some extra steps to get them registered in
the GTK2 database properly:</p>
<div class="orderedlist">
<ol type="1">
<li>
<p>Include <code class=
"filename">../../x11/gtk2/modules.mk</code>
instead of its <code class=
"filename">buildlink3.mk</code> file. This takes
care of rebuilding the database at installation
and deinstallation time.</p>
</li>
<li>
<p>Set <code class=
"varname">GTK2_IMMODULES=YES</code> if your
package installs GTK2 immodules.</p>
</li>
<li>
<p>Set <code class=
"varname">GTK2_LOADERS=YES</code> if your package
installs GTK2 loaders.</p>
</li>
<li>
<p>Patch the package to not touch any of the gtk2
databases directly. These are:</p>
<div class="itemizedlist">
<ul type="disc">
<li>
<p><code class=
"filename">libdata/gtk-2.0/gdk-pixbuf.loaders</code></p>
</li>
<li>
<p><code class=
"filename">libdata/gtk-2.0/gtk.immodules</code></p>
</li>
</ul>
</div>
</li>
<li>
<p>Check the PLIST and remove any entries under
the <code class="filename">libdata/gtk-2.0</code>
directory, as they will be handled
automatically.</p>
</li>
</ol>
</div>
</div>
<div class="sect2" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h3 class="title"><a name="id2593956" id=
"id2593956"></a>12.5.15.&nbsp;Packages installing
SGML or XML data</h3>
</div>
</div>
</div>
<p>If a package installs SGML or XML data files that
need to be registered in system-wide catalogs (like
DTDs, sub-catalogs, etc.), you need to take some extra
steps:</p>
<div class="orderedlist">
<ol type="1">
<li>
<p>Include <code class=
"filename">../../textproc/xmlcatmgr/catalogs.mk</code>
in your <code class="filename">Makefile</code>,
which takes care of registering those files in
system-wide catalogs at installation and
deinstallation time.</p>
</li>
<li>
<p>Set <code class="varname">SGML_CATALOGS</code>
to the full path of any SGML catalogs installed
by the package.</p>
</li>
<li>
<p>Set <code class="varname">XML_CATALOGS</code>
to the full path of any XML catalogs installed by
the package.</p>
</li>
<li>
<p>Set <code class="varname">SGML_ENTRIES</code>
to individual entries to be added to the SGML
catalog. These come in groups of three strings;
see xmlcatmgr(1) for more information
(specifically, arguments recognized by the 'add'
action). Note that you will normally not use this
variable.</p>
</li>
<li>
<p>Set <code class="varname">XML_ENTRIES</code>
to individual entries to be added to the XML
catalog. These come in groups of three strings;
see xmlcatmgr(1) for more information
(specifically, arguments recognized by the 'add'
action). Note that you will normally not use this
variable.</p>
</li>
</ol>
</div>
</div>
<div class="sect2" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h3 class="title"><a name="id2594076" id=
"id2594076"></a>12.5.16.&nbsp;Packages installing
extensions to the MIME database</h3>
</div>
</div>
</div>
<p>If a package provides extensions to the MIME
database by installing <code class=
"filename">.xml</code> files inside <code class=
"filename">${PREFIX}/share/mime/packages</code>, you
need to take some extra steps to ensure that the
database is kept consistent with respect to these new
files:</p>
<div class="orderedlist">
<ol type="1">
<li>
<p>Include <code class=
"filename">../../databases/shared-mime-info/mimedb.mk</code>
(avoid using the <code class=
"filename">buildlink3.mk</code> file from this
same directory, which is reserved for inclusion
from other <code class=
"filename">buildlink3.mk</code> files). It takes
care of rebuilding the MIME database at
installation and deinstallation time, and
disallows any access to it directly from the
package.</p>
</li>
<li>
<p>Check the PLIST and remove any entries under
the <code class="filename">share/mime</code>
directory, <span class=
"emphasis"><em>except</em></span> for files saved
under <code class=
"filename">share/mime/packages</code>. The former
are handled automatically by the
update-mime-database program, but the later are
package-dependent and must be removed by the
package that installed them in the first
place.</p>
</li>
<li>
<p>Remove any <code class=
"filename">share/mime/*</code> directories from
the PLIST. They will be handled by the
shared-mime-info package.</p>
</li>
</ol>
</div>
</div>
<div class="sect2" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h3 class="title"><a name="id2594283" id=
"id2594283"></a>12.5.17.&nbsp;Packages using
intltool</h3>
</div>
</div>
</div>
<p>If a package uses intltool during its build, include
the <code class=
"filename">../../textproc/intltool/buildlink3.mk</code>
file, which forces it to use the intltool package
provided by pkgsrc, instead of the one bundled with the
distribution file.</p>
<p>This tracks intltool's build-time dependencies and
uses the latest available version; this way, the
package benefits of any bug fixes that may have
appeared since it was released.</p>
</div>
</div>
<div class="sect1" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h2 class="title" style="clear: both"><a name=
"id2594297" id="id2594297"></a>12.6.&nbsp;Feedback
to the author</h2>
</div>
</div>
</div>
<p>If you have found any bugs in the package you make
available, if you had to do special steps to make it run
under NetBSD or if you enhanced the software in various
other ways, be sure to report these changes back to the
original author of the program! With that kind of
support, the next release of the program can incorporate
these fixes, and people not using the NetBSD packages
system can win from your efforts.</p>
<p>Support the idea of free software!</p>
</div>
</div>
<div class="chapter" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h2 class="title"><a name="debug" id=
"debug"></a>Chapter&nbsp;13.&nbsp;Debugging</h2>
</div>
</div>
</div>
<p>To check out all the gotchas when building a package,
here are the steps that I do in order to get a package
working. Please note this is basically the same as what was
explained in the previous sections, only with some
debugging aids.</p>
<div class="itemizedlist">
<ul type="disc">
<li>
<p>Be sure to set <code class=
"varname">PKG_DEVELOPER=1</code> in <code class=
"filename">/etc/mk.conf</code></p>
</li>
<li>
<p>Install <a xmlns=
"http://www.w3.org/TR/xhtml1/transitional" href=
"ftp://ftp.NetBSD.org/pub/NetBSD/packages/pkgsrc/pkgtools/url2pkg/README.html"
class="pkgname">pkgtools/url2pkg</a>, create a
directory for a new package, change into it, then run
<span><strong class=
"command">url2pkg</strong></span>:</p>
<pre class="screen">
<code class="prompt">%</code> <strong class=
"userinput"><code>mkdir /usr/pkgsrc/<em class=
"replaceable"><code>category</code></em>/<em class=
"replaceable"><code>examplepkg</code></em></code></strong>
<code class="prompt">%</code> <strong class=
"userinput"><code>cd /usr/pkgsrc/<em class=
"replaceable"><code>category</code></em>/<em class=
"replaceable"><code>examplepkg</code></em></code></strong>
<code class="prompt">%</code> <strong class=
"userinput"><code>url2pkg http://www.example.com/path/to/distfile.tar.gz</code></strong>
</pre>
</li>
<li>
<p>Edit the <code class="filename">Makefile</code> as
requested.</p>
</li>
<li>
<p>Fill in the <code class="filename">DESCR</code>
file</p>
</li>
<li>
<p>Run <span><strong class="command">make
configure</strong></span></p>
</li>
<li>
<p>Add any dependencies glimpsed from documentation
and the configure step to the package's <code class=
"filename">Makefile</code>.</p>
</li>
<li>
<p>Make the package compile, doing multiple rounds
of</p>
<pre class="screen">
<code class="prompt">%</code> <strong class=
"userinput"><code>make</code></strong>
<code class="prompt">%</code> <strong class=
"userinput"><code>pkgvi ${WRKSRC}/some/file/that/does/not/compile</code></strong>
<code class="prompt">%</code> <strong class=
"userinput"><code>mkpatches</code></strong>
<code class="prompt">%</code> <strong class=
"userinput"><code>patchdiff</code></strong>
<code class="prompt">%</code> <strong class=
"userinput"><code>mv ${WRKDIR}/.newpatches/* patches</code></strong>
<code class="prompt">%</code> <strong class=
"userinput"><code>make mps</code></strong>
<code class="prompt">%</code> <strong class=
"userinput"><code>make clean</code></strong>
</pre>
<p>Doing as non-root user will ensure that no files
are modified that shouldn't be, especially during the
build phase. <span><strong class=
"command">mkpatches</strong></span>,
<span><strong class=
"command">patchdiff</strong></span> and
<span><strong class="command">pkgvi</strong></span>
are from the <a xmlns=
"http://www.w3.org/TR/xhtml1/transitional" href=
"ftp://ftp.NetBSD.org/pub/NetBSD/packages/pkgsrc/pkgtools/pkgdiff/README.html"
class="pkgname">pkgtools/pkgdiff</a> package.</p>
</li>
<li>
<p>Look at the <code class=
"filename">Makefile</code>, fix if necessary; see
<a href="#components.Makefile" title=
"7.1.&nbsp;Makefile">Section&nbsp;7.1,
&#8220;<code class=
"filename">Makefile</code>&#8221;</a>.</p>
</li>
<li>
<p>Generate a <code class=
"filename">PLIST</code>:</p>
<pre class="screen">
<code class="prompt">#</code> <strong class=
"userinput"><code>make install</code></strong>
<code class="prompt">#</code> <strong class=
"userinput"><code>make print-PLIST &gt;PLIST</code></strong>
<code class="prompt">#</code> <strong class=
"userinput"><code>make deinstall</code></strong>
<code class="prompt">#</code> <strong class=
"userinput"><code>make install</code></strong>
<code class="prompt">#</code> <strong class=
"userinput"><code>make deinstall</code></strong>
</pre>
<p>You usually need to be <code class=
"username">root</code> to do this. Look if there are
any files left:</p>
<pre class="screen">
<code class="prompt">#</code> <strong class=
"userinput"><code>make print-PLIST</code></strong>
</pre>
<p>If this reveals any files that are missing in
<code class="filename">PLIST</code>, add them.</p>
</li>
<li>
<p>Now that the <code class="filename">PLIST</code>
is OK, install the package again and make a binary
package:</p>
<pre class="screen">
<code class="prompt">#</code> <strong class=
"userinput"><code>make reinstall</code></strong>
<code class="prompt">#</code> <strong class=
"userinput"><code>make package</code></strong>
</pre>
</li>
<li>
<p>Delete the installed package:</p>
<pre class="screen">
<code class="prompt">#</code> <strong class=
"userinput"><code>pkg_delete blub</code></strong>
</pre>
</li>
<li>
<p>Repeat the above <span><strong class=
"command">make print-PLIST</strong></span> command,
which shouldn't find anything now:</p>
<pre class="screen">
<code class="prompt">#</code> <strong class=
"userinput"><code>make print-PLIST</code></strong>
</pre>
</li>
<li>
<p>Reinstall the binary package:</p>
<pre class="screen">
<code class="prompt">#</code> <strong class=
"userinput"><code>pkgadd .../blub.tgz</code></strong>
</pre>
</li>
<li>
<p>Play with it. Make sure everything works.</p>
</li>
<li>
<p>Run <span><strong class=
"command">pkglint</strong></span> from <a xmlns=
"http://www.w3.org/TR/xhtml1/transitional" href=
"ftp://ftp.NetBSD.org/pub/NetBSD/packages/pkgsrc/pkgtools/pkglint/README.html"
class="pkgname">pkgtools/pkglint</a>, and fix the
problems it reports:</p>
<pre class="screen">
<code class="prompt">#</code> <strong class=
"userinput"><code>pkglint</code></strong>
</pre>
</li>
<li>
<p>Submit (or commit, if you have cvs access); see
<a href="#submit" title=
"Chapter&nbsp;14.&nbsp;Submitting and Committing">Chapter&nbsp;14,
<i>Submitting and Committing</i></a>.</p>
</li>
</ul>
</div>
</div>
<div class="chapter" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h2 class="title"><a name="submit" id=
"submit"></a>Chapter&nbsp;14.&nbsp;Submitting and
Committing</h2>
</div>
</div>
</div>
<div class="toc">
<p><b>Table of Contents</b></p>
<dl>
<dt><span class="sect1"><a href="#id2594827">14.1.
Submitting your packages</a></span></dt>
<dt><span class="sect1"><a href="#id2594878">14.2.
Committing: Importing a package into
CVS</a></span></dt>
<dt><span class="sect1"><a href="#id2594941">14.3.
Updating a package to a newer version</a></span></dt>
<dt><span class="sect1"><a href="#id2594961">14.4.
Moving a package in pkgsrc</a></span></dt>
</dl>
</div>
<div class="sect1" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h2 class="title" style="clear: both"><a name=
"id2594827" id=
"id2594827"></a>14.1.&nbsp;Submitting your
packages</h2>
</div>
</div>
</div>
<p>You have to separate between binary and
&#8220;<span class="quote">normal</span>&#8221; (source)
packages here:</p>
<div class="itemizedlist">
<ul type="disc">
<li>
<p>precompiled binary packages</p>
<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 href="#bulk-upload"
title="5.3.8.&nbsp;Uploading results of a bulk build">
Section&nbsp;5.3.8, &#8220;Uploading results of a
bulk build&#8221;</a>.</p>
</li>
<li>
<p>packages</p>
<p>First, check that your package is complete,
compiles and runs well; see <a href="#debug" title=
"Chapter&nbsp;13.&nbsp;Debugging">Chapter&nbsp;13,
<i>Debugging</i></a> and the rest of this document.
Next, generate an uuencoded gzipped tar(1) archive,
preferably with all files in a single directory.
Finally, <span><strong class=
"command">send-pr</strong></span> with category
&#8220;<span class="quote">pkg</span>&#8221;, a
synopsis which includes the package name and
version number, a short description of your package
(contents of the COMMENT variable or DESCR file are
OK) and attach the archive to your PR.</p>
<p>If you want to submit several packages, please
send a separate PR for each one, it's easier for us
to track things that way.</p>
<p>Alternatively, you can also import new packages
into pkgsrc-wip (&#8220;<span class="quote">pkgsrc
work-in-progress</span>&#8221;); see the homepage
at <a href="http://pkgsrc-wip.sourceforge.net/"
target=
"_top">http://pkgsrc-wip.sourceforge.net/</a> for
details.</p>
</li>
</ul>
</div>
</div>
<div class="sect1" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h2 class="title" style="clear: both"><a name=
"id2594878" id=
"id2594878"></a>14.2.&nbsp;Committing: Importing a
package into CVS</h2>
</div>
</div>
</div>
<p>This section is only of interest for pkgsrc developers
with write access to the pkgsrc repository. Please
remember that cvs imports files relative to the current
working directory, and that the pathname that you give
the <span><strong class="command">cvs
import</strong></span> command is so that it knows where
to place the files in the repository. Newly created
packages should be imported with a vendor tag of
&#8220;<span class="quote">TNF</span>&#8221; and a
release tag of &#8220;<span class=
"quote">pkgsrc-base</span>&#8221;, e.g:</p>
<pre class="programlisting">
% cd .../pkgsrc/category/pkgname
% cvs import pkgsrc/category/pkgname TNF pkgsrc-base
</pre>
<p>Remember to move the directory from which you imported
out of the way, or cvs will complain the next time you
&#8220;<span class="quote">cvs update</span>&#8221; your
source tree. Also don't forget to add the new package to
the category's <code class=
"filename">Makefile</code>.</p>
<p>The commit message of the initial import should
include part of the <code class="filename">DESCR</code>
file, so people reading the mailing lists know what the
package is/does.</p>
<p>Please note all package updates/additions in
<code class="filename">pkgsrc/doc/CHANGES</code>. It's
very important to keep this file up to date and
conforming to the existing format, because it will be
used by scripts to automatically update pages on <a href=
"http://www.NetBSD.org/" target="_top">www.NetBSD.org</a>
and other sites. Additionally, check the pkgsrc/doc/TODO
file and remove the entry for the package you updated, in
case it was mentioned there.</p>
<p>For new packages, &#8220;<span class="quote">cvs
import</span>&#8221; is preferred to &#8220;<span class=
"quote">cvs add</span>&#8221; because the former gets
everything with a single command, and provides a
consistent tag.</p>
</div>
<div class="sect1" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h2 class="title" style="clear: both"><a name=
"id2594941" id="id2594941"></a>14.3.&nbsp;Updating
a package to a newer version</h2>
</div>
</div>
</div>
<p>Please always put a concise, appropriate and relevant
summary of the changes between old and new versions into
the commit log when updating a package. There are various
reasons for this:</p>
<div class="itemizedlist">
<ul type="disc">
<li>
<p>A URL is volatile, and can change over time. It
may go away completely or its information may be
overwritten by newer information.</p>
</li>
<li>
<p>Having the change information between old and
new versions in our CVS repository is very useful
for people who use either cvs or anoncvs.</p>
</li>
<li>
<p>Having the change information between old and
new versions in our CVS repository is very useful
for people who read the pkgsrc-changes mailing
list, so that they can make tactical decisions
about when to upgrade the package.</p>
</li>
</ul>
</div>
<p>Please also recognise that, just because a new version
of a package has been released, it should not
automatically be upgraded in the CVS repository. We
prefer to be conservative in the packages that are
included in pkgsrc - development or beta packages are not
really the best thing for most places in which pkgsrc is
used. Please use your judgement about what should go into
pkgsrc, and bear in mind that stability is to be
preferred above new and possibly untested features.</p>
</div>
<div class="sect1" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h2 class="title" style="clear: both"><a name=
"id2594961" id="id2594961"></a>14.4.&nbsp;Moving a
package in pkgsrc</h2>
</div>
</div>
</div>
<div class="orderedlist">
<ol type="1">
<li>
<p>Make a copy of the directory somewhere else.</p>
</li>
<li>
<p>Remove all CVS dirs.</p>
<p>Alternatively to the first two steps you can
also do:</p>
<pre class="screen">
<code class="prompt">%</code> <strong class=
"userinput"><code>cvs -d user@cvs.NetBSD.org:/cvsroot export -D today pkgsrc/category/package</code></strong>
</pre>
<p>and use that for further work.</p>
</li>
<li>
<p>Fix <code class="varname">CATEGORIES</code> and
any <code class="varname">DEPENDS</code> paths that
just did &#8220;<span class=
"quote">../package</span>&#8221; instead of
&#8220;<span class=
"quote">../../category/package</span>&#8221;.</p>
</li>
<li>
<p><span><strong class="command">cvs
import</strong></span> the modified package in the
new place.</p>
</li>
<li>
<p>Check if any package depends on it:</p>
<pre class="screen">
<code class="prompt">%</code> <strong class=
"userinput"><code>cd /usr/pkgsrc</code></strong>
<code class="prompt">%</code> <strong class=
"userinput"><code>grep /package */*/Makefile* */*/buildlink*</code></strong>
</pre>
</li>
<li>
<p>Fix paths in packages from step 5 to point to
new location.</p>
</li>
<li>
<p><span><strong class="command">cvs rm
(-f)</strong></span> the package at the old
location.</p>
</li>
<li>
<p>Remove from <code class=
"filename">oldcategory/Makefile</code>.</p>
</li>
<li>
<p>Add to <code class=
"filename">newcategory/Makefile</code>.</p>
</li>
<li>
<p>Commit the changed and removed files:</p>
<pre class="screen">
<code class="prompt">%</code> <strong class=
"userinput"><code>cvs commit oldcategory/package oldcategory/Makefile newcategory/Makefile</code></strong>
</pre>
<p>(and any packages from step 5, of course).</p>
</li>
</ol>
</div>
</div>
</div>
</div>
<div class="appendix" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h2 class="title"><a name="examples" id=
"examples"></a>Appendix&nbsp;A.&nbsp;A simple example
package: bison</h2>
</div>
</div>
</div>
<div class="toc">
<p><b>Table of Contents</b></p>
<dl>
<dt><span class="sect1"><a href="#id2595255">A.1.
files</a></span></dt>
<dd>
<dl>
<dt><span class="sect2"><a href="#id2595258">A.1.1.
Makefile</a></span></dt>
<dt><span class="sect2"><a href="#id2595266">A.1.2.
DESCR</a></span></dt>
<dt><span class="sect2"><a href="#id2595281">A.1.3.
PLIST</a></span></dt>
<dt><span class="sect2"><a href="#id2595288">A.1.4.
Checking a package with <span><strong class=
"command">pkglint</strong></span></a></span></dt>
</dl>
</dd>
<dt><span class="sect1"><a href="#id2595329">A.2. Steps
for building, installing, packaging</a></span></dt>
</dl>
</div>
<p>We checked to find a piece of software that wasn't in the
packages collection, and picked GNU bison. Quite why someone
would want to have <span><strong class=
"command">bison</strong></span> when Berkeley
<span><strong class="command">yacc</strong></span> is already
present in the tree is beyond us, but it's useful for the
purposes of this exercise.</p>
<div class="sect1" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h2 class="title" style="clear: both"><a name=
"id2595255" id="id2595255"></a>A.1.&nbsp;files</h2>
</div>
</div>
</div>
<div class="sect2" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h3 class="title"><a name="id2595258" id=
"id2595258"></a>A.1.1.&nbsp;Makefile</h3>
</div>
</div>
</div>
<pre class="programlisting">
# $NetBSD$
#
DISTNAME= bison-1.25
CATEGORIES= devel
MASTER_SITES= ${MASTER_SITE_GNU}
MAINTAINER= thorpej@NetBSD.org
HOMEPAGE= http://www.gnu.org/software/bison/bison.html
COMMENT= GNU yacc clone
GNU_CONFIGURE= yes
INFO_FILES= bison.info
.include "../../mk/bsd.pkg.mk"
</pre>
</div>
<div class="sect2" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h3 class="title"><a name="id2595266" id=
"id2595266"></a>A.1.2.&nbsp;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 href=
"http://netbsd.gw.com/cgi-bin/man-cgi?yacc+1+NetBSD-current"><span class="citerefentry"><span class="refentrytitle">yacc</span>(1)</span></a> is part
of the NetBSD source tree is beyond me.
</pre>
</div>
<div class="sect2" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h3 class="title"><a name="id2595281" id=
"id2595281"></a>A.1.3.&nbsp;PLIST</h3>
</div>
</div>
</div>
<pre class="programlisting">
@comment $NetBSD$
bin/bison
man/man1/bison.1.gz
share/bison.simple
share/bison.hairy
</pre>
</div>
<div class="sect2" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h3 class="title"><a name="id2595288" id=
"id2595288"></a>A.1.4.&nbsp;Checking a package with
<span><strong class=
"command">pkglint</strong></span></h3>
</div>
</div>
</div>
<p>The NetBSD package system comes with <a xmlns=
"http://www.w3.org/TR/xhtml1/transitional" href=
"ftp://ftp.NetBSD.org/pub/NetBSD/packages/pkgsrc/pkgtools/pkglint/README.html"
class="pkgname">pkgtools/pkglint</a> which helps to check
the contents of these files. After installation it is
quite easy to use, just change to the directory of the
package you wish to examine and execute
<span><strong class=
"command">pkglint</strong></span>:</p>
<pre class="screen">
<code class="prompt">$</code> <strong class=
"userinput"><code>pkglint</code></strong>
OK: checking ./DESCR.
OK: checking Makefile.
OK: checking distinfo.
OK: checking patches/patch-aa.
looks fine.
</pre>
<p>Depending on the supplied command line arguments (see
pkglint(1)) more verbose checks will be performed. Use
e.g. <span><strong class="command">pkglint
-v</strong></span> for a very verbose check.</p>
</div>
</div>
<div class="sect1" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h2 class="title" style="clear: both"><a name=
"id2595329" id="id2595329"></a>A.2.&nbsp;Steps for
building, installing, packaging</h2>
</div>
</div>
</div>
<p>Create the directory where the package lives, plus any
auxiliary directories:</p>
<pre class="screen">
<code class="prompt">#</code> <strong class=
"userinput"><code>cd /usr/pkgsrc/lang</code></strong>
<code class="prompt">#</code> <strong class=
"userinput"><code>mkdir bison</code></strong>
<code class="prompt">#</code> <strong class=
"userinput"><code>cd bison</code></strong>
<code class="prompt">#</code> <strong class=
"userinput"><code>mkdir patches</code></strong>
</pre>
<p>Create <code class="filename">Makefile</code>,
<code class="filename">DESCR</code> and <code class=
"filename">PLIST</code> (see <a href="#components" title=
"Chapter&nbsp;7.&nbsp;Package components - files, directories and contents">
Chapter 7, <i>Package components - files, directories and
contents</i></a>) then continue with fetching the
distfile:</p>
<pre class="screen">
<code class="prompt">#</code> <strong class=
"userinput"><code>make fetch</code></strong>
&gt;&gt; bison-1.25.tar.gz doesn't seem to exist on this system.
&gt;&gt; Attempting to fetch from ftp://prep.ai.mit.edu/pub/gnu//.
Requesting ftp://prep.ai.mit.edu/pub/gnu//bison-1.25.tar.gz (via ftp://orpheus.amdahl.com:80/)
ftp: Error retrieving file: 500 Internal error
&gt;&gt; Attempting to fetch from ftp://wuarchive.wustl.edu/systems/gnu//.
Requesting ftp://wuarchive.wustl.edu/systems/gnu//bison-1.25.tar.gz (via ftp://orpheus.amdahl.com:80/)
ftp: Error retrieving file: 500 Internal error
&gt;&gt; Attempting to fetch from ftp://ftp.freebsd.org/pub/FreeBSD/distfiles//.
Requesting ftp://ftp.freebsd.org/pub/FreeBSD/distfiles//bison-1.25.tar.gz (via ftp://orpheus.amdahl.com:80/)
Successfully retrieved file.
</pre>
<p>Generate the checksum of the distfile into <code class=
"filename">distinfo</code>:</p>
<pre class="screen">
<code class="prompt">#</code> <strong class=
"userinput"><code>make makesum</code></strong>
</pre>
<p>Now compile:</p>
<pre class="screen">
<code class="prompt">#</code> <strong class=
"userinput"><code>make</code></strong>
&gt;&gt; Checksum OK for bison-1.25.tar.gz.
===&gt; Extracting for bison-1.25
===&gt; Patching for bison-1.25
===&gt; Ignoring empty patch directory
===&gt; Configuring for bison-1.25
creating cache ./config.cache
checking for gcc... cc
checking whether we are using GNU C... yes
checking for a BSD compatible install... /usr/bin/install -c -o bin -g bin
checking how to run the C preprocessor... cc -E
checking for minix/config.h... no
checking for POSIXized ISC... no
checking whether cross-compiling... no
checking for ANSI C header files... yes
checking for string.h... yes
checking for stdlib.h... yes
checking for memory.h... yes
checking for working const... yes
checking for working alloca.h... no
checking for alloca... yes
checking for strerror... yes
updating cache ./config.cache
creating ./config.status
creating Makefile
===&gt; Building for bison-1.25
cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include -g LR0.c
cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include -g allocate.c
cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include -g closure.c
cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include -g conflicts.c
cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include -g derives.c
cc -c -DXPFILE=\"/usr/pkg/share/bison.simple\" -DXPFILE1=\"/usr/pkg/share/bison.hairy\" -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -g ./files.c
cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include -g getargs.c
cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include -g gram.c
cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include -g lalr.c
cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include -g lex.c
cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include -g main.c
cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include -g nullable.c
cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include -g output.c
cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include -g print.c
cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include -g reader.c
cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include -g reduce.c
cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include -g symtab.c
cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include -g warshall.c
cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include -g version.c
cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include -g getopt.c
cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include -g getopt1.c
cc -g -o bison LR0.o allocate.o closure.o conflicts.o derives.o files.o getargs.o gram.o lalr.o lex.o main.o nullable.o output.o print.o reader.o reduce.o symtab.o warshall.o version.o getopt.o getopt1.o
./files.c:240: warning: mktemp() possibly used unsafely, consider using mkstemp()
rm -f bison.s1
sed -e "/^#line/ s|bison|/usr/pkg/share/bison|" &lt; ./bison.simple &gt; bison.s1
</pre>
<p>Everything seems OK, so install the files:</p>
<pre class="screen">
<code class="prompt">#</code> <strong class=
"userinput"><code>make install</code></strong>
&gt;&gt; Checksum OK for bison-1.25.tar.gz.
===&gt; Installing for bison-1.25
sh ./mkinstalldirs /usr/pkg/bin /usr/pkg/share /usr/pkg/info /usr/pkg/man/man1
rm -f /usr/pkg/bin/bison
cd /usr/pkg/share; rm -f bison.simple bison.hairy
rm -f /usr/pkg/man/man1/bison.1 /usr/pkg/info/bison.info*
install -c -o bin -g bin -m 555 bison /usr/pkg/bin/bison
/usr/bin/install -c -o bin -g bin -m 644 bison.s1 /usr/pkg/share/bison.simple
/usr/bin/install -c -o bin -g bin -m 644 ./bison.hairy /usr/pkg/share/bison.hairy
cd .; for f in bison.info*; do /usr/bin/install -c -o bin -g bin -m 644 $f /usr/pkg/info/$f; done
/usr/bin/install -c -o bin -g bin -m 644 ./bison.1 /usr/pkg/man/man1/bison.1
===&gt; Registering installation for bison-1.25
</pre>
<p>You can now use bison, and also - if you decide so -
remove it with <span><strong class="command">pkg_delete
bison</strong></span>. Should you decide that you want a
binary package, do this now:</p>
<pre class="screen">
<code class="prompt">#</code> <strong class=
"userinput"><code>make package</code></strong>
&gt;&gt; Checksum OK for bison-1.25.tar.gz.
===&gt; Building package for bison-1.25
Creating package bison-1.25.tgz
Registering depends:.
Creating gzip'd tar ball in '/u/pkgsrc/lang/bison/bison-1.25.tgz'
</pre>
<p>Now that you don't need the source and object files any
more, clean up:</p>
<pre class="screen">
<code class="prompt">#</code> <strong class=
"userinput"><code>make clean</code></strong>
===&gt; Cleaning for bison-1.25
</pre>
</div>
</div>
<div class="appendix" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h2 class="title"><a name="logs" id=
"logs"></a>Appendix&nbsp;B.&nbsp;Build logs</h2>
</div>
</div>
</div>
<div class="toc">
<p><b>Table of Contents</b></p>
<dl>
<dt><span class="sect1"><a href="#logs.building">B.1.
Building figlet</a></span></dt>
<dt><span class="sect1"><a href="#logs.package">B.2.
Packaging figlet</a></span></dt>
</dl>
</div>
<div class="sect1" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h2 class="title" style="clear: both"><a name=
"logs.building" id=
"logs.building"></a>B.1.&nbsp;Building figlet</h2>
</div>
</div>
</div>
<pre class="screen">
<code class="prompt">#</code> <strong class=
"userinput"><code>make</code></strong>
===&gt; Checking for vulnerabilities in figlet-2.2.1nb2
=&gt; figlet221.tar.gz doesn't seem to exist on this system.
=&gt; Attempting to fetch figlet221.tar.gz from ftp://ftp.figlet.org/pub/figlet/program/unix/.
=&gt; [172219 bytes]
Connected to ftp.plig.net.
220 ftp.plig.org NcFTPd Server (licensed copy) ready.
331 Guest login ok, send your complete e-mail address as password.
230-You are user #5 of 500 simultaneous users allowed.
230-
230- ___ _ _ _
230- | _| |_ ___ ___| |_|___ ___ ___ ___
230- | _| _| . |_| . | | | . |_| . | _| . |
230- |_| |_| | _|_| _|_|_|_ |_|___|_| |_ |
230- |_| |_| |___| |___|
230-
230-** Welcome to ftp.plig.org **
230-
230-Please note that all transfers from this FTP site are logged. If you
230-do not like this, please disconnect now.
230-
230-This arhive is available via
230-
230-HTTP: http://ftp.plig.org/
230-FTP: ftp://ftp.plig.org/ (max 500 connections)
230-RSYNC: rsync://ftp.plig.org/ (max 30 connections)
230-
230-Please email comments, bug reports and requests for packages to be
230-mirrored to ftp-admin@plig.org.
230-
230-
230 Logged in anonymously.
Remote system type is UNIX.
Using binary mode to transfer files.
200 Type okay.
250 "/pub" is new cwd.
250-"/pub/figlet" is new cwd.
250-
250-Welcome to the figlet archive at ftp.figlet.org
250-
250- ftp://ftp.figlet.org/pub/figlet/
250-
250-The official FIGlet web page is:
250- http://www.figlet.org/
250-
250-If you have questions, please mailto:info@figlet.org. If you want to
250-contribute a font or something else, you can email us.
250
250 "/pub/figlet/program" is new cwd.
250 "/pub/figlet/program/unix" is new cwd.
local: figlet221.tar.gz remote: figlet221.tar.gz
502 Unimplemented command.
227 Entering Passive Mode (195,40,6,41,246,104)
150 Data connection accepted from 84.128.86.72:65131; transfer starting for figlet221.tar.gz (172219 bytes).
38% |************** | 65800 64.16 KB/s 00:01 ETA
226 Transfer completed.
172219 bytes received in 00:02 (75.99 KB/s)
221 Goodbye.
=&gt; Checksum OK for figlet221.tar.gz.
===&gt; Extracting for figlet-2.2.1nb2
===&gt; Required installed package ccache-[0-9]*: ccache-2.3nb1 found
===&gt; Patching for figlet-2.2.1nb2
===&gt; Applying pkgsrc patches for figlet-2.2.1nb2
===&gt; Overriding tools for figlet-2.2.1nb2
===&gt; Creating toolchain wrappers for figlet-2.2.1nb2
===&gt; Configuring for figlet-2.2.1nb2
===&gt; Building for figlet-2.2.1nb2
gcc -O2 -DDEFAULTFONTDIR=\"/usr/pkg/share/figlet\" -DDEFAULTFONTFILE=\"standard.flf\" figlet.c zipio.c crc.c inflate.c -o figlet
chmod a+x figlet
gcc -O2 -o chkfont chkfont.c
=&gt; Unwrapping files-to-be-installed.
<code class="prompt">#</code>
<code class="prompt">#</code> <strong class=
"userinput"><code>make install</code></strong>
===&gt; Checking for vulnerabilities in figlet-2.2.1nb2
===&gt; Installing for figlet-2.2.1nb2
install -d -o root -g wheel -m 755 /usr/pkg/bin
install -d -o root -g wheel -m 755 /usr/pkg/man/man6
mkdir -p /usr/pkg/share/figlet
cp figlet /usr/pkg/bin
cp chkfont /usr/pkg/bin
chmod 555 figlist showfigfonts
cp figlist /usr/pkg/bin
cp showfigfonts /usr/pkg/bin
cp fonts/*.flf /usr/pkg/share/figlet
cp fonts/*.flc /usr/pkg/share/figlet
cp figlet.6 /usr/pkg/man/man6
===&gt; Registering installation for figlet-2.2.1nb2
<code class="prompt">#</code>
</pre>
</div>
<div class="sect1" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h2 class="title" style="clear: both"><a name=
"logs.package" id=
"logs.package"></a>B.2.&nbsp;Packaging figlet</h2>
</div>
</div>
</div>
<pre class="screen">
<code class="prompt">#</code> <strong class=
"userinput"><code>make package</code></strong>
===&gt; Checking for vulnerabilities in figlet-2.2.1nb2
===&gt; Packaging figlet-2.2.1nb2
===&gt; Building binary package for figlet-2.2.1nb2
Creating package /home/cvs/pkgsrc/packages/i386/All/figlet-2.2.1nb2.tgz
Using SrcDir value of /usr/pkg
Registering depends:.
<code class="prompt">#</code>
</pre>
</div>
</div>
<div class="appendix" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h2 class="title"><a name="ftp-layout" id=
"ftp-layout"></a>Appendix&nbsp;C.&nbsp;Layout of the
FTP server's package archive</h2>
</div>
</div>
</div>
<p>Layout for precompiled binary packages on
ftp.NetBSD.org:</p>
<pre class="programlisting">
/pub/NetBSD/packages/
distfiles/
# Unpacked pkgsrc trees
pkgsrc-current -&gt; /pub/NetBSD/NetBSD-current/pkgsrc
pkgsrc-2003Q4 -&gt; N/A
pkgsrc-2004Q1/pkgsrc
# pkgsrc archives
pkgsrc-current.tar.gz -&gt; ../NetBSD-current/tar_files/pkgsrc.tar.gz
pkgsrc-2003Q4.tar.gz -&gt; N/A
pkgsrc-2004Q1.tar.gz -&gt; N/A
# Per pkgsrc-release/OS-release/arch package archives
pkgsrc-2003Q4/
NetBSD-1.6.2/
i386/
All/
archivers/
foo -&gt; ../All/foo
...
pkgsrc-2004Q1/
NetBSD-1.6.2/
i386/
All/
...
NetBSD-2.0/
i386/
All/
...
SunOS-5.9/
sparc/
All/
...
x86/
All/
...
# Per os-release package archive convenience links
NetBSD-1.6.2 -&gt; 1.6.2
1.6.2/
i386 -&gt; ../pkgsrc-2004Q1/NetBSD-1.6.2/i386
m68k/
All/
archivers/
foo -&gt; ../All/foo
...
amiga -&gt; m68k
atari -&gt; m68k
...
2.0 -&gt; NetBSD-2.0 # backward compat, historic
NetBSD-2.0/
i386 -&gt; ../pkgsrc-2004Q1/NetBSD-2.0/i386
SunOS-5.9/
sparc -&gt; ../pkgsrc-2004Q1/SunOS-5.9/sparc
x86 -&gt; ../pkgsrc-2004Q1/SunOS-5.9/x86
</pre>
<p>To create:</p>
<div class="orderedlist">
<ol type="1">
<li>
<p>Run bulk build, see <a href="#bulkbuild" title=
"5.3.&nbsp;Doing a bulk build of all packages">Section
5.3, &#8220;Doing a bulk build of all
packages&#8221;</a></p>
</li>
<li>
<p>Upload /usr/pkgsrc/packages to</p>
<pre class="programlisting">
ftp://ftp.NetBSD.org/pub/NetBSD/packages/\
pkgsrc-2004Q4/\ # pkgsrc-branch
`uname -s`-`uname -r`/ # OS &amp; version
`uname -p` # architecture
</pre>
</li>
<li>
<p>If necessary, create a symlink <span><strong class=
"command">ln -s `uname -m` `uname -p`</strong></span>
(amiga -&gt; m68k, ...)</p>
</li>
</ol>
</div>
</div>
<div class="appendix" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h2 class="title"><a name="editing" id=
"editing"></a>Appendix&nbsp;D.&nbsp;Editing guidelines
for the pkgsrc guide</h2>
</div>
</div>
</div>
<div class="toc">
<p><b>Table of Contents</b></p>
<dl>
<dt><span class="sect1"><a href="#id2595975">D.1.
Targets</a></span></dt>
<dt><span class="sect1"><a href="#id2596387">D.2.
Procedure</a></span></dt>
</dl>
</div>
<p>This section contains information on editing the pkgsrc
guide itself.</p>
<div class="sect1" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h2 class="title" style="clear: both"><a name=
"id2595975" id="id2595975"></a>D.1.&nbsp;Targets</h2>
</div>
</div>
</div>
<p>The pkgsrc guide's source code is stored in <code class=
"filename">pkgsrc/doc/guide/files</code>, and several files
are created from it:</p>
<div class="itemizedlist">
<ul type="disc">
<li>
<p><code class=
"filename">pkgsrc/doc/pkgsrc.txt</code>, which
replaces <code class=
"filename">pkgsrc/Packages.txt</code></p>
</li>
<li>
<p><code class=
"filename">pkgsrc/doc/pkgsrc.html</code></p>
</li>
<li>
<p><code class=
"filename">http://www.NetBSD.org/Documentation/pkgsrc/</code>:
the documentation on the NetBSD website will be built
from pkgsrc and kept up to date on the web server
itself. This means you <span class=
"emphasis"><em>must</em></span> make sure that your
changes haven't broken the build!</p>
</li>
<li>
<p><code class=
"filename">http://www.NetBSD.org/Documentation/pkgsrc/pkgsrc.pdf</code>:
PDF version of the pkgsrc guide.</p>
</li>
<li>
<p><code class=
"filename">http://www.NetBSD.org/Documentation/pkgsrc/pkgsrc.ps</code>:
PostScript version of the pkgsrc guide.</p>
</li>
</ul>
</div>
</div>
<div class="sect1" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h2 class="title" style="clear: both"><a name=
"id2596387" id=
"id2596387"></a>D.2.&nbsp;Procedure</h2>
</div>
</div>
</div>
<p>The procedure to edit the pkgsrc guide is:</p>
<div class="itemizedlist">
<ul type="disc">
<li>
<p>Make sure you have the packages needed to
re-generate the pkgsrc guide (and other XML-based
NetBSD documentation) installed. These are
&#8220;<span class="quote">netbsd-doc</span>&#8221;
for creating the ASCII- and HTML-version, and
&#8220;<span class=
"quote">netbsd-doc-print</span>&#8221;for the
PostScript- and PDF version. You will need both
packages installed, to make sure documentation is
consistent across all formats. The packages can be
found in <code class=
"filename">pkgsrc/meta-pkgs/netbsd-doc</code> and
<code class=
"filename">pkgsrc/meta-pkgs/netbsd-doc-print</code>.</p>
</li>
<li>
<p>Edit the XML file(s) in <code class=
"filename">pkgsrc/doc/guide/files</code>.</p>
</li>
<li>
<p>Run <span><strong class="command">make extract
&amp;&amp; make do-lint</strong></span> in
<code class="filename">pkgsrc/doc/guide</code> to
check the XML syntax, and fix it if needed.</p>
</li>
<li>
<p>Run <span><strong class=
"command">make</strong></span> in <code class=
"filename">pkgsrc/doc/guide</code> to build the HTML
and ASCII version.</p>
</li>
<li>
<p>If all is well, run <span><strong class=
"command">make install-doc</strong></span> to put the
generated files into <code class=
"filename">pkgsrc/doc</code>.</p>
</li>
<li>
<p><span><strong class="command">cvs commit
pkgsrc/doc/guide/files</strong></span></p>
</li>
<li>
<p><span><strong class="command">cvs commit -m
re-generate
pkgsrc/doc/pkgsrc.{html,txt}</strong></span></p>
</li>
<li>
<p>Until the webserver on www.NetBSD.org is really
updated automatically to pick up changes to the
pkgsrc guide automatically, also run
<span><strong class="command">make install-htdoc
HTDOCSDIR=../../../htdocs</strong></span> (or
similar, adjust <code class=
"varname">HTDOCSDIR</code>!).</p>
</li>
<li>
<p><span><strong class="command">cvs commit
htdocs/Documentation/pkgsrc</strong></span></p>
</li>
</ul>
</div>
</div>
</div>
</div>
</body>
</html>