pkgsrc/doc/pkgsrc.html

10989 lines
432 KiB
HTML
Raw Normal View History

<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta name="generator" content=
2004-10-22 02:27:55 +02:00
"HTML Tidy for NetBSD (vers 1st October 2003), 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.65.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>
2004-10-22 02:27:55 +02:00
<h1 class="title"><a name="id2526935" id=
"id2526935"></a>The pkgsrc guide</h1>
</div>
<div>
2004-10-22 02:27:55 +02:00
<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><tt class="email">&lt;<a href=
"mailto:agc@NetBSD.org">agc@NetBSD.org</a>&gt;</tt></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><tt class="email">&lt;<a href=
"mailto:hubertf@NetBSD.org">hubertf@NetBSD.org</a>&gt;</tt></p>
</div>
</div>
</div>
2004-10-22 02:27:55 +02:00
2004-11-02 14:29:15 +01:00
<h3 class="corpauthor">The pkgsrc Developers</h3>
</div>
</div>
<div>
<p class="copyright">Copyright &#169; 1994-2004 The
NetBSD Foundation, Inc</p>
</div>
<div>
2004-11-02 14:29:15 +01:00
<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>
2004-10-22 02:27:55 +02:00
<dt><span class="sect1"><a href="#id2494406">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>
2004-10-22 02:27:55 +02:00
<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>
2004-11-02 14:29:15 +01:00
<dt><span class="sect1"><a href="#id2495052">2.1.
As tar file</a></span></dt>
2004-11-02 14:29:15 +01:00
<dt><span class="sect1"><a href="#id2495069">2.2.
Via SUP</a></span></dt>
2004-11-02 14:29:15 +01:00
<dt><span class="sect1"><a href="#id2495101">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>
2004-11-02 14:29:15 +01:00
<dt><span class="sect1"><a href="#id2495211">3.1.
Bootstrapping pkgsrc</a></span></dt>
2004-11-02 14:29:15 +01:00
<dt><span class="sect1"><a href="#id2495318">3.2.
Platform specific notes</a></span></dt>
<dd>
<dl>
<dt><span class="sect2"><a href=
2004-11-02 14:29:15 +01:00
"#id2495324">3.2.1. Darwin (Mac OS
X)</a></span></dt>
<dt><span class="sect2"><a href=
2004-11-02 14:29:15 +01:00
"#id2495623">3.2.2. FreeBSD</a></span></dt>
<dt><span class="sect2"><a href=
2004-11-02 14:29:15 +01:00
"#id2496272">3.2.3. Interix</a></span></dt>
<dt><span class="sect2"><a href=
2004-11-02 14:29:15 +01:00
"#id2496362">3.2.4. IRIX</a></span></dt>
<dt><span class="sect2"><a href=
2004-11-02 14:29:15 +01:00
"#id2496480">3.2.5. OpenBSD</a></span></dt>
<dt><span class="sect2"><a href=
2004-11-02 14:29:15 +01:00
"#id2496660">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=
2004-11-02 14:29:15 +01:00
"#id2496865">4.1.1. Where to get binary
packages</a></span></dt>
<dt><span class="sect2"><a href=
2004-11-02 14:29:15 +01:00
"#id2496905">4.1.2. How to use binary
packages</a></span></dt>
<dt><span class="sect2"><a href=
2004-11-02 14:29:15 +01:00
"#id2497040">4.1.3. A word of
warning</a></span></dt>
</dl>
</dd>
2004-11-02 14:29:15 +01:00
<dt><span class="sect1"><a href="#id2497051">4.2.
Building packages from source</a></span></dt>
<dd>
<dl>
<dt><span class="sect2"><a href=
2004-11-02 14:29:15 +01:00
"#id2497129">4.2.1.
Requirements</a></span></dt>
<dt><span class="sect2"><a href=
2004-11-02 14:29:15 +01:00
"#id2497149">4.2.2. Fetching
distfiles</a></span></dt>
<dt><span class="sect2"><a href=
2004-11-02 14:29:15 +01:00
"#id2497202">4.2.3. How to build and
install</a></span></dt>
<dt><span class="sect2"><a href=
2004-11-02 14:29:15 +01:00
"#id2498133">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>
2004-11-02 14:29:15 +01:00
<dt><span class="sect1"><a href="#id2563004">5.1.
Building a single binary package</a></span></dt>
2004-11-02 14:29:15 +01:00
<dt><span class="sect1"><a href="#id2563082">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=
2004-11-02 14:29:15 +01:00
"#id2563222">5.3.2. Other environmental
considerations</a></span></dt>
<dt><span class="sect2"><a href=
2004-11-02 14:29:15 +01:00
"#id2563262">5.3.3. Operation</a></span></dt>
<dt><span class="sect2"><a href=
2004-11-02 14:29:15 +01:00
"#id2563469">5.3.4. What it
does</a></span></dt>
<dt><span class="sect2"><a href=
2004-11-02 14:29:15 +01:00
"#id2563526">5.3.5. Disk space
requirements</a></span></dt>
<dt><span class="sect2"><a href=
2004-11-02 14:29:15 +01:00
"#id2563553">5.3.6. Setting up a sandbox for
chroot'ed builds</a></span></dt>
<dt><span class="sect2"><a href=
2004-11-02 14:29:15 +01:00
"#id2563916">5.3.7. Building a partial set of
packages</a></span></dt>
</dl>
</dd>
2004-11-02 14:29:15 +01:00
<dt><span class="sect1"><a href="#id2564027">5.4.
Creating a multiple CD-ROM packages
collection</a></span></dt>
<dd>
<dl>
<dt><span class="sect2"><a href=
2004-11-02 14:29:15 +01:00
"#id2564042">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>
2004-11-02 14:29:15 +01:00
<dt><span class="sect1"><a href="#id2564301">6.1.
Is there a mailing list for pkg-related
discussion?</a></span></dt>
2004-11-02 14:29:15 +01:00
<dt><span class="sect1"><a href="#id2564331">6.2.
Where's the pkgviews documentation?</a></span></dt>
2004-11-02 14:29:15 +01:00
<dt><span class="sect1"><a href="#id2564344">6.3.
Utilities for package management
(pkgtools)</a></span></dt>
2004-11-02 14:29:15 +01:00
<dt><span class="sect1"><a href="#id2564501">6.4.
How to use pkgsrc as non-root</a></span></dt>
2004-11-02 14:29:15 +01:00
<dt><span class="sect1"><a href="#id2564581">6.5.
How can I install/use XFree86 from
pkgsrc?</a></span></dt>
2004-11-02 14:29:15 +01:00
<dt><span class="sect1"><a href="#id2564609">6.6.
How can I install/use X.org from
pkgsrc?</a></span></dt>
2004-11-02 14:29:15 +01:00
<dt><span class="sect1"><a href="#id2564636">6.7.
How to fetch files from behind a
firewall</a></span></dt>
2004-11-02 14:29:15 +01:00
<dt><span class="sect1"><a href="#id2564650">6.8.
How do I tell make fetch to do passive
FTP?</a></span></dt>
2004-11-02 14:29:15 +01:00
<dt><span class="sect1"><a href="#id2564701">6.9.
How to fetch all distfiles at once</a></span></dt>
2004-11-02 14:29:15 +01:00
<dt><span class="sect1"><a href="#id2564978">6.10.
What does Don't know how to make
/usr/share/tmac/tmac.andoc mean?</a></span></dt>
2004-11-02 14:29:15 +01:00
<dt><span class="sect1"><a href="#id2565016">6.11.
What does Could not find bsd.own.mk
mean?</a></span></dt>
2004-11-02 14:29:15 +01:00
<dt><span class="sect1"><a href="#id2565074">6.12.
Using 'sudo' with pkgsrc</a></span></dt>
<dt><span class="sect1"><a href="#faq.conf">6.13.
Configuration files handling and
placement</a></span></dt>
<dt><span class="sect1"><a href=
"#audit-packages">6.14. Automated security
checks</a></span></dt>
</dl>
</dd>
</dl>
</dd>
2004-10-22 02:27:55 +02:00
<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.
Makefile</a></span></dt>
<dt><span class="sect1"><a href=
"#components.distinfo">7.2.
distinfo</a></span></dt>
<dt><span class="sect1"><a href=
"#components.patches">7.3.
patches/*</a></span></dt>
2004-11-02 14:29:15 +01:00
<dt><span class="sect1"><a href="#id2566249">7.4.
Other mandatory files</a></span></dt>
<dt><span class="sect1"><a href=
"#components.optional">7.5. Optional
files</a></span></dt>
2004-11-02 14:29:15 +01:00
<dt><span class="sect1"><a href="#id2566443">7.6.
work*</a></span></dt>
2004-11-02 14:29:15 +01:00
<dt><span class="sect1"><a href="#id2566531">7.7.
files/*</a></span></dt>
</dl>
</dd>
<dt><span class="chapter"><a href="#plist">8. PLIST
issues</a></span></dt>
<dd>
<dl>
2004-11-02 14:29:15 +01:00
<dt><span class="sect1"><a href="#id2566585">8.1.
RCS ID</a></span></dt>
2004-11-02 14:29:15 +01:00
<dt><span class="sect1"><a href="#id2566600">8.2.
Semi-automatic PLIST generation</a></span></dt>
<dt><span class="sect1"><a href="#print-PLIST">8.3.
Tweaking output of make print-PLIST</a></span></dt>
<dt><span class="sect1"><a href="#plist.misc">8.4.
Variable substitution in PLIST</a></span></dt>
2004-11-02 14:29:15 +01:00
<dt><span class="sect1"><a href="#id2566921">8.5.
Manpage-compression</a></span></dt>
2004-11-02 14:29:15 +01:00
<dt><span class="sect1"><a href="#id2566963">8.6.
Changing PLIST source with
PLIST_SRC</a></span></dt>
2004-11-02 14:29:15 +01:00
<dt><span class="sect1"><a href="#id2566980">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>
2004-11-02 14:29:15 +01:00
<dt><span class="sect1"><a href="#id2567252">9.1.
Converting packages to use
buildlink3</a></span></dt>
2004-11-02 14:29:15 +01:00
<dt><span class="sect1"><a href="#id2567579">9.2.
Writing buildlink3.mk files</a></span></dt>
<dd>
<dl>
<dt><span class="sect2"><a href=
2004-11-02 14:29:15 +01:00
"#id2567717">9.2.1. Anatomy of a buildlink3.mk
file</a></span></dt>
<dt><span class="sect2"><a href=
2004-11-02 14:29:15 +01:00
"#id2568157">9.2.2. Updating
BUILDLINK_DEPENDS.pkg in buildlink3.mk
files</a></span></dt>
</dl>
</dd>
2004-11-02 14:29:15 +01:00
<dt><span class="sect1"><a href="#id2568236">9.3.
Writing builtin.mk files</a></span></dt>
<dd>
<dl>
<dt><span class="sect2"><a href=
2004-11-02 14:29:15 +01:00
"#id2568386">9.3.1. Anatomy of a builtin.mk
file</a></span></dt>
<dt><span class="sect2"><a href=
2004-11-02 14:29:15 +01:00
"#id2568613">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>
2004-11-02 14:29:15 +01:00
<dt><span class="sect1"><a href="#id2568685">10.1.
Global default options</a></span></dt>
2004-11-02 14:29:15 +01:00
<dt><span class="sect1"><a href="#id2568700">10.2.
Converting packages to use
bsd.options.mk</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>
2004-11-02 14:29:15 +01:00
<dt><span class="sect1"><a href="#id2569445">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>
2004-11-02 14:29:15 +01:00
<dt><span class="sect1"><a href="#id2570842">12.1.
General operation</a></span></dt>
<dd>
<dl>
<dt><span class="sect2"><a href=
2004-11-02 14:29:15 +01:00
"#id2570845">12.1.1. How to pull in variables
from /etc/mk.conf</a></span></dt>
<dt><span class="sect2"><a href=
2004-11-02 14:29:15 +01:00
"#id2570929">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=
2004-11-02 14:29:15 +01:00
"#id2571444">12.1.4. Handling conflicts with
other packages</a></span></dt>
<dt><span class="sect2"><a href=
2004-11-02 14:29:15 +01:00
"#id2571494">12.1.5. Packages that cannot or
should not be built</a></span></dt>
<dt><span class="sect2"><a href=
2004-11-02 14:29:15 +01:00
"#id2571520">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=
2004-11-02 14:29:15 +01:00
"#id2571611">12.1.8. How to handle compiler
bugs</a></span></dt>
<dt><span class="sect2"><a href=
2004-11-02 14:29:15 +01:00
"#id2571634">12.1.9. How to handle incrementing
versions when fixing an existing
package</a></span></dt>
<dt><span class="sect2"><a href=
2004-11-02 14:29:15 +01:00
"#id2571751">12.1.10. Portability of
packages</a></span></dt>
</dl>
</dd>
2004-11-02 14:29:15 +01:00
<dt><span class="sect1"><a href="#id2571776">12.2.
Possible downloading issues</a></span></dt>
<dd>
<dl>
<dt><span class="sect2"><a href=
2004-11-02 14:29:15 +01:00
"#id2571779">12.2.1. Packages whose distfiles
aren't available for plain
downloading</a></span></dt>
<dt><span class="sect2"><a href=
2004-11-02 14:29:15 +01:00
"#id2571978">12.2.2. How to handle modified
distfiles with the 'old' name</a></span></dt>
</dl>
</dd>
2004-11-02 14:29:15 +01:00
<dt><span class="sect1"><a href="#id2571990">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=
2004-11-02 14:29:15 +01:00
"#id2572397">12.3.2. Using libtool on GNU
packages that already support
libtool</a></span></dt>
<dt><span class="sect2"><a href=
2004-11-02 14:29:15 +01:00
"#id2572482">12.3.3. GNU
Autoconf/Automake</a></span></dt>
</dl>
</dd>
2004-11-02 14:29:15 +01:00
<dt><span class="sect1"><a href="#id2572526">12.4.
Building considerations</a></span></dt>
<dd>
<dl>
<dt><span class="sect2"><a href=
2004-11-02 14:29:15 +01:00
"#id2572530">12.4.1. CPP
defines</a></span></dt>
</dl>
</dd>
2004-11-02 14:29:15 +01:00
<dt><span class="sect1"><a href="#id2572560">12.5.
Package specific actions</a></span></dt>
<dd>
<dl>
<dt><span class="sect2"><a href=
2004-11-02 14:29:15 +01:00
"#id2572563">12.5.1. Package configuration
files</a></span></dt>
<dt><span class="sect2"><a href=
2004-11-02 14:29:15 +01:00
"#id2572733">12.5.2. User
2004-10-22 02:27:55 +02:00
interaction</a></span></dt>
<dt><span class="sect2"><a href=
2004-11-02 14:29:15 +01:00
"#id2572778">12.5.3. Handling
licenses</a></span></dt>
<dt><span class="sect2"><a href=
2004-11-02 14:29:15 +01:00
"#id2572861">12.5.4. Creating an account from a
package</a></span></dt>
<dt><span class="sect2"><a href=
2004-11-02 14:29:15 +01:00
"#id2572992">12.5.5. Installing score
files</a></span></dt>
<dt><span class="sect2"><a href=
2004-11-02 14:29:15 +01:00
"#id2573035">12.5.6. Packages providing login
shells</a></span></dt>
<dt><span class="sect2"><a href=
2004-11-02 14:29:15 +01:00
"#id2573161">12.5.7. Packages containing perl
scripts</a></span></dt>
<dt><span class="sect2"><a href=
2004-11-02 14:29:15 +01:00
"#id2573248">12.5.8. Packages with hardcoded
paths to other interpreters</a></span></dt>
<dt><span class="sect2"><a href=
2004-11-02 14:29:15 +01:00
"#id2573269">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=
2004-11-02 14:29:15 +01:00
"#id2573557">12.5.11. Packages installing
GConf2 data files</a></span></dt>
<dt><span class="sect2"><a href=
2004-11-02 14:29:15 +01:00
"#id2573657">12.5.12. Packages installing
scrollkeeper data files</a></span></dt>
<dt><span class="sect2"><a href=
2004-11-02 14:29:15 +01:00
"#id2573708">12.5.13. Packages installing X11
fonts</a></span></dt>
<dt><span class="sect2"><a href=
2004-11-02 14:29:15 +01:00
"#id2573824">12.5.14. Packages installing GTK2
modules</a></span></dt>
<dt><span class="sect2"><a href=
2004-11-02 14:29:15 +01:00
"#id2573893">12.5.15. Packages installing SGML
or XML data</a></span></dt>
<dt><span class="sect2"><a href=
2004-11-02 14:29:15 +01:00
"#id2573945">12.5.16. Packages installing
extensions to the MIME database</a></span></dt>
<dt><span class="sect2"><a href=
2004-11-02 14:29:15 +01:00
"#id2574016">12.5.17. Packages using
intltool</a></span></dt>
</dl>
</dd>
2004-11-02 14:29:15 +01:00
<dt><span class="sect1"><a href="#id2574029">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>
2004-11-02 14:29:15 +01:00
<dt><span class="sect1"><a href="#id2574491">14.1.
Submitting your packages</a></span></dt>
2004-11-02 14:29:15 +01:00
<dt><span class="sect1"><a href="#id2574538">14.2.
Committing: Importing a package into
CVS</a></span></dt>
2004-11-02 14:29:15 +01:00
<dt><span class="sect1"><a href="#id2574738">14.3.
2004-10-22 02:27:55 +02:00
Updating a package to a newer
version</a></span></dt>
2004-11-02 14:29:15 +01:00
<dt><span class="sect1"><a href="#id2574825">14.4.
2004-10-22 02:27:55 +02:00
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>
2004-11-02 14:29:15 +01:00
<dt><span class="sect1"><a href="#id2575051">A.1.
files</a></span></dt>
<dd>
<dl>
2004-11-02 14:29:15 +01:00
<dt><span class="sect2"><a href="#id2575054">A.1.1.
Makefile</a></span></dt>
2004-11-02 14:29:15 +01:00
<dt><span class="sect2"><a href="#id2575062">A.1.2.
DESCR</a></span></dt>
2004-11-02 14:29:15 +01:00
<dt><span class="sect2"><a href="#id2575077">A.1.3.
PLIST</a></span></dt>
2004-11-02 14:29:15 +01:00
<dt><span class="sect2"><a href="#id2575084">A.1.4.
Checking a package with pkglint</a></span></dt>
</dl>
</dd>
2004-11-02 14:29:15 +01:00
<dt><span class="sect1"><a href="#id2575193">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>
2004-10-22 02:27:55 +02:00
<dt><span class="appendix"><a href="#editing">D. Editing
guidelines for the pkgsrc guide</a></span></dt>
<dd>
<dl>
2004-11-02 14:29:15 +01:00
<dt><span class="sect1"><a href="#id2575976">D.1.
2004-10-22 02:27:55 +02:00
Targets</a></span></dt>
2004-11-02 14:29:15 +01:00
<dt><span class="sect1"><a href="#id2576025">D.2.
2004-10-22 02:27:55 +02:00
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>
2004-10-22 02:27:55 +02:00
<dt><span class="sect1"><a href="#id2494406">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=
2004-10-22 02:27:55 +02:00
"id2494406" id=
"id2494406"></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><b class="command">pkg_*</b></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"
2004-10-22 02:27:55 +02:00
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"
2004-10-22 02:27:55 +02:00
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"
2004-10-22 02:27:55 +02:00
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"
2004-10-22 02:27:55 +02:00
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>
2004-11-02 14:29:15 +01:00
<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>
2004-11-02 14:29:15 +01:00
<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=
2004-10-22 02:27:55 +02:00
"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=
2004-10-22 02:27:55 +02:00
"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 <tt class=
"filename">/usr/pkgsrc</tt>.</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 <tt class=
"filename">/usr/pkgsrc/distfiles</tt>.</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 <tt class=
"filename">.tgz</tt> file so it can be installed on
machines of the same machine architecture without the
need to recompile. Packages are usually generated in
<tt class="filename">/usr/pkgsrc/packages</tt>; 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 <tt class=
"prompt">#</tt> for root's shell prompt, and a <tt class=
"prompt">$</tt> 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=
2004-10-22 02:27:55 +02:00
"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>
2004-11-02 14:29:15 +01:00
<dt><span class="sect1"><a href="#id2495052">2.1. As
tar file</a></span></dt>
2004-11-02 14:29:15 +01:00
<dt><span class="sect1"><a href="#id2495069">2.2. Via
SUP</a></span></dt>
2004-11-02 14:29:15 +01:00
<dt><span class="sect1"><a href="#id2495101">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>
2004-11-02 14:29:15 +01:00
<dt><span class="sect1"><a href="#id2495211">3.1.
Bootstrapping pkgsrc</a></span></dt>
2004-11-02 14:29:15 +01:00
<dt><span class="sect1"><a href="#id2495318">3.2.
Platform specific notes</a></span></dt>
<dd>
<dl>
<dt><span class="sect2"><a href=
2004-11-02 14:29:15 +01:00
"#id2495324">3.2.1. Darwin (Mac OS
X)</a></span></dt>
<dt><span class="sect2"><a href=
2004-11-02 14:29:15 +01:00
"#id2495623">3.2.2. FreeBSD</a></span></dt>
<dt><span class="sect2"><a href=
2004-11-02 14:29:15 +01:00
"#id2496272">3.2.3. Interix</a></span></dt>
<dt><span class="sect2"><a href=
2004-11-02 14:29:15 +01:00
"#id2496362">3.2.4. IRIX</a></span></dt>
<dt><span class="sect2"><a href=
2004-11-02 14:29:15 +01:00
"#id2496480">3.2.5. OpenBSD</a></span></dt>
<dt><span class="sect2"><a href=
2004-11-02 14:29:15 +01:00
"#id2496660">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=
2004-11-02 14:29:15 +01:00
"#id2496865">4.1.1. Where to get binary
packages</a></span></dt>
<dt><span class="sect2"><a href=
2004-11-02 14:29:15 +01:00
"#id2496905">4.1.2. How to use binary
packages</a></span></dt>
<dt><span class="sect2"><a href=
2004-11-02 14:29:15 +01:00
"#id2497040">4.1.3. A word of
warning</a></span></dt>
</dl>
</dd>
2004-11-02 14:29:15 +01:00
<dt><span class="sect1"><a href="#id2497051">4.2.
Building packages from source</a></span></dt>
<dd>
<dl>
<dt><span class="sect2"><a href=
2004-11-02 14:29:15 +01:00
"#id2497129">4.2.1. Requirements</a></span></dt>
<dt><span class="sect2"><a href=
2004-11-02 14:29:15 +01:00
"#id2497149">4.2.2. Fetching
distfiles</a></span></dt>
<dt><span class="sect2"><a href=
2004-11-02 14:29:15 +01:00
"#id2497202">4.2.3. How to build and
install</a></span></dt>
<dt><span class="sect2"><a href=
2004-11-02 14:29:15 +01:00
"#id2498133">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>
2004-11-02 14:29:15 +01:00
<dt><span class="sect1"><a href="#id2563004">5.1.
Building a single binary package</a></span></dt>
2004-11-02 14:29:15 +01:00
<dt><span class="sect1"><a href="#id2563082">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=
2004-11-02 14:29:15 +01:00
"#id2563222">5.3.2. Other environmental
considerations</a></span></dt>
<dt><span class="sect2"><a href=
2004-11-02 14:29:15 +01:00
"#id2563262">5.3.3. Operation</a></span></dt>
<dt><span class="sect2"><a href=
2004-11-02 14:29:15 +01:00
"#id2563469">5.3.4. What it does</a></span></dt>
<dt><span class="sect2"><a href=
2004-11-02 14:29:15 +01:00
"#id2563526">5.3.5. Disk space
requirements</a></span></dt>
<dt><span class="sect2"><a href=
2004-11-02 14:29:15 +01:00
"#id2563553">5.3.6. Setting up a sandbox for
chroot'ed builds</a></span></dt>
<dt><span class="sect2"><a href=
2004-11-02 14:29:15 +01:00
"#id2563916">5.3.7. Building a partial set of
packages</a></span></dt>
</dl>
</dd>
2004-11-02 14:29:15 +01:00
<dt><span class="sect1"><a href="#id2564027">5.4.
Creating a multiple CD-ROM packages
collection</a></span></dt>
<dd>
<dl>
<dt><span class="sect2"><a href=
2004-11-02 14:29:15 +01:00
"#id2564042">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>
2004-11-02 14:29:15 +01:00
<dt><span class="sect1"><a href="#id2564301">6.1. Is
there a mailing list for pkg-related
discussion?</a></span></dt>
2004-11-02 14:29:15 +01:00
<dt><span class="sect1"><a href="#id2564331">6.2.
Where's the pkgviews documentation?</a></span></dt>
2004-11-02 14:29:15 +01:00
<dt><span class="sect1"><a href="#id2564344">6.3.
Utilities for package management
(pkgtools)</a></span></dt>
2004-11-02 14:29:15 +01:00
<dt><span class="sect1"><a href="#id2564501">6.4. How
to use pkgsrc as non-root</a></span></dt>
2004-11-02 14:29:15 +01:00
<dt><span class="sect1"><a href="#id2564581">6.5. How
can I install/use XFree86 from
pkgsrc?</a></span></dt>
2004-11-02 14:29:15 +01:00
<dt><span class="sect1"><a href="#id2564609">6.6. How
can I install/use X.org from pkgsrc?</a></span></dt>
2004-11-02 14:29:15 +01:00
<dt><span class="sect1"><a href="#id2564636">6.7. How
to fetch files from behind a firewall</a></span></dt>
2004-11-02 14:29:15 +01:00
<dt><span class="sect1"><a href="#id2564650">6.8. How
do I tell make fetch to do passive
FTP?</a></span></dt>
2004-11-02 14:29:15 +01:00
<dt><span class="sect1"><a href="#id2564701">6.9. How
to fetch all distfiles at once</a></span></dt>
2004-11-02 14:29:15 +01:00
<dt><span class="sect1"><a href="#id2564978">6.10.
What does Don't know how to make
/usr/share/tmac/tmac.andoc mean?</a></span></dt>
2004-11-02 14:29:15 +01:00
<dt><span class="sect1"><a href="#id2565016">6.11.
What does Could not find bsd.own.mk
mean?</a></span></dt>
2004-11-02 14:29:15 +01:00
<dt><span class="sect1"><a href="#id2565074">6.12.
Using 'sudo' with pkgsrc</a></span></dt>
<dt><span class="sect1"><a href="#faq.conf">6.13.
Configuration files handling and
placement</a></span></dt>
<dt><span class="sect1"><a href=
"#audit-packages">6.14. 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>
2004-11-02 14:29:15 +01:00
<dt><span class="sect1"><a href="#id2495052">2.1. As
tar file</a></span></dt>
2004-11-02 14:29:15 +01:00
<dt><span class="sect1"><a href="#id2495069">2.2. Via
SUP</a></span></dt>
2004-11-02 14:29:15 +01:00
<dt><span class="sect1"><a href="#id2495101">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=
2004-11-02 14:29:15 +01:00
"id2495052" id="id2495052"></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-current/tar_files/pkgsrc.tar.gz"
2004-10-22 02:27:55 +02:00
target="_top">ftp.NetBSD.org</a> and unpack it into
<tt class="filename">/usr/pkgsrc</tt>.</p>
</div>
<div class="sect1" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h2 class="title" style="clear: both"><a name=
2004-11-02 14:29:15 +01:00
"id2495069" id="id2495069"></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 <tt class=
"filename">/usr/share/examples/supfiles</tt>, and that
the <tt class="filename">/usr/pkgsrc</tt> directory
exists. Then, simply run <span><b class="command">sup -v
<i class=
"replaceable"><tt>/path/to/your/supfile</tt></i></b></span>.</p>
</div>
<div class="sect1" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h2 class="title" style="clear: both"><a name=
2004-11-02 14:29:15 +01:00
"id2495101" id="id2495101"></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">
<tt class="prompt">%</tt> <b class=
"userinput"><tt>setenv CVSROOT anoncvs@anoncvs.NetBSD.org:/cvsroot</tt></b>
<tt class="prompt">%</tt> <b class=
"userinput"><tt>setenv CVS_RSH ssh</tt></b>
<tt class="prompt">%</tt> <b class="userinput"><tt>cd /usr</tt></b>
<tt class="prompt">%</tt> <b class=
"userinput"><tt>cvs checkout -P pkgsrc</tt></b>
</pre>
<p>This will create the <tt class="filename">pkgsrc</tt>
directory in your <tt class="filename">/usr</tt>, and all
the package source will be stored under <tt class=
"filename">/usr/pkgsrc</tt>. To update pkgsrc after the
initial checkout, make sure you have <tt class=
"varname">CVS_RSH</tt> set as above, then do:</p>
<pre class="screen">
<tt class="prompt">%</tt> <b class=
"userinput"><tt>cd /usr/pkgsrc</tt></b>
<tt class="prompt">%</tt> <b class=
"userinput"><tt>cvs -q update -dP</tt></b>
</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>
2004-11-02 14:29:15 +01:00
<dt><span class="sect1"><a href="#id2495211">3.1.
Bootstrapping pkgsrc</a></span></dt>
2004-11-02 14:29:15 +01:00
<dt><span class="sect1"><a href="#id2495318">3.2.
Platform specific notes</a></span></dt>
<dd>
<dl>
2004-11-02 14:29:15 +01:00
<dt><span class="sect2"><a href="#id2495324">3.2.1.
Darwin (Mac OS X)</a></span></dt>
2004-11-02 14:29:15 +01:00
<dt><span class="sect2"><a href="#id2495623">3.2.2.
FreeBSD</a></span></dt>
2004-11-02 14:29:15 +01:00
<dt><span class="sect2"><a href="#id2496272">3.2.3.
Interix</a></span></dt>
2004-11-02 14:29:15 +01:00
<dt><span class="sect2"><a href="#id2496362">3.2.4.
IRIX</a></span></dt>
2004-11-02 14:29:15 +01:00
<dt><span class="sect2"><a href="#id2496480">3.2.5.
OpenBSD</a></span></dt>
2004-11-02 14:29:15 +01:00
<dt><span class="sect2"><a href="#id2496660">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=
2004-11-02 14:29:15 +01:00
"id2495211" id=
"id2495211"></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">
<tt class="prompt">#</tt> <b class=
"userinput"><tt>env CVS_RSH=ssh cvs -d anoncvs@anoncvs.NetBSD.org:/cvsroot checkout pkgsrc</tt></b>
<tt class="prompt">#</tt> <b class=
"userinput"><tt>cd pkgsrc/bootstrap</tt></b>
<tt class="prompt">#</tt> <b class=
"userinput"><tt>./bootstrap</tt></b>
</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><b class=
"command">bootstrap</b></span> command will use the
defaults of <tt class="filename">/usr/pkg</tt> for the
<span class="emphasis"><em>prefix</em></span> where
programs will be installed in, and <tt class=
"filename">/var/db/pkg</tt> 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=
2004-11-02 14:29:15 +01:00
"id2495318" id="id2495318"></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>
2004-11-02 14:29:15 +01:00
<h3 class="title"><a name="id2495324" id=
"id2495324"></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">
<tt class="prompt">#</tt> <b class=
"userinput"><tt>cd pkgsrc/bootstrap</tt></b>
<tt class="prompt">#</tt> <b class=
"userinput"><tt>./ufsdiskimage create ~/Documents/NetBSD 512</tt></b> # megabytes - season to taste
<tt class="prompt">#</tt> <b class=
"userinput"><tt>./ufsdiskimage mount ~/Documents/NetBSD</tt></b>
<tt class="prompt">#</tt> <b class=
"userinput"><tt>sudo chown `id -u`:`id -g` /Volumes/NetBSD</tt></b>
</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, <tt class="filename">/usr</tt> will be
on your root file system, normally HFS+. It is
possible to use the default <span class=
"emphasis"><em>prefix</em></span> of <tt class=
"filename">/usr/pkg</tt> by symlinking <tt class=
"filename">/usr/pkg</tt> 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">
<tt class="prompt">#</tt> <b class=
"userinput"><tt>./bootstrap --pkgdbdir=/usr/pkg/pkgdb --pkgsrcdir=/Volumes/ufs/pkgsrc</tt></b>
</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
<tt class="filename">/Volumes/&lt;volume
name&gt;</tt> 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>
2004-11-02 14:29:15 +01:00
<h3 class="title"><a name="id2495623" id=
"id2495623"></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
<tt class="filename">/var/db/pkg</tt>. It is
therefore recommended that you choose a different
location (e.g. <tt class=
"filename">/usr/pkgdb</tt>) 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">
<tt class="prompt">#</tt> <b class=
"userinput"><tt>cd /usr/sbin</tt></b>
<tt class="prompt">#</tt> <b class=
"userinput"><tt>mv pkg_add pkg_add.orig</tt></b>
<tt class="prompt">#</tt> <b class=
"userinput"><tt>mv pkg_create pkg_create.orig</tt></b>
<tt class="prompt">#</tt> <b class=
"userinput"><tt>mv pkg_delete pkg_delete.orig</tt></b>
<tt class="prompt">#</tt> <b class=
"userinput"><tt>mv pkg_info pkg_info.orig</tt></b>
</pre>
</li>
<li>
<p>An example <tt class=
"filename">/etc/mk.conf</tt> file will be placed
in <tt class="filename">/etc/mk.conf.example</tt>
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>
2004-11-02 14:29:15 +01:00
<h3 class="title"><a name="id2496272" id=
"id2496272"></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
2004-10-22 02:27:55 +02:00
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>
2004-11-02 14:29:15 +01:00
<h3 class="title"><a name="id2496362" id=
"id2496362"></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 <tt class="varname">CC</tt> 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 <tt class="varname">CFLAGS</tt> in your
environment or the <tt class=
"filename">/etc/mk.conf</tt>. Particularly, make sure
that you do not try to link n32 object files with lib64
or vice versa. Check your <tt class=
"filename">/etc/compiler.defaults</tt>!</p>
<p>If you have the actual pkgsrc tree mounted via NFS
from a different host, please make sure to set
<tt class="varname">WRKOBJDIR</tt> 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 <tt class=
"filename">pkgsrc/mk/bsd.pkg.defaults.mk</tt> and, of
course, your compilers man pages for details.</p>
</div>
<div class="sect2" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
2004-11-02 14:29:15 +01:00
<h3 class="title"><a name="id2496480" id=
"id2496480"></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
<tt class="filename">/var/db/pkg</tt>. It is
therefore recommended that you choose a different
location (e.g. <tt class=
"filename">/usr/pkgdb</tt>) 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">
<tt class="prompt">#</tt> <b class=
"userinput"><tt>cd /usr/sbin</tt></b>
<tt class="prompt">#</tt> <b class=
"userinput"><tt>mv pkg_add pkg_add.orig</tt></b>
<tt class="prompt">#</tt> <b class=
"userinput"><tt>mv pkg_create pkg_create.orig</tt></b>
<tt class="prompt">#</tt> <b class=
"userinput"><tt>mv pkg_delete pkg_delete.orig</tt></b>
<tt class="prompt">#</tt> <b class=
"userinput"><tt>mv pkg_info pkg_info.orig</tt></b>
</pre>
</li>
<li>
<p>An example <tt class=
"filename">/etc/mk.conf</tt> file will be placed
in <tt class="filename">/etc/mk.conf.example</tt>
file when you use the bootstrap script. OpenBSD's
make program uses <tt class=
"filename">/etc/mk.conf</tt> 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 bsd.pkg.defaults.mk 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>
2004-11-02 14:29:15 +01:00
<h3 class="title"><a name="id2496660" id=
"id2496660"></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>
2004-11-02 14:29:15 +01:00
<h4 class="title"><a name="id2496691" id=
"id2496691"></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"
2004-10-22 02:27:55 +02:00
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"
2004-10-22 02:27:55 +02:00
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>
2004-11-02 14:29:15 +01:00
<h4 class="title"><a name="id2496712" id=
"id2496712"></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 <tt class="varname">CC</tt>,
<tt class="varname">CXX</tt> and optionally,
<tt class="varname">CPP</tt> in <tt class=
"filename">/etc/mk.conf</tt>, 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
<tt class="varname">PATH</tt>. This includes
<tt class="filename">/usr/ccs/{bin,lib}</tt> and eg.
<tt class="filename">/usr/pkg/{bin,sbin}</tt>.</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>
2004-11-02 14:29:15 +01:00
<dt><span class="sect2"><a href="#id2496865">4.1.1.
Where to get binary packages</a></span></dt>
2004-11-02 14:29:15 +01:00
<dt><span class="sect2"><a href="#id2496905">4.1.2.
How to use binary packages</a></span></dt>
2004-11-02 14:29:15 +01:00
<dt><span class="sect2"><a href="#id2497040">4.1.3.
A word of warning</a></span></dt>
</dl>
</dd>
2004-11-02 14:29:15 +01:00
<dt><span class="sect1"><a href="#id2497051">4.2.
Building packages from source</a></span></dt>
<dd>
<dl>
2004-11-02 14:29:15 +01:00
<dt><span class="sect2"><a href="#id2497129">4.2.1.
Requirements</a></span></dt>
2004-11-02 14:29:15 +01:00
<dt><span class="sect2"><a href="#id2497149">4.2.2.
Fetching distfiles</a></span></dt>
2004-11-02 14:29:15 +01:00
<dt><span class="sect2"><a href="#id2497202">4.2.3.
How to build and install</a></span></dt>
2004-11-02 14:29:15 +01:00
<dt><span class="sect2"><a href="#id2498133">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>
2004-11-02 14:29:15 +01:00
<h3 class="title"><a name="id2496865" id=
"id2496865"></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 <tt class=
"filename">/pub/NetBSD/packages</tt> for anonymous FTP
access. Please pick the right subdirectory there as
indicated by <span><b class="command">uname
-p</b></span>. In that directory, there is a
subdirectory for each category plus a subdirectory
<tt class="filename">All</tt> which includes the actual
binaries in <tt class="filename">.tgz</tt> files. The
category subdirectories use symbolic links to those
files (this is the same directory layout as in
<tt class="filename">/usr/pkgsrc/packages</tt>).</p>
<p>This same directory layout applies for CDROM
distributions, only that the directory may be rooted
somewhere else, probably somewhere below <tt class=
"filename">/cdrom</tt>. Please consult your CDROMs
documentation for the exact location.</p>
</div>
<div class="sect2" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
2004-11-02 14:29:15 +01:00
<h3 class="title"><a name="id2496905" id=
"id2496905"></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><b class=
"command">su</b></span> to root first):</p>
<pre class="screen">
<tt class="prompt">#</tt> <b class=
"userinput"><tt>pkg_add /path/to/package.tgz</tt></b>
</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><b class=
"command">pkg_add</b></span> an FTP URL:</p>
<pre class="screen">
<tt class="prompt">#</tt> <b class=
"userinput"><tt>pkg_add ftp://ftp.NetBSD.org/pub/NetBSD/packages/&lt;OSvers&gt;/&lt;arch&gt;/All/package.tgz</tt></b>
</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><b class="command">uname
-rp</b></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
<tt class="filename">/usr/pkg/bin</tt> in your
<tt class="varname">PATH</tt> so you can actually start
the just installed program.</p>
</div>
<div class="sect2" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
2004-11-02 14:29:15 +01:00
<h3 class="title"><a name="id2497040" id=
"id2497040"></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=
2004-11-02 14:29:15 +01:00
"id2497051" id="id2497051"></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=
2004-10-22 02:27:55 +02:00
"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>
2004-11-02 14:29:15 +01:00
<h3 class="title"><a name="id2497129" id=
"id2497129"></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>
2004-11-02 14:29:15 +01:00
<h3 class="title"><a name="id2497149" id=
"id2497149"></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 <tt class=
"filename">pkgsrc/mk/bsd.pkg.defaults.mk</tt> to find
some examples - in particular, look for the <tt class=
"varname">MASTER_SORT</tt>, <tt class=
"varname">MASTER_SORT_REGEX</tt> and <tt class=
"varname">INET_COUNTRY</tt> 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 <tt class="filename">/etc/mk.conf</tt>
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><b class="command">make fetch-list</b></span>
will tell you what you'll need. Put these distfiles
into <tt class=
"filename">/usr/pkgsrc/distfiles</tt>.</p>
</div>
<div class="sect2" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
2004-11-02 14:29:15 +01:00
<h3 class="title"><a name="id2497202" id=
"id2497202"></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><b class=
"command">make</b></span>. For example, type</p>
<pre class="screen">
<tt class="prompt">%</tt> <b class=
"userinput"><tt>cd misc/figlet</tt></b>
<tt class="prompt">%</tt> <b class="userinput"><tt>make</tt></b>
</pre>
<p>at the shell prompt to build the various components
of the package, and</p>
<pre class="screen">
<tt class="prompt">#</tt> <b class=
"userinput"><tt>make install</tt></b>
</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 - <tt class="filename">/usr/pkg</tt>.
Should this not conform to your tastes, set the
<tt class="varname">LOCALBASE</tt> variable in your
environment, and it will use that value as the root of
your packages tree. So, to use <tt class=
"filename">/usr/local</tt>, set <tt class=
"varname">LOCALBASE=/usr/local</tt> 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 <tt class=
"varname">LOCALBASE=/usr</tt>). Also, you should not
try to add any of your own files or directories (such
as <tt class="filename">src/</tt>, <tt class=
"filename">obj/</tt>, or <tt class=
"filename">pkgsrc/</tt>) below the <tt class=
"varname">LOCALBASE</tt> 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 <tt class=
"filename">/etc/mk.conf</tt> to alter some
configuration options at build time. Have a look at
<tt class="filename">pkgsrc/mk/bsd.pkg.defaults.mk</tt>
to get an overview of what will be set there by
default. Environment variables such as <tt class=
"varname">LOCALBASE</tt> can be set in <tt class=
"filename">/etc/mk.conf</tt> 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 <tt class="varname">PKG_DEBUG_LEVEL=2</tt>,
then a huge amount of information will be
displayed. For example,</p>
<pre class="screen">
<b class="userinput"><tt>make patch PKG_DEBUG_LEVEL=2</tt></b>
</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 <tt class=
"varname">VARNAME</tt> 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 <tt class="varname">DISTFILES</tt>:</p>
<pre class="screen">
<tt class="prompt">%</tt> <b class=
"userinput"><tt>make show-var VARNAME=LOCALBASE</tt></b>
/usr/pkg
<tt class="prompt">%</tt>
</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 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><b class="command">make package</b></span>. The
list of remote FTP sites searched is kept in the
variable <tt class="varname">BINPKG_SITE</tt>, 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 <tt class="varname">BIN_INSTALL_FLAGS</tt>. See
<tt class="filename">pkgsrc/mk/bsd.pkg.defaults.mk</tt>
for more details.</p>
<p>A final word of warning: If you setup a system that
has a non-standard setting for <tt class=
"varname">LOCALBASE</tt>, 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 <tt class="varname">LOCALBASE</tt> of
<tt class="filename">/usr/pkg</tt>, and that you should
<span class="emphasis"><em>not</em></span> install any
if you use a non-standard <tt class=
"varname">LOCALBASE</tt>.</p>
</div>
<div class="sect2" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
2004-11-02 14:29:15 +01:00
<h3 class="title"><a name="id2498133" id=
"id2498133"></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"><tt class=
"varname">PKGSRC_COMPILER</tt>:</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><tt class="varname">distcc</tt>:
distributed C/C++ (chainable)</p>
</li>
<li>
<p><tt class="varname">ccache</tt>:
compiler cache (chainable)</p>
</li>
<li>
<p><tt class="varname">gcc</tt>: GNU C/C++
Compiler</p>
</li>
<li>
<p><tt class="varname">mipspro</tt>:
Silicon Graphics, Inc. MIPSpro
(n32/n64)</p>
</li>
<li>
<p><tt class="varname">mipspro</tt>:
Silicon Graphics, Inc. MIPSpro (o32)</p>
</li>
<li>
<p><tt class="varname">sunpro</tt>:
Microsystems, Inc. WorkShip/Forte/Sun ONE
Studio</p>
</li>
</ul>
</div>
<p>The default is &#8220;<span class=
"quote"><tt class=
"varname">gcc</tt></span>&#8221;. You can use
<tt class="varname">ccache</tt> and/or <tt class=
"varname">distcc</tt> with an appropriate
<tt class="varname">PKGSRC_COMPILER</tt> setting,
e.g. &#8220;<span class="quote"><tt class=
"varname">ccache gcc</tt></span>&#8221;. This
variable should always be terminated with a value
for a real compiler.</p>
</dd>
<dt><span class="term"><tt class=
"varname">GCC_REQD</tt>:</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>
2004-11-02 14:29:15 +01:00
<dt><span class="sect1"><a href="#id2563004">5.1.
Building a single binary package</a></span></dt>
2004-11-02 14:29:15 +01:00
<dt><span class="sect1"><a href="#id2563082">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>
2004-11-02 14:29:15 +01:00
<dt><span class="sect2"><a href="#id2563222">5.3.2.
Other environmental considerations</a></span></dt>
2004-11-02 14:29:15 +01:00
<dt><span class="sect2"><a href="#id2563262">5.3.3.
Operation</a></span></dt>
2004-11-02 14:29:15 +01:00
<dt><span class="sect2"><a href="#id2563469">5.3.4.
What it does</a></span></dt>
2004-11-02 14:29:15 +01:00
<dt><span class="sect2"><a href="#id2563526">5.3.5.
Disk space requirements</a></span></dt>
2004-11-02 14:29:15 +01:00
<dt><span class="sect2"><a href="#id2563553">5.3.6.
Setting up a sandbox for chroot'ed
builds</a></span></dt>
2004-11-02 14:29:15 +01:00
<dt><span class="sect2"><a href="#id2563916">5.3.7.
Building a partial set of packages</a></span></dt>
</dl>
</dd>
2004-11-02 14:29:15 +01:00
<dt><span class="sect1"><a href="#id2564027">5.4.
Creating a multiple CD-ROM packages
collection</a></span></dt>
<dd>
<dl>
2004-11-02 14:29:15 +01:00
<dt><span class="sect2"><a href="#id2564042">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=
2004-11-02 14:29:15 +01:00
"id2563004" id="id2563004"></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><b class=
"command">make package</b></span>:</p>
<pre class="screen">
<tt class="prompt">#</tt> <b class=
"userinput"><tt>cd misc/figlet</tt></b>
<tt class="prompt">#</tt> <b class=
"userinput"><tt>make package</tt></b>
</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><b class=
"command">pkg_*</b></span> tools to manipulate it. Binary
packages are created by default in <tt class=
"filename">/usr/pkgsrc/packages</tt>, 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"
2004-10-22 02:27:55 +02:00
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=
2004-11-02 14:29:15 +01:00
"id2563082" id="id2563082"></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 <tt class=
"filename">/etc/mk.conf</tt>. Look at <tt class=
"filename">pkgsrc/mk/bsd.pkg.defaults.mk</tt> for
details of the default settings. You will want to
ensure that <tt class=
"varname">ACCEPTABLE_LICENSES</tt> meet your local
policy. As used in this example, <tt class=
"varname">_ACCEPTABLE=yes</tt> 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>
2004-11-02 14:29:15 +01:00
<h4 class="title"><a name="id2563146" id=
"id2563146"></a>5.3.1.2.&nbsp;<tt class=
"filename">build.conf</tt></h4>
</div>
</div>
</div>
<p>In <tt class="filename">pkgsrc/mk/bulk</tt>, copy
<tt class="filename">build.conf-example</tt> to
<tt class="filename">build.conf</tt> 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><b class="command">cvs update</b></span>.</p>
</div>
<div class="sect3" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
2004-11-02 14:29:15 +01:00
<h4 class="title"><a name="id2563182" id=
"id2563182"></a>5.3.1.3.&nbsp;<tt class=
"filename">pre-build.local</tt></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 <tt class=
"filename">pre-build.local</tt> exists in <tt class=
"filename">/usr/pkgsrc/mk/bulk</tt> it will be
executed (as a sh(1) script) at the end of the usual
pre-build stage. An example use of <tt class=
"filename">pre-build.local</tt> is to have the
line:</p>
<pre class="screen">
<tt class="prompt">#</tt> <b class=
"userinput"><tt>echo "I do not have enough disk space to build this pig." \
&gt; pkgsrc/games/crafty-book-enormous/$BROKENF</tt></b>
</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>
2004-11-02 14:29:15 +01:00
<h3 class="title"><a name="id2563222" id=
"id2563222"></a>5.3.2.&nbsp;Other environmental
considerations</h3>
</div>
</div>
</div>
<p>As <tt class="filename">/usr/pkg</tt> will be
completely deleted at the start of bulk builds, make
sure your login shell is placed somewhere else. Either
drop it into <tt class="filename">/usr/local/bin</tt>
(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
<tt class="filename">/etc/rc.local</tt>, 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
<tt class="filename">rc.local</tt>:</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>
2004-11-02 14:29:15 +01:00
<h3 class="title"><a name="id2563262" id=
"id2563262"></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
<tt class="filename">/usr/local</tt>, etc. then become
root and type:</p>
<pre class="screen">
<tt class="prompt">#</tt> <b class=
"userinput"><tt>cd /usr/pkgsrc</tt></b>
<tt class="prompt">#</tt> <b class=
"userinput"><tt>sh mk/bulk/build</tt></b>
</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">
<tt class="prompt">#</tt> <b class=
"userinput"><tt>sh mk/bulk/build restart</tt></b>
</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 <tt class="varname">FTP</tt> in the
<tt class="filename">build.conf</tt> file.</p>
</div>
<div class="sect2" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
2004-11-02 14:29:15 +01:00
<h3 class="title"><a name="id2563469" id=
"id2563469"></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 <tt class=
"filename">build.conf</tt> file named <tt class=
"filename">broken.html</tt>, 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 <tt class=
"filename">/usr/pkgsrc/.broken</tt> (or <tt class=
"filename">.../.broken.${MACHINE}</tt> if <tt class=
"varname">OBJMACHINE</tt> 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>
2004-11-02 14:29:15 +01:00
<h3 class="title"><a name="id2563526" id=
"id2563526"></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>
2004-11-02 14:29:15 +01:00
<h3 class="title"><a name="id2563553" id=
"id2563553"></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 pkgs 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 to do so is setting up a chroot
sandbox, e.g. <tt class="filename">/usr/sandbox</tt>.
After extracting all the sets from a NetBSD
installation or doing a <span><b class="command">make
distribution DESTDIR=/usr/sandbox</b></span> in
<tt class="filename">/usr/src/etc</tt>, be sure the
following items are present and properly
configured:</p>
<div class="procedure">
<ol type="1">
<li>
<p>Kernel</p>
<pre class="screen">
<tt class="prompt">#</tt> <b class=
"userinput"><tt>cp /netbsd /usr/sandbox</tt></b>
</pre>
</li>
<li>
<p><tt class="filename">/dev/*</tt></p>
<pre class="screen">
<tt class="prompt">#</tt> <b class=
"userinput"><tt>cd /usr/sandbox/dev ; sh MAKEDEV all</tt></b>
</pre>
</li>
<li>
<p><tt class="filename">/etc/resolv.conf</tt>
(for <a xmlns=
"http://www.w3.org/TR/xhtml1/transitional" href=
"ftp://ftp.NetBSD.org/pub/NetBSD/packages/pkgsrc/security/smtpd/README.html"
2004-10-22 02:27:55 +02:00
class="pkgname">security/smtpd</a> and
mail):</p>
<pre class="screen">
<tt class="prompt">#</tt> <b class=
"userinput"><tt>cp /etc/resolv.conf /usr/sandbox/etc</tt></b>
</pre>
</li>
<li>
<p>Working(!) mail config (hostname,
sendmail.cf):</p>
<pre class="screen">
<tt class="prompt">#</tt> <b class=
"userinput"><tt>cp /etc/mail/sendmail.cf /usr/sandbox/etc/mail</tt></b>
</pre>
</li>
<li>
<p><tt class="filename">/etc/localtime</tt> (for
<a xmlns=
"http://www.w3.org/TR/xhtml1/transitional" href=
"ftp://ftp.NetBSD.org/pub/NetBSD/packages/pkgsrc/security/smtpd/README.html"
2004-10-22 02:27:55 +02:00
class="pkgname">security/smtpd</a>):</p>
<pre class="screen">
<tt class="prompt">#</tt> <b class=
"userinput"><tt>ln -sf /usr/share/zoneinfo/UTC /usr/sandbox/etc/localtime</tt></b>
</pre>
</li>
<li>
<p><tt class="filename">/usr/src</tt> (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"
2004-10-22 02:27:55 +02:00
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">
<tt class="prompt">#</tt> <b class=
"userinput"><tt>ln -s ../disk1/cvs .</tt></b>
<tt class="prompt">#</tt> <b class=
"userinput"><tt>ln -s cvs/src-1.6 src</tt></b>
</pre>
</li>
<li>
<p>Create <tt class="filename">/var/db/pkg</tt>
(not part of default install):</p>
<pre class="screen">
<tt class="prompt">#</tt> <b class=
"userinput"><tt>mkdir /usr/sandbox/var/db/pkg</tt></b>
</pre>
</li>
<li>
<p>Create <tt class="filename">/usr/pkg</tt> (not
part of default install):</p>
<pre class="screen">
<tt class="prompt">#</tt> <b class=
"userinput"><tt>mkdir /usr/sandbox/usr/pkg</tt></b>
</pre>
</li>
<li>
<p>Checkout pkgsrc via cvs into <tt class=
"filename">/usr/sandbox/usr/pkgsrc</tt>:</p>
<pre class="screen">
<tt class="prompt">#</tt> <b class=
"userinput"><tt>cd /usr/sandbox/usr</tt></b>
<tt class="prompt">#</tt> <b class=
"userinput"><tt>cvs -d anoncvs@anoncvs.NetBSD.org:/cvsroot checkout -d -P pkgsrc</tt></b>
</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 <tt class=
"filename">/usr/sandbox/usr/pkgsrc/packages</tt>
and <tt class="filename">.../distfiles</tt> point
somewhere appropriate. NFS- and/or nullfs-mounts
may come in handy!</p>
</li>
<li>
<p>Edit <tt class="filename">/etc/mk.conf</tt>,
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 <tt class=
"filename">mk/bulk/build.conf</tt> to suit your
needs.</p>
</li>
<li>
<p>If you have set <tt class=
"varname">CVS_USER</tt> in <tt class=
"filename">build.conf</tt>, make sure that
account exists and can do a <span><b class=
"command">cvs ${CVS_FLAGS} update</b></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">
<tt class="prompt">#</tt> <b class=
"userinput"><tt>cd /usr/sandbox/usr/pkgsrc</tt></b>
<tt class="prompt">#</tt> <b class=
"userinput"><tt>sh mk/bulk/do-sandbox-build</tt></b>
</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 <tt class=
"filename">/usr/sandbox/usr/pkgsrc/packages</tt>
(wherever that points/mounts to/from).</p>
</div>
<div class="sect2" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
2004-11-02 14:29:15 +01:00
<h3 class="title"><a name="id2563916" id=
"id2563916"></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 <tt class=
"filename">pkgsrc/mk/bulk/build</tt> script may be used
to build a subset of the packages contained in pkgsrc.
By setting defining <tt class=
"varname">SPECIFIC_PKGS</tt> in <tt class=
"filename">/etc/mk.conf</tt>, 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
<tt class="varname">SPECIFIC_PKGS</tt> 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>
<div class="sect1" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h2 class="title" style="clear: both"><a name=
2004-11-02 14:29:15 +01:00
"id2564027" id="id2564027"></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"
2004-10-22 02:27:55 +02:00
class="pkgname">pkgtools/cdpack</a> package provides a
simple tool for creating the ISO 9660 images.
<span><b class="command">cdpack</b></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>
2004-11-02 14:29:15 +01:00
<h3 class="title"><a name="id2564042" id=
"id2564042"></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 <tt class=
"filename">/usr/pkgsrc/packages/All</tt> and that
sufficient disk space exists in <tt class=
"filename">/u2</tt> to hold the ISO 9660 images.</p>
<pre class="screen">
<tt class="prompt">#</tt> <b class=
"userinput"><tt>mkdir /u2/images</tt></b>
<tt class="prompt">#</tt> <b class=
"userinput"><tt>pkg_add /usr/pkgsrc/packages/All/cdpack</tt></b>
<tt class="prompt">#</tt> <b class=
"userinput"><tt>cdpack /usr/pkgsrc/packages/All /u2/images</tt></b>
</pre>
<p>If you wish to include a common set of files
(<tt class="filename">COPYRIGHT</tt>, <tt class=
"filename">README</tt>, etc.) on each CD in the
collection, then you need to create a directory which
contains these files. e.g.</p>
<pre class="screen">
<tt class="prompt">#</tt> <b class=
"userinput"><tt>mkdir /tmp/common</tt></b>
<tt class="prompt">#</tt> <b class=
"userinput"><tt>echo "This is a README" &gt; /tmp/common/README</tt></b>
<tt class="prompt">#</tt> <b class=
"userinput"><tt>echo "Another file" &gt; /tmp/common/COPYING</tt></b>
<tt class="prompt">#</tt> <b class=
"userinput"><tt>mkdir /tmp/common/bin</tt></b>
<tt class="prompt">#</tt> <b class=
"userinput"><tt>echo "#!/bin/sh" &gt; /tmp/common/bin/myscript</tt></b>
<tt class="prompt">#</tt> <b class=
"userinput"><tt>echo "echo Hello world" &gt;&gt; /tmp/common/bin/myscript</tt></b>
<tt class="prompt">#</tt> <b class=
"userinput"><tt>chmod 755 /tmp/common/bin/myscript</tt></b>
</pre>
<p>Now create the images:</p>
<pre class="screen">
<tt class="prompt">#</tt> <b class=
"userinput"><tt>cdpack -x /tmp/common /usr/pkgsrc/packages/All /u2/images</tt></b>
</pre>
<p>Each image will contain <tt class=
"filename">README</tt>, <tt class=
"filename">COPYING</tt>, and <tt class=
"filename">bin/myscript</tt> 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>
2004-11-02 14:29:15 +01:00
<dt><span class="sect1"><a href="#id2564301">6.1. Is
there a mailing list for pkg-related
discussion?</a></span></dt>
2004-11-02 14:29:15 +01:00
<dt><span class="sect1"><a href="#id2564331">6.2.
Where's the pkgviews documentation?</a></span></dt>
2004-11-02 14:29:15 +01:00
<dt><span class="sect1"><a href="#id2564344">6.3.
Utilities for package management
(pkgtools)</a></span></dt>
2004-11-02 14:29:15 +01:00
<dt><span class="sect1"><a href="#id2564501">6.4. How
to use pkgsrc as non-root</a></span></dt>
2004-11-02 14:29:15 +01:00
<dt><span class="sect1"><a href="#id2564581">6.5. How
can I install/use XFree86 from pkgsrc?</a></span></dt>
2004-11-02 14:29:15 +01:00
<dt><span class="sect1"><a href="#id2564609">6.6. How
can I install/use X.org from pkgsrc?</a></span></dt>
2004-11-02 14:29:15 +01:00
<dt><span class="sect1"><a href="#id2564636">6.7. How
to fetch files from behind a firewall</a></span></dt>
2004-11-02 14:29:15 +01:00
<dt><span class="sect1"><a href="#id2564650">6.8. How
do I tell make fetch to do passive FTP?</a></span></dt>
2004-11-02 14:29:15 +01:00
<dt><span class="sect1"><a href="#id2564701">6.9. How
to fetch all distfiles at once</a></span></dt>
2004-11-02 14:29:15 +01:00
<dt><span class="sect1"><a href="#id2564978">6.10. What
does Don't know how to make /usr/share/tmac/tmac.andoc
mean?</a></span></dt>
2004-11-02 14:29:15 +01:00
<dt><span class="sect1"><a href="#id2565016">6.11. What
does Could not find bsd.own.mk mean?</a></span></dt>
2004-11-02 14:29:15 +01:00
<dt><span class="sect1"><a href="#id2565074">6.12.
Using 'sudo' with pkgsrc</a></span></dt>
<dt><span class="sect1"><a href="#faq.conf">6.13.
Configuration files handling and
placement</a></span></dt>
<dt><span class="sect1"><a href="#audit-packages">6.14.
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=
2004-11-02 14:29:15 +01:00
"id2564301" id="id2564301"></a>6.1.&nbsp;Is there a
mailing list for pkg-related discussion?</h2>
</div>
</div>
</div>
<p>Yes, <tt class="email">&lt;<a href=
"mailto:tech-pkg@NetBSD.org">tech-pkg@NetBSD.org</a>&gt;</tt>
is the list for discussing package related issues. To
subscribe do:</p>
<pre class="programlisting">
<tt class=
"prompt">%</tt> 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=
2004-11-02 14:29:15 +01:00
"id2564331" id="id2564331"></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 <tt class=
"filename">pkgsrc/mk/buildlink3/PKGVIEWS_UG</tt>.</p>
</div>
<div class="sect1" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h2 class="title" style="clear: both"><a name=
2004-11-02 14:29:15 +01:00
"id2564344" id="id2564344"></a>6.3.&nbsp;Utilities
for package management (pkgtools)</h2>
</div>
</div>
</div>
<p>The <tt class="filename">pkgsrc/pkgtools</tt>
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"
2004-10-22 02:27:55 +02:00
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"
2004-10-22 02:27:55 +02:00
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"
2004-10-22 02:27:55 +02:00
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"
2004-10-22 02:27:55 +02:00
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"
2004-10-22 02:27:55 +02:00
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"
2004-10-22 02:27:55 +02:00
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/xpkgwedge/README.html"
2004-10-22 02:27:55 +02:00
class="pkgname">pkgtools/xpkgwedge</a>: put X11
packages someplace else (enabled by default)</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"
2004-10-22 02:27:55 +02:00
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"
2004-10-22 02:27:55 +02:00
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"
2004-10-22 02:27:55 +02:00
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"
2004-10-22 02:27:55 +02:00
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"
2004-10-22 02:27:55 +02:00
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"
2004-10-22 02:27:55 +02:00
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"
2004-10-22 02:27:55 +02:00
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"
2004-10-22 02:27:55 +02:00
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"
2004-10-22 02:27:55 +02:00
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"
2004-10-22 02:27:55 +02:00
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"
2004-10-22 02:27:55 +02:00
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=
2004-11-02 14:29:15 +01:00
"id2564501" id="id2564501"></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"
2004-10-22 02:27:55 +02:00
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=
2004-11-02 14:29:15 +01:00
"id2564581" id="id2564581"></a>6.5.&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 (<tt class="filename">/usr/X11R6</tt>,
<tt class="filename">/usr/openwin</tt>, ...), you will
have to add the following lines into <tt class=
"filename">mk.conf</tt>:</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=
2004-11-02 14:29:15 +01:00
"id2564609" id="id2564609"></a>6.6.&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 (<tt class="filename">/usr/X11R6</tt>,
<tt class="filename">/usr/openwin</tt>, ...) you will
have to add the following lines into <tt class=
"filename">mk.conf</tt>:</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=
2004-11-02 14:29:15 +01:00
"id2564636" id="id2564636"></a>6.7.&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=
2004-11-02 14:29:15 +01:00
"id2564650" id="id2564650"></a>6.8.&nbsp;How do I
tell <span><b class="command">make fetch</b></span>
to do passive FTP?</h2>
</div>
</div>
</div>
<p>This depends on which utility is used to retrieve
distfiles. From <tt class="filename">bsd.pkg.mk</tt>,
<tt class="varname">FETCH_CMD</tt> 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
<tt class="filename">/usr/bin/ftp</tt>, 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
<tt class="filename">/etc/mk.conf</tt> file: <tt class=
"varname">PASSIVE_FETCH=1</tt>.</p>
<p>Having that option present will prevent <tt class=
"filename">/usr/bin/ftp</tt> 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=
2004-11-02 14:29:15 +01:00
"id2564701" id="id2564701"></a>6.9.&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><b class="command">make fetch</b></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><b class=
"command">make fetch-list</b></span> in <tt class=
"filename">/usr/pkgsrc</tt> 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 <tt class="varname">FETCH_CMD</tt> to
something that fetches a URL:</p>
<p>At home:</p>
<pre class="screen">
<tt class="prompt">%</tt> <b class=
"userinput"><tt>cd /usr/pkgsrc</tt></b>
<tt class="prompt">%</tt> <b class=
"userinput"><tt>make fetch-list FETCH_CMD=wget DISTDIR=/tmp/distfiles &gt;/tmp/fetch.sh</tt></b>
<tt class="prompt">%</tt> <b class=
"userinput"><tt>scp /tmp/fetch.sh work:/tmp</tt></b>
</pre>
<p>At work:</p>
<pre class="screen">
<tt class="prompt">%</tt> <b class=
"userinput"><tt>sh /tmp/fetch.sh</tt></b>
</pre>
<p>then tar up <tt class="filename">/tmp/distfiles</tt>
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><b class="command">make fetch-list</b></span>
approach, or fetch the distfiles directly by running:</p>
<pre class="screen">
<tt class="prompt">%</tt> <b class=
"userinput"><tt>make mirror-distfiles</tt></b>
</pre>
<p>If you even decide to ignore <tt class=
"varname">NO_{SRC,BIN}_ON_{FTP,CDROM}</tt>, then you can
get everything by running:</p>
<pre class="screen">
<tt class="prompt">%</tt> <b class=
"userinput"><tt>make fetch NO_SKIP=yes</tt></b>
</pre>
</div>
<div class="sect1" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h2 class="title" style="clear: both"><a name=
2004-11-02 14:29:15 +01:00
"id2564978" id="id2564978"></a>6.10.&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"
2004-10-22 02:27:55 +02:00
class="pkgname">pkgtools/pkg_install</a> package, you
get the error from make that it doesn't know how to
make <tt class=
"filename">/usr/share/tmac/tmac.andoc</tt>? 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"
2004-10-22 02:27:55 +02:00
class="pkgname">pkgtools/pkg_install</a> package, you
can get away with setting <tt class=
"varname">NOMAN=YES</tt> either in the environment or
in <tt class="filename">/etc/mk.conf</tt>.</p>
</div>
<div class="sect1" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h2 class="title" style="clear: both"><a name=
2004-11-02 14:29:15 +01:00
"id2565016" id="id2565016"></a>6.11.&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, <tt class=
"filename">comp.tgz</tt>, when you installed your NetBSD
machine. Please get it and install it, by extracting it
in <tt class="filename">/</tt>:</p>
<pre class="screen">
<tt class="prompt">#</tt> <b class="userinput"><tt>cd /</tt></b>
<tt class="prompt">#</tt> <b class=
"userinput"><tt>tar --unlink -zxvpf .../comp.tgz</tt></b>
</pre>
<p><tt class="filename">comp.tgz</tt> is part of every
NetBSD release. Get the one that corresponds to your
release (determine via <span><b class="command">uname
-r</b></span>).</p>
</div>
<div class="sect1" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h2 class="title" style="clear: both"><a name=
2004-11-02 14:29:15 +01:00
"id2565074" id="id2565074"></a>6.12.&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"
2004-10-22 02:27:55 +02:00
class="pkgname">security/sudo</a>) and then put the
following into your <tt class=
"filename">/etc/mk.conf</tt>:</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.13.&nbsp;Configuration files
handling and placement</h2>
</div>
</div>
</div>
<p>The global variable <tt class=
"varname">PKG_SYSCONFBASE</tt> (and some others) can be
set by the system administrator in <tt class=
"filename">/etc/mk.conf</tt> 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 <tt class="filename">$PREFIX/share</tt> should go
there.</p>
<p>We will take a look at available variables first
(<tt class="filename">bsd.pkg.mk</tt> contains more
information). <tt class="varname">PKG_SYSCONFDIR</tt> is
where the configuration files for a package may be found
(that is, the full path, e.g. <tt class=
"filename">/etc</tt> or <tt class=
"filename">/usr/pkg/etc</tt>). This value may be
customized in various ways:</p>
<div class="orderedlist">
<ol type="1">
<li>
<p><tt class="varname">PKG_SYSCONFBASE</tt> is the
main config directory under which all package
configuration files are to be found. Users will
typically want to set it to <tt class=
"filename">/etc</tt>, or accept the default
location of <tt class=
"filename">$PREFIX/etc</tt>.</p>
</li>
<li>
<p><tt class="varname">PKG_SYSCONFSUBDIR</tt> is
the subdirectory of <tt class=
"varname">PKG_SYSCONFBASE</tt> under which the
configuration files for a particular package may be
found. Defaults to <tt class=
"varname">${SYSCONFBASE}</tt>.</p>
</li>
<li>
<p><tt class="varname">PKG_SYSCONFVAR</tt> is the
special suffix used to distinguish any overriding
values for a particular package (see next item). It
defaults to <tt class="varname">${PKGBASE}</tt>,
but for a collection of related packages that
should all have the same <tt class=
"varname">PKG_SYSCONFDIR</tt> value, it can be set
in each of the package Makefiles to a common
value.</p>
</li>
<li>
<p><tt class=
"varname">PKG_SYSCONFDIR.${PKG_SYSCONFVAR}</tt>
overrides the value of <tt class=
"varname">${PKG_SYSCONFDIR}</tt> for packages with
the same value for <tt class=
"varname">PKG_SYSCONFVAR</tt>.</p>
<p>As an example, all the various KDE packages may
want to set <tt class="varname">PKG_SYSCONFVAR</tt>
to &#8220;<span class="quote">kde</span>&#8221; so
admins can set <tt class=
"varname">PKG_SYSCONFDIR.kde</tt> in <tt class=
"filename">/etc/mk.conf</tt> 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
<tt class="filename">share/examples/${PKGNAME}</tt> so
<tt class="filename">PLIST</tt> can register them.</p>
<p>Once you have the required configuration files in
place (under the <tt class="filename">share/examples</tt>
directory) the variable <tt class=
"varname">CONF_FILES</tt> should be set to copy them into
<tt class="varname">PKG_SYSCONFDIR</tt>. 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 <tt class=
"filename">PLIST</tt>) 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
<tt class="filename">INSTALL</tt>/<tt class=
"filename">DEINSTALL</tt> scripts which are created
automatically. The package <tt class=
"filename">Makefile</tt> must also set <tt class=
"varname">USE_PKGINSTALL=YES</tt> to use these
automatically generated scripts. The automatic copying of
config files can be toggled by setting the environment
variable <tt class="varname">PKG_CONFIG</tt> 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 <tt class="varname">EGDIR</tt>, which are
registered by <tt class="filename">PLIST</tt>. After
that, the variable <tt class="varname">CONF_FILES</tt>
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.14.&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"
2004-10-22 02:27:55 +02:00
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"
2004-10-22 02:27:55 +02:00
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.1.1.1 2004/10/21 14:27:43 grant 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=
2004-10-22 02:27:55 +02:00
"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. Makefile</a></span></dt>
<dt><span class="sect1"><a href=
"#components.distinfo">7.2. distinfo</a></span></dt>
<dt><span class="sect1"><a href=
"#components.patches">7.3. patches/*</a></span></dt>
2004-11-02 14:29:15 +01:00
<dt><span class="sect1"><a href="#id2566249">7.4.
Other mandatory files</a></span></dt>
<dt><span class="sect1"><a href=
"#components.optional">7.5. Optional
files</a></span></dt>
2004-11-02 14:29:15 +01:00
<dt><span class="sect1"><a href="#id2566443">7.6.
work*</a></span></dt>
2004-11-02 14:29:15 +01:00
<dt><span class="sect1"><a href="#id2566531">7.7.
files/*</a></span></dt>
</dl>
</dd>
<dt><span class="chapter"><a href="#plist">8. PLIST
issues</a></span></dt>
<dd>
<dl>
2004-11-02 14:29:15 +01:00
<dt><span class="sect1"><a href="#id2566585">8.1. RCS
ID</a></span></dt>
2004-11-02 14:29:15 +01:00
<dt><span class="sect1"><a href="#id2566600">8.2.
Semi-automatic PLIST generation</a></span></dt>
<dt><span class="sect1"><a href="#print-PLIST">8.3.
Tweaking output of make print-PLIST</a></span></dt>
<dt><span class="sect1"><a href="#plist.misc">8.4.
Variable substitution in PLIST</a></span></dt>
2004-11-02 14:29:15 +01:00
<dt><span class="sect1"><a href="#id2566921">8.5.
Manpage-compression</a></span></dt>
2004-11-02 14:29:15 +01:00
<dt><span class="sect1"><a href="#id2566963">8.6.
Changing PLIST source with PLIST_SRC</a></span></dt>
2004-11-02 14:29:15 +01:00
<dt><span class="sect1"><a href="#id2566980">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>
2004-11-02 14:29:15 +01:00
<dt><span class="sect1"><a href="#id2567252">9.1.
Converting packages to use buildlink3</a></span></dt>
2004-11-02 14:29:15 +01:00
<dt><span class="sect1"><a href="#id2567579">9.2.
Writing buildlink3.mk files</a></span></dt>
<dd>
<dl>
<dt><span class="sect2"><a href=
2004-11-02 14:29:15 +01:00
"#id2567717">9.2.1. Anatomy of a buildlink3.mk
file</a></span></dt>
<dt><span class="sect2"><a href=
2004-11-02 14:29:15 +01:00
"#id2568157">9.2.2. Updating
BUILDLINK_DEPENDS.pkg in buildlink3.mk
files</a></span></dt>
</dl>
</dd>
2004-11-02 14:29:15 +01:00
<dt><span class="sect1"><a href="#id2568236">9.3.
Writing builtin.mk files</a></span></dt>
<dd>
<dl>
<dt><span class="sect2"><a href=
2004-11-02 14:29:15 +01:00
"#id2568386">9.3.1. Anatomy of a builtin.mk
file</a></span></dt>
<dt><span class="sect2"><a href=
2004-11-02 14:29:15 +01:00
"#id2568613">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>
2004-11-02 14:29:15 +01:00
<dt><span class="sect1"><a href="#id2568685">10.1.
Global default options</a></span></dt>
2004-11-02 14:29:15 +01:00
<dt><span class="sect1"><a href="#id2568700">10.2.
Converting packages to use
bsd.options.mk</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>
2004-11-02 14:29:15 +01:00
<dt><span class="sect1"><a href="#id2569445">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>
2004-11-02 14:29:15 +01:00
<dt><span class="sect1"><a href="#id2570842">12.1.
General operation</a></span></dt>
<dd>
<dl>
<dt><span class="sect2"><a href=
2004-11-02 14:29:15 +01:00
"#id2570845">12.1.1. How to pull in variables
from /etc/mk.conf</a></span></dt>
<dt><span class="sect2"><a href=
2004-11-02 14:29:15 +01:00
"#id2570929">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=
2004-11-02 14:29:15 +01:00
"#id2571444">12.1.4. Handling conflicts with
other packages</a></span></dt>
<dt><span class="sect2"><a href=
2004-11-02 14:29:15 +01:00
"#id2571494">12.1.5. Packages that cannot or
should not be built</a></span></dt>
<dt><span class="sect2"><a href=
2004-11-02 14:29:15 +01:00
"#id2571520">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=
2004-11-02 14:29:15 +01:00
"#id2571611">12.1.8. How to handle compiler
bugs</a></span></dt>
<dt><span class="sect2"><a href=
2004-11-02 14:29:15 +01:00
"#id2571634">12.1.9. How to handle incrementing
versions when fixing an existing
package</a></span></dt>
<dt><span class="sect2"><a href=
2004-11-02 14:29:15 +01:00
"#id2571751">12.1.10. Portability of
packages</a></span></dt>
</dl>
</dd>
2004-11-02 14:29:15 +01:00
<dt><span class="sect1"><a href="#id2571776">12.2.
Possible downloading issues</a></span></dt>
<dd>
<dl>
<dt><span class="sect2"><a href=
2004-11-02 14:29:15 +01:00
"#id2571779">12.2.1. Packages whose distfiles
aren't available for plain
downloading</a></span></dt>
<dt><span class="sect2"><a href=
2004-11-02 14:29:15 +01:00
"#id2571978">12.2.2. How to handle modified
distfiles with the 'old' name</a></span></dt>
</dl>
</dd>
2004-11-02 14:29:15 +01:00
<dt><span class="sect1"><a href="#id2571990">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=
2004-11-02 14:29:15 +01:00
"#id2572397">12.3.2. Using libtool on GNU
packages that already support
libtool</a></span></dt>
<dt><span class="sect2"><a href=
2004-11-02 14:29:15 +01:00
"#id2572482">12.3.3. GNU
Autoconf/Automake</a></span></dt>
</dl>
</dd>
2004-11-02 14:29:15 +01:00
<dt><span class="sect1"><a href="#id2572526">12.4.
Building considerations</a></span></dt>
<dd>
<dl>
<dt><span class="sect2"><a href=
2004-11-02 14:29:15 +01:00
"#id2572530">12.4.1. CPP defines</a></span></dt>
</dl>
</dd>
2004-11-02 14:29:15 +01:00
<dt><span class="sect1"><a href="#id2572560">12.5.
Package specific actions</a></span></dt>
<dd>
<dl>
<dt><span class="sect2"><a href=
2004-11-02 14:29:15 +01:00
"#id2572563">12.5.1. Package configuration
files</a></span></dt>
<dt><span class="sect2"><a href=
2004-11-02 14:29:15 +01:00
"#id2572733">12.5.2. User
2004-10-22 02:27:55 +02:00
interaction</a></span></dt>
<dt><span class="sect2"><a href=
2004-11-02 14:29:15 +01:00
"#id2572778">12.5.3. Handling
licenses</a></span></dt>
<dt><span class="sect2"><a href=
2004-11-02 14:29:15 +01:00
"#id2572861">12.5.4. Creating an account from a
package</a></span></dt>
<dt><span class="sect2"><a href=
2004-11-02 14:29:15 +01:00
"#id2572992">12.5.5. Installing score
files</a></span></dt>
<dt><span class="sect2"><a href=
2004-11-02 14:29:15 +01:00
"#id2573035">12.5.6. Packages providing login
shells</a></span></dt>
<dt><span class="sect2"><a href=
2004-11-02 14:29:15 +01:00
"#id2573161">12.5.7. Packages containing perl
scripts</a></span></dt>
<dt><span class="sect2"><a href=
2004-11-02 14:29:15 +01:00
"#id2573248">12.5.8. Packages with hardcoded
paths to other interpreters</a></span></dt>
<dt><span class="sect2"><a href=
2004-11-02 14:29:15 +01:00
"#id2573269">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=
2004-11-02 14:29:15 +01:00
"#id2573557">12.5.11. Packages installing GConf2
data files</a></span></dt>
<dt><span class="sect2"><a href=
2004-11-02 14:29:15 +01:00
"#id2573657">12.5.12. Packages installing
scrollkeeper data files</a></span></dt>
<dt><span class="sect2"><a href=
2004-11-02 14:29:15 +01:00
"#id2573708">12.5.13. Packages installing X11
fonts</a></span></dt>
<dt><span class="sect2"><a href=
2004-11-02 14:29:15 +01:00
"#id2573824">12.5.14. Packages installing GTK2
modules</a></span></dt>
<dt><span class="sect2"><a href=
2004-11-02 14:29:15 +01:00
"#id2573893">12.5.15. Packages installing SGML or
XML data</a></span></dt>
<dt><span class="sect2"><a href=
2004-11-02 14:29:15 +01:00
"#id2573945">12.5.16. Packages installing
extensions to the MIME database</a></span></dt>
<dt><span class="sect2"><a href=
2004-11-02 14:29:15 +01:00
"#id2574016">12.5.17. Packages using
intltool</a></span></dt>
</dl>
</dd>
2004-11-02 14:29:15 +01:00
<dt><span class="sect1"><a href="#id2574029">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>
2004-11-02 14:29:15 +01:00
<dt><span class="sect1"><a href="#id2574491">14.1.
Submitting your packages</a></span></dt>
2004-11-02 14:29:15 +01:00
<dt><span class="sect1"><a href="#id2574538">14.2.
Committing: Importing a package into
CVS</a></span></dt>
2004-11-02 14:29:15 +01:00
<dt><span class="sect1"><a href="#id2574738">14.3.
2004-10-22 02:27:55 +02:00
Updating a package to a newer version</a></span></dt>
2004-11-02 14:29:15 +01:00
<dt><span class="sect1"><a href="#id2574825">14.4.
2004-10-22 02:27:55 +02:00
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. Makefile</a></span></dt>
<dt><span class="sect1"><a href=
"#components.distinfo">7.2. distinfo</a></span></dt>
<dt><span class="sect1"><a href=
"#components.patches">7.3. patches/*</a></span></dt>
2004-11-02 14:29:15 +01:00
<dt><span class="sect1"><a href="#id2566249">7.4. Other
mandatory files</a></span></dt>
<dt><span class="sect1"><a href=
"#components.optional">7.5. Optional
files</a></span></dt>
2004-11-02 14:29:15 +01:00
<dt><span class="sect1"><a href="#id2566443">7.6.
work*</a></span></dt>
2004-11-02 14:29:15 +01:00
<dt><span class="sect1"><a href="#id2566531">7.7.
files/*</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;<tt class=
"filename">Makefile</tt></h2>
</div>
</div>
</div>
<p>Building, installation and creation of a binary
package are all controlled by the package's <tt class=
"filename">Makefile</tt>.</p>
<p>There is a <tt class="filename">Makefile</tt> for each
package. This file includes the standard <tt class=
"filename">bsd.pkg.mk</tt> file (referenced as <tt class=
"filename">../../mk/bsd.pkg.mk</tt>), which sets all the
definitions and actions necessary for the package to
compile and install itself. The mandatory variables are
the <tt class="varname">DISTNAME</tt> which specifies the
base name of the distribution file to be downloaded from
the site on the Internet, <tt class=
"varname">MASTER_SITES</tt> which specifies that site,
<tt class="varname">CATEGORIES</tt> which denotes the
categories into which the package falls, <tt class=
"varname">PKGNAME</tt> which is the name of the package,
the <tt class="varname">MAINTAINER</tt>'s name, and the
<tt class="varname">COMMENT</tt> 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 <tt class="varname">MASTER_SITES</tt> 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_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><tt class="varname">MASTER_SITE_SUBDIR</tt> has been
deprecated and <span class="emphasis"><em>should no
longer be used</em></span>.</p>
</div>
<p>If the package has multiple <tt class=
"varname">DISTFILES</tt> or multiple <tt class=
"varname">PATCHFILES</tt> from different sites, set
<tt class="varname">SITES_foo</tt> 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 <tt class=
"varname">DISTFILES</tt> 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
<tt class="varname">CATEGORIES</tt>. 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 <tt class="varname">MANCOMPRESSED</tt> if
manpages are installed in compressed form by the
package; see comment in <tt class=
"filename">bsd.pkg.mk</tt>.</p>
</li>
<li>
<p>Replace <tt class="filename">/usr/local</tt>
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 <tt class="varname">MAINTAINER</tt> to be
yourself. If you really can't maintain the package
for future updates, set it to <tt class=
"email">&lt;<a href=
"mailto:tech-pkg@NetBSD.org">tech-pkg@NetBSD.org</a>&gt;</tt>.</p>
</li>
<li>
<p>If a home page for the software in question
exists, add the variable <tt class=
"varname">HOMEPAGE</tt> right after <tt class=
"varname">MAINTAINER</tt>. The value of this
variable should be the URL for the home page.</p>
</li>
<li>
<p>Be sure to set the <tt class=
"varname">COMMENT</tt> 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;<tt class=
"filename">distinfo</tt></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><b class=
"command">make makesum</b></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"
2004-10-22 02:27:55 +02:00
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"
2004-10-22 02:27:55 +02:00
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 <tt class="filename">patches/</tt>
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 <tt class="filename">distinfo</tt> 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><b class="command">make
makepatchsum</b></span> (or <span><b class="command">make
mps</b></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
<tt class="filename">patch-aa</tt> is applied before
<tt class="filename">patch-ab</tt>, etc.</p>
<p>Patch files which are optional and will depend on
local site configuration can be included with names
matching the pattern <tt class=
"filename">patches/patch-optional-*</tt>. Their suffixes
should match the configuration options. The selected
optional patch file names should be assigned to the
variable <tt class="varname">OPTIONAL_PATCHFILES</tt>.
They will not be applied by default.</p>
<p>For example if a package data file needs patching to
indicate the default local printer paper size as
specified in the <tt class="varname">$PAPERSIZE</tt> file
you can include patches for all the possible paper sizes
other than the one the package comes configured for by
default. In this case you might have a patch called
"<tt class=
"filename">patch-optional-Letter-papersize</tt>" and/or
another patch called "<tt class=
"filename">patch-optional-A4-papersize</tt>". In your
<tt class="filename">Makefile</tt> you would select
between them with the following construct:</p>
<pre class="programlisting">
PATCHDIR= ${.CURDIR}/patches
.if exists(${PATCHDIR}/patch-optional-${PAPERSIZE}-papersize)
OPTIONAL_PATCHFILES+= ${PATCHDIR}/patch-optional-${PAPERSIZE}-papersize
.endif
</pre>
<p>Note that you have to define the value of <tt class=
"varname">PATCHDIR</tt> in order to use it in a
&#8220;<span class="quote"><span><b class=
"command">.if</b></span></span>&#8221; statement like
this as otherwise it's not defined until too late during
the processing of the Makefile. You should use a
&#8220;<span class="quote"><span><b class=
"command">.if</b></span></span>&#8221; statement in order
to avoid problems should the configuration item
(<tt class="varname">$PAPERSIZE</tt> in this example) be
set to an unexpected value.</p>
<p>The <tt class="filename">patch-*</tt> files should be
in <span><b class="command">diff -bu</b></span> format,
and apply without a fuzz to avoid problems. (To force
patches to apply with fuzz you can set <tt class=
"varname">PATCH_FUZZ_FACTOR=-F2</tt>). 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><b class=
"command">pkgdiff</b></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"
2004-10-22 02:27:55 +02:00
class="pkgname">pkgtools/pkgdiff</a> package to avoid
these problems.</p>
<p>For even more automation, we recommend using
<span><b class="command">mkpatches</b></span> from the
same package to make a whole set of patches. You just
have to backup files before you edit them to <tt class=
"filename">filename.orig</tt>, e.g. with <span><b class=
"command">cp -p filename filename.orig</b></span> or,
easier, by using <span><b class=
"command">pkgvi</b></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><b class="command">patchdiff</b></span>.</p>
<p>When you have finished a package, remember to generate
the checksums for the patch files by using the
<span><b class="command">make makepatchsum</b></span>
command, see <a href="#components.distinfo" title=
"7.2.&nbsp;distinfo">Section 7.2,
&#8220;distinfo&#8221;</a>.</p>
<p>Patch files that are distributed by the author or
other maintainers can be listed in <tt class=
"varname">$PATCHFILES</tt>.</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 <tt class=
"filename">$LOCALPATCHES</tt> 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 <tt class=
"filename">$LOCALPATCHES/$PKGPATH</tt>). For example if
you want to keep a private patch for <tt class=
"filename">pkgsrc/graphics/png</tt>, keep it in
<tt class="filename">$LOCALPATCHES/graphics/png/mypatch</tt>.
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=
2004-11-02 14:29:15 +01:00
"id2566249" id="id2566249"></a>7.4.&nbsp;Other
mandatory files</h2>
</div>
</div>
</div>
<div class="variablelist">
<dl>
<dt><span class="term"><tt class=
"filename">DESCR</tt></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"><tt class=
"filename">PLIST</tt></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"><tt class=
"filename">INSTALL</tt></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 <tt class="filename">PLIST</tt>. 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"><tt class=
"filename">DEINSTALL</tt></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"><tt class=
"filename">MESSAGE</tt></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 <tt class=
"varname">MESSAGE_SUBST</tt> in the package's
<tt class="filename">Makefile</tt>:</p>
<pre class="programlisting">
MESSAGE_SUBST+= SOMEVAR="somevalue"
</pre>
<p>replaces "${SOMEVAR}" with &#8220;<span class=
"quote">somevalue</span>&#8221; in <tt class=
"filename">MESSAGE</tt>.</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=
2004-11-02 14:29:15 +01:00
"id2566443" id="id2566443"></a>7.6.&nbsp;<tt class=
"filename">work*</tt></h2>
</div>
</div>
</div>
<p>When you type <span><b class="command">make</b></span>
the distribution files are unpacked into this directory.
It can be removed by running <span><b class=
"command">make clean</b></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
<tt class="varname">WRKSRC</tt> 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"
2004-10-22 02:27:55 +02:00
class="pkgname">editors/sam</a> again, but the quick
answer is:</p>
<pre class="programlisting">
WRKSRC= ${WRKDIR}
</pre>
<p>Please note that the old <tt class=
"varname">NO_WRKSUBDIR</tt> has been deprecated and
should not be used. Also, if your package doesn't create
a subdir with the name of <tt class=
"varname">DISTNAME</tt> but some different name, set
<tt class="varname">WRKSRC</tt> to point to the proper
name in <tt class="filename">${WRKDIR}</tt>. See
<a xmlns="http://www.w3.org/TR/xhtml1/transitional" href=
"ftp://ftp.NetBSD.org/pub/NetBSD/packages/pkgsrc/lang/tcl/README.html"
2004-10-22 02:27:55 +02:00
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
<tt class="filename">work</tt> by default. If the same
pkgsrc tree should be used on several different
platforms, the variable <tt class=
"varname">OBJMACHINE</tt> can be set in /etc/mk.conf to
attach the platform to the directory name, e.g.
<tt class="filename">work.i386</tt> or <tt class=
"filename">work.sparc</tt>.</p>
</div>
<div class="sect1" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h2 class="title" style="clear: both"><a name=
2004-11-02 14:29:15 +01:00
"id2566531" id="id2566531"></a>7.7.&nbsp;<tt class=
"filename">files/*</tt></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 <tt class="filename">/dev/null</tt>
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>
2004-11-02 14:29:15 +01:00
<dt><span class="sect1"><a href="#id2566585">8.1. RCS
ID</a></span></dt>
2004-11-02 14:29:15 +01:00
<dt><span class="sect1"><a href="#id2566600">8.2.
Semi-automatic PLIST generation</a></span></dt>
<dt><span class="sect1"><a href="#print-PLIST">8.3.
Tweaking output of make print-PLIST</a></span></dt>
<dt><span class="sect1"><a href="#plist.misc">8.4.
Variable substitution in PLIST</a></span></dt>
2004-11-02 14:29:15 +01:00
<dt><span class="sect1"><a href="#id2566921">8.5.
Manpage-compression</a></span></dt>
2004-11-02 14:29:15 +01:00
<dt><span class="sect1"><a href="#id2566963">8.6.
Changing PLIST source with PLIST_SRC</a></span></dt>
2004-11-02 14:29:15 +01:00
<dt><span class="sect1"><a href="#id2566980">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 <tt class="filename">PLIST</tt> 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 <tt class=
"filename">${PREFIX}</tt> 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 <tt class=
"filename">PLIST</tt> 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=
2004-11-02 14:29:15 +01:00
"id2566585" id="id2566585"></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
<tt class="filename">PLIST</tt> 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=
2004-11-02 14:29:15 +01:00
"id2566600" id=
"id2566600"></a>8.2.&nbsp;Semi-automatic <tt class=
"filename">PLIST</tt> generation</h2>
</div>
</div>
</div>
<p>You can use the <span><b class="command">make
print-PLIST</b></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><b class="command">make
print-PLIST</b></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><b class="command">make
print-PLIST</b></span> outputs a set of <tt class=
"varname">@comment</tt>s instead of real <tt class=
"varname">@dirrm</tt> 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 <tt class="varname">PRINT_PLIST_AWK</tt> 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 <tt class=
"filename">libdata/foo</tt> directory removed from the
resulting PLIST:</p>
<pre class="programlisting">
PRINT_PLIST_AWK+= /^libdata\/foo/ { next; }
</pre>
<p>And to get all the <tt class="varname">@dirrm</tt>
lines referring to a specific (shared) directory
converted to <tt class="varname">@comment</tt>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"><tt class=
"varname">${MACHINE_ARCH}</tt>, <tt class=
"varname">${MACHINE_GNU_ARCH}</tt></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"><tt class=
"varname">${MACHINE_ARCH}</tt></span>&#8221; will
be replaced by what <span><b class="command">uname
-p</b></span> gives. The same is done if the string
<tt class="varname">${MACHINE_GNU_ARCH}</tt> 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"><tt class=
"varname">$ARCH</tt></span>&#8221; that was
replaced by the output of <span><b class=
"command">uname -m</b></span>, but that's no
longer supported and has been removed.</p>
</div>
</dd>
<dt><span class="term"><tt class=
"varname">${OPSYS}</tt>, <tt class=
"varname">${LOWER_OPSYS}</tt>, <tt class=
"varname">${OS_VERSION}</tt></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 <tt class=
"filename">PLIST</tt>:</p>
<div class="itemizedlist">
<ul type="disc">
<li>
<p><tt class="varname">${OPSYS}</tt> - output
of &#8220;<span class="quote"><span><b class=
"command">uname
-s</b></span></span>&#8221;</p>
</li>
<li>
<p><tt class="varname">${LOWER_OPSYS}</tt> -
lowercase common name (eg.
&#8220;<span class="quote">solaris</span>&#8221;)</p>
</li>
<li>
<p><tt class="varname">${OS_VERSION}</tt> -
&#8220;<span class="quote"><span><b class=
"command">uname
-r</b></span></span>&#8221;</p>
</li>
</ul>
</div>
</dd>
<dt><span class="term"><tt class=
"varname">${PKGLOCALEDIR}</tt></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 <tt class="filename">share</tt> or <tt class=
"filename">lib</tt> by default.</p>
</dd>
</dl>
</div>
<p>For a complete list of values which are replaced by
default, please look in <tt class=
"filename">bsd.pkg.mk</tt> (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 <tt class=
"varname">MESSAGE_SUBST</tt> (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=
2004-11-02 14:29:15 +01:00
"id2566921" id=
"id2566921"></a>8.5.&nbsp;Manpage-compression</h2>
</div>
</div>
</div>
<p>Manpages should be installed in compressed form if
<tt class="varname">MANZ</tt> is set (in <tt class=
"filename">bsd.own.mk</tt>), and uncompressed otherwise.
To handle this in the <tt class="filename">PLIST</tt>
file, the suffix &#8220;<span class=
"quote">.gz</span>&#8221; is appended/removed
automatically for manpages according to <tt class=
"varname">MANZ</tt> and <tt class=
"varname">MANCOMPRESSED</tt> being set or not, see above
for details. This modification of the <tt class=
"filename">PLIST</tt> file is done on a copy of it, not
<tt class="filename">PLIST</tt> itself.</p>
</div>
<div class="sect1" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h2 class="title" style="clear: both"><a name=
2004-11-02 14:29:15 +01:00
"id2566963" id="id2566963"></a>8.6.&nbsp;Changing
PLIST source with <tt class=
"varname">PLIST_SRC</tt></h2>
</div>
</div>
</div>
<p>To use one or more files as source for the <tt class=
"filename">PLIST</tt> used in generating the binary
package, set the variable <tt class=
"varname">PLIST_SRC</tt> 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=
2004-11-02 14:29:15 +01:00
"id2566980" id="id2566980"></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><tt class="filename">PLIST.common</tt></p>
</li>
<li>
<p><tt class="filename">PLIST.${OPSYS}</tt></p>
</li>
<li>
<p><tt class="filename">PLIST.common_end</tt></p>
</li>
</ul>
</div>
<p>If <tt class="filename">PLIST.${OPSYS}</tt> exists,
these files are used instead of <tt class=
"filename">PLIST</tt>. This allows packages which behave
in this way to be handled gracefully. Manually overriding
<tt class="varname">PLIST_SRC</tt> 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"
2004-10-22 02:27:55 +02:00
class="pkgname">textproc/scrollkeeper</a>, which
removes the shared directory <tt class=
"filename">share/omf</tt>.</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">
<tt class="prompt">%</tt> cd .../pkgsrc
<tt class="prompt">%</tt> ls -d */*-dirs
</pre>
<p>Their use from other packages is very simple. The
<tt class="varname">USE_DIRS</tt> 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
<tt class="filename">share/applications</tt>, 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><b class=
"command">make print-PLIST</b></span>, you should get the
right (commented out) lines.</p>
<p>Note that, even if your package is using <tt class=
"filename">$X11BASE</tt>, it must not depend on the
*-x11-dirs packages. Just specify the name without that
part and pkgsrc (in particular, <tt class=
"filename">mk/dirs.mk</tt>) 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>
2004-11-02 14:29:15 +01:00
<dt><span class="sect1"><a href="#id2567252">9.1.
Converting packages to use buildlink3</a></span></dt>
2004-11-02 14:29:15 +01:00
<dt><span class="sect1"><a href="#id2567579">9.2.
Writing buildlink3.mk files</a></span></dt>
<dd>
<dl>
2004-11-02 14:29:15 +01:00
<dt><span class="sect2"><a href="#id2567717">9.2.1.
Anatomy of a buildlink3.mk file</a></span></dt>
2004-11-02 14:29:15 +01:00
<dt><span class="sect2"><a href="#id2568157">9.2.2.
Updating BUILDLINK_DEPENDS.pkg in buildlink3.mk
files</a></span></dt>
</dl>
</dd>
2004-11-02 14:29:15 +01:00
<dt><span class="sect1"><a href="#id2568236">9.3.
Writing builtin.mk files</a></span></dt>
<dd>
<dl>
2004-11-02 14:29:15 +01:00
<dt><span class="sect2"><a href="#id2568386">9.3.1.
Anatomy of a builtin.mk file</a></span></dt>
2004-11-02 14:29:15 +01:00
<dt><span class="sect2"><a href="#id2568613">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 <tt class="varname">BUILDLINK_DIR</tt>, which by
default is a subdirectory of <tt class=
"varname">WRKDIR</tt>.</p>
</li>
<li>
<p>Create wrapper scripts that are used in place of
the normal compiler tools that translate <tt class=
"option">-I${LOCALBASE}/include</tt> and <tt class=
"option">-L${LOCALBASE}/lib</tt> into references to
<tt class="varname">BUILDLINK_DIR</tt>. 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. <tt class=
"filename">/usr/include</tt>, <tt class=
"filename">/usr/lib</tt>, 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=
2004-11-02 14:29:15 +01:00
"id2567252" id="id2567252"></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 <tt class="varname">USE_BUILDLINK3</tt> 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 <tt class=
"filename">${WRKDIR}/.work.log</tt> to see if the
wrappers are being invoked.</p>
</li>
<li>
<p>Don't override <tt class="varname">PREFIX</tt>
from within the package Makefile, e.g. Java VMs,
standalone shells, etc., because the code to
symlink files into <tt class=
"filename">${BUILDLINK_DIR}</tt> looks for files
relative to &#8220;<span class="quote">pkg_info -qp
<i class=
"replaceable"><tt>pkgname</tt></i></span>&#8221;.</p>
</li>
<li>
<p>Remember that <span class=
"emphasis"><em>only</em></span> the <tt class=
"filename">buildlink3.mk</tt> 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 <tt class=
"filename">buildlink3.mk</tt> files in <tt class=
"filename">pkgsrc/mk</tt> that handle special package
issues:</p>
<div class="itemizedlist">
<ul type="disc">
<li>
<p><tt class="filename">bdb.buildlink3.mk</tt>
chooses either the native or a pkgsrc Berkeley DB
implementation based on the values of <tt class=
"varname">BDB_ACCEPTED</tt> and <tt class=
"varname">BDB_DEFAULT</tt>.</p>
</li>
<li>
<p><tt class="filename">curses.buildlink3.mk</tt>
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"
2004-10-22 02:27:55 +02:00
class="pkgname">devel/ncurses</a> package.</p>
</li>
<li>
<p><tt class="filename">krb5.buildlink3.mk</tt>
uses the value of <tt class=
"varname">KRB5_ACCEPTED</tt> to choose between
adding a dependency on Heimdal or MIT-krb5 for
packages that require a Kerberos 5
implementation.</p>
</li>
<li>
<p><tt class="filename">motif.buildlink3.mk</tt>
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"
2004-10-22 02:27:55 +02:00
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><tt class="filename">ossaudio.buildlink3.mk</tt>
defines several variables that may be used by
packages that use the Open Sound System (OSS)
API;</p>
</li>
<li>
<p><tt class="filename">pgsql.buildlink3.mk</tt>
will accept either Postgres 7.3 or 7.4, whichever
is found installed. See the file for more
information.</p>
</li>
<li>
<p><tt class="filename">pthread.buildlink3.mk</tt>
uses the value of <tt class=
"varname">PTHREAD_OPTS</tt> 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"
2004-10-22 02:27:55 +02:00
class="pkgname">devel/pth</a> as needed;</p>
</li>
<li>
<p><tt class="filename">xaw.buildlink3.mk</tt> uses
the value of <tt class="varname">XAW_TYPE</tt> to
choose a particular Athena widgets library.</p>
</li>
</ul>
</div>
<p>The comments in those <tt class=
"filename">buildlink3.mk</tt> 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=
2004-11-02 14:29:15 +01:00
"id2567579" id="id2567579"></a>9.2.&nbsp;Writing
<tt class="filename">buildlink3.mk</tt> files</h2>
</div>
</div>
</div>
<p>A package's <tt class="filename">buildlink3.mk</tt>
file is included by Makefiles to indicate the need to
compile and link against header files and libraries
provided by the package. A <tt class=
"filename">buildlink3.mk</tt> file should always provide
enough information to add the correct type of dependency
relationship and include any other <tt class=
"filename">buildlink3.mk</tt> files that it needs to find
headers and libraries that it needs in turn.</p>
<p>To generate an initial <tt class=
"filename">buildlink3.mk</tt> 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"
2004-10-22 02:27:55 +02:00
class="pkgname">pkgtools/createbuildlink</a> package
is highly recommended. For most packages, the
following command will generate a good starting point
for <tt class="filename">buildlink3.mk</tt> files:</p>
<pre class="screen">
<tt class="prompt">%</tt> <b class=
"userinput"><tt>cd pkgsrc/<i class=
"replaceable"><tt>category</tt></i>/<i class=
"replaceable"><tt>pkgdir</tt></i>
<tt class=
"prompt">%</tt> createbuildlink -3 &gt;buildlink3.mk</tt></b>
</pre>
<div class="sect2" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
2004-11-02 14:29:15 +01:00
<h3 class="title"><a name="id2567717" id=
"id2567717"></a>9.2.1. Anatomy of a buildlink3.mk
file</h3>
</div>
</div>
</div>
<p>The following real-life example <tt class=
"filename">buildlink3.mk</tt> is taken from <tt class=
"filename">pkgsrc/graphics/tiff</tt>:</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 <tt class=
"varname">BUILDLINK_DEPTH</tt>, which is common across
all <tt class="filename">buildlink3.mk</tt> files and
is used to track at what depth we are including
<tt class="filename">buildlink3.mk</tt> files.</p>
<p>The first section controls if the dependency on
<i class="replaceable"><tt>pkg</tt></i> is added.
<tt class="varname">BUILDLINK_DEPENDS</tt> is the
global list of packages for which dependencies are
added by buildlink3.</p>
<p>The second section advises pkgsrc that the
<tt class="filename">buildlink3.mk</tt> file for
<i class="replaceable"><tt>pkg</tt></i> has been
included at some point. <tt class=
"varname">BUILDLINK_PACKAGES</tt> is the global list of
packages for which <tt class=
"filename">buildlink3.mk</tt> files have been included.
It must <span class="emphasis"><em>always</em></span>
be appended to within a <tt class=
"filename">buildlink3.mk</tt> file.</p>
<p>The third section is protected from multiple
inclusion and controls how the dependency on <i class=
"replaceable"><tt>pkg</tt></i> is added. Several
important variables are set in the section:</p>
<div class="itemizedlist">
<ul type="disc">
<li>
<p><tt class=
"varname">BUILDLINK_DEPENDS.<i class="replaceable">
<tt>pkg</tt></i></tt> is the actual dependency
recorded in the installed package; this should
always be set using <span><b class=
"command">+=</b></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><tt class=
"varname">BUILDLINK_PKGSRCDIR.<i class=
"replaceable"><tt>pkg</tt></i></tt> is the
location of the <i class=
"replaceable"><tt>pkg</tt></i> pkgsrc
directory;</p>
</li>
<li>
<p><tt class=
"varname">BUILDLINK_DEPMETHOD.<i class=
"replaceable"><tt>pkg</tt></i></tt> (not shown
above) controls whether we use <tt class=
"varname">BUILD_DEPENDS</tt> or <tt class=
"varname">DEPENDS</tt> to add the dependency on
<i class="replaceable"><tt>pkg</tt></i>. The
build dependency is selected by setting
<tt class="varname">BUILDLINK_DEPMETHOD.<i class=
"replaceable"><tt>pkg</tt></i></tt> to
&#8220;<span class="quote">build</span>&#8221;.
By default, the full dependency is used.</p>
</li>
<li>
<p><tt class=
"varname">BUILDLINK_INCDIRS.<i class="replaceable">
<tt>pkg</tt></i></tt> and <tt class=
"varname">BUILDLINK_LIBDIRS.<i class=
"replaceable"><tt>pkg</tt></i></tt> (not shown
above) are lists of subdirectories of <tt class=
"filename">${BUILDLINK_PREFIX.<i class=
"replaceable"><tt>pkg</tt></i>}</tt> 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><tt class=
"varname">BUILDLINK_CPPFLAGS.<i class=
"replaceable"><tt>pkg</tt></i></tt> (not shown
above) is the list of preprocessor flags to add
to <tt class="varname">CPPFLAGS</tt>, 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 <tt class=
"varname">BUILDLINK_INCDIRS.<i class=
"replaceable"><tt>pkg</tt></i></tt> 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 <tt class=
"filename">${BUILDLINK_DIR}</tt> and how their names
are transformed during the symlinking:</p>
<div class="itemizedlist">
<ul type="disc">
<li>
<p><tt class="varname">BUILDLINK_FILES.<i class=
"replaceable"><tt>pkg</tt></i></tt> (not shown
above) is a shell glob pattern relative to
<tt class="filename">${BUILDLINK_PREFIX.<i class=
"replaceable"><tt>pkg</tt></i>}</tt> to be
symlinked into <tt class=
"filename">${BUILDLINK_DIR}</tt>, e.g. <tt class=
"filename">include/*.h</tt>.</p>
</li>
<li>
<p><tt class=
"varname">BUILDLINK_FILES_CMD.<i class=
"replaceable"><tt>pkg</tt></i></tt> (not shown
above) is a shell pipeline that outputs to stdout
a list of files relative to <tt class=
"filename">${BUILDLINK_PREFIX.<i class=
"replaceable"><tt>pkg</tt></i>}</tt>. The
resulting files are to be symlinked into
<tt class="filename">${BUILDLINK_DIR}</tt>. By
default, this takes the <tt class=
"filename">+CONTENTS</tt> of a <i class=
"replaceable"><tt>pkg</tt></i> and filters it
through <tt class=
"varname">${BUILDLINK_CONTENTS_FILTER.<i class=
"replaceable"><tt>pkg</tt></i>}</tt>.</p>
</li>
<li>
<p><tt class=
"varname">BUILDLINK_CONTENTS_FILTER.<i class=
"replaceable"><tt>pkg</tt></i></tt> (not shown
above) is a filter command that filters
<tt class="filename">+CONTENTS</tt> input into a
list of files relative to <tt class=
"filename">${BUILDLINK_PREFIX.<i class=
"replaceable"><tt>pkg</tt></i>}</tt> on stdout.
By default for overwrite packages, <tt class=
"varname">BUILDLINK_CONTENTS_FILTER.<i class=
"replaceable"><tt>pkg</tt></i></tt> outputs the
contents of the <tt class="filename">include</tt>
and <tt class="filename">lib</tt> directories in
the package <tt class="filename">+CONTENTS</tt>,
and for pkgviews packages, it outputs any libtool
archives in <tt class="filename">lib</tt>
directories.</p>
</li>
<li>
<p><tt class=
"varname">BUILDLINK_TRANSFORM.<i class=
"replaceable"><tt>pkg</tt></i></tt> (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><b class=
"command">-e
"s|/curses.h|/ncurses.h|g"</b></span>.</p>
</li>
</ul>
</div>
<p>The last section includes any <tt class=
"filename">buildlink3.mk</tt> needed for <i class=
"replaceable"><tt>pkg</tt></i>'s library dependencies.
Including these <tt class="filename">buildlink3.mk</tt>
files means that the headers and libraries for these
dependencies are also symlinked into <tt class=
"filename">${BUILDLINK_DIR}</tt> whenever the <i class=
"replaceable"><tt>pkg</tt></i> <tt class=
"filename">buildlink3.mk</tt> file is included.</p>
</div>
<div class="sect2" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
2004-11-02 14:29:15 +01:00
<h3 class="title"><a name="id2568157" id=
"id2568157"></a>9.2.2. Updating <tt class=
"varname">BUILDLINK_DEPENDS.<i class=
"replaceable"><tt>pkg</tt></i></tt> in <tt class=
"filename">buildlink3.mk</tt> files</h3>
</div>
</div>
</div>
<p>There are two situations that require increasing the
dependency listed in <tt class=
"varname">BUILDLINK_DEPENDS.<i class=
"replaceable"><tt>pkg</tt></i></tt> 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, <tt class=
"varname">BUILDLINK_DEPENDS.<i class=
"replaceable"><tt>pkg</tt></i></tt> 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 <tt class="varname">PKGREVISION</tt>s
increased and, if they have <tt class=
"filename">buildlink3.mk</tt> files, their <tt class=
"varname">BUILDLINK_DEPENDS.<i class=
"replaceable"><tt>pkg</tt></i></tt> 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
<tt class="varname">BUILDLINK_DEPENDS.<i class=
"replaceable"><tt>pkg</tt></i></tt> 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
<tt class="varname">BUILDLINK_RECOMMENDED</tt> and
<tt class="varname">RECOMMENDED</tt> 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=
2004-11-02 14:29:15 +01:00
"id2568236" id="id2568236"></a>9.3.&nbsp;Writing
<tt class="filename">builtin.mk</tt> 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 <tt class=
"filename">buildlink3.mk</tt> file, these packages should
also include a <tt class="filename">builtin.mk</tt> 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
<i class="replaceable"><tt>pkg</tt></i> are:</p>
<div class="orderedlist">
<ol type="1">
<li>
<p>It should set <tt class=
"varname">USE_BUILTIN.<i class=
"replaceable"><tt>pkg</tt></i></tt> 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
<tt class="varname">USE_BUILTIN.<i class=
"replaceable"><tt>pkg</tt></i></tt> which is
already set before the <tt class=
"filename">builtin.mk</tt> 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 <tt class=
"filename">Makefile</tt> coding.</p>
</li>
</ol>
</div>
<div class="sect2" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
2004-11-02 14:29:15 +01:00
<h3 class="title"><a name="id2568386" id=
"id2568386"></a>9.3.1.&nbsp;Anatomy of a
<tt class="filename">builtin.mk</tt> 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 <tt class=
"varname">IS_BUILTIN.<i class=
"replaceable"><tt>pkg</tt></i></tt> depending on if
<i class="replaceable"><tt>pkg</tt></i> really exists
in the base system. This should not be a base system
software with similar functionality to <i class=
"replaceable"><tt>pkg</tt></i>; 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
<tt class="filename">builtin.mk</tt> file.</p>
<p>The second section sets <tt class=
"varname">BUILTIN_PKG.<i class=
"replaceable"><tt>pkg</tt></i></tt> to the version of
<i class="replaceable"><tt>pkg</tt></i> in the base
system if it exists (if <tt class=
"varname">IS_BUILTIN.<i class=
"replaceable"><tt>pkg</tt></i></tt> is
&#8220;<span class="quote">yes</span>&#8221;). This
variable is only used internally within the <tt class=
"filename">builtin.mk</tt> file.</p>
<p>The third section sets <tt class=
"varname">USE_BUILTIN.<i class=
"replaceable"><tt>pkg</tt></i></tt> and is <span class=
"emphasis"><em>required</em></span> in all <tt class=
"filename">builtin.mk</tt> files. The code in this
section must make the determination whether the
built-in software is adequate to satisfy the
dependencies listed in <tt class=
"varname">BUILDLINK_DEPENDS.<i class=
"replaceable"><tt>pkg</tt></i></tt>. This is typically
done by comparing <tt class=
"varname">BUILTIN_PKG.<i class=
"replaceable"><tt>pkg</tt></i></tt> against each of the
dependencies in <tt class=
"varname">BUILDLINK_DEPENDS.<i class=
"replaceable"><tt>pkg</tt></i></tt>. <tt class=
"varname">USE_BUILTIN.<i class=
"replaceable"><tt>pkg</tt></i></tt> <span class=
"emphasis"><em>must</em></span> be set to the correct
value by the end of the <tt class=
"filename">builtin.mk</tt> file. Note that <tt class=
"varname">USE_BUILTIN.<i class=
"replaceable"><tt>pkg</tt></i></tt> may be
&#8220;<span class="quote">yes</span>&#8221; even if
<tt class="varname">IS_BUILTIN.<i class=
"replaceable"><tt>pkg</tt></i></tt> 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 <tt class=
"varname">CHECK_BUILTIN.<i class=
"replaceable"><tt>pkg</tt></i></tt>, and includes code
that uses the value of <tt class=
"varname">USE_BUILTIN.<i class=
"replaceable"><tt>pkg</tt></i></tt> set in the previous
section. This typically includes, e.g., adding
additional dependency restrictions and listing
additional files to symlink into <tt class=
"filename">${BUILDLINK_DIR}</tt> (via <tt class=
"varname">BUILDLINK_FILES.<i class=
"replaceable"><tt>pkg</tt></i></tt>).</p>
</div>
<div class="sect2" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
2004-11-02 14:29:15 +01:00
<h3 class="title"><a name="id2568613" id=
"id2568613"></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 <tt class="varname">PREFER_PKGSRC</tt> and
<tt class="varname">PREFER_NATIVE</tt>. 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.
<tt class="varname">PREFER_PKGSRC</tt> tells pkgsrc to
use the pkgsrc versions of software, while <tt class=
"varname">PREFER_NATIVE</tt> tells pkgsrc to use the
built-in versions. Preferences are determined by the
most specific instance of the package in either
<tt class="varname">PREFER_PKGSRC</tt> or <tt class=
"varname">PREFER_NATIVE</tt>. If a package is specified
in neither or in both variables, then <tt class=
"varname">PREFER_PKGSRC</tt> has precedence over
<tt class="varname">PREFER_NATIVE</tt>. 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 <tt class=
"filename">builtin.mk</tt> file to be listed in
<tt class="varname">PREFER_NATIVE</tt>, 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>
2004-11-02 14:29:15 +01:00
<dt><span class="sect1"><a href="#id2568685">10.1.
Global default options</a></span></dt>
2004-11-02 14:29:15 +01:00
<dt><span class="sect1"><a href="#id2568700">10.2.
Converting packages to use
bsd.options.mk</a></span></dt>
</dl>
</div>
<p>Many packages have the ability to be built to support
different sets of features. <tt class=
"filename">bsd.options.mk</tt> 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=
2004-11-02 14:29:15 +01:00
"id2568685" id="id2568685"></a>10.1.&nbsp;Global
default options</h2>
</div>
</div>
</div>
<p>Global default options are listed in <tt class=
"varname">PKG_DEFAULT_OPTIONS</tt>, 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
<tt class="filename">/etc/mk.conf</tt>.</p>
</div>
<div class="sect1" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h2 class="title" style="clear: both"><a name=
2004-11-02 14:29:15 +01:00
"id2568700" id=
"id2568700"></a>10.2.&nbsp;Converting packages to
use <tt class="filename">bsd.options.mk</tt></h2>
</div>
</div>
</div>
<p>The following example shows how <tt class=
"filename">bsd.options.mk</tt> should be use in a package
<tt class="filename">Makefile</tt>, or in a file, e.g.
<tt class="filename">options.mk</tt>, that is included by
the main package <tt class="filename">Makefile</tt>.</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
<tt class="filename">bsd.options.mk</tt>. It converts
global or legacy options variables into an equivalent
<tt class="varname">PKG_OPTIONS.<i class=
"replaceable"><tt>pkg</tt></i></tt> 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><tt class="varname">PKG_OPTIONS_VAR</tt> 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.<i class=
"replaceable"><tt>pkg</tt></i></span>&#8221; but
any package-specific value may be used. This
variable should be set in a package Makefile.</p>
</li>
<li>
<p><tt class="varname">PKG_SUPPORTED_OPTIONS</tt>
is a list of build options supported by the
package. This variable should be set in a package
Makefile.</p>
</li>
<li>
<p><tt class="varname">${PKG_OPTIONS_VAR}</tt> (the
variables named in <tt class=
"varname">PKG_OPTIONS_VAR</tt>) are variables that
list the selected build options and override any
default options given in <tt class=
"varname">PKG_DEFAULT_OPTIONS</tt>. 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 <tt class=
"filename">/etc/mk.conf</tt>.</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><tt class="varname">PKG_OPTIONS</tt> 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 <tt class=
"varname">PKG_SUPPORTED_OPTIONS</tt>, 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 <tt class="varname">PKG_OPTIONS</tt>.</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>
2004-11-02 14:29:15 +01:00
<dt><span class="sect1"><a href="#id2569445">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, <tt class=
"filename">pkgsrc/mk/bsd.pkg.mk</tt>.</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 <tt class="varname">PREFIX</tt>
indicates where all files of the final program shall be
installed. It is usually set to <tt class=
"varname">LOCALBASE</tt> (<tt class=
"filename">/usr/pkg</tt>), or <tt class=
"varname">CROSSBASE</tt> for pkgs in the
&#8220;<span class="quote">cross</span>&#8221; category.
The value of <tt class="varname">PREFIX</tt> 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><tt class="varname">PREFIX</tt> 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><tt class="varname">LOCALBASE</tt> 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><tt class="varname">X11BASE</tt> 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 <tt class=
"varname">X11BASE</tt> or <tt class=
"varname">LOCALBASE</tt>.</p>
<p>Usually, X11 packages should be installed under
<tt class="varname">LOCALBASE</tt> whenever
possible. Note that you will need to set <tt class=
"varname">USE_X11</tt> 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 <tt class=
"varname">LOCALBASE</tt>: those that come with
app-defaults files. These packages are special and
they must be placed under <tt class=
"varname">X11BASE</tt>. To accomplish this, set
either <tt class="varname">USE_X11BASE</tt> or
<tt class="varname">USE_IMAKE</tt> in your
package.</p>
<p>Some notes: <tt class="varname">USE_X11</tt> and
<tt class="varname">USE_X11BASE</tt> are mutually
exclusive. If you need to find includes or
libraries installed by a pkg that has <tt class=
"varname">USE_IMAKE</tt> or <tt class=
"varname">USE_X11BASE</tt> in its pkg <tt class=
"filename">Makefile</tt>, you need to use
<span class="emphasis"><em>both</em></span>
<tt class="filename">${X11BASE}</tt> and <tt class=
"filename">${LOCALBASE}</tt>. To force installation
of all X11 packages in <tt class=
"varname">LOCALBASE</tt>, the <a xmlns=
"http://www.w3.org/TR/xhtml1/transitional" href=
"ftp://ftp.NetBSD.org/pub/NetBSD/packages/pkgsrc/pkgtools/xpkgwedge/README.html"
2004-10-22 02:27:55 +02:00
class="pkgname">pkgtools/xpkgwedge</a> is
enabled by default.</p>
</li>
<li>
<p><tt class="varname">X11PREFIX</tt> should be
used to refer to the installed location of an X11
package. <tt class="varname">X11PREFIX</tt> will be
set to <tt class="varname">X11BASE</tt> if
xpkgwedge is not installed, and to <tt class=
"varname">LOCALBASE</tt> if xpkgwedge is
installed.</p>
</li>
<li>
<p>If xpkgwedge is installed, it is possible to
have some packages installed in <tt class=
"varname">X11BASE</tt> and some in <tt class=
"varname">LOCALBASE</tt>. To determine the prefix
of an installed package, the <tt class=
"varname">EVAL_PREFIX</tt> 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 <tt class=
"varname">DIRNAME</tt> 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 <tt class=
"filename">pkgsrc/wm/scwm/Makefile</tt>:</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 <tt class=
"varname">EVAL_PREFIX</tt>, by using a definition
of the form:</p>
<pre class="programlisting">
GTKDIR_DEFAULT= ${LOCALBASE}
</pre>
<p>where <tt class="varname">GTKDIR</tt>
corresponds to the first definition in the
<tt class="varname">EVAL_PREFIX</tt> pair.</p>
</li>
<li>
<p>Within <tt class="filename">${PREFIX}</tt>,
packages should install files according to hier(7),
with the exception that manual pages go into
<tt class="filename">${PREFIX}/man</tt>, not
<tt class="filename">${PREFIX}/share/man</tt>.</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=
2004-11-02 14:29:15 +01:00
"id2569445" id="id2569445"></a>11.2.&nbsp;Main
targets</h2>
</div>
</div>
</div>
<p>The main targets used during the build process defined
in <tt class="filename">bsd.pkg.mk</tt> 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 <tt class="varname">DISTFILES</tt> and
<tt class="varname">PATCHFILES</tt> (as defined in
the package's Makefile) are present on the local
system in <tt class=
"filename">/usr/pkgsrc/distfiles</tt>. 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, <tt class=
"varname">MASTER_SITE_OVERRIDE</tt> is tried, then
the sites specified in either <tt class=
"varname">SITES_file</tt> if defined, else
<tt class="varname">MASTER_SITES</tt> or <tt class=
"varname">PATCH_SITES</tt>, as applies, then
finally the value of <tt class=
"varname">MASTER_SITE_BACKUP</tt>. The order of all
except the first can be optionally sorted by the
user, via setting either <tt class=
"varname">MASTER_SORT_AWK</tt> or <tt class=
"varname">MASTER_SORT_REGEX</tt>.</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 <tt class=
"filename">.tar.gz</tt>.</p>
<p>If only some of the distfiles need to be
uncompressed, the files to be uncompressed should
be put into <tt class=
"varname">EXTRACT_ONLY</tt>.</p>
<p>If the distfiles are not in <tt class=
"filename">.tar.gz</tt> format, they can be
extracted by setting either <tt class=
"varname">EXTRACT_SUFX</tt>, or <tt class=
"varname">EXTRACT_CMD</tt>, <tt class=
"varname">EXTRACT_BEFORE_ARGS</tt> and <tt class=
"varname">EXTRACT_AFTER_ARGS</tt>. In the former
case, pkgsrc knows how to extract a number of
suffixes (<tt class="filename">.tar.gz</tt>,
<tt class="filename">.tgz</tt>, <tt class=
"filename">.tar.gz2</tt>, <tt class=
"filename">.tbz</tt>, <tt class=
"filename">.tar.Z</tt>, <tt class=
"filename">.tar</tt>, <tt class=
"filename">.shar.gz</tt>, <tt class=
"filename">.shar.bz2</tt>, <tt class=
"filename">.shar.Z</tt>, <tt class=
"filename">.shar</tt>, <tt class=
"filename">.Z</tt>, <tt class="filename">.bz2</tt>
and <tt class="filename">.gz</tt>; see the
definition of the various <tt class=
"varname">DECOMPRESS_CMD</tt> variables <tt class=
"filename">bsd.pkg.mk</tt> 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 <tt class=
"filename">.msg.gz</tt>:</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
<tt class="varname">PATCHFILES</tt>, those present
in the patches subdirectory of the package as well
as in $LOCALPATCHES/$PKGPATH (e.g. <tt class=
"filename">/usr/local/patches/graphics/png</tt>)
are applied. Patchfiles ending in <tt class=
"filename">.Z</tt> or <tt class="filename">.gz</tt>
are uncompressed before they are applied, files
ending in <tt class="filename">.orig</tt> or
<tt class="filename">.rej</tt> are ignored. Any
special options to patch(1) can be handed in
<tt class="varname">PATCH_DIST_ARGS</tt>. 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
<tt class="varname">HAS_CONFIGURE</tt>. If the
configure script is a GNU autoconf script,
<tt class="varname">GNU_CONFIGURE</tt> should be
specified instead. In either case, any arguments to
the configure script can be specified in the
<tt class="varname">CONFIGURE_ARGS</tt> variable,
and the configure script's name can be set in
<tt class="varname">CONFIGURE_SCRIPT</tt> 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"
2004-10-22 02:27:55 +02:00
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 <tt class="varname">USE_IMAKE</tt> to
&#8220;<span class="quote">YES</span>&#8221;. (If
you only want the package installed in <tt class=
"varname">$X11PREFIX</tt> but xmkmf not being run,
set <tt class="varname">USE_X11BASE</tt>
instead!)</p>
</dd>
<dt><span class="term">build</span></dt>
<dd>
<p>Once configuration has taken place, the software
will be built by invoking <tt class=
"varname">$MAKE_PROGRAM</tt> on <tt class=
"varname">$MAKEFILE</tt> with <tt class=
"varname">$ALL_TARGET</tt> as the target to build.
The default <tt class="varname">MAKE_PROGRAM</tt>
is &#8220;<span class="quote">gmake</span>&#8221;
if <tt class="varname">USE_GMAKE</tt> is set,
&#8220;<span class="quote">make</span>&#8221;
otherwise. <tt class="varname">MAKEFILE</tt> is set
to &#8220;<span class=
"quote">Makefile</span>&#8221; by default, and
<tt class="varname">ALL_TARGET</tt> 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, <tt class=
"varname">$MAKE_PROGRAM</tt> is invoked on
<tt class="varname">$MAKEFILE</tt> here, but with
the <tt class="varname">$INSTALL_TARGET</tt>
instead, the latter defaulting to
&#8220;<span class="quote">install</span>&#8221;
(plus &#8220;<span class=
"quote">install.man</span>&#8221;, if <tt class=
"varname">USE_IMAKE</tt> 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><b class="command">make build</b></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><b class="command">make
install</b></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"><tt class=
"varname">PKG_VERBOSE</tt></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"><tt class=
"varname">DEINSTALLDEPENDS</tt></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><b class="command">make deinstall
DEINSTALLDEPENDS=1</b></span> is done in
<tt class="filename">pkgsrc/x11/kde</tt>,
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><b class=
"command">make deinstall</b></span> and
<span><b class="command">make install</b></span>
(or whatever <tt class="varname">UPDATE_TARGET</tt>
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><b class=
"command">make update</b></span> was interrupted
for some reason. However, in this case, make sure
you don't call <span><b class="command">make
clean</b></span> or otherwise remove the list of
dependent packages in <tt class=
"varname">WRKDIR</tt>. 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><b class=
"command">make update</b></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><b class=
"command">make update</b></span> will most
certainly fail!</p>
<p>The following variables can be used either on
the command line or in <tt class=
"filename">/etc/mk.conf</tt> to alter the behaviour
of <span><b class="command">make
update</b></span>:</p>
<div class="variablelist">
<dl>
<dt><span class="term"><tt class=
"varname">UPDATE_TARGET</tt></span></dt>
<dd>
<p>Install target to recursively use for the
updated package and the dependent packages.
Defaults to <tt class=
"varname">DEPENDS_TARGET</tt> if set,
&#8220;<span class=
"quote">install</span>&#8221; otherwise for
<span><b class="command">make
update</b></span>. e.g. <span><b class=
"command">make update
UPDATE_TARGET=package</b></span></p>
</dd>
<dt><span class="term"><tt class=
"varname">NOCLEAN</tt></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><b class="command">make</b></span> or
<span><b class="command">make
update</b></span>.</p>
</dd>
<dt><span class="term"><tt class=
"varname">REINSTALL</tt></span></dt>
<dd>
<p>Deinstall each package before installing
(making <tt class=
"varname">DEPENDS_TARGET</tt>). This may be
necessary if the &#8220;<span class=
"quote">clean-update</span>&#8221; target
(see below) was called after interrupting a
running <span><b class="command">make
update</b></span>.</p>
</dd>
<dt><span class="term"><tt class=
"varname">DEPENDS_TARGET</tt></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 <tt class=
"varname">DEPENDS_TARGET</tt> if you want to
disable recursive updates. Use <tt class=
"varname">UPDATE_TARGET</tt> instead to just
set a specific target for each package to be
installed during <span><b class=
"command">make update</b></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><b class="command">make
update</b></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><b class="command">make update</b></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><b class="command">make
update</b></span> and only if you have a dirty
package tree (e.g., if you used <tt class=
"varname">NOCLEAN</tt>).</p>
<p>If you unsure about whether your tree is clean
you can either perform a <span><b class=
"command">make clean</b></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><b class="command">make update</b></span> for
the first time, otherwise you lose all the packages
you wanted to update!):</p>
<pre class="screen">
<tt class="prompt">#</tt> <b class=
"userinput"><tt>make clean-update</tt></b>
<tt class="prompt">#</tt> <b class=
"userinput"><tt>make clean CLEANDEPENDS=YES</tt></b>
<tt class="prompt">#</tt> <b class=
"userinput"><tt>make update</tt></b>
</pre>
<p>The following variables can be used either on
the command line or in <tt class=
"filename">/etc/mk.conf</tt> to alter the behaviour
of <span><b class="command">make
clean-update</b></span>:</p>
<div class="variablelist">
<dl>
<dt><span class="term"><tt class=
"varname">CLEAR_DIRLIST</tt></span></dt>
<dd>
<p>After <span><b class="command">make
clean</b></span>, do not reconstruct the list
of directories to update for this package.
Only use this if <span><b class=
"command">make update</b></span> successfully
installed all packages you wanted to update.
Normally, this is done automatically on
<span><b class="command">make
update</b></span>, but may have been
suppressed by the <tt class=
"varname">NOCLEAN</tt> 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 <tt class=
"filename">README.html</tt> 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"
2004-10-22 02:27:55 +02:00
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 <tt class="varname">PACKAGES</tt>
directory on the local host. The generated files
can be made to refer to URLs based on <tt class=
"varname">FTP_PKG_URL_HOST</tt> and <tt class=
"varname">FTP_PKG_URL_DIR</tt>. For example, if
I wanted to generate <tt class=
"filename">README.html</tt> files which pointed
to binary packages on the local machine, in the
directory <tt class=
"filename">/usr/packages</tt>, set <tt class=
"varname">FTP_PKG_URL_HOST=file://localhost</tt>
and <tt class=
"varname">FTP_PKG_URL_DIR=/usr/packages</tt>.
The <tt class="varname">${PACKAGES}</tt>
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 <tt class=
"filename">README-all.html</tt> 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 <tt class=
"filename">pkgsrc/*/README.html</tt> files, so be
sure to run this <span class=
"emphasis"><em>after</em></span> a <span><b class=
"command">make readme</b></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 <tt class=
"filename">README.html</tt> files, and can be made
to refer to URLs based on <tt class=
"varname">CDROM_PKG_URL_HOST</tt> and <tt class=
"varname">CDROM_PKG_URL_DIR</tt>.</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. (<tt class=
"varname">DISTFILES</tt> and <tt class=
"varname">PATCHFILES</tt>, but not <tt class=
"filename">patches/*</tt>)</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 <tt class=
"varname">DEPENDS</tt>. 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 <tt class="varname">PKG_DEVELOPER</tt>
is set in <tt class=
"filename">/etc/mk.conf</tt>.</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
<tt class="filename">PLIST</tt> from a
<span><b class="command">find -newer
work/.extract_done</b></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 <tt class="filename">PLIST</tt>. On upgrades,
it's useful to diff the output of this command
against an already existing <tt class=
"filename">PLIST</tt> 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
<tt class="filename">PLIST</tt>, 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 make
print-PLIST&#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 <tt class=
"varname">PKG_DEPENDS</tt> 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><b class="command">make
bulk-package</b></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 (<tt class=
"filename">Makefile</tt>, ...) 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>
2004-11-02 14:29:15 +01:00
<dt><span class="sect1"><a href="#id2570842">12.1.
General operation</a></span></dt>
<dd>
<dl>
<dt><span class="sect2"><a href=
2004-11-02 14:29:15 +01:00
"#id2570845">12.1.1. How to pull in variables from
/etc/mk.conf</a></span></dt>
<dt><span class="sect2"><a href=
2004-11-02 14:29:15 +01:00
"#id2570929">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=
2004-11-02 14:29:15 +01:00
"#id2571444">12.1.4. Handling conflicts with other
packages</a></span></dt>
<dt><span class="sect2"><a href=
2004-11-02 14:29:15 +01:00
"#id2571494">12.1.5. Packages that cannot or should
not be built</a></span></dt>
<dt><span class="sect2"><a href=
2004-11-02 14:29:15 +01:00
"#id2571520">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=
2004-11-02 14:29:15 +01:00
"#id2571611">12.1.8. How to handle compiler
bugs</a></span></dt>
<dt><span class="sect2"><a href=
2004-11-02 14:29:15 +01:00
"#id2571634">12.1.9. How to handle incrementing
versions when fixing an existing
package</a></span></dt>
<dt><span class="sect2"><a href=
2004-11-02 14:29:15 +01:00
"#id2571751">12.1.10. Portability of
packages</a></span></dt>
</dl>
</dd>
2004-11-02 14:29:15 +01:00
<dt><span class="sect1"><a href="#id2571776">12.2.
Possible downloading issues</a></span></dt>
<dd>
<dl>
<dt><span class="sect2"><a href=
2004-11-02 14:29:15 +01:00
"#id2571779">12.2.1. Packages whose distfiles
aren't available for plain
downloading</a></span></dt>
<dt><span class="sect2"><a href=
2004-11-02 14:29:15 +01:00
"#id2571978">12.2.2. How to handle modified
distfiles with the 'old' name</a></span></dt>
</dl>
</dd>
2004-11-02 14:29:15 +01:00
<dt><span class="sect1"><a href="#id2571990">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=
2004-11-02 14:29:15 +01:00
"#id2572397">12.3.2. Using libtool on GNU packages
that already support libtool</a></span></dt>
<dt><span class="sect2"><a href=
2004-11-02 14:29:15 +01:00
"#id2572482">12.3.3. GNU
Autoconf/Automake</a></span></dt>
</dl>
</dd>
2004-11-02 14:29:15 +01:00
<dt><span class="sect1"><a href="#id2572526">12.4.
Building considerations</a></span></dt>
<dd>
<dl>
<dt><span class="sect2"><a href=
2004-11-02 14:29:15 +01:00
"#id2572530">12.4.1. CPP defines</a></span></dt>
</dl>
</dd>
2004-11-02 14:29:15 +01:00
<dt><span class="sect1"><a href="#id2572560">12.5.
Package specific actions</a></span></dt>
<dd>
<dl>
<dt><span class="sect2"><a href=
2004-11-02 14:29:15 +01:00
"#id2572563">12.5.1. Package configuration
files</a></span></dt>
<dt><span class="sect2"><a href=
2004-11-02 14:29:15 +01:00
"#id2572733">12.5.2. User
2004-10-22 02:27:55 +02:00
interaction</a></span></dt>
<dt><span class="sect2"><a href=
2004-11-02 14:29:15 +01:00
"#id2572778">12.5.3. Handling
licenses</a></span></dt>
<dt><span class="sect2"><a href=
2004-11-02 14:29:15 +01:00
"#id2572861">12.5.4. Creating an account from a
package</a></span></dt>
<dt><span class="sect2"><a href=
2004-11-02 14:29:15 +01:00
"#id2572992">12.5.5. Installing score
files</a></span></dt>
<dt><span class="sect2"><a href=
2004-11-02 14:29:15 +01:00
"#id2573035">12.5.6. Packages providing login
shells</a></span></dt>
<dt><span class="sect2"><a href=
2004-11-02 14:29:15 +01:00
"#id2573161">12.5.7. Packages containing perl
scripts</a></span></dt>
<dt><span class="sect2"><a href=
2004-11-02 14:29:15 +01:00
"#id2573248">12.5.8. Packages with hardcoded paths
to other interpreters</a></span></dt>
<dt><span class="sect2"><a href=
2004-11-02 14:29:15 +01:00
"#id2573269">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=
2004-11-02 14:29:15 +01:00
"#id2573557">12.5.11. Packages installing GConf2
data files</a></span></dt>
<dt><span class="sect2"><a href=
2004-11-02 14:29:15 +01:00
"#id2573657">12.5.12. Packages installing
scrollkeeper data files</a></span></dt>
<dt><span class="sect2"><a href=
2004-11-02 14:29:15 +01:00
"#id2573708">12.5.13. Packages installing X11
fonts</a></span></dt>
<dt><span class="sect2"><a href=
2004-11-02 14:29:15 +01:00
"#id2573824">12.5.14. Packages installing GTK2
modules</a></span></dt>
<dt><span class="sect2"><a href=
2004-11-02 14:29:15 +01:00
"#id2573893">12.5.15. Packages installing SGML or
XML data</a></span></dt>
<dt><span class="sect2"><a href=
2004-11-02 14:29:15 +01:00
"#id2573945">12.5.16. Packages installing
extensions to the MIME database</a></span></dt>
<dt><span class="sect2"><a href=
2004-11-02 14:29:15 +01:00
"#id2574016">12.5.17. Packages using
intltool</a></span></dt>
</dl>
</dd>
2004-11-02 14:29:15 +01:00
<dt><span class="sect1"><a href="#id2574029">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=
2004-11-02 14:29:15 +01:00
"id2570842" id="id2570842"></a>12.1.&nbsp;General
operation</h2>
</div>
</div>
</div>
<div class="sect2" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
2004-11-02 14:29:15 +01:00
<h3 class="title"><a name="id2570845" id=
"id2570845"></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 <tt class="varname">MAKECONF</tt> or
<tt class="filename">/etc/mk.conf</tt> 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 <tt class=
"filename">/etc/mk.conf</tt>) in one of the .if*
statements, the file <tt class=
"filename">/etc/mk.conf</tt> must be included before
that .if* statement.</p>
<p>Rather than have a number of ad-hoc ways of
including <tt class="filename">/etc/mk.conf</tt>,
should it exist, or <tt class="varname">MAKECONF</tt>,
should it exist, include the <tt class=
"filename">pkgsrc/mk/bsd.prefs.mk</tt> 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 <tt class=
"varname">CFLAGS</tt> variable in <tt class=
"filename">/etc/mk.conf</tt> please make sure to
use:</p>
<pre class="programlisting">
CFLAGS+= -your -flags
</pre>
<p>Using <tt class="varname">CFLAGS=</tt> (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"
2004-10-22 02:27:55 +02:00
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>
2004-11-02 14:29:15 +01:00
<h3 class="title"><a name="id2570929" id=
"id2570929"></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><tt class="varname">RESTRICTED</tt></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><tt class="varname">NO_BIN_ON_CDROM</tt></p>
<p>Binaries may not be placed on CD-ROM. Set this
variable to <tt class=
"varname">${RESTRICTED}</tt> whenever a binary
package may not be included on a CD-ROM.</p>
</li>
<li>
<p><tt class="varname">NO_BIN_ON_FTP</tt></p>
<p>Binaries may not be placed on an FTP server.
Set this variable to <tt class=
"varname">${RESTRICTED}</tt> whenever a binary
package may not not be made available on the
Internet.</p>
</li>
<li>
<p><tt class="varname">NO_SRC_ON_CDROM</tt></p>
<p>Distfiles may not be placed on CD-ROM. Set
this variable to <tt class=
"varname">${RESTRICTED}</tt> if re-distribution
of the source code or other distfile(s) is not
allowed on CD-ROMs.</p>
</li>
<li>
<p><tt class="varname">NO_SRC_ON_FTP</tt></p>
<p>Distfiles may not be placed on FTP. Set this
variable to <tt class=
"varname">${RESTRICTED}</tt> 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 <tt class=
"varname">NO_PACKAGE</tt>, <tt class=
"varname">IGNORE</tt>, <tt class=
"varname">NO_CDROM</tt>, 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 <tt class=
"varname">BUILD_DEPENDS</tt> and <tt class=
"varname">DEPENDS</tt> definitions, as well as
dependencies via <tt class=
"filename">buildlink3.mk</tt>, 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 <tt class="varname">DEPENDS</tt>
definition registers that pre-requisite in the binary
package so it will be pulled in when the binary package
is later installed, whilst the <tt class=
"varname">BUILD_DEPENDS</tt> 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
<tt class="varname">BUILD_DEPENDS</tt>.</p>
<p>The format for a <tt class=
"varname">BUILD_DEPENDS</tt> and a <tt class=
"varname">DEPENDS</tt> 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 <tt class=
"filename">buildlink3.mk</tt> 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 <tt class=
"filename">buildlink3.mk</tt> file available, use
the <tt class="varname">BUILD_DEPENDS</tt>
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 <tt class=
"filename">buildlink3.mk</tt> file available,
this is specified using the <tt class=
"varname">DEPENDS</tt> 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"
2004-10-22 02:27:55 +02:00
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;
<tt class="varname">DEPENDS</tt>.</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
<tt class="varname">RECOMMENDED</tt>:</p>
<pre class="programlisting">
RECOMMENDED+= tiff&gt;=3.6.1:../../graphics/tiff
</pre>
<p>In addition to the above <tt class=
"varname">DEPENDS</tt> line, this denotes that
while a package will build against
tiff&gt;=3.5.4, at least version 3.6.1 is
recommended. <tt class="varname">RECOMMENDED</tt>
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
<tt class="varname">RECOMMENDED</tt>, 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
<tt class="filename">buildlink3.mk</tt> file,
this is specified using the <tt class=
"varname">DEPENDS</tt> variable. The <a xmlns=
"http://www.w3.org/TR/xhtml1/transitional" href=
"ftp://ftp.NetBSD.org/pub/NetBSD/packages/pkgsrc/print/lyx/README.html"
2004-10-22 02:27:55 +02:00
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"
2004-10-22 02:27:55 +02:00
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 <tt class=
"varname">BUILD_USES_MSGFMT</tt> and <tt class=
"varname">BUILD_USES_GETTEXT_M4</tt> 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"
2004-10-22 02:27:55 +02:00
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>
2004-11-02 14:29:15 +01:00
<h3 class="title"><a name="id2571444" id=
"id2571444"></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 <tt class=
"varname">CONFLICTS</tt> 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"
2004-10-22 02:27:55 +02:00
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 <tt class=
"filename">pkgsrc/x11/Xaw3d/Makefile</tt>:</p>
<pre class="programlisting">
CONFLICTS= Xaw-Xpm-[0-9]*
</pre>
<p>and in <tt class=
"filename">pkgsrc/x11/Xaw-Xpm/Makefile</tt>:</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>
2004-11-02 14:29:15 +01:00
<h3 class="title"><a name="id2571494" id=
"id2571494"></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 <tt class=
"varname">NOT_FOR_PLATFORM</tt>. If the package builds
and runs on a small handful of platforms, set
<tt class="varname">ONLY_FOR_PLATFORM</tt> instead. If
the package should be skipped (for example, because it
provides functionality already provided by the system),
set <tt class="varname">PKG_SKIP_REASON</tt> to a
descriptive message. If the package should fail because
some preconditions are not met, set <tt class=
"varname">PKG_FAIL_REASON</tt> to a descriptive
message.</p>
<p><tt class="varname">IGNORE</tt> 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>
2004-11-02 14:29:15 +01:00
<h3 class="title"><a name="id2571520" id=
"id2571520"></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 <tt class=
"varname">PKG_PRESERVE</tt> 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 <tt class=
"filename">localsrc/security/advisories/pkg-vulnerabilities</tt>,
and after the commit of that file, it should be copied
to both <tt class=
"filename">/pub/NetBSD/packages/distfiles/pkg-vulnerabilities</tt>
and <tt class=
"filename">/pub/NetBSD/packages/distfiles/vulnerabilities</tt>
on ftp.NetBSD.org using <tt class=
"filename">localsrc/security/advisories/Makefile</tt>.
In addition, if a <tt class=
"filename">buildlink3.mk</tt> file exists for an
affected package, bumping <tt class=
"varname">PKGREVISION</tt> and creating a corresponding
<tt class="varname">BUILDLINK_RECOMMENDED.<i class=
"replaceable"><tt>pkg</tt></i></tt> 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 <tt class="filename">buildlink3.mk</tt>
files and <tt class="varname">BUILDLINK_*</tt>
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>
2004-11-02 14:29:15 +01:00
<h3 class="title"><a name="id2571611" id=
"id2571611"></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
<tt class="varname">MACHINE_ARCH</tt> and compiler
version, disabling optimisation for that
file/<tt class="varname">MACHINE_ARCH</tt>/compiler
combination, and documenting it in <tt class=
"filename">pkgsrc/doc/HACKS</tt>. See that file for a
number of examples!</p>
</div>
<div class="sect2" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
2004-11-02 14:29:15 +01:00
<h3 class="title"><a name="id2571634" id=
"id2571634"></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 <tt class=
"varname">PKGNAME</tt>. 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
<tt class="varname">PKGREVISION=1</tt> (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 <tt class="varname">PKGNAME</tt> of
&#8220;<span class=
"quote">foo-17.42nb9</span>&#8221;.</p>
<p>When a new release of the package is released, the
<tt class="varname">PKGREVISION</tt> 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>
2004-11-02 14:29:15 +01:00
<h3 class="title"><a name="id2571751" id=
"id2571751"></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>
2004-11-02 14:29:15 +01:00
<h4 class="title"><a name="id2571756" id=
"id2571756"></a>12.1.10.1.&nbsp;${INSTALL},
${INSTALL_DATA_DIR}, ...</h4>
</div>
</div>
</div>
<p>The BSD-compatible <span><b class=
"command">install</b></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=
2004-11-02 14:29:15 +01:00
"id2571776" id="id2571776"></a>12.2.&nbsp;Possible
downloading issues</h2>
</div>
</div>
</div>
<div class="sect2" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
2004-11-02 14:29:15 +01:00
<h3 class="title"><a name="id2571779" id=
"id2571779"></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 <tt class="varname">DYNAMIC_MASTER_SITES</tt> and a
<span><b class="command">make fetch</b></span> will
call <tt class="filename">files/getsite.sh</tt> 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"
2004-10-22 02:27:55 +02:00
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 <tt class="varname">_FETCH_MESSAGE</tt> to a
macro which displays a message explaining the
situation. <tt class="varname">_FETCH_MESSAGE</tt> must
be executable shell commands, not just a message.
(Generally, it executes <tt class=
"varname">${ECHO}</tt>). 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"
2004-10-22 02:27:55 +02:00
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>
2004-11-02 14:29:15 +01:00
<h3 class="title"><a name="id2571978" id=
"id2571978"></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 <tt class=
"filename">/pub/NetBSD/packages/distfiles</tt>
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=
2004-11-02 14:29:15 +01:00
"id2571990" id=
"id2571990"></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"
2004-10-22 02:27:55 +02:00
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 <tt class="varname">USE_LIBTOOL=yes</tt>
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
<tt class="varname">CC</tt>, 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
<tt class="filename">.la</tt> extension, and the
objects are changed to have a <tt class=
"filename">.lo</tt> extension. Change <tt class=
"varname">OBJS</tt> as necessary. This
automatically creates all of the <tt class=
"filename">.a</tt>, <tt class=
"filename">.so.major.minor</tt>, 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 <tt class="filename">PLIST</tt>,
include all of the <tt class="filename">.a</tt>,
<tt class="filename">.la</tt>, and <tt class=
"filename">.so</tt>, <tt class=
"filename">.so.<i class=
"replaceable"><tt>major</tt></i></tt> and
<tt class="filename">.so.<i class=
"replaceable"><tt>major</tt></i>.<i class=
"replaceable"><tt>minor</tt></i></tt> files.</p>
</li>
<li>
<p>When linking shared object (<tt class=
"filename">.so</tt>) 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 <tt class="filename">PLIST</tt> file gets
the <tt class="filename">foo.so</tt> 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
<tt class="filename">.la</tt> 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 <i class=
"replaceable"><tt>someprog</tt></i> <i class=
"replaceable"><tt>../somelib/somelib.la</tt></i>
</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 <tt class="filename">.la</tt>.
e.g.</p>
<pre class="programlisting">
${LIBTOOL} --mode=install ${BSD_INSTALL_DATA} ${SOMELIB:.a=.la} ${PREFIX}/lib
</pre>
<p>This will install the static <tt class=
"filename">.a</tt>, 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 <tt class="filename">PLIST</tt>,
include all of the <tt class="filename">.a</tt>,
<tt class="filename">.la</tt>, and <tt class=
"filename">.so</tt>, <tt class=
"filename">.so.CURRENT</tt> and <tt class=
"filename">.so.CURRENT.REVISION</tt> 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>
2004-11-02 14:29:15 +01:00
<h3 class="title"><a name="id2572397" id=
"id2572397"></a>12.3.2.&nbsp;Using libtool on GNU
packages that already support libtool</h3>
</div>
</div>
</div>
<p>Add <tt class="varname">USE_LIBTOOL=yes</tt> 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><b class="command">make
configure; find work*/ -name libtool</b></span>.</p>
<p><tt class="varname">LIBTOOL_OVERRIDE</tt> specifies
which libtool scripts, relative to <tt class=
"varname">WRKSRC</tt>, 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 <tt class="filename">*.a</tt>
static libraries built and installed, then use
<tt class="varname">SHLIBTOOL_OVERRIDE</tt>
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 <tt class=
"varname">USE_BUILDLINK3=YES</tt>).</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. <tt class="filename">libfoo.la</tt>,
not <tt class="filename">foo.la</tt></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
<tt class=
"varname">LTDL_SET_PRELOADED_SYMBOLS</tt>
included in executables.</p>
</li>
</ul>
</div>
</div>
<div class="sect2" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
2004-11-02 14:29:15 +01:00
<h3 class="title"><a name="id2572482" id=
"id2572482"></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 <tt class=
"filename">pkgsrc/mk/autoconf.mk</tt> and <tt class=
"filename">pkgsrc/mk/automake.mk</tt> 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 <tt class=
"filename">mk/automake.mk</tt>.</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 <tt class=
"varname">AUTOMAKE_OVERRIDE=NO</tt> 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=
2004-11-02 14:29:15 +01:00
"id2572526" id="id2572526"></a>12.4.&nbsp;Building
considerations</h2>
</div>
</div>
</div>
<div class="sect2" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
2004-11-02 14:29:15 +01:00
<h3 class="title"><a name="id2572530" id=
"id2572530"></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 <tt class=
"filename">&lt;sys/param.h&gt;</tt> 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=
2004-11-02 14:29:15 +01:00
"id2572560" id="id2572560"></a>12.5.&nbsp;Package
specific actions</h2>
</div>
</div>
</div>
<div class="sect2" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
2004-11-02 14:29:15 +01:00
<h3 class="title"><a name="id2572563" id=
"id2572563"></a>12.5.1.&nbsp;Package
configuration files</h3>
</div>
</div>
</div>
<p>Packages should be taught to look for their
configuration files in <tt class=
"varname">${PKG_SYSCONFDIR}</tt>, which is passed
through to the configure and build processes.
<tt class="varname">PKG_SYSCONFDIR</tt> may be
customized in various ways by setting other make
variables:</p>
<div class="itemizedlist">
<ul type="disc">
<li>
<p><tt class="varname">PKG_SYSCONFBASE</tt> is
the main config directory under which all package
configuration files are to be found. This
defaults to <tt class=
"filename">${PREFIX}/etc</tt>, but may be
overridden in <tt class=
"filename">/etc/mk.conf</tt>.</p>
</li>
<li>
<p><tt class="varname">PKG_SYSCONFSUBDIR</tt> is
the subdirectory of <tt class=
"varname">PKG_SYSCONFBASE</tt> under which the
configuration files for a particular package may
be found, e.g. the Apache configuration files may
all be found under the <tt class=
"filename">httpd/</tt> subdirectory of <tt class=
"varname">${PKG_SYSCONFBASE}</tt>. This should be
set in the package Makefile.</p>
</li>
<li>
<p>By default, <tt class=
"varname">PKG_SYSCONFDIR</tt> is set to
<tt class="varname">${PKG_SYSCONFBASE}/${PKG_SYSCONFSUBDIR}</tt>,
but this may be overridden by setting <tt class=
"varname">PKG_SYSCONFDIR.${PKG_SYSCONFVAR}</tt>
for a particular package, where <tt class=
"varname">PKG_SYSCONFVAR</tt> defaults to
<tt class="varname">${PKGBASE}</tt>. This is not
meant to be set by a package Makefile, but is
reserved for users who wish to override the
<tt class="varname">PKG_SYSCONFDIR</tt> setting
for a particular package with a special
location.</p>
</li>
</ul>
</div>
<p>The only variables that users should customize are
<tt class="varname">PKG_SYSCONFBASE</tt> and <tt class=
"varname">PKG_SYSCONFDIR.${PKG_SYSCONFVAR}</tt>. Users
will typically want to set <tt class=
"varname">PKG_SYSCONFBASE</tt> to <tt class=
"filename">/etc</tt>, or to accept the default location
of <tt class="filename">${PREFIX}/etc</tt>.</p>
</div>
<div class="sect2" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
2004-11-02 14:29:15 +01:00
<h3 class="title"><a name="id2572733" id=
"id2572733"></a>12.5.2.&nbsp;User
2004-10-22 02:27:55 +02:00
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 <tt class="varname">INTERACTIVE_STAGE</tt>
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 <tt class=
"filename">Makefile</tt>. 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>
2004-11-02 14:29:15 +01:00
<h3 class="title"><a name="id2572778" id=
"id2572778"></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 <tt class="varname">LICENSE</tt>
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"
2004-10-22 02:27:55 +02:00
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">
<tt class="prompt">%</tt> <b class="userinput"><tt>make</tt></b>
===&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><b class=
"command">make show-license</b></span>, and if it is
considered appropriate, the line printed above can be
added to <tt class="filename">/etc/mk.conf</tt> 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 <tt class=
"filename">pkgsrc/licenses</tt> for displaying. A list
of known licenses can be seen in this directory as well
as by looking at the list of (commented out) <tt class=
"varname">ACCEPTABLE_LICENSES</tt> variable settings in
<tt class=
"filename">pkgsrc/mk/bsd.pkg.defaults.mk</tt>.</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 <tt class=
"varname">_ACCEPTABLE=yes</tt>.</p>
</div>
<div class="sect2" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
2004-11-02 14:29:15 +01:00
<h3 class="title"><a name="id2572861" id=
"id2572861"></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 <tt class=
"varname">PKG_GROUPS</tt>, which is a list of
group[:groupid] elements, where the groupid is
optional. The second is <tt class=
"varname">PKG_USERS</tt>, 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
<tt class="filename">/nonexistent</tt>, and login shell
<tt class="filename">/sbin/nologin</tt> unless they are
specified as part of the user element.</p>
<p>The package <tt class="filename">Makefile</tt> must
also set <tt class="varname">USE_PKGINSTALL=YES</tt>.
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 <tt class=
"varname">PKG_CREATE_USERGROUP</tt> variable prior to
package installation.</p>
</div>
<div class="sect2" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
2004-11-02 14:29:15 +01:00
<h3 class="title"><a name="id2572992" id=
"id2572992"></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
<tt class="filename">mk/bsd.pkg.defaults.mk</tt>,
control this behaviour: <tt class=
"varname">SETGIDGAME</tt>, <tt class=
"varname">GAMEDATAMODE</tt>, <tt class=
"varname">GAMEGRP</tt>, <tt class=
"varname">GAMEMODE</tt>, <tt class=
"varname">GAMEOWN</tt>.</p>
<p>Note that per default, setgid installation of games
is disabled; setting <tt class=
"varname">SETGIDGAME=YES</tt> will set all the other
variables accordingly.</p>
<p>A package should therefor never hard code file
ownership or access permissions but rely on <tt class=
"varname">INSTALL_GAME</tt> and <tt class=
"varname">INSTALL_GAME_DATA</tt> to set these
correctly.</p>
</div>
<div class="sect2" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
2004-11-02 14:29:15 +01:00
<h3 class="title"><a name="id2573035" id=
"id2573035"></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 <tt class="varname">PKG_SHELL</tt>
should contain the full pathname of the shell
executable installed by this package. The package
<tt class="filename">Makefile</tt> must also set
<tt class="varname">USE_PKGINSTALL=YES</tt> to use the
automatically generated <tt class=
"filename">INSTALL</tt>/<tt class=
"filename">DEINSTALL</tt> 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 <tt class=
"filename">/etc/shells</tt> file automatically in the
post-install target by the generated <tt class=
"filename">INSTALL</tt> script and removed in the
deinstall target by the <tt class=
"filename">DEINSTALL</tt> script.</p>
</div>
<div class="sect2" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
2004-11-02 14:29:15 +01:00
<h3 class="title"><a name="id2573161" id=
"id2573161"></a>12.5.7.&nbsp;Packages containing
perl scripts</h3>
</div>
</div>
</div>
<p>If your package contains interpreted perl scripts,
set <tt class="varname">REPLACE_PERL</tt> to ensure
that the proper interpreter path is set. <tt class=
"varname">REPLACE_PERL</tt> should contain a list of
scripts, relative to <tt class="varname">WRKSRC</tt>,
that you want adjusted.</p>
</div>
<div class="sect2" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
2004-11-02 14:29:15 +01:00
<h3 class="title"><a name="id2573248" id=
"id2573248"></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 <tt class="filename">Makefile</tt> (we shall
use <span><b class="command">tclsh</b></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>
2004-11-02 14:29:15 +01:00
<h3 class="title"><a name="id2573269" id=
"id2573269"></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 <tt class=
"filename">../../lang/perl5/module.mk</tt>. It provides
a <span><b class="command">do-configure</b></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 <tt class="filename">PLIST</tt> corresponding to
the files listed in the installed <tt class=
"filename">.packlist</tt> file generated by most perl5
modules. This is invoked by defining <tt class=
"varname">PERL5_PACKLIST</tt> 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 <tt class=
"varname">PERL5_SITELIB</tt>, <tt class=
"varname">PERL5_SITEARCH</tt>, and <tt class=
"varname">PERL5_ARCHLIB</tt> 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 <tt class="filename">PLIST</tt>.</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
<tt class=
"filename">${PREFIX}/${INFO_DIR}</tt>,</p>
</li>
<li>
<p>is registered in the Info directory file
<tt class=
"filename">${PREFIX}/${INFO_DIR}/dir</tt>,</p>
</li>
<li>
<p>and must be listed as a filename in the
<tt class="varname">INFO_FILES</tt> variable in
the package Makefile.</p>
</li>
</ul>
</div>
<p><tt class="varname">INFO_DIR</tt> defaults to
&#8220;<span class="quote">info</span>&#8221; and can
be overridden in the package Makefile. <tt class=
"filename">INSTALL</tt> and <tt class=
"filename">DEINSTALL</tt> 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 <tt class=
"varname">USE_MAKEINFO</tt> 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 <tt class=
"varname">TEXINFO_REQD</tt> variable in the package
<tt class="filename">Makefile</tt>. By default, a
minimum version of 3.12 is required. If the system does
not provide a <span><b class=
"command">makeinfo</b></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"
2004-10-22 02:27:55 +02:00
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><b class="command">install-info</b></span>
command as the registration of info files is the task
of the package <tt class="filename">INSTALL</tt>
script, and it must use the appropriate <span><b class=
"command">makeinfo</b></span> command.</p>
<p>To achieve this goal the pkgsrc infrastructure
creates overriding scripts for the <span><b class=
"command">install-info</b></span> and <span><b class=
"command">makeinfo</b></span> commands in a directory
listed early in <tt class="varname">PATH</tt>.</p>
<p>The script overriding <span><b class=
"command">install-info</b></span> has no effect except
the logging of a message. The script overriding
<span><b class="command">makeinfo</b></span> logs a
message and according to the value of <tt class=
"varname">USE_MAKEINFO</tt> and <tt class=
"varname">TEXINFO_REQD</tt> either run the appropriate
<span><b class="command">makeinfo</b></span> command or
exit on error.</p>
</div>
<div class="sect2" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
2004-11-02 14:29:15 +01:00
<h3 class="title"><a name="id2573557" id=
"id2573557"></a>12.5.11.&nbsp;Packages installing
GConf2 data files</h3>
</div>
</div>
</div>
<p>If a package installs <tt class=
"filename">.schemas</tt> or <tt class=
"filename">.entries</tt> 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 <tt class=
"filename">../../devel/GConf2/schemas.mk</tt>
instead of its <tt class=
"filename">buildlink3.mk</tt> 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
<tt class="filename">.schemas</tt> files under
<tt class=
"filename">${PREFIX}/share/gconf/schemas</tt>. If
they get installed under <tt class=
"filename">${PREFIX}/etc</tt>, 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.13.&nbsp;Configuration files handling and placement">
Section&nbsp;6.13, &#8220;Configuration files
handling and placement&#8221;</a> for more
information.</p>
</li>
<li>
<p>Define the <tt class=
"varname">GCONF2_SCHEMAS</tt> variable in your
<tt class="filename">Makefile</tt> with a list of
all <tt class="filename">.schemas</tt> files
installed by the package, if any. Names must not
contain any directories in them.</p>
</li>
<li>
<p>Define the <tt class=
"varname">GCONF2_ENTRIES</tt> variable in your
<tt class="filename">Makefile</tt> with a list of
all <tt class="filename">.entries</tt> 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>
2004-11-02 14:29:15 +01:00
<h3 class="title"><a name="id2573657" id=
"id2573657"></a>12.5.12.&nbsp;Packages installing
scrollkeeper data files</h3>
</div>
</div>
</div>
<p>If a package installs <tt class="filename">.omf</tt>
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 <tt class=
"filename">../../textproc/scrollkeeper/omf.mk</tt>
instead of its <tt class=
"filename">buildlink3.mk</tt> 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 <tt class=
"filename">libdata/scrollkeeper</tt> directory,
as they will be handled automatically.</p>
</li>
<li>
<p>Remove the <tt class="filename">share/omf</tt>
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>
2004-11-02 14:29:15 +01:00
<h3 class="title"><a name="id2573708" id=
"id2573708"></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 <tt class=
"filename">mk/fonts.mk</tt>, which you need to include
in your <tt class="filename">Makefile</tt>.</p>
<p>When the file is included, you can list the
directories where fonts are installed in the <tt class=
"varname">FONTS_<i class=
"replaceable"><tt>type</tt></i>_DIRS</tt> variables,
where <i class="replaceable"><tt>type</tt></i> 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 <tt class=
"filename">fonts.dir</tt> 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>
2004-11-02 14:29:15 +01:00
<h3 class="title"><a name="id2573824" id=
"id2573824"></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 <tt class=
"filename">../../x11/gtk2/modules.mk</tt> instead
of its <tt class="filename">buildlink3.mk</tt>
file. This takes care of rebuilding the database
at installation and deinstallation time.</p>
</li>
<li>
<p>Set <tt class=
"varname">GTK2_IMMODULES=YES</tt> if your package
installs GTK2 immodules.</p>
</li>
<li>
<p>Set <tt class="varname">GTK2_LOADERS=YES</tt>
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><tt class=
"filename">libdata/gtk-2.0/gdk-pixbuf.loaders</tt></p>
</li>
<li>
<p><tt class=
"filename">libdata/gtk-2.0/gtk.immodules</tt></p>
</li>
</ul>
</div>
</li>
<li>
<p>Check the PLIST and remove any entries under
the <tt class="filename">libdata/gtk-2.0</tt>
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>
2004-11-02 14:29:15 +01:00
<h3 class="title"><a name="id2573893" id=
"id2573893"></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 <tt class=
"filename">../../textproc/xmlcatmgr/catalogs.mk</tt>
in your <tt class="filename">Makefile</tt>, which
takes care of registering those files in
system-wide catalogs at installation and
deinstallation time.</p>
</li>
<li>
<p>Set <tt class="varname">SGML_CATALOGS</tt> to
the full path of any SGML catalogs installed by
the package.</p>
</li>
<li>
<p>Set <tt class="varname">XML_CATALOGS</tt> to
the full path of any XML catalogs installed by
the package.</p>
</li>
<li>
<p>Set <tt class="varname">SGML_ENTRIES</tt> 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 <tt class="varname">XML_ENTRIES</tt> 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>
2004-11-02 14:29:15 +01:00
<h3 class="title"><a name="id2573945" id=
"id2573945"></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 <tt class="filename">.xml</tt>
files inside <tt class=
"filename">${PREFIX}/share/mime/packages</tt>, 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 <tt class=
"filename">../../databases/shared-mime-info/mimedb.mk</tt>
(avoid using the <tt class=
"filename">buildlink3.mk</tt> file from this same
directory, which is reserved for inclusion from
other <tt class="filename">buildlink3.mk</tt>
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 <tt class="filename">share/mime</tt>
directory, <span class=
"emphasis"><em>except</em></span> for files saved
under <tt class=
"filename">share/mime/packages</tt>. 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 <tt class=
"filename">share/mime/*</tt> 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>
2004-11-02 14:29:15 +01:00
<h3 class="title"><a name="id2574016" id=
"id2574016"></a>12.5.17.&nbsp;Packages using
intltool</h3>
</div>
</div>
</div>
<p>If a package uses intltool during its build, include
the <tt class=
"filename">../../textproc/intltool/buildlink3.mk</tt>
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=
2004-11-02 14:29:15 +01:00
"id2574029" id="id2574029"></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 <tt class=
"varname">PKG_DEVELOPER=1</tt> in <tt class=
"filename">/etc/mk.conf</tt></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"
2004-10-22 02:27:55 +02:00
class="pkgname">pkgtools/url2pkg</a>, create a
directory for a new package, change into it, then
run <span><b class=
"command">url2pkg</b></span>:</p>
<pre class="screen">
<tt class="prompt">%</tt> <b class=
"userinput"><tt>mkdir /usr/pkgsrc/<i class=
"replaceable"><tt>category</tt></i>/<i class=
"replaceable"><tt>examplepkg</tt></i></tt></b>
<tt class="prompt">%</tt> <b class=
"userinput"><tt>cd /usr/pkgsrc/<i class=
"replaceable"><tt>category</tt></i>/<i class=
"replaceable"><tt>examplepkg</tt></i></tt></b>
<tt class="prompt">%</tt> <b class=
"userinput"><tt>url2pkg http://www.example.com/path/to/distfile.tar.gz</tt></b>
</pre>
</li>
<li>
<p>Edit the <tt class="filename">Makefile</tt> as
requested.</p>
</li>
<li>
<p>Fill in the <tt class="filename">DESCR</tt>
file</p>
</li>
<li>
<p>Run <span><b class="command">make
configure</b></span></p>
</li>
<li>
<p>Add any dependencies glimpsed from documentation
and the configure step to the package's <tt class=
"filename">Makefile</tt>.</p>
</li>
<li>
<p>Make the package compile, doing multiple rounds
of</p>
<pre class="screen">
<tt class="prompt">%</tt> <b class="userinput"><tt>make</tt></b>
<tt class="prompt">%</tt> <b class=
"userinput"><tt>pkgvi ${WRKSRC}/some/file/that/does/not/compile</tt></b>
<tt class="prompt">%</tt> <b class=
"userinput"><tt>mkpatches</tt></b>
<tt class="prompt">%</tt> <b class=
"userinput"><tt>patchdiff</tt></b>
<tt class="prompt">%</tt> <b class=
"userinput"><tt>mv ${WRKDIR}/.newpatches/* patches</tt></b>
<tt class="prompt">%</tt> <b class=
"userinput"><tt>make mps</tt></b>
<tt class="prompt">%</tt> <b class=
"userinput"><tt>make clean</tt></b>
</pre>
<p>Doing as non-root user will ensure that no files
are modified that shouldn't be, especially during the
build phase. <span><b class=
"command">mkpatches</b></span>, <span><b class=
"command">patchdiff</b></span> and <span><b class=
"command">pkgvi</b></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"
2004-10-22 02:27:55 +02:00
class="pkgname">pkgtools/pkgdiff</a> package.</p>
</li>
<li>
<p>Look at the <tt class="filename">Makefile</tt>,
fix if necessary; see <a href="#components.Makefile"
title="7.1.&nbsp;Makefile">Section&nbsp;7.1,
&#8220;Makefile&#8221;</a>.</p>
</li>
<li>
<p>Generate a <tt class="filename">PLIST</tt>:</p>
<pre class="screen">
<tt class="prompt">#</tt> <b class=
"userinput"><tt>make install</tt></b>
<tt class="prompt">#</tt> <b class=
"userinput"><tt>make print-PLIST &gt;PLIST</tt></b>
<tt class="prompt">#</tt> <b class=
"userinput"><tt>make deinstall</tt></b>
<tt class="prompt">#</tt> <b class=
"userinput"><tt>make install</tt></b>
<tt class="prompt">#</tt> <b class=
"userinput"><tt>make deinstall</tt></b>
</pre>
<p>You usually need to be <tt class=
"username">root</tt> to do this. Look if there are
any files left:</p>
<pre class="screen">
<tt class="prompt">#</tt> <b class=
"userinput"><tt>make print-PLIST</tt></b>
</pre>
<p>If this reveals any files that are missing in
<tt class="filename">PLIST</tt>, add them.</p>
</li>
<li>
<p>Now that the <tt class="filename">PLIST</tt> is
OK, install the package again and make a binary
package:</p>
<pre class="screen">
<tt class="prompt">#</tt> <b class=
"userinput"><tt>make reinstall</tt></b>
<tt class="prompt">#</tt> <b class=
"userinput"><tt>make package</tt></b>
</pre>
</li>
<li>
<p>Delete the installed package:</p>
<pre class="screen">
<tt class="prompt">#</tt> <b class=
"userinput"><tt>pkg_delete blub</tt></b>
</pre>
</li>
<li>
<p>Repeat the above <span><b class="command">make
print-PLIST</b></span> command, which shouldn't find
anything now:</p>
<pre class="screen">
<tt class="prompt">#</tt> <b class=
"userinput"><tt>make print-PLIST</tt></b>
</pre>
</li>
<li>
<p>Reinstall the binary package:</p>
<pre class="screen">
<tt class="prompt">#</tt> <b class=
"userinput"><tt>pkgadd .../blub.tgz</tt></b>
</pre>
</li>
<li>
<p>Play with it. Make sure everything works.</p>
</li>
<li>
<p>Run <span><b class="command">pkglint</b></span>
from <a xmlns=
"http://www.w3.org/TR/xhtml1/transitional" href=
"ftp://ftp.NetBSD.org/pub/NetBSD/packages/pkgsrc/pkgtools/pkglint/README.html"
2004-10-22 02:27:55 +02:00
class="pkgname">pkgtools/pkglint</a>, and fix the
problems it reports:</p>
<pre class="screen">
<tt class="prompt">#</tt> <b class="userinput"><tt>pkglint</tt></b>
</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>
2004-11-02 14:29:15 +01:00
<dt><span class="sect1"><a href="#id2574491">14.1.
Submitting your packages</a></span></dt>
2004-11-02 14:29:15 +01:00
<dt><span class="sect1"><a href="#id2574538">14.2.
Committing: Importing a package into
CVS</a></span></dt>
2004-11-02 14:29:15 +01:00
<dt><span class="sect1"><a href="#id2574738">14.3.
2004-10-22 02:27:55 +02:00
Updating a package to a newer version</a></span></dt>
2004-11-02 14:29:15 +01:00
<dt><span class="sect1"><a href="#id2574825">14.4.
2004-10-22 02:27:55 +02:00
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=
2004-11-02 14:29:15 +01:00
"id2574491" id=
"id2574491"></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
piss anyone off 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.</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><b class=
"command">send-pr</b></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=
2004-11-02 14:29:15 +01:00
"id2574538" id=
"id2574538"></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><b class="command">cvs import</b></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 <tt class="filename">Makefile</tt>.</p>
<p>The commit message of the initial import should
include part of the <tt class="filename">DESCR</tt> file,
so people reading the mailing lists know what the package
is/does.</p>
<p>Please note all package updates/additions in
<tt class="filename">pkgsrc/doc/CHANGES</tt>. 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=
2004-11-02 14:29:15 +01:00
"id2574738" id="id2574738"></a>14.3.&nbsp;Updating
2004-10-22 02:27:55 +02:00
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=
2004-11-02 14:29:15 +01:00
"id2574825" id="id2574825"></a>14.4.&nbsp;Moving a
2004-10-22 02:27:55 +02:00
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">
<tt class="prompt">%</tt> <b class=
"userinput"><tt>cvs -d user@cvs.NetBSD.org:/cvsroot export -D today pkgsrc/category/package</tt></b>
</pre>
<p>and use that for further work.</p>
</li>
<li>
<p>Fix <tt class="varname">CATEGORIES</tt> and any
<tt class="varname">DEPENDS</tt> 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><b class="command">cvs import</b></span>
the modified package in the new place.</p>
</li>
<li>
<p>Check if any package depends on it:</p>
<pre class="screen">
<tt class="prompt">%</tt> <b class=
"userinput"><tt>cd /usr/pkgsrc</tt></b>
<tt class="prompt">%</tt> <b class=
"userinput"><tt>grep /package */*/Makefile* */*/buildlink*</tt></b>
</pre>
</li>
<li>
<p>Fix paths in packages from step 5 to point to
new location.</p>
</li>
<li>
<p><span><b class="command">cvs rm (-f)</b></span>
the package at the old location.</p>
</li>
<li>
<p>Remove from <tt class=
"filename">oldcategory/Makefile</tt>.</p>
</li>
<li>
<p>Add to <tt class=
"filename">newcategory/Makefile</tt>.</p>
</li>
<li>
<p>Commit the changed and removed files:</p>
<pre class="screen">
<tt class="prompt">%</tt> <b class=
"userinput"><tt>cvs commit oldcategory/package oldcategory/Makefile newcategory/Makefile</tt></b>
</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>
2004-11-02 14:29:15 +01:00
<dt><span class="sect1"><a href="#id2575051">A.1.
files</a></span></dt>
<dd>
<dl>
2004-11-02 14:29:15 +01:00
<dt><span class="sect2"><a href="#id2575054">A.1.1.
Makefile</a></span></dt>
2004-11-02 14:29:15 +01:00
<dt><span class="sect2"><a href="#id2575062">A.1.2.
DESCR</a></span></dt>
2004-11-02 14:29:15 +01:00
<dt><span class="sect2"><a href="#id2575077">A.1.3.
PLIST</a></span></dt>
2004-11-02 14:29:15 +01:00
<dt><span class="sect2"><a href="#id2575084">A.1.4.
Checking a package with pkglint</a></span></dt>
</dl>
</dd>
2004-11-02 14:29:15 +01:00
<dt><span class="sect1"><a href="#id2575193">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><b class="command">bison</b></span>
when Berkeley <span><b class="command">yacc</b></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=
2004-11-02 14:29:15 +01:00
"id2575051" id="id2575051"></a>A.1.&nbsp;files</h2>
</div>
</div>
</div>
<div class="sect2" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
2004-11-02 14:29:15 +01:00
<h3 class="title"><a name="id2575054" id=
"id2575054"></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>
2004-11-02 14:29:15 +01:00
<h3 class="title"><a name="id2575062" id=
"id2575062"></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>
2004-11-02 14:29:15 +01:00
<h3 class="title"><a name="id2575077" id=
"id2575077"></a>A.1.3.&nbsp;PLIST</h3>
</div>
</div>
</div>
<pre class="programlisting">
@comment $NetBSD$
bin/bison
man/man1/bison.1.gz
info/bison.info
info/bison.info-1
info/bison.info-2
info/bison.info-3
info/bison.info-4
info/bison.info-5
share/bison.simple
share/bison.hairy
</pre>
</div>
<div class="sect2" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
2004-11-02 14:29:15 +01:00
<h3 class="title"><a name="id2575084" id=
"id2575084"></a>A.1.4.&nbsp;Checking a package with
<span><b class="command">pkglint</b></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"
2004-10-22 02:27:55 +02:00
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><b class="command">pkglint</b></span>:</p>
<pre class="screen">
<tt class="prompt">$</tt> <b class="userinput"><tt>pkglint</tt></b>
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><b class="command">pkglint -v</b></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=
2004-11-02 14:29:15 +01:00
"id2575193" id="id2575193"></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">
<tt class="prompt">#</tt> <b class=
"userinput"><tt>cd /usr/pkgsrc/lang</tt></b>
<tt class="prompt">#</tt> <b class=
"userinput"><tt>mkdir bison</tt></b>
<tt class="prompt">#</tt> <b class=
"userinput"><tt>cd bison</tt></b>
<tt class="prompt">#</tt> <b class=
"userinput"><tt>mkdir patches</tt></b>
</pre>
<p>Create <tt class="filename">Makefile</tt>, <tt class=
"filename">DESCR</tt> and <tt class="filename">PLIST</tt>
(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">
<tt class="prompt">#</tt> <b class=
"userinput"><tt>make fetch</tt></b>
&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 <tt class=
"filename">distinfo</tt>:</p>
<pre class="screen">
<tt class="prompt">#</tt> <b class=
"userinput"><tt>make makesum</tt></b>
</pre>
<p>Now compile:</p>
<pre class="screen">
<tt class="prompt">#</tt> <b class="userinput"><tt>make</tt></b>
&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">
<tt class="prompt">#</tt> <b class=
"userinput"><tt>make install</tt></b>
&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><b class="command">pkg_delete
bison</b></span>. Should you decide that you want a binary
package, do this now:</p>
<pre class="screen">
<tt class="prompt">#</tt> <b class=
"userinput"><tt>make package</tt></b>
&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">
<tt class="prompt">#</tt> <b class=
"userinput"><tt>make clean</tt></b>
===&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">
<tt class="prompt">#</tt> <b class="userinput"><tt>make</tt></b>
===&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.
<tt class="prompt">#</tt>
<tt class="prompt">#</tt> <b class=
"userinput"><tt>make install</tt></b>
===&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
<tt class="prompt">#</tt>
</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">
<tt class="prompt">#</tt> <b class=
"userinput"><tt>make package</tt></b>
===&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:.
<tt class="prompt">#</tt>
</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-2004Q3/\ # pkgsrc-branch
`uname -s`-`uname -r`/ # OS &amp; version
`uname -p` # architecture
</pre>
</li>
<li>
<p>If necessary, create a symlink <span><b class=
"command">ln -s `uname -m` `uname -p`</b></span> (amiga
-&gt; m68k, ...)</p>
</li>
</ol>
</div>
</div>
2004-10-22 02:27:55 +02:00
<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>
2004-11-02 14:29:15 +01:00
<dt><span class="sect1"><a href="#id2575976">D.1.
2004-10-22 02:27:55 +02:00
Targets</a></span></dt>
2004-11-02 14:29:15 +01:00
<dt><span class="sect1"><a href="#id2576025">D.2.
2004-10-22 02:27:55 +02:00
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=
2004-11-02 14:29:15 +01:00
"id2575976" id="id2575976"></a>D.1.&nbsp;Targets</h2>
2004-10-22 02:27:55 +02:00
</div>
</div>
</div>
<p>The pkgsrc guide's source code is stored in <tt class=
"filename">pkgsrc/doc/guide/files</tt>, and several files
are created from it:</p>
<div class="itemizedlist">
<ul type="disc">
<li>
<p><tt class="filename">pkgsrc/doc/pkgsrc.txt</tt>,
which replaces <tt class=
"filename">pkgsrc/Packages.txt</tt></p>
</li>
<li>
<p><tt class=
"filename">pkgsrc/doc/pkgsrc.html</tt></p>
</li>
<li>
<p><tt class=
"filename">http://www.NetBSD.org/Documentation/pkgsrc/</tt>:
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>
</ul>
</div>
</div>
<div class="sect1" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h2 class="title" style="clear: both"><a name=
2004-11-02 14:29:15 +01:00
"id2576025" id=
"id2576025"></a>D.2.&nbsp;Procedure</h2>
2004-10-22 02:27:55 +02:00
</div>
</div>
</div>
<p>The procedure to edit the pkgsrc guide is:</p>
<div class="itemizedlist">
<ul type="disc">
<li>
<p>Edit the XML file(s) in <tt class=
"filename">pkgsrc/doc/guide/files</tt></p>
</li>
<li>
<p>Run <span><b class="command">make</b></span> in
<tt class="filename">pkgsrc/doc/guide</tt> to build
the HTML and ASCII version</p>
</li>
<li>
<p>Run <span><b class="command">make
OUTPUT=pdf</b></span> in <tt class=
"filename">pkgsrc/doc/guide</tt> to build the PDF
version. Dont' omit this, as this does a very strict
SGML test, and doing this properly is important for
getting proper documentation on the web server!</p>
</li>
<li>
<p>If all is well, run <span><b class="command">make
install-doc</b></span> to put the generated files
into <tt class="filename">pkgserc/doc</tt>.</p>
</li>
<li>
<p><span><b class="command">cvs commit
pkgsrc/doc/guide/files</b></span></p>
</li>
<li>
<p><span><b class="command">cvs commit
pkgsrc/doc/pkgsrc.{html,txt}</b></span></p>
</li>
</ul>
</div>
</div>
</div>
</div>
</body>
</html>