kpriv/pkgsrc
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity
pkgsrc/pkgsrc.html
grant 4aa2816ede use the stylesheet from www.NetBSD.org -- if you don't have web 
access, you won't get the pretty styles.
2003-06-23 07:49:44 +00:00

5198 lines
218 KiB
HTML
Raw Blame History

This file contains invisible Unicode characters

This file contains invisible Unicode characters that are indistinguishable to humans but may be processed differently by a computer. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title>The NetBSD Packages Collection (pkgsrc)</title>
<link rel="stylesheet" href="http://www.NetBSD.org/NetBSD.css" type="text/css">
<meta name="generator" content="DocBook XSL Stylesheets V1.60.1">
<meta name="description" content="Information about using the NetBSD package system and
building packages.">
</head>
<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="book" lang="en">
<div class="titlepage">
<div>
<div><h1 class="title">
<a name="id2856616"></a>The NetBSD Packages Collection (pkgsrc)</h1></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>
</div></div>
<div><p class="releaseinfo">$NetBSD: pkgsrc.html,v 1.2 2003/06/23 07:49:44 grant Exp $</p></div>
<div><p class="copyright">Copyright © 1994-2003 The NetBSD Foundation, Inc</p></div>
<div><div class="abstract">
<p class="title"><b>Abstract</b></p>
<p>Information about using the NetBSD package system and
building packages.</p>
</div></div>
</div>
<div></div>
<hr>
</div>
<div class="toc">
<p><b>Table of Contents</b></p>
<dl>
<dt>1. <a href="#introduction">Introduction</a>
</dt>
<dd><dl>
<dt>1.1. <a href="#id2862064">Introduction</a>
</dt>
<dt>1.2. <a href="#overview">Overview</a>
</dt>
<dt>1.3. <a href="#terminology">Terminology</a>
</dt>
<dt>1.4. <a href="#typography">Typography</a>
</dt>
</dl></dd>
<dt>I. <a href="#users-guide">pkgsrc user's guide</a>
</dt>
<dd><dl>
<dt>2. <a href="#platforms">Using pkgsrc on systems other than NetBSD</a>
</dt>
<dd><dl>
<dt>2.1. <a href="#id2862465">Bootstrapping pkgsrc</a>
</dt>
<dt>2.2. <a href="#id2863843">Platform specific notes</a>
</dt>
</dl></dd>
<dt>3. <a href="#using">Using The NetBSD package system</a>
</dt>
<dd><dl>
<dt>3.1. <a href="#getting%20started">Working with binary packages</a>
</dt>
<dt>3.2. <a href="#id2937398">Building packages from source</a>
</dt>
</dl></dd>
<dt>4. <a href="#binary">Creating binary packages</a>
</dt>
<dd><dl>
<dt>4.1. <a href="#id2936710">Building a single binary package</a>
</dt>
<dt>4.2. <a href="#id2939394">Settings for creation of binary packages</a>
</dt>
<dt>4.3. <a href="#id2939411">Doing a bulk build of all packages</a>
</dt>
<dt>4.4. <a href="#id2940945">Creating a multiple CD-ROM packages collection</a>
</dt>
</dl></dd>
</dl></dd>
<dt>II. <a href="#developers-guide">pkgsrc developer's guide</a>
</dt>
<dd><dl>
<dt>5. <a href="#components">Package components - files, directories and contents</a>
</dt>
<dd><dl>
<dt>5.1. <a href="#components.Makefile">Makefile</a>
</dt>
<dt>5.2. <a href="#components.distinfo">distinfo</a>
</dt>
<dt>5.3. <a href="#components.patches">patches/*</a>
</dt>
<dt>5.4. <a href="#id2943680">Other mandatory files</a>
</dt>
<dt>5.5. <a href="#id2943718">Optional files</a>
</dt>
<dt>5.6. <a href="#id2943959">work*</a>
</dt>
<dt>5.7. <a href="#id2943990">files/*</a>
</dt>
<dt>5.8. <a href="#id2944093">Portability of packages</a>
</dt>
</dl></dd>
<dt>6. <a href="#plist">PLIST issues</a>
</dt>
<dd><dl>
<dt>6.1. <a href="#plist.misc">Miscellaneous</a>
</dt>
<dt>6.2. <a href="#id2945543">PLIST_SRC</a>
</dt>
<dt>6.3. <a href="#id2945566">PLIST_SUBST</a>
</dt>
<dt>6.4. <a href="#id2945697">Perl5 modules</a>
</dt>
<dt>6.5. <a href="#id2945836">User Interaction</a>
</dt>
</dl></dd>
<dt>7. <a href="#fixes">Notes on fixes for packages</a>
</dt>
<dd><dl>
<dt>7.1. <a href="#id2944290">CPP defines</a>
</dt>
<dt>7.2. <a href="#fixes.libtool">Shared libraries - libtool</a>
</dt>
<dt>7.3. <a href="#id2947315">Using libtool on GNU packages that already support libtool</a>
</dt>
<dt>7.4. <a href="#id2947414">GNU Autoconf/Automake</a>
</dt>
<dt>7.5. <a href="#id2947454">Package configuration files</a>
</dt>
<dt>7.6. <a href="#id2947668">Feedback to the author</a>
</dt>
</dl></dd>
<dt>8. <a href="#build">The build process</a>
</dt>
<dd><dl>
<dt>8.1. <a href="#build.prefix">Program location</a>
</dt>
<dt>8.2. <a href="#id2949108">Main targets</a>
</dt>
<dt>8.3. <a href="#build.helpful-targets">Other helpful targets</a>
</dt>
</dl></dd>
<dt>9. <a href="#buildlink2">buildlink2 methodology</a>
</dt>
<dd><dl>
<dt>9.1. <a href="#id2953172">Converting packages to use buildlink2</a>
</dt>
<dt>9.2. <a href="#id2953308">Writing buildlink2.mk files</a>
</dt>
</dl></dd>
<dt>10. <a href="#debug">Debugging</a>
</dt>
<dt>11. <a href="#features">FAQs &amp; features of the package system</a>
</dt>
<dd><dl>
<dt>11.1. <a href="#id2952494">Packages using GNU autoconf</a>
</dt>
<dt>11.2. <a href="#id2954262">Other distrib methods than .tar.gz</a>
</dt>
<dt>11.3. <a href="#id2954307">Packages not creating their own subdirectory</a>
</dt>
<dt>11.4. <a href="#id2955763">Custom configuration process</a>
</dt>
<dt>11.5. <a href="#id2955785">Packages not building in their DISTNAME directory</a>
</dt>
<dt>11.6. <a href="#id2955896">How to fetch all distfiles at once</a>
</dt>
<dt>11.7. <a href="#id2956076">How to fetch files from behind a firewall</a>
</dt>
<dt>11.8. <a href="#id2956098">If your patch contains an RCS ID</a>
</dt>
<dt>11.9. <a href="#id2956116">How to pull in variables from /etc/mk.conf</a>
</dt>
<dt>11.10. <a href="#id2956180">Is there a mailing list for pkg-related discussion?</a>
</dt>
<dt>11.11. <a href="#id2956204">How do I tell make fetch to do passive FTP?</a>
</dt>
<dt>11.12. <a href="#id2956350">Dependencies on other packages</a>
</dt>
<dt>11.13. <a href="#id2956571">Conflicts with other packages</a>
</dt>
<dt>11.14. <a href="#id2956642">Software which has a WWW Home Page</a>
</dt>
<dt>11.15. <a href="#id2956667">How to handle modified distfiles with the 'old' name</a>
</dt>
<dt>11.16. <a href="#id2956764">What does &quot;Don't know how to make /usr/share/tmac/tmac.andoc&quot; mean?</a>
</dt>
<dt>11.17. <a href="#id2956809">How to handle incrementing versions when fixing an existing
package</a>
</dt>
<dt>11.18. <a href="#id2956956">Could not find bsd.own.mk - what's wrong?</a>
</dt>
<dt>11.19. <a href="#id2957027">Restricted packages</a>
</dt>
<dt>11.20. <a href="#id2957213">Packages using (n)curses</a>
</dt>
<dt>11.21. <a href="#id2957255">Automated security check</a>
</dt>
<dt>11.22. <a href="#id2957425">What's the proper way to create an account from a package?</a>
</dt>
<dt>11.23. <a href="#id2957593">How to handle compiler bugs</a>
</dt>
<dt>11.24. <a href="#features.info-files">Packages providing info files</a>
</dt>
<dt>11.25. <a href="#id2957793">Packages whose distfiles aren't available for plain downloading</a>
</dt>
<dt>11.26. <a href="#id2957953">Configuration files handling and placement</a>
</dt>
<dt>11.27. <a href="#id2958470">Packages providing login shells</a>
</dt>
<dt>11.28. <a href="#id2958558">Packages providing locale catalogues</a>
</dt>
<dt>11.29. <a href="#id2958592">Using 'sudo' with pkgsrc</a>
</dt>
<dt>11.30. <a href="#id2958621">Packages containing perl scripts</a>
</dt>
<dt>11.31. <a href="#id2958648">Packages that cannot or should not be built</a>
</dt>
</dl></dd>
<dt>12. <a href="#submit">Submitting and Committing</a>
</dt>
<dd><dl>
<dt>12.1. <a href="#id2960258">Submitting your packages</a>
</dt>
<dt>12.2. <a href="#id2961824">Committing: Importing a package into CVS</a>
</dt>
<dt>12.3. <a href="#id2962087">Updating a Package to a Newer Version</a>
</dt>
<dt>12.4. <a href="#id2962208">Moving a Package in pkgsrc</a>
</dt>
</dl></dd>
<dt>13. <a href="#examples">A simple example of a package: bison</a>
</dt>
<dd><dl>
<dt>13.1. <a href="#id2961656">files</a>
</dt>
<dt>13.2. <a href="#id2963176">Steps for building, installing, packaging</a>
</dt>
</dl></dd>
</dl></dd>
<dt>A. <a href="#logs">Build logs</a>
</dt>
<dd><dl>
<dt>A.1. <a href="#logs.building">Building top</a>
</dt>
<dt>A.2. <a href="#logs.package">Packaging top</a>
</dt>
</dl></dd>
<dt>B. <a href="#ftp-layout">Layout of the FTP server's package archive</a>
</dt>
</dl>
</div>
<div class="chapter" lang="en">
<div class="titlepage">
<div><div><h2 class="title">
<a name="introduction"></a>Chapter 1. Introduction</h2></div></div>
<div></div>
</div>
<div class="toc">
<p><b>Table of Contents</b></p>
<dl>
<dt>1.1. <a href="#id2862064">Introduction</a>
</dt>
<dt>1.2. <a href="#overview">Overview</a>
</dt>
<dt>1.3. <a href="#terminology">Terminology</a>
</dt>
<dt>1.4. <a href="#typography">Typography</a>
</dt>
</dl>
</div>
<div class="sect1" lang="en">
<div class="titlepage">
<div><div><h2 class="title" style="clear: both">
<a name="id2862064"></a>1.1. Introduction</h2></div></div>
<div></div>
</div>
<p>The NetBSD package system, <span class="emphasis"><em>pkgsrc</em></span>,
is a framework for building third-party software on NetBSD and other
UNIX-like systems. It is used to enable such freely available
software to be configured and built easily on supported platforms.</p>
<p>Once the software
has been built, it is manipulated with the pkg_* 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 over 3500 packages, including:</p>
<div class="itemizedlist"><ul type="disc">
<li>
<a xmlns:html="http://www.w3.org/1999/xhtml" href="ftp://ftp.netbsd.org/pub/NetBSD/packages/pkgsrc/www/apache/README.html" class="pkgname">www/apache</a> - The Apache web server</li>
<li>
<a xmlns:html="http://www.w3.org/1999/xhtml" href="ftp://ftp.netbsd.org/pub/NetBSD/packages/pkgsrc/www/mozilla/README.html" class="pkgname">www/mozilla</a> - The Mozilla web browser</li>
<li>
<a xmlns:html="http://www.w3.org/1999/xhtml" href="ftp://ftp.netbsd.org/pub/NetBSD/packages/pkgsrc/x11/gnome/README.html" class="pkgname">x11/gnome</a> - The GNOME Desktop Environment</li>
<li>
<a xmlns:html="http://www.w3.org/1999/xhtml" href="ftp://ftp.netbsd.org/pub/NetBSD/packages/pkgsrc/x11/kde3/README.html" class="pkgname">x11/kde3</a> - The K Desktop Environment</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 originally developed on NetBSD, and now supports the
following platforms:</p>
<div class="itemizedlist"><ul type="disc">
<li>
<a href="http://developer.apple.com/darwin/" target="_top">Darwin</a>
(<a href="http://www.apple.com/macosx/" target="_top">MacOS X</a>)</li>
<li><a href="http://www.FreeBSD.org/" target="_top">FreeBSD</a></li>
<li><a href="http://www.sgi.com/software/irix6.5/" target="_top">IRIX</a></li>
<li><a href="http://www.linux.org/" target="_top">Linux</a></li>
<li>
<a href="http://www.NetBSD.org/" target="_top">NetBSD</a> (of
course)</li>
<li><a href="http://www.openbsd.org/" target="_top">OpenBSD</a></li>
<li><a href="http://www.sun.com/solaris/" target="_top">Solaris</a></li>
</ul></div>
</div>
<div class="sect1" lang="en">
<div class="titlepage">
<div><div><h2 class="title" style="clear: both">
<a name="overview"></a>1.2. Overview</h2></div></div>
<div></div>
</div>
<p>
This document is divided into two parts. The first, <a href="#users-guide" title="Part I. pkgsrc user's guide">pkgsrc user's guide</a>,
describes how one can use one of the packages in the Package
Collection, either by installing a precompiled binary package, or
by building one's own copy using the NetBSD package system. The
second part, <a href="#developers-guide" title="Part II. pkgsrc developer's guide">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>
</div>
<div class="sect1" lang="en">
<div class="titlepage">
<div><div><h2 class="title" style="clear: both">
<a name="terminology"></a>1.3. Terminology</h2></div></div>
<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="itemizedlist"><ul type="disc">
<li>
<p><span class="emphasis"><em>Package</em></span></p>
<p>
A set of files and building instructions that describe what's necessary
to build a certain piece of software using the NetBSD package
system. Packages are traditionally stored under
<tt class="filename">/usr/pkgsrc</tt>.
</p>
</li>
<li>
<p><span class="emphasis"><em>The NetBSD package system</em></span></p>
<p>
This is the part of the NetBSD operating system handling building
(compiling), installing, and removing of packages.
</p>
</li>
<li>
<p><span class="emphasis"><em>Distfile</em></span></p>
<p>
This term describes the file or files that are provided by the author
of the piece of freely available 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 stored below <tt class="filename">/usr/pkgsrc/distfiles</tt>.
</p>
</li>
<li>
<p><span class="emphasis"><em>Port</em></span></p>
<p>
This is the term used by FreeBSD people for what we call a package.
In NetBSD terminology, &#8220;<span class="quote">port</span>&#8221; refers to a different
architecture.
</p>
</li>
<li>
<p><span class="emphasis"><em>Precompiled (binary) package</em></span></p>
<p>
A set of binaries built by the NetBSD package system from a distfile
using the NetBSD package system 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
generated in <tt class="filename">/usr/pkgsrc/packages</tt> by the NetBSD
package system; 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>
</li>
<li>
<p><span class="emphasis"><em>Program</em></span></p>
<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>
</li>
</ul></div>
</div>
<div class="sect1" lang="en">
<div class="titlepage">
<div><div><h2 class="title" style="clear: both">
<a name="typography"></a>1.4. Typography</h2></div></div>
<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 &#8220;<span class="quote">#</span>&#8221; for root's shell
prompt, and a &#8220;<span class="quote">%</span>&#8221; for users' shell prompt, assuming they use
the C-shell or tcsh.
</p>
</div>
</div>
<div class="part" lang="en">
<div class="titlepage">
<div><div><h1 class="title">
<a name="users-guide"></a>pkgsrc user's guide</h1></div></div>
<div></div>
</div>
<div class="toc">
<p><b>Table of Contents</b></p>
<dl>
<dt>2. <a href="#platforms">Using pkgsrc on systems other than NetBSD</a>
</dt>
<dd><dl>
<dt>2.1. <a href="#id2862465">Bootstrapping pkgsrc</a>
</dt>
<dt>2.2. <a href="#id2863843">Platform specific notes</a>
</dt>
</dl></dd>
<dt>3. <a href="#using">Using The NetBSD package system</a>
</dt>
<dd><dl>
<dt>3.1. <a href="#getting%20started">Working with binary packages</a>
</dt>
<dt>3.2. <a href="#id2937398">Building packages from source</a>
</dt>
</dl></dd>
<dt>4. <a href="#binary">Creating binary packages</a>
</dt>
<dd><dl>
<dt>4.1. <a href="#id2936710">Building a single binary package</a>
</dt>
<dt>4.2. <a href="#id2939394">Settings for creation of binary packages</a>
</dt>
<dt>4.3. <a href="#id2939411">Doing a bulk build of all packages</a>
</dt>
<dt>4.4. <a href="#id2940945">Creating a multiple CD-ROM packages collection</a>
</dt>
</dl></dd>
</dl>
</div>
<div class="chapter" lang="en">
<div class="titlepage">
<div><div><h2 class="title">
<a name="platforms"></a>Chapter 2. Using pkgsrc on systems other than NetBSD</h2></div></div>
<div></div>
</div>
<div class="toc">
<p><b>Table of Contents</b></p>
<dl>
<dt>2.1. <a href="#id2862465">Bootstrapping pkgsrc</a>
</dt>
<dt>2.2. <a href="#id2863843">Platform specific notes</a>
</dt>
</dl>
</div>
<div class="sect1" lang="en">
<div class="titlepage">
<div><div><h2 class="title" style="clear: both">
<a name="id2862465"></a>2.1. Bootstrapping pkgsrc</h2></div></div>
<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. As well as
native NetBSD support, pkgsrc and the bootstrap kit have support for
the following operating systems:
</p>
<div class="itemizedlist"><ul type="disc">
<li>Darwin (MacOS X)</li>
<li>FreeBSD</li>
<li>IRIX</li>
<li>Linux</li>
<li>OpenBSD</li>
<li>Solaris</li>
</ul></div>
<p>
Support for other platforms is under development.
</p>
<p>
Installing the bootstrap kit should be as simple as:
</p>
<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre><tt class="prompt">#</tt> <b class="userinput"><tt>cvs checkout othersrc/bootstrap-pkgsrc</tt></b>
<tt class="prompt">#</tt> <b class="userinput"><tt>cd othersrc/bootstrap-pkgsrc</tt></b>
<tt class="prompt">#</tt> <b class="userinput"><tt>./bootstrap</tt></b></pre></td></tr></table>
<p>
This will use the defaults of <tt class="filename">/usr/pkg</tt> for the
<span class="emphasis"><em>prefix</em></span>
and <tt class="filename">/var/db/pkg</tt> for the package database directory.
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="../../software/packages.html" target="_top">www.pkgsrc.org</a>.
</p>
</div>
<div class="sect1" lang="en">
<div class="titlepage">
<div><div><h2 class="title" style="clear: both">
<a name="id2863843"></a>2.2. Platform specific notes</h2></div></div>
<div></div>
</div>
<p>
Here are some platform-specific notes you should be aware of.
</p>
<div class="sect2" lang="en">
<div class="titlepage">
<div><div><h3 class="title">
<a name="id2863854"></a>2.2.1. Darwin (Mac OS X)</h3></div></div>
<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="2.2.1.1. Using a disk image">disk
image</a>, or a <a href="#platform.osx-ufs" title="2.2.1.2. Using a UFS partition">UFS
partition</a>.
</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>
You cannot use a HFS+ file system for pkgsrc, because pkgsrc currently
requires the filesystem to be case-sensitive, and HFS+ is not.
</div>
<div class="sect3" lang="en">
<div class="titlepage">
<div><div><h4 class="title">
<a name="platform.osx-image"></a>2.2.1.1. Using a disk image</h4></div></div>
<div></div>
</div>
<p>
Create the disk image:
</p>
<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre><tt class="prompt">#</tt> <b class="userinput"><tt>cd bootstrap-pkgsrc</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></td></tr></table>
<p>
That's it!
</p>
</div>
<div class="sect3" lang="en">
<div class="titlepage">
<div><div><h4 class="title">
<a name="platform.osx-ufs"></a>2.2.1.2. Using a UFS partition</h4></div></div>
<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>
<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre><tt class="prompt">#</tt> <b class="userinput"><tt>./bootstrap --pkgdbdir=/usr/pkg/pkgdb --pkgsrc=/Volumes/ufs/pkgsrc</tt></b></pre></td></tr></table>
<p>
</p>
<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">
<div class="titlepage">
<div><div><h3 class="title">
<a name="id2865702"></a>2.2.2. FreeBSD</h3></div></div>
<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>
<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre><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></td></tr></table>
</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">
<div class="titlepage">
<div><div><h3 class="title">
<a name="id2935473"></a>2.2.3. IRIX</h3></div></div>
<div></div>
</div>
<p>
IRIX 6.5 is tested and supported, other versions may work.
</p>
<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.
</p>
<p>
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>
</div>
<div class="sect2" lang="en">
<div class="titlepage">
<div><div><h3 class="title">
<a name="id2935518"></a>2.2.4. OpenBSD</h3></div></div>
<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>
<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre><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></td></tr></table>
</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>
<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre>.ifdef BSD_PKG_MK
# pkgsrc stuff, e.g. insert bsd.pkg.defaults.mk or similar here
.else
# OpenBSD stuff
.endif</pre></td></tr></table>
</li>
</ol></div>
</div>
<div class="sect2" lang="en">
<div class="titlepage">
<div><div><h3 class="title">
<a name="id2935748"></a>2.2.5. Solaris</h3></div></div>
<div></div>
</div>
<p>
Solaris 2.6 through 9 are supported. 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>SUNWsprot</li>
<li>SUNWarc</li>
<li>SUNWbtool</li>
<li>SUNWtoo</li>
<li>SUNWlibm</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">
<div class="titlepage">
<div><div><h4 class="title">
<a name="id2935793"></a>2.2.5.1. If you are using gcc</h4></div></div>
<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:html="http://www.w3.org/1999/xhtml" href="ftp://ftp.netbsd.org/pub/NetBSD/packages/pkgsrc/lang/gcc/README.html" class="pkgname">lang/gcc</a> or install a binary gcc
package, then remove gcc used during bootstrapping.
</p>
</div>
<div class="sect3" lang="en">
<div class="titlepage">
<div><div><h4 class="title">
<a name="id2935811"></a>2.2.5.2. If you are using Sun WorkShop</h4></div></div>
<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>SPROcc - Sun WorkShop Compiler C 5.0</li>
<li>SPROcpl - Sun WorkShop Compiler C++ 5.0</li>
<li>SPROild - Sun WorkShop Incremental Linker</li>
<li>SPROlang - Sun WorkShop Compilers common components</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>
<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre>CC= cc
CXX= CC
CPP= /usr/ccs/lib/cpp</pre></td></tr></table>
<p>
You may also want to build 64-bit binaries, eg.
</p>
<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre>CFLAGS= -xtarget=ultra -xarch=v9</pre></td></tr></table>
</div>
<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 class="chapter" lang="en">
<div class="titlepage">
<div><div><h2 class="title">
<a name="using"></a>Chapter 3. Using The NetBSD package system</h2></div></div>
<div></div>
</div>
<div class="toc">
<p><b>Table of Contents</b></p>
<dl>
<dt>3.1. <a href="#getting%20started">Working with binary packages</a>
</dt>
<dt>3.2. <a href="#id2937398">Building packages from source</a>
</dt>
</dl>
</div>
<div class="sect1" lang="en">
<div class="titlepage">
<div><div><h2 class="title" style="clear: both">
<a name="getting started"></a>3.1. Working with binary packages</h2></div></div>
<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">
<div class="titlepage">
<div><div><h3 class="title">
<a name="id2935275"></a>3.1.1. How to get binary packages</h3></div></div>
<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 <b class="command">uname -p</b>. 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">
<div class="titlepage">
<div><div><h3 class="title">
<a name="id2935328"></a>3.1.2. Installing binary packages</h3></div></div>
<div></div>
</div>
<p>
If you have the files on a CDROM or downloaded them to your hard disk, you
can install them with the following command (be sure to
<b class="command">su</b> to root first):
</p>
<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre><tt class="prompt">#</tt> <b class="userinput"><tt>pkg_add /path/to/package.tgz</tt></b></pre></td></tr></table>
<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
<b class="command">pkg_add</b> an FTP URL:
</p>
<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre><tt class="prompt">#</tt> <b class="userinput"><tt>pkg_add ftp://ftp.NetBSD.org/pub/NetBSD/packages/&lt;OS Ver&gt;/&lt;arch&gt;/All/package.tgz</tt></b></pre></td></tr></table>
<p>
If there is any doubt, the uname utility can be used to determine the
&lt;OS Ver&gt;, and &lt;arch&gt; by running <b class="command">uname -rp</b>.
</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">
<div class="titlepage">
<div><div><h3 class="title">
<a name="id2937385"></a>3.1.3. A word of warning</h3></div></div>
<div></div>
</div>
<p>
Please pay very careful attention to the warnings expressed in that 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">
<div class="titlepage">
<div><div><h2 class="title" style="clear: both">
<a name="id2937398"></a>3.2. Building packages from source</h2></div></div>
<div></div>
</div>
<p>
This assumes that the package is already part of the NetBSD package system.
If it is not, see <a href="#developers-guide" title="Part II. pkgsrc developer's guide">Part II</a>.
</p>
<div class="sect2" lang="en">
<div class="titlepage">
<div><div><h3 class="title">
<a name="id2937412"></a>3.2.1. Requirements</h3></div></div>
<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 class="sect3" lang="en">
<div class="titlepage">
<div><div><h4 class="title">
<a name="id2937440"></a>3.2.1.1. Where to get pkgsrc</h4></div></div>
<div></div>
</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>
<p>
To get the package source 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" target="_top">ftp.NetBSD.org</a> and unpack it into <tt class="filename">/usr/pkgsrc</tt>.
</p>
<p>
As an alternative, you can get pkgsrc via the Software Update Protocol,
SUP. To do so, make sure your supfile has a line
</p>
<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre>release=pkgsrc</pre></td></tr></table>
<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
<b class="command">sup -v /path/to/your/supfile</b>.
</p>
<p>
To get pkgsrc via CVS, make sure you have cvs 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>
<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre><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></td></tr></table>
<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>
<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre><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></td></tr></table>
<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 class="sect3" lang="en">
<div class="titlepage">
<div><div><h4 class="title">
<a name="id2937693"></a>3.2.1.2. Fetching distfiles</h4></div></div>
<div></div>
</div>
<p>
There is one gotcha: The distribution file (i.e. the unmodified source)
must exist on your system for the packages system to be able to build it.
If it does not, then <b class="command">ftp</b> is used to fetch the
distribution files 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, <b class="command">make fetch-list</b> will tell you
what you'll need. Put these distfiles into
<tt class="filename">/usr/pkgsrc/distfiles</tt>.
</p>
</div>
<div class="sect3" lang="en">
<div class="titlepage">
<div><div><h4 class="title">
<a name="id2937763"></a>3.2.1.3. How to build and install</h4></div></div>
<div></div>
</div>
<p>
Once the distfile(s) have been fetched, building a package is as
simple as changing into the package directory and running make:
</p>
<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre><tt class="prompt">%</tt> <b class="userinput"><tt>cd editors/vim</tt></b>
<tt class="prompt">%</tt> <b class="userinput"><tt>make</tt></b></pre></td></tr></table>
<p>
</p>
<p>
Installing the package on your system requires you to be root.
However, pkgsrc has a <span class="emphasis"><em>just-in-time</em></span> su feature,
which allows you to only become root for the actual installation step.
e.g.
</p>
<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre><tt class="prompt">%</tt> <b class="userinput"><tt>make install</tt></b>
===&gt; Installing for top-3.5beta5
===&gt; Becoming root@mofo to install top-3.5beta5.
/usr/bin/su Password: <b class="userinput"><tt>&lt;password&gt;</tt></b>
[...installation continues...]</pre></td></tr></table>
<p>
</p>
<p>
Taking the top system utility as an example, we can install it on our
system by building as shown in <a href="#logs" title="Appendix A. Build logs">Appendix A, <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,
simply 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 root 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>
There is, of course, one exception to this - X11 packages are traditionally
installed in the X11 tree. The definition used to identify the root of the
X11 tree is the <tt class="varname">X11BASE</tt> definition.
</p>
<p>
It is possible to install X11 packages in the
<tt class="varname">LOCALBASE</tt> tree, for which you must install the
<a xmlns:html="http://www.w3.org/1999/xhtml" href="ftp://ftp.netbsd.org/pub/NetBSD/packages/pkgsrc/pkgtools/xpkgwedge/README.html" class="pkgname">pkgtools/xpkgwedge</a> package - see <a href="#build.prefix" title="8.1. Program location">Section 8.1, &#8220;Program location&#8221;</a> for further details.
</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>, and
<tt class="varname">X11BASE</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 make(1) command with <tt class="varname">PKG_DEBUG_LEVEL=2</tt>,
then a huge amount of information will be displayed. For example,
</p>
<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre><tt class="prompt">%</tt> <b class="userinput"><tt>make patch PKG_DEBUG_LEVEL=2</tt></b></pre></td></tr></table>
<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.
</p>
<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre><tt class="prompt">%</tt> <b class="userinput"><tt>make show-var VARNAME=DISTFILES</tt></b></pre></td></tr></table>
<p>
will show the expansion of the make(1) variable
<tt class="varname">DISTFILES</tt>.
</p>
</li>
</ol></div>
<p>
If you want to de-install and re-install a binary package that you've
created (see next section), that you put into pkgsrc/packages manually or
that's located on a remote FTP server, you can use the the &quot;bin-install&quot;
target. This target will install a binary package - if available - via
<b class="command">pkg_add</b>, else do a <b class="command">make package</b>.
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 pkg_add(8) 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> (or
<tt class="varname">X11BASE</tt>, for that matter), 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>
</div>
</div>
<div class="chapter" lang="en">
<div class="titlepage">
<div><div><h2 class="title">
<a name="binary"></a>Chapter 4. Creating binary packages</h2></div></div>
<div></div>
</div>
<div class="toc">
<p><b>Table of Contents</b></p>
<dl>
<dt>4.1. <a href="#id2936710">Building a single binary package</a>
</dt>
<dt>4.2. <a href="#id2939394">Settings for creation of binary packages</a>
</dt>
<dt>4.3. <a href="#id2939411">Doing a bulk build of all packages</a>
</dt>
<dt>4.4. <a href="#id2940945">Creating a multiple CD-ROM packages collection</a>
</dt>
</dl>
</div>
<div class="sect1" lang="en">
<div class="titlepage">
<div><div><h2 class="title" style="clear: both">
<a name="id2936710"></a>4.1. Building a single binary package</h2></div></div>
<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 pkg_add(1). This saves having to build the same package on
a group of hosts and wasting CPU time. It also provides a simple means
for others to install your package, should you distribute it.
</p>
<p>
Create a binary package:
</p>
<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre><tt class="prompt">#</tt> <b class="userinput"><tt>cd sysutils/top</tt></b>
<tt class="prompt">#</tt> <b class="userinput"><tt>make package</tt></b></pre></td></tr></table>
<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
<b class="command">pkg_*</b> tools to manipulate it. Binary packages are
created by default in <tt class="filename">/usr/pkgsrc/packages</tt>, in the
form of a gzip or bzip2 tar file. See <a href="#logs.package" title="A.2. Packaging top">Section A.2, &#8220;Packaging top&#8221;</a> for
a continuation of the above <a xmlns:html="http://www.w3.org/1999/xhtml" href="ftp://ftp.netbsd.org/pub/NetBSD/packages/pkgsrc/sysutils/top/README.html" class="pkgname">sysutils/top</a> example.
</p>
<p>
See <a href="#submit" title="Chapter 12. Submitting and Committing">Chapter 12, <i>Submitting and Committing</i></a> for information on how to submit such a
binary package.
</p>
</div>
<div class="sect1" lang="en">
<div class="titlepage">
<div><div><h2 class="title" style="clear: both">
<a name="id2939394"></a>4.2. Settings for creation of binary packages</h2></div></div>
<div></div>
</div>
<p>
See <a href="#build.helpful-targets" title="8.3. Other helpful targets">Section 8.3, &#8220;Other helpful targets&#8221;</a>.
</p>
</div>
<div class="sect1" lang="en">
<div class="titlepage">
<div><div><h2 class="title" style="clear: both">
<a name="id2939411"></a>4.3. Doing a bulk build of all packages</h2></div></div>
<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 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 ftpd(8) 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">
<div class="titlepage">
<div><div><h3 class="title">
<a name="id2939422"></a>4.3.1. Configuration</h3></div></div>
<div></div>
</div>
<div class="sect3" lang="en">
<div class="titlepage">
<div><div><h4 class="title">
<a name="binary.mk.conf"></a>4.3.1.1. /etc/mk.conf</h4></div></div>
<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>
<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre>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></td></tr></table>
<p>
If you wish to use xpkgwedge for the entire build, then add:
</p>
<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre>BULK_PREREQ+= pkgtools/xpkgwedge</pre></td></tr></table>
<p>
Other packages which must be installed during the bulk build to modify the
build behaviour may be added to the <tt class="varname">BULK_PREREQ</tt> variable.
Note that currently the only package for which
<tt class="varname">BULK_PREREQ</tt> makes sense is xpkgwedge.
</p>
</div>
<div class="sect3" lang="en">
<div class="titlepage">
<div><div><h4 class="title">
<a name="id2939736"></a>4.3.1.2. build.conf</h4></div></div>
<div></div>
</div>
<p>
In <tt class="filename">pkgsrc/mk/bulk</tt>, copy
&#8220;<span class="quote">build.conf-example</span>&#8221; to &#8220;<span class="quote">build.conf</span>&#8221; 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, where your pkgsrc is located and
which user to su(8) to do a <b class="command">cvs update</b>.
</p>
</div>
<div class="sect3" lang="en">
<div class="titlepage">
<div><div><h4 class="title">
<a name="id2939767"></a>4.3.1.3. pre-build.local</h4></div></div>
<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>
<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre><tt class="prompt">#</tt> <b class="userinput"><tt>echo &quot;I do not have enough disk space to build this pig.&quot; \
&gt; pkgsrc/games/crafty-book-enormous/$BROKENF</tt></b></pre></td></tr></table>
<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">
<div class="titlepage">
<div><div><h3 class="title">
<a name="id2939817"></a>4.3.2. Other environmental considerations</h3></div></div>
<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 password file), or (re-)install
it via <b class="command">pkg_add</b> 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 rc.local:
</p>
<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre>( 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></td></tr></table>
<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">
<div class="titlepage">
<div><div><h3 class="title">
<a name="id2939943"></a>4.3.3. Operation</h3></div></div>
<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>
During the bulk build, <span class="emphasis"><em>all packages will be
removed!</em></span>
</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>
<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre><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></td></tr></table>
<p>
If for some reason your last build didn't complete (power failure,
system panic, ...), you can continue it by running:
</p>
<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre><tt class="prompt">#</tt> <b class="userinput"><tt>sh mk/bulk/build restart</tt></b></pre></td></tr></table>
<p>
At the end of the bulk run, 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">
<div class="titlepage">
<div><div><h3 class="title">
<a name="id2940032"></a>4.3.4. What it does</h3></div></div>
<div></div>
</div>
<p>
The bulk builds consist of three steps:
</p>
<div class="orderedlist"><ol type="1">
<li>pre-build
<p>
The script updates your pkgsrc via (anon)cvs, then cleans
out any broken distfiles, and removes all packages installed.
</p>
</li>
<li>the bulk build
<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 depends
will be built later.
</p>
</li>
<li>post-build
<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>
</li>
</ol></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">
<div class="titlepage">
<div><div><h3 class="title">
<a name="id2940189"></a>4.3.5. Disk space requirements</h3></div></div>
<div></div>
</div>
<p>
Currently, roughly the following requirements are valid for
1.5/i386:
</p>
<div class="itemizedlist"><ul type="disc">
<li>1500MB - distfiles (NFS ok)</li>
<li>1000MB - full set of all binaries (NFS ok)</li>
<li>1500MB - temp space for compiling (local disk recommended)</li>
</ul></div>
<p>
For 1.5/alpha:
</p>
<div class="itemizedlist"><ul type="disc"><li>1300MB - full set of all binaries (NFS ok)</li></ul></div>
<p>
Note that all pkgs will be de-installed as soon as they are turned into a
binary package, and that work-sources are removed, so there is no huge
demand to disk space. Afterwards, if the package is needed again, it will
be installed via &#8220;<span class="quote">pkg_add</span>&#8221; instead of building again, so
there are no cycles wasted by recompiling.
</p>
</div>
<div class="sect2" lang="en">
<div class="titlepage">
<div><div><h3 class="title">
<a name="id2940316"></a>4.3.6. Setting up a sandbox for chroot'ed builds</h3></div></div>
<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
<b class="command">make distribution DESTDIR=/usr/sandbox</b> in
<tt class="filename">/usr/src/etc</tt>, be sure the following
items are present and properly configured:
</p>
<div class="itemizedlist"><ul type="disc">
<li>
kernel
<p>
</p>
<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre><tt class="prompt">#</tt> <b class="userinput"><tt>cp /netbsd /usr/sandbox</tt></b></pre></td></tr></table>
<p>
</p>
</li>
<li>
<tt class="filename">/dev/*</tt><p>
</p>
<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre><tt class="prompt">#</tt> <b class="userinput"><tt>cd /usr/sandbox/dev ; sh MAKEDEV all</tt></b></pre></td></tr></table>
<p>
</p>
</li>
<li>
<tt class="filename">/etc/resolv.conf</tt> (for <a xmlns:html="http://www.w3.org/1999/xhtml" href="ftp://ftp.netbsd.org/pub/NetBSD/packages/pkgsrc/security/smtpd/README.html" class="pkgname">security/smtpd</a> and mail):
<p>
</p>
<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre><tt class="prompt">#</tt> <b class="userinput"><tt>cp /etc/resolv.conf /usr/sandbox/etc</tt></b></pre></td></tr></table>
<p>
</p>
</li>
<li>
working(!) mail config (hostname, sendmail.cf):
<p>
</p>
<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre><tt class="prompt">#</tt> <b class="userinput"><tt>cp /etc/mail/sendmail.cf /usr/sandbox/etc/mail</tt></b></pre></td></tr></table>
<p>
</p>
</li>
<li>
<tt class="filename">/etc/localtime</tt> (for <a xmlns:html="http://www.w3.org/1999/xhtml" href="ftp://ftp.netbsd.org/pub/NetBSD/packages/pkgsrc/security/smtpd/README.html" class="pkgname">security/smtpd</a>):
<p>
</p>
<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre><tt class="prompt">#</tt> <b class="userinput"><tt>ln -sf /usr/share/zoneinfo/GMT /usr/sandbox/etc/localtime</tt></b></pre></td></tr></table>
<p>
</p>
</li>
<li>
<tt class="filename">/usr/src</tt> (system sources, for <a xmlns:html="http://www.w3.org/1999/xhtml" href="ftp://ftp.netbsd.org/pub/NetBSD/packages/pkgsrc/sysutils/aperture/README.html" class="pkgname">sysutils/aperture</a>,
<a xmlns:html="http://www.w3.org/1999/xhtml" href="ftp://ftp.netbsd.org/pub/NetBSD/packages/pkgsrc/net/ppp-mppe/README.html" class="pkgname">net/ppp-mppe</a>):
<p>
</p>
<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre><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>
<tt class="prompt">#</tt> <b class="userinput"><tt>ln -s cvs/pkgsrc .</tt></b></pre></td></tr></table>
<p>
</p>
</li>
<li>
create <tt class="filename">/var/db/pkg</tt> (not part of default install):
<p>
</p>
<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre><tt class="prompt">#</tt> <b class="userinput"><tt>mkdir /usr/sandbox/var/db/pkg</tt></b></pre></td></tr></table>
<p>
</p>
</li>
<li>
create <tt class="filename">/usr/pkg</tt> (not part of default install):
<p>
</p>
<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre><tt class="prompt">#</tt> <b class="userinput"><tt>mkdir /usr/sandbox/usr/pkg</tt></b></pre></td></tr></table>
<p>
</p>
</li>
<li>
checkout pkgsrc into
<tt class="filename">/usr/sandbox/usr/pkgsrc</tt>:
<p>
</p>
<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre><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></td></tr></table>
<p>
</p>
</li>
<li>
edit <tt class="filename">/etc/mk.conf</tt>, see <a href="#binary.mk.conf" title="4.3.1.1. /etc/mk.conf">Section 4.3.1.1, &#8220;/etc/mk.conf&#8221;</a>.
</li>
<li>
adjust <tt class="filename">mk/bulk/build.conf</tt> to suit your needs.
</li>
</ul></div>
<div class="note" style="margin-left: 0.5in; margin-right: 0.5in;">
<h3 class="title">Note</h3>
Don't forget to install X.
</div>
<p>
If you are a developer and want to upload the resulting binary packages
to ftp.NetBSD.org, be sure you are using the default X version for your
architecture and release (that is XFree86 3.3.6 for 1.5.x, and XFree86
4.2.1 for NetBSD 1.6.1 on <a href="../../Ports/cats/" target="_top">cats</a>,
<a href="../../Ports/i386/" target="_top">i386</a> and <a href="../../Ports/macppc/" target="_top">macppc</a> ports, 3.3.6 on all other
ports).
</p>
<p>
The next thing you need is a <span class="emphasis"><em>fresh checkout of pkgsrc</em></span>
(e.g. from anoncvs). Do not mount/link this to the copy of your pkgsrc tree
you do development in, as this will likely cause problems! Adjust
<tt class="filename">.../pkgsrc/packages</tt> and
<tt class="filename">.../pkgsrc/distfiles</tt> to point to some places
outside the sandbox if you want to make the files public.
</p>
<p>
When the chroot sandbox is setup, you can start the build with the following
steps:
</p>
<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre><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></td></tr></table>
<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>
<div class="sect1" lang="en">
<div class="titlepage">
<div><div><h2 class="title" style="clear: both">
<a name="id2940945"></a>4.4. Creating a multiple CD-ROM packages collection</h2></div></div>
<div></div>
</div>
<p>
After your bulk pkgsrc 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:html="http://www.w3.org/1999/xhtml" href="ftp://ftp.netbsd.org/pub/NetBSD/packages/pkgsrc/pkgtools/cdpack/README.html" class="pkgname">pkgtools/cdpack</a> package provides a simple
tool for creating the ISO 9660 images. <b class="command">cdpack</b> 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">
<div class="titlepage">
<div><div><h3 class="title">
<a name="id2940966"></a>4.4.1. Example of cdpack</h3></div></div>
<div></div>
</div>
<p>
Complete documentation for cdpack is found in cdpack(1). 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>
<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre><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></td></tr></table>
<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>
<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre><tt class="prompt">#</tt> <b class="userinput"><tt>mkdir /tmp/common</tt></b>
<tt class="prompt">#</tt> <b class="userinput"><tt>echo &quot;This is a README&quot; &gt; /tmp/common/README</tt></b>
<tt class="prompt">#</tt> <b class="userinput"><tt>echo &quot;Another file&quot; &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 &quot;#!/bin/sh&quot; &gt; /tmp/common/bin/myscript</tt></b>
<tt class="prompt">#</tt> <b class="userinput"><tt>echo &quot;echo Hello world&quot; &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></td></tr></table>
<p>
Now create the images:
</p>
<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre><tt class="prompt">#</tt> <b class="userinput"><tt>cdpack -x /tmp/common /usr/pkgsrc/packages/All /u2/images</tt></b></pre></td></tr></table>
<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>
<div class="part" lang="en">
<div class="titlepage">
<div><div><h1 class="title">
<a name="developers-guide"></a>pkgsrc developer's guide</h1></div></div>
<div></div>
</div>
<div class="toc">
<p><b>Table of Contents</b></p>
<dl>
<dt>5. <a href="#components">Package components - files, directories and contents</a>
</dt>
<dd><dl>
<dt>5.1. <a href="#components.Makefile">Makefile</a>
</dt>
<dt>5.2. <a href="#components.distinfo">distinfo</a>
</dt>
<dt>5.3. <a href="#components.patches">patches/*</a>
</dt>
<dt>5.4. <a href="#id2943680">Other mandatory files</a>
</dt>
<dt>5.5. <a href="#id2943718">Optional files</a>
</dt>
<dt>5.6. <a href="#id2943959">work*</a>
</dt>
<dt>5.7. <a href="#id2943990">files/*</a>
</dt>
<dt>5.8. <a href="#id2944093">Portability of packages</a>
</dt>
</dl></dd>
<dt>6. <a href="#plist">PLIST issues</a>
</dt>
<dd><dl>
<dt>6.1. <a href="#plist.misc">Miscellaneous</a>
</dt>
<dt>6.2. <a href="#id2945543">PLIST_SRC</a>
</dt>
<dt>6.3. <a href="#id2945566">PLIST_SUBST</a>
</dt>
<dt>6.4. <a href="#id2945697">Perl5 modules</a>
</dt>
<dt>6.5. <a href="#id2945836">User Interaction</a>
</dt>
</dl></dd>
<dt>7. <a href="#fixes">Notes on fixes for packages</a>
</dt>
<dd><dl>
<dt>7.1. <a href="#id2944290">CPP defines</a>
</dt>
<dt>7.2. <a href="#fixes.libtool">Shared libraries - libtool</a>
</dt>
<dt>7.3. <a href="#id2947315">Using libtool on GNU packages that already support libtool</a>
</dt>
<dt>7.4. <a href="#id2947414">GNU Autoconf/Automake</a>
</dt>
<dt>7.5. <a href="#id2947454">Package configuration files</a>
</dt>
<dt>7.6. <a href="#id2947668">Feedback to the author</a>
</dt>
</dl></dd>
<dt>8. <a href="#build">The build process</a>
</dt>
<dd><dl>
<dt>8.1. <a href="#build.prefix">Program location</a>
</dt>
<dt>8.2. <a href="#id2949108">Main targets</a>
</dt>
<dt>8.3. <a href="#build.helpful-targets">Other helpful targets</a>
</dt>
</dl></dd>
<dt>9. <a href="#buildlink2">buildlink2 methodology</a>
</dt>
<dd><dl>
<dt>9.1. <a href="#id2953172">Converting packages to use buildlink2</a>
</dt>
<dt>9.2. <a href="#id2953308">Writing buildlink2.mk files</a>
</dt>
</dl></dd>
<dt>10. <a href="#debug">Debugging</a>
</dt>
<dt>11. <a href="#features">FAQs &amp; features of the package system</a>
</dt>
<dd><dl>
<dt>11.1. <a href="#id2952494">Packages using GNU autoconf</a>
</dt>
<dt>11.2. <a href="#id2954262">Other distrib methods than .tar.gz</a>
</dt>
<dt>11.3. <a href="#id2954307">Packages not creating their own subdirectory</a>
</dt>
<dt>11.4. <a href="#id2955763">Custom configuration process</a>
</dt>
<dt>11.5. <a href="#id2955785">Packages not building in their DISTNAME directory</a>
</dt>
<dt>11.6. <a href="#id2955896">How to fetch all distfiles at once</a>
</dt>
<dt>11.7. <a href="#id2956076">How to fetch files from behind a firewall</a>
</dt>
<dt>11.8. <a href="#id2956098">If your patch contains an RCS ID</a>
</dt>
<dt>11.9. <a href="#id2956116">How to pull in variables from /etc/mk.conf</a>
</dt>
<dt>11.10. <a href="#id2956180">Is there a mailing list for pkg-related discussion?</a>
</dt>
<dt>11.11. <a href="#id2956204">How do I tell make fetch to do passive FTP?</a>
</dt>
<dt>11.12. <a href="#id2956350">Dependencies on other packages</a>
</dt>
<dt>11.13. <a href="#id2956571">Conflicts with other packages</a>
</dt>
<dt>11.14. <a href="#id2956642">Software which has a WWW Home Page</a>
</dt>
<dt>11.15. <a href="#id2956667">How to handle modified distfiles with the 'old' name</a>
</dt>
<dt>11.16. <a href="#id2956764">What does &quot;Don't know how to make /usr/share/tmac/tmac.andoc&quot; mean?</a>
</dt>
<dt>11.17. <a href="#id2956809">How to handle incrementing versions when fixing an existing
package</a>
</dt>
<dt>11.18. <a href="#id2956956">Could not find bsd.own.mk - what's wrong?</a>
</dt>
<dt>11.19. <a href="#id2957027">Restricted packages</a>
</dt>
<dt>11.20. <a href="#id2957213">Packages using (n)curses</a>
</dt>
<dt>11.21. <a href="#id2957255">Automated security check</a>
</dt>
<dt>11.22. <a href="#id2957425">What's the proper way to create an account from a package?</a>
</dt>
<dt>11.23. <a href="#id2957593">How to handle compiler bugs</a>
</dt>
<dt>11.24. <a href="#features.info-files">Packages providing info files</a>
</dt>
<dt>11.25. <a href="#id2957793">Packages whose distfiles aren't available for plain downloading</a>
</dt>
<dt>11.26. <a href="#id2957953">Configuration files handling and placement</a>
</dt>
<dt>11.27. <a href="#id2958470">Packages providing login shells</a>
</dt>
<dt>11.28. <a href="#id2958558">Packages providing locale catalogues</a>
</dt>
<dt>11.29. <a href="#id2958592">Using 'sudo' with pkgsrc</a>
</dt>
<dt>11.30. <a href="#id2958621">Packages containing perl scripts</a>
</dt>
<dt>11.31. <a href="#id2958648">Packages that cannot or should not be built</a>
</dt>
</dl></dd>
<dt>12. <a href="#submit">Submitting and Committing</a>
</dt>
<dd><dl>
<dt>12.1. <a href="#id2960258">Submitting your packages</a>
</dt>
<dt>12.2. <a href="#id2961824">Committing: Importing a package into CVS</a>
</dt>
<dt>12.3. <a href="#id2962087">Updating a Package to a Newer Version</a>
</dt>
<dt>12.4. <a href="#id2962208">Moving a Package in pkgsrc</a>
</dt>
</dl></dd>
<dt>13. <a href="#examples">A simple example of a package: bison</a>
</dt>
<dd><dl>
<dt>13.1. <a href="#id2961656">files</a>
</dt>
<dt>13.2. <a href="#id2963176">Steps for building, installing, packaging</a>
</dt>
</dl></dd>
</dl>
</div>
<div class="chapter" lang="en">
<div class="titlepage">
<div><div><h2 class="title">
<a name="components"></a>Chapter 5. Package components - files, directories and contents</h2></div></div>
<div></div>
</div>
<div class="toc">
<p><b>Table of Contents</b></p>
<dl>
<dt>5.1. <a href="#components.Makefile">Makefile</a>
</dt>
<dt>5.2. <a href="#components.distinfo">distinfo</a>
</dt>
<dt>5.3. <a href="#components.patches">patches/*</a>
</dt>
<dt>5.4. <a href="#id2943680">Other mandatory files</a>
</dt>
<dt>5.5. <a href="#id2943718">Optional files</a>
</dt>
<dt>5.6. <a href="#id2943959">work*</a>
</dt>
<dt>5.7. <a href="#id2943990">files/*</a>
</dt>
<dt>5.8. <a href="#id2944093">Portability of packages</a>
</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">
<div class="titlepage">
<div><div><h2 class="title" style="clear: both">
<a name="components.Makefile"></a>5.1. Makefile</h2></div></div>
<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 Makefile 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>
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
port can complain vigorously.
</p>
<p>
The <tt class="varname">MASTER_SITES</tt> may be set to one of the
predefined sites:
</p>
<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre>${MASTER_SITE_XCONTRIB}
${MASTER_SITE_GNU}
${MASTER_SITE_PERL_CPAN}
${MASTER_SITE_TEX_CTAN}
${MASTER_SITE_SUNSITE}
${MASTER_SITE_GNOME}
${MASTER_SITE_SOURCEFORGE}</pre></td></tr></table>
<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>
<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre>${MASTER_SITE_GNU:=subdirectory/name/}</pre></td></tr></table>
<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>
<tt class="varname">MASTER_SITE_SUBDIR</tt> has been deprecated and
<span class="emphasis"><em>should no longer be used</em></span>.
</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>
<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre>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></td></tr></table>
<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>
<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre>archivers audio benchmarks biology cad
chat comms converters cross databases
devel editors emulators finance fonts
games graphics ham japanese lang
mail math mbone misc net
news parallel print security shells
sysutils textproc time wm www
x11</pre></td></tr></table>
<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 bsd.pkg.mk.
</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="#features.info-files" title="11.24. Packages providing info files">Section 11.24, &#8220;Packages providing info files&#8221;</a>.
</p></li>
<li><p>
Adjust <tt class="varname">MAINTAINER</tt> to be either yourself, if you plan
to maintain the package for future updates, or set it to the default
maintainer <tt class="email">&lt;<a href="mailto:tech-pkg@NetBSD.org">tech-pkg@NetBSD.org</a>&gt;</tt>.
</p></li>
<li><p>
If there exists a home page for the software in question, please
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.
</p></li>
</ul></div>
</div>
<div class="sect1" lang="en">
<div class="titlepage">
<div><div><h2 class="title" style="clear: both">
<a name="components.distinfo"></a>5.2. distinfo</h2></div></div>
<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 best generated using the <b class="command">make makesum</b> 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:html="http://www.w3.org/1999/xhtml" href="ftp://ftp.netbsd.org/pub/NetBSD/packages/pkgsrc/pkgtools/digest/README.html" class="pkgname">pkgtools/digest</a> utility calculates all of the digests
in the distinfo file, and it provides various different algorithms.
At the current time, the algorithms provided are:
<span class="emphasis"><em>md5</em></span>, <span class="emphasis"><em>rmd160</em></span>,
<span class="emphasis"><em>sha1</em></span>, <span class="emphasis"><em>sha256</em></span>,
<span class="emphasis"><em>sha384</em></span> and <span class="emphasis"><em>sha512</em></span>.
</p>
<p>
Some packages have different sets of distfiles on a per architecture
basis (a good example is <a xmlns:html="http://www.w3.org/1999/xhtml" href="ftp://ftp.netbsd.org/pub/NetBSD/packages/pkgsrc/www/navigator/README.html" class="pkgname">www/navigator</a>). These are kept in the
same distinfo file and care should be taken when upgrading such a
package to ensure distfile information is not lost.
</p>
<p>
The message digest/checksum for all the official patches found in the
<tt class="filename">patches/</tt> directory (see <a href="#components.patches" title="5.3. patches/*">Section 5.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 <b class="command">make makepatchsum</b>.
</p>
</div>
<div class="sect1" lang="en">
<div class="titlepage">
<div><div><h2 class="title" style="clear: both">
<a name="components.patches"></a>5.3. patches/*</h2></div></div>
<div></div>
</div>
<p>
This directory contains files that are used by the patch(1) 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>
The <tt class="filename">patch-??</tt> files should be in
<b class="command">diff -bu</b> 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
<a xmlns:html="http://www.w3.org/1999/xhtml" href="ftp://ftp.netbsd.org/pub/NetBSD/packages/pkgsrc/pkgtools/pkgdiff/README.html" class="pkgname">pkgtools/pkgdiff</a> package to avoid these problems.
</p>
<p>
For even more automation, we recommend using mkpatches 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
<b class="command">cp -p filename filename.orig</b> or, easier, by using
<b class="command">pkgvi</b> 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 patchdiff.
</p>
<p>
When you have finished a package, remember to generate the checksums
for the patch files by using the <b class="command">make makepatchsum</b>
command, see <a href="#components.distinfo" title="5.2. distinfo">Section 5.2, &#8220;distinfo&#8221;</a>.
</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">
<div class="titlepage">
<div><div><h2 class="title" style="clear: both">
<a name="id2943680"></a>5.4. Other mandatory files</h2></div></div>
<div></div>
</div>
<div class="itemizedlist"><ul type="disc">
<li>
<tt class="filename">DESCR</tt><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>
</li>
<li>
<tt class="filename">PLIST</tt><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.
</p>
</li>
</ul></div>
</div>
<div class="sect1" lang="en">
<div class="titlepage">
<div><div><h2 class="title" style="clear: both">
<a name="id2943718"></a>5.5. Optional files</h2></div></div>
<div></div>
</div>
<div class="itemizedlist"><ul type="disc">
<li>
<tt class="filename">INSTALL</tt><p>
Shell script invoked twice during pkg_add. 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
pkg_add(1) and pkg_create(1) for more information.
</p>
</li>
<li>
<tt class="filename">DEINSTALL</tt><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 pkg_delete(1)
and pkg_create(1) for more information.
</p>
</li>
<li>
<tt class="filename">MESSAGE</tt><p>
Display this file after installation of the package.
Useful for things like legal notices on almost-free software, etc.
Please note that you can modify variables in it easily by using
<tt class="varname">MESSAGE_SUBST</tt> in the package's Makefile:
</p>
<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre>MESSAGE_SUBST+= SOMEVAR=&quot;somevalue&quot;</pre></td></tr></table>
<p>
replaces &quot;${SOMEVAR}&quot; with &#8220;<span class="quote">somevalue</span>&#8221; in
<tt class="filename">MESSAGE</tt>.
</p>
</li>
</ul></div>
</div>
<div class="sect1" lang="en">
<div class="titlepage">
<div><div><h2 class="title" style="clear: both">
<a name="id2943959"></a>5.6. <tt class="filename">work*</tt></h2></div></div>
<div></div>
</div>
<p>
When you type <b class="command">make</b> the distribution files are
unpacked into this directory. It can be removed by running
<b class="command">make clean</b>.
</p>
<p>
This directory is also used to keep various timestamp files.
</p>
</div>
<div class="sect1" lang="en">
<div class="titlepage">
<div><div><h2 class="title" style="clear: both">
<a name="id2943990"></a>5.7. <tt class="filename">files/*</tt></h2></div></div>
<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 pre-configure 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 class="sect1" lang="en">
<div class="titlepage">
<div><div><h2 class="title" style="clear: both">
<a name="id2944093"></a>5.8. Portability of packages</h2></div></div>
<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="sect2" lang="en">
<div class="titlepage">
<div><div><h3 class="title">
<a name="id2944103"></a>5.8.1. ${INSTALL}, ${INSTALL_DATA_DIR}, ...</h3></div></div>
<div></div>
</div>
<p>
The BSD-compatible <b class="command">install</b> 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>
<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre>${INSTALL_DATA_DIR} ${PREFIX}/dir1
${INSTALL_DATA_DIR} ${PREFIX}/dir2</pre></td></tr></table>
</div>
</div>
</div>
<div class="chapter" lang="en">
<div class="titlepage">
<div><div><h2 class="title">
<a name="plist"></a>Chapter 6. PLIST issues</h2></div></div>
<div></div>
</div>
<div class="toc">
<p><b>Table of Contents</b></p>
<dl>
<dt>6.1. <a href="#plist.misc">Miscellaneous</a>
</dt>
<dt>6.2. <a href="#id2945543">PLIST_SRC</a>
</dt>
<dt>6.3. <a href="#id2945566">PLIST_SUBST</a>
</dt>
<dt>6.4. <a href="#id2945697">Perl5 modules</a>
</dt>
<dt>6.5. <a href="#id2945836">User Interaction</a>
</dt>
</dl>
</div>
<p>
This section addresses some special issues that one needs to pay attention
to when dealing with the <tt class="filename">PLIST</tt> file (or files, see below!).
</p>
<div class="sect1" lang="en">
<div class="titlepage">
<div><div><h2 class="title" style="clear: both">
<a name="plist.misc"></a>6.1. Miscellaneous</h2></div></div>
<div></div>
</div>
<div class="itemizedlist"><ul type="disc">
<li>
<p>NetBSD RCS Id</p>
<p>
Be sure to add a RCS ID line as the first thing in any
<tt class="filename">PLIST</tt> file you write:
</p>
<p>
</p>
<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre>@comment $NetBSD: pkgsrc.html,v 1.2 2003/06/23 07:49:44 grant Exp $</pre></td></tr></table>
<p>
</p>
</li>
<li>
<p>${MACHINE_ARCH}, ${MACHINE_GNU_ARCH}</p>
<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 &quot;${MACHINE_ARCH}&quot; will be replaced by
what <b class="command">uname -p</b> gives. The same is done if the string
${MACHINE_GNU_ARCH} is embedded in PLIST somewhere - use this on
packages that have GNU autoconf created configure scripts.
</p>
<p>
Legacy note: There used to be a symbol &quot;&lt;$ARCH&gt;&quot; that was replaced by
the output of <b class="command">uname -m</b>, but that's no longer supported
and has been removed.
</p>
</li>
<li>
<p>${OPSYS}, ${LOWER_OPSYS}, ${OS_VERSION}</p>
<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="circle">
<li>${OPSYS} - output of &quot;uname -s&quot;</li>
<li>${LOWER_OPSYS} - lowercase common name (eg. &quot;solaris&quot;)</li>
<li>${OS_VERSION} - &quot;uname -r&quot;</li>
</ul></div>
</li>
<li>
<p>${PKGLOCALEDIR}</p>
<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 OS's expect locale files to be either in
<tt class="filename">share</tt> or <tt class="filename">lib</tt> by default.
</p>
</li>
<li>
<p>Manpage-compression</p>
<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>
</li>
<li>
<p>Platform specific and differing PLISTs</p>
<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="circle">
<li><tt class="filename">PLIST.common</tt></li>
<li><tt class="filename">PLIST.${OPSYS}</tt></li>
<li><tt class="filename">PLIST.common_end</tt></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>
</li>
<li>
<p>Semi-automatic <tt class="filename">PLIST</tt> generation</p>
<p>
You can use the <b class="command">make print-PLIST</b> command to output
a PLIST that matches any new files since the package was extracted.
See below for more information on this target.
</p>
</li>
</ul></div>
</div>
<div class="sect1" lang="en">
<div class="titlepage">
<div><div><h2 class="title" style="clear: both">
<a name="id2945543"></a>6.2. PLIST_SRC</h2></div></div>
<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">
<div class="titlepage">
<div><div><h2 class="title" style="clear: both">
<a name="id2945566"></a>6.3. PLIST_SUBST</h2></div></div>
<div></div>
</div>
<p>
Similar to <tt class="varname">MESSAGE_SUBST</tt> (see above), you can add
variables and their expansions to this variable in the following way:
</p>
<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre>PLIST_SUBST+= SOMEVAR=&quot;somevalue&quot;</pre></td></tr></table>
<p>
which replaces all occurrences of &#8220;<span class="quote">${SOMEVAR}</span>&#8221; in the
<tt class="filename">PLIST</tt> with &#8220;<span class="quote">somevalue</span>&#8221;.
For the 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>
</div>
<div class="sect1" lang="en">
<div class="titlepage">
<div><div><h2 class="title" style="clear: both">
<a name="id2945697"></a>6.4. Perl5 modules</h2></div></div>
<div></div>
</div>
<p>
Makefile of packages providing perl5 modules should include the
makefile fragment <tt class="filename">lang/perl5/module.mk</tt>. It provides
a do-configure
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, the NetBSD
packages system will append lines to the <tt class="filename">PLIST</tt>
corresponding to the files
listed in the installed .packlist 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:
</p>
<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre>PERL5_PACKLIST= ${PERL5_SITEARCH}/auto/Pg/.packlist</pre></td></tr></table>
<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="sect1" lang="en">
<div class="titlepage">
<div><div><h2 class="title" style="clear: both">
<a name="id2945836"></a>6.5. User Interaction</h2></div></div>
<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>help in fetching the distfiles</li>
<li>help to configure the package before it is built</li>
<li>help during the build process</li>
<li>help during the installation of a package</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>
<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre>INTERACTIVE_STAGE= build</pre></td></tr></table>
<p>
Multiple interactive stages can be specified:
</p>
<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre>INTERACTIVE_STAGE= configure install</pre></td></tr></table>
</div>
</div>
<div class="chapter" lang="en">
<div class="titlepage">
<div><div><h2 class="title">
<a name="fixes"></a>Chapter 7. Notes on fixes for packages</h2></div></div>
<div></div>
</div>
<div class="toc">
<p><b>Table of Contents</b></p>
<dl>
<dt>7.1. <a href="#id2944290">CPP defines</a>
</dt>
<dt>7.2. <a href="#fixes.libtool">Shared libraries - libtool</a>
</dt>
<dt>7.3. <a href="#id2947315">Using libtool on GNU packages that already support libtool</a>
</dt>
<dt>7.4. <a href="#id2947414">GNU Autoconf/Automake</a>
</dt>
<dt>7.5. <a href="#id2947454">Package configuration files</a>
</dt>
<dt>7.6. <a href="#id2947668">Feedback to the author</a>
</dt>
</dl>
</div>
<div class="sect1" lang="en">
<div class="titlepage">
<div><div><h2 class="title" style="clear: both">
<a name="id2944290"></a>7.1. CPP defines</h2></div></div>
<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>
<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre>#include &lt;sys/param.h&gt;</pre></td></tr></table>
<p>
and then you can surround the BSD-specific parts of your port using
the conditional:
</p>
<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre>#if (defined(BSD) &amp;&amp; BSD &gt;= 199306)
...
#endif</pre></td></tr></table>
<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 class="sect1" lang="en">
<div class="titlepage">
<div><div><h2 class="title" style="clear: both">
<a name="fixes.libtool"></a>7.2. Shared libraries - libtool</h2></div></div>
<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:html="http://www.w3.org/1999/xhtml" href="ftp://ftp.netbsd.org/pub/NetBSD/packages/pkgsrc/devel/libtool/README.html" class="pkgname">devel/libtool</a> pkg
can help here, as it just &#8220;<span class="quote">knows</span>&#8221; how to build both static
and dynamic libraries from a set of source files, thus being platform
independent.
</p>
<p>
Here's how to use libtool in a pkg in seven simple steps:
</p>
<div class="orderedlist"><ol type="1">
<li><p>
Add <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 use instead:
</p>
<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre>${LIBTOOL} --mode=link ${CC} -o ${.TARGET:.a=.la} ${OBJS:.o=.lo} -rpath ${PREFIX}/lib -version-info major:minor</pre></td></tr></table>
<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>
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.<span class="emphasis"><em>major</em></span></tt> and
<tt class="filename">.so.<span class="emphasis"><em>major</em></span>.<span class="emphasis"><em>minor</em></span></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>
<tt class="filename">PLIST</tt> 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
<b class="command">cc</b> or <b class="command">ld</b> 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>
<div class="informalexample"><table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre>${LIBTOOL} --mode=link ${CC} -o someprog -L../somelib -lsomelib</pre></td></tr></table></div>
<p>
should be changed to:
</p>
<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre>${LIBTOOL} --mode=link ${CC} -o someprog ../somelib/somelib.la</pre></td></tr></table>
<p>
and it will do the right thing with the libraries.
</p>
</li>
<li>
<p>
When installing libraries, preface the <b class="command">install</b>
or <b class="command">cp</b> 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>
<div class="informalexample"><table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre>${LIBTOOL} --mode=install ${BSD_INSTALL_DATA} ${SOMELIB:.a=.la} ${PREFIX}/lib</pre></td></tr></table></div>
<p>
This will install the static <tt class="filename">.a</tt>, shared
library, any needed symlinks, and run <b class="command">ldconfig</b>.
</p>
</li>
</ol></div>
</div>
<div class="sect1" lang="en">
<div class="titlepage">
<div><div><h2 class="title" style="clear: both">
<a name="id2947315"></a>7.3. Using libtool on GNU packages that already support libtool</h2></div></div>
<div></div>
</div>
<p>
Add <tt class="varname">USE_LIBTOOL=yes</tt> and
<tt class="varname">LTCONFIG_OVERRIDE=${WRKSRC}/ltconfig</tt> to the
package Makefile as the quick way to bypass the pkg's own
<span class="emphasis"><em>libtool</em></span>. The pkg's own
<span class="emphasis"><em>libtool</em></span> is created by ltconfig script at
do-configure target. If <tt class="varname">USE_LIBTOOL</tt> and
<tt class="varname">LTCONFIG_OVERRIDE</tt> are defined, the specified
ltconfig is overridden, using <a xmlns:html="http://www.w3.org/1999/xhtml" href="ftp://ftp.netbsd.org/pub/NetBSD/packages/pkgsrc/devel/libtool/README.html" class="pkgname">devel/libtool</a> instead of
the pkg's own libtool. For newer versions of libtool (without
ltconfig) it may be necessary to use
<tt class="varname">LIBTOOL_OVERRIDE=${WRKSRC}/libtool</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 buildlink2.mk (and
set <tt class="varname">USE_BUILDLINK2=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>
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:
<div class="orderedlist"><ol type="1">
<li>The shared object is named correctly, i.e.
<tt class="filename">libfoo.la</tt>, not
<tt class="filename">foo.la</tt>
</li>
<li>The -dlopen option is used when linking an executable.</li>
</ol></div>
</li>
<li>
The use of libltdl without the correct calls to initialisation routines.
The function lt_dlinit() should be called and the macro
LTDL_SET_PRELOADED_SYMBOLS included in executables.
</li>
</ul></div>
</div>
<div class="sect1" lang="en">
<div class="titlepage">
<div><div><h2 class="title" style="clear: both">
<a name="id2947414"></a>7.4. GNU Autoconf/Automake</h2></div></div>
<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
pkgsrc/mk/autoconf.mk and pkgsrc/mk/automake.mk to help
dealing with these tools. See comments in these files for
details.
</p>
<p>
For packages that need only autoconf:
</p>
<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre>AUTOCONF_REQD= 2.50 # if default version is not good enough
...
pre-configure:
cd ${WRKSRC}; ${AUTOCONF}
...
.include &quot;../../mk/autoconf.mk&quot;</pre></td></tr></table>
<p>
and for packages that need automake and autoconf:
</p>
<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre>AUTOMAKE_REQD= 1.7.1 # if default version is not good enough
...
pre-configure:
cd ${WRKSRC}; \
${ACLOCAL}; \
${AUTOHEADER}; \
${AUTOMAKE} -a --foreign -i; \
${AUTOCONF}
...
.include &quot;../mk/automake.mk&quot;</pre></td></tr></table>
<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 class="sect1" lang="en">
<div class="titlepage">
<div><div><h2 class="title" style="clear: both">
<a name="id2947454"></a>7.5. Package configuration files</h2></div></div>
<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=${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="sect1" lang="en">
<div class="titlepage">
<div><div><h2 class="title" style="clear: both">
<a name="id2947668"></a>7.6. Feedback to the author</h2></div></div>
<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">
<div class="titlepage">
<div><div><h2 class="title">
<a name="build"></a>Chapter 8. The build process</h2></div></div>
<div></div>
</div>
<div class="toc">
<p><b>Table of Contents</b></p>
<dl>
<dt>8.1. <a href="#build.prefix">Program location</a>
</dt>
<dt>8.2. <a href="#id2949108">Main targets</a>
</dt>
<dt>8.3. <a href="#build.helpful-targets">Other helpful targets</a>
</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">
<div class="titlepage">
<div><div><h2 class="title" style="clear: both">
<a name="build.prefix"></a>8.1. Program location</h2></div></div>
<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, though its value becomes that of <tt class="varname">X11BASE</tt> if
<tt class="varname">USE_IMAKE</tt> or <tt class="varname">USE_X11BASE</tt> is set.
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="5.3. patches/*">Section 5.3, &#8220;patches/*&#8221;</a> and <a href="#fixes.libtool" title="7.2. Shared libraries - libtool">Section 7.2, &#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 pkgs are special in that they may be installed in either
<tt class="varname">X11BASE</tt> or <tt class="varname">LOCALBASE</tt>. To install X11
packages in <tt class="varname">LOCALBASE</tt>, simply install
<a xmlns:html="http://www.w3.org/1999/xhtml" href="ftp://ftp.netbsd.org/pub/NetBSD/packages/pkgsrc/pkgtools/xpkgwedge/README.html" class="pkgname">pkgtools/xpkgwedge</a>. 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 Makefile, you need to
use <span class="emphasis"><em>both</em></span> &#8220;<span class="quote">${X11BASE}</span>&#8221; and
&#8220;<span class="quote">${LOCALBASE}</span>&#8221;.
</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>
<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre>EVAL_PREFIX+= GTKDIR=gtk+
CONFIGURE_ARGS+= --with-guile-prefix=${LOCALBASE} \
--with-gtk-prefix=&quot;${GTKDIR}&quot; \
--enable-multibyte</pre></td></tr></table>
<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>
<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre>GTKDIR_DEFAULT= ${LOCALBASE}</pre></td></tr></table>
<p>
where <tt class="varname">GTKDIR</tt> corresponds to the first definition in
the <tt class="varname">EVAL_PREFIX</tt> pair.
</p>
</li>
</ul></div>
</div>
<div class="sect1" lang="en">
<div class="titlepage">
<div><div><h2 class="title" style="clear: both">
<a name="id2949108"></a>8.2. Main targets</h2></div></div>
<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="itemizedlist"><ul type="disc">
<li>
<p>fetch</p>
<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>
<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre>${FETCH_CMD} ${FETCH_BEFORE_ARGS} ${site}${file} ${FETCH_AFTER_ARGS}</pre></td></tr></table>
<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>
</li>
<li>
<p>checksum</p>
<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>
</li>
<li>
<p>extract</p>
<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>. 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>. If the distfiles
are not in <tt class="filename">.tar.gz</tt> format, they can be
extracted by setting <tt class="varname">EXTRACT_CMD</tt>,
<tt class="varname">EXTRACT_BEFORE_ARGS</tt> and/or
<tt class="varname">EXTRACT_AFTER_ARGS</tt>.
</p>
</li>
<li>
<p>patch</p>
<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="5.3. patches/*">Section 5.3, &#8220;patches/*&#8221;</a> for more details.
</p>
<p>
By default patch is given special args to make it fail if the
patches with some lines of fuzz. Please fix (regen) the patches
so that they apply cleanly. The rationale behind this is that
patches that apply cleanly may end up being applied in the wrong
place, and cause severe harm there.
</p>
</li>
<li>
<p>configure</p>
<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;.
</p>
<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>
</li>
<li>
<p>build</p>
<p>
Once configuration has taken place, the software can be built on
NetBSD 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 to
change the default build process.
</p>
</li>
<li>
<p>install</p>
<p>
Once the build stage has completed, the final step is to install
the software in public directories, for users. 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>
</li>
</ul></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.
<b class="command">make build</b> will also perform the equivalent of:
</p>
<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre>make fetch
make checksum
make extract
make patch
make configure
make build</pre></td></tr></table>
</div>
<div class="sect1" lang="en">
<div class="titlepage">
<div><div><h2 class="title" style="clear: both">
<a name="build.helpful-targets"></a>8.3. Other helpful targets</h2></div></div>
<div></div>
</div>
<div class="itemizedlist"><ul type="disc">
<li>
<p>pre/post-*</p>
<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, for example, which program's configure script
or install target omitted.
</p>
</li>
<li>
<p>do-*</p>
<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>
</li>
<li>
<p>reinstall</p>
<p>
If you did a <b class="command">make install</b> 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>
</li>
<li>
<p>deinstall</p>
<p>
This target does a pkg_delete(1) in the current directory,
effectively de-installing the package. The following variables can
be used either on the command line or in
<tt class="filename">/etc/mk.conf</tt> to tune the behaviour:
</p>
<div class="itemizedlist"><ul type="circle">
<li>
<p><tt class="varname">PKG_VERBOSE</tt></p>
<p>
Add a &quot;-v&quot; to the pkg_delete(1) command.
</p>
</li>
<li>
<p><tt class="varname">DEINSTALLDEPENDS</tt></p>
<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 <b class="command">make deinstall
DEINSTALLDEPENDS=1</b> 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 pkg_delete command line.
</p>
</li>
</ul></div>
</li>
<li>
<p>update</p>
<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 <b class="command">make
deinstall</b> and <b class="command">make install</b> (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 <b class="command">make update</b> was interrupted
for some reason. However, in this case, make sure you don't call
<b class="command">make clean</b> 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 <b class="command">make update</b> 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
<b class="command">make update</b> 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
<b class="command">make update</b>:
</p>
<div class="itemizedlist"><ul type="circle">
<li>
<tt class="varname">UPDATE_TARGET</tt><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 <b class="command">make update</b>.
e.g. <b class="command">make update UPDATE_TARGET=package</b>
</p>
</li>
<li>
<tt class="varname">NOCLEAN</tt><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 <b class="command">make</b> or <b class="command">make update</b>.
</p>
</li>
<li>
<tt class="varname">REINSTALL</tt><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 <b class="command">make update</b>.
</p>
</li>
<li>
<tt class="varname">DEPENDS_TARGET</tt><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
<b class="command">make update</b> (see above).
</p>
</li>
</ul></div>
</li>
<li>
<p>clean-update</p>
<p>
Clean the source tree for all packages that would get updated if
<b class="command">make update</b> 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
<b class="command">make update</b>) 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
<b class="command">make update</b> 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 <b class="command">make clean</b> 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
<b class="command">make update</b> for the first time, otherwise you lose
all the packages you wanted to update!):
</p>
<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre><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></td></tr></table>
<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
<b class="command">make clean-update</b>:
</p>
<div class="itemizedlist"><ul type="circle"><li>
<tt class="varname">CLEAR_DIRLIST</tt><p>
After <b class="command">make clean</b>, do not reconstruct the list of
directories to update for this package. Only use this if <b class="command">make
update</b> successfully installed all packages you wanted to
update. Normally, this is done automatically on <b class="command">make
update</b>, but may have been suppressed by the
<tt class="varname">NOCLEAN</tt> variable (see above).
</p>
</li></ul></div>
</li>
<li>
<p>info</p>
<p>
This target invokes <b class="command">pkg_info</b> for the current
package. You can use this to check which version of a package is
installed.
</p>
</li>
<li>
<p>readme</p>
<p>
This target generates a <tt class="filename">README.html</tt> file, which
can be viewed using a browser such as <a xmlns:html="http://www.w3.org/1999/xhtml" href="ftp://ftp.netbsd.org/pub/NetBSD/packages/pkgsrc/www/navigator/README.html" class="pkgname">www/navigator</a> or
<a xmlns:html="http://www.w3.org/1999/xhtml" href="ftp://ftp.netbsd.org/pub/NetBSD/packages/pkgsrc/www/lynx/README.html" class="pkgname">www/lynx</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>
</li>
<li>
<p>readme-all</p>
<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 <b class="command">make readme</b>.
</p>
</li>
<li>
<p>cdrom-readme</p>
<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>
</li>
<li>
<p>show-distfiles</p>
<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>
</li>
<li>
<p>show-downlevel</p>
<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>
</li>
<li>
<p>show-pkgsrc-dir</p>
<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>
</li>
<li>
<p>show-installed-depends</p>
<p>
This target shows which installed packages match the current package's
<tt class="varname">DEPENDS</tt>. Useful if out of date DEPENDS are
causing build problems.
</p>
</li>
<li>
<p>check-shlibs</p>
<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>
</li>
<li>
<p>print-PLIST</p>
<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 <b class="command">find -newer work/.extract_done</b>.
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 &#8220;<span class="quote">find -newer</span>&#8221; won't catch
them!
</p>
</li>
<li>
<p>bulk-package</p>
<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">Section 4.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>
</li>
<li>
<p>bulk-install</p>
<p>
Used during bulk-installs to install required packages. If an
appropriate binary package is available, it will be installed via
pkg_add. If not, <b class="command">make bulk-package</b> will be executed,
but the installed binary not be removed. A binary package is
&#8220;<span class="quote">appropriate</span>&#8221; to be installed via <b class="command">pkg_add</b>
if:
</p>
<div class="itemizedlist"><ul type="circle">
<li>None of the package's files (<tt class="filename">Makefile</tt>,
...) were modified since it was built.</li>
<li>None of the package's required (binary) packages were
modified since it was built.</li>
</ul></div>
</li>
</ul></div>
</div>
</div>
<div class="chapter" lang="en">
<div class="titlepage">
<div><div><h2 class="title">
<a name="buildlink2"></a>Chapter 9. buildlink2 methodology</h2></div></div>
<div></div>
</div>
<div class="toc">
<p><b>Table of Contents</b></p>
<dl>
<dt>9.1. <a href="#id2953172">Converting packages to use buildlink2</a>
</dt>
<dt>9.2. <a href="#id2953308">Writing buildlink2.mk files</a>
</dt>
</dl>
</div>
<p>
buildlink2 is a pkgsrc framework 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 &#8220;<span class="quote">-I${LOCALBASE}/include</span>&#8221; and
&#8220;<span class="quote">-L${LOCALBASE}/lib</span>&#8221; into references to
<tt class="varname">BUILDLINK_DIR</tt>.
</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 may other software may
installed. Please refer to
<tt class="filename">pkgsrc/mk/buildlink2/buildlink2.txt</tt> for some
FAQs and answers regarding buildlink2, and to
<tt class="filename">pkgsrc/mk/buildlink2/README</tt>
for a description of how buildlink2 is implemented in pkgsrc.
</p>
<div class="sect1" lang="en">
<div class="titlepage">
<div><div><h2 class="title" style="clear: both">
<a name="id2953172"></a>9.1. Converting packages to use buildlink2</h2></div></div>
<div></div>
</div>
<p>
The process of converting packages to use the buildlink2 framework is
fairly straightforward. The package <tt class="filename">Makefile</tt> must
define <tt class="varname">USE_BUILDLINK2</tt>.
If a dependency on a particular package, e.g. foo, is required for its
libraries and headers, then we replace:
</p>
<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre>DEPENDS+= foo&gt;=1.1.0:../../category/foo</pre></td></tr></table>
<p>
with
</p>
<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre>.include &quot;../../category/foo/buildlink2.mk&quot;</pre></td></tr></table>
<p>
There are several buildlink2.mk 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">motif.buildlink2.mk</tt> checks for a system-provided
Motif installation or adds a dependency on <a xmlns:html="http://www.w3.org/1999/xhtml" href="ftp://ftp.netbsd.org/pub/NetBSD/packages/pkgsrc/x11/lesstif/README.html" class="pkgname">x11/lesstif</a> or
<a xmlns:html="http://www.w3.org/1999/xhtml" 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.buildlink2.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">pthread.buildlink2.mk</tt> uses the value of
<tt class="varname">PTHREAD_OPTS</tt> and checks for native pthreads or adds
a dependency on <a xmlns:html="http://www.w3.org/1999/xhtml" href="ftp://ftp.netbsd.org/pub/NetBSD/packages/pkgsrc/devel/pth/README.html" class="pkgname">devel/pth</a> as needed;
</p></li>
<li><p>
<tt class="filename">xaw.buildlink2.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 buildlink2.mk files provide a more complete
description of how to use them properly.
</p>
</div>
<div class="sect1" lang="en">
<div class="titlepage">
<div><div><h2 class="title" style="clear: both">
<a name="id2953308"></a>9.2. Writing buildlink2.mk files</h2></div></div>
<div></div>
</div>
<p>
A simple example of a buildlink2.mk file for a mythical package foo
follows:
</p>
<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre>BUILDLINK_PACKAGES+= foo
BUILDLINK_PKGBASE.foo= foo
BUILDLINK_DEPENDS.foo?= foo&gt;=1.0
BUILDLINK_PKGSRCDIR.foo?= ../../category/foo
EVAL_PREFIX+= BUILDLINK_PREFIX.foo=foo
BUILDLINK_PREFIX.foo_DEFAULT= ${LOCALBASE}
BUILDLINK_FILES.foo= include/foo.h
BUILDLINK_FILES.foo+= include/bar.h
BUILDLINK_FILES.foo+= lib/libfoo.*
BUILDLINK_TARGETS+= foo-buildlink
foo-buildlink: _BUILDLINK_USE</pre></td></tr></table>
<p>
The first section controls how the dependency on foo is added. The
dependency is constructed from four parts:
</p>
<div class="orderedlist"><ol type="1">
<li><p>
<tt class="varname">BUILDLINK_PACKAGES</tt> is the global list of packages
for which dependencies will be added by buildlink2;
</p></li>
<li><p>
<tt class="varname">BUILDLINK_DEPENDS.foo</tt> is the actual dependency
recorded in the installed package;
</p></li>
<li><p>
<tt class="varname">BUILDLINK_PKGSRCDIR.foo</tt> is the location of the
foo pkgsrc directory;
</p></li>
<li><p>
<tt class="varname">BUILDLINK_DEPMETHOD.foo</tt> (not shown above) controls
whether we use <tt class="varname">BUILD_DEPENDS</tt> or
<tt class="varname">DEPENDS</tt> to add the foo dependency, where the
full dependency is added if
<tt class="varname">BUILDLINK_DEPMETHOD.foo</tt> contains &#8220;<span class="quote">full</span>&#8221;.
</p></li>
</ol></div>
<p>
The second section controls which files are linked into
<tt class="varname">BUILDLINK_DIR</tt>:
</p>
<div class="orderedlist"><ol type="1">
<li><p>
<tt class="varname">BUILDLINK_PREFIX.foo</tt> is the installation prefix of
the package which we derive by using <tt class="varname">EVAL_PREFIX</tt>;
</p></li>
<li><p>
<tt class="varname">BUILDLINK_FILES.foo</tt> is a list of files (shell globs
allowed) relative to the <tt class="varname">BUILDLINK_PREFIX.foo</tt>
directory and will be symlinked into <tt class="varname">BUILDLINK_DIR</tt>;
</p></li>
<li><p>
<tt class="varname">BUILDLINK_FILES_CMD.foo</tt> (not shown above) is a
shell pipeline that outputs a list of files relative to the
<tt class="varname">BUILDLINK_PREFIX.foo</tt> directory and will be symlinked
into <tt class="varname">BUILDLINK_DIR</tt>.
</p></li>
</ol></div>
<p>
The remaining parts create the &#8220;<span class="quote">foo-buildlink</span>&#8221; target that
actually performs the symlinking and adds the
&#8220;<span class="quote">foo-buildlink</span>&#8221; target to
<tt class="varname">BUILDLINK_TARGETS</tt>, which is the global list of targets
to execute at do-buildlink time.
</p>
</div>
</div>
<div class="chapter" lang="en">
<div class="titlepage">
<div><div><h2 class="title">
<a name="debug"></a>Chapter 10. Debugging</h2></div></div>
<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:html="http://www.w3.org/1999/xhtml" href="ftp://ftp.netbsd.org/pub/NetBSD/packages/pkgsrc/pkgtools/url2pkg/README.html" class="pkgname">pkgtools/url2pkg</a> and run
</p>
<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre><tt class="prompt">#</tt> <b class="userinput"><tt>url2pkg http://www.example.com/path/to/distfile.tar.gz</tt></b></pre></td></tr></table>
</li>
<li><p>
Edit the <tt class="filename">Makefile</tt> as requested.
</p></li>
<li><p>Fill in <tt class="filename">DESCR</tt>
</p></li>
<li><p>
Run <b class="command">make configure</b>
</p></li>
<li><p>
Add any dependencies glimpsed from 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>
<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre><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></td></tr></table>
<p>
Doing as non-root user will ensure that no files are modified that
shouldn't be, especially during the build phase.
</p>
</li>
<li><p>
Look at <tt class="filename">Makefile</tt>, fix if necessary; see <a href="#components.Makefile" title="5.1. Makefile">Section 5.1, &#8220;Makefile&#8221;</a>.
</p></li>
<li>
<p>
Generate a <tt class="filename">PLIST</tt>:
</p>
<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre><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></td></tr></table>
<p>
You usually need to be root to do this. Look if there are any files left:
</p>
<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre><tt class="prompt">#</tt> <b class="userinput"><tt>make print-PLIST</tt></b></pre></td></tr></table>
<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>
<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre><tt class="prompt">#</tt> <b class="userinput"><tt>make reinstall &amp;&amp; make package</tt></b></pre></td></tr></table>
</li>
<li>
<p>
Delete the installed package:
</p>
<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre><tt class="prompt">#</tt> <b class="userinput"><tt>pkg_delete blub</tt></b></pre></td></tr></table>
</li>
<li>
<p>
Repeat the above find command, which shouldn't find anything now:
</p>
<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre><tt class="prompt">#</tt> <b class="userinput"><tt>make print-PLIST</tt></b></pre></td></tr></table>
</li>
<li>
<p>
Reinstall the binary package:
</p>
<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre><tt class="prompt">#</tt> <b class="userinput"><tt>pkgadd .../blub.tgz</tt></b></pre></td></tr></table>
</li>
<li><p>
Play with it. Make sure everything works.
</p></li>
<li>
<p>
Run <b class="command">pkglint</b> from <a xmlns:html="http://www.w3.org/1999/xhtml" href="ftp://ftp.netbsd.org/pub/NetBSD/packages/pkgsrc/pkgtools/pkglint/README.html" class="pkgname">pkgtools/pkglint</a>, and fix the
problems it reports.
</p>
<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre><tt class="prompt">#</tt> <b class="userinput"><tt>pkglint</tt></b></pre></td></tr></table>
</li>
<li><p>
Submit (or commit, if you have cvs access); see <a href="#submit" title="Chapter 12. Submitting and Committing">Chapter 12, <i>Submitting and Committing</i></a>.
</p></li>
</ul></div>
</div>
<div class="chapter" lang="en">
<div class="titlepage">
<div><div><h2 class="title">
<a name="features"></a>Chapter 11. FAQs &amp; features of the package system</h2></div></div>
<div></div>
</div>
<div class="toc">
<p><b>Table of Contents</b></p>
<dl>
<dt>11.1. <a href="#id2952494">Packages using GNU autoconf</a>
</dt>
<dt>11.2. <a href="#id2954262">Other distrib methods than .tar.gz</a>
</dt>
<dt>11.3. <a href="#id2954307">Packages not creating their own subdirectory</a>
</dt>
<dt>11.4. <a href="#id2955763">Custom configuration process</a>
</dt>
<dt>11.5. <a href="#id2955785">Packages not building in their DISTNAME directory</a>
</dt>
<dt>11.6. <a href="#id2955896">How to fetch all distfiles at once</a>
</dt>
<dt>11.7. <a href="#id2956076">How to fetch files from behind a firewall</a>
</dt>
<dt>11.8. <a href="#id2956098">If your patch contains an RCS ID</a>
</dt>
<dt>11.9. <a href="#id2956116">How to pull in variables from /etc/mk.conf</a>
</dt>
<dt>11.10. <a href="#id2956180">Is there a mailing list for pkg-related discussion?</a>
</dt>
<dt>11.11. <a href="#id2956204">How do I tell make fetch to do passive FTP?</a>
</dt>
<dt>11.12. <a href="#id2956350">Dependencies on other packages</a>
</dt>
<dt>11.13. <a href="#id2956571">Conflicts with other packages</a>
</dt>
<dt>11.14. <a href="#id2956642">Software which has a WWW Home Page</a>
</dt>
<dt>11.15. <a href="#id2956667">How to handle modified distfiles with the 'old' name</a>
</dt>
<dt>11.16. <a href="#id2956764">What does &quot;Don't know how to make /usr/share/tmac/tmac.andoc&quot; mean?</a>
</dt>
<dt>11.17. <a href="#id2956809">How to handle incrementing versions when fixing an existing
package</a>
</dt>
<dt>11.18. <a href="#id2956956">Could not find bsd.own.mk - what's wrong?</a>
</dt>
<dt>11.19. <a href="#id2957027">Restricted packages</a>
</dt>
<dt>11.20. <a href="#id2957213">Packages using (n)curses</a>
</dt>
<dt>11.21. <a href="#id2957255">Automated security check</a>
</dt>
<dt>11.22. <a href="#id2957425">What's the proper way to create an account from a package?</a>
</dt>
<dt>11.23. <a href="#id2957593">How to handle compiler bugs</a>
</dt>
<dt>11.24. <a href="#features.info-files">Packages providing info files</a>
</dt>
<dt>11.25. <a href="#id2957793">Packages whose distfiles aren't available for plain downloading</a>
</dt>
<dt>11.26. <a href="#id2957953">Configuration files handling and placement</a>
</dt>
<dt>11.27. <a href="#id2958470">Packages providing login shells</a>
</dt>
<dt>11.28. <a href="#id2958558">Packages providing locale catalogues</a>
</dt>
<dt>11.29. <a href="#id2958592">Using 'sudo' with pkgsrc</a>
</dt>
<dt>11.30. <a href="#id2958621">Packages containing perl scripts</a>
</dt>
<dt>11.31. <a href="#id2958648">Packages that cannot or should not be built</a>
</dt>
</dl>
</div>
<div class="sect1" lang="en">
<div class="titlepage">
<div><div><h2 class="title" style="clear: both">
<a name="id2952494"></a>11.1. Packages using GNU autoconf</h2></div></div>
<div></div>
</div>
<p>
If your package uses GNU autoconf created configure scripts, add the following
to your package's <tt class="filename">Makefile</tt>:
</p>
<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre>GNU_CONFIGURE= yes</pre></td></tr></table>
<p>
Note that this appends &#8220;<span class="quote">--prefix=${PREFIX}</span>&#8221; to
<tt class="varname">CONFIGURE_ARGS</tt>, so you don't
have to do that yourself, but may not be desired.
</p>
</div>
<div class="sect1" lang="en">
<div class="titlepage">
<div><div><h2 class="title" style="clear: both">
<a name="id2954262"></a>11.2. Other distrib methods than .tar.gz</h2></div></div>
<div></div>
</div>
<p>
If your package uses a different distribution method from
<tt class="filename">.tar.gz</tt>, take a
look at the package for <a xmlns:html="http://www.w3.org/1999/xhtml" href="ftp://ftp.netbsd.org/pub/NetBSD/packages/pkgsrc/editors/sam/README.html" class="pkgname">editors/sam</a>, which uses a gzipped shell archive
(shar), but the quick solution is to set
<tt class="varname">EXTRACT_SUFX</tt> to the name after the
<tt class="varname">DISTNAME</tt> field, and add the following to your
package's <tt class="filename">Makefile</tt>:
</p>
<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre>EXTRACT_SUFX= .msg.gz
EXTRACT_CMD= zcat
EXTRACT_BEFORE_ARGS=
EXTRACT_AFTER_ARGS= |sh</pre></td></tr></table>
</div>
<div class="sect1" lang="en">
<div class="titlepage">
<div><div><h2 class="title" style="clear: both">
<a name="id2954307"></a>11.3. Packages not creating their own subdirectory</h2></div></div>
<div></div>
</div>
<p>
Your package doesn't create a subdirectory for itself (like GNU software
does, for instance), but extracts itself in the current directory: see
<a xmlns:html="http://www.w3.org/1999/xhtml" href="ftp://ftp.netbsd.org/pub/NetBSD/packages/pkgsrc/editors/sam/README.html" class="pkgname">editors/sam</a> again, but the quick answer is:
</p>
<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre>WRKSRC= ${WRKDIR}</pre></td></tr></table>
<p>
Please note that the old:
</p>
<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre>NO_WRKSUBDIR= yes</pre></td></tr></table>
<p>
has been deprecated and should not be used.
</p>
</div>
<div class="sect1" lang="en">
<div class="titlepage">
<div><div><h2 class="title" style="clear: both">
<a name="id2955763"></a>11.4. Custom configuration process</h2></div></div>
<div></div>
</div>
<p>
Your package uses a weird Configure script, eg.
<a xmlns:html="http://www.w3.org/1999/xhtml" href="ftp://ftp.netbsd.org/pub/NetBSD/packages/pkgsrc/sysutils/top/README.html" class="pkgname">sysutils/top</a>. The quick answer is:
</p>
<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre>HAS_CONFIGURE= yes
CONFIGURE_SCRIPT= Configure
CONFIGURE_ARGS+= netbsd13</pre></td></tr></table>
</div>
<div class="sect1" lang="en">
<div class="titlepage">
<div><div><h2 class="title" style="clear: both">
<a name="id2955785"></a>11.5. Packages not building in their DISTNAME directory</h2></div></div>
<div></div>
</div>
<p>
Your package builds in a different directory from its base
<tt class="varname">DISTNAME</tt> (see <a xmlns:html="http://www.w3.org/1999/xhtml" href="ftp://ftp.netbsd.org/pub/NetBSD/packages/pkgsrc/lang/tcl/README.html" class="pkgname">lang/tcl</a> and
<a xmlns:html="http://www.w3.org/1999/xhtml" href="ftp://ftp.netbsd.org/pub/NetBSD/packages/pkgsrc/x11/tk/README.html" class="pkgname">x11/tk</a>).
</p>
<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre>WRKSRC= ${WRKDIR}/${DISTNAME}/unix</pre></td></tr></table>
</div>
<div class="sect1" lang="en">
<div class="titlepage">
<div><div><h2 class="title" style="clear: both">
<a name="id2955896"></a>11.6. How to fetch all distfiles at once</h2></div></div>
<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 <b class="command">make fetch</b>. 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 <b class="command">make fetch-list</b> in
<tt class="filename">/usr/pkgsrc</tt>, 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 an URL:
</p>
<p>
At home:
</p>
<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre><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></td></tr></table>
<p>
At work:
</p>
<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre><tt class="prompt">%</tt> <b class="userinput"><tt>sh /tmp/fetch.sh</tt></b></pre></td></tr></table>
<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 <b class="command">make fetch-list</b> approach, or
fetch the distfiles directly by running:
</p>
<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre><tt class="prompt">%</tt> <b class="userinput"><tt>make mirror-distfiles</tt></b></pre></td></tr></table>
<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>
<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre><tt class="prompt">%</tt> <b class="userinput"><tt>make fetch NO_SKIP=yes</tt></b></pre></td></tr></table>
</div>
<div class="sect1" lang="en">
<div class="titlepage">
<div><div><h2 class="title" style="clear: both">
<a name="id2956076"></a>11.7. How to fetch files from behind a firewall</h2></div></div>
<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>
<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre>ftp_proxy=ftp://orpheus.amdahl.com:80/
http_proxy=http://orpheus.amdahl.com:80/</pre></td></tr></table>
</div>
<div class="sect1" lang="en">
<div class="titlepage">
<div><div><h2 class="title" style="clear: both">
<a name="id2956098"></a>11.8. If your patch contains an RCS ID</h2></div></div>
<div></div>
</div>
<p>
See <a href="#components.patches" title="5.3. patches/*">Section 5.3, &#8220;patches/*&#8221;</a> for information on how to
remove RCS IDs from patch files.
</p>
</div>
<div class="sect1" lang="en">
<div class="titlepage">
<div><div><h2 class="title" style="clear: both">
<a name="id2956116"></a>11.9. How to pull in variables from /etc/mk.conf</h2></div></div>
<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 make(1) 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>
<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre>.include &quot;../../mk/bsd.prefs.mk&quot;
.if defined(USE_MENUS)
...
.endif</pre></td></tr></table>
</div>
<div class="sect1" lang="en">
<div class="titlepage">
<div><div><h2 class="title" style="clear: both">
<a name="id2956180"></a>11.10. Is there a mailing list for pkg-related discussion?</h2></div></div>
<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>
<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre>% echo subscribe tech-pkg | mail majordomo@NetBSD.org</pre></td></tr></table>
</div>
<div class="sect1" lang="en">
<div class="titlepage">
<div><div><h2 class="title" style="clear: both">
<a name="id2956204"></a>11.11. How do I tell <b class="command">make fetch</b> to do passive FTP?</h2></div></div>
<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>
<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre>/usr/bin/fetch
${LOCALBASE}/bsd/bin/ftp
/usr/bin/ftp</pre></td></tr></table>
<p>
On a default NetBSD install, 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">
<div class="titlepage">
<div><div><h2 class="title" style="clear: both">
<a name="id2956350"></a>11.12. Dependencies on other packages</h2></div></div>
<div></div>
</div>
<p>
Your package may depend on some other package being present - and there are
various ways of expressing this dependency. NetBSD supports the
<tt class="varname">BUILD_DEPENDS</tt> and <tt class="varname">DEPENDS</tt> definitions,
as well as dependencies via
<tt class="filename">buildlink2.mk</tt> (see <a href="#buildlink2" title="Chapter 9. buildlink2 methodology">Chapter 9, <i>buildlink2 methodology</i></a>).
</p>
<p>
The basic difference between the two definitions is as follows: The
<tt class="varname">DEPENDS</tt> definition registers that pre-requisite in the binary package,
whilst the <tt class="varname">BUILD_DEPENDS</tt> definition does not.
</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>
<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre>&lt;pre-req-package-name&gt;:../../&lt;category&gt;/&lt;pre-req-package&gt;</pre></td></tr></table>
<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 pkg_info(1).
</p>
<div class="orderedlist"><ol type="1">
<li>
<p>
If your package needs to use another package to build itself, this
is specified using the <tt class="varname">BUILD_DEPENDS</tt> definition.
</p>
<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre>BUILD_DEPENDS+= autoconf-2.13:../../devel/autoconf</pre></td></tr></table>
</li>
<li>
<p>
If your package needs a library with which to link, this is specified
using the <tt class="varname">DEPENDS</tt> definition. An example of this is
the <a xmlns:html="http://www.w3.org/1999/xhtml" href="ftp://ftp.netbsd.org/pub/NetBSD/packages/pkgsrc/print/lyx/README.html" class="pkgname">print/lyx</a>
package, which uses the xpm library, version 3.4j to build.
</p>
<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre>DEPENDS+= xpm-3.4j:../../graphics/xpm</pre></td></tr></table>
<p>
You can also use wildcards in package dependences:
</p>
<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre>DEPENDS+= xpm-[0-9]*:../../graphics/xpm</pre></td></tr></table>
<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 -[0-9]* should be used instead of -* to avoid potentially
ambiguous matches such as tk-postgresql matching a tk-*
<tt class="varname">DEPENDS</tt>.
</p>
</li>
<li>
<p>
If your package needs some executable to be able to run correctly, this
is specified using the <tt class="varname">DEPENDS</tt> definition. The
<a xmlns:html="http://www.w3.org/1999/xhtml" href="ftp://ftp.netbsd.org/pub/NetBSD/packages/pkgsrc/print/lyx/README.html" class="pkgname">print/lyx</a> package needs
to be able to execute the latex binary from the teTeX package when it runs,
and that is specified:
</p>
<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre>DEPENDS+= teTeX-[0-9]*:../../print/teTeX</pre></td></tr></table>
<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:html="http://www.w3.org/1999/xhtml" href="ftp://ftp.netbsd.org/pub/NetBSD/packages/pkgsrc/print/ghostscript5/README.html" class="pkgname">print/ghostscript5</a> package
(it relies on the jpeg sources being present in source form during the
build):
</p>
<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre>if [ ! -e ${_PKGSRCDIR}/graphics/jpeg/${WRKDIR:T}/jpeg-6b ]; then \
cd ${_PKGSRCDIR}/../../graphics/jpeg &amp;&amp; ${MAKE} extract; \
fi</pre></td></tr></table>
<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>
<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre>pre-clean:
cd ${_PKGSRCDIR}/../../graphics/jpeg &amp;&amp; ${MAKE} clean</pre></td></tr></table>
<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:html="http://www.w3.org/1999/xhtml" href="ftp://ftp.netbsd.org/pub/NetBSD/packages/pkgsrc/devel/gettext/README.html" class="pkgname">devel/gettext</a> package. The latter adds a build dependency on either an
installed version of an older gettext package, or if it isn't, installs the
<a xmlns:html="http://www.w3.org/1999/xhtml" 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="sect1" lang="en">
<div class="titlepage">
<div><div><h2 class="title" style="clear: both">
<a name="id2956571"></a>11.13. Conflicts with other packages</h2></div></div>
<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:html="http://www.w3.org/1999/xhtml" href="ftp://ftp.netbsd.org/pub/NetBSD/packages/pkgsrc/x11/Xaw3d/README.html" class="pkgname">x11/Xaw3d</a> and
<a xmlns:html="http://www.w3.org/1999/xhtml" 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>
<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre>CONFLICTS= Xaw-Xpm-[0-9]*</pre></td></tr></table>
<p>
and in <tt class="filename">pkgsrc/x11/Xaw-Xpm/Makefile</tt>:
</p>
<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre>CONFLICTS= Xaw3d-[0-9]*</pre></td></tr></table>
<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="sect1" lang="en">
<div class="titlepage">
<div><div><h2 class="title" style="clear: both">
<a name="id2956642"></a>11.14. Software which has a WWW Home Page</h2></div></div>
<div></div>
</div>
<p>
The NetBSD packages system now supports a variable called
<tt class="varname">HOMEPAGE</tt>.
If the software being packaged has a home page, the Makefile should
include the URL for that page in the <tt class="varname">HOMEPAGE</tt> variable.
The definition of the variable should be placed immediately after the
<tt class="varname">MAINTAINER</tt> variable.
</p>
</div>
<div class="sect1" lang="en">
<div class="titlepage">
<div><div><h2 class="title" style="clear: both">
<a name="id2956667"></a>11.15. How to handle modified distfiles with the 'old' name</h2></div></div>
<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 class="sect1" lang="en">
<div class="titlepage">
<div><div><h2 class="title" style="clear: both">
<a name="id2956764"></a>11.16. What does &quot;Don't know how to make /usr/share/tmac/tmac.andoc&quot; mean?</h2></div></div>
<div></div>
</div>
<p>
When compiling the <a xmlns:html="http://www.w3.org/1999/xhtml" href="ftp://ftp.netbsd.org/pub/NetBSD/packages/pkgsrc/pkgtools/pkg_install/README.html" class="pkgname">pkgtools/pkg_install</a> package, you get the error
from make that it doesn't know how to make
<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.
</p>
<p>
In the case of the <a xmlns:html="http://www.w3.org/1999/xhtml" href="ftp://ftp.netbsd.org/pub/NetBSD/packages/pkgsrc/pkgtools/pkg_install/README.html" class="pkgname">pkgtools/pkg_install</a> package, you can get
away with setting <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">
<div class="titlepage">
<div><div><h2 class="title" style="clear: both">
<a name="id2956809"></a>11.17. How to handle incrementing versions when fixing an existing
package</h2></div></div>
<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>
<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre>DISTNAME= foo-17.42
PKGREVISION= 9</pre></td></tr></table>
<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>
<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre>DISTNAME= foo-17.43</pre></td></tr></table>
</div>
<div class="sect1" lang="en">
<div class="titlepage">
<div><div><h2 class="title" style="clear: both">
<a name="id2956956"></a>11.18. Could not find bsd.own.mk - what's wrong?</h2></div></div>
<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>
<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre><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></td></tr></table>
<p>
<tt class="filename">comp.tgz</tt> is part of every NetBSD release. Get
the one that corresponds to your release (determine via
<b class="command">uname -r</b>).
</p>
</div>
<div class="sect1" lang="en">
<div class="titlepage">
<div><div><h2 class="title" style="clear: both">
<a name="id2957027"></a>11.19. Restricted packages</h2></div></div>
<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="sect1" lang="en">
<div class="titlepage">
<div><div><h2 class="title" style="clear: both">
<a name="id2957213"></a>11.20. Packages using (n)curses</h2></div></div>
<div></div>
</div>
<p>
Some packages need curses functionality that wasn't present in NetBSD's own
curses prior to 1.4Y.
</p>
<p>
If <tt class="filename">../../devel/ncurses/buildlink2.mk</tt> is included in
a package's <tt class="filename">Makefile</tt>,
then a curses library and headers with ncurses functionality are linked
into <tt class="varname">${BUILDLINK_DIR}</tt> at pre-configure time. If
ncurses is actually required, then define <tt class="varname">USE_NCURSES</tt>
in the package's <tt class="filename">Makefile</tt>.
</p>
</div>
<div class="sect1" lang="en">
<div class="titlepage">
<div><div><h2 class="title" style="clear: both">
<a name="id2957255"></a>11.21. Automated security check</h2></div></div>
<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:html="http://www.w3.org/1999/xhtml" href="ftp://ftp.netbsd.org/pub/NetBSD/packages/pkgsrc/security/audit-packages/README.html" class="pkgname">security/audit-packages</a> package. It has two components:
</p>
<div class="orderedlist"><ol type="1">
<li>
<p>
&#8220;<span class="quote">download-vulnerability-list</span>&#8221;, an easy way to download a list of the
security vulnerabilities information. This list is kept up to date by
the NetBSD security officer and the NetBSD packages team, and is
distributed from the NetBSD ftp server:
</p>
<p>
<a href="ftp://ftp.NetBSD.org/pub/NetBSD/packages/distfiles/vulnerabilities" target="_top">ftp://ftp.NetBSD.org/pub/NetBSD/packages/distfiles/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>
<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre>
======================================================================
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.
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></td></tr></table>
<p>
Note to package developers: 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
<tt class="filename">/pub/NetBSD/packages/distfiles/vulnerabilities</tt> on ftp.NetBSD.org.
</p>
</div>
<div class="sect1" lang="en">
<div class="titlepage">
<div><div><h2 class="title" style="clear: both">
<a name="id2957425"></a>11.22. What's the proper way to create an account from a package?</h2></div></div>
<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>
<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre>user:group[:[userid][:[description][:[home][:shell]]]]</pre></td></tr></table>
<p>
where only the user and group are required, the rest being optional. A
simple example is:
</p>
<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre>PKG_GROUPS= foogroup
PKG_USERS= foouser:foogroup</pre></td></tr></table>
<p>
A more complex example is that creates two groups and two users is:
</p>
<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre>PKG_GROUPS= group1 group2:1005
PKG_USERS= first:group1::First\\ User \
second:group2::Second\\ User:/home/second:${SH}</pre></td></tr></table>
<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 Makefile must also include
<tt class="filename">../../mk/bsd.pkg.install.mk</tt> prior to
the inclusion of <tt class="filename">bsd.pkg.mk</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 environment variable
<tt class="varname">PKG_CREATE_USERGROUP</tt> prior to package installation.
</p>
</div>
<div class="sect1" lang="en">
<div class="titlepage">
<div><div><h2 class="title" style="clear: both">
<a name="id2957593"></a>11.23. How to handle compiler bugs</h2></div></div>
<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">doc/HACKS</tt>. See
<tt class="filename">doc/HACKS</tt> for examples.
</p>
</div>
<div class="sect1" lang="en">
<div class="titlepage">
<div><div><h2 class="title" style="clear: both">
<a name="features.info-files"></a>11.24. Packages providing info files</h2></div></div>
<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 info file:
</p>
<div class="itemizedlist"><ul type="disc">
<li>is considered to be installed in the directory
<tt class="filename">${PREFIX}/${INFO_DIR}</tt>,</li>
<li>is registered in the Info directory file
<tt class="filename">${PREFIX}/${INFO_DIR}/dir</tt>,</li>
<li>and must be listed as a filename in the
<tt class="varname">INFO_FILES</tt> variable in the package
Makefile.</li>
</ul></div>
<p>
</p>
<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 for handling
registration of the info files in the Info directory file. The command
&#8220;<span class="quote">install-info</span>&#8221; 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 need 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 Makefile. By default, a minimum version of 3.12
is required. If the system does not provide a &#8220;<span class="quote">makeinfo</span>&#8221;
command or if it does not match the required minimum, a build dependency
on the <a xmlns:html="http://www.w3.org/1999/xhtml" href="ftp://ftp.netbsd.org/pub/NetBSD/packages/pkgsrc/devel/gtexinfo/README.html" class="pkgname">devel/gtexinfo</a> package is added automatically.
</p>
<p>
The installation process of the software provided by the package must not
use &#8220;<span class="quote">install-info</span>&#8221;, as the registration of info files
is the task of the package INSTALL sript, and it must use
the right &#8220;<span class="quote">makeinfo</span>&#8221;.
</p>
<p>
If the package use buildlink2 framework no special action should be needed
to achieve this goal.
</p>
<p>
If the package does not use the buildlink2 framework patch files are likely
to be needed so the build and installation process of the software
picks up the <span class="emphasis"><em>possibly dummy</em></span> values of
<tt class="varname">INSTALL_INFO</tt> and <tt class="varname">MAKEINFO</tt>
variables.
</p>
<div class="note" style="margin-left: 0.5in; margin-right: 0.5in;">
<h3 class="title">Note</h3>
Temporarily, the variable <tt class="varname">USE_NEW_TEXINFO</tt> must be
defined in the package Makefile. Previously, info files,
&#8220;<span class="quote">install-info</span>&#8221; and &#8220;<span class="quote">makeinfo</span>&#8221;
were handled somewhat differently and the two ways will coexist for
a short period of time until all older packages are updated.
</div>
</div>
<div class="sect1" lang="en">
<div class="titlepage">
<div><div><h2 class="title" style="clear: both">
<a name="id2957793"></a>11.25. Packages whose distfiles aren't available for plain downloading</h2></div></div>
<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 <b class="command">make fetch</b> 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:html="http://www.w3.org/1999/xhtml" href="ftp://ftp.netbsd.org/pub/NetBSD/packages/pkgsrc/graphics/ns-cult3d/README.html" class="pkgname">graphics/ns-cult3d</a> is an example of this usage.
</p>
<p>
If the download can't be automated, because the user must submit personal
information to apply for a password, or must pay for the source, or whatever,
you can set <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:html="http://www.w3.org/1999/xhtml" href="ftp://ftp.netbsd.org/pub/NetBSD/packages/pkgsrc/audio/realplayer/README.html" class="pkgname">audio/realplayer</a>,
<a xmlns:html="http://www.w3.org/1999/xhtml" href="ftp://ftp.netbsd.org/pub/NetBSD/packages/pkgsrc/cad/simian/README.html" class="pkgname">cad/simian</a>, <a xmlns:html="http://www.w3.org/1999/xhtml" href="ftp://ftp.netbsd.org/pub/NetBSD/packages/pkgsrc/devel/ipv6socket/README.html" class="pkgname">devel/ipv6socket</a>,
<a xmlns:html="http://www.w3.org/1999/xhtml" href="ftp://ftp.netbsd.org/pub/NetBSD/packages/pkgsrc/emulators/vmare-module/README.html" class="pkgname">emulators/vmare-module</a>,
<a xmlns:html="http://www.w3.org/1999/xhtml" href="ftp://ftp.netbsd.org/pub/NetBSD/packages/pkgsrc/fonts/acroread-jpnfont/README.html" class="pkgname">fonts/acroread-jpnfont</a>,
<a xmlns:html="http://www.w3.org/1999/xhtml" href="ftp://ftp.netbsd.org/pub/NetBSD/packages/pkgsrc/sysutils/storage-manager/README.html" class="pkgname">sysutils/storage-manager</a>,
<a xmlns:html="http://www.w3.org/1999/xhtml" href="ftp://ftp.netbsd.org/pub/NetBSD/packages/pkgsrc/www/ap-aolserver/README.html" class="pkgname">www/ap-aolserver</a>, <a xmlns:html="http://www.w3.org/1999/xhtml" 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="sect1" lang="en">
<div class="titlepage">
<div><div><h2 class="title" style="clear: both">
<a name="id2957953"></a>11.26. Configuration files handling and placement</h2></div></div>
<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
include <tt class="filename">../../mk/bsd.pkg.install.mk</tt> prior to the
inclusion of <tt class="filename">bsd.pkg.mk</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>
<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre>EGDIR= ${PREFIX}/share/doc/mutt/samples
CONF_FILES= ${EGDIR}/Muttrc ${PKG_SYSCONFDIR}/Muttrc</pre></td></tr></table>
<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">
<div class="titlepage">
<div><div><h2 class="title" style="clear: both">
<a name="id2958470"></a>11.27. Packages providing login shells</h2></div></div>
<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> also must include
<tt class="filename">../../mk/bsd.pkg.install.mk</tt> prior to the inclusion of
<tt class="filename">bsd.pkg.mk</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>
<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre>PKG_SHELL= ${PREFIX}/bin/zsh
.include &quot;../../mk/bsd.pkg.install.mk&quot;</pre></td></tr></table>
<p>
The shell is registered into <tt class="filename">/etc/shells</tt> file automatically in the
post-install target by the <tt class="filename">INSTALL</tt> script generated
by <tt class="filename">bsd.pkg.install.mk</tt> and removed in the deinstall
target by the <tt class="filename">DEINSTALL</tt> script.
</p>
</div>
<div class="sect1" lang="en">
<div class="titlepage">
<div><div><h2 class="title" style="clear: both">
<a name="id2958558"></a>11.28. Packages providing locale catalogues</h2></div></div>
<div></div>
</div>
<p>
If the package provides its own locale catalogues, the variable
<tt class="varname">USE_PKGLOCALEDIR</tt> should be defined. It will ensure
that the package's <tt class="filename">Makefile</tt> template files are fixed
and point to the correct locale directories
(which may vary, depending on OS), if necessary. See <a href="#plist.misc" title="6.1. Miscellaneous">Section 6.1, &#8220;Miscellaneous&#8221;</a> for details about <tt class="varname">PKGLOCALEDIR</tt>.
This functionality is buildlink2-only.
</p>
</div>
<div class="sect1" lang="en">
<div class="titlepage">
<div><div><h2 class="title" style="clear: both">
<a name="id2958592"></a>11.29. Using 'sudo' with pkgsrc</h2></div></div>
<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:html="http://www.w3.org/1999/xhtml" href="ftp://ftp.netbsd.org/pub/NetBSD/packages/pkgsrc/security/sudo/README.html" class="pkgname">security/sudo</a>) and then put the following
into your <tt class="filename">/etc/mk.conf</tt>:
</p>
<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre>SU_CMD=/usr/pkg/bin/sudo /bin/sh -c</pre></td></tr></table>
</div>
<div class="sect1" lang="en">
<div class="titlepage">
<div><div><h2 class="title" style="clear: both">
<a name="id2958621"></a>11.30. Packages containing perl scripts</h2></div></div>
<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="sect1" lang="en">
<div class="titlepage">
<div><div><h2 class="title" style="clear: both">
<a name="id2958648"></a>11.31. Packages that cannot or should not be built</h2></div></div>
<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>
<div class="chapter" lang="en">
<div class="titlepage">
<div><div><h2 class="title">
<a name="submit"></a>Chapter 12. Submitting and Committing</h2></div></div>
<div></div>
</div>
<div class="toc">
<p><b>Table of Contents</b></p>
<dl>
<dt>12.1. <a href="#id2960258">Submitting your packages</a>
</dt>
<dt>12.2. <a href="#id2961824">Committing: Importing a package into CVS</a>
</dt>
<dt>12.3. <a href="#id2962087">Updating a Package to a Newer Version</a>
</dt>
<dt>12.4. <a href="#id2962208">Moving a Package in pkgsrc</a>
</dt>
</dl>
</div>
<div class="sect1" lang="en">
<div class="titlepage">
<div><div><h2 class="title" style="clear: both">
<a name="id2960258"></a>12.1. Submitting your packages</h2></div></div>
<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 NetBSD 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 10. Debugging">Chapter 10, <i>Debugging</i></a> and the rest of this document. Next,
generate a gzipped
tar-file of all the files needed for the package, preferably with all
files in a single directory. Place this tar-file to a place where the
package maintainers can fetch it using FTP or HTTP (WWW). Finally,
<b class="command">send-pr</b> 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 <tt class="varname">COMMENT</tt>
variable are OK) and the URL of your tar-file.
</p>
<p>
You will be notified if your PR has been addressed so you can remove
the tar-file.
</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>
</li>
</ul></div>
</div>
<div class="sect1" lang="en">
<div class="titlepage">
<div><div><h2 class="title" style="clear: both">
<a name="id2961824"></a>12.2. Committing: Importing a package into CVS</h2></div></div>
<div></div>
</div>
<p>
This section is only of interest for NetBSD developers with write
access to the NetBSD pkgsrc repository. Please remember that cvs
imports files relative to the cwd, and that the pathname that you
give the <b class="command">cvs import</b> 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>
<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre><tt class="prompt">%</tt> <b class="userinput"><tt>cd
.../pkgsrc/&lt;category&gt;/&lt;pkgname&gt;</tt></b>
<tt class="prompt">%</tt> <b class="userinput"><tt>cvs import pkgsrc/&lt;category&gt;/&lt;pkgname&gt; TNF pkgsrc-base</tt></b></pre></td></tr></table>
<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.
</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">
<div class="titlepage">
<div><div><h2 class="title" style="clear: both">
<a name="id2962087"></a>12.3. Updating a Package to a Newer Version</h2></div></div>
<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">
<div class="titlepage">
<div><div><h2 class="title" style="clear: both">
<a name="id2962208"></a>12.4. Moving a Package in pkgsrc</h2></div></div>
<div></div>
</div>
<div class="orderedlist"><ol type="1">
<li>Make a copy of the directory somewhere else.</li>
<li>
<p>Remove all CVS dirs.</p>
<p>
Alternatively to the first two steps you can also do:
</p>
<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre><tt class="prompt">%</tt> <b class="userinput"><tt>cvs -d user@cvs.NetBSD.org:/cvsroot export -D today pkgsrc/category/package</tt></b></pre></td></tr></table>
<p>
and use that for further work.
</p>
</li>
<li>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;.
</li>
<li>
<b class="command">cvs import</b> the modified package in the new
place.</li>
<li>
<p>Check if any package depends on it:
</p>
<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre><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></td></tr></table>
<p>
</p>
</li>
<li>Fix paths in packages from step 5 to point to new location.</li>
<li>
<b class="command">cvs rm (-f)</b> the package at the old location.</li>
<li>Remove from <tt class="filename">oldcategory/Makefile</tt>.</li>
<li>Add to <tt class="filename">newcategory/Makefile</tt>.</li>
<li>
<p>Commit the changed and removed files:</p>
<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre><tt class="prompt">%</tt> <b class="userinput"><tt>cvs commit oldcategory/package oldcategory/Makefile newcategory/Makefile</tt></b></pre></td></tr></table>
<p>
(and any packages from step 5, of course).
</p>
</li>
</ol></div>
</div>
</div>
<div class="chapter" lang="en">
<div class="titlepage">
<div><div><h2 class="title">
<a name="examples"></a>Chapter 13. A simple example of a package: bison</h2></div></div>
<div></div>
</div>
<div class="toc">
<p><b>Table of Contents</b></p>
<dl>
<dt>13.1. <a href="#id2961656">files</a>
</dt>
<dt>13.2. <a href="#id2963176">Steps for building, installing, packaging</a>
</dt>
</dl>
</div>
<p>
I 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
<b class="command">bison</b> when Berkeley <b class="command">yacc</b> is already
present in the tree is beyond me, but it's useful for the purposes of
this exercise.
</p>
<div class="sect1" lang="en">
<div class="titlepage">
<div><div><h2 class="title" style="clear: both">
<a name="id2961656"></a>13.1. files</h2></div></div>
<div></div>
</div>
<div class="sect2" lang="en">
<div class="titlepage">
<div><div><h3 class="title">
<a name="id2961662"></a>13.1.1. Makefile</h3></div></div>
<div></div>
</div>
<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre># $NetBSD: pkgsrc.html,v 1.2 2003/06/23 07:49:44 grant Exp $
#
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 &quot;../../mk/bsd.pkg.mk&quot;</pre></td></tr></table>
</div>
<div class="sect2" lang="en">
<div class="titlepage">
<div><div><h3 class="title">
<a name="id2961676"></a>13.1.2. DESCR</h3></div></div>
<div></div>
</div>
<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre>GNU version of yacc. Can make re-entrant parsers, and numerous other
improvements. Why you would want this when Berkeley yacc(1) is part
of the NetBSD source tree is beyond me.</pre></td></tr></table>
</div>
<div class="sect2" lang="en">
<div class="titlepage">
<div><div><h3 class="title">
<a name="id2961689"></a>13.1.3. PLIST</h3></div></div>
<div></div>
</div>
<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre>@comment $NetBSD: pkgsrc.html,v 1.2 2003/06/23 07:49:44 grant Exp $
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></td></tr></table>
</div>
<div class="sect2" lang="en">
<div class="titlepage">
<div><div><h3 class="title">
<a name="id2961703"></a>13.1.4. Checking a package with <b class="command">pkglint</b></h3></div></div>
<div></div>
</div>
<p>
The NetBSD package system comes with <a xmlns:html="http://www.w3.org/1999/xhtml" href="ftp://ftp.netbsd.org/pub/NetBSD/packages/pkgsrc/pkgtools/pkglint/README.html" class="pkgname">pkgtools/pkglint</a>
which helps to check the contents of these
files. After installation it is quite easy to use, just change to the
directory of the package you wish to examine and execute
<b class="command">pkglint</b>:
</p>
<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre><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></td></tr></table>
<p>
Depending on the supplied command line arguments (see pkglint(1)) more
verbose checks will be performed. Use e.g. <b class="command">pkglint
-v</b> for a very verbose check.
</p>
</div>
</div>
<div class="sect1" lang="en">
<div class="titlepage">
<div><div><h2 class="title" style="clear: both">
<a name="id2963176"></a>13.2. Steps for building, installing, packaging</h2></div></div>
<div></div>
</div>
<p>
Create the directory where the package lives, plus any auxiliary directories:
</p>
<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre><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></td></tr></table>
<p>
Create <tt class="filename">Makefile</tt>, <tt class="filename">DESCR</tt> and
<tt class="filename">PLIST</tt> (see <a href="#components" title="Chapter 5. Package components - files, directories and contents">Chapter 5, <i>Package components - files, directories and contents</i></a>)
then continue with fetching the distfile:
</p>
<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre><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></td></tr></table>
<p>
Generate the checksum of the distfile into <tt class="filename">distinfo</tt>:
</p>
<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre><tt class="prompt">#</tt> <b class="userinput"><tt>make makesum</tt></b></pre></td></tr></table>
<p>
Now compile:
</p>
<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre><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=\&quot;/usr/pkg/share/bison.simple\&quot; -DXPFILE1=\&quot;/usr/pkg/share/bison.hairy\&quot; -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 &quot;/^#line/ s|bison|/usr/pkg/share/bison|&quot; &lt; ./bison.simple &gt; bison.s1</pre></td></tr></table>
<p>
Everything seems OK, so install the files:
</p>
<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre><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></td></tr></table>
<p>
You can now use bison, and also - if you decide so - remove it with
<b class="command">pkg_delete bison</b>. Should you decide that you want a
binary package, do this now:
</p>
<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre><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></td></tr></table>
<p>
Now that you don't need the source and object files any more, clean up:
</p>
<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre><tt class="prompt">#</tt> <b class="userinput"><tt>make clean</tt></b>
===&gt; Cleaning for bison-1.25</pre></td></tr></table>
</div>
</div>
</div>
<div class="appendix" lang="en">
<div class="titlepage">
<div><div><h2 class="title">
<a name="logs"></a>Appendix A. Build logs</h2></div></div>
<div></div>
</div>
<div class="toc">
<p><b>Table of Contents</b></p>
<dl>
<dt>A.1. <a href="#logs.building">Building top</a>
</dt>
<dt>A.2. <a href="#logs.package">Packaging top</a>
</dt>
</dl>
</div>
<div class="sect1" lang="en">
<div class="titlepage">
<div><div><h2 class="title" style="clear: both">
<a name="logs.building"></a>A.1. Building top</h2></div></div>
<div></div>
</div>
<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre><tt class="prompt">#</tt> <b class="userinput"><tt>make</tt></b>
&gt;&gt; top-3.5beta5.tar.gz doesn't seem to exist on this system.
&gt;&gt; Attempting to fetch from ftp://ftp.groupsys.com/pub/top/.
Requesting ftp://ftp.groupsys.com/pub/top/top-3.5beta5.tar.gz (via ftp://orpheus.amdahl.com:80/)
Successfully retrieved file.
&gt;&gt; Checksum OK for top-3.5beta5.tar.gz.
===&gt; Extracting for top-3.5beta5
===&gt; Patching for top-3.5beta5
===&gt; Applying NetBSD patches for top-3.5beta5
===&gt; Configuring for top-3.5beta5
/bin/cp /u/pkgsrc/sysutils/top/files/defaults /u/pkgsrc/sysutils/top/work/top-3.5beta5/.defaults
chmod a-x /u/pkgsrc/sysutils/top/work/top-3.5beta5/install
Reading configuration from last time...
Using these settings:
Bourne Shell /bin/sh
C compiler cc
Compiler options -DHAVE_GETOPT -O
Awk command awk
Install command /usr/bin/install
Module netbsd13
LoadMax 5.0
Default TOPN -1
Nominal TOPN 18
Default Delay 2
Random passwd access yes
Table Size 47
Owner root
Group Owner kmem
Mode 2755
bin directory $(PREFIX)/bin
man directory $(PREFIX)/man/man1
man extension 1
man style man
Building Makefile...
Building top.local.h...
Building top.1...
Doing a &quot;make clean&quot;.
rm -f *.o top core core.* sigdesc.h
To create the executable, type &quot;make&quot;.
To install the executable, type &quot;make install&quot;.
===&gt; Building for top-3.5beta5
cc -DHAVE_GETOPT -DORDER -DHAVE_GETOPT -O -c top.c
awk -f sigconv.awk /usr/include/sys/signal.h &gt;sigdesc.h
cc -DHAVE_GETOPT -DORDER -DHAVE_GETOPT -O -c commands.c
cc -DHAVE_GETOPT -DORDER -DHAVE_GETOPT -O -c display.c
cc -DHAVE_GETOPT -DORDER -DHAVE_GETOPT -O -c screen.c
cc -DHAVE_GETOPT -DORDER -DHAVE_GETOPT -O -c username.c
cc -DHAVE_GETOPT -DORDER -DHAVE_GETOPT -O -c utils.c
utils.c: In function `errmsg':
utils.c:348: warning: return discards `const' from pointer target type
cc -DHAVE_GETOPT -DORDER -DHAVE_GETOPT -O -c version.c
cc -DHAVE_GETOPT -DORDER -DHAVE_GETOPT -O -c getopt.c
cc &quot;-DOSREV=12G&quot; -DHAVE_GETOPT -DORDER -DHAVE_GETOPT -O -c machine.c
rm -f top
cc -o top top.o commands.o display.o screen.o username.o utils.o version.o getopt.o machine.o -ltermcap -lm -lkvm
<tt class="prompt">#</tt>
<tt class="prompt">#</tt> <b class="userinput"><tt>make install</tt></b>
&gt;&gt; Checksum OK for top-3.5beta5.tar.gz.
===&gt; Installing for top-3.5beta5
/usr/bin/install -o root -m 2755 -g kmem top /usr/pkg/bin
/usr/bin/install top.1 /usr/pkg/man/man1/top.1
strip /usr/pkg/bin/top
===&gt; Registering installation for top-3.5beta5</pre></td></tr></table>
</div>
<div class="sect1" lang="en">
<div class="titlepage">
<div><div><h2 class="title" style="clear: both">
<a name="logs.package"></a>A.2. Packaging top</h2></div></div>
<div></div>
</div>
<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre><tt class="prompt">#</tt> <b class="userinput"><tt>make package</tt></b>
&gt;&gt; Checksum OK for top-3.5beta5.tar.gz.
===&gt; Building package for top-3.5beta5
Creating package top-3.5beta5.tgz
Registering depends:.
Creating gzip'd tar ball in '/u/pkgsrc/sysutils/top/top-3.5beta5.tgz'</pre></td></tr></table>
</div>
</div>
<div class="appendix" lang="en">
<div class="titlepage">
<div><div><h2 class="title">
<a name="ftp-layout"></a>Appendix B. Layout of the FTP server's package archive</h2></div></div>
<div></div>
</div>
<p>
Layout for precompiled binary packages on ftp.NetBSD.org:
</p>
<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre>
/pub/NetBSD/packages/
README
distfiles/
pkgsrc -&gt; /pub/NetBSD/NetBSD-current/pkgsrc
1.6/
i386/
All/
archivers/
foo -&gt; ../All/foo
...
m68k/
All/
archivers/
foo -&gt; ../All/foo
...
amiga -&gt; m68k
atari -&gt; m68k
...
</pre></td></tr></table>
</div>
</div></body>
</html>
Reference in a new issue View git blame Copy permalink