diff options
| author | wiz <wiz@pkgsrc.org> | 2006-09-10 19:55:23 +0000 |
|---|---|---|
| committer | wiz <wiz@pkgsrc.org> | 2006-09-10 19:55:23 +0000 |
| commit | 550ac289b54bde3fca09bb3000ab050cbf3f5385 (patch) | |
| tree | eb2d5ad60b48bb8be0486a539ad50e96b3efdb4e /doc | |
| parent | 06cbeb626e8d820a1da699e80332d2bf9e832d07 (diff) | |
| download | pkgsrc-550ac289b54bde3fca09bb3000ab050cbf3f5385.tar.gz | |
regen
Diffstat (limited to 'doc')
| -rw-r--r-- | doc/pkgsrc.html | 5360 | ||||
| -rw-r--r-- | doc/pkgsrc.txt | 1044 |
2 files changed, 3357 insertions, 3047 deletions
diff --git a/doc/pkgsrc.html b/doc/pkgsrc.html index 80fb946f234..59cb98e1c22 100644 --- a/doc/pkgsrc.html +++ b/doc/pkgsrc.html @@ -307,34 +307,44 @@ <dt><span class="sect2"><a href="#using-libtool">17.3.2. Using libtool on GNU packages that already support libtool</a></span></dt> <dt><span class="sect2"><a href="#autoconf-automake">17.3.3. GNU Autoconf/Automake</a></span></dt> </dl></dd> -<dt><span class="sect1"><a href="#fixes.build">17.4. Fixing problems in the <span class="emphasis"><em>build</em></span> phase</a></span></dt> +<dt><span class="sect1"><a href="#programming-languages">17.4. Programming languages</a></span></dt> <dd><dl> -<dt><span class="sect2"><a href="#fixes.build.cpp">17.4.1. Compiling C and C++ code conditionally</a></span></dt> -<dt><span class="sect2"><a href="#compiler-bugs">17.4.2. How to handle compiler bugs</a></span></dt> -<dt><span class="sect2"><a href="#undefined-reference">17.4.3. Undefined reference to “<span class="quote">...</span>”</a></span></dt> +<dt><span class="sect2"><a href="#basic-programming-languages">17.4.1. C, C++, and Fortran</a></span></dt> +<dt><span class="sect2"><a href="#java-programming-language">17.4.2. Java</a></span></dt> +<dt><span class="sect2"><a href="#perl-scripts">17.4.3. Packages containing perl scripts</a></span></dt> +<dt><span class="sect2"><a href="#other-programming-languages">17.4.4. Other programming languages</a></span></dt> </dl></dd> -<dt><span class="sect1"><a href="#fixes.install">17.5. Fixing problems in the <span class="emphasis"><em>install</em></span> phase</a></span></dt> +<dt><span class="sect1"><a href="#fixes.build">17.5. Fixing problems in the <span class="emphasis"><em>build</em></span> phase</a></span></dt> <dd><dl> -<dt><span class="sect2"><a href="#install-scripts">17.5.1. Creating needed directories</a></span></dt> -<dt><span class="sect2"><a href="#where-to-install-documentation">17.5.2. Where to install documentation</a></span></dt> -<dt><span class="sect2"><a href="#installing-score-files">17.5.3. Installing score files</a></span></dt> -<dt><span class="sect2"><a href="#perl-scripts">17.5.4. Packages containing perl scripts</a></span></dt> -<dt><span class="sect2"><a href="#hardcoded-paths">17.5.5. Packages with hardcoded paths to other interpreters</a></span></dt> -<dt><span class="sect2"><a href="#perl-modules">17.5.6. Packages installing perl modules</a></span></dt> -<dt><span class="sect2"><a href="#faq.info-files">17.5.7. Packages installing info files</a></span></dt> -<dt><span class="sect2"><a href="#manpages">17.5.8. Packages installing man pages</a></span></dt> -<dt><span class="sect2"><a href="#gconf2-data-files">17.5.9. Packages installing GConf2 data files</a></span></dt> -<dt><span class="sect2"><a href="#scrollkeeper-data-files">17.5.10. Packages installing scrollkeeper data files</a></span></dt> -<dt><span class="sect2"><a href="#x11-fonts">17.5.11. Packages installing X11 fonts</a></span></dt> -<dt><span class="sect2"><a href="#gtk2-modules">17.5.12. Packages installing GTK2 modules</a></span></dt> -<dt><span class="sect2"><a href="#sgml-xml-data">17.5.13. Packages installing SGML or XML data</a></span></dt> -<dt><span class="sect2"><a href="#mime-database">17.5.14. Packages installing extensions to the MIME database</a></span></dt> -<dt><span class="sect2"><a href="#intltool">17.5.15. Packages using intltool</a></span></dt> -<dt><span class="sect2"><a href="#startup-scripts">17.5.16. Packages installing startup scripts</a></span></dt> -<dt><span class="sect2"><a href="#tex-packages">17.5.17. Packages installing TeX modules</a></span></dt> -<dt><span class="sect2"><a href="#hicolor-theme">17.5.18. Packages installing hicolor theme icons</a></span></dt> -<dt><span class="sect2"><a href="#desktop-files">17.5.19. Packages installing desktop files</a></span></dt> +<dt><span class="sect2"><a href="#fixes.build.cpp">17.5.1. Compiling C and C++ code conditionally</a></span></dt> +<dt><span class="sect2"><a href="#compiler-bugs">17.5.2. How to handle compiler bugs</a></span></dt> +<dt><span class="sect2"><a href="#undefined-reference">17.5.3. Undefined reference to “<span class="quote">...</span>”</a></span></dt> +<dt><span class="sect2"><a href="#out-of-memory">17.5.4. Running out of memory</a></span></dt> </dl></dd> +<dt><span class="sect1"><a href="#fixes.install">17.6. Fixing problems in the <span class="emphasis"><em>install</em></span> phase</a></span></dt> +<dd><dl> +<dt><span class="sect2"><a href="#install-scripts">17.6.1. Creating needed directories</a></span></dt> +<dt><span class="sect2"><a href="#where-to-install-documentation">17.6.2. Where to install documentation</a></span></dt> +<dt><span class="sect2"><a href="#installing-score-files">17.6.3. Installing score files</a></span></dt> +<dt><span class="sect2"><a href="#hardcoded-paths">17.6.4. Packages with hardcoded paths to other interpreters</a></span></dt> +<dt><span class="sect2"><a href="#perl-modules">17.6.5. Packages installing perl modules</a></span></dt> +<dt><span class="sect2"><a href="#faq.info-files">17.6.6. Packages installing info files</a></span></dt> +<dt><span class="sect2"><a href="#manpages">17.6.7. Packages installing man pages</a></span></dt> +<dt><span class="sect2"><a href="#gconf2-data-files">17.6.8. Packages installing GConf2 data files</a></span></dt> +<dt><span class="sect2"><a href="#scrollkeeper-data-files">17.6.9. Packages installing scrollkeeper data files</a></span></dt> +<dt><span class="sect2"><a href="#x11-fonts">17.6.10. Packages installing X11 fonts</a></span></dt> +<dt><span class="sect2"><a href="#gtk2-modules">17.6.11. Packages installing GTK2 modules</a></span></dt> +<dt><span class="sect2"><a href="#sgml-xml-data">17.6.12. Packages installing SGML or XML data</a></span></dt> +<dt><span class="sect2"><a href="#mime-database">17.6.13. Packages installing extensions to the MIME database</a></span></dt> +<dt><span class="sect2"><a href="#intltool">17.6.14. Packages using intltool</a></span></dt> +<dt><span class="sect2"><a href="#startup-scripts">17.6.15. Packages installing startup scripts</a></span></dt> +<dt><span class="sect2"><a href="#tex-packages">17.6.16. Packages installing TeX modules</a></span></dt> +<dt><span class="sect2"><a href="#emulation-packages">17.6.17. Packages supporting running binaries in + emulation</a></span></dt> +<dt><span class="sect2"><a href="#hicolor-theme">17.6.18. Packages installing hicolor theme icons</a></span></dt> +<dt><span class="sect2"><a href="#desktop-files">17.6.19. Packages installing desktop files</a></span></dt> +</dl></dd> +<dt><span class="sect1"><a href="#punting">17.7. Marking packages as having problems</a></span></dt> </dl></dd> <dt><span class="chapter"><a href="#debug">18. Debugging</a></span></dt> <dt><span class="chapter"><a href="#submit">19. Submitting and Committing</a></span></dt> @@ -636,13 +646,11 @@ minutes!</p> pkgsrc. Packages are traditionally stored under <code class="filename">/usr/pkgsrc</code>.</p></dd> <dt><span class="term">The NetBSD package system</span></dt> -<dd><p> - This is the former name of “<span class="quote">pkgsrc</span>”. It is - part of the NetBSD operating system and can be bootstrapped to - run on non-NetBSD operating systems as well. It handles - building (compiling), installing, and removing of - packages. - </p></dd> +<dd><p>This is the former name of “<span class="quote">pkgsrc</span>”. It + is part of the NetBSD operating system and can be bootstrapped + to run on non-NetBSD operating systems as well. It handles + building (compiling), installing, and removing of + packages.</p></dd> <dt><span class="term">Distfile</span></dt> <dd><p>This term describes the file or files that are provided by the author of the piece of software to @@ -1226,27 +1234,28 @@ file and inspect the contents before extracting it. <pre class="screen"> <code class="prompt">#</code> <strong class="userinput"><code>env CVS_RSH=ssh cvs -d anoncvs@anoncvs.NetBSD.org:/cvsroot checkout pkgsrc</code></strong> <code class="prompt">#</code> <strong class="userinput"><code>cd pkgsrc/bootstrap</code></strong> -<code class="prompt">#</code> <strong class="userinput"><code>./bootstrap</code></strong></pre> +<code class="prompt">#</code> <strong class="userinput"><code>./bootstrap</code></strong> + </pre> <p>See <a href="#getting" title="Chapter 2. Where to get pkgsrc and how to keep it up-to-date">Chapter 2, <i>Where to get pkgsrc and how to keep it up-to-date</i></a> for other ways to get - pkgsrc before bootstrapping. The given - <span><strong class="command">bootstrap</strong></span> command will use the defaults of - <code class="filename">/usr/pkg</code> for the - <span class="emphasis"><em>prefix</em></span> where programs will be installed in, - and <code class="filename">/var/db/pkg</code> for the package database - directory where pkgsrc will do its internal bookkeeping. - However, these can also be set using command-line - arguments.</p> + pkgsrc before bootstrapping. The given + <span><strong class="command">bootstrap</strong></span> command will use the defaults of + <code class="filename">/usr/pkg</code> for the + <span class="emphasis"><em>prefix</em></span> where programs will be installed in, + and <code class="filename">/var/db/pkg</code> for the package database + directory where pkgsrc will do its internal bookkeeping. + However, these can also be set using command-line + arguments.</p> <p>Binary packages for the pkgsrc tools and an initial set of packages is - available for supported platforms. An up-to-date list of these can be - found on <a href="http://www.pkgsrc.org/" target="_top">www.pkgsrc.org</a>. - Note that this only works for privileged builds that install - into <code class="filename">/usr/pkg</code>.</p> + available for supported platforms. An up-to-date list of these can be + found on <a href="http://www.pkgsrc.org/" target="_top">www.pkgsrc.org</a>. + Note that this only works for privileged builds that install + into <code class="filename">/usr/pkg</code>.</p> <div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"> <h3 class="title">Note</h3> <p>The bootstrap installs a <span><strong class="command">bmake</strong></span> tool. - Use this <span><strong class="command">bmake</strong></span> when building via pkgsrc. - For examples in this guide, use <span><strong class="command">bmake</strong></span> - instead of “<span class="quote">make</span>”.</p> + Use this <span><strong class="command">bmake</strong></span> when building via pkgsrc. + For examples in this guide, use <span><strong class="command">bmake</strong></span> + instead of “<span class="quote">make</span>”.</p> </div> </div> <div class="sect1" lang="en"> @@ -1261,14 +1270,14 @@ file and inspect the contents before extracting it. image</a>, or a <a href="#platform.osx-ufs" title="3.3.1.2. Using a UFS partition">UFS partition</a>.</p> <p>Before you start, you will need to download and install the Mac OS X Developer - Tools from Apple's Developer Connection. See <a href="http://developer.apple.com/macosx/" target="_top">http://developer.apple.com/macosx/</a> - for details. Also, make sure you install X11 for Mac OS X and the X11 SDK - from <a href="http://www.apple.com/macosx/x11/download/" target="_top">http://www.apple.com/macosx/x11/download/</a> - if you intend to build packages that use the X11 Window System.</p> + Tools from Apple's Developer Connection. See <a href="http://developer.apple.com/macosx/" target="_top">http://developer.apple.com/macosx/</a> + for details. Also, make sure you install X11 for Mac OS X and the X11 SDK + from <a href="http://www.apple.com/macosx/x11/download/" target="_top">http://www.apple.com/macosx/x11/download/</a> + if you intend to build packages that use the X11 Window System.</p> <p>If you already have a UFS partition, or have a spare partition - that you can format as UFS, it is recommended to use that instead of - the disk image. It'll be somewhat faster and will mount automatically - at boot time, where you must manually mount a disk image.</p> + that you can format as UFS, it is recommended to use that instead of + the disk image. It'll be somewhat faster and will mount automatically + at boot time, where you must manually mount a disk image.</p> <div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"> <h3 class="title">Note</h3> <p>You cannot use an ordinary HFS+ file system for pkgsrc, because pkgsrc currently @@ -1293,80 +1302,81 @@ file and inspect the contents before extracting it. <div class="titlepage"><div><div><h4 class="title"> <a name="platform.osx-ufs"></a>3.3.1.2. Using a UFS partition</h4></div></div></div> <p>By default, <code class="filename">/usr</code> will be on your root file - system, normally HFS+. It is possible to use the default - <span class="emphasis"><em>prefix</em></span> of <code class="filename">/usr/pkg</code> - by symlinking <code class="filename">/usr/pkg</code> to a directory on a UFS - file system. Obviously, another symlink is required if you want to - place the package database directory outside the - <span class="emphasis"><em>prefix</em></span>. e.g.</p> + system, normally HFS+. It is possible to use the default + <span class="emphasis"><em>prefix</em></span> of <code class="filename">/usr/pkg</code> + by symlinking <code class="filename">/usr/pkg</code> to a directory on a UFS + file system. Obviously, another symlink is required if you want to + place the package database directory outside the + <span class="emphasis"><em>prefix</em></span>. e.g.</p> <pre class="screen"><code class="prompt">#</code> <strong class="userinput"><code>./bootstrap --pkgdbdir /usr/pkg/pkgdb</code></strong></pre> <p>If you created your partitions at the time of installing Mac OS X - and formatted the target partition as UFS, it should automatically - mount on <code class="filename">/Volumes/<volume name></code> when the - machine boots. If you are (re)formatting a partition as UFS, you need - to ensure that the partition map correctly reflects - “<span class="quote">Apple_UFS</span>” and not “<span class="quote">Apple_HFS</span>”.</p> + and formatted the target partition as UFS, it should automatically + mount on <code class="filename">/Volumes/<volume name></code> when the + machine boots. If you are (re)formatting a partition as UFS, you need + to ensure that the partition map correctly reflects + “<span class="quote">Apple_UFS</span>” and not “<span class="quote">Apple_HFS</span>”.</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> + 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> + 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> + 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> + 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="freebsd"></a>3.3.2. FreeBSD</h3></div></div></div> -<p> - FreeBSD 4.7 and 5.0 have been tested and are supported, other versions - may work.</p> +<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> + with the FreeBSD userland tools. There are several steps:</p> <div class="orderedlist"><ol type="1"> <li><p>FreeBSD stores its ports pkg database in - <code class="filename">/var/db/pkg</code>. It is therefore - recommended that you choose a different location (e.g. - <code class="filename">/usr/pkgdb</code>) by - using the --pkgdbdir option to the bootstrap script.</p></li> + <code class="filename">/var/db/pkg</code>. It is therefore + recommended that you choose a different location (e.g. + <code class="filename">/usr/pkgdb</code>) by + using the --pkgdbdir option to the bootstrap script.</p></li> <li> <p>If you do not intend to use the FreeBSD ports tools, it's probably a - good idea to move them out of the way to avoid confusion, e.g.</p> -<pre class="screen"><code class="prompt">#</code> <strong class="userinput"><code>cd /usr/sbin</code></strong> + good idea to move them out of the way to avoid confusion, e.g.</p> +<pre class="screen"> +<code class="prompt">#</code> <strong class="userinput"><code>cd /usr/sbin</code></strong> <code class="prompt">#</code> <strong class="userinput"><code>mv pkg_add pkg_add.orig</code></strong> <code class="prompt">#</code> <strong class="userinput"><code>mv pkg_create pkg_create.orig</code></strong> <code class="prompt">#</code> <strong class="userinput"><code>mv pkg_delete pkg_delete.orig</code></strong> -<code class="prompt">#</code> <strong class="userinput"><code>mv pkg_info pkg_info.orig</code></strong></pre> +<code class="prompt">#</code> <strong class="userinput"><code>mv pkg_info pkg_info.orig</code></strong> + </pre> </li> <li><p>An example <code class="filename">/etc/mk.conf</code> file will be placed in - <code class="filename">/etc/mk.conf.example</code> file - when you use the bootstrap script.</p></li> + <code class="filename">/etc/mk.conf.example</code> file + when you use the bootstrap script.</p></li> </ol></div> </div> <div class="sect2" lang="en"> <div class="titlepage"><div><div><h3 class="title"> <a name="interix"></a>3.3.3. Interix</h3></div></div></div> <p>Interix is a POSIX-compatible subsystem for the Windows NT kernel, - providing a Unix-like environment with a tighter kernel integration than - available with Cygwin. It is part of the Windows Services for Unix - package, available for free for any licensed copy of Windows 2000, XP - (not including XP Home), or 2003. SFU can be downloaded from <a href="http://www.microsoft.com/windows/sfu/" target="_top">http://www.microsoft.com/windows/sfu/</a>.</p> + providing a Unix-like environment with a tighter kernel integration than + available with Cygwin. It is part of the Windows Services for Unix + package, available for free for any licensed copy of Windows 2000, XP + (not including XP Home), or 2003. SFU can be downloaded from <a href="http://www.microsoft.com/windows/sfu/" target="_top">http://www.microsoft.com/windows/sfu/</a>.</p> <p>Services for Unix 3.5, current as of this writing, has been tested. 3.0 - or 3.1 may work, but are not officially supported. (The main difference - in 3.0/3.1 is lack of pthreads.)</p> + or 3.1 may work, but are not officially supported. (The main difference + in 3.0/3.1 is lack of pthreads.)</p> <div class="sect3" lang="en"> <div class="titlepage"><div><div><h4 class="title"> <a name="platform.interix-sfu-install"></a>3.3.3.1. When installing Interix/SFU</h4></div></div></div> <p>At an absolute minimum, the following packages must be installed from - the Windows Services for Unix 3.5 distribution in order to use pkgsrc:</p> + the Windows Services for Unix 3.5 distribution in order to use pkgsrc:</p> <div class="itemizedlist"><ul type="disc"> <li><p>Utilities -> Base Utilities</p></li> <li><p>Interix GNU Components -> (all)</p></li> @@ -1374,43 +1384,43 @@ file and inspect the contents before extracting it. <li><p>Interix SDK</p></li> </ul></div> <p>When using pkgsrc on Interix, DO NOT install the Utilities subcomponent - "UNIX Perl". That is Perl 5.6 without shared module support, installed to - /usr/local, and will only cause confusion. Instead, install Perl 5.8 from - pkgsrc (or from a binary package).</p> + "UNIX Perl". That is Perl 5.6 without shared module support, installed to + /usr/local, and will only cause confusion. Instead, install Perl 5.8 from + pkgsrc (or from a binary package).</p> <p>The Remote Connectivity subcomponent "Windows Remote Shell Service" does - not need to be installed, but Remote Connectivity itself should be - installed in order to have a working inetd.</p> + not need to be installed, but Remote Connectivity itself should be + installed in order to have a working inetd.</p> <p>During installation you may be asked whether to enable setuid - behavior for Interix programs, and whether to make pathnames default to - case-sensitive. Setuid should be enabled, and case-sensitivity MUST be - enabled. (Without case-sensitivity, a large number of packages including - perl will not build.)</p> + behavior for Interix programs, and whether to make pathnames default to + case-sensitive. Setuid should be enabled, and case-sensitivity MUST be + enabled. (Without case-sensitivity, a large number of packages including + perl will not build.)</p> <p>NOTE: Newer Windows service packs change the way binary execution - works (via the Data Execution Prevention feature). In order to use - pkgsrc and other gcc-compiled binaries reliably, a hotfix containing - POSIX.EXE, PSXDLL.DLL, PSXRUN.EXE, and PSXSS.EXE (899522 or newer) - must be installed. Hotfixes are available from Microsoft through a - support contract; however, a NetBSD developer has made most Interix - hotfixes available for personal use from <a href="http://www.duh.org/interix/hotfixes.php" target="_top">http://www.duh.org/interix/hotfixes.php</a>.</p> + works (via the Data Execution Prevention feature). In order to use + pkgsrc and other gcc-compiled binaries reliably, a hotfix containing + POSIX.EXE, PSXDLL.DLL, PSXRUN.EXE, and PSXSS.EXE (899522 or newer) + must be installed. Hotfixes are available from Microsoft through a + support contract; however, a NetBSD developer has made most Interix + hotfixes available for personal use from <a href="http://www.duh.org/interix/hotfixes.php" target="_top">http://www.duh.org/interix/hotfixes.php</a>.</p> </div> <div class="sect3" lang="en"> <div class="titlepage"><div><div><h4 class="title"> <a name="platform.interix-sfu-postinstall"></a>3.3.3.2. What to do if Interix/SFU is already installed</h4></div></div></div> <p>If SFU is already installed and you wish to alter these settings to work - with pkgsrc, note the following things.</p> + with pkgsrc, note the following things.</p> <div class="itemizedlist"><ul type="disc"> <li><p>To uninstall UNIX Perl, use Add/Remove Programs, select Microsoft - Windows Services for UNIX, then click Change. In the installer, choose - Add or Remove, then uncheck Utilities->UNIX Perl.</p></li> + Windows Services for UNIX, then click Change. In the installer, choose + Add or Remove, then uncheck Utilities->UNIX Perl.</p></li> <li> <p>To enable case-sensitivity for the file system, run REGEDIT.EXE, and - change the following registry key:</p> + change the following registry key:</p> <p>HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\kernel</p> <p>Set the DWORD value "obcaseinsensitive" to 0; then reboot.</p> </li> <li> <p>To enable setuid binaries (optional), run REGEDIT.EXE, and change the - following registry key:</p> + following registry key:</p> <p>HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Services for UNIX</p> <p>Set the DWORD value "EnableSetuidBinaries" to 1; then reboot.</p> </li> @@ -1420,84 +1430,84 @@ file and inspect the contents before extracting it. <div class="titlepage"><div><div><h4 class="title"> <a name="platform.interix-notes"></a>3.3.3.3. Important notes for using pkgsrc</h4></div></div></div> <p>The package manager (either the pkgsrc "su" user, or the user - running "pkg_add") must be a member of the local Administrators - group. Such a user must also be used to run the bootstrap. This is - slightly relaxed from the normal pkgsrc requirement of "root".</p> + running "pkg_add") must be a member of the local Administrators + group. Such a user must also be used to run the bootstrap. This is + slightly relaxed from the normal pkgsrc requirement of "root".</p> <p>The package manager should use a umask of 002. "make install" will - automatically complain if this is not the case. This ensures that - directories written in /var/db/pkg are Administrators-group writeable.</p> + automatically complain if this is not the case. This ensures that + directories written in /var/db/pkg are Administrators-group writeable.</p> <p>The popular Interix binary packages from http://www.interopsystems.com/ - use an older version of pkgsrc's pkg_* tools. Ideally, these should - NOT be used in conjunction with pkgsrc. If you choose to use them at - the same time as the pkgsrc packages, ensure that you use the proper - pkg_* tools for each type of binary package.</p> + use an older version of pkgsrc's pkg_* tools. Ideally, these should + NOT be used in conjunction with pkgsrc. If you choose to use them at + the same time as the pkgsrc packages, ensure that you use the proper + pkg_* tools for each type of binary package.</p> <p>The TERM setting used for DOS-type console windows (including those - invoked by the csh and ksh startup shortcuts) is "interix". Most systems - don't have a termcap/terminfo entry for it, but the following .termcap - entry provides adequate emulation in most cases:</p> + invoked by the csh and ksh startup shortcuts) is "interix". Most systems + don't have a termcap/terminfo entry for it, but the following .termcap + entry provides adequate emulation in most cases:</p> <pre class="programlisting"> - interix:kP=\E[S:kN=\E[T:kH=\E[U:dc@:DC@:tc=pcansi: -</pre> + interix:kP=\E[S:kN=\E[T:kH=\E[U:dc@:DC@:tc=pcansi: + </pre> </div> <div class="sect3" lang="en"> <div class="titlepage"><div><div><h4 class="title"> <a name="platform.interix-limits"></a>3.3.3.4. Limitations of the Interix platform</h4></div></div></div> <p>Though Interix suffices as a familiar and flexible substitute - for a full Unix-like platform, it has some drawbacks that should - be noted for those desiring to make the most of Interix.</p> + for a full Unix-like platform, it has some drawbacks that should + be noted for those desiring to make the most of Interix.</p> <div class="itemizedlist"><ul type="disc"> <li> <p><span class="strong"><strong>X11:</strong></span></p> <p>Interix comes with the standard set of X11R6 client libraries, - and can run X11 based applications, but it does - <span class="emphasis"><em>not</em></span> come with an X server. Some options are - <a href="http://www.starnet.com/products/xwin32/" target="_top">StarNet X-Win32</a>, - <a href="http://connectivity.hummingbird.com/products/nc/exceed/" target="_top">Hummingbird Exceed</a> - (available in a trimmed version for Interix from Interop Systems as the - <a href="http://www.interopsystems.com/InteropXserver.htm" target="_top">Interop X Server</a>), - and the free X11 server included with - <a href="http://x.cygwin.com/" target="_top">Cygwin</a>.</p> + and can run X11 based applications, but it does + <span class="emphasis"><em>not</em></span> come with an X server. Some options are + <a href="http://www.starnet.com/products/xwin32/" target="_top">StarNet X-Win32</a>, + <a href="http://connectivity.hummingbird.com/products/nc/exceed/" target="_top">Hummingbird Exceed</a> + (available in a trimmed version for Interix from Interop Systems as the + <a href="http://www.interopsystems.com/InteropXserver.htm" target="_top">Interop X Server</a>), + and the free X11 server included with + <a href="http://x.cygwin.com/" target="_top">Cygwin</a>.</p> <p>Also, StarNet Communications has graciously provided a free - version of their X-Win32 product that accepts connections only - from localhost: - <a href="http://www.starnet.com/xwin32LX/get_xwin32LX.htm" target="_top">X-Win32 LX</a>, - recommended by the maintainer of Interix pkgsrc support.</p> + version of their X-Win32 product that accepts connections only + from localhost: + <a href="http://www.starnet.com/xwin32LX/get_xwin32LX.htm" target="_top">X-Win32 LX</a>, + recommended by the maintainer of Interix pkgsrc support.</p> </li> <li> <p><span class="strong"><strong>X11 acceleration:</strong></span></p> <p>Because Interix runs in a completely different NT subsystem from - Win32 applications, it does not currently support various X11 - protocol extensions for acceleration (such as MIT-SHM or DGA). - Most interactive applications to a local X server will run - reasonably fast, but full motion video and other graphics - intensive applications may require a faster-than-expected CPU.</p> + Win32 applications, it does not currently support various X11 + protocol extensions for acceleration (such as MIT-SHM or DGA). + Most interactive applications to a local X server will run + reasonably fast, but full motion video and other graphics + intensive applications may require a faster-than-expected CPU.</p> </li> <li> <p><span class="strong"><strong>Audio:</strong></span></p> <p>Interix has no native support for audio output. For audio - support, pkgsrc uses the <span><strong class="command">esound</strong></span> client/server - audio system on Interix. Unlike on most platforms, the - <a href="ftp://ftp.NetBSD.org/pub/NetBSD/packages/pkgsrc/audio/esound/README.html" target="_top"><code class="filename">audio/esound</code></a> package does - <span class="emphasis"><em>not</em></span> contain the <span><strong class="command">esd</strong></span> - server component. To output audio via an Interix host, the - <a href="ftp://ftp.NetBSD.org/pub/NetBSD/packages/pkgsrc/emulators/cygwin_esound/README.html" target="_top"><code class="filename">emulators/cygwin_esound</code></a> package - must also be installed.</p> + support, pkgsrc uses the <span><strong class="command">esound</strong></span> client/server + audio system on Interix. Unlike on most platforms, the + <a href="ftp://ftp.NetBSD.org/pub/NetBSD/packages/pkgsrc/audio/esound/README.html" target="_top"><code class="filename">audio/esound</code></a> package does + <span class="emphasis"><em>not</em></span> contain the <span><strong class="command">esd</strong></span> + server component. To output audio via an Interix host, the + <a href="ftp://ftp.NetBSD.org/pub/NetBSD/packages/pkgsrc/emulators/cygwin_esound/README.html" target="_top"><code class="filename">emulators/cygwin_esound</code></a> package + must also be installed.</p> </li> <li> <p><span class="strong"><strong>CD/DVDs, USB, and SCSI:</strong></span></p> <p>Direct device access is not currently supported in Interix, so it - is not currently possible to access CD/DVD drives, USB devices, - or SCSI devices through non-filesystem means. Among other things, - this makes it impossible to use Interix directly for CD/DVD - burning.</p> + is not currently possible to access CD/DVD drives, USB devices, + or SCSI devices through non-filesystem means. Among other things, + this makes it impossible to use Interix directly for CD/DVD + burning.</p> </li> <li> <p><span class="strong"><strong>Tape drives:</strong></span></p> <p>Due to the same limitations as for CD-ROMs and SCSI devices, tape - drives are also not directly accessible in Interix. However, - support is in work to make tape drive access possible by using - Cygwin as a bridge (similarly to audio bridged via Cygwin's - esound server).</p> + drives are also not directly accessible in Interix. However, + support is in work to make tape drive access possible by using + Cygwin as a bridge (similarly to audio bridged via Cygwin's + esound server).</p> </li> </ul></div> </div> @@ -1505,149 +1515,153 @@ file and inspect the contents before extracting it. <div class="titlepage"><div><div><h4 class="title"> <a name="platform.interix-knownissues"></a>3.3.3.5. Known issues for pkgsrc on Interix</h4></div></div></div> <p>It is not necessary, in general, to have a "root" user on the - Windows system; any member of the local Administrators group will - suffice. However, some packages currently assume that the user - named "root" is the privileged user. To accommodate these, you - may create such a user; make sure it is in the local group - Administrators (or your language equivalent).</p> -<p>"pkg_add" creates directories of mode 0755, not 0775, in - $PKG_DBDIR. For the time being, install packages as the local - Administrator (or your language equivalent), or run the following - command after installing a package to work around the issue:</p> + Windows system; any member of the local Administrators group will + suffice. However, some packages currently assume that the user + named "root" is the privileged user. To accommodate these, you + may create such a user; make sure it is in the local group + Administrators (or your language equivalent).</p> +<p><span><strong class="command">pkg_add</strong></span> creates directories of mode + 0755, not 0775, in <code class="filename">$PKG_DBDIR</code>. For the + time being, install packages as the local Administrator (or + your language equivalent), or run the following command after + installing a package to work around the issue:</p> <pre class="screen"> -<code class="prompt">#</code> <strong class="userinput"><code>chmod -R g+w $PKG_DBDIR</code></strong></pre> +<code class="prompt">#</code> <strong class="userinput"><code>chmod -R g+w $PKG_DBDIR</code></strong> + </pre> </div> </div> <div class="sect2" lang="en"> <div class="titlepage"><div><div><h3 class="title"> <a name="irix"></a>3.3.4. IRIX</h3></div></div></div> <p>You will need a working C compiler, either gcc or SGI's MIPS and MIPSpro - compiler (cc/c89). Please set the <code class="varname">CC</code> environment variable - according to your preference. If you do not have a license for the MIPSpro - compiler suite, you can download a gcc tardist file from <a href="http://freeware.sgi.com/" target="_top">http://freeware.sgi.com/</a>.</p> + compiler (cc/c89). Please set the <code class="varname">CC</code> environment variable + according to your preference. If you do not have a license for the MIPSpro + compiler suite, you can download a gcc tardist file from <a href="http://freeware.sgi.com/" target="_top">http://freeware.sgi.com/</a>.</p> <p>Please note that you will need IRIX 6.5.17 or higher, as this is the earliest - version of IRIX providing support for <a href="http://netbsd.gw.com/cgi-bin/man-cgi?if_indextoname+3+NetBSD-current"><span class="citerefentry"><span class="refentrytitle">if_indextoname</span>(3)</span></a>, <a href="http://netbsd.gw.com/cgi-bin/man-cgi?if_nametoindex+3+NetBSD-current"><span class="citerefentry"><span class="refentrytitle">if_nametoindex</span>(3)</span></a>, - etc.</p> + version of IRIX providing support for <a href="http://netbsd.gw.com/cgi-bin/man-cgi?if_indextoname+3+NetBSD-current"><span class="citerefentry"><span class="refentrytitle">if_indextoname</span>(3)</span></a>, <a href="http://netbsd.gw.com/cgi-bin/man-cgi?if_nametoindex+3+NetBSD-current"><span class="citerefentry"><span class="refentrytitle">if_nametoindex</span>(3)</span></a>, + etc.</p> <p>At this point in time, pkgsrc only supports one ABI at a time. That is, you cannot switch between the old 32-bit ABI, the new 32-bit ABI and the 64-bit ABI. If you start out using "abi=n32", that's what all your packages will be built with.</p> <p>Therefore, please make sure that you have no conflicting - <code class="varname">CFLAGS</code> in your environment or the - <code class="filename">/etc/mk.conf</code>. Particularly, make sure that you do not - try to link n32 object files with lib64 or vice versa. Check your - <code class="filename">/etc/compiler.defaults</code>!</p> + <code class="varname">CFLAGS</code> in your environment or the + <code class="filename">/etc/mk.conf</code>. Particularly, make sure that you do not + try to link n32 object files with lib64 or vice versa. Check your + <code class="filename">/etc/compiler.defaults</code>!</p> <p>If you have the actual pkgsrc tree mounted via NFS from a different host, - please make sure to set <code class="varname">WRKOBJDIR</code> to a local directory, - as it appears that IRIX linker occasionally runs into issues when trying to - link over a network-mounted file system.</p> + please make sure to set <code class="varname">WRKOBJDIR</code> to a local directory, + as it appears that IRIX linker occasionally runs into issues when trying to + link over a network-mounted file system.</p> <p>The bootstrapping process should set all the right options for programs such - as imake(1), but you may want to set some options depending on your local - setup. Please see <code class="filename">pkgsrc/mk/defaults/mk.conf</code> and, of - course, your compiler's man pages for details.</p> + as imake(1), but you may want to set some options depending on your local + setup. Please see <code class="filename">pkgsrc/mk/defaults/mk.conf</code> and, of + course, your compiler's man pages for details.</p> <p>If you are using SGI's MIPSPro compiler, please set -</p> + </p> <pre class="programlisting"> - PKGSRC_COMPILER= mipspro -</pre> + PKGSRC_COMPILER= mipspro + </pre> <p> - in <code class="filename">/etc/mk.conf</code>. Otherwise, pkgsrc will assume you - are using gcc and may end up passing invalid flags to the compiler. Note that - bootstrap should create an appropriate <code class="filename">mk.conf.example</code> by - default.</p> + in <code class="filename">/etc/mk.conf</code>. Otherwise, pkgsrc will assume you + are using gcc and may end up passing invalid flags to the compiler. Note that + bootstrap should create an appropriate <code class="filename">mk.conf.example</code> by + default.</p> <p>If you have both the MIPSPro compiler chain installed as well as gcc, - but want to make sure that MIPRPro is used, please set your <code class="varname">PATH</code> - to <span class="emphasis"><em>not</em></span> include the location of gcc (often - <code class="filename">/usr/freeware/bin</code>), and (important) pass the - '--preserve-path' flag.</p> + but want to make sure that MIPRPro is used, please set your <code class="varname">PATH</code> + to <span class="emphasis"><em>not</em></span> include the location of gcc (often + <code class="filename">/usr/freeware/bin</code>), and (important) pass the + '--preserve-path' flag.</p> </div> <div class="sect2" lang="en"> <div class="titlepage"><div><div><h3 class="title"> <a name="linux"></a>3.3.5. Linux</h3></div></div></div> -<p> - Some versions of Linux (for example Debian GNU/Linux) need either - libtermcap or libcurses (libncurses). Installing the distributions - libncurses-dev package (or equivalent) should fix the problem.</p> -<p> - pkgsrc supports both gcc (GNU Compiler Collection) and icc (Intel C++ - Compiler). gcc is the default. icc 8.0 and 8.1 on i386 have been tested. - </p> +<p>Some versions of Linux (for example Debian GNU/Linux) need + either libtermcap or libcurses (libncurses). Installing the + distributions libncurses-dev package (or equivalent) should fix + the problem.</p> +<p>pkgsrc supports both gcc (GNU Compiler Collection) and icc + (Intel C++ Compiler). gcc is the default. icc 8.0 and 8.1 on + i386 have been tested.</p> <p>To bootstrap using icc, assuming the default icc installation - directory:</p> + directory:</p> <pre class="programlisting"> - env CC=/opt/intel_cc_80/bin/icc LDFLAGS=-static-libcxa \ - ac_cv___attribute__=yes ./bootstrap -</pre> + env CC=/opt/intel_cc_80/bin/icc LDFLAGS=-static-libcxa \ + ac_cv___attribute__=yes ./bootstrap + </pre> <div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"> <h3 class="title">Note</h3> <p>icc 8.1 needs the `-i-static' argument instead of -static-libcxa.</p> </div> <p>icc supports __attribute__, but the GNU configure test uses a nested - function, which icc does not support. #undef'ing __attribute__ has the - unfortunate side-effect of breaking many of the Linux header files, which - cannot be compiled properly without __attribute__. The test must be - overridden so that __attribute__ is assumed supported by the - compiler.</p> + function, which icc does not support. #undef'ing __attribute__ has the + unfortunate side-effect of breaking many of the Linux header files, which + cannot be compiled properly without __attribute__. The test must be + overridden so that __attribute__ is assumed supported by the + compiler.</p> <p>After bootstrapping, you should set <code class="varname">PKGSRC_COMPILER</code> - in <code class="filename">/etc/mk.conf</code>:</p> + in <code class="filename">/etc/mk.conf</code>:</p> <pre class="programlisting"> - PKGSRC_COMPILER= icc -</pre> + PKGSRC_COMPILER= icc + </pre> <p>The default installation directory for icc is - <code class="filename">/opt/intel_cc_80</code>, which - is also the pkgsrc default. If you have installed it into a different - directory, set <code class="varname">ICCBASE</code> in - <code class="filename">/etc/mk.conf</code>:</p> + <code class="filename">/opt/intel_cc_80</code>, which + is also the pkgsrc default. If you have installed it into a different + directory, set <code class="varname">ICCBASE</code> in + <code class="filename">/etc/mk.conf</code>:</p> <pre class="programlisting"> - ICCBASE= /opt/icc -</pre> + ICCBASE= /opt/icc + </pre> <p>pkgsrc uses the static linking method of the runtime libraries - provided by icc, so binaries can be run on other systems which do not - have the shared libraries installed.</p> -<p>Libtool, however, extracts a list of libraries from the <a href="http://netbsd.gw.com/cgi-bin/man-cgi?ld+1+NetBSD-current"><span class="citerefentry"><span class="refentrytitle">ld</span>(1)</span></a> - command run when linking a C++ shared library and records it, throwing - away the -Bstatic and -Bdynamic options interspersed between the libraries. - This means that libtool-linked C++ shared libraries will have a - runtime dependency on the icc libraries until this is fixed in libtool. - </p> + provided by icc, so binaries can be run on other systems which do not + have the shared libraries installed.</p> +<p>Libtool, however, extracts a list of libraries from the + <a href="http://netbsd.gw.com/cgi-bin/man-cgi?ld+1+NetBSD-current"><span class="citerefentry"><span class="refentrytitle">ld</span>(1)</span></a> command run when linking a C++ shared library and + records it, throwing away the -Bstatic and -Bdynamic options + interspersed between the libraries. This means that + libtool-linked C++ shared libraries will have a runtime + dependency on the icc libraries until this is fixed in + libtool.</p> </div> <div class="sect2" lang="en"> <div class="titlepage"><div><div><h3 class="title"> <a name="openbsd"></a>3.3.6. OpenBSD</h3></div></div></div> <p>OpenBSD 3.0 and 3.2 are tested and supported.</p> <p>Care should be taken so that the tools that this kit installs do not conflict - with the OpenBSD userland tools. There are several steps:</p> + with the OpenBSD userland tools. There are several steps:</p> <div class="orderedlist"><ol type="1"> <li><p>OpenBSD stores its ports pkg database in - <code class="filename">/var/db/pkg</code>. It is therefore - recommended that you choose a different location (e.g. - <code class="filename">/usr/pkgdb</code>) by - using the --pkgdbdir option to the bootstrap script.</p></li> + <code class="filename">/var/db/pkg</code>. It is therefore + recommended that you choose a different location (e.g. + <code class="filename">/usr/pkgdb</code>) by + using the --pkgdbdir option to the bootstrap script.</p></li> <li> <p>If you do not intend to use the OpenBSD ports tools, it's probably a - good idea to move them out of the way to avoid confusion, e.g.</p> -<pre class="screen"><code class="prompt">#</code> <strong class="userinput"><code>cd /usr/sbin</code></strong> + good idea to move them out of the way to avoid confusion, e.g.</p> +<pre class="screen"> +<code class="prompt">#</code> <strong class="userinput"><code>cd /usr/sbin</code></strong> <code class="prompt">#</code> <strong class="userinput"><code>mv pkg_add pkg_add.orig</code></strong> <code class="prompt">#</code> <strong class="userinput"><code>mv pkg_create pkg_create.orig</code></strong> <code class="prompt">#</code> <strong class="userinput"><code>mv pkg_delete pkg_delete.orig</code></strong> -<code class="prompt">#</code> <strong class="userinput"><code>mv pkg_info pkg_info.orig</code></strong></pre> +<code class="prompt">#</code> <strong class="userinput"><code>mv pkg_info pkg_info.orig</code></strong> + </pre> </li> <li> <p>An example <code class="filename">/etc/mk.conf</code> file will be placed in - <code class="filename">/etc/mk.conf.example</code> file - when you use the bootstrap script. OpenBSD's make program uses - <code class="filename">/etc/mk.conf</code> - as well. You can work around this by enclosing all the pkgsrc-specific parts - of the file with:</p> + <code class="filename">/etc/mk.conf.example</code> file + when you use the bootstrap script. OpenBSD's make program uses + <code class="filename">/etc/mk.conf</code> + as well. You can work around this by enclosing all the pkgsrc-specific parts + of the file with:</p> <pre class="programlisting"> - .ifdef BSD_PKG_MK - # pkgsrc stuff, e.g. insert defaults/mk.conf or similar here - .else - # OpenBSD stuff - .endif -</pre> + .ifdef BSD_PKG_MK + # pkgsrc stuff, e.g. insert defaults/mk.conf or similar here + .else + # OpenBSD stuff + .endif + </pre> </li> </ol></div> </div> @@ -1655,10 +1669,10 @@ file and inspect the contents before extracting it. <div class="titlepage"><div><div><h3 class="title"> <a name="solaris"></a>3.3.7. Solaris</h3></div></div></div> <p>Solaris 2.6 through 9 are supported on both x86 and sparc. - You will need a working C compiler. Both gcc 2.95.3 and - Sun WorkShop 5 have been tested.</p> + 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> + process and to build packages.</p> <div class="itemizedlist"><ul type="disc"> <li><p>SUNWsprot</p></li> <li><p>SUNWarc</p></li> @@ -1667,45 +1681,45 @@ file and inspect the contents before extracting it. <li><p>SUNWlibm</p></li> </ul></div> <p>Please note that the use of GNU binutils on Solaris is - <span class="emphasis"><em>not</em></span> supported, as of June 2006.</p> + <span class="emphasis"><em>not</em></span> supported, as of June 2006.</p> <p>Whichever compiler you use, please ensure the compiler tools and - your $prefix are in your <code class="varname">PATH</code>. This includes - <code class="filename">/usr/ccs/{bin,lib}</code> - and e.g. <code class="filename">/usr/pkg/{bin,sbin}</code>.</p> + your $prefix are in your <code class="varname">PATH</code>. This includes + <code class="filename">/usr/ccs/{bin,lib}</code> + and e.g. <code class="filename">/usr/pkg/{bin,sbin}</code>.</p> <div class="sect3" lang="en"> <div class="titlepage"><div><div><h4 class="title"> <a name="solaris-gcc-note"></a>3.3.7.1. If you are using gcc</h4></div></div></div> <p>It makes life much simpler if you only use the same gcc consistently - for building all packages.</p> + for building all packages.</p> <p>It is recommended that an external gcc be used only for bootstrapping, - then either build gcc from - <a href="ftp://ftp.NetBSD.org/pub/NetBSD/packages/pkgsrc/lang/gcc/README.html" target="_top"><code class="filename">lang/gcc</code></a> or install a binary gcc - package, then remove gcc used during bootstrapping.</p> + then either build gcc from + <a href="ftp://ftp.NetBSD.org/pub/NetBSD/packages/pkgsrc/lang/gcc/README.html" target="_top"><code class="filename">lang/gcc</code></a> or install a binary gcc + package, then remove gcc used during bootstrapping.</p> <p>Binary packages of gcc can be found through <a href="http://www.sun.com/bigadmin/common/freewareSearch.html" target="_top">http://www.sun.com/bigadmin/common/freewareSearch.html</a>.</p> </div> <div class="sect3" lang="en"> <div class="titlepage"><div><div><h4 class="title"> <a name="solaris-sun-workshop-note"></a>3.3.7.2. If you are using Sun WorkShop</h4></div></div></div> <p>You will need at least the following packages installed (from WorkShop - 5.0)</p> + 5.0)</p> <div class="itemizedlist"><ul type="disc"> <li><p>SPROcc - - Sun WorkShop Compiler C 5.0</p></li> + - Sun WorkShop Compiler C 5.0</p></li> <li><p>SPROcpl - - Sun WorkShop Compiler C++ 5.0</p></li> + - Sun WorkShop Compiler C++ 5.0</p></li> <li><p>SPROild - - Sun WorkShop Incremental Linker</p></li> + - Sun WorkShop Incremental Linker</p></li> <li><p>SPROlang - - Sun WorkShop Compilers common components</p></li> + - Sun WorkShop Compilers common components</p></li> </ul></div> <p>You should set <code class="varname">CC</code>, <code class="varname">CXX</code> and - optionally, <code class="varname">CPP</code> in <code class="filename">/etc/mk.conf</code>, - e.g.:</p> + optionally, <code class="varname">CPP</code> in <code class="filename">/etc/mk.conf</code>, + e.g.:</p> <pre class="programlisting"> - CC= cc - CXX= CC - CPP= /usr/ccs/lib/cpp -</pre> + CC= cc + CXX= CC + CPP= /usr/ccs/lib/cpp + </pre> </div> <div class="sect3" lang="en"> <div class="titlepage"><div><div><h4 class="title"> @@ -1719,25 +1733,25 @@ file and inspect the contents before extracting it. called <code class="filename">cc64</code> and put it somewhere in the <code class="varname">PATH</code>:</p> <pre class="programlisting"> - #! /bin/sh - exec /opt/SUNWspro/bin/cc -xtarget=ultra -xarch=v9 ${1+"$@"} -</pre> + #! /bin/sh + exec /opt/SUNWspro/bin/cc -xtarget=ultra -xarch=v9 ${1+"$@"} + </pre> <p>Then, pass the definition for <code class="varname">CC</code> in the environment of the <span><strong class="command">bootstrap</strong></span> command:</p> <pre class="programlisting"> - <code class="prompt">$</code> <strong class="userinput"><code>cd bootstrap</code></strong> - <code class="prompt">$</code> <strong class="userinput"><code>CC=cc64 ./bootstrap</code></strong> -</pre> + <code class="prompt">$</code> <strong class="userinput"><code>cd bootstrap</code></strong> + <code class="prompt">$</code> <strong class="userinput"><code>CC=cc64 ./bootstrap</code></strong> + </pre> <p>After bootstrapping, there are two alternative ways, depending on whether you want to find bugs in packages or get your system ready quickly. If you just want a running system, add the following lines to your <code class="filename">mk.conf</code> file:</p> <pre class="programlisting"> - CC= cc64 - CXX= CC64 - PKGSRC_COMPILER= sunpro -</pre> + CC= cc64 + CXX= CC64 + PKGSRC_COMPILER= sunpro + </pre> <p>This way, all calls to the compiler will be intercepted by the above wrapper and therefore get the necessary ABI options automatically. (Don't forget to create the shell script @@ -1747,13 +1761,13 @@ file and inspect the contents before extracting it. the following lines to your <code class="filename">mk.conf</code> file:</p> <pre class="programlisting"> - CC= cc - CXX= CC - PKGSRC_COMPILER= sunpro - CFLAGS= -xtarget=ultra -xarch=v9 - CXXFLAGS= -xtarget=ultra -xarch=v9 - LDFLAGS= -xtarget=ultra -xarch=v9 -</pre> + CC= cc + CXX= CC + PKGSRC_COMPILER= sunpro + CFLAGS= -xtarget=ultra -xarch=v9 + CXXFLAGS= -xtarget=ultra -xarch=v9 + LDFLAGS= -xtarget=ultra -xarch=v9 + </pre> <p>Packages that don't use the flags provided in the configuration file will try to build 32-bit binaries and fail during linking. Detecting this is useful to prevent bugs on @@ -1764,14 +1778,14 @@ file and inspect the contents before extracting it. <div class="titlepage"><div><div><h4 class="title"> <a name="plat.sunos.problems"></a>3.3.7.4. Common problems</h4></div></div></div> <p>Sometimes, when using <span><strong class="command">libtool</strong></span>, - <code class="filename">/bin/ksh</code> crashes with a segmentation fault. - The workaround is to use another shell for the configure - scripts, for example by installing <a href="ftp://ftp.NetBSD.org/pub/NetBSD/packages/pkgsrc/shells/bash/README.html" target="_top"><code class="filename">shells/bash</code></a> and adding the following lines - to your <code class="filename">mk.conf</code>:</p> + <code class="filename">/bin/ksh</code> crashes with a segmentation fault. + The workaround is to use another shell for the configure + scripts, for example by installing <a href="ftp://ftp.NetBSD.org/pub/NetBSD/packages/pkgsrc/shells/bash/README.html" target="_top"><code class="filename">shells/bash</code></a> and adding the following lines + to your <code class="filename">mk.conf</code>:</p> <pre class="programlisting"> - CONFIG_SHELL= ${LOCALBASE}/bin/bash - WRAPPER_SHELL= ${LOCALBASE}/bin/bash -</pre> + CONFIG_SHELL= ${LOCALBASE}/bin/bash + WRAPPER_SHELL= ${LOCALBASE}/bin/bash + </pre> <p>Then, rebuild the <a href="ftp://ftp.NetBSD.org/pub/NetBSD/packages/pkgsrc/devel/libtool-base/README.html" target="_top"><code class="filename">devel/libtool-base</code></a> package.</p> </div> </div> @@ -1894,18 +1908,17 @@ file and inspect the contents before extracting it. <div class="sect2" lang="en"> <div class="titlepage"><div><div><h3 class="title"> <a name="installing-binary-packages"></a>4.1.2. Installing binary packages</h3></div></div></div> -<p> If you have the files on a CD-ROM or downloaded them to +<p>If you have the files on a CD-ROM or downloaded them to your hard disk, you can install them with the following command (be sure to <span><strong class="command">su</strong></span> to root first):</p> <pre class="screen"><code class="prompt">#</code> <strong class="userinput"><code>pkg_add /path/to/package.tgz</code></strong></pre> -<p> If you have FTP access and you don't want to download the +<p>If you have FTP access and you don't want to download the packages via FTP prior to installation, you can do this - automatically by giving <span><strong class="command">pkg_add</strong></span> an FTP URL: - </p> + automatically by giving <span><strong class="command">pkg_add</strong></span> an FTP URL:</p> <pre class="screen"><code class="prompt">#</code> <strong class="userinput"><code>pkg_add ftp://ftp.NetBSD.org/pub/NetBSD/packages/<OSVERSION>/<ARCH>/All/package</code></strong></pre> <p>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> + present where you install from.</p> <p>To save some typing, you can set the <code class="varname">PKG_PATH</code> environment variable to a semicolon-separated list of paths (including remote URLs); trailing slashes are not allowed. @@ -1926,7 +1939,7 @@ file and inspect the contents before extracting it. <p>After you've installed packages, be sure to have <code class="filename">/usr/pkg/bin</code> and <code class="filename">/usr/pkg/sbin</code> in your <code class="varname">PATH</code> so you can actually start the just - installed program. </p> + installed program.</p> </div> <div class="sect2" lang="en"> <div class="titlepage"><div><div><h3 class="title"> @@ -2034,8 +2047,7 @@ package on your system and rebuild any dependencies. <div class="sect1" lang="en"> <div class="titlepage"><div><div><h2 class="title" style="clear: both"> <a name="building-packages-from-source"></a>4.2. Building packages from source</h2></div></div></div> -<p> -After obtaining pkgsrc, the <code class="filename">pkgsrc</code> directory +<p>After obtaining pkgsrc, the <code class="filename">pkgsrc</code> directory now contains a set of packages, organized into categories. You can browse the online index of packages, or run <span><strong class="command">make readme</strong></span> from the <code class="filename">pkgsrc</code> directory to build local @@ -2080,7 +2092,7 @@ to your <code class="filename">mk.conf</code>. <p>You can overwrite some of the major distribution sites to fit to sites that are close to your own. Have a look at <code class="filename">pkgsrc/mk/defaults/mk.conf</code> to find some examples - — in particular, look for the <code class="varname">MASTER_SORT</code>, + — in particular, look for the <code class="varname">MASTER_SORT</code>, <code class="varname">MASTER_SORT_REGEX</code> and <code class="varname">INET_COUNTRY</code> definitions. This may save some of your bandwidth and time.</p> @@ -2117,7 +2129,7 @@ compile time. use the pkgsrc <span><strong class="command">bmake</strong></span> command instead of “<span class="quote">make</span>” in the examples in this guide.</p> </div> -<p>For example, type </p> +<p>For example, type</p> <pre class="screen"><code class="prompt">%</code> <strong class="userinput"><code>cd misc/figlet</code></strong> <code class="prompt">%</code> <strong class="userinput"><code>make</code></strong></pre> <p>at the shell prompt to build the various components of the @@ -2224,14 +2236,13 @@ You can now enter: <div class="titlepage"><div><div><h3 class="title"> <a name="selecting-the-compiler"></a>4.2.4. Selecting the compiler</h3></div></div></div> <p>By default, pkgsrc will use GCC to build packages. This may be - overridden by setting the following variables in /etc/mk.conf: - </p> + overridden by setting the following variables in /etc/mk.conf:</p> <div class="variablelist"><dl> <dt><span class="term"><code class="varname">PKGSRC_COMPILER</code>:</span></dt> <dd> -<p> This is a list of values specifying the chain of +<p>This is a list of values specifying the chain of compilers to invoke when building packages. Valid values - are: </p> + are:</p> <div class="itemizedlist"><ul type="disc"> <li><p><code class="varname">distcc</code>: distributed C/C++ (chainable)</p></li> @@ -2246,20 +2257,20 @@ You can now enter: <li><p><code class="varname">sunpro</code>: Sun Microsystems, Inc. WorkShip/Forte/Sun ONE Studio</p></li> </ul></div> -<p> The default is +<p>The default is “<span class="quote"><code class="varname">gcc</code></span>”. You can use <code class="varname">ccache</code> and/or <code class="varname">distcc</code> with an appropriate <code class="varname">PKGSRC_COMPILER</code> setting, e.g. “<span class="quote"><code class="varname">ccache gcc</code></span>”. This variable should always be - terminated with a value for a real compiler. </p> + terminated with a value for a real compiler.</p> </dd> <dt><span class="term"><code class="varname">GCC_REQD</code>:</span></dt> -<dd><p> This specifies the minimum version of GCC to use +<dd><p>This specifies the minimum version of GCC to use when building packages. If the system GCC doesn't satisfy this requirement, then pkgsrc will build and - install one of the GCC packages to use instead. </p></dd> + install one of the GCC packages to use instead.</p></dd> </dl></div> </div> </div> @@ -2341,7 +2352,7 @@ You can now enter: can be NFS-mounted while <code class="filename">${WRKOBJDIR}</code> is local to every architecture. (It should be noted that <code class="varname">PKGSRCDIR</code> should not be set by the user - — it is an internal definition which refers to the + — it is an internal definition which refers to the root of the pkgsrc tree. It is possible to have many pkgsrc tree instances.)</p></li> <li><p><code class="varname">LOCALPATCHES</code>: @@ -2363,8 +2374,6 @@ You can now enter: <code class="literal">package</code> to automatically create binary packages after installing dependencies.</p></li> </ul></div> -<p> - </p> </div> <div class="sect1" lang="en"> <div class="titlepage"><div><div><h2 class="title" style="clear: both"> @@ -2401,7 +2410,7 @@ You can now enter: find their shared libs.</p></li> </ul></div> <p> - </p> + </p> </li> <li><p><code class="varname">PKG_DEBUG_LEVEL</code>: The level of debugging output which is displayed whilst @@ -2507,32 +2516,28 @@ PKG_OPTIONS.apache= suexec </pre> <div class="sect1" lang="en"> <div class="titlepage"><div><div><h2 class="title" style="clear: both"> <a name="building-a-single-binary-package"></a>6.1. Building a single binary package</h2></div></div></div> -<p> - Once you have built and installed a package, you can create a - <span class="emphasis"><em>binary package</em></span> which can be installed on - another system with <a href="http://netbsd.gw.com/cgi-bin/man-cgi?pkg_add+1+NetBSD-current"><span class="citerefentry"><span class="refentrytitle">pkg_add</span>(1)</span></a>. This saves having to build - the same package on a group of hosts and wasting CPU time. It - also provides a simple means for others to install your package, - should you distribute it. - </p> -<p> - To create a binary package, change into the appropriate - directory in pkgsrc, and run <span><strong class="command">make - package</strong></span>: - </p> -<pre class="screen"><code class="prompt">#</code> <strong class="userinput"><code>cd misc/figlet</code></strong> -<code class="prompt">#</code> <strong class="userinput"><code>make package</code></strong></pre> -<p> - This will build and install your package (if not already done), - and then build a binary package from what was installed. You can - then use the <span><strong class="command">pkg_*</strong></span> tools to manipulate - it. Binary packages are created by default in - <code class="filename">/usr/pkgsrc/packages</code>, in the form of a - gzipped tar file. See <a href="#logs.package" title="B.2. Packaging figlet">Section B.2, “Packaging figlet”</a> for a - continuation of the above <a href="ftp://ftp.NetBSD.org/pub/NetBSD/packages/pkgsrc/misc/figlet/README.html" target="_top"><code class="filename">misc/figlet</code></a> example.</p> -<p> - See <a href="#submit" title="Chapter 19. Submitting and Committing">Chapter 19, <i>Submitting and Committing</i></a> for information on how to submit - such a binary package.</p> +<p>Once you have built and installed a package, you can create + a <span class="emphasis"><em>binary package</em></span> which can be installed on + another system with <a href="http://netbsd.gw.com/cgi-bin/man-cgi?pkg_add+1+NetBSD-current"><span class="citerefentry"><span class="refentrytitle">pkg_add</span>(1)</span></a>. This saves having to build + the same package on a group of hosts and wasting CPU time. It also + provides a simple means for others to install your package, should + you distribute it.</p> +<p>To create a binary package, change into the appropriate + directory in pkgsrc, and run <span><strong class="command">make + package</strong></span>:</p> +<pre class="screen"> +<code class="prompt">#</code> <strong class="userinput"><code>cd misc/figlet</code></strong> +<code class="prompt">#</code> <strong class="userinput"><code>make package</code></strong> + </pre> +<p>This will build and install your package (if not already done), + and then build a binary package from what was installed. You can + then use the <span><strong class="command">pkg_*</strong></span> tools to manipulate + it. Binary packages are created by default in + <code class="filename">/usr/pkgsrc/packages</code>, in the form of a + gzipped tar file. See <a href="#logs.package" title="B.2. Packaging figlet">Section B.2, “Packaging figlet”</a> for a + continuation of the above <a href="ftp://ftp.NetBSD.org/pub/NetBSD/packages/pkgsrc/misc/figlet/README.html" target="_top"><code class="filename">misc/figlet</code></a> example.</p> +<p>See <a href="#submit" title="Chapter 19. Submitting and Committing">Chapter 19, <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"> @@ -2543,16 +2548,16 @@ PKG_OPTIONS.apache= suexec </pre> <div class="titlepage"><div><div><h2 class="title" style="clear: both"> <a name="bulkbuild"></a>6.3. Doing a bulk build of all packages</h2></div></div></div> <p>If you want to get a full set of precompiled binary - packages, this section describes how to get them. Beware that - the bulk build will remove all currently installed packages from - your system!</p> + packages, this section describes how to get them. Beware that + the bulk build will remove all currently installed packages from + your system!</p> <p>Having an 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 other machines that can then - save time by installing only the binary packages. See <a href="http://netbsd.gw.com/cgi-bin/man-cgi?ftpd+8+NetBSD-current"><span class="citerefentry"><span class="refentrytitle">ftpd</span>(8)</span></a> for - more information. If you use a remote NFS server's storage, be - sure to not actually compile on NFS storage, as this slows - things down a lot.</p> + machine doing the bulk builds or on a nearby NFS server can help + to make the packages available to other machines that can then + save time by installing only the binary packages. See <a href="http://netbsd.gw.com/cgi-bin/man-cgi?ftpd+8+NetBSD-current"><span class="citerefentry"><span class="refentrytitle">ftpd</span>(8)</span></a> for + more information. If you use a remote NFS server's storage, be + sure to not actually compile on NFS storage, as this slows + things down a lot.</p> <div class="sect2" lang="en"> <div class="titlepage"><div><div><h3 class="title"> <a name="binary.configuration"></a>6.3.1. Configuration</h3></div></div></div> @@ -2560,142 +2565,141 @@ PKG_OPTIONS.apache= suexec </pre> <div class="titlepage"><div><div><h4 class="title"> <a name="binary.bulk.build.conf"></a>6.3.1.1. <code class="filename">build.conf</code></h4></div></div></div> <p>The <code class="filename">build.conf</code> file is the main - configuration file for bulk builds. You can configure how your - copy of pkgsrc is kept up to date, how the distfiles are - downloaded, how the packages are built and how the report is - generated. You can find an annotated example file in - <code class="filename">pkgsrc/mk/bulk/build.conf-example</code>. To use - it, copy <code class="filename">build.conf-example</code> to - <code class="filename">build.conf</code> and edit it, following the - comments in that file.</p> + configuration file for bulk builds. You can configure how your + copy of pkgsrc is kept up to date, how the distfiles are + downloaded, how the packages are built and how the report is + generated. You can find an annotated example file in + <code class="filename">pkgsrc/mk/bulk/build.conf-example</code>. To use + it, copy <code class="filename">build.conf-example</code> to + <code class="filename">build.conf</code> and edit it, following the + comments in that file.</p> </div> <div class="sect3" lang="en"> <div class="titlepage"><div><div><h4 class="title"> <a name="binary.mk.conf"></a>6.3.1.2. /etc/mk.conf</h4></div></div></div> <p>You may want to set variables in - <code class="filename">/etc/mk.conf</code>. - Look at <code class="filename">pkgsrc/mk/defaults/mk.conf</code> for - details of the default settings. You will want to ensure that - <code class="varname">ACCEPTABLE_LICENSES</code> meet your local policy. - As used in this example, <code class="varname">_ACCEPTABLE=yes</code> - accepts <span class="emphasis"><em>all</em></span> licenses.</p> + <code class="filename">/etc/mk.conf</code>. + Look at <code class="filename">pkgsrc/mk/defaults/mk.conf</code> for + details of the default settings. You will want to ensure that + <code class="varname">ACCEPTABLE_LICENSES</code> meet your local policy. + As used in this example, <code class="varname">_ACCEPTABLE=yes</code> + accepts <span class="emphasis"><em>all</em></span> licenses.</p> <pre class="programlisting"> - PACKAGES?= ${_PKGSRCDIR}/packages/${MACHINE_ARCH} - WRKOBJDIR?= /usr/tmp/pkgsrc # build here instead of in pkgsrc - BSDSRCDIR= /usr/src - BSDXSRCDIR= /usr/xsrc # for x11/xservers - OBJHOSTNAME?= yes # use work.`hostname` - FAILOVER_FETCH= yes # insist on the correct checksum - PKG_DEVELOPER?= yes - _ACCEPTABLE= yes -</pre> + 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> <p>Some options that are especially useful for bulk builds can be found at the top lines of the file <code class="filename">mk/bulk/bsd.bulk-pkg.mk</code>. The most useful options of these are briefly described here.</p> <div class="itemizedlist"><ul type="disc"> <li><p>If you are on a slow machine, you may want to - set <code class="varname">USE_BULK_BROKEN_CHECK</code> to - “<span class="quote">no</span>”.</p></li> + set <code class="varname">USE_BULK_BROKEN_CHECK</code> to + “<span class="quote">no</span>”.</p></li> <li><p>If you are doing bulk builds from a read-only - copy of pkgsrc, you have to set <code class="varname">BULKFILESDIR</code> - to the directory where all log files are created. Otherwise the - log files are created in the pkgsrc directory.</p></li> + copy of pkgsrc, you have to set <code class="varname">BULKFILESDIR</code> + to the directory where all log files are created. Otherwise the + log files are created in the pkgsrc directory.</p></li> <li><p>Another important variable is - <code class="varname">BULK_PREREQ</code>, which is a list of packages that - should be always available while building other - packages.</p></li> + <code class="varname">BULK_PREREQ</code>, which is a list of packages that + should be always available while building other + packages.</p></li> </ul></div> <p>Some other options are scattered in the pkgsrc infrastructure:</p> <div class="itemizedlist"><ul type="disc"> <li><p><code class="varname">ALLOW_VULNERABLE_PACKAGES</code> - should be set to <code class="literal">yes</code>. The purpose of the bulk - builds is creating binary packages, no matter if they are - vulnerable or not. When uploading the packages to a public - server, the vulnerable packages will be put into a directory of - their own. Leaving this variable unset would prevent the bulk - build system from even trying to build them, so possible - building errors would not show up.</p></li> + should be set to <code class="literal">yes</code>. The purpose of the bulk + builds is creating binary packages, no matter if they are + vulnerable or not. When uploading the packages to a public + server, the vulnerable packages will be put into a directory of + their own. Leaving this variable unset would prevent the bulk + build system from even trying to build them, so possible + building errors would not show up.</p></li> <li><p><code class="varname">CHECK_FILES</code> - (<code class="filename">pkgsrc/mk/bsd.pkg.check.mk</code>) can be set to - “<span class="quote">yes</span>” to check that the installed set of files - matches the <code class="filename">PLIST</code>.</p></li> + (<code class="filename">pkgsrc/mk/bsd.pkg.check.mk</code>) can be set to + “<span class="quote">yes</span>” to check that the installed set of files + matches the <code class="filename">PLIST</code>.</p></li> <li><p><code class="varname">CHECK_INTERPRETER</code> - (<code class="filename">pkgsrc/mk/bsd.pkg.check.mk</code>) can be set to - “<span class="quote">yes</span>” to check that the installed - “<span class="quote">#!</span>”-scripts will find their - interpreter.</p></li> + (<code class="filename">pkgsrc/mk/bsd.pkg.check.mk</code>) can be set to + “<span class="quote">yes</span>” to check that the installed + “<span class="quote">#!</span>”-scripts will find their + interpreter.</p></li> </ul></div> </div> <div class="sect3" lang="en"> <div class="titlepage"><div><div><h4 class="title"> <a name="pre-build.local"></a>6.3.1.3. <code class="filename">pre-build.local</code></h4></div></div></div> <p>It is possible to configure the bulk build to perform - certain site-specific tasks at the end of the pre-build - stage. If the file - <code class="filename">pre-build.local</code> exists in - <code class="filename">/usr/pkgsrc/mk/bulk</code>, it will be executed - (as a <a href="http://netbsd.gw.com/cgi-bin/man-cgi?sh+1+NetBSD-current"><span class="citerefentry"><span class="refentrytitle">sh</span>(1)</span></a> script) at the end of the usual pre-build - stage. An example use of - <code class="filename">pre-build.local</code> is to have the line:</p> + certain site-specific tasks at the end of the pre-build + stage. If the file + <code class="filename">pre-build.local</code> exists in + <code class="filename">/usr/pkgsrc/mk/bulk</code>, it will be executed + (as a <a href="http://netbsd.gw.com/cgi-bin/man-cgi?sh+1+NetBSD-current"><span class="citerefentry"><span class="refentrytitle">sh</span>(1)</span></a> script) at the end of the usual pre-build + stage. An example use of + <code class="filename">pre-build.local</code> is to have the line:</p> <pre class="screen">echo "I do not have enough disk space to build this pig." \ - > misc/openoffice/$BROKENF</pre> + > misc/openoffice/$BROKENF</pre> <p>to prevent the system from trying to build a particular package - which requires nearly 3 GB of disk space.</p> + 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="other-environmental-considerations"></a>6.3.2. Other environmental considerations</h3></div></div></div> <p>As <code class="filename">/usr/pkg</code> will be completely - deleted at the start of bulk builds, make sure your login - shell is placed somewhere else. Either drop it into - <code class="filename">/usr/local/bin</code> (and adjust your login - shell in the passwd file), or (re-)install it via - <a href="http://netbsd.gw.com/cgi-bin/man-cgi?pkg_add+1+NetBSD-current"><span class="citerefentry"><span class="refentrytitle">pkg_add</span>(1)</span></a> from <code class="filename">/etc/rc.local</code>, so - you can login after a reboot (remember that your current - process won't die if the package is removed, you just can't - start any new instances of the shell any more). Also, if you - use NetBSD earlier than 1.5, or you still want to use the pkgsrc - version of ssh for some reason, be sure to install ssh before - starting it from <code class="filename">rc.local</code>:</p> + deleted at the start of bulk builds, make sure your login + shell is placed somewhere else. Either drop it into + <code class="filename">/usr/local/bin</code> (and adjust your login + shell in the passwd file), or (re-)install it via + <a href="http://netbsd.gw.com/cgi-bin/man-cgi?pkg_add+1+NetBSD-current"><span class="citerefentry"><span class="refentrytitle">pkg_add</span>(1)</span></a> from <code class="filename">/etc/rc.local</code>, so + you can login after a reboot (remember that your current + process won't die if the package is removed, you just can't + start any new instances of the shell any more). Also, if you + use NetBSD earlier than 1.5, or you still want to use the pkgsrc + version of ssh for some reason, be sure to install ssh before + starting it from <code class="filename">rc.local</code>:</p> <pre class="programlisting"> - ( cd /usr/pkgsrc/security/ssh ; make bulk-install ) - if [ -f /usr/pkg/etc/rc.d/sshd ]; then - /usr/pkg/etc/rc.d/sshd - fi -</pre> + ( cd /usr/pkgsrc/security/ssh ; make bulk-install ) + if [ -f /usr/pkg/etc/rc.d/sshd ]; then + /usr/pkg/etc/rc.d/sshd + fi + </pre> <p>Not doing so will result in you being not able to log in - via ssh after the bulk build is finished or if the machine - gets rebooted or crashes. You have been warned! :)</p> + 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="operation"></a>6.3.3. Operation</h3></div></div></div> <p>Make sure you don't need any of the packages still - installed. - </p> + installed.</p> <div class="warning" style="margin-left: 0.5in; margin-right: 0.5in;"> <h3 class="title">Warning</h3> <p>During the bulk build, <span class="emphasis"><em>all packages will be - removed!</em></span></p> + removed!</em></span></p> </div> <p>Be sure to remove all other things that might - interfere with builds, like some libs installed in - <code class="filename">/usr/local</code>, etc. then become root and type:</p> -<pre class="screen"><code class="prompt">#</code> <strong class="userinput"><code>cd /usr/pkgsrc</code></strong> -<code class="prompt">#</code> <strong class="userinput"><code>sh mk/bulk/build</code></strong></pre> + interfere with builds, like some libs installed in + <code class="filename">/usr/local</code>, etc. then become root and type:</p> +<pre class="screen"> +<code class="prompt">#</code> <strong class="userinput"><code>cd /usr/pkgsrc</code></strong> +<code class="prompt">#</code> <strong class="userinput"><code>sh mk/bulk/build</code></strong> + </pre> <p>If for some reason your last build didn't complete (power - failure, system panic, ...), you can continue it by - running:</p> + failure, system panic, ...), you can continue it by + running:</p> <pre class="screen"><code class="prompt">#</code> <strong class="userinput"><code>sh mk/bulk/build restart</code></strong></pre> -<p> - At the end of the bulk build, you will get a summary via mail, - and find build logs in the directory specified by - <code class="varname">FTP</code> in the <code class="filename">build.conf</code> - file. - </p> +<p>At the end of the bulk build, you will get a summary via mail, + and find build logs in the directory specified by + <code class="varname">FTP</code> in the <code class="filename">build.conf</code> + file.</p> </div> <div class="sect2" lang="en"> <div class="titlepage"><div><div><h3 class="title"> @@ -2703,94 +2707,72 @@ PKG_OPTIONS.apache= suexec </pre> <p>The bulk builds consist of three steps:</p> <div class="variablelist"><dl> <dt><span class="term">1. pre-build</span></dt> -<dd><p> - The script updates your pkgsrc tree via (anon)cvs, then - cleans out any broken distfiles, and removes all - packages installed.</p></dd> +<dd><p>The script updates your pkgsrc tree via (anon)cvs, then + cleans out any broken distfiles, and removes all + packages installed.</p></dd> <dt><span class="term">2. the bulk build</span></dt> -<dd><p> - This is basically “<span class="quote">make bulk-package</span>” with - an optimised order in which packages will be - built. Packages that don't require other packages will - be built first, and packages with many dependencies will - be built later. - </p></dd> +<dd><p>This is basically “<span class="quote">make bulk-package</span>” with + an optimised order in which packages will be + built. Packages that don't require other packages will + be built first, and packages with many dependencies will + be built later.</p></dd> <dt><span class="term">3. post-build</span></dt> -<dd><p> - Generates a report that's placed in the directory - specified in the <code class="filename">build.conf</code> file - named <code class="filename">broken.html</code>, a short version - of that report will also be mailed to the build's - admin.</p></dd> +<dd><p>Generates a report that's placed in the directory + specified in the <code class="filename">build.conf</code> file + named <code class="filename">broken.html</code>, a short version + of that report will also be mailed to the build's + admin.</p></dd> </dl></div> -<p> - During the build, a list of broken packages will be compiled - in <code class="filename">/usr/pkgsrc/.broken</code> (or - <code class="filename">.../.broken.${MACHINE}</code> if - <code class="varname">OBJMACHINE</code> is set), individual build logs - of broken builds can be found in the package's - directory. These files are used by the bulk-targets to mark - broken builds to not waste time trying to rebuild them, and - they can be used to debug these broken package builds - later. - </p> +<p>During the build, a list of broken packages will be compiled + in <code class="filename">/usr/pkgsrc/.broken</code> (or + <code class="filename">.../.broken.${MACHINE}</code> if + <code class="varname">OBJMACHINE</code> is set), individual build logs + of broken builds can be found in the package's + directory. These files are used by the bulk-targets to mark + broken builds to not waste time trying to rebuild them, and + they can be used to debug these broken package builds + later.</p> </div> <div class="sect2" lang="en"> <div class="titlepage"><div><div><h3 class="title"> <a name="disk-space-requirements"></a>6.3.5. Disk space requirements</h3></div></div></div> <p>Currently, roughly the following requirements are valid for - NetBSD 2.0/i386:</p> + NetBSD 2.0/i386:</p> <div class="itemizedlist"><ul type="disc"> -<li><p> - 10 GB - distfiles (NFS ok) - </p></li> -<li><p> - 8 GB - full set of all binaries (NFS ok) - </p></li> -<li><p> - 5 GB - temp space for compiling (local disk recommended) - </p></li> +<li><p>10 GB - distfiles (NFS ok)</p></li> +<li><p>8 GB - full set of all binaries (NFS ok)</p></li> +<li><p>5 GB - temp space for compiling (local disk recommended)</p></li> </ul></div> -<p> - Note that all pkgs will be de-installed as soon as they are - turned into a binary package, and that sources are removed, - so there is no excessively huge demand to disk - space. Afterwards, if the package is needed again, it will - be installed via <a href="http://netbsd.gw.com/cgi-bin/man-cgi?pkg_add+1+NetBSD-current"><span class="citerefentry"><span class="refentrytitle">pkg_add</span>(1)</span></a> instead of building again, so - there are no cycles wasted by recompiling. - </p> +<p>Note that all pkgs will be de-installed as soon as they are + turned into a binary package, and that sources are removed, + so there is no excessively huge demand to disk + space. Afterwards, if the package is needed again, it will + be installed via <a href="http://netbsd.gw.com/cgi-bin/man-cgi?pkg_add+1+NetBSD-current"><span class="citerefentry"><span class="refentrytitle">pkg_add</span>(1)</span></a> instead of building again, so + there are no cycles wasted by recompiling.</p> </div> <div class="sect2" lang="en"> <div class="titlepage"><div><div><h3 class="title"> <a name="setting-up-a-sandbox"></a>6.3.6. Setting up a sandbox for chrooted builds</h3></div></div></div> -<p> - If you don't want all the packages nuked from a machine - (rendering it useless for anything but pkg compiling), there - is the possibility of doing the package bulk build inside a - chroot environment. - </p> -<p> - The first step is to set up a chroot sandbox, - e.g. <code class="filename">/usr/sandbox</code>. This can be done by - using null mounts, or manually. - </p> -<p> - There is a shell script called - <code class="filename">pkgsrc/mk/bulk/mksandbox</code> which will set - up the sandbox environment using null mounts. It will also - create a script called <code class="filename">sandbox</code> in the - root of the sandbox environment, which will allow the null - mounts to be activated using the <span><strong class="command">sandbox - mount</strong></span> command and deactivated using the - <span><strong class="command">sandbox umount</strong></span> command. - </p> -<p> - To set up a sandbox environment by hand, after extracting all - the sets from a NetBSD installation or doing a <span><strong class="command">make - distribution DESTDIR=/usr/sandbox</strong></span> in - <code class="filename">/usr/src/etc</code>, be sure the following items - are present and properly configured: - </p> +<p>If you don't want all the packages nuked from a machine + (rendering it useless for anything but pkg compiling), there + is the possibility of doing the package bulk build inside a + chroot environment.</p> +<p>The first step is to set up a chroot sandbox, + e.g. <code class="filename">/usr/sandbox</code>. This can be done by + using null mounts, or manually.</p> +<p>There is a shell script called + <code class="filename">pkgsrc/mk/bulk/mksandbox</code> which will set + up the sandbox environment using null mounts. It will also + create a script called <code class="filename">sandbox</code> in the + root of the sandbox environment, which will allow the null + mounts to be activated using the <span><strong class="command">sandbox + mount</strong></span> command and deactivated using the + <span><strong class="command">sandbox umount</strong></span> command.</p> +<p>To set up a sandbox environment by hand, after extracting all + the sets from a NetBSD installation or doing a <span><strong class="command">make + distribution DESTDIR=/usr/sandbox</strong></span> in + <code class="filename">/usr/src/etc</code>, be sure the following items + are present and properly configured:</p> <div class="procedure"><ol type="1"> <li> <p>Kernel</p> @@ -2814,9 +2796,9 @@ PKG_OPTIONS.apache= suexec </pre> </li> <li> <p><code class="filename">/usr/src</code> (system sources, - e. g. for <a href="ftp://ftp.NetBSD.org/pub/NetBSD/packages/pkgsrc/sysutils/aperture/README.html" target="_top"><code class="filename">sysutils/aperture</code></a>):</p> + e. g. for <a href="ftp://ftp.NetBSD.org/pub/NetBSD/packages/pkgsrc/sysutils/aperture/README.html" target="_top"><code class="filename">sysutils/aperture</code></a>):</p> <pre class="screen"><code class="prompt">#</code> <strong class="userinput"><code>ln -s ../disk1/cvs .</code></strong> -<code class="prompt">#</code> <strong class="userinput"><code>ln -s cvs/src-2.0 src</code></strong></pre> + <code class="prompt">#</code> <strong class="userinput"><code>ln -s cvs/src-2.0 src</code></strong></pre> </li> <li> <p>Create <code class="filename">/var/db/pkg</code> (not part of default install):</p> @@ -2828,198 +2810,175 @@ PKG_OPTIONS.apache= suexec </pre> </li> <li> <p>Checkout pkgsrc via cvs into - <code class="filename">/usr/sandbox/usr/pkgsrc</code>:</p> -<pre class="screen"><code class="prompt">#</code> <strong class="userinput"><code>cd /usr/sandbox/usr</code></strong> -<code class="prompt">#</code> <strong class="userinput"><code>cvs -d anoncvs@anoncvs.NetBSD.org:/cvsroot checkout -d -P pkgsrc</code></strong></pre> + <code class="filename">/usr/sandbox/usr/pkgsrc</code>:</p> +<pre class="screen"> +<code class="prompt">#</code> <strong class="userinput"><code>cd /usr/sandbox/usr</code></strong> +<code class="prompt">#</code> <strong class="userinput"><code>cvs -d anoncvs@anoncvs.NetBSD.org:/cvsroot checkout -d -P pkgsrc</code></strong> + </pre> <p>Do not mount/link this to the copy of your pkgsrc tree - you do development in, as this will likely cause problems! - </p> + you do development in, as this will likely cause problems!</p> </li> <li><p>Make - <code class="filename">/usr/sandbox/usr/pkgsrc/packages</code> and - <code class="filename">.../distfiles</code> point somewhere - appropriate. NFS- and/or nullfs-mounts may come in handy! - </p></li> + <code class="filename">/usr/sandbox/usr/pkgsrc/packages</code> and + <code class="filename">.../distfiles</code> point somewhere + appropriate. NFS- and/or nullfs-mounts may come in handy!</p></li> <li><p>Edit <code class="filename">/etc/mk.conf</code>, see <a href="#binary.mk.conf" title="6.3.1.2. /etc/mk.conf">Section 6.3.1.2, “/etc/mk.conf”</a>.</p></li> <li><p>Adjust <code class="filename">mk/bulk/build.conf</code> to suit your needs.</p></li> </ol></div> <p>When the chroot sandbox is set up, you can start - the build with the following steps:</p> -<pre class="screen"><code class="prompt">#</code> <strong class="userinput"><code>cd /usr/sandbox/usr/pkgsrc</code></strong> -<code class="prompt">#</code> <strong class="userinput"><code>sh mk/bulk/do-sandbox-build</code></strong></pre> -<p> - This will just jump inside the sandbox and start building. At - the end of the build, mail will be sent with the results of - the build. Created binary pkgs will be in - <code class="filename">/usr/sandbox/usr/pkgsrc/packages</code> - (wherever that points/mounts to/from).</p> + the build with the following steps:</p> +<pre class="screen"> +<code class="prompt">#</code> <strong class="userinput"><code>cd /usr/sandbox/usr/pkgsrc</code></strong> +<code class="prompt">#</code> <strong class="userinput"><code>sh mk/bulk/do-sandbox-build</code></strong> + </pre> +<p>This will just jump inside the sandbox and start building. At + the end of the build, mail will be sent with the results of + the build. Created binary pkgs will be in + <code class="filename">/usr/sandbox/usr/pkgsrc/packages</code> + (wherever that points/mounts to/from).</p> </div> <div class="sect2" lang="en"> <div class="titlepage"><div><div><h3 class="title"> <a name="building-a-partial-set"></a>6.3.7. Building a partial set of packages</h3></div></div></div> -<p> In addition to building a complete set of all packages in - pkgsrc, the <code class="filename">pkgsrc/mk/bulk/build</code> script - may be used to build a subset of the packages contained in - pkgsrc. By setting <code class="varname">SPECIFIC_PKGS</code> - in <code class="filename">/etc/mk.conf</code>, the variables</p> +<p>In addition to building a complete set of all packages in + pkgsrc, the <code class="filename">pkgsrc/mk/bulk/build</code> script + may be used to build a subset of the packages contained in + pkgsrc. By setting <code class="varname">SPECIFIC_PKGS</code> + in <code class="filename">/etc/mk.conf</code>, the variables</p> <div class="itemizedlist"><ul type="disc"> <li><p>SITE_SPECIFIC_PKGS</p></li> <li><p>HOST_SPECIFIC_PKGS</p></li> <li><p>GROUP_SPECIFIC_PKGS</p></li> <li><p>USER_SPECIFIC_PKGS</p></li> </ul></div> -<p> will define the set of packages which should be built. - The bulk build code will also include any packages which are - needed as dependencies for the explicitly listed packages. - </p> -<p> One use of this is to do a bulk build with - <code class="varname">SPECIFIC_PKGS</code> in a chroot sandbox - periodically to have a complete set of the binary packages - needed for your site available without the overhead of - building extra packages that are not needed. </p> +<p>will define the set of packages which should be built. + The bulk build code will also include any packages which are + needed as dependencies for the explicitly listed packages.</p> +<p>One use of this is to do a bulk build with + <code class="varname">SPECIFIC_PKGS</code> in a chroot sandbox + periodically to have a complete set of the binary packages + needed for your site available without the overhead of + building extra packages that are not needed.</p> </div> <div class="sect2" lang="en"> <div class="titlepage"><div><div><h3 class="title"> <a name="bulk-upload"></a>6.3.8. Uploading results of a bulk build</h3></div></div></div> -<p> - This section describes how pkgsrc developers can upload binary - pkgs built by bulk builds to ftp.NetBSD.org. - </p> -<p> - If you would like to automatically create checksum files for the - binary packages you intend to upload, remember to set - <code class="varname">MKSUMS=yes</code> in your - <code class="filename">mk/bulk/build.conf</code>. - </p> -<p> - If you would like to PGP sign the checksum files (highly - recommended!), remember to set - <code class="varname">SIGN_AS=username@NetBSD.org</code> in your - <code class="filename">mk/bulk/build.conf</code>. This will prompt you for - your GPG password to sign the files before uploading everything. - </p> -<p> - Then, make sure that you have <code class="varname">RSYNC_DST</code> - set properly in your <code class="filename">mk/bulk/build.conf</code> - file, i.e. adjust it to something like one of the following: - </p> +<p>This section describes how pkgsrc developers can upload binary + pkgs built by bulk builds to ftp.NetBSD.org.</p> +<p>If you would like to automatically create checksum files for the + binary packages you intend to upload, remember to set + <code class="varname">MKSUMS=yes</code> in your + <code class="filename">mk/bulk/build.conf</code>.</p> +<p>If you would like to PGP sign the checksum files (highly + recommended!), remember to set + <code class="varname">SIGN_AS=username@NetBSD.org</code> in your + <code class="filename">mk/bulk/build.conf</code>. This will prompt you for + your GPG password to sign the files before uploading everything.</p> +<p>Then, make sure that you have <code class="varname">RSYNC_DST</code> + set properly in your <code class="filename">mk/bulk/build.conf</code> + file, i.e. adjust it to something like one of the following:</p> <pre class="screen">RSYNC_DST=ftp.NetBSD.org:/pub/NetBSD/packages/pkgsrc-200xQy/NetBSD-a.b.c/arch/upload </pre> <p>Please use appropriate values for "pkgsrc-200xQy", - "NetBSD-a.b.c" and "arch" here. If your login on ftp.NetBSD.org - is different from your local login, write your login directly - into the variable, e.g. my local account is "feyrer", but for my - login "hubertf", I use:</p> -<pre class="screen">RSYNC_DST=hubertf@ftp.NetBSD.org:/pub/NetBSD/packages/pkgsrc-200xQy/NetBSD-a.b.c/arch/upload </pre> -<p> - A separate <code class="filename">upload</code> directory is used - here to allow "closing" the directory during upload. To do - so, run the following command on ftp.NetBSD.org next: - </p> + "NetBSD-a.b.c" and "arch" here. If your login on ftp.NetBSD.org + is different from your local login, write your login directly + into the variable, e.g. my local account is "feyrer", but for my + login "hubertf", I use:</p> +<pre class="screen">RSYNC_DST=hubertf@ftp.NetBSD.org:/pub/NetBSD/packages/pkgsrc-200xQy/NetBSD-a.b.c/arch/upload</pre> +<p>A separate <code class="filename">upload</code> directory is used + here to allow "closing" the directory during upload. To do + so, run the following command on ftp.NetBSD.org next:</p> <pre class="screen">nbftp% <strong class="userinput"><code>mkdir -p -m 750 /pub/NetBSD/packages/pkgsrc-200xQy/NetBSD-a.b.c/arch/upload</code></strong></pre> -<p> - Please note that <code class="filename">/pub/NetBSD/packages</code> is - only appropriate for packages for the NetBSD operating - system. Binary packages for other operating systems should go - into <code class="filename">/pub/pkgsrc</code>. - </p> -<p> - Before uploading the binary pkgs, ssh authentication needs to - be set up. This example shows how to set up temporary keys - for the root account <span class="emphasis"><em>inside the sandbox</em></span> - (assuming that no keys should be present there usually): - </p> -<pre class="screen"><code class="prompt">#</code> <strong class="userinput"><code>chroot /usr/sandbox</code></strong> +<p>Please note that <code class="filename">/pub/NetBSD/packages</code> is + only appropriate for packages for the NetBSD operating + system. Binary packages for other operating systems should go + into <code class="filename">/pub/pkgsrc</code>.</p> +<p>Before uploading the binary pkgs, ssh authentication needs + to be set up. This example shows how to set up temporary keys + for the root account <span class="emphasis"><em>inside the sandbox</em></span> + (assuming that no keys should be present there usually):</p> +<pre class="screen"> +<code class="prompt">#</code> <strong class="userinput"><code>chroot /usr/sandbox</code></strong> chroot-<code class="prompt">#</code> <strong class="userinput"><code>rm $HOME/.ssh/id-dsa*</code></strong> chroot-<code class="prompt">#</code> <strong class="userinput"><code>ssh-keygen -t dsa</code></strong> -chroot-<code class="prompt">#</code> <strong class="userinput"><code>cat $HOME/.ssh/id-dsa.pub</code></strong> </pre> -<p> - Now take the output of <code class="filename">id-dsa.pub</code> and - append it to your <code class="filename">~/.ssh/authorized_keys</code> - file on ftp.NetBSD.org. You can remove the key after the - upload is done! - </p> -<p> - Next, test if your ssh connection really works: - </p> +chroot-<code class="prompt">#</code> <strong class="userinput"><code>cat $HOME/.ssh/id-dsa.pub</code></strong> + </pre> +<p>Now take the output of <code class="filename">id-dsa.pub</code> and + append it to your <code class="filename">~/.ssh/authorized_keys</code> + file on ftp.NetBSD.org. You can remove the key after the + upload is done!</p> +<p>Next, test if your ssh connection really works:</p> <pre class="screen">chroot-<code class="prompt">#</code> <strong class="userinput"><code>ssh ftp.NetBSD.org date</code></strong> </pre> -<p> - Use "-l yourNetBSDlogin" here as appropriate! - </p> -<p> - Now after all this works, you can exit the sandbox and start - the upload: - </p> -<pre class="screen">chroot-<code class="prompt">#</code> <strong class="userinput"><code>exit</code></strong> +<p>Use "-l yourNetBSDlogin" here as appropriate!</p> +<p>Now after all this works, you can exit the sandbox and start + the upload:</p> +<pre class="screen"> +chroot-<code class="prompt">#</code> <strong class="userinput"><code>exit</code></strong> <code class="prompt">#</code> <strong class="userinput"><code>cd /usr/sandbox/usr/pkgsrc</code></strong> -<code class="prompt">#</code> <strong class="userinput"><code>sh mk/bulk/do-sandbox-upload</code></strong> </pre> -<p> - The upload process may take quite some time. Use <a href="http://netbsd.gw.com/cgi-bin/man-cgi?ls+1+NetBSD-current"><span class="citerefentry"><span class="refentrytitle">ls</span>(1)</span></a> or - <a href="http://netbsd.gw.com/cgi-bin/man-cgi?du+1+NetBSD-current"><span class="citerefentry"><span class="refentrytitle">du</span>(1)</span></a> on the FTP server to monitor progress of the - upload. The upload script will take care of not uploading - restricted packages and putting vulnerable packages into the - <code class="filename">vulnerable</code> subdirectory. - </p> -<p> - After the upload has ended, first thing is to revoke ssh access: - </p> +<code class="prompt">#</code> <strong class="userinput"><code>sh mk/bulk/do-sandbox-upload</code></strong> + </pre> +<p>The upload process may take quite some time. Use <a href="http://netbsd.gw.com/cgi-bin/man-cgi?ls+1+NetBSD-current"><span class="citerefentry"><span class="refentrytitle">ls</span>(1)</span></a> or + <a href="http://netbsd.gw.com/cgi-bin/man-cgi?du+1+NetBSD-current"><span class="citerefentry"><span class="refentrytitle">du</span>(1)</span></a> on the FTP server to monitor progress of the + upload. The upload script will take care of not uploading + restricted packages and putting vulnerable packages into the + <code class="filename">vulnerable</code> subdirectory.</p> +<p>After the upload has ended, first thing is to revoke ssh access:</p> <pre class="screen">nbftp% <strong class="userinput"><code>vi ~/.ssh/authorized_keys</code></strong> -Gdd:x! </pre> -<p> - Use whatever is needed to remove the key you've entered - before! Last, move the uploaded packages out of the - <code class="filename">upload</code> directory to have them accessible - to everyone: - </p> -<pre class="screen">nbftp% <strong class="userinput"><code>cd /pub/NetBSD/packages/pkgsrc-200xQy/NetBSD-a.b.c/arch</code></strong> + Gdd:x! </pre> +<p>Use whatever is needed to remove the key you've entered + before! Last, move the uploaded packages out of the + <code class="filename">upload</code> directory to have them accessible + to everyone:</p> +<pre class="screen"> +nbftp% <strong class="userinput"><code>cd /pub/NetBSD/packages/pkgsrc-200xQy/NetBSD-a.b.c/arch</code></strong> nbftp% <strong class="userinput"><code>mv upload/* .</code></strong> nbftp% <strong class="userinput"><code>rmdir upload</code></strong> -nbftp% <strong class="userinput"><code>chmod 755 .</code></strong> </pre> +nbftp% <strong class="userinput"><code>chmod 755 .</code></strong> + </pre> </div> </div> <div class="sect1" lang="en"> <div class="titlepage"><div><div><h2 class="title" style="clear: both"> <a name="creating-cdroms"></a>6.4. Creating a multiple CD-ROM packages collection</h2></div></div></div> -<p> - After your pkgsrc bulk-build has completed, you may wish to - create a CD-ROM set of the resulting binary packages to assist - in installing packages on other machines. The - <a href="ftp://ftp.NetBSD.org/pub/NetBSD/packages/pkgsrc/pkgtools/cdpack/README.html" target="_top"><code class="filename">pkgtools/cdpack</code></a> package provides - a simple tool for creating the ISO 9660 images. - <span><strong class="command">cdpack</strong></span> arranges the packages on the CD-ROMs in a - way that keeps all the dependencies for a given package on the same - CD as that package. - </p> +<p>After your pkgsrc bulk-build has completed, you may wish to + create a CD-ROM set of the resulting binary packages to assist + in installing packages on other machines. The + <a href="ftp://ftp.NetBSD.org/pub/NetBSD/packages/pkgsrc/pkgtools/cdpack/README.html" target="_top"><code class="filename">pkgtools/cdpack</code></a> package provides + a simple tool for creating the ISO 9660 images. + <span><strong class="command">cdpack</strong></span> arranges the packages on the CD-ROMs in a + way that keeps all the dependencies for a 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="cdpack-example"></a>6.4.1. Example of cdpack</h3></div></div></div> -<p> - Complete documentation for cdpack is found in the cdpack(1) - man page. The following short example assumes that the binary - packages are left in - <code class="filename">/usr/pkgsrc/packages/All</code> and that - sufficient disk space exists in <code class="filename">/u2</code> to - hold the ISO 9660 images.</p> -<pre class="screen"><code class="prompt">#</code> <strong class="userinput"><code>mkdir /u2/images</code></strong> +<p>Complete documentation for cdpack is found in the cdpack(1) + man page. The following short example assumes that the binary + packages are left in + <code class="filename">/usr/pkgsrc/packages/All</code> and that + sufficient disk space exists in <code class="filename">/u2</code> to + hold the ISO 9660 images.</p> +<pre class="screen"> +<code class="prompt">#</code> <strong class="userinput"><code>mkdir /u2/images</code></strong> <code class="prompt">#</code> <strong class="userinput"><code>pkg_add /usr/pkgsrc/packages/All/cdpack</code></strong> -<code class="prompt">#</code> <strong class="userinput"><code>cdpack /usr/pkgsrc/packages/All /u2/images</code></strong></pre> -<p> - If you wish to include a common set of files - (<code class="filename">COPYRIGHT</code>, <code class="filename">README</code>, - etc.) on each CD in the collection, then you need to create a - directory which contains these files. e.g. - </p> -<pre class="screen"><code class="prompt">#</code> <strong class="userinput"><code>mkdir /tmp/common</code></strong> +<code class="prompt">#</code> <strong class="userinput"><code>cdpack /usr/pkgsrc/packages/All /u2/images</code></strong> + </pre> +<p>If you wish to include a common set of files + (<code class="filename">COPYRIGHT</code>, <code class="filename">README</code>, + etc.) on each CD in the collection, then you need to create a + directory which contains these files. e.g.</p> +<pre class="screen"> +<code class="prompt">#</code> <strong class="userinput"><code>mkdir /tmp/common</code></strong> <code class="prompt">#</code> <strong class="userinput"><code>echo "This is a README" > /tmp/common/README</code></strong> <code class="prompt">#</code> <strong class="userinput"><code>echo "Another file" > /tmp/common/COPYING</code></strong> <code class="prompt">#</code> <strong class="userinput"><code>mkdir /tmp/common/bin</code></strong> <code class="prompt">#</code> <strong class="userinput"><code>echo "#!/bin/sh" > /tmp/common/bin/myscript</code></strong> <code class="prompt">#</code> <strong class="userinput"><code>echo "echo Hello world" >> /tmp/common/bin/myscript</code></strong> -<code class="prompt">#</code> <strong class="userinput"><code>chmod 755 /tmp/common/bin/myscript</code></strong></pre> +<code class="prompt">#</code> <strong class="userinput"><code>chmod 755 /tmp/common/bin/myscript</code></strong> + </pre> <p>Now create the images:</p> <pre class="screen"><code class="prompt">#</code> <strong class="userinput"><code>cdpack -x /tmp/common /usr/pkgsrc/packages/All /u2/images</code></strong></pre> <p>Each image will contain <code class="filename">README</code>, - <code class="filename">COPYING</code>, and <code class="filename">bin/myscript</code> - in their root directories.</p> + <code class="filename">COPYING</code>, and <code class="filename">bin/myscript</code> + in their root directories.</p> </div> </div> </div> @@ -3108,8 +3067,7 @@ with each package.</p> <li><p><a href="ftp://ftp.NetBSD.org/pub/NetBSD/packages/pkgsrc/pkgtools/libnbcompat/README.html" target="_top"><code class="filename">pkgtools/libnbcompat</code></a>: Compatibility library for pkgsrc tools.</p></li> <li><p><a href="ftp://ftp.NetBSD.org/pub/NetBSD/packages/pkgsrc/pkgtools/mtree/README.html" target="_top"><code class="filename">pkgtools/mtree</code></a>: Installed on - non-BSD systems due to lack of native mtree. - </p></li> + non-BSD systems due to lack of native mtree.</p></li> <li><p><a href="ftp://ftp.NetBSD.org/pub/NetBSD/packages/pkgsrc/pkgtools/pkg_install/README.html" target="_top"><code class="filename">pkgtools/pkg_install</code></a>: Up-to-date replacement for <code class="filename">/usr/sbin/pkg_install</code>, or for use on operating @@ -3237,8 +3195,7 @@ you will have to add the following line into <div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"> <h3 class="title">Note</h3> <p>The DragonFly operating system defaults to using -this X.org X11 implementation from pkgsrc. -</p> +this X.org X11 implementation from pkgsrc.</p> </div> </div> <div class="sect1" lang="en"> @@ -3325,7 +3282,7 @@ environment or in <code class="filename">/etc/mk.conf</code>.</p> <div class="sect1" lang="en"> <div class="titlepage"><div><div><h2 class="title" style="clear: both"> <a name="bsd.own.mk-missing"></a>7.12. What does “<span class="quote">Could not find bsd.own.mk</span>” mean?</h2></div></div></div> -<p> You didn't install the compiler set, <code class="filename">comp.tgz</code>, +<p>You didn't install the compiler set, <code class="filename">comp.tgz</code>, when you installed your NetBSD machine. Please get and install it, by extracting it in <code class="filename">/</code>:</p> <pre class="screen"><code class="prompt">#</code> <strong class="userinput"><code>cd /</code></strong> @@ -3402,10 +3359,9 @@ package is strongly recommended! After “<span class="quote">audit-packages</span>” is installed, please read the package's message, which you can get by running <strong class="userinput"><code>pkg_info -D audit-packages</code></strong>.</p> -<p>If this package is installed, pkgsrc builds will use it to perform -a security check before building any package. See -<a href="#variables-affecting-build" title="5.2. Variables affecting the build process">Section 5.2, “Variables affecting the build process”</a> for ways to control this check. -</p> +<p>If this package is installed, pkgsrc builds will use it to +perform a security check before building any package. See <a href="#variables-affecting-build" title="5.2. Variables affecting the build process">Section 5.2, “Variables affecting the build process”</a> for ways to control this +check.</p> </div> <div class="sect1" lang="en"> <div class="titlepage"><div><div><h2 class="title" style="clear: both"> @@ -3607,34 +3563,44 @@ a security check before building any package. See <dt><span class="sect2"><a href="#using-libtool">17.3.2. Using libtool on GNU packages that already support libtool</a></span></dt> <dt><span class="sect2"><a href="#autoconf-automake">17.3.3. GNU Autoconf/Automake</a></span></dt> </dl></dd> -<dt><span class="sect1"><a href="#fixes.build">17.4. Fixing problems in the <span class="emphasis"><em>build</em></span> phase</a></span></dt> +<dt><span class="sect1"><a href="#programming-languages">17.4. Programming languages</a></span></dt> <dd><dl> -<dt><span class="sect2"><a href="#fixes.build.cpp">17.4.1. Compiling C and C++ code conditionally</a></span></dt> -<dt><span class="sect2"><a href="#compiler-bugs">17.4.2. How to handle compiler bugs</a></span></dt> -<dt><span class="sect2"><a href="#undefined-reference">17.4.3. Undefined reference to “<span class="quote">...</span>”</a></span></dt> +<dt><span class="sect2"><a href="#basic-programming-languages">17.4.1. C, C++, and Fortran</a></span></dt> +<dt><span class="sect2"><a href="#java-programming-language">17.4.2. Java</a></span></dt> +<dt><span class="sect2"><a href="#perl-scripts">17.4.3. Packages containing perl scripts</a></span></dt> +<dt><span class="sect2"><a href="#other-programming-languages">17.4.4. Other programming languages</a></span></dt> </dl></dd> -<dt><span class="sect1"><a href="#fixes.install">17.5. Fixing problems in the <span class="emphasis"><em>install</em></span> phase</a></span></dt> +<dt><span class="sect1"><a href="#fixes.build">17.5. Fixing problems in the <span class="emphasis"><em>build</em></span> phase</a></span></dt> <dd><dl> -<dt><span class="sect2"><a href="#install-scripts">17.5.1. Creating needed directories</a></span></dt> -<dt><span class="sect2"><a href="#where-to-install-documentation">17.5.2. Where to install documentation</a></span></dt> -<dt><span class="sect2"><a href="#installing-score-files">17.5.3. Installing score files</a></span></dt> -<dt><span class="sect2"><a href="#perl-scripts">17.5.4. Packages containing perl scripts</a></span></dt> -<dt><span class="sect2"><a href="#hardcoded-paths">17.5.5. Packages with hardcoded paths to other interpreters</a></span></dt> -<dt><span class="sect2"><a href="#perl-modules">17.5.6. Packages installing perl modules</a></span></dt> -<dt><span class="sect2"><a href="#faq.info-files">17.5.7. Packages installing info files</a></span></dt> -<dt><span class="sect2"><a href="#manpages">17.5.8. Packages installing man pages</a></span></dt> -<dt><span class="sect2"><a href="#gconf2-data-files">17.5.9. Packages installing GConf2 data files</a></span></dt> -<dt><span class="sect2"><a href="#scrollkeeper-data-files">17.5.10. Packages installing scrollkeeper data files</a></span></dt> -<dt><span class="sect2"><a href="#x11-fonts">17.5.11. Packages installing X11 fonts</a></span></dt> -<dt><span class="sect2"><a href="#gtk2-modules">17.5.12. Packages installing GTK2 modules</a></span></dt> -<dt><span class="sect2"><a href="#sgml-xml-data">17.5.13. Packages installing SGML or XML data</a></span></dt> -<dt><span class="sect2"><a href="#mime-database">17.5.14. Packages installing extensions to the MIME database</a></span></dt> -<dt><span class="sect2"><a href="#intltool">17.5.15. Packages using intltool</a></span></dt> -<dt><span class="sect2"><a href="#startup-scripts">17.5.16. Packages installing startup scripts</a></span></dt> -<dt><span class="sect2"><a href="#tex-packages">17.5.17. Packages installing TeX modules</a></span></dt> -<dt><span class="sect2"><a href="#hicolor-theme">17.5.18. Packages installing hicolor theme icons</a></span></dt> -<dt><span class="sect2"><a href="#desktop-files">17.5.19. Packages installing desktop files</a></span></dt> +<dt><span class="sect2"><a href="#fixes.build.cpp">17.5.1. Compiling C and C++ code conditionally</a></span></dt> +<dt><span class="sect2"><a href="#compiler-bugs">17.5.2. How to handle compiler bugs</a></span></dt> +<dt><span class="sect2"><a href="#undefined-reference">17.5.3. Undefined reference to “<span class="quote">...</span>”</a></span></dt> +<dt><span class="sect2"><a href="#out-of-memory">17.5.4. Running out of memory</a></span></dt> </dl></dd> +<dt><span class="sect1"><a href="#fixes.install">17.6. Fixing problems in the <span class="emphasis"><em>install</em></span> phase</a></span></dt> +<dd><dl> +<dt><span class="sect2"><a href="#install-scripts">17.6.1. Creating needed directories</a></span></dt> +<dt><span class="sect2"><a href="#where-to-install-documentation">17.6.2. Where to install documentation</a></span></dt> +<dt><span class="sect2"><a href="#installing-score-files">17.6.3. Installing score files</a></span></dt> +<dt><span class="sect2"><a href="#hardcoded-paths">17.6.4. Packages with hardcoded paths to other interpreters</a></span></dt> +<dt><span class="sect2"><a href="#perl-modules">17.6.5. Packages installing perl modules</a></span></dt> +<dt><span class="sect2"><a href="#faq.info-files">17.6.6. Packages installing info files</a></span></dt> +<dt><span class="sect2"><a href="#manpages">17.6.7. Packages installing man pages</a></span></dt> +<dt><span class="sect2"><a href="#gconf2-data-files">17.6.8. Packages installing GConf2 data files</a></span></dt> +<dt><span class="sect2"><a href="#scrollkeeper-data-files">17.6.9. Packages installing scrollkeeper data files</a></span></dt> +<dt><span class="sect2"><a href="#x11-fonts">17.6.10. Packages installing X11 fonts</a></span></dt> +<dt><span class="sect2"><a href="#gtk2-modules">17.6.11. Packages installing GTK2 modules</a></span></dt> +<dt><span class="sect2"><a href="#sgml-xml-data">17.6.12. Packages installing SGML or XML data</a></span></dt> +<dt><span class="sect2"><a href="#mime-database">17.6.13. Packages installing extensions to the MIME database</a></span></dt> +<dt><span class="sect2"><a href="#intltool">17.6.14. Packages using intltool</a></span></dt> +<dt><span class="sect2"><a href="#startup-scripts">17.6.15. Packages installing startup scripts</a></span></dt> +<dt><span class="sect2"><a href="#tex-packages">17.6.16. Packages installing TeX modules</a></span></dt> +<dt><span class="sect2"><a href="#emulation-packages">17.6.17. Packages supporting running binaries in + emulation</a></span></dt> +<dt><span class="sect2"><a href="#hicolor-theme">17.6.18. Packages installing hicolor theme icons</a></span></dt> +<dt><span class="sect2"><a href="#desktop-files">17.6.19. Packages installing desktop files</a></span></dt> +</dl></dd> +<dt><span class="sect1"><a href="#punting">17.7. Marking packages as having problems</a></span></dt> </dl></dd> <dt><span class="chapter"><a href="#debug">18. Debugging</a></span></dt> <dt><span class="chapter"><a href="#submit">19. Submitting and Committing</a></span></dt> @@ -3765,212 +3731,237 @@ a security check before building any package. See <dt><span class="sect1"><a href="#files-dir">9.7. <code class="filename">files/*</code></a></span></dt> </dl> </div> -<p> Whenever you're preparing a package, there are a number of - files involved which are described in the following - sections. </p> +<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>9.1. <code class="filename">Makefile</code></h2></div></div></div> <p>Building, installation and creation of a binary package are all - controlled by the package's <code class="filename">Makefile</code>. - The <code class="filename">Makefile</code> describes various things about - a package, for example from where to get it, how to configure, - build, and install it. - </p> + controlled by the package's <code class="filename">Makefile</code>. + The <code class="filename">Makefile</code> describes various things about + a package, for example from where to get it, how to configure, + build, and install it.</p> <p>A package <code class="filename">Makefile</code> contains several - sections that describe the package.</p> + sections that describe the package.</p> <p>In the first section there are the following variables, which - should appear exactly in the order given here. The ordering and - grouping of variables is mostly historical and has no further - meaning.</p> + should appear exactly in the order given here. The order and + grouping of the variables is mostly historical and has no further + meaning.</p> <div class="itemizedlist"><ul type="disc"> <li><p><code class="varname">DISTNAME</code> is the basename of the - distribution file to be downloaded from the package's - website.</p></li> + distribution file to be downloaded from the package's + website.</p></li> <li><p><code class="varname">PKGNAME</code> is the name of the - package, as used by pkgsrc. You only need to provide it if it - differs from <code class="varname">DISTNAME</code>. Usually it is the directory name together - with the version number. It must match the regular expression - <code class="varname">^[A-Za-z0-9][A-Za-z0-9-_.+]*$</code>, that is, it - starts with a letter or digit, and contains only letters, digits, - dashes, underscores, dots and plus signs.</p></li> + package, as used by pkgsrc. You only need to provide it if + <code class="varname">DISTNAME</code> (which is the default) is not a good + name for the package in pkgsrc. Usually it is the pkgsrc + directory name together with the version number. It must match the + regular expression + <code class="varname">^[A-Za-z0-9][A-Za-z0-9-_.+]*$</code>, that is, it + starts with a letter or digit, and contains only letters, digits, + dashes, underscores, dots and plus signs.</p></li> +<li><p><code class="varname">SVR4_PKGNAME</code> is the name of + the package file to create if the <code class="varname">PKGNAME</code> + isn't unique on a SVR4 system. The default is + <code class="varname">PKGNAME</code>, which may be shortened when you use + <a href="ftp://ftp.NetBSD.org/pub/NetBSD/packages/pkgsrc/pkgtools/gensolpkg/README.html" target="_top"><code class="filename">pkgtools/gensolpkg</code></a>. Only add + <code class="varname">SVR4_PKGNAME</code> if <code class="varname">PKGNAME</code> + does not produce an unique package name on a SVR4 system. + The length of <code class="varname">SVR4_PKGNAME</code> is limited to 5 + characters.</p></li> <li> <p><code class="varname">CATEGORIES</code> is a list of categories - which the package fits in. You can choose any of the top-level - directories of pkgsrc for it.</p> + which the package fits in. You can choose any of the top-level + directories of pkgsrc for it.</p> <p>Currently the following values are available for - <code class="varname">CATEGORIES</code>. If more than - one is used, they need to be separated by spaces:</p> + <code class="varname">CATEGORIES</code>. If more than + one is used, they need to be separated by spaces:</p> <pre class="programlisting"> - archivers cross geography meta-pkgs security - audio databases graphics misc shells - benchmarks devel ham multimedia sysutils - biology editors inputmethod net textproc - cad emulators lang news time - chat finance mail parallel wm - comms fonts math pkgtools www - converters games mbone print x11 -</pre> + archivers cross geography meta-pkgs security + audio databases graphics misc shells + benchmarks devel ham multimedia sysutils + biology editors inputmethod net textproc + cad emulators lang news time + chat finance mail parallel wm + comms fonts math pkgtools www + converters games mbone print x11 + </pre> </li> <li><p><code class="varname">MASTER_SITES</code>, - <code class="varname">DYNAMIC_MASTER_SITES</code>, - <code class="varname">DIST_SUBDIR</code>, <code class="varname">EXTRACT_SUFX</code> - and <code class="varname">DISTFILES</code> are discussed in detail in - <a href="#build.fetch" title="15.5. The fetch phase">Section 15.5, “The <span class="emphasis"><em>fetch</em></span> phase”</a>.</p></li> + <code class="varname">DYNAMIC_MASTER_SITES</code>, + <code class="varname">DIST_SUBDIR</code>, <code class="varname">EXTRACT_SUFX</code> + and <code class="varname">DISTFILES</code> are discussed in detail in + <a href="#build.fetch" title="15.5. The fetch phase">Section 15.5, “The <span class="emphasis"><em>fetch</em></span> phase”</a>.</p></li> </ul></div> <p>The second section contains information about separately - downloaded patches, if any. - </p> + downloaded patches, if any. + </p> <div class="itemizedlist"><ul type="disc"> <li><p><code class="varname">PATCHFILES:</code> - Name(s) of additional files that contain distribution patches. - There is no default. pkgsrc will look for them at - <code class="varname">PATCH_SITES</code>. - They will automatically be uncompressed before patching if - the names end with <code class="filename">.gz</code> or - <code class="filename">.Z</code>.</p></li> + Name(s) of additional files that contain distribution patches. + There is no default. pkgsrc will look for them at + <code class="varname">PATCH_SITES</code>. + They will automatically be uncompressed before patching if + the names end with <code class="filename">.gz</code> or + <code class="filename">.Z</code>.</p></li> <li><p><code class="varname">PATCH_SITES</code>: - Primary location(s) for distribution patch files (see - <code class="varname">PATCHFILES</code> below) if not found locally.</p></li> + Primary location(s) for distribution patch files (see + <code class="varname">PATCHFILES</code> below) if not found locally.</p></li> </ul></div> -<p> - </p> <p>The third section contains the following variables. - </p> + </p> <div class="itemizedlist"><ul type="disc"> <li><p><code class="varname">MAINTAINER</code> is the email address - of the person who feels responsible for this package, and who is - most likely to look at problems or questions regarding this - package which have been reported with <a href="http://netbsd.gw.com/cgi-bin/man-cgi?send-pr+1+NetBSD-current"><span class="citerefentry"><span class="refentrytitle">send-pr</span>(1)</span></a>. Other - developers should contact the <code class="varname">MAINTAINER</code> before - making major changes to the package. When packaging a new program, - set <code class="varname">MAINTAINER</code> to yourself. If you really can't - maintain the package for future updates, set it to - <code class="email"><<a href="mailto:pkgsrc-users@NetBSD.org">pkgsrc-users@NetBSD.org</a>></code>.</p></li> + of the person who feels responsible for this package, and who is + most likely to look at problems or questions regarding this + package which have been reported with <a href="http://netbsd.gw.com/cgi-bin/man-cgi?send-pr+1+NetBSD-current"><span class="citerefentry"><span class="refentrytitle">send-pr</span>(1)</span></a>. Other + developers should contact the <code class="varname">MAINTAINER</code> before + making major changes to the package. When packaging a new program, + set <code class="varname">MAINTAINER</code> to yourself. If you really can't + maintain the package for future updates, set it to + <code class="email"><<a href="mailto:pkgsrc-users@NetBSD.org">pkgsrc-users@NetBSD.org</a>></code>.</p></li> <li><p><code class="varname">HOMEPAGE</code> is a URL where users can - find more information about the package.</p></li> + find more information about the package.</p></li> <li><p><code class="varname">COMMENT</code> is a one-line - description of the package (should not include the package - name).</p></li> + description of the package (should not include the package + name).</p></li> </ul></div> -<p> - </p> <p>Other variables that affect the build: - </p> + </p> <div class="itemizedlist"><ul type="disc"><li> <p><code class="varname">WRKSRC</code>: The directory where the - interesting distribution files of the package are found. The - default is <code class="filename">${WRKDIR}/${DISTNAME}</code>, which - works for most packages.</p> + interesting distribution files of the package are found. The + default is <code class="filename">${WRKDIR}/${DISTNAME}</code>, which + works for most packages.</p> <p>If a package doesn't create a subdirectory for itself - (most GNU software does, for instance), but extracts itself in - the current directory, you should set <code class="varname">WRKSRC= - ${WRKDIR}</code>.</p> -<p>If a package doesn't create a subdirectory with the name - of <code class="varname">DISTNAME</code> but some different name, set - <code class="varname">WRKSRC</code> to point to the proper name in - <code class="filename">${WRKDIR}</code>, for example <code class="varname">WRKSRC= - ${WRKDIR}/${DISTNAME}/unix</code>. See <a href="ftp://ftp.NetBSD.org/pub/NetBSD/packages/pkgsrc/lang/tcl/README.html" target="_top"><code class="filename">lang/tcl</code></a> and <a href="ftp://ftp.NetBSD.org/pub/NetBSD/packages/pkgsrc/x11/tk/README.html" target="_top"><code class="filename">x11/tk</code></a> for other examples.</p> + (most GNU software does, for instance), but extracts itself in + the current directory, you should set + <code class="varname">WRKSRC=${WRKDIR}</code>.</p> +<p>If a package doesn't create a subdirectory with the + name of <code class="varname">DISTNAME</code> but some different name, + set <code class="varname">WRKSRC</code> to point to the proper name in + <code class="filename">${WRKDIR}</code>, for example + <code class="varname">WRKSRC=${WRKDIR}/${DISTNAME}/unix</code>. See + <a href="ftp://ftp.NetBSD.org/pub/NetBSD/packages/pkgsrc/lang/tcl/README.html" target="_top"><code class="filename">lang/tcl</code></a> and <a href="ftp://ftp.NetBSD.org/pub/NetBSD/packages/pkgsrc/x11/tk/README.html" target="_top"><code class="filename">x11/tk</code></a> for other examples.</p> <p>The name of the working directory created by pkgsrc is - taken from the <code class="varname">WRKDIR_BASENAME</code> variable. By - default, its value is <code class="filename">work</code>. If you want - to use the same pkgsrc tree for building different kinds of - binary packages, you can change the variable according to your - needs. Two other variables handle common cases of setting - <code class="varname">WRKDIR_BASENAME</code> individually. If - <code class="varname">OBJHOSTNAME</code> is defined in - <code class="filename">/etc/mk.conf</code>, the first component of the - host's name is attached to the directory name. If - <code class="varname">OBJMACHINE</code> is defined, the platform name is - attached, which might look like <code class="filename">work.i386</code> - or <code class="filename">work.sparc</code>.</p> + taken from the <code class="varname">WRKDIR_BASENAME</code> + variable. By default, its value is + <code class="filename">work</code>. If you want to use the same + pkgsrc tree for building different kinds of binary packages, + you can change the variable according to your needs. Two + other variables handle common cases of setting + <code class="varname">WRKDIR_BASENAME</code> individually. If + <code class="varname">OBJHOSTNAME</code> is defined in + <code class="filename">/etc/mk.conf</code>, the first component of + the host's name is attached to the directory name. If + <code class="varname">OBJMACHINE</code> is defined, the platform name + is attached, which might look like + <code class="filename">work.i386</code> or + <code class="filename">work.sparc</code>.</p> </li></ul></div> -<p> - </p> <p>Please pay attention to the following gotchas:</p> <div class="itemizedlist"><ul type="disc"> -<li><p>Add <code class="varname">MANCOMPRESSED</code> if man pages are installed in - compressed form by the package; see comment in - <code class="filename">bsd.pkg.mk</code>.</p></li> +<li><p>Add <code class="varname">MANCOMPRESSED</code> if man pages are + installed in compressed form by the package; see comment in + <code class="filename">bsd.pkg.mk</code>.</p></li> <li><p>Replace <code class="filename">/usr/local</code> with - “<span class="quote">${PREFIX}</span>” in all files (see patches, below).</p></li> + “<span class="quote">${PREFIX}</span>” in all files (see patches, below).</p></li> <li><p>If the package installs any info files, see - <a href="#faq.info-files" title="17.5.7. Packages installing info files">Section 17.5.7, “Packages installing info files”</a>.</p></li> + <a href="#faq.info-files" title="17.6.6. Packages installing info files">Section 17.6.6, “Packages installing info files”</a>.</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>9.2. <code class="filename">distinfo</code></h2></div></div></div> <p>The <code class="filename">distinfo</code> file contains the message - digest, or checksum, of each distfile needed for the package. This - ensures that the distfiles retrieved from the Internet have not been - corrupted during transfer or altered by a malign force to introduce - a security hole. Due to recent rumor about weaknesses of digest - algorithms, all distfiles are protected using both SHA1 and RMD160 - message digests, as well as the file size.</p> + digest, or checksum, of each distfile needed for the package. This + ensures that the distfiles retrieved from the Internet have not been + corrupted during transfer or altered by a malign force to introduce + a security hole. Due to recent rumor about weaknesses of digest + algorithms, all distfiles are protected using both SHA1 and RMD160 + message digests, as well as the file size.</p> <p>The <code class="filename">distinfo</code> file also contains the - checksums for all the patches found in the - <code class="filename">patches</code> directory (see <a href="#components.patches" title="9.3. patches/*">Section 9.3, “patches/*”</a>).</p> + checksums for all the patches found in the + <code class="filename">patches</code> directory (see <a href="#components.patches" title="9.3. patches/*">Section 9.3, “patches/*”</a>).</p> <p>To regenerate the <code class="filename">distinfo</code> file, use the - <span><strong class="command">make makedistinfo</strong></span> or <span><strong class="command">make mdi</strong></span> - command.</p> + <span><strong class="command">make makedistinfo</strong></span> or <span><strong class="command">make mdi</strong></span> + command.</p> <p>Some packages have different sets of distfiles depending on - the platform, for example <a href="ftp://ftp.NetBSD.org/pub/NetBSD/packages/pkgsrc/www/navigator/README.html" target="_top"><code class="filename">www/navigator</code></a>). These are kept in the same - <code class="filename">distinfo</code> file and care should be taken when - upgrading such a package to ensure distfile information is not - lost.</p> + the platform, for example <a href="ftp://ftp.NetBSD.org/pub/NetBSD/packages/pkgsrc/www/navigator/README.html" target="_top"><code class="filename">www/navigator</code></a>). These are kept in the same + <code class="filename">distinfo</code> file and care should be taken when + upgrading such a package to ensure distfile information is not + lost.</p> </div> <div class="sect1" lang="en"> <div class="titlepage"><div><div><h2 class="title" style="clear: both"> <a name="components.patches"></a>9.3. patches/*</h2></div></div></div> <p>This directory contains files that are used by the - <a href="http://netbsd.gw.com/cgi-bin/man-cgi?patch+1+NetBSD-current"><span class="citerefentry"><span class="refentrytitle">patch</span>(1)</span></a> command to - modify the sources as distributed in the distribution file into a form - that will compile and run perfectly on NetBSD. The files are applied - successively in alphabetic order (as returned by a shell - “<span class="quote">patches/patch-*</span>” glob expansion), so - <code class="filename">patch-aa</code> is applied before - <code class="filename">patch-ab</code>, etc.</p> + <a href="http://netbsd.gw.com/cgi-bin/man-cgi?patch+1+NetBSD-current"><span class="citerefentry"><span class="refentrytitle">patch</span>(1)</span></a> command to + modify the sources as distributed in the distribution file into a form + that will compile and run perfectly on NetBSD. The files are applied + successively in alphabetic order (as returned by a shell + “<span class="quote">patches/patch-*</span>” glob expansion), so + <code class="filename">patch-aa</code> is applied before + <code class="filename">patch-ab</code>, etc.</p> <p>The <code class="filename">patch-*</code> files should be in - <span><strong class="command">diff -bu</strong></span> format, and apply without a fuzz to avoid - problems. (To force patches to apply - with fuzz you can set <code class="varname">PATCH_FUZZ_FACTOR=-F2</code>). - Furthermore, do not put changes for more than one file into a single - patch file, as this will make future modifications more difficult.</p> + <span><strong class="command">diff -bu</strong></span> format, and apply without a fuzz to avoid + problems. (To force patches to apply + with fuzz you can set <code class="varname">PATCH_FUZZ_FACTOR=-F2</code>). + Furthermore, do not put changes for more than one file into a single + patch file, as this will make future modifications more difficult.</p> <p>Similar, a file should be patched at most once, not several times by - several different patches. If a file needs several patches, they should - be combined into one file.</p> + several different patches. If a file needs several patches, they should + be combined into one file.</p> <p>One important thing to mention is to pay attention that no RCS IDs - get stored in the patch files, as these will cause problems when - later checked into the NetBSD CVS tree. Use the - <span><strong class="command">pkgdiff</strong></span> from the - <a href="ftp://ftp.NetBSD.org/pub/NetBSD/packages/pkgsrc/pkgtools/pkgdiff/README.html" target="_top"><code class="filename">pkgtools/pkgdiff</code></a> package to avoid - these problems.</p> -<p>For even more automation, we recommend using <span><strong class="command">mkpatches</strong></span> from the same - package to make a whole set of patches. You just have to backup files - before you edit them to <code class="filename">filename.orig</code>, e.g. with - <span><strong class="command">cp -p filename filename.orig</strong></span> or, easier, by using - <span><strong class="command">pkgvi</strong></span> again from the same package. If you upgrade a package - this way, you can easily compare the new set of patches with the - previously existing one with <span><strong class="command">patchdiff</strong></span>.</p> -<p>When you have finished a package, remember to generate the checksums - for the patch files by using the <span><strong class="command">make makepatchsum</strong></span> - command, see <a href="#components.distinfo" title="9.2. distinfo">Section 9.2, “<code class="filename">distinfo</code>”</a>.</p> + get stored in the patch files, as these will cause problems when + later checked into the NetBSD CVS tree. Use the + <span><strong class="command">pkgdiff</strong></span> from the + <a href="ftp://ftp.NetBSD.org/pub/NetBSD/packages/pkgsrc/pkgtools/pkgdiff/README.html" target="_top"><code class="filename">pkgtools/pkgdiff</code></a> package to avoid + these problems.</p> +<p>For even more automation, we recommend using + <span><strong class="command">mkpatches</strong></span> from the same package to make a + whole set of patches. You just have to backup files before you + edit them to <code class="filename">filename.orig</code>, e.g. with + <span><strong class="command">cp -p filename filename.orig</strong></span> or, easier, by + using <span><strong class="command">pkgvi</strong></span> again from the same package. If + you upgrade a package this way, you can easily compare the new + set of patches with the previously existing one with + <span><strong class="command">patchdiff</strong></span>. Copy the patches you want to use + or update from the <code class="filename">work/.newpatches</code> + directory to <code class="filename">patches/</code>.</p> +<p>When you have finished a package, remember to generate + the checksums for the patch files by using the <span><strong class="command">make + makepatchsum</strong></span> command, see <a href="#components.distinfo" title="9.2. distinfo">Section 9.2, “<code class="filename">distinfo</code>”</a>.</p> +<p>When adding a patch that corrects a problem in the + distfile (rather than e.g. enforcing pkgsrc's view of where + man pages should go), send the patch as a bug report to the + maintainer. This benefits non-pkgsrc users of the package, + and usually makes it possible to remove the patch in future + version.</p> +<p>If you want to share patches between multiple packages + in pkgsrc, e.g. because they use the same distfiles, set + <code class="varname">PATCHDIR</code> to the path where the patch files + can be found, e.g.:</p> +<pre class="programlisting"> + PATCHDIR= ${.CURDIR}/../xemacs/patches + </pre> <p>Patch files that are distributed by the author or other - maintainers can be listed in - <code class="varname">$PATCHFILES</code>. </p> -<p>If it is desired to store any patches that should not be committed into - pkgsrc, they can be kept outside the pkgsrc tree in the - <code class="filename">$LOCALPATCHES</code> - directory. The directory tree there is expected to have the same - “<span class="quote">category/package</span>” structure as pkgsrc, and patches are - expected to be stored inside these dirs (also known as - <code class="filename">$LOCALPATCHES/$PKGPATH</code>). For - example, if you want to keep a private patch for - <code class="filename">pkgsrc/graphics/png</code>, keep - it in <code class="filename">$LOCALPATCHES/graphics/png/mypatch</code>. All - files in the named directory are expected to be patch files, and - <span class="emphasis"><em>they are applied after pkgsrc patches are applied</em></span>.</p> + maintainers can be listed in + <code class="varname">PATCHFILES</code>.</p> +<p>If it is desired to store any patches that should not be + committed into pkgsrc, they can be kept outside the pkgsrc + tree in the <code class="filename">$LOCALPATCHES</code> directory. The + directory tree there is expected to have the same + “<span class="quote">category/package</span>” structure as pkgsrc, and + patches are expected to be stored inside these dirs (also + known as <code class="filename">$LOCALPATCHES/$PKGPATH</code>). For + example, if you want to keep a private patch for + <code class="filename">pkgsrc/graphics/png</code>, keep it in + <code class="filename">$LOCALPATCHES/graphics/png/mypatch</code>. All + files in the named directory are expected to be patch files, + and <span class="emphasis"><em>they are applied after pkgsrc patches are + applied</em></span>.</p> <div class="sect2" lang="en"> <div class="titlepage"><div><div><h3 class="title"> <a name="components.patches.guidelines"></a>9.3.1. Patching guidelines</h3></div></div></div> @@ -3983,7 +3974,7 @@ a security check before building any package. See specific <span class="emphasis"><em>features</em></span> you need. For example, instead of assuming that kqueue is available under NetBSD and using the <code class="varname">__NetBSD__</code> macro to conditionalize - kqueue support, add a check that detects kqueue itself — + kqueue support, add a check that detects kqueue itself — yes, this generally involves patching the <span><strong class="command">configure</strong></span> script. There is absolutely nothing that prevents some OSes from adopting interfaces from other OSes @@ -3991,7 +3982,7 @@ a security check before building any package. See cannot take into account.</p> <p>Of course, checking for features generally involves more work on the developer's side, but the resulting changes are - clearner and there are chances they will work on many other + cleaner and there are chances they will work on many other platforms. Not to mention that there are higher chances of being later integrated into the mainstream sources. Remember: <span class="emphasis"><em>It doesn't work unless it is right!</em></span></p> @@ -4014,9 +4005,9 @@ a security check before building any package. See <td>configure script</td> <td> <pre class="programlisting">case ${target_os} in - netbsd*) have_kvm=yes ;; - *) have_kvm=no ;; - esac</pre> + netbsd*) have_kvm=yes ;; + *) have_kvm=no ;; + esac</pre> </td> <td> <pre class="programlisting">AC_CHECK_LIB(kvm, kvm_open, have_kvm=yes, have_kvm=no)</pre> @@ -4026,40 +4017,40 @@ a security check before building any package. See <td>C source file</td> <td> <pre class="programlisting">#if defined(__NetBSD__) - # include <sys/event.h> - #endif</pre> + # include <sys/event.h> + #endif</pre> </td> <td> <pre class="programlisting">#if defined(HAVE_SYS_EVENT_H) - # include <sys/event.h> - #endif</pre> + # include <sys/event.h> + #endif</pre> </td> </tr> <tr> <td>C source file</td> <td> <pre class="programlisting">int - monitor_file(...) - { - #if defined(__NetBSD__) - int fd = kqueue(); - ... - #else - ... - #endif - }</pre> + monitor_file(...) + { + #if defined(__NetBSD__) + int fd = kqueue(); + ... + #else + ... + #endif + }</pre> </td> <td> <pre class="programlisting">int - monitor_file(...) - { - #if defined(HAVE_KQUEUE) - int fd = kqueue(); - ... - #else - ... - #endif - }</pre> + monitor_file(...) + { + #if defined(HAVE_KQUEUE) + int fd = kqueue(); + ... + #else + ... + #endif + }</pre> </td> </tr> </tbody> @@ -4100,16 +4091,16 @@ a security check before building any package. See <div class="variablelist"><dl> <dt><span class="term"><code class="filename">DESCR</code></span></dt> <dd><p>A multi-line description of the piece of software. This should include - any credits where they are due. Please bear in mind that others do not - share your sense of humour (or spelling idiosyncrasies), and that others - will read everything that you write here.</p></dd> + any credits where they are due. Please bear in mind that others do not + share your sense of humour (or spelling idiosyncrasies), and that others + will read everything that you write here.</p></dd> <dt><span class="term"><code class="filename">PLIST</code></span></dt> -<dd><p> - This file governs the files that are installed on your system: all the - binaries, manual pages, etc. There are other directives which may be - entered in this file, to control the creation and deletion of - directories, and the location of inserted files. - See <a href="#plist" title="Chapter 11. PLIST issues">Chapter 11, <i>PLIST issues</i></a> for more information. </p></dd> +<dd><p>This file governs the files that are installed on your + system: all the binaries, manual pages, etc. There are other + directives which may be entered in this file, to control the + creation and deletion of directories, and the location of + inserted files. See <a href="#plist" title="Chapter 11. PLIST issues">Chapter 11, <i>PLIST issues</i></a> for more + information.</p></dd> </dl></div> </div> <div class="sect1" lang="en"> @@ -4121,33 +4112,44 @@ a security check before building any package. See <div class="variablelist"><dl> <dt><span class="term"><code class="filename">INSTALL</code></span></dt> <dd><p>This shell script is invoked twice by <a href="http://netbsd.gw.com/cgi-bin/man-cgi?pkg_add+1+NetBSD-current"><span class="citerefentry"><span class="refentrytitle">pkg_add</span>(1)</span></a>. - First time after package - extraction and before files are moved in place, the second time after - the files to install are moved in place. This can be used to do any - custom procedures not possible with @exec commands in - <code class="filename">PLIST</code>. See - <a href="http://netbsd.gw.com/cgi-bin/man-cgi?pkg_add+1+NetBSD-current"><span class="citerefentry"><span class="refentrytitle">pkg_add</span>(1)</span></a> and <a href="http://netbsd.gw.com/cgi-bin/man-cgi?pkg_create+1+NetBSD-current"><span class="citerefentry"><span class="refentrytitle">pkg_create</span>(1)</span></a> for more information.</p></dd> + First time after package extraction and before files are + moved in place, the second time after the files to install + are moved in place. This can be used to do any custom + procedures not possible with @exec commands in + <code class="filename">PLIST</code>. See <a href="http://netbsd.gw.com/cgi-bin/man-cgi?pkg_add+1+NetBSD-current"><span class="citerefentry"><span class="refentrytitle">pkg_add</span>(1)</span></a> and + <a href="http://netbsd.gw.com/cgi-bin/man-cgi?pkg_create+1+NetBSD-current"><span class="citerefentry"><span class="refentrytitle">pkg_create</span>(1)</span></a> for more information. See also <a href="#files-and-dirs-outside-prefix" title="13.1. Files and directories outside the installation prefix">Section 13.1, “Files and directories outside the installation prefix”</a>.</p></dd> <dt><span class="term"><code class="filename">DEINSTALL</code></span></dt> <dd><p>This script is executed before and after any files are removed. It is - this script's responsibility to clean up any additional messy details - around the package's installation, since all pkg_delete knows is how to - delete the files created in the original distribution. - See <a href="http://netbsd.gw.com/cgi-bin/man-cgi?pkg_delete+1+NetBSD-current"><span class="citerefentry"><span class="refentrytitle">pkg_delete</span>(1)</span></a> - and <a href="http://netbsd.gw.com/cgi-bin/man-cgi?pkg_create+1+NetBSD-current"><span class="citerefentry"><span class="refentrytitle">pkg_create</span>(1)</span></a> for more information.</p></dd> + this script's responsibility to clean up any additional messy details + around the package's installation, since all pkg_delete knows is how to + delete the files created in the original distribution. + See <a href="http://netbsd.gw.com/cgi-bin/man-cgi?pkg_delete+1+NetBSD-current"><span class="citerefentry"><span class="refentrytitle">pkg_delete</span>(1)</span></a> + and <a href="http://netbsd.gw.com/cgi-bin/man-cgi?pkg_create+1+NetBSD-current"><span class="citerefentry"><span class="refentrytitle">pkg_create</span>(1)</span></a> for more information.</p></dd> <dt><span class="term"><code class="filename">MESSAGE</code></span></dt> <dd> <p>This file is displayed after installation of the package. - Useful for things like legal notices on almost-free - software and hints for updating config files after - installing modules for apache, PHP etc. - Please note that you can modify variables in it easily by using - <code class="varname">MESSAGE_SUBST</code> in the package's - <code class="filename">Makefile</code>:</p> + Useful for things like legal notices on almost-free + software and hints for updating config files after + installing modules for apache, PHP etc. + Please note that you can modify variables in it easily by using + <code class="varname">MESSAGE_SUBST</code> in the package's + <code class="filename">Makefile</code>:</p> <pre class="programlisting"> - MESSAGE_SUBST+= SOMEVAR="somevalue" -</pre> + MESSAGE_SUBST+= SOMEVAR="somevalue" + </pre> <p>replaces "${SOMEVAR}" with “<span class="quote">somevalue</span>” in - <code class="filename">MESSAGE</code>.</p> + <code class="filename">MESSAGE</code>. By default, substitution is + performed for <code class="varname">PKGNAME</code>, + <code class="varname">PKGBASE</code>, <code class="varname">PREFIX</code>, + <code class="varname">LOCALBASE</code>, <code class="varname">X11PREFIX</code>, + <code class="varname">X11BASE</code>, + <code class="varname">PKG_SYSCONFDIR</code>, + <code class="varname">ROOT_GROUP</code>, and + <code class="varname">ROOT_GROUP</code>.</p> +<p>You can display a different or additional files by + setting the <code class="varname">MESSAGE_SRC</code> variable. Its + default is <code class="filename">MESSAGE</code>, if the file + exists.</p> </dd> <dt><span class="term"><code class="filename">ALTERNATIVES</code></span></dt> <dd><p>FIXME: There is no documentation on the @@ -4202,25 +4204,32 @@ a security check before building any package. See <div class="titlepage"><div><div><h2 class="title" style="clear: both"> <a name="work-dir"></a>9.6. <code class="filename">work*</code></h2></div></div></div> <p>When you type <span><strong class="command">make</strong></span>, the distribution files are - unpacked into the directory denoted by - <code class="varname">WRKDIR</code>. It can be removed by running - <span><strong class="command">make clean</strong></span>. Besides the sources, this - directory is also used to keep various timestamp files. - The directory gets <span class="emphasis"><em>removed completely</em></span> on clean. - The default is <code class="filename">${.CURDIR}/work</code> - or <code class="filename">${.CURDIR}/work.${MACHINE_ARCH}</code> - if <code class="varname">OBJMACHINE</code> is set.</p> + unpacked into the directory denoted by + <code class="varname">WRKDIR</code>. It can be removed by running + <span><strong class="command">make clean</strong></span>. Besides the sources, this + directory is also used to keep various timestamp files. + The directory gets <span class="emphasis"><em>removed completely</em></span> on clean. + The default is <code class="filename">${.CURDIR}/work</code> + or <code class="filename">${.CURDIR}/work.${MACHINE_ARCH}</code> + if <code class="varname">OBJMACHINE</code> is set.</p> </div> <div class="sect1" lang="en"> <div class="titlepage"><div><div><h2 class="title" style="clear: both"> <a name="files-dir"></a>9.7. <code class="filename">files/*</code></h2></div></div></div> <p>If you have any files that you wish to be placed in the package prior - to configuration or building, you could place these files here and use - a “<span class="quote">${CP}</span>” command in the - “<span class="quote">pre-configure</span>” target to achieve - this. Alternatively, you could simply diff the file against - <code class="filename">/dev/null</code> and use the patch mechanism to manage - the creation of this file.</p> + to configuration or building, you could place these files here and use + a <span><strong class="command">${CP}</strong></span> command in the + “<span class="quote">pre-configure</span>” target to achieve + this. Alternatively, you could simply diff the file against + <code class="filename">/dev/null</code> and use the patch mechanism to manage + the creation of this file.</p> +<p>If you want to share files in this way with other + packages, set the <code class="varname">FILESDIR</code> variable to point + to the other package's <code class="filename">files</code> directory, + e.g.:</p> +<pre class="programlisting"> + FILESDIR=${.CURDIR}/../xemacs/files + </pre> </div> </div> <div class="chapter" lang="en"> @@ -4288,7 +4297,7 @@ a security check before building any package. See operate on the words, others operate on the string as a whole. When a string is split into words, it is split as you would expect it from <a href="http://netbsd.gw.com/cgi-bin/man-cgi?sh+1+NetBSD-current"><span class="citerefentry"><span class="refentrytitle">sh</span>(1)</span></a>.</p> -<p>No rule without exception—the <span><strong class="command">.for</strong></span> +<p>No rule without exception—the <span><strong class="command">.for</strong></span> loop does not follow the shell quoting rules but splits at sequences of whitespace.</p> <p>There are several types of variables that should be handled @@ -4531,97 +4540,94 @@ a security check before building any package. See <dt><span class="sect1"><a href="#faq.common-dirs">11.8. Sharing directories between packages</a></span></dt> </dl> </div> -<p> The <code class="filename">PLIST</code> file contains a package's - “<span class="quote">packing list</span>”, i.e. a list of files that belong to - the package (relative to the <code class="filename">${PREFIX}</code> - directory it's been installed in) plus some additional statements - - see the <a href="http://netbsd.gw.com/cgi-bin/man-cgi?pkg_create+1+NetBSD-current"><span class="citerefentry"><span class="refentrytitle">pkg_create</span>(1)</span></a> man page for a full list. - This chapter addresses some issues that need attention when - dealing with the <code class="filename">PLIST</code> file (or files, see - below!).</p> +<p>The <code class="filename">PLIST</code> file contains a package's + “<span class="quote">packing list</span>”, i.e. a list of files that belong to + the package (relative to the <code class="filename">${PREFIX}</code> + directory it's been installed in) plus some additional statements + - see the <a href="http://netbsd.gw.com/cgi-bin/man-cgi?pkg_create+1+NetBSD-current"><span class="citerefentry"><span class="refentrytitle">pkg_create</span>(1)</span></a> man page for a full list. + This chapter addresses some issues that need attention when + dealing with the <code class="filename">PLIST</code> file (or files, see + below!).</p> <div class="sect1" lang="en"> <div class="titlepage"><div><div><h2 class="title" style="clear: both"> <a name="rcs-id"></a>11.1. RCS ID</h2></div></div></div> -<p> - Be sure to add a RCS ID line as the first thing in any - <code class="filename">PLIST</code> file you write: - </p> +<p>Be sure to add a RCS ID line as the first thing in any + <code class="filename">PLIST</code> file you write:</p> <pre class="programlisting"> - @comment $NetBSD$ -</pre> + @comment $NetBSD$ + </pre> </div> <div class="sect1" lang="en"> <div class="titlepage"><div><div><h2 class="title" style="clear: both"> <a name="automatic-plist-generation"></a>11.2. Semi-automatic <code class="filename">PLIST</code> generation</h2></div></div></div> <p>You can use the <span><strong class="command">make print-PLIST</strong></span> command - to output a PLIST that matches any new files since the package - was extracted. See <a href="#build.helpful-targets" title="15.16. Other helpful targets">Section 15.16, “Other helpful targets”</a> for - more information on this target.</p> + to output a PLIST that matches any new files since the package + was extracted. See <a href="#build.helpful-targets" title="15.16. Other helpful targets">Section 15.16, “Other helpful targets”</a> for + more information on this target.</p> </div> <div class="sect1" lang="en"> <div class="titlepage"><div><div><h2 class="title" style="clear: both"> <a name="print-PLIST"></a>11.3. Tweaking output of <span><strong class="command">make print-PLIST</strong></span></h2></div></div></div> -<p> If you have used any of the *-dirs packages, as explained in - <a href="#faq.common-dirs" title="11.8. Sharing directories between packages">Section 11.8, “Sharing directories between packages”</a>, you may have noticed that - <span><strong class="command">make print-PLIST</strong></span> outputs a set of - <code class="varname">@comment</code>s instead of real - <code class="varname">@dirrm</code> lines. You can also do this for - specific directories and files, so that the results of that - command are very close to reality. This helps <span class="emphasis"><em>a - lot</em></span> during the update of packages. </p> -<p> The <code class="varname">PRINT_PLIST_AWK</code> variable takes a set - of AWK patterns and actions that are used to filter the output of - print-PLIST. You can <span class="emphasis"><em>append</em></span> any chunk of AWK - scripting you like to it, but be careful with quoting. </p> -<p> For example, to get all files inside the - <code class="filename">libdata/foo</code> directory removed from the - resulting PLIST:</p> +<p>If you have used any of the *-dirs packages, as explained in + <a href="#faq.common-dirs" title="11.8. Sharing directories between packages">Section 11.8, “Sharing directories between packages”</a>, you may have noticed that + <span><strong class="command">make print-PLIST</strong></span> outputs a set of + <code class="varname">@comment</code>s instead of real + <code class="varname">@dirrm</code> lines. You can also do this for + specific directories and files, so that the results of that + command are very close to reality. This helps <span class="emphasis"><em>a + lot</em></span> during the update of packages.</p> +<p>The <code class="varname">PRINT_PLIST_AWK</code> variable takes a set + of AWK patterns and actions that are used to filter the output of + print-PLIST. You can <span class="emphasis"><em>append</em></span> any chunk of AWK + scripting you like to it, but be careful with quoting.</p> +<p>For example, to get all files inside the + <code class="filename">libdata/foo</code> directory removed from the + resulting PLIST:</p> <pre class="programlisting"> - PRINT_PLIST_AWK+= /^libdata\/foo/ { next; } -</pre> -<p> And to get all the <code class="varname">@dirrm</code> lines referring - to a specific (shared) directory converted to - <code class="varname">@comment</code>s: </p> + PRINT_PLIST_AWK+= /^libdata\/foo/ { next; } + </pre> +<p>And to get all the <code class="varname">@dirrm</code> lines referring + to a specific (shared) directory converted to + <code class="varname">@comment</code>s:</p> <pre class="programlisting"> - PRINT_PLIST_AWK+= /^@dirrm share\/specific/ { print "@comment " $$0; next; } -</pre> + PRINT_PLIST_AWK+= /^@dirrm share\/specific/ { print "@comment " $$0; next; } + </pre> </div> <div class="sect1" lang="en"> <div class="titlepage"><div><div><h2 class="title" style="clear: both"> <a name="plist.misc"></a>11.4. Variable substitution in PLIST</h2></div></div></div> -<p> - A number of variables are substituted automatically in PLISTs - when a package is installed on a system. This includes the - following variables: </p> +<p>A number of variables are substituted automatically in + PLISTs when a package is installed on a system. This includes the + following variables:</p> <div class="variablelist"><dl> <dt><span class="term"><code class="varname">${MACHINE_ARCH}</code>, <code class="varname">${MACHINE_GNU_ARCH}</code></span></dt> <dd> <p>Some packages like emacs and perl embed information - about which architecture they were built on into the - pathnames where they install their files. To handle this - case, PLIST will be preprocessed before actually used, and - the symbol - “<span class="quote"><code class="varname">${MACHINE_ARCH}</code></span>” will be - replaced by what <span><strong class="command">uname -p</strong></span> gives. The - same is done if the string - <code class="varname">${MACHINE_GNU_ARCH}</code> is embedded in - PLIST somewhere - use this on packages that have GNU - autoconf-created configure scripts.</p> + about which architecture they were built on into the + pathnames where they install their files. To handle this + case, PLIST will be preprocessed before actually used, and + the symbol + “<span class="quote"><code class="varname">${MACHINE_ARCH}</code></span>” will be + replaced by what <span><strong class="command">uname -p</strong></span> gives. The + same is done if the string + <code class="varname">${MACHINE_GNU_ARCH}</code> is embedded in + PLIST somewhere - use this on packages that have GNU + autoconf-created configure scripts.</p> <div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"> <h3 class="title">Legacy note</h3> <p>There used to be a symbol - “<span class="quote"><code class="varname">$ARCH</code></span>” that - was replaced by the output of <span><strong class="command">uname - -m</strong></span>, but that's no longer supported and has - been removed.</p> + “<span class="quote"><code class="varname">$ARCH</code></span>” that + was replaced by the output of <span><strong class="command">uname + -m</strong></span>, but that's no longer supported and has + been removed.</p> </div> </dd> <dt><span class="term"><code class="varname">${OPSYS}</code>, <code class="varname">${LOWER_OPSYS}</code>, <code class="varname">${OS_VERSION}</code></span></dt> <dd> <p>Some packages want to embed the OS name and version - into some paths. To do this, use these variables in the - <code class="filename">PLIST</code>: - </p> + into some paths. To do this, use these variables in the + <code class="filename">PLIST</code>: + </p> <div class="itemizedlist"><ul type="disc"> <li><p><code class="varname">${OPSYS}</code> - output of “<span class="quote"><span><strong class="command">uname -s</strong></span></span>”</p></li> <li><p><code class="varname">${LOWER_OPSYS}</code> - lowercase common name (eg. “<span class="quote">solaris</span>”)</p></li> @@ -4629,46 +4635,48 @@ a security check before building any package. See </ul></div> </dd> </dl></div> -<p> For a complete list of values which are replaced by - default, please look in <code class="filename">bsd.pkg.mk</code> (and - search for <span class="emphasis"><em>PLIST_SUBST</em></span>). </p> -<p> If you want to change other variables not listed above, you - can add variables and their expansions to this variable in the - following way, similar to <code class="varname">MESSAGE_SUBST</code> (see <a href="#components.optional" title="9.5. Optional files">Section 9.5, “Optional files”</a>): </p> +<p>For a complete list of values which are replaced by + default, please look in <code class="filename">bsd.pkg.mk</code> (and + search for <code class="varname">PLIST_SUBST</code>).</p> +<p>If you want to change other variables not listed above, you + can add variables and their expansions to this variable in the + following way, similar to <code class="varname">MESSAGE_SUBST</code> (see <a href="#components.optional" title="9.5. Optional files">Section 9.5, “Optional files”</a>):</p> <pre class="programlisting"> - PLIST_SUBST+= SOMEVAR="somevalue" -</pre> + PLIST_SUBST+= SOMEVAR="somevalue" + </pre> <p>This replaces all occurrences of “<span class="quote">${SOMEVAR}</span>” - in the PLIST with “<span class="quote">somevalue</span>”. </p> + in the <code class="filename">PLIST</code> with + “<span class="quote">somevalue</span>”.</p> </div> <div class="sect1" lang="en"> <div class="titlepage"><div><div><h2 class="title" style="clear: both"> <a name="manpage-compression"></a>11.5. Man page compression</h2></div></div></div> <p>Man pages should be installed in compressed form if - <code class="varname">MANZ</code> is set (in <code class="filename">bsd.own.mk</code>), - and uncompressed otherwise. To handle this in the - <code class="filename">PLIST</code> file, the suffix “<span class="quote">.gz</span>” is - appended/removed automatically for man pages according to - <code class="varname">MANZ</code> and <code class="varname">MANCOMPRESSED</code> being set - or not, see above for details. This modification of the - <code class="filename">PLIST</code> file is done on a copy of it, not - <code class="filename">PLIST</code> itself.</p> + <code class="varname">MANZ</code> is set (in <code class="filename">bsd.own.mk</code>), + and uncompressed otherwise. To handle this in the + <code class="filename">PLIST</code> file, the suffix “<span class="quote">.gz</span>” is + appended/removed automatically for man pages according to + <code class="varname">MANZ</code> and <code class="varname">MANCOMPRESSED</code> being set + or not, see above for details. This modification of the + <code class="filename">PLIST</code> file is done on a copy of it, not + <code class="filename">PLIST</code> itself.</p> </div> <div class="sect1" lang="en"> <div class="titlepage"><div><div><h2 class="title" style="clear: both"> <a name="using-PLIST_SRC"></a>11.6. Changing PLIST source with <code class="varname">PLIST_SRC</code></h2></div></div></div> <p>To use one or more files as source for the <code class="filename">PLIST</code> used - in generating the binary package, set the variable - <code class="varname">PLIST_SRC</code> to the names of that file(s). - The files are later concatenated using <a href="http://netbsd.gw.com/cgi-bin/man-cgi?cat+1+NetBSD-current"><span class="citerefentry"><span class="refentrytitle">cat</span>(1)</span></a>, and order of things is - important.</p> + in generating the binary package, set the variable + <code class="varname">PLIST_SRC</code> to the names of that file(s). + The files are later concatenated using <a href="http://netbsd.gw.com/cgi-bin/man-cgi?cat+1+NetBSD-current"><span class="citerefentry"><span class="refentrytitle">cat</span>(1)</span></a>, and the order of things is + important. The default for <code class="varname">PLIST_SRC</code> is + <code class="filename">${PKGDIR}/PLIST</code>.</p> </div> <div class="sect1" lang="en"> <div class="titlepage"><div><div><h2 class="title" style="clear: both"> <a name="platform-specific-plist"></a>11.7. Platform-specific and differing PLISTs</h2></div></div></div> <p>Some packages decide to install a different set of files based on - the operating system being used. These differences can be - automatically handled by using the following files:</p> + the operating system being used. These differences can be + automatically handled by using the following files:</p> <div class="itemizedlist"><ul type="disc"> <li><p><code class="filename">PLIST.common</code></p></li> <li><p><code class="filename">PLIST.${OPSYS}</code></p></li> @@ -4680,58 +4688,56 @@ a security check before building any package. See <div class="sect1" lang="en"> <div class="titlepage"><div><div><h2 class="title" style="clear: both"> <a name="faq.common-dirs"></a>11.8. Sharing directories between packages</h2></div></div></div> -<p> A “<span class="quote">shared directory</span>” is a directory where - multiple (and unrelated) packages install files. These - directories are problematic because you have to add special tricks - in the PLIST to conditionally remove them, or have some - centralized package handle them. </p> -<p> Within pkgsrc, you'll find both approaches. If a directory - is shared by a few unrelated packages, it's often not worth to add - an extra package to remove it. Therefore, one simply does: - </p> +<p>A “<span class="quote">shared directory</span>” is a directory where + multiple (and unrelated) packages install files. These + directories are problematic because you have to add special tricks + in the PLIST to conditionally remove them, or have some + centralized package handle them.</p> +<p>Within pkgsrc, you'll find both approaches. If a directory + is shared by a few unrelated packages, it's often not worth to add + an extra package to remove it. Therefore, one simply does:</p> <pre class="programlisting"> - @unexec ${RMDIR} %D/path/to/shared/directory 2>/dev/null || ${TRUE} -</pre> -<p> in the PLISTs of all affected packages, instead of the - regular "@dirrm" line. </p> -<p> However, if the directory is shared across many packages, two - different solutions are available: </p> + @unexec ${RMDIR} %D/path/to/shared/directory 2>/dev/null || ${TRUE} + </pre> +<p>in the PLISTs of all affected packages, instead of the + regular "@dirrm" line.</p> +<p>However, if the directory is shared across many packages, two + different solutions are available:</p> <div class="orderedlist"><ol type="1"> -<li><p> If the packages have a common dependency, the directory - can be removed in that. For example, see - <a href="ftp://ftp.NetBSD.org/pub/NetBSD/packages/pkgsrc/textproc/scrollkeeper/README.html" target="_top"><code class="filename">textproc/scrollkeeper</code></a>, which - removes the shared directory - <code class="filename">share/omf</code>. </p></li> -<li><p> If the packages using the directory are not related at - all (they have no common dependencies), a *-dirs package is - used. </p></li> +<li><p>If the packages have a common dependency, the directory + can be removed in that. For example, see + <a href="ftp://ftp.NetBSD.org/pub/NetBSD/packages/pkgsrc/textproc/scrollkeeper/README.html" target="_top"><code class="filename">textproc/scrollkeeper</code></a>, which + removes the shared directory + <code class="filename">share/omf</code>.</p></li> +<li><p>If the packages using the directory are not related at + all (they have no common dependencies), a *-dirs package is + used.</p></li> </ol></div> -<p> From now on, we'll discuss the second solution. To get an - idea of the *-dirs packages available, issue: </p> +<p>From now on, we'll discuss the second solution. To get an + idea of the *-dirs packages available, issue:</p> <pre class="programlisting"> - <code class="prompt">%</code> cd .../pkgsrc - <code class="prompt">%</code> ls -d */*-dirs -</pre> -<p> Their use from other packages is very simple. The - <code class="varname">USE_DIRS</code> variable takes a list of package names - (without the “<span class="quote">-dirs</span>” part) together with the required - version number (always pick the latest one when writing new - packages). </p> -<p> For example, if a package installs files under - <code class="filename">share/applications</code>, it should have the - following line in it: - </p> + <code class="prompt">%</code> cd .../pkgsrc + <code class="prompt">%</code> ls -d */*-dirs + </pre> +<p>Their use from other packages is very simple. The + <code class="varname">USE_DIRS</code> variable takes a list of package names + (without the “<span class="quote">-dirs</span>” part) together with the required + version number (always pick the latest one when writing new + packages).</p> +<p>For example, if a package installs files under + <code class="filename">share/applications</code>, it should have the + following line in it:</p> <pre class="programlisting"> - USE_DIRS+= xdg-1.1 -</pre> -<p> After regenerating the PLIST using <span><strong class="command">make - print-PLIST</strong></span>, you should get the right (commented out) - lines. </p> -<p> Note that even if your package is using - <code class="filename">$X11BASE</code>, it must not depend on the - *-x11-dirs packages. Just specify the name without that part and - pkgsrc (in particular, <code class="filename">mk/dirs.mk</code>) will take - care of it. </p> + USE_DIRS+= xdg-1.1 + </pre> +<p>After regenerating the PLIST using <span><strong class="command">make + print-PLIST</strong></span>, you should get the right (commented out) + lines.</p> +<p>Note that even if your package is using + <code class="filename">$X11BASE</code>, it must not depend on the + *-x11-dirs packages. Just specify the name without that part and + pkgsrc (in particular, <code class="filename">mk/dirs.mk</code>) will take + care of it.</p> </div> </div> <div class="chapter" lang="en"> @@ -4754,239 +4760,231 @@ a security check before building any package. See </dl> </div> <p>Buildlink is a framework in pkgsrc that controls what headers and libraries - are seen by a package's configure and build processes. This is implemented - in a two step process:</p> + are seen by a package's configure and build processes. This is implemented + in a two step process:</p> <div class="orderedlist"><ol type="1"> <li><p>Symlink headers and libraries for dependencies into - <code class="varname">BUILDLINK_DIR</code>, which by default is a subdirectory - of <code class="varname">WRKDIR</code>.</p></li> + <code class="varname">BUILDLINK_DIR</code>, which by default is a subdirectory + of <code class="varname">WRKDIR</code>.</p></li> <li><p>Create wrapper scripts that are used in place of the normal compiler - tools that translate <code class="option">-I${LOCALBASE}/include</code> and - <code class="option">-L${LOCALBASE}/lib</code> into references to - <code class="varname">BUILDLINK_DIR</code>. The wrapper scripts also make - native compiler on some operating systems look like GCC, so that - packages that expect GCC won't require modifications to build with - those native compilers.</p></li> + tools that translate <code class="option">-I${LOCALBASE}/include</code> and + <code class="option">-L${LOCALBASE}/lib</code> into references to + <code class="varname">BUILDLINK_DIR</code>. The wrapper scripts also make + native compiler on some operating systems look like GCC, so that + packages that expect GCC won't require modifications to build with + those native compilers.</p></li> </ol></div> <p>This normalizes the environment in which a package is built so that the - package may be built consistently despite what other software may be - installed. Please note that the normal system header and library paths, - e.g. <code class="filename">/usr/include</code>, - <code class="filename">/usr/lib</code>, etc., are always searched -- buildlink3 is - designed to insulate the package build from non-system-supplied - software. </p> + package may be built consistently despite what other software may be + installed. Please note that the normal system header and library paths, + e.g. <code class="filename">/usr/include</code>, + <code class="filename">/usr/lib</code>, etc., are always searched -- buildlink3 is + designed to insulate the package build from non-system-supplied + software.</p> <div class="sect1" lang="en"> <div class="titlepage"><div><div><h2 class="title" style="clear: both"> <a name="converting-to-buildlink3"></a>12.1. Converting packages to use buildlink3</h2></div></div></div> <p>The process of converting packages to use the buildlink3 - framework (“<span class="quote">bl3ifying</span>”) is fairly straightforward. - The things to keep in mind are:</p> + framework (“<span class="quote">bl3ifying</span>”) is fairly straightforward. + The things to keep in mind are:</p> <div class="orderedlist"><ol type="1"> -<li><p> Ensure that the build always calls the wrapper scripts - instead of the actual toolchain. Some packages are tricky, - and the only way to know for sure is the check - <code class="filename">${WRKDIR}/.work.log</code> to see if the - wrappers are being invoked. </p></li> -<li><p> Don't override <code class="varname">PREFIX</code> from within - the package Makefile, e.g. Java VMs, standalone shells, - etc., because the code to symlink files into - <code class="filename">${BUILDLINK_DIR}</code> looks for files - relative to “<span class="quote">pkg_info -qp <em class="replaceable"><code>pkgname</code></em></span>”. - </p></li> -<li><p> Remember that <span class="emphasis"><em>only</em></span> the - <code class="filename">buildlink3.mk</code> files that you list in a - package's Makefile are added as dependencies for that package. - </p></li> +<li><p>Ensure that the build always calls the wrapper scripts + instead of the actual toolchain. Some packages are tricky, + and the only way to know for sure is the check + <code class="filename">${WRKDIR}/.work.log</code> to see if the + wrappers are being invoked.</p></li> +<li><p>Don't override <code class="varname">PREFIX</code> from within + the package Makefile, e.g. Java VMs, standalone shells, + etc., because the code to symlink files into + <code class="filename">${BUILDLINK_DIR}</code> looks for files + relative to “<span class="quote">pkg_info -qp <em class="replaceable"><code>pkgname</code></em></span>”. + </p></li> +<li><p>Remember that <span class="emphasis"><em>only</em></span> the + <code class="filename">buildlink3.mk</code> files that you list in a + package's Makefile are added as dependencies for that package. + </p></li> </ol></div> -<p> If a dependency on a particular package is required for its libraries and - headers, then we replace: </p> +<p>If a dependency on a particular package is required for its libraries and + headers, then we replace:</p> <pre class="programlisting"> - DEPENDS+= foo>=1.1.0:../../category/foo -</pre> + DEPENDS+= foo>=1.1.0:../../category/foo + </pre> <p>with</p> <pre class="programlisting"> - .include "../../category/foo/buildlink3.mk" -</pre> + .include "../../category/foo/buildlink3.mk" + </pre> <p>The buildlink3.mk files usually define the required dependencies. If you need a newer version of the dependency when using buildlink3.mk - files, then you can define it in your Makefile; for example: - </p> + files, then you can define it in your Makefile; for example:</p> <pre class="programlisting"> - BUILDLINK_API_DEPENDS.foo+= foo>=1.1.0 - .include "../../category/foo/buildlink3.mk" -</pre> + BUILDLINK_API_DEPENDS.foo+= foo>=1.1.0 + .include "../../category/foo/buildlink3.mk" + </pre> <p>There are several <code class="filename">buildlink3.mk</code> - files in <code class="filename">pkgsrc/mk</code> - that handle special package issues:</p> + files in <code class="filename">pkgsrc/mk</code> + that handle special package issues:</p> <div class="itemizedlist"><ul type="disc"> <li><p><code class="filename">bdb.buildlink3.mk</code> chooses either - the native or a pkgsrc Berkeley DB implementation based on - the values of <code class="varname">BDB_ACCEPTED</code> and - <code class="varname">BDB_DEFAULT</code>.</p></li> + the native or a pkgsrc Berkeley DB implementation based on + the values of <code class="varname">BDB_ACCEPTED</code> and + <code class="varname">BDB_DEFAULT</code>.</p></li> <li><p><code class="filename">curses.buildlink3.mk</code>: If the system - comes with neither Curses nor NCurses, this will take care - to install the <a href="ftp://ftp.NetBSD.org/pub/NetBSD/packages/pkgsrc/devel/ncurses/README.html" target="_top"><code class="filename">devel/ncurses</code></a> package.</p></li> + comes with neither Curses nor NCurses, this will take care + to install the <a href="ftp://ftp.NetBSD.org/pub/NetBSD/packages/pkgsrc/devel/ncurses/README.html" target="_top"><code class="filename">devel/ncurses</code></a> package.</p></li> <li><p><code class="filename">krb5.buildlink3.mk</code> uses the value - of <code class="varname">KRB5_ACCEPTED</code> to choose between - adding a dependency on Heimdal or MIT-krb5 for packages that - require a Kerberos 5 implementation.</p></li> + of <code class="varname">KRB5_ACCEPTED</code> to choose between + adding a dependency on Heimdal or MIT-krb5 for packages that + require a Kerberos 5 implementation.</p></li> <li><p><code class="filename">motif.buildlink3.mk</code> checks - for a system-provided - Motif installation or adds a dependency on <a href="ftp://ftp.NetBSD.org/pub/NetBSD/packages/pkgsrc/x11/lesstif/README.html" target="_top"><code class="filename">x11/lesstif</code></a> or - <a href="ftp://ftp.NetBSD.org/pub/NetBSD/packages/pkgsrc/x11/openmotif/README.html" target="_top"><code class="filename">x11/openmotif</code></a>.</p></li> + for a system-provided + Motif installation or adds a dependency on <a href="ftp://ftp.NetBSD.org/pub/NetBSD/packages/pkgsrc/x11/lesstif/README.html" target="_top"><code class="filename">x11/lesstif</code></a> or + <a href="ftp://ftp.NetBSD.org/pub/NetBSD/packages/pkgsrc/x11/openmotif/README.html" target="_top"><code class="filename">x11/openmotif</code></a>.</p></li> <li><p><code class="filename">oss.buildlink3.mk</code> defines several - variables that may be used by packages that use the - Open Sound System (OSS) API.</p></li> + variables that may be used by packages that use the + Open Sound System (OSS) API.</p></li> <li><p><code class="filename">pgsql.buildlink3.mk</code> will accept - either Postgres 7.3 or 7.4, whichever is found installed. See - the file for more information. </p></li> + either Postgres 7.3 or 7.4, whichever is found installed. See + the file for more information.</p></li> <li><p><code class="filename">pthread.buildlink3.mk</code> uses the value of - <code class="varname">PTHREAD_OPTS</code> and checks for native pthreads or adds - a dependency on <a href="ftp://ftp.NetBSD.org/pub/NetBSD/packages/pkgsrc/devel/pth/README.html" target="_top"><code class="filename">devel/pth</code></a> as needed.</p></li> + <code class="varname">PTHREAD_OPTS</code> and checks for native pthreads or adds + a dependency on <a href="ftp://ftp.NetBSD.org/pub/NetBSD/packages/pkgsrc/devel/pth/README.html" target="_top"><code class="filename">devel/pth</code></a> as needed.</p></li> <li><p><code class="filename">xaw.buildlink3.mk</code> uses the value of - <code class="varname">XAW_TYPE</code> to choose a particular Athena widgets - library.</p></li> + <code class="varname">XAW_TYPE</code> to choose a particular Athena widgets + library.</p></li> </ul></div> <p>The comments in those <code class="filename">buildlink3.mk</code> - files provide a more complete - description of how to use them properly.</p> + 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="creating-buildlink3.mk"></a>12.2. Writing <code class="filename">buildlink3.mk</code> files</h2></div></div></div> -<p> A package's <code class="filename">buildlink3.mk</code> file is - included by Makefiles to indicate the need to compile and link - against header files and libraries provided by the package. A - <code class="filename">buildlink3.mk</code> file should always provide - enough information to add the correct type of dependency - relationship and include any other - <code class="filename">buildlink3.mk</code> files that it needs to find - headers and libraries that it needs in turn.</p> -<p> To generate an initial <code class="filename">buildlink3.mk</code> - file for further editing, Rene Hexel's <a href="ftp://ftp.NetBSD.org/pub/NetBSD/packages/pkgsrc/pkgtools/createbuildlink/README.html" target="_top"><code class="filename">pkgtools/createbuildlink</code></a> - package is highly recommended. For most packages, the following - command will generate a good starting point for - <code class="filename">buildlink3.mk</code> files:</p> -<pre class="screen"><code class="prompt">%</code> <strong class="userinput"><code>cd pkgsrc/<em class="replaceable"><code>category</code></em>/<em class="replaceable"><code>pkgdir</code></em> -<code class="prompt">%</code> createbuildlink >buildlink3.mk</code></strong></pre> +<p>A package's <code class="filename">buildlink3.mk</code> file is + included by Makefiles to indicate the need to compile and link + against header files and libraries provided by the package. A + <code class="filename">buildlink3.mk</code> file should always provide + enough information to add the correct type of dependency + relationship and include any other + <code class="filename">buildlink3.mk</code> files that it needs to find + headers and libraries that it needs in turn.</p> +<p>To generate an initial <code class="filename">buildlink3.mk</code> + file for further editing, Rene Hexel's <a href="ftp://ftp.NetBSD.org/pub/NetBSD/packages/pkgsrc/pkgtools/createbuildlink/README.html" target="_top"><code class="filename">pkgtools/createbuildlink</code></a> + package is highly recommended. For most packages, the following + command will generate a good starting point for + <code class="filename">buildlink3.mk</code> files:</p> +<pre class="screen"> +<code class="prompt">%</code> <strong class="userinput"><code>cd pkgsrc/<em class="replaceable"><code>category</code></em>/<em class="replaceable"><code>pkgdir</code></em> +<code class="prompt">%</code> createbuildlink >buildlink3.mk</code></strong> + </pre> <div class="sect2" lang="en"> <div class="titlepage"><div><div><h3 class="title"> <a name="anatomy-of-bl3"></a>12.2.1. Anatomy of a buildlink3.mk file</h3></div></div></div> <p>The following real-life example - <code class="filename">buildlink3.mk</code> is taken - from <code class="filename">pkgsrc/graphics/tiff</code>:</p> + <code class="filename">buildlink3.mk</code> is taken + from <code class="filename">pkgsrc/graphics/tiff</code>:</p> <pre class="programlisting"> - # $NetBSD: buildlink3.mk,v 1.7 2004/03/18 09:12:12 jlam Exp $ + # $NetBSD: buildlink3.mk,v 1.7 2004/03/18 09:12:12 jlam Exp $ - BUILDLINK_DEPTH:= ${BUILDLINK_DEPTH}+ - TIFF_BUILDLINK3_MK:= ${TIFF_BUILDLINK3_MK}+ + BUILDLINK_DEPTH:= ${BUILDLINK_DEPTH}+ + TIFF_BUILDLINK3_MK:= ${TIFF_BUILDLINK3_MK}+ - .if !empty(BUILDLINK_DEPTH:M+) - BUILDLINK_DEPENDS+= tiff - .endif + .if !empty(BUILDLINK_DEPTH:M+) + BUILDLINK_DEPENDS+= tiff + .endif - BUILDLINK_PACKAGES:= ${BUILDLINK_PACKAGES:Ntiff} - BUILDLINK_PACKAGES+= tiff + BUILDLINK_PACKAGES:= ${BUILDLINK_PACKAGES:Ntiff} + BUILDLINK_PACKAGES+= tiff - .if !empty(TIFF_BUILDLINK3_MK:M+) - BUILDLINK_API_DEPENDS.tiff+= tiff>=3.6.1 - BUILDLINK_PKGSRCDIR.tiff?= ../../graphics/tiff - .endif # TIFF_BUILDLINK3_MK + .if !empty(TIFF_BUILDLINK3_MK:M+) + BUILDLINK_API_DEPENDS.tiff+= tiff>=3.6.1 + BUILDLINK_PKGSRCDIR.tiff?= ../../graphics/tiff + .endif # TIFF_BUILDLINK3_MK - .include "../../devel/zlib/buildlink3.mk" - .include "../../graphics/jpeg/buildlink3.mk" + .include "../../devel/zlib/buildlink3.mk" + .include "../../graphics/jpeg/buildlink3.mk" - BUILDLINK_DEPTH:= ${BUILDLINK_DEPTH:S/+$//} -</pre> -<p> The header and footer manipulate - <code class="varname">BUILDLINK_DEPTH</code>, which is common across all - <code class="filename">buildlink3.mk</code> files and is used to track - at what depth we are including - <code class="filename">buildlink3.mk</code> files.</p> -<p> The first section controls if the dependency on - <em class="replaceable"><code>pkg</code></em> is added. - <code class="varname">BUILDLINK_DEPENDS</code> is the global list of - packages for which dependencies are added by - buildlink3.</p> -<p> The second section advises pkgsrc that the - <code class="filename">buildlink3.mk</code> file for - <em class="replaceable"><code>pkg</code></em> has been included at some point. - <code class="varname">BUILDLINK_PACKAGES</code> is the global list of - packages for which <code class="filename">buildlink3.mk</code> files - have been included. It must <span class="emphasis"><em>always</em></span> be - appended to within a <code class="filename">buildlink3.mk</code> - file. </p> -<p> The third section is protected from multiple inclusion - and controls how the dependency on <em class="replaceable"><code>pkg</code></em> is - added. Several important variables are set in the section: - </p> + BUILDLINK_DEPTH:= ${BUILDLINK_DEPTH:S/+$//} + </pre> +<p>The header and footer manipulate + <code class="varname">BUILDLINK_DEPTH</code>, which is common across all + <code class="filename">buildlink3.mk</code> files and is used to track + at what depth we are including + <code class="filename">buildlink3.mk</code> files.</p> +<p>The first section controls if the dependency on + <em class="replaceable"><code>pkg</code></em> is added. + <code class="varname">BUILDLINK_DEPENDS</code> is the global list of + packages for which dependencies are added by + buildlink3.</p> +<p>The second section advises pkgsrc that the + <code class="filename">buildlink3.mk</code> file for + <em class="replaceable"><code>pkg</code></em> has been included at some point. + <code class="varname">BUILDLINK_PACKAGES</code> is the global list of + packages for which <code class="filename">buildlink3.mk</code> files + have been included. It must <span class="emphasis"><em>always</em></span> be + appended to within a <code class="filename">buildlink3.mk</code> + file.</p> +<p>The third section is protected from multiple inclusion + and controls how the dependency on <em class="replaceable"><code>pkg</code></em> is + added. Several important variables are set in the section:</p> <div class="itemizedlist"><ul type="disc"> -<li><p> <code class="varname">BUILDLINK_API_DEPENDS.<em class="replaceable"><code>pkg</code></em></code> - is the actual dependency recorded in the installed - package; this should always be set using - <span><strong class="command">+=</strong></span> to ensure that - we're appending to any pre-existing list of values. This - variable should be set to the first version of the - package that had an API change. - </p></li> -<li><p> <code class="varname">BUILDLINK_PKGSRCDIR.<em class="replaceable"><code>pkg</code></em></code> - is the location of the <em class="replaceable"><code>pkg</code></em> - pkgsrc directory.</p></li> -<li><p> - <code class="varname">BUILDLINK_DEPMETHOD.<em class="replaceable"><code>pkg</code></em></code> - (not shown above) controls whether we use - <code class="varname">BUILD_DEPENDS</code> or - <code class="varname">DEPENDS</code> to add the dependency on - <em class="replaceable"><code>pkg</code></em>. - The build dependency is selected by setting - <code class="varname">BUILDLINK_DEPMETHOD.<em class="replaceable"><code>pkg</code></em></code> - to “<span class="quote">build</span>”. By default, the - full dependency is used. - </p></li> -<li><p> - <code class="varname">BUILDLINK_INCDIRS.<em class="replaceable"><code>pkg</code></em></code> +<li><p><code class="varname">BUILDLINK_API_DEPENDS.<em class="replaceable"><code>pkg</code></em></code> + is the actual dependency recorded in the installed + package; this should always be set using + <span><strong class="command">+=</strong></span> to ensure that + we're appending to any pre-existing list of values. This + variable should be set to the first version of the + package that had an API change. + </p></li> +<li><p><code class="varname">BUILDLINK_PKGSRCDIR.<em class="replaceable"><code>pkg</code></em></code> + is the location of the <em class="replaceable"><code>pkg</code></em> + pkgsrc directory.</p></li> +<li><p><code class="varname">BUILDLINK_DEPMETHOD.<em class="replaceable"><code>pkg</code></em></code> + (not shown above) controls whether we use + <code class="varname">BUILD_DEPENDS</code> or + <code class="varname">DEPENDS</code> to add the dependency on + <em class="replaceable"><code>pkg</code></em>. The build dependency is + selected by setting + <code class="varname">BUILDLINK_DEPMETHOD.<em class="replaceable"><code>pkg</code></em></code> + to “<span class="quote">build</span>”. By default, the full dependency is + used.</p></li> +<li><p><code class="varname">BUILDLINK_INCDIRS.<em class="replaceable"><code>pkg</code></em></code> and <code class="varname">BUILDLINK_LIBDIRS.<em class="replaceable"><code>pkg</code></em></code> (not shown above) are lists of subdirectories of <code class="filename">${BUILDLINK_PREFIX.<em class="replaceable"><code>pkg</code></em>}</code> to add to the header and library search paths. These default to “<span class="quote">include</span>” and “<span class="quote">lib</span>” - respectively. </p></li> -<li><p> - <code class="varname">BUILDLINK_CPPFLAGS.<em class="replaceable"><code>pkg</code></em></code> + respectively.</p></li> +<li><p><code class="varname">BUILDLINK_CPPFLAGS.<em class="replaceable"><code>pkg</code></em></code> (not shown above) is the list of preprocessor flags to add to <code class="varname">CPPFLAGS</code>, which are passed on to the configure and build phases. The “<span class="quote">-I</span>” option should be avoided and instead be handled using <code class="varname">BUILDLINK_INCDIRS.<em class="replaceable"><code>pkg</code></em></code> as - above.</p></li> + above.</p></li> </ul></div> -<p> The following variables are all optionally defined within - this second section (protected against multiple inclusion) and - control which package files are symlinked into - <code class="filename">${BUILDLINK_DIR}</code> and how their names are - transformed during the symlinking: </p> +<p>The following variables are all optionally defined within + this second section (protected against multiple inclusion) and + control which package files are symlinked into + <code class="filename">${BUILDLINK_DIR}</code> and how their names are + transformed during the symlinking:</p> <div class="itemizedlist"><ul type="disc"> -<li><p> - <code class="varname">BUILDLINK_FILES.<em class="replaceable"><code>pkg</code></em></code> +<li><p><code class="varname">BUILDLINK_FILES.<em class="replaceable"><code>pkg</code></em></code> (not shown above) is a shell glob pattern relative to <code class="filename">${BUILDLINK_PREFIX.<em class="replaceable"><code>pkg</code></em>}</code> to be symlinked into <code class="filename">${BUILDLINK_DIR}</code>, - e.g. <code class="filename">include/*.h</code>. </p></li> -<li><p> - <code class="varname">BUILDLINK_FILES_CMD.<em class="replaceable"><code>pkg</code></em></code> - (not shown above) is a shell pipeline that - outputs to stdout a list of files relative to - <code class="filename">${BUILDLINK_PREFIX.<em class="replaceable"><code>pkg</code></em>}</code>. - The resulting files are to be symlinked - into <code class="filename">${BUILDLINK_DIR}</code>. By default, - this takes the <code class="filename">+CONTENTS</code> of a - <em class="replaceable"><code>pkg</code></em> and filters it through - <code class="varname">${BUILDLINK_CONTENTS_FILTER.<em class="replaceable"><code>pkg</code></em>}</code>. - </p></li> -<li><p> - <code class="varname">BUILDLINK_CONTENTS_FILTER.<em class="replaceable"><code>pkg</code></em></code> + e.g. <code class="filename">include/*.h</code>.</p></li> +<li><p><code class="varname">BUILDLINK_FILES_CMD.<em class="replaceable"><code>pkg</code></em></code> + (not shown above) is a shell pipeline that + outputs to stdout a list of files relative to + <code class="filename">${BUILDLINK_PREFIX.<em class="replaceable"><code>pkg</code></em>}</code>. + The resulting files are to be symlinked + into <code class="filename">${BUILDLINK_DIR}</code>. By default, + this takes the <code class="filename">+CONTENTS</code> of a + <em class="replaceable"><code>pkg</code></em> and filters it through + <code class="varname">${BUILDLINK_CONTENTS_FILTER.<em class="replaceable"><code>pkg</code></em>}</code>.</p></li> +<li><p><code class="varname">BUILDLINK_CONTENTS_FILTER.<em class="replaceable"><code>pkg</code></em></code> (not shown above) is a filter command that filters <code class="filename">+CONTENTS</code> input into a list of files relative to @@ -4997,228 +4995,211 @@ a security check before building any package. See and <code class="filename">lib</code> directories in the package <code class="filename">+CONTENTS</code>, and for pkgviews packages, it outputs any libtool archives in - <code class="filename">lib</code> directories. - </p></li> -<li><p> - <code class="varname">BUILDLINK_TRANSFORM.<em class="replaceable"><code>pkg</code></em></code> + <code class="filename">lib</code> directories.</p></li> +<li><p><code class="varname">BUILDLINK_TRANSFORM.<em class="replaceable"><code>pkg</code></em></code> (not shown above) is a list of sed arguments used to transform the name of the source filename into a destination filename, e.g. <span><strong class="command">-e - "s|/curses.h|/ncurses.h|g"</strong></span>. - </p></li> + "s|/curses.h|/ncurses.h|g"</strong></span>.</p></li> </ul></div> -<p> The last section includes any - <code class="filename">buildlink3.mk</code> needed for - <em class="replaceable"><code>pkg</code></em>'s library dependencies. - Including these <code class="filename">buildlink3.mk</code> files - means that the headers and libraries for these - dependencies are also symlinked into - <code class="filename">${BUILDLINK_DIR}</code> - whenever the <em class="replaceable"><code>pkg</code></em> - <code class="filename">buildlink3.mk</code> - file is included. - </p> +<p>The last section includes any + <code class="filename">buildlink3.mk</code> needed for + <em class="replaceable"><code>pkg</code></em>'s library dependencies. + Including these <code class="filename">buildlink3.mk</code> files + means that the headers and libraries for these + dependencies are also symlinked into + <code class="filename">${BUILDLINK_DIR}</code> + whenever the <em class="replaceable"><code>pkg</code></em> + <code class="filename">buildlink3.mk</code> + file is included.</p> </div> <div class="sect2" lang="en"> <div class="titlepage"><div><div><h3 class="title"> <a name="updating-buildlink-depends"></a>12.2.2. Updating <code class="varname">BUILDLINK_API_DEPENDS.<em class="replaceable"><code>pkg</code></em></code> in <code class="filename">buildlink3.mk</code> files</h3></div></div></div> -<p> - The situation that requires increasing the dependency listed in +<p>The situation that requires increasing the dependency listed in <code class="varname">BUILDLINK_API_DEPENDS.<em class="replaceable"><code>pkg</code></em></code> after a package update is when the API or interface to the - header files change.</p> -<p> In this case, - <code class="varname">BUILDLINK_API_DEPENDS.<em class="replaceable"><code>pkg</code></em></code> - should be adjusted to require at least the new package - version. In some cases, the packages that depend on this new - version may need their <code class="varname">PKGREVISION</code>s - increased and, if they have <code class="filename">buildlink3.mk</code> - files, their - <code class="varname">BUILDLINK_API_DEPENDS.<em class="replaceable"><code>pkg</code></em></code> - adjusted, too. This is needed so pkgsrc will require the - correct package dependency and not settle for an older one - when building the source.</p> -<p> - <code class="varname">BUILDLINK_ABI_DEPENDS.<em class="replaceable"><code>pkg</code></em></code> + header files change.</p> +<p>In this case, + <code class="varname">BUILDLINK_API_DEPENDS.<em class="replaceable"><code>pkg</code></em></code> + should be adjusted to require at least the new package + version. In some cases, the packages that depend on this new + version may need their <code class="varname">PKGREVISION</code>s + increased and, if they have <code class="filename">buildlink3.mk</code> + files, their + <code class="varname">BUILDLINK_API_DEPENDS.<em class="replaceable"><code>pkg</code></em></code> + adjusted, too. This is needed so pkgsrc will require the + correct package dependency and not settle for an older one + when building the source.</p> +<p><code class="varname">BUILDLINK_ABI_DEPENDS.<em class="replaceable"><code>pkg</code></em></code> should be increased when the binary interface or sonames (major number of the library version) of any installed shared libraries change. This is needed so that binary packages made using it will require the correct package dependency and not settle for an older one which will not - contain the necessary shared libraries. </p> -<p> - See <a href="#dependencies" title="17.1.6. Handling dependencies">Section 17.1.6, “Handling dependencies”</a> for + contain the necessary shared libraries.</p> +<p>See <a href="#dependencies" title="17.1.6. Handling dependencies">Section 17.1.6, “Handling dependencies”</a> for more information about dependencies on other packages, including the <code class="varname">BUILDLINK_ABI_DEPENDS</code> and - <code class="varname">ABI_DEPENDS</code> definitions. </p> -<p> Please take careful consideration before adjusting - <code class="varname">BUILDLINK_API_DEPENDS.<em class="replaceable"><code>pkg</code></em></code> - or - <code class="varname">BUILDLINK_ABI_DEPENDS.<em class="replaceable"><code>pkg</code></em></code> - as we don't want to cause unneeded package deletions and - rebuilds. In many cases, new versions of packages work just - fine with older dependencies.</p> -<p> - Also it is not needed to set + <code class="varname">ABI_DEPENDS</code> definitions.</p> +<p>Please take careful consideration before adjusting + <code class="varname">BUILDLINK_API_DEPENDS.<em class="replaceable"><code>pkg</code></em></code> + or + <code class="varname">BUILDLINK_ABI_DEPENDS.<em class="replaceable"><code>pkg</code></em></code> + as we don't want to cause unneeded package deletions and + rebuilds. In many cases, new versions of packages work just + fine with older dependencies.</p> +<p>Also it is not needed to set <code class="varname">BUILDLINK_ABI_DEPENDS.<em class="replaceable"><code>pkg</code></em></code> when it is identical to - <code class="varname">BUILDLINK_API_DEPENDS.<em class="replaceable"><code>pkg</code></em></code>. </p> + <code class="varname">BUILDLINK_API_DEPENDS.<em class="replaceable"><code>pkg</code></em></code>. </p> </div> </div> <div class="sect1" lang="en"> <div class="titlepage"><div><div><h2 class="title" style="clear: both"> <a name="writing-builtin.mk"></a>12.3. Writing <code class="filename">builtin.mk</code> files</h2></div></div></div> -<p> - Some packages in pkgsrc install headers and libraries that +<p>Some packages in pkgsrc install headers and libraries that coincide with headers and libraries present in the base system. Aside from a <code class="filename">buildlink3.mk</code> file, these packages should also include a <code class="filename">builtin.mk</code> file that includes the necessary checks to decide whether using the built-in software or the pkgsrc software is - appropriate. </p> -<p> The only requirements of a builtin.mk file for - <em class="replaceable"><code>pkg</code></em> are: - </p> + appropriate.</p> +<p>The only requirements of a builtin.mk file for + <em class="replaceable"><code>pkg</code></em> are:</p> <div class="orderedlist"><ol type="1"> -<li><p> It should set - <code class="varname">USE_BUILTIN.<em class="replaceable"><code>pkg</code></em></code> - to either “<span class="quote">yes</span>” or “<span class="quote">no</span>” - after it is included. - </p></li> -<li><p> It should <span class="emphasis"><em>not</em></span> override any - <code class="varname">USE_BUILTIN.<em class="replaceable"><code>pkg</code></em></code> - which is already set before the - <code class="filename">builtin.mk</code> file is included. - </p></li> -<li><p> It should be written to allow multiple inclusion. This - is <span class="emphasis"><em>very</em></span> important and takes careful - attention to <code class="filename">Makefile</code> coding. - </p></li> +<li><p>It should set + <code class="varname">USE_BUILTIN.<em class="replaceable"><code>pkg</code></em></code> + to either “<span class="quote">yes</span>” or “<span class="quote">no</span>” + after it is included.</p></li> +<li><p>It should <span class="emphasis"><em>not</em></span> override any + <code class="varname">USE_BUILTIN.<em class="replaceable"><code>pkg</code></em></code> + which is already set before the + <code class="filename">builtin.mk</code> file is included.</p></li> +<li><p>It should be written to allow multiple inclusion. This + is <span class="emphasis"><em>very</em></span> important and takes careful + attention to <code class="filename">Makefile</code> coding.</p></li> </ol></div> <div class="sect2" lang="en"> <div class="titlepage"><div><div><h3 class="title"> <a name="anatomy-of-builtin.mk"></a>12.3.1. Anatomy of a <code class="filename">builtin.mk</code> file</h3></div></div></div> <p>The following is the recommended template for builtin.mk - files: </p> + files:</p> <pre class="programlisting"> - .if !defined(IS_BUILTIN.foo) - # - # IS_BUILTIN.foo is set to "yes" or "no" depending on whether "foo" - # genuinely exists in the system or not. - # - IS_BUILTIN.foo?= no + .if !defined(IS_BUILTIN.foo) + # + # IS_BUILTIN.foo is set to "yes" or "no" depending on whether "foo" + # genuinely exists in the system or not. + # + IS_BUILTIN.foo?= no - # BUILTIN_PKG.foo should be set here if "foo" is built-in and its package - # version can be determined. - # - . if !empty(IS_BUILTIN.foo:M[yY][eE][sS]) - BUILTIN_PKG.foo?= foo-1.0 - . endif - .endif # IS_BUILTIN.foo + # BUILTIN_PKG.foo should be set here if "foo" is built-in and its package + # version can be determined. + # + . if !empty(IS_BUILTIN.foo:M[yY][eE][sS]) + BUILTIN_PKG.foo?= foo-1.0 + . endif + .endif # IS_BUILTIN.foo - .if !defined(USE_BUILTIN.foo) - USE_BUILTIN.foo?= ${IS_BUILTIN.foo} - . if defined(BUILTIN_PKG.foo) - . for _depend_ in ${BUILDLINK_API_DEPENDS.foo} - . if !empty(USE_BUILTIN.foo:M[yY][eE][sS]) - USE_BUILTIN.foo!= \ - if ${PKG_ADMIN} pmatch '${_depend_}' ${BUILTIN_PKG.foo}; then \ - ${ECHO} "yes"; \ - else \ - ${ECHO} "no"; \ - fi - . endif - . endfor - . endif - .endif # USE_BUILTIN.foo + .if !defined(USE_BUILTIN.foo) + USE_BUILTIN.foo?= ${IS_BUILTIN.foo} + . if defined(BUILTIN_PKG.foo) + . for _depend_ in ${BUILDLINK_API_DEPENDS.foo} + . if !empty(USE_BUILTIN.foo:M[yY][eE][sS]) + USE_BUILTIN.foo!= \ + if ${PKG_ADMIN} pmatch '${_depend_}' ${BUILTIN_PKG.foo}; then \ + ${ECHO} "yes"; \ + else \ + ${ECHO} "no"; \ + fi + . endif + . endfor + . endif + .endif # USE_BUILTIN.foo - CHECK_BUILTIN.foo?= no - .if !empty(CHECK_BUILTIN.foo:M[nN][oO]) - # - # Here we place code that depends on whether USE_BUILTIN.foo is set to - # "yes" or "no". - # - .endif # CHECK_BUILTIN.foo -</pre> -<p> The first section sets - <code class="varname">IS_BUILTIN.<em class="replaceable"><code>pkg</code></em></code> - depending on if <em class="replaceable"><code>pkg</code></em> really exists - in the base system. This should not be a base system software - with similar functionality to <em class="replaceable"><code>pkg</code></em>; - it should only be “<span class="quote">yes</span>” if the actual package is - included as part of the base system. This variable is only - used internally within the <code class="filename">builtin.mk</code> - file. </p> -<p> The second section sets - <code class="varname">BUILTIN_PKG.<em class="replaceable"><code>pkg</code></em></code> - to the version of <em class="replaceable"><code>pkg</code></em> in the base - system if it exists (if - <code class="varname">IS_BUILTIN.<em class="replaceable"><code>pkg</code></em></code> - is “<span class="quote">yes</span>”). This variable is only used internally - within the <code class="filename">builtin.mk</code> file. </p> -<p> The third section sets - <code class="varname">USE_BUILTIN.<em class="replaceable"><code>pkg</code></em></code> - and is <span class="emphasis"><em>required</em></span> in all - <code class="filename">builtin.mk</code> files. The code in this - section must make the determination whether the built-in - software is adequate to satisfy the dependencies listed in - <code class="varname">BUILDLINK_API_DEPENDS.<em class="replaceable"><code>pkg</code></em></code>. - This is typically done by comparing - <code class="varname">BUILTIN_PKG.<em class="replaceable"><code>pkg</code></em></code> - against each of the dependencies in - <code class="varname">BUILDLINK_API_DEPENDS.<em class="replaceable"><code>pkg</code></em></code>. - <code class="varname">USE_BUILTIN.<em class="replaceable"><code>pkg</code></em></code> - <span class="emphasis"><em>must</em></span> be set to the correct value by the - end of the <code class="filename">builtin.mk</code> file. Note that - <code class="varname">USE_BUILTIN.<em class="replaceable"><code>pkg</code></em></code> - may be “<span class="quote">yes</span>” even if - <code class="varname">IS_BUILTIN.<em class="replaceable"><code>pkg</code></em></code> - is “<span class="quote">no</span>” because we may make the determination - that the built-in version of the software is similar enough to - be used as a replacement. </p> -<p> The last section is guarded by - <code class="varname">CHECK_BUILTIN.<em class="replaceable"><code>pkg</code></em></code>, - and includes code that uses the value of - <code class="varname">USE_BUILTIN.<em class="replaceable"><code>pkg</code></em></code> - set in the previous section. This typically includes, e.g., - adding additional dependency restrictions and listing - additional files to symlink into - <code class="filename">${BUILDLINK_DIR}</code> (via - <code class="varname">BUILDLINK_FILES.<em class="replaceable"><code>pkg</code></em></code>). - </p> + CHECK_BUILTIN.foo?= no + .if !empty(CHECK_BUILTIN.foo:M[nN][oO]) + # + # Here we place code that depends on whether USE_BUILTIN.foo is set to + # "yes" or "no". + # + .endif # CHECK_BUILTIN.foo + </pre> +<p>The first section sets + <code class="varname">IS_BUILTIN.<em class="replaceable"><code>pkg</code></em></code> + depending on if <em class="replaceable"><code>pkg</code></em> really exists + in the base system. This should not be a base system software + with similar functionality to <em class="replaceable"><code>pkg</code></em>; + it should only be “<span class="quote">yes</span>” if the actual package is + included as part of the base system. This variable is only + used internally within the <code class="filename">builtin.mk</code> + file.</p> +<p>The second section sets + <code class="varname">BUILTIN_PKG.<em class="replaceable"><code>pkg</code></em></code> + to the version of <em class="replaceable"><code>pkg</code></em> in the base + system if it exists (if + <code class="varname">IS_BUILTIN.<em class="replaceable"><code>pkg</code></em></code> + is “<span class="quote">yes</span>”). This variable is only used internally + within the <code class="filename">builtin.mk</code> file.</p> +<p>The third section sets + <code class="varname">USE_BUILTIN.<em class="replaceable"><code>pkg</code></em></code> + and is <span class="emphasis"><em>required</em></span> in all + <code class="filename">builtin.mk</code> files. The code in this + section must make the determination whether the built-in + software is adequate to satisfy the dependencies listed in + <code class="varname">BUILDLINK_API_DEPENDS.<em class="replaceable"><code>pkg</code></em></code>. + This is typically done by comparing + <code class="varname">BUILTIN_PKG.<em class="replaceable"><code>pkg</code></em></code> + against each of the dependencies in + <code class="varname">BUILDLINK_API_DEPENDS.<em class="replaceable"><code>pkg</code></em></code>. + <code class="varname">USE_BUILTIN.<em class="replaceable"><code>pkg</code></em></code> + <span class="emphasis"><em>must</em></span> be set to the correct value by the + end of the <code class="filename">builtin.mk</code> file. Note that + <code class="varname">USE_BUILTIN.<em class="replaceable"><code>pkg</code></em></code> + may be “<span class="quote">yes</span>” even if + <code class="varname">IS_BUILTIN.<em class="replaceable"><code>pkg</code></em></code> + is “<span class="quote">no</span>” because we may make the determination + that the built-in version of the software is similar enough to + be used as a replacement.</p> +<p>The last section is guarded by + <code class="varname">CHECK_BUILTIN.<em class="replaceable"><code>pkg</code></em></code>, + and includes code that uses the value of + <code class="varname">USE_BUILTIN.<em class="replaceable"><code>pkg</code></em></code> + set in the previous section. This typically includes, e.g., + adding additional dependency restrictions and listing additional + files to symlink into <code class="filename">${BUILDLINK_DIR}</code> (via + <code class="varname">BUILDLINK_FILES.<em class="replaceable"><code>pkg</code></em></code>).</p> </div> <div class="sect2" lang="en"> <div class="titlepage"><div><div><h3 class="title"> <a name="native-or-pkgsrc-preference"></a>12.3.2. Global preferences for native or pkgsrc software</h3></div></div></div> -<p> - When building packages, it's possible to choose whether to set - a global preference for using either the built-in (native) - version or the pkgsrc version of software to satisfy a - dependency. This is controlled by setting - <code class="varname">PREFER_PKGSRC</code> and - <code class="varname">PREFER_NATIVE</code>. These variables take values - of either “<span class="quote">yes</span>”, “<span class="quote">no</span>”, or a list of - packages. <code class="varname">PREFER_PKGSRC</code> tells pkgsrc to - use the pkgsrc versions of software, while - <code class="varname">PREFER_NATIVE</code> tells pkgsrc to use the - built-in versions. Preferences are determined by the most - specific instance of the package in either - <code class="varname">PREFER_PKGSRC</code> or - <code class="varname">PREFER_NATIVE</code>. If a package is specified - in neither or in both variables, then - <code class="varname">PREFER_PKGSRC</code> has precedence over - <code class="varname">PREFER_NATIVE</code>. For example, to require - using pkgsrc versions of software for all but the most basic - bits on a NetBSD system, you can set: </p> +<p>When building packages, it's possible to choose whether to set + a global preference for using either the built-in (native) + version or the pkgsrc version of software to satisfy a + dependency. This is controlled by setting + <code class="varname">PREFER_PKGSRC</code> and + <code class="varname">PREFER_NATIVE</code>. These variables take values + of either “<span class="quote">yes</span>”, “<span class="quote">no</span>”, or a list of + packages. <code class="varname">PREFER_PKGSRC</code> tells pkgsrc to + use the pkgsrc versions of software, while + <code class="varname">PREFER_NATIVE</code> tells pkgsrc to use the + built-in versions. Preferences are determined by the most + specific instance of the package in either + <code class="varname">PREFER_PKGSRC</code> or + <code class="varname">PREFER_NATIVE</code>. If a package is specified + in neither or in both variables, then + <code class="varname">PREFER_PKGSRC</code> has precedence over + <code class="varname">PREFER_NATIVE</code>. For example, to require + using pkgsrc versions of software for all but the most basic + bits on a NetBSD system, you can set:</p> <pre class="programlisting"> - PREFER_PKGSRC= yes - PREFER_NATIVE= getopt skey tcp_wrappers -</pre> -<p> A package <span class="emphasis"><em>must</em></span> have a - <code class="filename">builtin.mk</code> - file to be listed in <code class="varname">PREFER_NATIVE</code>, - otherwise it is simply ignored in that list. - </p> + PREFER_PKGSRC= yes + PREFER_NATIVE= getopt skey tcp_wrappers + </pre> +<p>A package <span class="emphasis"><em>must</em></span> have a + <code class="filename">builtin.mk</code> + file to be listed in <code class="varname">PREFER_NATIVE</code>, + otherwise it is simply ignored in that list.</p> </div> </div> </div> @@ -5280,15 +5261,29 @@ which means that it cannot register files outside this directory (absolute path names are not allowed). Despite this restriction, some packages need to install files outside this location; e.g., under <code class="filename">${VARBASE}</code> or -<code class="filename">${PKG_SYSCONFDIR}</code>.</p> -<p>The only way to achieve this is to create such files during -installation time by using the installation scripts. These scripts can run -arbitrary commands, so they have the potential to create and manage files -anywhere in the file system. Here is where pkginstall comes into play: it -provides generic scripts to abstract the manipulation of such files and -directories based on variables set in the package's -<code class="filename">Makefile</code>. The rest of this section describes these -variables.</p> +<code class="filename">${PKG_SYSCONFDIR}</code>. The only way to achieve this +is to create such files during installation time by using +installation scripts.</p> +<p>The generic installation scripts are shell scripts that can +contain arbitrary code. The list of scripts to execute is taken from +the <code class="varname">INSTALL_FILE</code> variable, which defaults to +<code class="filename">INSTALL</code>. A similar variable exists for package +removal (<code class="varname">DEINSTALL_FILE</code>, whose default is +<code class="filename">DEINSTALL</code>). These scripts can run arbitrary +commands, so they have the potential to create and manage files +anywhere in the file system.</p> +<p>Using these general installation files is not recommended, but +may be needed in some special cases. One reason for avoiding them is +that the user has to trust the packager that there is no unwanted or +simply erroneous code included in the installation script. Also, +previously there were many similar scripts for the same functionality, +and fixing a common error involved finding and changing all of +them.</p> +<p>The pkginstall framework offers another, standardized way. It +provides generic scripts to abstract the manipulation of such files +and directories based on variables set in the package's +<code class="filename">Makefile</code>. The rest of this section describes +these variables.</p> <div class="sect2" lang="en"> <div class="titlepage"><div><div><h3 class="title"> <a name="dirs-outside-prefix"></a>13.1.1. Directory manipulation</h3></div></div></div> @@ -5533,18 +5528,18 @@ syntax:</p> <pre class="programlisting"> user:group </pre> -<p>Further specification of user details may be done by setting per-user -variables. -<code class="varname">PKG_UID.<em class="replaceable"><code>user</code></em></code> is the numeric -UID for the user. -<code class="varname">PKG_GECOS.<em class="replaceable"><code>user</code></em></code> is the user's -description or comment. -<code class="varname">PKG_HOME.<em class="replaceable"><code>user</code></em></code> is the user's -home directory, and defaults to <code class="filename">/nonexistent</code> if not -specified. -<code class="varname">PKG_SHELL.<em class="replaceable"><code>user</code></em></code> is the user's -shell, and defaults to <code class="filename">/sbinno/login</code> if not specified. -</p> +<p>Further specification of user details may be done by setting +per-user variables. +<code class="varname">PKG_UID.<em class="replaceable"><code>user</code></em></code> is the +numeric UID for the user. +<code class="varname">PKG_GECOS.<em class="replaceable"><code>user</code></em></code> is the +user's description or comment. +<code class="varname">PKG_HOME.<em class="replaceable"><code>user</code></em></code> is the +user's home directory, and defaults to +<code class="filename">/nonexistent</code> if not specified. +<code class="varname">PKG_SHELL.<em class="replaceable"><code>user</code></em></code> is the +user's shell, and defaults to <code class="filename">/sbinno/login</code> if +not specified.</p> <p>Similarly, groups can be created by adding entries to the <code class="varname">PKG_GROUPS</code> variable, whose syntax is:</p> <pre class="programlisting"> @@ -5830,158 +5825,158 @@ support.</span>” The file is sorted by option names.</p> <div class="titlepage"><div><div><h2 class="title" style="clear: both"> <a name="build.intro"></a>15.1. Introduction</h2></div></div></div> <p>This chapter gives a detailed description on how a package is -built. Building a package is separated into different -<span class="emphasis"><em>phases</em></span> (for example <code class="varname">fetch</code>, -<code class="varname">build</code>, <code class="varname">install</code>), all of which are -described in the following sections. Each phase is splitted into -so-called <span class="emphasis"><em>stages</em></span>, which take the name of the -containing phase, prefixed by one of <code class="varname">pre-</code>, -<code class="varname">do-</code> or <code class="varname">post-</code>. (Examples are -<code class="varname">pre-configure</code>, <code class="varname">post-build</code>.) Most -of the actual work is done in the <code class="varname">do-*</code> stages.</p> + built. Building a package is separated into different + <span class="emphasis"><em>phases</em></span> (for example <code class="varname">fetch</code>, + <code class="varname">build</code>, <code class="varname">install</code>), all of which are + described in the following sections. Each phase is splitted into + so-called <span class="emphasis"><em>stages</em></span>, which take the name of the + containing phase, prefixed by one of <code class="varname">pre-</code>, + <code class="varname">do-</code> or <code class="varname">post-</code>. (Examples are + <code class="varname">pre-configure</code>, <code class="varname">post-build</code>.) Most + of the actual work is done in the <code class="varname">do-*</code> stages.</p> <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 pkgsrc-specific patches -to compile properly 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.</p> + the program's source (<span class="emphasis"><em>distfile</em></span>) must be brought to + the local system and then extracted. After any pkgsrc-specific patches + to compile properly 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.</p> </div> <div class="sect1" lang="en"> <div class="titlepage"><div><div><h2 class="title" style="clear: both"> <a name="build.prefix"></a>15.2. Program location</h2></div></div></div> <p>Before outlining the process performed by the NetBSD package system in - the next section, here's a brief discussion on where programs are - installed, and which variables influence this.</p> + the next section, here's a brief discussion on where programs are + installed, and which variables influence this.</p> <p>The automatic variable <code class="varname">PREFIX</code> indicates - where all files of the final program shall be installed. It is - usually set to <code class="varname">LOCALBASE</code> - (<code class="filename">/usr/pkg</code>), or <code class="varname">CROSSBASE</code> - for pkgs in the “<span class="quote">cross</span>” category. The value of - <code class="varname">PREFIX</code> needs to be put - into the various places in the program's source where paths to - these files are encoded. See <a href="#components.patches" title="9.3. patches/*">Section 9.3, “patches/*”</a> and <a href="#fixes.libtool" title="17.3.1. Shared libraries - libtool">Section 17.3.1, “Shared libraries - libtool”</a> for more details.</p> + where all files of the final program shall be installed. It is + usually set to <code class="varname">LOCALBASE</code> + (<code class="filename">/usr/pkg</code>), or <code class="varname">CROSSBASE</code> + for pkgs in the “<span class="quote">cross</span>” category. The value of + <code class="varname">PREFIX</code> needs to be put + into the various places in the program's source where paths to + these files are encoded. See <a href="#components.patches" title="9.3. patches/*">Section 9.3, “patches/*”</a> and <a href="#fixes.libtool" title="17.3.1. Shared libraries - libtool">Section 17.3.1, “Shared libraries - libtool”</a> for more details.</p> <p>When choosing which of these variables to use, - follow the following rules:</p> + follow the following rules:</p> <div class="itemizedlist"><ul type="disc"> <li><p><code class="varname">PREFIX</code> always points to the location where the current - pkg will be installed. When referring to a pkg's own installation path, - use “<span class="quote">${PREFIX}</span>”.</p></li> + pkg will be installed. When referring to a pkg's own installation path, + use “<span class="quote">${PREFIX}</span>”.</p></li> <li><p><code class="varname">LOCALBASE</code> is where all non-X11 pkgs are installed. - If you need to construct a -I or -L argument to the compiler to find - includes and libraries installed by another non-X11 pkg, use - “<span class="quote">${LOCALBASE}</span>”. The name - <code class="varname">LOCALBASE</code> stems from FreeBSD, which - installed all packages in <code class="filename">/usr/local</code>. As - pkgsrc leaves <code class="filename">/usr/local</code> for the system - administrator, this variable is a misnomer.</p></li> + 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 + “<span class="quote">${LOCALBASE}</span>”. The name + <code class="varname">LOCALBASE</code> stems from FreeBSD, which + installed all packages in <code class="filename">/usr/local</code>. As + pkgsrc leaves <code class="filename">/usr/local</code> for the system + administrator, this variable is a misnomer.</p></li> <li><p><code class="varname">X11BASE</code> is where the actual X11 distribution (from - xsrc, etc.) is installed. When looking for - <span class="emphasis"><em>standard</em></span> X11 includes (not - those installed by a pkg), use “<span class="quote">${X11BASE}</span>”.</p></li> + xsrc, etc.) is installed. When looking for + <span class="emphasis"><em>standard</em></span> X11 includes (not + those installed by a pkg), use “<span class="quote">${X11BASE}</span>”.</p></li> <li> <p>X11-based packages are special in that they may be installed in - either <code class="varname">X11BASE</code> or <code class="varname">LOCALBASE</code>.</p> + either <code class="varname">X11BASE</code> or <code class="varname">LOCALBASE</code>.</p> <p>Usually, X11 packages should be installed under - <code class="varname">LOCALBASE</code> whenever possible. Note that you will - need to include <code class="filename">../../mk/x11.buildlink3.mk</code> - in them to request the - presence of X11 and to get the right compilation flags.</p> + <code class="varname">LOCALBASE</code> whenever possible. Note that you will + need to include <code class="filename">../../mk/x11.buildlink3.mk</code> + in them to request the + presence of X11 and to get the right compilation flags.</p> <p>Even though, there are some packages that cannot be installed - under <code class="varname">LOCALBASE</code>: those that come with app-defaults - files. These packages are special and they must be placed under - <code class="varname">X11BASE</code>. To accomplish this, set either - <code class="varname">USE_X11BASE</code> or <code class="varname">USE_IMAKE</code> in - your package.</p> + under <code class="varname">LOCALBASE</code>: those that come with app-defaults + files. These packages are special and they must be placed under + <code class="varname">X11BASE</code>. To accomplish this, set either + <code class="varname">USE_X11BASE</code> or <code class="varname">USE_IMAKE</code> in + your package.</p> <p>Some notes: If you need - to find includes or libraries installed by a pkg that has - <code class="varname">USE_IMAKE</code> or <code class="varname">USE_X11BASE</code> in - its pkg <code class="filename">Makefile</code>, you need to look in - <span class="emphasis"><em>both</em></span> <code class="filename">${X11BASE}</code> and - <code class="filename">${LOCALBASE}</code>. To force installation of - all X11 packages in <code class="varname">LOCALBASE</code>, the - <a href="ftp://ftp.NetBSD.org/pub/NetBSD/packages/pkgsrc/pkgtools/xpkgwedge/README.html" target="_top"><code class="filename">pkgtools/xpkgwedge</code></a> package - is enabled by default.</p> + to find includes or libraries installed by a pkg that has + <code class="varname">USE_IMAKE</code> or <code class="varname">USE_X11BASE</code> in + its pkg <code class="filename">Makefile</code>, you need to look in + <span class="emphasis"><em>both</em></span> <code class="filename">${X11BASE}</code> and + <code class="filename">${LOCALBASE}</code>. To force installation of + all X11 packages in <code class="varname">LOCALBASE</code>, the + <a href="ftp://ftp.NetBSD.org/pub/NetBSD/packages/pkgsrc/pkgtools/xpkgwedge/README.html" target="_top"><code class="filename">pkgtools/xpkgwedge</code></a> package + is enabled by default.</p> </li> <li><p><code class="varname">X11PREFIX</code> should be used to refer to the installed - location of an X11 package. <code class="varname">X11PREFIX</code> will be set to - <code class="varname">X11BASE</code> if xpkgwedge is not installed, - and to <code class="varname">LOCALBASE</code> if xpkgwedge is installed.</p></li> + location of an X11 package. <code class="varname">X11PREFIX</code> will be set to + <code class="varname">X11BASE</code> if xpkgwedge is not installed, + and to <code class="varname">LOCALBASE</code> if xpkgwedge is installed.</p></li> <li> <p>If xpkgwedge is installed, it is possible to have some packages installed - in <code class="varname">X11BASE</code> and some in <code class="varname">LOCALBASE</code>. - To determine the prefix of an installed package, the - <code class="varname">EVAL_PREFIX</code> definition can be used. It takes pairs in the - format “<span class="quote">DIRNAME=<package></span>”, and the <a href="http://netbsd.gw.com/cgi-bin/man-cgi?make+1+NetBSD-current"><span class="citerefentry"><span class="refentrytitle">make</span>(1)</span></a> variable - <code class="varname">DIRNAME</code> will be set to the prefix of the installed - package <package>, or “<span class="quote">${X11PREFIX}</span>” if the package is - not installed.</p> + in <code class="varname">X11BASE</code> and some in <code class="varname">LOCALBASE</code>. + To determine the prefix of an installed package, the + <code class="varname">EVAL_PREFIX</code> definition can be used. It takes pairs in the + format “<span class="quote">DIRNAME=<package></span>”, and the <a href="http://netbsd.gw.com/cgi-bin/man-cgi?make+1+NetBSD-current"><span class="citerefentry"><span class="refentrytitle">make</span>(1)</span></a> variable + <code class="varname">DIRNAME</code> will be set to the prefix of the installed + package <package>, or “<span class="quote">${X11PREFIX}</span>” if the package is + not installed.</p> <p>This is best illustrated by example.</p> <p>The following lines are taken from - <code class="filename">pkgsrc/wm/scwm/Makefile</code>:</p> + <code class="filename">pkgsrc/wm/scwm/Makefile</code>:</p> <pre class="programlisting"> - EVAL_PREFIX+= GTKDIR=gtk+ - CONFIGURE_ARGS+= --with-guile-prefix=${LOCALBASE:Q} - CONFIGURE_ARGS+= --with-gtk-prefix=${GTKDIR:Q} - CONFIGURE_ARGS+= --enable-multibyte -</pre> + EVAL_PREFIX+= GTKDIR=gtk+ + CONFIGURE_ARGS+= --with-guile-prefix=${LOCALBASE:Q} + CONFIGURE_ARGS+= --with-gtk-prefix=${GTKDIR:Q} + CONFIGURE_ARGS+= --enable-multibyte + </pre> <p>Specific defaults can be defined for the packages evaluated using - <code class="varname">EVAL_PREFIX</code>, by using a definition of the form:</p> + <code class="varname">EVAL_PREFIX</code>, by using a definition of the form:</p> <pre class="programlisting"> - GTKDIR_DEFAULT= ${LOCALBASE} -</pre> + GTKDIR_DEFAULT= ${LOCALBASE} + </pre> <p>where <code class="varname">GTKDIR</code> corresponds - to the first definition in - the <code class="varname">EVAL_PREFIX</code> pair.</p> + to the first definition in + the <code class="varname">EVAL_PREFIX</code> pair.</p> </li> <li><p>Within <code class="filename">${PREFIX}</code>, packages should - install files according to <a href="http://netbsd.gw.com/cgi-bin/man-cgi?hier+7+NetBSD-current"><span class="citerefentry"><span class="refentrytitle">hier</span>(7)</span></a>, with the exception that - manual pages go into <code class="filename">${PREFIX}/man</code>, not - <code class="filename">${PREFIX}/share/man</code>.</p></li> + install files according to <a href="http://netbsd.gw.com/cgi-bin/man-cgi?hier+7+NetBSD-current"><span class="citerefentry"><span class="refentrytitle">hier</span>(7)</span></a>, with the exception that + manual pages go into <code class="filename">${PREFIX}/man</code>, not + <code class="filename">${PREFIX}/share/man</code>.</p></li> </ul></div> </div> <div class="sect1" lang="en"> <div class="titlepage"><div><div><h2 class="title" style="clear: both"> <a name="build.builddirs"></a>15.3. Directories used during the build process</h2></div></div></div> <p>When building a package, a number of directories is used to store -source files, temporary files, pkgsrc-internal files, and so on. These -directories are explained here.</p> + source files, temporary files, pkgsrc-internal files, and so on. These + directories are explained here.</p> <p>Some of the directory variables contain relative pathnames. There -are two common base directories for these relative directories: -<code class="varname">PKGSRCDIR/PKGPATH</code> is used for directories that are -pkgsrc-specific. <code class="varname">WRKSRC</code> is used for directories -inside the package itself.</p> + are two common base directories for these relative directories: + <code class="varname">PKGSRCDIR/PKGPATH</code> is used for directories that are + pkgsrc-specific. <code class="varname">WRKSRC</code> is used for directories + inside the package itself.</p> <div class="variablelist"><dl> <dt><span class="term"><code class="varname">PKGSRCDIR</code></span></dt> <dd><p>This is an absolute pathname that points to the pkgsrc -root directory. Generally, you don't need -it.</p></dd> + root directory. Generally, you don't need + it.</p></dd> <dt><span class="term"><code class="varname">PKGPATH</code></span></dt> <dd><p>This is a pathname relative to -<code class="varname">PKGSRCDIR</code> that points to the current -package.</p></dd> + <code class="varname">PKGSRCDIR</code> that points to the current + package.</p></dd> <dt><span class="term"><code class="varname">WRKDIR</code></span></dt> <dd><p>This is an absolute pathname pointing to the directory -where all work takes place. The distfiles are extraced to this -directory. It also contains temporary directories and log files used by -the various pkgsrc frameworks, like <span class="emphasis"><em>buildlink</em></span> or -the <span class="emphasis"><em>wrappers</em></span>.</p></dd> + where all work takes place. The distfiles are extraced to this + directory. It also contains temporary directories and log files used by + the various pkgsrc frameworks, like <span class="emphasis"><em>buildlink</em></span> or + the <span class="emphasis"><em>wrappers</em></span>.</p></dd> <dt><span class="term"><code class="varname">WRKSRC</code></span></dt> <dd><p>This is an absolute pathname pointing to the directory -where the distfiles are extracted. It is usually a direct subdirectory -of <code class="varname">WRKDIR</code>, and often it's the only directory entry -that isn't hidden. This variable may be changed by a package -<code class="filename">Makefile</code>.</p></dd> + where the distfiles are extracted. It is usually a direct subdirectory + of <code class="varname">WRKDIR</code>, and often it's the only directory entry + that isn't hidden. This variable may be changed by a package + <code class="filename">Makefile</code>.</p></dd> </dl></div> </div> <div class="sect1" lang="en"> <div class="titlepage"><div><div><h2 class="title" style="clear: both"> <a name="build.running"></a>15.4. Running a phase</h2></div></div></div> <p>You can run a particular phase by typing <span><strong class="command">make -phase</strong></span>, where <span class="emphasis"><em>phase</em></span> is the name of the -phase. This will automatically run all phases that are required for this -phase. The default phase is <code class="varname">build</code>, that is, when you -run <span><strong class="command">make</strong></span> without parameters in a package directory, -the package will be built, but not installed.</p> + phase</strong></span>, where <span class="emphasis"><em>phase</em></span> is the name of the + phase. This will automatically run all phases that are required for this + phase. The default phase is <code class="varname">build</code>, that is, when you + run <span><strong class="command">make</strong></span> without parameters in a package directory, + the package will be built, but not installed.</p> </div> <div class="sect1" lang="en"> <div class="titlepage"><div><div><h2 class="title" style="clear: both"> @@ -6262,7 +6257,7 @@ is executed.</p> .for d in ${BUILD_DIRS} cd ${WRKSRC} && cd ${d} && env ${MAKE_ENV} \ ${MAKE_PROGRAM} ${BUILD_MAKE_FLAGS} \ - -f ${MAKEFILE} ${BUILD_TARGET} + -f ${MAKE_FILE} ${BUILD_TARGET} .endfor </pre> <p><code class="varname">BUILD_DIRS</code> (default: “<span class="quote">.</span>”) is a @@ -6271,12 +6266,12 @@ these directories, <code class="varname">MAKE_PROGRAM</code> is run with the environment <code class="varname">MAKE_ENV</code> and arguments <code class="varname">BUILD_MAKE_FLAGS</code>. The variables <code class="varname">MAKE_ENV</code>, <code class="varname">BUILD_MAKE_FLAGS</code>, -<code class="varname">MAKEFILE</code> and <code class="varname">BUILD_TARGET</code> may all +<code class="varname">MAKE_FILE</code> and <code class="varname">BUILD_TARGET</code> may all be changed by the package.</p> <p>The default value of <code class="varname">MAKE_PROGRAM</code> is “<span class="quote">gmake</span>” if <code class="varname">USE_TOOLS</code> contains “<span class="quote">gmake</span>”, “<span class="quote">make</span>” otherwise. The default value -of <code class="varname">MAKEFILE</code> is “<span class="quote">Makefile</span>”, and +of <code class="varname">MAKE_FILE</code> is “<span class="quote">Makefile</span>”, and <code class="varname">BUILD_TARGET</code> defaults to “<span class="quote">all</span>”.</p> </div> <div class="sect1" lang="en"> @@ -6298,7 +6293,7 @@ of <code class="varname">MAKEFILE</code> is “<span class="quote">Makefile< .for d in ${INSTALL_DIRS} cd ${WRKSRC} && cd ${d} && env ${MAKE_ENV} \ ${MAKE_PROGRAM} ${INSTALL_MAKE_FLAGS} \ - -f ${MAKEFILE} ${BUILD_TARGET} + -f ${MAKE_FILE} ${BUILD_TARGET} .endfor </pre> <p>The variable's meanings are analogous to the ones in the @@ -6367,129 +6362,133 @@ of <code class="varname">MAKEFILE</code> is “<span class="quote">Makefile< <a name="build.helpful-targets"></a>15.16. Other helpful targets</h2></div></div></div> <div class="variablelist"><dl> <dt><span class="term">pre/post-*</span></dt> -<dd><p>For any of the main targets described in the previous section, two - auxiliary targets exist with “<span class="quote">pre-</span>” and - “<span class="quote">post-</span>” used as a prefix - for the main target's name. These targets are invoked before and - after the main target is called, allowing extra configuration or - installation steps be performed from a package's Makefile, for - example, which a program's configure script - or install target omitted.</p></dd> +<dd><p>For any of the main targets described in the previous + section, two auxiliary targets exist with + “<span class="quote">pre-</span>” and “<span class="quote">post-</span>” used as a + prefix for the main target's name. These targets are + invoked before and after the main target is called, allowing + extra configuration or installation steps be performed from + a package's Makefile, for example, which a program's + configure script or install target omitted.</p></dd> <dt><span class="term">do-*</span></dt> -<dd><p>Should one of the main targets do the wrong thing, and should there - be no variable to fix this, you can redefine it with the do-* - target. (Note that redefining the target itself instead of the - do-* target is a bad idea, as the pre-* and post-* targets won't be - called anymore, etc.) You will not usually need to do this.</p></dd> +<dd><p>Should one of the main targets do the wrong thing, and + should there be no variable to fix this, you can redefine it + with the do-* target. (Note that redefining the target + itself instead of the do-* target is a bad idea, as the + pre-* and post-* targets won't be called anymore, etc.) You + will not usually need to do this.</p></dd> <dt><span class="term">reinstall</span></dt> -<dd><p>If you did a <span><strong class="command">make install</strong></span> and you noticed some file - was not installed properly, you can repeat the installation with this - target, which will ignore the “<span class="quote">already installed</span>” flag.</p></dd> +<dd><p>If you did a <span><strong class="command">make install</strong></span> and you + noticed some file was not installed properly, you can repeat + the installation with this target, which will ignore the + “<span class="quote">already installed</span>” flag.</p></dd> <dt><span class="term">deinstall</span></dt> <dd> <p>This target does a <a href="http://netbsd.gw.com/cgi-bin/man-cgi?pkg_delete+1+NetBSD-current"><span class="citerefentry"><span class="refentrytitle">pkg_delete</span>(1)</span></a> in the current directory, - effectively de-installing the package. The following variables can - be used to tune the behaviour:</p> + effectively de-installing the package. The following variables can + be used to tune the behaviour:</p> <div class="variablelist"><dl> <dt><span class="term"><code class="varname">PKG_VERBOSE</code></span></dt> <dd><p>Add a "-v" to the <a href="http://netbsd.gw.com/cgi-bin/man-cgi?pkg_delete+1+NetBSD-current"><span class="citerefentry"><span class="refentrytitle">pkg_delete</span>(1)</span></a> command.</p></dd> <dt><span class="term"><code class="varname">DEINSTALLDEPENDS</code></span></dt> <dd><p>Remove all packages that require (depend on) the given package. - This can be used to remove any packages that may have been pulled in - by a given package, e.g. if <span><strong class="command">make deinstall - DEINSTALLDEPENDS=1</strong></span> is done in - <code class="filename">pkgsrc/x11/kde</code>, this is likely to remove whole - KDE. Works by adding “<span class="quote">-R</span>” to the <a href="http://netbsd.gw.com/cgi-bin/man-cgi?pkg_delete+1+NetBSD-current"><span class="citerefentry"><span class="refentrytitle">pkg_delete</span>(1)</span></a> command line.</p></dd> + This can be used to remove any packages that may have been pulled in + by a given package, e.g. if <span><strong class="command">make deinstall + DEINSTALLDEPENDS=1</strong></span> is done in + <code class="filename">pkgsrc/x11/kde</code>, this is likely to remove whole + KDE. Works by adding “<span class="quote">-R</span>” to the <a href="http://netbsd.gw.com/cgi-bin/man-cgi?pkg_delete+1+NetBSD-current"><span class="citerefentry"><span class="refentrytitle">pkg_delete</span>(1)</span></a> command line.</p></dd> </dl></div> </dd> <dt><span class="term">update</span></dt> <dd> <p>This target causes the current package to be updated to the latest - version. The package and all depending packages first get de-installed, - then current versions of the corresponding packages get compiled and - installed. This is similar to manually noting which packages are - currently installed, then performing a series of <span><strong class="command">make - deinstall</strong></span> and <span><strong class="command">make install</strong></span> (or whatever - <code class="varname">UPDATE_TARGET</code> is set to) for these packages.</p> + version. The package and all depending packages first get de-installed, + then current versions of the corresponding packages get compiled and + installed. This is similar to manually noting which packages are + currently installed, then performing a series of <span><strong class="command">make + deinstall</strong></span> and <span><strong class="command">make install</strong></span> (or whatever + <code class="varname">UPDATE_TARGET</code> is set to) for these packages.</p> <p>You can use the “<span class="quote">update</span>” target to resume package - updating in case a previous <span><strong class="command">make update</strong></span> was interrupted - for some reason. However, in this case, make sure you don't call - <span><strong class="command">make clean</strong></span> or otherwise remove the list of dependent - packages in <code class="varname">WRKDIR</code>. Otherwise, you lose the - ability to automatically update the current package along with the - dependent packages you have installed.</p> + updating in case a previous <span><strong class="command">make update</strong></span> was interrupted + for some reason. However, in this case, make sure you don't call + <span><strong class="command">make clean</strong></span> or otherwise remove the list of dependent + packages in <code class="varname">WRKDIR</code>. Otherwise, you lose the + ability to automatically update the current package along with the + dependent packages you have installed.</p> <p>Resuming an interrupted <span><strong class="command">make update</strong></span> will only work as - long as the package tree remains unchanged. If the source code for - one of the packages to be updated has been changed, resuming - <span><strong class="command">make update</strong></span> will most certainly fail!</p> + long as the package tree remains unchanged. If the source code for + one of the packages to be updated has been changed, resuming + <span><strong class="command">make update</strong></span> will most certainly fail!</p> <p>The following variables can be used either on the command line or in - <code class="filename">/etc/mk.conf</code> to alter the behaviour of - <span><strong class="command">make update</strong></span>:</p> + <code class="filename">/etc/mk.conf</code> to alter the behaviour of + <span><strong class="command">make update</strong></span>:</p> <div class="variablelist"><dl> <dt><span class="term"><code class="varname">UPDATE_TARGET</code></span></dt> <dd><p>Install target to recursively use for the updated package and the - dependent packages. Defaults to <code class="varname">DEPENDS_TARGET</code> if set, - “<span class="quote">install</span>” otherwise for <span><strong class="command">make update</strong></span>. - e.g. <span><strong class="command">make update UPDATE_TARGET=package</strong></span></p></dd> + dependent packages. Defaults to <code class="varname">DEPENDS_TARGET</code> if set, + “<span class="quote">install</span>” otherwise for <span><strong class="command">make update</strong></span>. + e.g. <span><strong class="command">make update UPDATE_TARGET=package</strong></span></p></dd> <dt><span class="term"><code class="varname">NOCLEAN</code></span></dt> <dd><p>Don't clean up after updating. Useful if you want to leave the - work sources of the updated packages around for inspection or - other purposes. Be sure you eventually clean up the source - tree (see the “<span class="quote">clean-update</span>” target below) or you may - run into troubles with old source code still lying around on your - next <span><strong class="command">make</strong></span> or <span><strong class="command">make update</strong></span>.</p></dd> + work sources of the updated packages around for inspection or + other purposes. Be sure you eventually clean up the source + tree (see the “<span class="quote">clean-update</span>” target below) or you may + run into troubles with old source code still lying around on your + next <span><strong class="command">make</strong></span> or <span><strong class="command">make update</strong></span>.</p></dd> <dt><span class="term"><code class="varname">REINSTALL</code></span></dt> <dd><p>Deinstall each package before installing (making - <code class="varname">DEPENDS_TARGET</code>). This may be necessary if the - “<span class="quote">clean-update</span>” target (see below) was called after - interrupting a running <span><strong class="command">make update</strong></span>.</p></dd> + <code class="varname">DEPENDS_TARGET</code>). This may be necessary if the + “<span class="quote">clean-update</span>” target (see below) was called after + interrupting a running <span><strong class="command">make update</strong></span>.</p></dd> <dt><span class="term"><code class="varname">DEPENDS_TARGET</code></span></dt> <dd><p>Allows you to disable recursion and hardcode the target for - packages. The default is “<span class="quote">update</span>” for the update target, - facilitating a recursive update of prerequisite packages. - Only set <code class="varname">DEPENDS_TARGET</code> if you want to disable - recursive updates. Use <code class="varname">UPDATE_TARGET</code> instead to just - set a specific target for each package to be installed during - <span><strong class="command">make update</strong></span> (see above).</p></dd> + packages. The default is “<span class="quote">update</span>” for the update target, + facilitating a recursive update of prerequisite packages. + Only set <code class="varname">DEPENDS_TARGET</code> if you want to disable + recursive updates. Use <code class="varname">UPDATE_TARGET</code> instead to just + set a specific target for each package to be installed during + <span><strong class="command">make update</strong></span> (see above).</p></dd> </dl></div> </dd> <dt><span class="term">clean-update</span></dt> <dd> <p>Clean the source tree for all packages that would get updated if - <span><strong class="command">make update</strong></span> was called from the current directory. - This target should not be used if the current package (or any of its - depending packages) have already been de-installed (e.g., after calling - <span><strong class="command">make update</strong></span>) or you may lose some packages you intended - to update. As a rule of thumb: only use this target - <span class="emphasis"><em>before</em></span> the first time you run - <span><strong class="command">make update</strong></span> and only if you have a dirty package tree - (e.g., if you used <code class="varname">NOCLEAN</code>).</p> + <span><strong class="command">make update</strong></span> was called from the current directory. + This target should not be used if the current package (or any of its + depending packages) have already been de-installed (e.g., after calling + <span><strong class="command">make update</strong></span>) or you may lose some packages you intended + to update. As a rule of thumb: only use this target + <span class="emphasis"><em>before</em></span> the first time you run + <span><strong class="command">make update</strong></span> and only if you have a dirty package tree + (e.g., if you used <code class="varname">NOCLEAN</code>).</p> <p>If you are unsure about whether your tree is clean, you can either - perform a <span><strong class="command">make clean</strong></span> at the top of the tree, or use - the following sequence of commands from the directory of the package - you want to update (<span class="emphasis"><em>before</em></span> running - <span><strong class="command">make update</strong></span> for the first time, otherwise you lose - all the packages you wanted to update!):</p> -<pre class="screen"><code class="prompt">#</code> <strong class="userinput"><code>make clean-update</code></strong> + perform a <span><strong class="command">make clean</strong></span> at the top of the tree, or use + the following sequence of commands from the directory of the package + you want to update (<span class="emphasis"><em>before</em></span> running + <span><strong class="command">make update</strong></span> for the first time, otherwise you lose + all the packages you wanted to update!):</p> +<pre class="screen"> +<code class="prompt">#</code> <strong class="userinput"><code>make clean-update</code></strong> <code class="prompt">#</code> <strong class="userinput"><code>make clean CLEANDEPENDS=YES</code></strong> -<code class="prompt">#</code> <strong class="userinput"><code>make update</code></strong></pre> +<code class="prompt">#</code> <strong class="userinput"><code>make update</code></strong> + </pre> <p>The following variables can be used either on the command line or in - <code class="filename">/etc/mk.conf</code> to alter the behaviour of - <span><strong class="command">make clean-update</strong></span>:</p> + <code class="filename">/etc/mk.conf</code> to alter the behaviour of + <span><strong class="command">make clean-update</strong></span>:</p> <div class="variablelist"><dl> <dt><span class="term"><code class="varname">CLEAR_DIRLIST</code></span></dt> <dd><p>After <span><strong class="command">make clean</strong></span>, do not reconstruct the list of - directories to update for this package. Only use this if <span><strong class="command">make - update</strong></span> successfully installed all packages you wanted to - update. Normally, this is done automatically on <span><strong class="command">make - update</strong></span>, but may have been suppressed by the - <code class="varname">NOCLEAN</code> variable (see above).</p></dd> + directories to update for this package. Only use this if <span><strong class="command">make + update</strong></span> successfully installed all packages you wanted to + update. Normally, this is done automatically on <span><strong class="command">make + update</strong></span>, but may have been suppressed by the + <code class="varname">NOCLEAN</code> variable (see above).</p></dd> </dl></div> </dd> <dt><span class="term">info</span></dt> <dd><p>This target invokes <a href="http://netbsd.gw.com/cgi-bin/man-cgi?pkg_info+1+NetBSD-current"><span class="citerefentry"><span class="refentrytitle">pkg_info</span>(1)</span></a> for the current - package. You can use this to check which version of a package is - installed.</p></dd> + package. You can use this to check which version of a package is + installed.</p></dd> <dt><span class="term">readme</span></dt> <dd><p>This target generates a <code class="filename">README.html</code> file, which can be viewed using a browser such as @@ -6509,93 +6508,95 @@ of <code class="varname">MAKEFILE</code> is “<span class="quote">Makefile< searched for all the binary packages.</p></dd> <dt><span class="term">readme-all</span></dt> <dd><p>Use this target to create a file <code class="filename">README-all.html</code> - which contains a list of all packages currently available in the NetBSD - Packages Collection, together with the category they belong to and a - short description. This file is compiled from the - <code class="filename">pkgsrc/*/README.html</code> files, so be sure to run - this <span class="emphasis"><em>after</em></span> a <span><strong class="command">make readme</strong></span>.</p></dd> + which contains a list of all packages currently available in the NetBSD + Packages Collection, together with the category they belong to and a + short description. This file is compiled from the + <code class="filename">pkgsrc/*/README.html</code> files, so be sure to run + this <span class="emphasis"><em>after</em></span> a <span><strong class="command">make readme</strong></span>.</p></dd> <dt><span class="term">cdrom-readme</span></dt> <dd><p>This is very much the same as the “<span class="quote">readme</span>” target (see - above), but is to be used when generating a pkgsrc tree to be written - to a CD-ROM. This target also produces - <code class="filename">README.html</code> files, and can be made to refer - to URLs based on <code class="varname">CDROM_PKG_URL_HOST</code> and - <code class="varname">CDROM_PKG_URL_DIR</code>.</p></dd> + above), but is to be used when generating a pkgsrc tree to be written + to a CD-ROM. This target also produces + <code class="filename">README.html</code> files, and can be made to refer + to URLs based on <code class="varname">CDROM_PKG_URL_HOST</code> and + <code class="varname">CDROM_PKG_URL_DIR</code>.</p></dd> <dt><span class="term">show-distfiles</span></dt> -<dd><p>This target shows which distfiles and patchfiles are needed to build - the package. (<code class="varname">DISTFILES</code> and - <code class="varname">PATCHFILES</code>, but not <code class="filename">patches/*</code>)</p></dd> +<dd><p>This target shows which distfiles and patchfiles are + needed to build the package (<code class="varname">ALLFILES</code>, + which contains all <code class="varname">DISTFILES</code> and + <code class="varname">PATCHFILES</code>, but not + <code class="filename">patches/*</code>).</p></dd> <dt><span class="term">show-downlevel</span></dt> <dd><p>This target shows nothing if the package is not installed. If a version - of this package is installed, but is not the version provided in this - version of pkgsrc, then a warning message is displayed. This target can - be used to show which of your installed packages are downlevel, and so - the old versions can be deleted, and the current ones added.</p></dd> + of this package is installed, but is not the version provided in this + version of pkgsrc, then a warning message is displayed. This target can + be used to show which of your installed packages are downlevel, and so + the old versions can be deleted, and the current ones added.</p></dd> <dt><span class="term">show-pkgsrc-dir</span></dt> <dd><p>This target shows the directory in the pkgsrc hierarchy from which the - package can be built and installed. This may not be the same directory - as the one from which the package was installed. This target is intended - to be used by people who may wish to upgrade many packages on a single - host, and can be invoked from the top-level pkgsrc Makefile by using the - “<span class="quote">show-host-specific-pkgs</span>” target.</p></dd> + 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 + “<span class="quote">show-host-specific-pkgs</span>” target.</p></dd> <dt><span class="term">show-installed-depends</span></dt> <dd><p>This target shows which installed packages match the current package's - <code class="varname">DEPENDS</code>. Useful if out of date dependencies are - causing build problems.</p></dd> + <code class="varname">DEPENDS</code>. Useful if out of date dependencies are + causing build problems.</p></dd> <dt><span class="term">check-shlibs</span></dt> <dd><p>After a package is installed, check all its binaries and (on ELF - platforms) shared libraries to see if they find the shared libs they need. - Run by default if <code class="varname">PKG_DEVELOPER</code> is set in - <code class="filename">/etc/mk.conf</code>.</p></dd> + platforms) shared libraries to see if they find the shared libs they need. + Run by default if <code class="varname">PKG_DEVELOPER</code> is set in + <code class="filename">/etc/mk.conf</code>.</p></dd> <dt><span class="term">print-PLIST</span></dt> <dd> <p>After a “<span class="quote">make install</span>” from a new or - upgraded pkg, this prints out an attempt to generate a new - <code class="filename">PLIST</code> from a <span><strong class="command">find -newer - work/.extract_done</strong></span>. An attempt is made to care - for shared libs etc., but it is - <span class="emphasis"><em>strongly</em></span> recommended to review the - result before putting it into - <code class="filename">PLIST</code>. On upgrades, it's useful to - diff the output of this command against an already - existing <code class="filename">PLIST</code> file.</p> + upgraded pkg, this prints out an attempt to generate a new + <code class="filename">PLIST</code> from a <span><strong class="command">find -newer + work/.extract_done</strong></span>. An attempt is made to care + for shared libs etc., but it is + <span class="emphasis"><em>strongly</em></span> recommended to review the + result before putting it into + <code class="filename">PLIST</code>. On upgrades, it's useful to + diff the output of this command against an already + existing <code class="filename">PLIST</code> file.</p> <p>If the package installs files via <a href="http://netbsd.gw.com/cgi-bin/man-cgi?tar+1+NetBSD-current"><span class="citerefentry"><span class="refentrytitle">tar</span>(1)</span></a> or other - methods that don't update file access times, be sure to - add these files manually to your - <code class="filename">PLIST</code>, as the “<span class="quote">find - -newer</span>” command used by this target won't catch - them!</p> -<p> See <a href="#print-PLIST" title="11.3. Tweaking output of make print-PLIST">Section 11.3, “Tweaking output of <span><strong class="command">make print-PLIST</strong></span>”</a> for more - information on this target.</p> + methods that don't update file access times, be sure to + add these files manually to your + <code class="filename">PLIST</code>, as the “<span class="quote">find + -newer</span>” command used by this target won't catch + them!</p> +<p>See <a href="#print-PLIST" title="11.3. Tweaking output of make print-PLIST">Section 11.3, “Tweaking output of <span><strong class="command">make print-PLIST</strong></span>”</a> for more + information on this target.</p> </dd> <dt><span class="term">bulk-package</span></dt> <dd> <p>Used to do bulk builds. If an appropriate binary package already exists, - no action is taken. If not, this target will compile, install and - package it (and its depends, if <code class="varname">PKG_DEPENDS</code> is - set properly. See <a href="#binary.configuration" title="6.3.1. Configuration">Section 6.3.1, “Configuration”</a>). - After creating the binary - package, the sources, the just-installed package and its required - packages are removed, preserving free disk space.</p> + no action is taken. If not, this target will compile, install and + package it (and its depends, if <code class="varname">PKG_DEPENDS</code> is + set properly. See <a href="#binary.configuration" title="6.3.1. Configuration">Section 6.3.1, “Configuration”</a>). + After creating the binary + package, the sources, the just-installed package and its required + packages are removed, preserving free disk space.</p> <p><span class="emphasis"><em>Beware that this target may deinstall all - packages installed on a system!</em></span></p> + packages installed on a system!</em></span></p> </dd> <dt><span class="term">bulk-install</span></dt> <dd> <p>Used during bulk-installs to install required packages. If an - up-to-date binary package is available, it will be installed via - <a href="http://netbsd.gw.com/cgi-bin/man-cgi?pkg_add+1+NetBSD-current"><span class="citerefentry"><span class="refentrytitle">pkg_add</span>(1)</span></a>. If not, <span><strong class="command">make bulk-package</strong></span> will be executed, - but the installed binary won't be removed. </p> -<p> A binary package is considered “<span class="quote">up-to-date</span>” to be - installed via <a href="http://netbsd.gw.com/cgi-bin/man-cgi?pkg_add+1+NetBSD-current"><span class="citerefentry"><span class="refentrytitle">pkg_add</span>(1)</span></a> if:</p> + up-to-date binary package is available, it will be installed via + <a href="http://netbsd.gw.com/cgi-bin/man-cgi?pkg_add+1+NetBSD-current"><span class="citerefentry"><span class="refentrytitle">pkg_add</span>(1)</span></a>. If not, <span><strong class="command">make bulk-package</strong></span> will be executed, + but the installed binary won't be removed.</p> +<p>A binary package is considered “<span class="quote">up-to-date</span>” to be + installed via <a href="http://netbsd.gw.com/cgi-bin/man-cgi?pkg_add+1+NetBSD-current"><span class="citerefentry"><span class="refentrytitle">pkg_add</span>(1)</span></a> if:</p> <div class="itemizedlist"><ul type="disc"> <li><p>None of the package's files (<code class="filename">Makefile</code>, - ...) were modified since it was built.</p></li> + ...) were modified since it was built.</p></li> <li><p>None of the package's required (binary) packages were - modified since it was built.</p></li> + modified since it was built.</p></li> </ul></div> <p><span class="emphasis"><em>Beware that this target may deinstall all - packages installed on a system!</em></span></p> + packages installed on a system!</em></span></p> </dd> </dl></div> </div> @@ -6611,86 +6612,65 @@ of <code class="varname">MAKEFILE</code> is “<span class="quote">Makefile< <dt><span class="sect1"><a href="#platform-tools">16.3. Tools provided by platforms</a></span></dt> </dl> </div> -<p> -The <code class="varname">USE_TOOLS</code> definition is used both internally +<p>The <code class="varname">USE_TOOLS</code> definition is used both internally by pkgsrc and also for individual packages to define what commands are needed for building a package (like <code class="varname">BUILD_DEPENDS</code>) or for later run-time of an installed packaged (such as <code class="varname">DEPENDS</code>). If the native system provides an adequate tool, then in many cases, a pkgsrc -package will not be used. -</p> -<p> -When building a package, the replacement tools are +package will not be used.</p> +<p>When building a package, the replacement tools are made available in a directory (as symlinks or wrapper scripts) that is early in the executable search path. Just like the buildlink -system, this helps with consistent builds. -</p> -<p> -A tool may be needed to help build a specific package. For example, -perl, GNU make (gmake) or yacc may be needed. -</p> -<p> -Also a tool may be needed, for example, because the native system's supplied +system, this helps with consistent builds.</p> +<p>A tool may be needed to help build a specific package. For example, +perl, GNU make (gmake) or yacc may be needed.</p> +<p>Also a tool may be needed, for example, because the native system's supplied tool may be inefficient for building a package with pkgsrc. For example, a package may need GNU awk, bison (instead of -yacc) or a better sed. -</p> -<p> -The tools used by a package can be listed by running -<span><strong class="command">make show-tools</strong></span>. -</p> +yacc) or a better sed.</p> +<p>The tools used by a package can be listed by running +<span><strong class="command">make show-tools</strong></span>.</p> <div class="sect1" lang="en"> <div class="titlepage"><div><div><h2 class="title" style="clear: both"> <a name="pkgsrc-tools"></a>16.1. Tools for pkgsrc builds</h2></div></div></div> -<p> -The default set of tools used by pkgsrc is defined in +<p>The default set of tools used by pkgsrc is defined in <code class="filename">bsd.pkg.mk</code>. This includes standard Unix tools, such as: <span><strong class="command">cat</strong></span>, <span><strong class="command">awk</strong></span>, <span><strong class="command">chmod</strong></span>, <span><strong class="command">test</strong></span>, and so on. These can be seen by running: -<span><strong class="command">make show-var VARNAME=USE_TOOLS</strong></span>. -</p> -<p> -If a package needs a specific program to build +<span><strong class="command">make show-var VARNAME=USE_TOOLS</strong></span>.</p> +<p>If a package needs a specific program to build then the <code class="varname">USE_TOOLS</code> variable can be used -to define the tools needed. -</p> +to define the tools needed.</p> </div> <div class="sect1" lang="en"> <div class="titlepage"><div><div><h2 class="title" style="clear: both"> <a name="package-tools"></a>16.2. Tools needed by packages</h2></div></div></div> -<p> -In the following examples, the :pkgsrc means to use the pkgsrc version +<p>In the following examples, the :pkgsrc means to use the pkgsrc version and not the native version for a build dependency. And the :run means that it is used for a run-time dependencies also (and becomes a DEPENDS). The default is a build dependency which can be set with :build. (So in this example, it is the same as gmake:build -and pkg-config:build.) -</p> +and pkg-config:build.)</p> <pre class="programlisting"> USE_TOOLS+= mktemp:pkgsrc USE_TOOLS+= gmake perl:run pkg-config </pre> -<p> -When using the tools framework, a +<p>When using the tools framework, a <code class="varname">TOOLS_PATH.foo</code> variable is defined which contains the full path to the appropriate tool. For example, <code class="varname">TOOLS_PATH.bash</code> could be “<span class="quote">/bin/bash</span>” -on Linux systems. -</p> -<p> -If you always need a pkgsrc version of the +on Linux systems.</p> +<p>If you always need a pkgsrc version of the tool at run-time, then just use <code class="varname">DEPENDS</code> instead. - </p> </div> <div class="sect1" lang="en"> <div class="titlepage"><div><div><h2 class="title" style="clear: both"> <a name="platform-tools"></a>16.3. Tools provided by platforms</h2></div></div></div> -<p> -When improving or porting pkgsrc to a new platform, have a look +<p>When improving or porting pkgsrc to a new platform, have a look at (or create) the corresponding platform specific make file fragment under <code class="filename">pkgsrc/mk/tools/tools.${OPSYS}.mk</code> which defines the name of the common tools. For example:</p> @@ -6737,34 +6717,44 @@ TOOLS_PLATFORM.true?= true # shell builtin <dt><span class="sect2"><a href="#using-libtool">17.3.2. Using libtool on GNU packages that already support libtool</a></span></dt> <dt><span class="sect2"><a href="#autoconf-automake">17.3.3. GNU Autoconf/Automake</a></span></dt> </dl></dd> -<dt><span class="sect1"><a href="#fixes.build">17.4. Fixing problems in the <span class="emphasis"><em>build</em></span> phase</a></span></dt> +<dt><span class="sect1"><a href="#programming-languages">17.4. Programming languages</a></span></dt> +<dd><dl> +<dt><span class="sect2"><a href="#basic-programming-languages">17.4.1. C, C++, and Fortran</a></span></dt> +<dt><span class="sect2"><a href="#java-programming-language">17.4.2. Java</a></span></dt> +<dt><span class="sect2"><a href="#perl-scripts">17.4.3. Packages containing perl scripts</a></span></dt> +<dt><span class="sect2"><a href="#other-programming-languages">17.4.4. Other programming languages</a></span></dt> +</dl></dd> +<dt><span class="sect1"><a href="#fixes.build">17.5. Fixing problems in the <span class="emphasis"><em>build</em></span> phase</a></span></dt> <dd><dl> -<dt><span class="sect2"><a href="#fixes.build.cpp">17.4.1. Compiling C and C++ code conditionally</a></span></dt> -<dt><span class="sect2"><a href="#compiler-bugs">17.4.2. How to handle compiler bugs</a></span></dt> -<dt><span class="sect2"><a href="#undefined-reference">17.4.3. Undefined reference to “<span class="quote">...</span>”</a></span></dt> +<dt><span class="sect2"><a href="#fixes.build.cpp">17.5.1. Compiling C and C++ code conditionally</a></span></dt> +<dt><span class="sect2"><a href="#compiler-bugs">17.5.2. How to handle compiler bugs</a></span></dt> +<dt><span class="sect2"><a href="#undefined-reference">17.5.3. Undefined reference to “<span class="quote">...</span>”</a></span></dt> +<dt><span class="sect2"><a href="#out-of-memory">17.5.4. Running out of memory</a></span></dt> </dl></dd> -<dt><span class="sect1"><a href="#fixes.install">17.5. Fixing problems in the <span class="emphasis"><em>install</em></span> phase</a></span></dt> +<dt><span class="sect1"><a href="#fixes.install">17.6. Fixing problems in the <span class="emphasis"><em>install</em></span> phase</a></span></dt> <dd><dl> -<dt><span class="sect2"><a href="#install-scripts">17.5.1. Creating needed directories</a></span></dt> -<dt><span class="sect2"><a href="#where-to-install-documentation">17.5.2. Where to install documentation</a></span></dt> -<dt><span class="sect2"><a href="#installing-score-files">17.5.3. Installing score files</a></span></dt> -<dt><span class="sect2"><a href="#perl-scripts">17.5.4. Packages containing perl scripts</a></span></dt> -<dt><span class="sect2"><a href="#hardcoded-paths">17.5.5. Packages with hardcoded paths to other interpreters</a></span></dt> -<dt><span class="sect2"><a href="#perl-modules">17.5.6. Packages installing perl modules</a></span></dt> -<dt><span class="sect2"><a href="#faq.info-files">17.5.7. Packages installing info files</a></span></dt> -<dt><span class="sect2"><a href="#manpages">17.5.8. Packages installing man pages</a></span></dt> -<dt><span class="sect2"><a href="#gconf2-data-files">17.5.9. Packages installing GConf2 data files</a></span></dt> -<dt><span class="sect2"><a href="#scrollkeeper-data-files">17.5.10. Packages installing scrollkeeper data files</a></span></dt> -<dt><span class="sect2"><a href="#x11-fonts">17.5.11. Packages installing X11 fonts</a></span></dt> -<dt><span class="sect2"><a href="#gtk2-modules">17.5.12. Packages installing GTK2 modules</a></span></dt> -<dt><span class="sect2"><a href="#sgml-xml-data">17.5.13. Packages installing SGML or XML data</a></span></dt> -<dt><span class="sect2"><a href="#mime-database">17.5.14. Packages installing extensions to the MIME database</a></span></dt> -<dt><span class="sect2"><a href="#intltool">17.5.15. Packages using intltool</a></span></dt> -<dt><span class="sect2"><a href="#startup-scripts">17.5.16. Packages installing startup scripts</a></span></dt> -<dt><span class="sect2"><a href="#tex-packages">17.5.17. Packages installing TeX modules</a></span></dt> -<dt><span class="sect2"><a href="#hicolor-theme">17.5.18. Packages installing hicolor theme icons</a></span></dt> -<dt><span class="sect2"><a href="#desktop-files">17.5.19. Packages installing desktop files</a></span></dt> +<dt><span class="sect2"><a href="#install-scripts">17.6.1. Creating needed directories</a></span></dt> +<dt><span class="sect2"><a href="#where-to-install-documentation">17.6.2. Where to install documentation</a></span></dt> +<dt><span class="sect2"><a href="#installing-score-files">17.6.3. Installing score files</a></span></dt> +<dt><span class="sect2"><a href="#hardcoded-paths">17.6.4. Packages with hardcoded paths to other interpreters</a></span></dt> +<dt><span class="sect2"><a href="#perl-modules">17.6.5. Packages installing perl modules</a></span></dt> +<dt><span class="sect2"><a href="#faq.info-files">17.6.6. Packages installing info files</a></span></dt> +<dt><span class="sect2"><a href="#manpages">17.6.7. Packages installing man pages</a></span></dt> +<dt><span class="sect2"><a href="#gconf2-data-files">17.6.8. Packages installing GConf2 data files</a></span></dt> +<dt><span class="sect2"><a href="#scrollkeeper-data-files">17.6.9. Packages installing scrollkeeper data files</a></span></dt> +<dt><span class="sect2"><a href="#x11-fonts">17.6.10. Packages installing X11 fonts</a></span></dt> +<dt><span class="sect2"><a href="#gtk2-modules">17.6.11. Packages installing GTK2 modules</a></span></dt> +<dt><span class="sect2"><a href="#sgml-xml-data">17.6.12. Packages installing SGML or XML data</a></span></dt> +<dt><span class="sect2"><a href="#mime-database">17.6.13. Packages installing extensions to the MIME database</a></span></dt> +<dt><span class="sect2"><a href="#intltool">17.6.14. Packages using intltool</a></span></dt> +<dt><span class="sect2"><a href="#startup-scripts">17.6.15. Packages installing startup scripts</a></span></dt> +<dt><span class="sect2"><a href="#tex-packages">17.6.16. Packages installing TeX modules</a></span></dt> +<dt><span class="sect2"><a href="#emulation-packages">17.6.17. Packages supporting running binaries in + emulation</a></span></dt> +<dt><span class="sect2"><a href="#hicolor-theme">17.6.18. Packages installing hicolor theme icons</a></span></dt> +<dt><span class="sect2"><a href="#desktop-files">17.6.19. Packages installing desktop files</a></span></dt> </dl></dd> +<dt><span class="sect1"><a href="#punting">17.7. Marking packages as having problems</a></span></dt> </dl> </div> <div class="sect1" lang="en"> @@ -6774,445 +6764,445 @@ TOOLS_PLATFORM.true?= true # shell builtin <div class="titlepage"><div><div><h3 class="title"> <a name="portability-of-packages"></a>17.1.1. Portability of packages</h3></div></div></div> <p>One appealing feature of pkgsrc is that it runs on many - different platforms. As a result, it is important to ensure, - where possible, that packages in pkgsrc are portable. This - chapter mentions some particular details you should pay - attention to while working on pkgsrc.</p> + different platforms. As a result, it is important to ensure, + where possible, that packages in pkgsrc are portable. This + chapter mentions some particular details you should pay + attention to while working on pkgsrc.</p> </div> <div class="sect2" lang="en"> <div class="titlepage"><div><div><h3 class="title"> <a name="pulling-vars-from-etc-mk.conf"></a>17.1.2. How to pull in user-settable variables from <code class="filename">mk.conf</code></h3></div></div></div> <p>The pkgsrc user can configure pkgsrc by overriding several - variables in the file pointed to by <code class="varname">MAKECONF</code>, - which is <code class="filename">/etc/mk.conf</code> by default. When you - want to use those variables in the preprocessor directives of - <a href="http://netbsd.gw.com/cgi-bin/man-cgi?make+1+NetBSD-current"><span class="citerefentry"><span class="refentrytitle">make</span>(1)</span></a> (for example <code class="literal">.if</code> or - <code class="literal">.for</code>), you need to include the file - <code class="filename">../../mk/bsd.prefs.mk</code> before, which in turn - loads the user preferences.</p> + variables in the file pointed to by <code class="varname">MAKECONF</code>, + which is <code class="filename">/etc/mk.conf</code> by default. When you + want to use those variables in the preprocessor directives of + <a href="http://netbsd.gw.com/cgi-bin/man-cgi?make+1+NetBSD-current"><span class="citerefentry"><span class="refentrytitle">make</span>(1)</span></a> (for example <code class="literal">.if</code> or + <code class="literal">.for</code>), you need to include the file + <code class="filename">../../mk/bsd.prefs.mk</code> before, which in turn + loads the user preferences.</p> <p>But note that some variables may not be completely defined - after <code class="filename">../../mk/bsd.prefs.mk</code> has been - included, as they may contain references to variables that are - not yet defined. In shell commands this is no problem, since - variables are actually macros, which are only expanded when they - are used. But in the preprocessor directives mentioned above and - in dependency lines (of the form <code class="literal">target: - dependencies</code>) the variables are expanded at load - time.</p> + after <code class="filename">../../mk/bsd.prefs.mk</code> has been + included, as they may contain references to variables that are + not yet defined. In shell commands this is no problem, since + variables are actually macros, which are only expanded when they + are used. But in the preprocessor directives mentioned above and + in dependency lines (of the form <code class="literal">target: + dependencies</code>) the variables are expanded at load + time.</p> <div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"> <h3 class="title">Note</h3> <p>Currently there is no exhaustive list of all - variables that tells you whether they can be used at load time - or only at run time, but it is in preparation.</p> + variables that tells you whether they can be used at load time + or only at run time, but it is in preparation.</p> </div> </div> <div class="sect2" lang="en"> <div class="titlepage"><div><div><h3 class="title"> <a name="user-interaction"></a>17.1.3. User interaction</h3></div></div></div> <p>Occasionally, packages require interaction from the user, and this can be - in a number of ways:</p> + in a number of ways:</p> <div class="itemizedlist"><ul type="disc"> <li><p>When fetching the distfiles, some packages require user - interaction such as entering username/password or accepting a - license on a web page.</p></li> + interaction such as entering username/password or accepting a + license on a web page.</p></li> <li><p>When extracting the distfiles, some packages may ask for passwords.</p></li> <li><p>help to configure the package before it is built</p></li> <li><p>help during the build process</p></li> <li><p>help during the installation of a package</p></li> </ul></div> <p>The <code class="varname">INTERACTIVE_STAGE</code> definition is provided to notify - the pkgsrc mechanism of an interactive stage which will be needed, and - this should be set in the package's <code class="filename">Makefile</code>, e.g.:</p> + the pkgsrc mechanism of an interactive stage which will be needed, and + this should be set in the package's <code class="filename">Makefile</code>, e.g.:</p> <pre class="programlisting"> - INTERACTIVE_STAGE= build -</pre> + INTERACTIVE_STAGE= build + </pre> <p>Multiple interactive stages can be specified:</p> <pre class="programlisting"> - INTERACTIVE_STAGE= configure install -</pre> + INTERACTIVE_STAGE= configure install + </pre> </div> <div class="sect2" lang="en"> <div class="titlepage"><div><div><h3 class="title"> <a name="handling-licenses"></a>17.1.4. Handling licenses</h3></div></div></div> <p>A package may be covered by a license which the user has - or has not agreed to accept. For these cases, pkgsrc contains - a mechanism to note that a package is covered by a particular - license, and the package cannot be built unless the user has - accepted the license. (Installation of binary packages are - not currently subject to this mechanism.) Packages with - licenses that are either Open Source according to the Open - Source Initiative or Free according to the Free Software - Foundation will not be marked with a license tag. Packages - with licenses that have not been determined to meet either - definition will be marked with a license tag referring to the - license. This will prevent building unless pkgsrc is informed - that the license is acceptable, and enables displaying the - license.</p> + or has not agreed to accept. For these cases, pkgsrc contains + a mechanism to note that a package is covered by a particular + license, and the package cannot be built unless the user has + accepted the license. (Installation of binary packages are + not currently subject to this mechanism.) Packages with + licenses that are either Open Source according to the Open + Source Initiative or Free according to the Free Software + Foundation will not be marked with a license tag. Packages + with licenses that have not been determined to meet either + definition will be marked with a license tag referring to the + license. This will prevent building unless pkgsrc is informed + that the license is acceptable, and enables displaying the + license.</p> <p>The license tag mechanism is intended to address - copyright-related issues surrounding building, installing and - using a package, and not to address redistribution issues (see - <code class="varname">RESTRICTED</code> and - <code class="varname">NO_SRC_ON_FTP</code>, etc.). However, the above - definition of licenses for which tags are not needed implies - that packages with redistribution restrictions should have - tags.</p> -<p> - Denoting that a package is covered by a particular license is - done by placing the license in - <code class="filename">pkgsrc/licenses</code> and setting the - <code class="varname">LICENSE</code> variable to a string identifying - the license, e.g. in - <a href="ftp://ftp.NetBSD.org/pub/NetBSD/packages/pkgsrc/graphics/xv/README.html" target="_top"><code class="filename">graphics/xv</code></a>: </p> + copyright-related issues surrounding building, installing and + using a package, and not to address redistribution issues (see + <code class="varname">RESTRICTED</code> and + <code class="varname">NO_SRC_ON_FTP</code>, etc.). However, the above + definition of licenses for which tags are not needed implies + that packages with redistribution restrictions should have + tags.</p> +<p>Denoting that a package is covered by a particular license + is done by placing the license in + <code class="filename">pkgsrc/licenses</code> and setting the + <code class="varname">LICENSE</code> variable to a string identifying the + license, e.g. in <a href="ftp://ftp.NetBSD.org/pub/NetBSD/packages/pkgsrc/graphics/xv/README.html" target="_top"><code class="filename">graphics/xv</code></a>:</p> <pre class="programlisting"> - LICENSE= xv-license -</pre> -<p> - When trying to build, the user will get a notice that the - package is covered by a license which has not been - accepted:</p> + LICENSE= xv-license + </pre> +<p>When trying to build, the user will get a notice that the + package is covered by a license which has not been + accepted:</p> <pre class="programlisting"> - <code class="prompt">%</code> <strong class="userinput"><code>make</code></strong> - ===> xv-3.10anb9 has an unacceptable license: xv-license. - ===> To view the license, enter "/usr/bin/make show-license". - ===> To indicate acceptance, add this line to your /etc/mk.conf: - ===> ACCEPTABLE_LICENSES+=xv-license - *** Error code 1 -</pre> + <code class="prompt">%</code> <strong class="userinput"><code>make</code></strong> + ===> xv-3.10anb9 has an unacceptable license: xv-license. + ===> To view the license, enter "/usr/bin/make show-license". + ===> To indicate acceptance, add this line to your /etc/mk.conf: + ===> ACCEPTABLE_LICENSES+=xv-license + *** Error code 1 + </pre> <p>The license can be viewed with <span><strong class="command">make - show-license</strong></span>, and if it is considered appropriate, - the line printed above can be added to - <code class="filename">/etc/mk.conf</code> to indicate acceptance of - the particular license:</p> + show-license</strong></span>, and if it is considered appropriate, + the line printed above can be added to + <code class="filename">/etc/mk.conf</code> to indicate acceptance of + the particular license:</p> <pre class="programlisting"> - ACCEPTABLE_LICENSES+=xv-license -</pre> + ACCEPTABLE_LICENSES+=xv-license + </pre> <p>When adding a package with a new license, the license - text should be added to <code class="filename">pkgsrc/licenses</code> - for displaying. A list of known licenses can be seen in this - directory as well as by looking at the list of (commented - out) <code class="varname">ACCEPTABLE_LICENSES</code> variable - settings in - <code class="filename">pkgsrc/mk/defaults/mk.conf</code>.</p> + text should be added to <code class="filename">pkgsrc/licenses</code> + for displaying. A list of known licenses can be seen in this + directory as well as by looking at the list of (commented + out) <code class="varname">ACCEPTABLE_LICENSES</code> variable + settings in + <code class="filename">pkgsrc/mk/defaults/mk.conf</code>.</p> <p>The use of <code class="varname">LICENSE=shareware</code>, - <code class="varname">LICENSE=no-commercial-use</code>, and similar - language is deprecated because it does not crisply refer to - a particular license text. Another problem with such usage - is that it does not enable a user to denote acceptance of - the license for a single package without accepting the same - license text for another package. In particular, this can - be inappropriate when e.g. one accepts a particular license to - indicate to pkgsrc that a fee has been paid.</p> + <code class="varname">LICENSE=no-commercial-use</code>, and similar + language is deprecated because it does not crisply refer to + a particular license text. Another problem with such usage + is that it does not enable a user to denote acceptance of + the license for a single package without accepting the same + license text for another package. In particular, this can + be inappropriate when e.g. one accepts a particular license to + indicate to pkgsrc that a fee has been paid.</p> </div> <div class="sect2" lang="en"> <div class="titlepage"><div><div><h3 class="title"> <a name="restricted-packages"></a>17.1.5. Restricted packages</h3></div></div></div> <p>Some licenses restrict how software may be re-distributed. - In order to satisfy these restrictions, the package system - defines five make variables that can be set to note these - restrictions:</p> + In order to satisfy these restrictions, the package system + defines five make variables that can be set to note these + restrictions:</p> <div class="itemizedlist"><ul type="disc"> <li> <p><code class="varname">RESTRICTED</code></p> <p>This variable should be set whenever a restriction - exists (regardless of its kind). Set this variable to a - string containing the reason for the restriction.</p> + exists (regardless of its kind). Set this variable to a + string containing the reason for the restriction.</p> </li> <li> <p><code class="varname">NO_BIN_ON_CDROM</code></p> <p>Binaries may not be placed on CD-ROM. Set this - variable to <code class="varname">${RESTRICTED}</code> whenever a - binary package may not be included on a CD-ROM.</p> + variable to <code class="varname">${RESTRICTED}</code> whenever a + binary package may not be included on a CD-ROM.</p> </li> <li> <p><code class="varname">NO_BIN_ON_FTP</code></p> <p>Binaries may not be placed on an FTP server. Set - this variable to <code class="varname">${RESTRICTED}</code> - whenever a binary package may not not be made available - on the Internet.</p> + this variable to <code class="varname">${RESTRICTED}</code> + whenever a binary package may not not be made available + on the Internet.</p> </li> <li> <p><code class="varname">NO_SRC_ON_CDROM</code></p> <p>Distfiles may not be placed on CD-ROM. Set this - variable to <code class="varname">${RESTRICTED}</code> if - re-distribution of the source code or other distfile(s) is - not allowed on CD-ROMs.</p> + variable to <code class="varname">${RESTRICTED}</code> if + re-distribution of the source code or other distfile(s) is + not allowed on CD-ROMs.</p> </li> <li> <p><code class="varname">NO_SRC_ON_FTP</code></p> <p>Distfiles may not be placed on FTP. Set this variable - to <code class="varname">${RESTRICTED}</code> if re-distribution of - the source code or other distfile(s) via the Internet is not - allowed.</p> + to <code class="varname">${RESTRICTED}</code> if re-distribution of + the source code or other distfile(s) via the Internet is not + allowed. If this variable is not set, the distfile(s) will + be mirrored on ftp.NetBSD.org.</p> </li> </ul></div> <p>Please note that the use of <code class="varname">NO_PACKAGE</code>, - <code class="varname">IGNORE</code>, <code class="varname">NO_CDROM</code>, or other - generic make variables to denote restrictions is deprecated, - because they unconditionally prevent users from generating - binary packages!</p> + <code class="varname">IGNORE</code>, <code class="varname">NO_CDROM</code>, or other + generic make variables to denote restrictions is deprecated, + because they unconditionally prevent users from generating + binary packages!</p> </div> <div class="sect2" lang="en"> <div class="titlepage"><div><div><h3 class="title"> <a name="dependencies"></a>17.1.6. Handling dependencies</h3></div></div></div> <p>Your package may depend on some other package being present - - and there are various ways of expressing this - dependency. pkgsrc supports the <code class="varname">BUILD_DEPENDS</code> - and <code class="varname">DEPENDS</code> definitions, the - <code class="varname">USE_TOOLS</code> definition, as well as - dependencies via <code class="filename">buildlink3.mk</code>, which is - the preferred way to handle dependencies, and which uses the - variables named above. See <a href="#buildlink" title="Chapter 12. Buildlink methodology">Chapter 12, <i>Buildlink methodology</i></a> for more - information.</p> + - and there are various ways of expressing this + dependency. pkgsrc supports the <code class="varname">BUILD_DEPENDS</code> + and <code class="varname">DEPENDS</code> definitions, the + <code class="varname">USE_TOOLS</code> definition, as well as + dependencies via <code class="filename">buildlink3.mk</code>, which is + the preferred way to handle dependencies, and which uses the + variables named above. See <a href="#buildlink" title="Chapter 12. Buildlink methodology">Chapter 12, <i>Buildlink methodology</i></a> for more + information.</p> <p>The basic difference between the two variables is as - follows: The <code class="varname">DEPENDS</code> definition registers - that pre-requisite in the binary package so it will be pulled in - when the binary package is later installed, whilst the - <code class="varname">BUILD_DEPENDS</code> definition does not, marking a - dependency that is only needed for building the package. -</p> + follows: The <code class="varname">DEPENDS</code> definition registers + that pre-requisite in the binary package so it will be pulled in + when the binary package is later installed, whilst the + <code class="varname">BUILD_DEPENDS</code> definition does not, marking a + dependency that is only needed for building the package.</p> <p>This means that if you only need a package present whilst - you are building, it should be noted as a - <code class="varname">BUILD_DEPENDS</code>.</p> + you are building, it should be noted as a + <code class="varname">BUILD_DEPENDS</code>.</p> <p>The format for a <code class="varname">BUILD_DEPENDS</code> and a - <code class="varname">DEPENDS</code> definition is:</p> + <code class="varname">DEPENDS</code> definition is:</p> <pre class="programlisting"> - <pre-req-package-name>:../../<category>/<pre-req-package> -</pre> + <pre-req-package-name>:../../<category>/<pre-req-package> + </pre> <p>Please note that the “<span class="quote">pre-req-package-name</span>” - may include any of the wildcard version numbers recognized by - <a href="http://netbsd.gw.com/cgi-bin/man-cgi?pkg_info+1+NetBSD-current"><span class="citerefentry"><span class="refentrytitle">pkg_info</span>(1)</span></a>.</p> + may include any of the wildcard version numbers recognized by + <a href="http://netbsd.gw.com/cgi-bin/man-cgi?pkg_info+1+NetBSD-current"><span class="citerefentry"><span class="refentrytitle">pkg_info</span>(1)</span></a>.</p> <div class="orderedlist"><ol type="1"> <li> <p>If your package needs another package's binaries or - libraries to build or run, and if that package has a - <code class="filename">buildlink3.mk</code> file available, use it: -</p> + libraries to build or run, and if that package has a + <code class="filename">buildlink3.mk</code> file available, use it:</p> <pre class="programlisting"> - .include "../../graphics/jpeg/buildlink3.mk" -</pre> + .include "../../graphics/jpeg/buildlink3.mk" + </pre> </li> <li> <p>If your package needs to use another package to build - itself and there is no <code class="filename">buildlink3.mk</code> - file available, use the <code class="varname">BUILD_DEPENDS</code> - definition:</p> + itself and there is no <code class="filename">buildlink3.mk</code> + file available, use the <code class="varname">BUILD_DEPENDS</code> + definition:</p> <pre class="programlisting"> - BUILD_DEPENDS+= autoconf-2.13:../../devel/autoconf -</pre> + BUILD_DEPENDS+= autoconf-2.13:../../devel/autoconf + </pre> </li> <li> <p>If your package needs a library with which to link and again there is no <code class="filename">buildlink3.mk</code> file - available, this is specified using the - <code class="varname">DEPENDS</code> definition. For example:</p> + available, this is specified using the + <code class="varname">DEPENDS</code> definition. For example:</p> <pre class="programlisting"> - DEPENDS+= xpm-3.4j:../../graphics/xpm -</pre> + DEPENDS+= xpm-3.4j:../../graphics/xpm + </pre> <p>You can also use wildcards in package dependences:</p> <pre class="programlisting"> - DEPENDS+= xpm-[0-9]*:../../graphics/xpm -</pre> + DEPENDS+= xpm-[0-9]*:../../graphics/xpm + </pre> <p>Note that such wildcard dependencies are retained when - creating binary packages. The dependency is checked when - installing the binary package and any package which matches - the pattern will be used. Wildcard dependencies should be - used with care.</p> + 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 “<span class="quote">-[0-9]*</span>” should be used instead of - “<span class="quote">-*</span>” to avoid potentially ambiguous matches - such as “<span class="quote">tk-postgresql</span>” matching a - “<span class="quote">tk-*</span>” <code class="varname">DEPENDS</code>.</p> + “<span class="quote">-*</span>” to avoid potentially ambiguous matches + such as “<span class="quote">tk-postgresql</span>” matching a + “<span class="quote">tk-*</span>” <code class="varname">DEPENDS</code>.</p> <p>Wildcards can also be used to specify that a package - will only build against a certain minimum version of a - pre-requisite:</p> + will only build against a certain minimum version of a + pre-requisite:</p> <pre class="programlisting"> - DEPENDS+= tiff>=3.5.4:../../graphics/tiff -</pre> + DEPENDS+= tiff>=3.5.4:../../graphics/tiff + </pre> <p>This means that the package will build against version - 3.5.4 of the tiff library or newer. Such a dependency may - be warranted if, for example, the API of the library has - changed with version 3.5.4 and a package would not compile - against an earlier version of tiff.</p> + 3.5.4 of the tiff library or newer. Such a dependency may + be warranted if, for example, the API of the library has + changed with version 3.5.4 and a package would not compile + against an earlier version of tiff.</p> <p>Please note that such dependencies should only be - updated if a package requires a newer pre-requisite, but - not to denote recommendations such as - ABI changes that do not prevent a package from building - correctly. Such recommendations can be expressed using - <code class="varname">ABI_DEPENDS</code>:</p> + updated if a package requires a newer pre-requisite, but + not to denote recommendations such as + ABI changes that do not prevent a package from building + correctly. Such recommendations can be expressed using + <code class="varname">ABI_DEPENDS</code>:</p> <pre class="programlisting"> - ABI_DEPENDS+= tiff>=3.6.1:../../graphics/tiff -</pre> + ABI_DEPENDS+= tiff>=3.6.1:../../graphics/tiff + </pre> <p>In addition to the above <code class="varname">DEPENDS</code> - line, this denotes that while a package will build against - tiff>=3.5.4, at least version 3.6.1 is recommended. - <code class="varname">ABI_DEPENDS</code> entries will be turned into - dependencies unless explicitly ignored (in which case a - warning will be printed).</p> + line, this denotes that while a package will build against + tiff>=3.5.4, at least version 3.6.1 is recommended. + <code class="varname">ABI_DEPENDS</code> entries will be turned into + dependencies unless explicitly ignored (in which case a + warning will be printed).</p> <p>To ignore these ABI dependency recommendations and just - use the required <code class="varname">DEPENDS</code>, set - <code class="varname">USE_ABI_DEPENDS=NO</code>. This may make - it easier and faster to update packages built using pkgsrc, - since older compatible dependencies can continue to be - used. This is useful for people who watch their rebuilds - very carefully; it is not very good as a general-purpose - hammer. If you use it, you need to be mindful of possible - ABI changes, including those from the underlying OS. -</p> + use the required <code class="varname">DEPENDS</code>, set + <code class="varname">USE_ABI_DEPENDS=NO</code>. This may make + it easier and faster to update packages built using pkgsrc, + since older compatible dependencies can continue to be + used. This is useful for people who watch their rebuilds + very carefully; it is not very good as a general-purpose + hammer. If you use it, you need to be mindful of possible + ABI changes, including those from the underlying OS.</p> <p>Packages that are built with recommendations ignored - may not be uploaded to ftp.NetBSD.org by developers and - should not be used across different systems that may have - different versions of binary packages installed.</p> + may not be uploaded to ftp.NetBSD.org by developers and + should not be used across different systems that may have + different versions of binary packages installed.</p> <p>For security fixes, please update the package - vulnerabilities file. See <a href="#security-handling" title="17.1.10. Handling packages with security problems">Section 17.1.10, “Handling packages with security problems”</a> for more - information.</p> + vulnerabilities file. See <a href="#security-handling" title="17.1.10. Handling packages with security problems">Section 17.1.10, “Handling packages with security problems”</a> for more + information.</p> </li> <li> <p>If your package needs some executable to be able to run - correctly and if there's no - <code class="filename">buildlink3.mk</code> file, this is specified - using the <code class="varname">DEPENDS</code> variable. The - <a href="ftp://ftp.NetBSD.org/pub/NetBSD/packages/pkgsrc/print/lyx/README.html" target="_top"><code class="filename">print/lyx</code></a> package needs to - be able to execute the latex binary from the teTeX package - when it runs, and that is specified:</p> + correctly and if there's no + <code class="filename">buildlink3.mk</code> file, this is specified + using the <code class="varname">DEPENDS</code> variable. The + <a href="ftp://ftp.NetBSD.org/pub/NetBSD/packages/pkgsrc/print/lyx/README.html" target="_top"><code class="filename">print/lyx</code></a> package needs to + be able to execute the latex binary from the teTeX package + when it runs, and that is specified:</p> <pre class="programlisting"> - DEPENDS+= teTeX-[0-9]*:../../print/teTeX -</pre> + DEPENDS+= teTeX-[0-9]*:../../print/teTeX + </pre> <p>The comment about wildcard dependencies from previous - paragraph applies here, too.</p> + paragraph applies here, too.</p> </li> </ol></div> <p>If your package needs files from another package to build, - add the relevant distribution files to - <code class="varname">DISTFILES</code>, so they will be extracted - automatically. See the <a href="ftp://ftp.NetBSD.org/pub/NetBSD/packages/pkgsrc/print/ghostscript/README.html" target="_top"><code class="filename">print/ghostscript</code></a> package for an example. - (It relies on the jpeg sources being present in source form - during the build.)</p> + add the relevant distribution files to + <code class="varname">DISTFILES</code>, so they will be extracted + automatically. See the <a href="ftp://ftp.NetBSD.org/pub/NetBSD/packages/pkgsrc/print/ghostscript/README.html" target="_top"><code class="filename">print/ghostscript</code></a> package for an example. + (It relies on the jpeg sources being present in source form + during the build.)</p> <p>Please also note the <code class="varname">BUILD_USES_MSGFMT</code> - and <code class="varname">BUILD_USES_GETTEXT_M4</code> definitions, which - are provided as convenience definitions. The former works out - whether <a href="http://netbsd.gw.com/cgi-bin/man-cgi?msgfmt+1+NetBSD-current"><span class="citerefentry"><span class="refentrytitle">msgfmt</span>(1)</span></a> is part of the base system, and, if it isn't, - installs the <a href="ftp://ftp.NetBSD.org/pub/NetBSD/packages/pkgsrc/devel/gettext/README.html" target="_top"><code class="filename">devel/gettext</code></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 href="ftp://ftp.NetBSD.org/pub/NetBSD/packages/pkgsrc/devel/gettext-m4/README.html" target="_top"><code class="filename">devel/gettext-m4</code></a> package.</p> + and <code class="varname">BUILD_USES_GETTEXT_M4</code> definitions, which + are provided as convenience definitions. The former works out + whether <a href="http://netbsd.gw.com/cgi-bin/man-cgi?msgfmt+1+NetBSD-current"><span class="citerefentry"><span class="refentrytitle">msgfmt</span>(1)</span></a> is part of the base system, and, if it isn't, + installs the <a href="ftp://ftp.NetBSD.org/pub/NetBSD/packages/pkgsrc/devel/gettext/README.html" target="_top"><code class="filename">devel/gettext</code></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 href="ftp://ftp.NetBSD.org/pub/NetBSD/packages/pkgsrc/devel/gettext-m4/README.html" target="_top"><code class="filename">devel/gettext-m4</code></a> package.</p> </div> <div class="sect2" lang="en"> <div class="titlepage"><div><div><h3 class="title"> <a name="conflicts"></a>17.1.7. Handling conflicts with other packages</h3></div></div></div> <p>Your package may conflict with other packages a user might - already have installed on his system, e.g. if your package - installs the same set of files like another package in our - pkgsrc tree.</p> + already have installed on his system, e.g. if your package + installs the same set of files like another package in our + pkgsrc tree.</p> <p>In this case you can set <code class="varname">CONFLICTS</code> to a - space-separated list of packages (including version string) your - package conflicts with.</p> + space-separated list of packages (including version string) your + package conflicts with.</p> <p>For example, <a href="ftp://ftp.NetBSD.org/pub/NetBSD/packages/pkgsrc/x11/Xaw3d/README.html" target="_top"><code class="filename">x11/Xaw3d</code></a> - and <a href="ftp://ftp.NetBSD.org/pub/NetBSD/packages/pkgsrc/x11/Xaw-Xpm/README.html" target="_top"><code class="filename">x11/Xaw-Xpm</code></a> - install the same shared library, thus you set in - <code class="filename">pkgsrc/x11/Xaw3d/Makefile</code>:</p> + and <a href="ftp://ftp.NetBSD.org/pub/NetBSD/packages/pkgsrc/x11/Xaw-Xpm/README.html" target="_top"><code class="filename">x11/Xaw-Xpm</code></a> + install the same shared library, thus you set in + <code class="filename">pkgsrc/x11/Xaw3d/Makefile</code>:</p> <pre class="programlisting"> - CONFLICTS= Xaw-Xpm-[0-9]* -</pre> -<p>and in <code class="filename">pkgsrc/x11/Xaw-Xpm/Makefile</code>: -</p> + CONFLICTS= Xaw-Xpm-[0-9]* + </pre> +<p>and in <code class="filename">pkgsrc/x11/Xaw-Xpm/Makefile</code>:</p> <pre class="programlisting"> - CONFLICTS= Xaw3d-[0-9]* -</pre> + CONFLICTS= Xaw3d-[0-9]* + </pre> <p>Packages will automatically conflict with other packages - with the name prefix and a different version - string. “<span class="quote">Xaw3d-1.5</span>” e.g. will automatically - conflict with the older version “<span class="quote">Xaw3d-1.3</span>”. -</p> + with the name prefix and a different version + string. “<span class="quote">Xaw3d-1.5</span>” e.g. will automatically + conflict with the older version “<span class="quote">Xaw3d-1.3</span>”.</p> </div> <div class="sect2" lang="en"> <div class="titlepage"><div><div><h3 class="title"> <a name="not-building-packages"></a>17.1.8. Packages that cannot or should not be built</h3></div></div></div> <p>There are several reasons why a package might be - instructed to not build under certain circumstances. If the - package builds and runs on most platforms, the exceptions - should be noted with <code class="varname">NOT_FOR_PLATFORM</code>. If - the package builds and runs on a small handful of platforms, - set <code class="varname">ONLY_FOR_PLATFORM</code> instead. - Both <code class="varname">ONLY_FOR_PLATFORM</code> and - <code class="varname">NOT_FOR_PLATFORM</code> are OS triples - (OS-version-platform) that can use glob-style - wildcards.</p> + instructed to not build under certain circumstances. If the + package builds and runs on most platforms, the exceptions + should be noted with <code class="varname">NOT_FOR_PLATFORM</code>. If + the package builds and runs on a small handful of platforms, + set <code class="varname">ONLY_FOR_PLATFORM</code> instead. + Both <code class="varname">ONLY_FOR_PLATFORM</code> and + <code class="varname">NOT_FOR_PLATFORM</code> are OS triples + (OS-version-platform) that can use glob-style + wildcards.</p> <p>If the package should be skipped (for example, because it - provides functionality already provided by the system), set - <code class="varname">PKG_SKIP_REASON</code> to a descriptive message. - If the package should fail because some preconditions are not - met, set <code class="varname">PKG_FAIL_REASON</code> to a descriptive - message.</p> + provides functionality already provided by the system), set + <code class="varname">PKG_SKIP_REASON</code> to a descriptive message. + If the package should fail because some preconditions are not + met, set <code class="varname">PKG_FAIL_REASON</code> to a descriptive + message.</p> </div> <div class="sect2" lang="en"> <div class="titlepage"><div><div><h3 class="title"> <a name="undeletable-packages"></a>17.1.9. Packages which should not be deleted, once installed</h3></div></div></div> <p>To ensure that a package may not be deleted, once it has been - installed, the <code class="varname">PKG_PRESERVE</code> definition should - be set in the package Makefile. This will be carried into any - binary package that is made from this pkgsrc entry. A - “<span class="quote">preserved</span>” package will - not be deleted using <a href="http://netbsd.gw.com/cgi-bin/man-cgi?pkg_delete+1+NetBSD-current"><span class="citerefentry"><span class="refentrytitle">pkg_delete</span>(1)</span></a> unless the - “<span class="quote">-f</span>” option is used.</p> + installed, the <code class="varname">PKG_PRESERVE</code> definition should + be set in the package Makefile. This will be carried into any + binary package that is made from this pkgsrc entry. A + “<span class="quote">preserved</span>” package will + not be deleted using <a href="http://netbsd.gw.com/cgi-bin/man-cgi?pkg_delete+1+NetBSD-current"><span class="citerefentry"><span class="refentrytitle">pkg_delete</span>(1)</span></a> unless the + “<span class="quote">-f</span>” option is used.</p> </div> <div class="sect2" lang="en"> <div class="titlepage"><div><div><h3 class="title"> <a name="security-handling"></a>17.1.10. Handling packages with security problems</h3></div></div></div> <p>When a vulnerability is found, this should be noted in - <code class="filename">localsrc/security/advisories/pkg-vulnerabilities</code>, - and after committing that file, use <span><strong class="command">make upload</strong></span> - in the same directory to update the file on ftp.NetBSD.org.</p> + <code class="filename">localsrc/security/advisories/pkg-vulnerabilities</code>, + and after committing that file, use <span><strong class="command">make upload</strong></span> + in the same directory to update the file on ftp.NetBSD.org.</p> <p>After fixing the vulnerability by a patch, its - <code class="varname">PKGREVISION</code> should be increased (this - is of course not necessary if the problem is fixed by using - a newer release of the software).</p> + <code class="varname">PKGREVISION</code> should be increased (this + is of course not necessary if the problem is fixed by using + a newer release of the software).</p> <p>Also, if the fix should be applied to the stable pkgsrc - branch, be sure to submit a pullup request!</p> + branch, be sure to submit a pullup request!</p> <p>Binary packages already on ftp.NetBSD.org will be handled - semi-automatically by a weekly cron job.</p> + semi-automatically by a weekly cron job.</p> </div> <div class="sect2" lang="en"> <div class="titlepage"><div><div><h3 class="title"> <a name="bumping-pkgrevision"></a>17.1.11. How to handle incrementing versions when fixing an existing package</h3></div></div></div> <p>When making fixes to an existing package it can be useful - to change the version number in <code class="varname">PKGNAME</code>. To - avoid conflicting with future versions by the original author, a - “<span class="quote">nb1</span>”, “<span class="quote">nb2</span>”, ... suffix can be used - on package versions by setting <code class="varname">PKGREVISION=1</code> - (2, ...). The “<span class="quote">nb</span>” is treated like a - “<span class="quote">.</span>” by the pkg tools. e.g.</p> + to change the version number in <code class="varname">PKGNAME</code>. To + avoid conflicting with future versions by the original author, a + “<span class="quote">nb1</span>”, “<span class="quote">nb2</span>”, ... suffix can be used + on package versions by setting <code class="varname">PKGREVISION=1</code> + (2, ...). The “<span class="quote">nb</span>” is treated like a + “<span class="quote">.</span>” by the package tools. e.g.</p> <pre class="programlisting"> - DISTNAME= foo-17.42 - PKGREVISION= 9 -</pre> + DISTNAME= foo-17.42 + PKGREVISION= 9 + </pre> <p>will result in a <code class="varname">PKGNAME</code> of - “<span class="quote">foo-17.42nb9</span>”.</p> + “<span class="quote">foo-17.42nb9</span>”. If you want to use the original + value of <code class="varname">PKGNAME</code> without the “<span class="quote">nbX</span>” + suffix, e.g. for setting <code class="varname">DIST_SUBDIR</code>, use + <code class="varname">PKGNAME_NOREV</code>.</p> <p>When a new release of the package is released, the - <code class="varname">PKGREVISION</code> should be removed, e.g. on a new - minor release of the above package, things should be like:</p> + <code class="varname">PKGREVISION</code> should be removed, e.g. on a new + minor release of the above package, things should be like:</p> <pre class="programlisting"> - DISTNAME= foo-17.43 -</pre> -<p>PKGREVISION should be incremented for any non-trivial change in the - resulting binary package. Without a PKGREVISION bump, someone with - the previous version installed has no way of knowing that their - package is out of date. Thus, changes without increasing PKGREVISION - are essentially labeled "this is so trivial that no reasonable person - would want to upgrade", and this is the rough test for when increasing - PKGREVISION is appropriate. Examples of changes that do not merit - increasing PKGREVISION are:</p> + DISTNAME= foo-17.43 + </pre> +<p><code class="varname">PKGREVISION</code> should be incremented for any + non-trivial change in the resulting binary package. Without a + <code class="varname">PKGREVISION</code> bump, someone with the previous + version installed has no way of knowing that their package is out + of date. Thus, changes without increasing + <code class="varname">PKGREVISION</code> are essentially labeled "this is so + trivial that no reasonable person would want to upgrade", and this + is the rough test for when increasing + <code class="varname">PKGREVISION</code> is appropriate. Examples of + changes that do not merit increasing + <code class="varname">PKGREVISION</code> are:</p> <pre class="programlisting"> -Changing HOMEPAGE, MAINTAINER, or comments in Makefile. -Changing build variables if the resulting binary package is the same. -Changing DESCR. -Adding PKG_OPTIONS if the default options don't change. -</pre> -<p>Examples of changes that do merit an increase to PKGREVISION - include:</p> + Changing <code class="varname">HOMEPAGE</code>, <code class="varname">MAINTAINER</code>, + or comments in Makefile. + Changing build variables if the resulting binary package is the same. + Changing <code class="filename">DESCR</code>. + Adding <code class="varname">PKG_OPTIONS</code> if the default options don't change. + </pre> +<p>Examples of changes that do merit an increase to + <code class="varname">PKGREVISION</code> include:</p> <pre class="programlisting"> -Security fixes -Changes or additions to a patch file -Changes to the PLIST -</pre> + Security fixes + Changes or additions to a patch file + Changes to the <code class="filename">PLIST</code> + </pre> <p>PKGREVISION must also be incremented when dependencies have ABI changes.</p> </div> @@ -7220,60 +7210,60 @@ Changes to the PLIST <div class="titlepage"><div><div><h3 class="title"> <a name="fixes.subst"></a>17.1.12. Substituting variable text in the package files (the SUBST framework)</h3></div></div></div> <p>When you want to replace the same text in multiple files - or when the replacement text varies, patches alone cannot help. - This is where the SUBST framework comes in. It provides an - easy-to-use interface for replacing text in files. - Example:</p> + or when the replacement text varies, patches alone cannot help. + This is where the SUBST framework comes in. It provides an + easy-to-use interface for replacing text in files. + Example:</p> <pre class="programlisting"> - SUBST_CLASSES+= fix-paths - SUBST_STAGE.fix-paths= pre-configure - SUBST_MESSAGE.fix-paths= Fixing absolute paths. - SUBST_FILES.fix-paths= src/*.c - SUBST_FILES.fix-paths+= scripts/*.sh - SUBST_SED.fix-paths= -e 's,"/usr/local,"${PREFIX},g' - SUBST_SED.fix-paths+= -e 's,"/var/log,"${VARBASE}/log,g' -</pre> + SUBST_CLASSES+= fix-paths + SUBST_STAGE.fix-paths= pre-configure + SUBST_MESSAGE.fix-paths= Fixing absolute paths. + SUBST_FILES.fix-paths= src/*.c + SUBST_FILES.fix-paths+= scripts/*.sh + SUBST_SED.fix-paths= -e 's,"/usr/local,"${PREFIX},g' + SUBST_SED.fix-paths+= -e 's,"/var/log,"${VARBASE}/log,g' + </pre> <p><code class="varname">SUBST_CLASSES</code> is a list of identifiers - that are used to identify the different SUBST blocks that are - defined. The SUBST framework is heavily used by pkgsrc, so it is - important to always use the <code class="literal">+=</code> operator with - this variable. Otherwise some substitutions may be - skipped.</p> + that are used to identify the different SUBST blocks that are + defined. The SUBST framework is heavily used by pkgsrc, so it is + important to always use the <code class="literal">+=</code> operator with + this variable. Otherwise some substitutions may be + skipped.</p> <p>The remaining variables of each SUBST block are - parameterized with the identifier from the first line - (<code class="literal">fix-paths</code> in this case.) They can be seen as - parameters to a function call.</p> + parameterized with the identifier from the first line + (<code class="literal">fix-paths</code> in this case.) They can be seen as + parameters to a function call.</p> <p><code class="varname">SUBST_STAGE.*</code> specifies the stage at - which the replacement will take place. All combinations of - <code class="literal">pre-</code>, <code class="literal">do-</code> and - <code class="literal">post-</code> together with a phase name are - possible, though only few are actually used. Most commonly used - are <code class="literal">post-patch</code> and - <code class="literal">pre-configure</code>. Of these two, - <code class="literal">pre-configure</code> should be preferred because - then it is possible to run <span><strong class="command">bmake patch</strong></span> and - have the state after applying the patches but before making any - other changes. This is especially useful when you are debugging - a package in order to create new patches for it. Similarly, - <code class="literal">post-build</code> is preferred over - <code class="literal">pre-install</code>, because the install phase should - generally be kept as simple as possible. When you use - <code class="literal">post-build</code>, you have the same files in the - working directory that will be installed later, so you can check - if the substitution has succeeded.</p> + which the replacement will take place. All combinations of + <code class="literal">pre-</code>, <code class="literal">do-</code> and + <code class="literal">post-</code> together with a phase name are + possible, though only few are actually used. Most commonly used + are <code class="literal">post-patch</code> and + <code class="literal">pre-configure</code>. Of these two, + <code class="literal">pre-configure</code> should be preferred because + then it is possible to run <span><strong class="command">bmake patch</strong></span> and + have the state after applying the patches but before making any + other changes. This is especially useful when you are debugging + a package in order to create new patches for it. Similarly, + <code class="literal">post-build</code> is preferred over + <code class="literal">pre-install</code>, because the install phase should + generally be kept as simple as possible. When you use + <code class="literal">post-build</code>, you have the same files in the + working directory that will be installed later, so you can check + if the substitution has succeeded.</p> <p><code class="varname">SUBST_MESSAGE.*</code> is an optional text - that is printed just before the substitution is done.</p> + that is printed just before the substitution is done.</p> <p><code class="varname">SUBST_FILES.*</code> is the list of shell - globbing patterns that specifies the files in which the - substitution will take place. The patterns are interpreted - relatively to the <code class="varname">WRKSRC</code> directory.</p> + globbing patterns that specifies the files in which the + substitution will take place. The patterns are interpreted + relatively to the <code class="varname">WRKSRC</code> directory.</p> <p><code class="varname">SUBST_SED.*</code> is a list of arguments to - <a href="http://netbsd.gw.com/cgi-bin/man-cgi?sed+1+NetBSD-current"><span class="citerefentry"><span class="refentrytitle">sed</span>(1)</span></a> that specify the actual substitution. Every sed - command should be prefixed with <code class="literal">-e</code>, so that - all SUBST blocks look uniform.</p> + <a href="http://netbsd.gw.com/cgi-bin/man-cgi?sed+1+NetBSD-current"><span class="citerefentry"><span class="refentrytitle">sed</span>(1)</span></a> that specify the actual substitution. Every sed + command should be prefixed with <code class="literal">-e</code>, so that + all SUBST blocks look uniform.</p> <p>There are some more variables, but they are so seldomly - used that they are only documented in the - <code class="filename">mk/subst.mk</code> file.</p> + used that they are only documented in the + <code class="filename">mk/subst.mk</code> file.</p> </div> </div> <div class="sect1" lang="en"> @@ -7283,46 +7273,49 @@ Changes to the PLIST <div class="titlepage"><div><div><h3 class="title"> <a name="no-plain-download"></a>17.2.1. Packages whose distfiles aren't available for plain downloading</h3></div></div></div> <p>If you need to download from a dynamic URL you can set - <code class="varname">DYNAMIC_MASTER_SITES</code> and a <span><strong class="command">make - fetch</strong></span> will call <code class="filename">files/getsite.sh</code> - with the name of each file to download as an argument, expecting - it to output the URL of the directory from which to download - it. <a href="ftp://ftp.NetBSD.org/pub/NetBSD/packages/pkgsrc/graphics/ns-cult3d/README.html" target="_top"><code class="filename">graphics/ns-cult3d</code></a> is an - example of this usage.</p> + <code class="varname">DYNAMIC_MASTER_SITES</code> and a <span><strong class="command">make + fetch</strong></span> will call <code class="filename">files/getsite.sh</code> + with the name of each file to download as an argument, expecting + it to output the URL of the directory from which to download + it. <a href="ftp://ftp.NetBSD.org/pub/NetBSD/packages/pkgsrc/graphics/ns-cult3d/README.html" target="_top"><code class="filename">graphics/ns-cult3d</code></a> is an + example of this usage.</p> <p>If the download can't be automated, because the user must - submit personal information to apply for a password, or must pay - for the source, or whatever, you can set - <code class="varname">FETCH_MESSAGE</code> to a list of lines that are - displayed to the user before aborting the build. Example:</p> + submit personal information to apply for a password, or must pay + for the source, or whatever, you can set + <code class="varname">FETCH_MESSAGE</code> to a list of lines that are + displayed to the user before aborting the build. Example:</p> <pre class="programlisting"> - FETCH_MESSAGE= "Please download the files" - FETCH_MESSAGE+= " "${DISTFILES:Q} - FETCH_MESSAGE+= "manually from "${MASTER_SITES:Q}"." -</pre> + FETCH_MESSAGE= "Please download the files" + FETCH_MESSAGE+= " "${DISTFILES:Q} + FETCH_MESSAGE+= "manually from "${MASTER_SITES:Q}"." + </pre> </div> <div class="sect2" lang="en"> <div class="titlepage"><div><div><h3 class="title"> <a name="modified-distfiles-same-name"></a>17.2.2. How to handle modified distfiles with the 'old' name</h3></div></div></div> <p>Sometimes authors of a software package make some - modifications after the software was released, and they put up a - new distfile without changing the package's version number. If a - package is already in pkgsrc at that time, the checksum will - no longer match. The contents of the new distfile should be - compared against the old one before changing anything, to make - sure the distfile was really updated on purpose, and that - no trojan horse or so crept in. - Then, the correct way to work around this is to - set <code class="varname">DIST_SUBDIR</code> to a unique directory name, - usually based on <code class="varname">PKGNAME_NOREV</code>. In case this - happens more often, <code class="varname">PKGNAME</code> can be used (thus - including the <code class="filename">nbX</code> suffix) or a date stamp - can be appended, like <code class="varname">${PKGNAME_NOREV}-YYYYMMDD</code>. - Do not forget regenerating the <code class="filename">distinfo</code> file - after that, since it contains the <code class="varname">DIST_SUBDIR</code> - path in the filenames. - Furthermore, a mail to the package's authors seems appropriate - telling them that changing distfiles after releases without - changing the file names is not good practice.</p> + 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 checksum will + no longer match. The contents of the new distfile should be + compared against the old one before changing anything, to make + sure the distfile was really updated on purpose, and that + no trojan horse or so crept in. + Then, the correct way to work around this is to + set <code class="varname">DIST_SUBDIR</code> to a unique directory name, + usually based on <code class="varname">PKGNAME_NOREV</code>. All + <code class="varname">DISTFILES</code> and + <code class="varname">PATCHFILES</code> for this package will be put in that + subdirectory of the local distfiles directory. In case this + happens more often, <code class="varname">PKGNAME</code> can be used (thus + including the <code class="filename">nbX</code> suffix) or a date stamp + can be appended, like <code class="varname">${PKGNAME_NOREV}-YYYYMMDD</code>. + Do not forget regenerating the <code class="filename">distinfo</code> file + after that, since it contains the <code class="varname">DIST_SUBDIR</code> + path in the filenames. + Furthermore, a mail to the package's authors seems appropriate + telling them that changing distfiles after releases without + changing the file names is not good practice.</p> </div> </div> <div class="sect1" lang="en"> @@ -7332,209 +7325,278 @@ Changes to the PLIST <div class="titlepage"><div><div><h3 class="title"> <a name="fixes.libtool"></a>17.3.1. Shared libraries - libtool</h3></div></div></div> <p>pkgsrc supports many different machines, with different - object formats like a.out and ELF, and varying abilities to do - shared library and dynamic loading at all. To accompany this, - 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 href="ftp://ftp.NetBSD.org/pub/NetBSD/packages/pkgsrc/devel/libtool/README.html" target="_top"><code class="filename">devel/libtool</code></a> pkg - can help here, as it just “<span class="quote">knows</span>” how to build - both static and dynamic libraries from a set of source files, - thus being platform-independent.</p> -<p>Here's how to use libtool in a pkg in seven simple - steps:</p> + 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 href="ftp://ftp.NetBSD.org/pub/NetBSD/packages/pkgsrc/devel/libtool/README.html" target="_top"><code class="filename">devel/libtool</code></a> pkg + can help here, as it just “<span class="quote">knows</span>” how to build + both static and dynamic libraries from a set of source files, + thus being platform-independent.</p> +<p>Here's how to use libtool in a package in seven simple + steps:</p> <div class="orderedlist"><ol type="1"> <li><p>Add <code class="varname">USE_LIBTOOL=yes</code> to the package - Makefile.</p></li> + Makefile.</p></li> <li><p>For library objects, use “<span class="quote">${LIBTOOL} --mode=compile - ${CC}</span>” in place of “<span class="quote">${CC}</span>”. You could even - add it to the definition of <code class="varname">CC</code>, if only - libraries are being built in a given Makefile. This one command - will build both PIC and non-PIC library objects, so you need not - have separate shared and non-shared library rules.</p></li> + ${CC}</span>” in place of “<span class="quote">${CC}</span>”. You could even + add it to the definition of <code class="varname">CC</code>, if only + libraries are being built in a given Makefile. This one command + will build both PIC and non-PIC library objects, so you need not + have separate shared and non-shared library rules.</p></li> <li> <p>For the linking of the library, remove any - “<span class="quote">ar</span>”, “<span class="quote">ranlib</span>”, and “<span class="quote">ld - -Bshareable</span>” commands, and instead use:</p> + “<span class="quote">ar</span>”, “<span class="quote">ranlib</span>”, and “<span class="quote">ld + -Bshareable</span>” commands, and instead use:</p> <pre class="programlisting"> - ${LIBTOOL} --mode=link ${CC} -o ${.TARGET:.a=.la} ${OBJS:.o=.lo} \ - -rpath ${PREFIX}/lib -version-info major:minor -</pre> + ${LIBTOOL} --mode=link ${CC} -o ${.TARGET:.a=.la} ${OBJS:.o=.lo} \ + -rpath ${PREFIX}/lib -version-info major:minor + </pre> <p>Note that the library is changed to have a - <code class="filename">.la</code> extension, and the objects are - changed to have a <code class="filename">.lo</code> - extension. Change <code class="varname">OBJS</code> as - necessary. This automatically creates all of the - <code class="filename">.a</code>, - <code class="filename">.so.major.minor</code>, and ELF symlinks (if - necessary) in the build directory. Be sure to include - “<span class="quote">-version-info</span>”, especially when major and - minor are zero, as libtool will otherwise strip off the - shared library version.</p> + <code class="filename">.la</code> extension, and the objects are + changed to have a <code class="filename">.lo</code> + extension. Change <code class="varname">OBJS</code> as + necessary. This automatically creates all of the + <code class="filename">.a</code>, + <code class="filename">.so.major.minor</code>, and ELF symlinks (if + necessary) in the build directory. Be sure to include + “<span class="quote">-version-info</span>”, especially when major and + minor are zero, as libtool will otherwise strip off the + shared library version.</p> <p>From the libtool manual:</p> <pre class="programlisting"> - So, libtool library versions are described by three integers: + So, libtool library versions are described by three integers: - CURRENT - The most recent interface number that this library implements. + CURRENT + The most recent interface number that this library implements. - REVISION - The implementation number of the CURRENT interface. + REVISION + The implementation number of the CURRENT interface. - AGE - The difference between the newest and oldest interfaces that - this library implements. In other words, the library implements - all the interface numbers in the range from number `CURRENT - - AGE' to `CURRENT'. + AGE + The difference between the newest and oldest interfaces that + this library implements. In other words, the library implements + all the interface numbers in the range from number `CURRENT - + AGE' to `CURRENT'. - If two libraries have identical CURRENT and AGE numbers, then the - dynamic linker chooses the library with the greater REVISION number. -</pre> + If two libraries have identical CURRENT and AGE numbers, then the + dynamic linker chooses the library with the greater REVISION number. + </pre> <p>The “<span class="quote">-release</span>” option will produce - different results for a.out and ELF (excluding symlinks) - in only one case. An ELF library of the form - “<span class="quote">libfoo-release.so.<span class="emphasis"><em>x</em></span>.<span class="emphasis"><em>y</em></span></span>” - will have a symlink of - “<span class="quote">libfoo.so.<span class="emphasis"><em>x</em></span>.<span class="emphasis"><em>y</em></span></span>” - on an a.out platform. This is handled - automatically.</p> + different results for a.out and ELF (excluding symlinks) + in only one case. An ELF library of the form + “<span class="quote">libfoo-release.so.<span class="emphasis"><em>x</em></span>.<span class="emphasis"><em>y</em></span></span>” + will have a symlink of + “<span class="quote">libfoo.so.<span class="emphasis"><em>x</em></span>.<span class="emphasis"><em>y</em></span></span>” + on an a.out platform. This is handled + automatically.</p> <p>The “<span class="quote">-rpath argument</span>” is the install - directory of the library being built.</p> + directory of the library being built.</p> <p>In the <code class="filename">PLIST</code>, include only the - <code class="filename">.la</code> file, the other files will be - added automatically.</p> + <code class="filename">.la</code> file, the other files will be + added automatically.</p> </li> <li> <p>When linking shared object (<code class="filename">.so</code>) - files, i.e. files that are loaded via <a href="http://netbsd.gw.com/cgi-bin/man-cgi?dlopen+3+NetBSD-current"><span class="citerefentry"><span class="refentrytitle">dlopen</span>(3)</span></a>, NOT - shared libraries, use “<span class="quote">-module - -avoid-version</span>” to prevent them getting version - tacked on.</p> + files, i.e. files that are loaded via <a href="http://netbsd.gw.com/cgi-bin/man-cgi?dlopen+3+NetBSD-current"><span class="citerefentry"><span class="refentrytitle">dlopen</span>(3)</span></a>, NOT + shared libraries, use “<span class="quote">-module + -avoid-version</span>” to prevent them getting version + tacked on.</p> <p>The <code class="filename">PLIST</code> file gets the - <code class="filename">foo.so</code> entry.</p> + <code class="filename">foo.so</code> entry.</p> </li> <li> <p>When linking programs that depend on these libraries - <span class="emphasis"><em>before</em></span> they are installed, preface - the <a href="http://netbsd.gw.com/cgi-bin/man-cgi?cc+1+NetBSD-current"><span class="citerefentry"><span class="refentrytitle">cc</span>(1)</span></a> or <a href="http://netbsd.gw.com/cgi-bin/man-cgi?ld+1+NetBSD-current"><span class="citerefentry"><span class="refentrytitle">ld</span>(1)</span></a> line with “<span class="quote">${LIBTOOL} - --mode=link</span>”, and it will find the correct - libraries (static or shared), but please be aware that - libtool will not allow you to specify a relative path in - -L (such as “<span class="quote">-L../somelib</span>”), because it - expects you to change that argument to be the - <code class="filename">.la</code> file. e.g.</p> + <span class="emphasis"><em>before</em></span> they are installed, preface + the <a href="http://netbsd.gw.com/cgi-bin/man-cgi?cc+1+NetBSD-current"><span class="citerefentry"><span class="refentrytitle">cc</span>(1)</span></a> or <a href="http://netbsd.gw.com/cgi-bin/man-cgi?ld+1+NetBSD-current"><span class="citerefentry"><span class="refentrytitle">ld</span>(1)</span></a> line with “<span class="quote">${LIBTOOL} + --mode=link</span>”, and it will find the correct + libraries (static or shared), but please be aware that + libtool will not allow you to specify a relative path in + -L (such as “<span class="quote">-L../somelib</span>”), because it + expects you to change that argument to be the + <code class="filename">.la</code> file. e.g.</p> <pre class="programlisting"> - ${LIBTOOL} --mode=link ${CC} -o someprog -L../somelib -lsomelib -</pre> + ${LIBTOOL} --mode=link ${CC} -o someprog -L../somelib -lsomelib + </pre> <p>should be changed to:</p> <pre class="programlisting"> - ${LIBTOOL} --mode=link ${CC} -o <em class="replaceable"><code>someprog</code></em> <em class="replaceable"><code>../somelib/somelib.la</code></em> -</pre> + ${LIBTOOL} --mode=link ${CC} -o <em class="replaceable"><code>someprog</code></em> <em class="replaceable"><code>../somelib/somelib.la</code></em> + </pre> <p>and it will do the right thing with the libraries.</p> </li> <li> <p>When installing libraries, preface the <a href="http://netbsd.gw.com/cgi-bin/man-cgi?install+1+NetBSD-current"><span class="citerefentry"><span class="refentrytitle">install</span>(1)</span></a> - or <a href="http://netbsd.gw.com/cgi-bin/man-cgi?cp+1+NetBSD-current"><span class="citerefentry"><span class="refentrytitle">cp</span>(1)</span></a> command with “<span class="quote">${LIBTOOL} - --mode=install</span>”, and change the library name to - <code class="filename">.la</code>. e.g.</p> + or <a href="http://netbsd.gw.com/cgi-bin/man-cgi?cp+1+NetBSD-current"><span class="citerefentry"><span class="refentrytitle">cp</span>(1)</span></a> command with “<span class="quote">${LIBTOOL} + --mode=install</span>”, and change the library name to + <code class="filename">.la</code>. e.g.</p> <pre class="programlisting"> - ${LIBTOOL} --mode=install ${BSD_INSTALL_DATA} ${SOMELIB:.a=.la} ${PREFIX}/lib -</pre> + ${LIBTOOL} --mode=install ${BSD_INSTALL_DATA} ${SOMELIB:.a=.la} ${PREFIX}/lib + </pre> <p>This will install the static <code class="filename">.a</code>, - shared library, any needed symlinks, and run - <a href="http://netbsd.gw.com/cgi-bin/man-cgi?ldconfig+8+NetBSD-current"><span class="citerefentry"><span class="refentrytitle">ldconfig</span>(8)</span></a>.</p> + shared library, any needed symlinks, and run + <a href="http://netbsd.gw.com/cgi-bin/man-cgi?ldconfig+8+NetBSD-current"><span class="citerefentry"><span class="refentrytitle">ldconfig</span>(8)</span></a>.</p> </li> <li><p>In your <code class="filename">PLIST</code>, include only - the <code class="filename">.la</code> - file (this is a change from previous behaviour).</p></li> + the <code class="filename">.la</code> + file (this is a change from previous behaviour).</p></li> </ol></div> </div> <div class="sect2" lang="en"> <div class="titlepage"><div><div><h3 class="title"> <a name="using-libtool"></a>17.3.2. Using libtool on GNU packages that already support libtool</h3></div></div></div> <p>Add <code class="varname">USE_LIBTOOL=yes</code> to the - package Makefile. This will override the package's own libtool - in most cases. For older libtool using packages, libtool is - made by ltconfig script during the do-configure step; you can - check the libtool script location by doing <span><strong class="command">make - configure; find work*/ -name libtool</strong></span>.</p> + package Makefile. This will override the package's own libtool + in most cases. For older libtool using packages, libtool is + made by ltconfig script during the do-configure step; you can + check the libtool script location by doing <span><strong class="command">make + configure; find work*/ -name libtool</strong></span>.</p> <p><code class="varname">LIBTOOL_OVERRIDE</code> specifies which libtool - scripts, relative to <code class="varname">WRKSRC</code>, to override. By - default, it is set to “<span class="quote">libtool */libtool - */*/libtool</span>”. If this does not match the location of the - package's libtool script(s), set it as appropriate.</p> + scripts, relative to <code class="varname">WRKSRC</code>, to override. By + default, it is set to “<span class="quote">libtool */libtool + */*/libtool</span>”. If this does not match the location of the + package's libtool script(s), set it as appropriate.</p> <p>If you do not need <code class="filename">*.a</code> static - libraries built and installed, then use - <code class="varname">SHLIBTOOL_OVERRIDE</code> instead.</p> + libraries built and installed, then use + <code class="varname">SHLIBTOOL_OVERRIDE</code> instead.</p> <p>If your package makes use of the platform-independent library - for loading dynamic shared objects, that comes with libtool - (libltdl), you should include devel/libltdl/buildlink3.mk.</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> + for loading dynamic shared objects, that comes with libtool + (libltdl), you should include devel/libltdl/buildlink3.mk.</p> +<p>Some packages use libtool incorrectly so that the package + may not work or build in some circumstances. Some of the more + common errors are:</p> <div class="itemizedlist"><ul type="disc"> <li> <p>The inclusion of a shared object (-module) as a dependent library in an - executable or library. This in itself isn't a problem if one of two things - has been done:</p> + executable or library. This in itself isn't a problem if one of two things + has been done:</p> <div class="orderedlist"><ol type="1"> <li><p>The shared object is named correctly, i.e. - <code class="filename">libfoo.la</code>, not - <code class="filename">foo.la</code></p></li> + <code class="filename">libfoo.la</code>, not + <code class="filename">foo.la</code></p></li> <li><p>The -dlopen option is used when linking an executable.</p></li> </ol></div> </li> <li><p>The use of libltdl without the correct calls to initialisation routines. - The function lt_dlinit() should be called and the macro - <code class="varname">LTDL_SET_PRELOADED_SYMBOLS</code> included in - executables.</p></li> + The function lt_dlinit() should be called and the macro + <code class="varname">LTDL_SET_PRELOADED_SYMBOLS</code> included in + executables.</p></li> </ul></div> </div> <div class="sect2" lang="en"> <div class="titlepage"><div><div><h3 class="title"> <a name="autoconf-automake"></a>17.3.3. GNU Autoconf/Automake</h3></div></div></div> <p>If a package needs GNU autoconf or automake to be executed - to regenerate the configure script and Makefile.in makefile - templates, then they should be executed in a pre-configure - target.</p> + to regenerate the configure script and Makefile.in makefile + templates, then they should be executed in a pre-configure + target.</p> <p>For packages that need only autoconf:</p> <pre class="programlisting"> - AUTOCONF_REQD= 2.50 # if default version is not good enough - USE_TOOLS+= autoconf # use "autoconf213" for autoconf-2.13 - ... + AUTOCONF_REQD= 2.50 # if default version is not good enough + USE_TOOLS+= autoconf # use "autoconf213" for autoconf-2.13 + ... - pre-configure: - cd ${WRKSRC}; autoconf + pre-configure: + cd ${WRKSRC}; autoconf - ... -</pre> + ... + </pre> <p>and for packages that need automake and autoconf:</p> <pre class="programlisting"> - AUTOMAKE_REQD= 1.7.1 # if default version is not good enough - USE_TOOLS+= automake # use "automake14" for automake-1.4 - ... + AUTOMAKE_REQD= 1.7.1 # if default version is not good enough + USE_TOOLS+= automake # use "automake14" for automake-1.4 + ... - pre-configure: - cd ${WRKSRC}; \ - aclocal; autoheader; \ - automake -a --foreign -i; autoconf + pre-configure: + cd ${WRKSRC}; \ + aclocal; autoheader; \ + automake -a --foreign -i; autoconf - ... -</pre> + ... + </pre> <p>Packages which use GNU Automake will almost certainly - require GNU Make.</p> + require GNU Make.</p> <p>There are times when the configure process makes - additional changes to the generated files, which then causes - the build process to try to re-execute the automake sequence. - This is prevented by touching various files in the configure - stage. If this causes problems with your package you can set - <code class="varname">AUTOMAKE_OVERRIDE=NO</code> in the package - Makefile.</p> + additional changes to the generated files, which then causes + the build process to try to re-execute the automake sequence. + This is prevented by touching various files in the configure + stage. If this causes problems with your package you can set + <code class="varname">AUTOMAKE_OVERRIDE=NO</code> in the package + Makefile.</p> +</div> +</div> +<div class="sect1" lang="en"> +<div class="titlepage"><div><div><h2 class="title" style="clear: both"> +<a name="programming-languages"></a>17.4. Programming languages</h2></div></div></div> +<div class="sect2" lang="en"> +<div class="titlepage"><div><div><h3 class="title"> +<a name="basic-programming-languages"></a>17.4.1. C, C++, and Fortran</h3></div></div></div> +<p>Compilers for the C, C++, and Fortran languages comes with + the NetBSD base system. By default, pkgsrc assumes that a package + is written in C and will hide all other compilers (via the wrapper + framework, see <a href="#buildlink" title="Chapter 12. Buildlink methodology">Chapter 12, <i>Buildlink methodology</i></a>).</p> +<p>To declare which language's compiler a package needs, set + the <code class="varname">USE_LANGUAGES</code> variable. Allowed values + currently are “<span class="quote">c</span>”, “<span class="quote">c++</span>”, and + “<span class="quote">fortran</span>” (and any combination). The default is + “<span class="quote">c</span>”. Packages using GNU configure scripts, even if + written in C++, usually need a C compiler for the configure + phase.</p> +</div> +<div class="sect2" lang="en"> +<div class="titlepage"><div><div><h3 class="title"> +<a name="java-programming-language"></a>17.4.2. Java</h3></div></div></div> +<p>If a program is written in Java, use the Java framework in + pkgsrc. The package must include + <code class="filename">../../mk/java-vm.mk</code>. This Makefile fragment + provides the following variables:</p> +<div class="itemizedlist"><ul type="disc"> +<li><p><code class="varname">USE_JAVA</code> defines if a build + dependency on the JDK is added. If + <code class="varname">USE_JAVA</code> is set to “<span class="quote">run</span>”, then + there is only a runtime dependency on the JDK. The default is + “<span class="quote">yes</span>”, which also adds a build dependency on the + JDK.</p></li> +<li><p>Set <code class="varname">USE_JAVA2</code> to declare that + a package needs a Java2 implementation. The supported values + are “<span class="quote">yes</span>”, “<span class="quote">1.4</span>”, and + “<span class="quote">1.5</span>”. “<span class="quote">yes</span>” accepts any Java2 + implementation, “<span class="quote">1.4</span>” insists on versions 1.4 or + above, and “<span class="quote">1.5</span>” only accepts versions 1.5 or + above. This variable is not set by default.</p></li> +</ul></div> +</div> +<div class="sect2" lang="en"> +<div class="titlepage"><div><div><h3 class="title"> +<a name="perl-scripts"></a>17.4.3. Packages containing perl scripts</h3></div></div></div> +<p>If your package contains interpreted perl scripts, add + “<span class="quote">perl</span>” to the <code class="varname">USE_TOOLS</code> variable + and set <code class="varname">REPLACE_PERL</code> to ensure that the proper + interpreter path is set. <code class="varname">REPLACE_PERL</code> should + contain a list of scripts, relative to <code class="varname">WRKSRC</code>, + that you want adjusted. Every occurrence of + <code class="filename">*/bin/perl</code> will be replaced with the full + path to the perl executable.</p> +<p>If a particular version of perl is needed, set the + <code class="varname">PERL5_REQD</code> variable to the version number. The + default is “<span class="quote">5.0</span>”.</p> +<p>See <a href="#perl-modules" title="17.6.5. Packages installing perl modules">Section 17.6.5, “Packages installing perl modules”</a> for information + about handling perl modules.</p> +</div> +<div class="sect2" lang="en"> +<div class="titlepage"><div><div><h3 class="title"> +<a name="other-programming-languages"></a>17.4.4. Other programming languages</h3></div></div></div> +<p>Currently, there is no special handling for other languages + in pkgsrc. If a compiler package provides a + <code class="filename">buildlink3.mk</code> file, include that, otherwise + just add a (build) dependency on the appropriate compiler + package.</p> </div> </div> <div class="sect1" lang="en"> <div class="titlepage"><div><div><h2 class="title" style="clear: both"> -<a name="fixes.build"></a>17.4. Fixing problems in the <span class="emphasis"><em>build</em></span> phase</h2></div></div></div> +<a name="fixes.build"></a>17.5. Fixing problems in the <span class="emphasis"><em>build</em></span> phase</h2></div></div></div> <p>The most common failures when building a package are that some platforms do not provide certain header files, functions or libraries, or they provide the functions in a library that the @@ -7543,7 +7605,7 @@ Changes to the PLIST use the missing functions or provides a replacement function.</p> <div class="sect2" lang="en"> <div class="titlepage"><div><div><h3 class="title"> -<a name="fixes.build.cpp"></a>17.4.1. Compiling C and C++ code conditionally</h3></div></div></div> +<a name="fixes.build.cpp"></a>17.5.1. Compiling C and C++ code conditionally</h3></div></div></div> <p>If a package already comes with a GNU configure script, the preferred way to fix the build failure is to change the configure script, not the code. In the other cases, you can @@ -7563,7 +7625,7 @@ Changes to the PLIST does not define it. Use <code class="varname">__sun</code> instead.</p> <div class="sect3" lang="en"> <div class="titlepage"><div><div><h4 class="title"> -<a name="fixes.build.cpp.os"></a>17.4.1.1. C preprocessor macros to identify the operating system</h4></div></div></div> +<a name="fixes.build.cpp.os"></a>17.5.1.1. C preprocessor macros to identify the operating system</h4></div></div></div> <p>To distinguish between 4.4 BSD-derived systems and the rest of the world, you should use the following code.</p> <pre class="programlisting"> @@ -7588,7 +7650,7 @@ Changes to the PLIST </div> <div class="sect3" lang="en"> <div class="titlepage"><div><div><h4 class="title"> -<a name="fixes.build.cpp.arch"></a>17.4.1.2. C preprocessor macros to identify the hardware architecture</h4></div></div></div> +<a name="fixes.build.cpp.arch"></a>17.5.1.2. C preprocessor macros to identify the hardware architecture</h4></div></div></div> <pre class="programlisting"> i386 i386, __i386, __i386__ MIPS __mips @@ -7597,7 +7659,7 @@ Changes to the PLIST </div> <div class="sect3" lang="en"> <div class="titlepage"><div><div><h4 class="title"> -<a name="fixes.build.cpp.compiler"></a>17.4.1.3. C preprocessor macros to identify the compiler</h4></div></div></div> +<a name="fixes.build.cpp.compiler"></a>17.5.1.3. C preprocessor macros to identify the compiler</h4></div></div></div> <pre class="programlisting"> GCC __GNUC__ (major version), __GNUC_MINOR__ SunPro __SUNPRO_C (0x570 for version 5.7) @@ -7607,22 +7669,22 @@ Changes to the PLIST </div> <div class="sect2" lang="en"> <div class="titlepage"><div><div><h3 class="title"> -<a name="compiler-bugs"></a>17.4.2. How to handle compiler bugs</h3></div></div></div> +<a name="compiler-bugs"></a>17.5.2. How to handle compiler bugs</h3></div></div></div> <p>Some source files trigger bugs in the compiler, based on - combinations of compiler version and architecture and almost - always relation to optimisation being enabled. Common symptoms - are gcc internal errors or never finishing compiling a + combinations of compiler version and architecture and almost + always relation to optimisation being enabled. Common symptoms + are gcc internal errors or never finishing compiling a file.</p> <p>Typically, a workaround involves testing the <code class="varname">MACHINE_ARCH</code> and compiler version, disabling optimisation for that combination of file, <code class="varname">MACHINE_ARCH</code> and compiler, and documenting it - in <code class="filename">pkgsrc/doc/HACKS</code>. See that file for a + in <code class="filename">pkgsrc/doc/HACKS</code>. See that file for a number of examples.</p> </div> <div class="sect2" lang="en"> <div class="titlepage"><div><div><h3 class="title"> -<a name="undefined-reference"></a>17.4.3. Undefined reference to “<span class="quote">...</span>”</h3></div></div></div> +<a name="undefined-reference"></a>17.5.3. Undefined reference to “<span class="quote">...</span>”</h3></div></div></div> <p>This compiler error often means that a package did not link to a shared library it needs. The following functions are known to cause this error message over and over.</p> @@ -7678,485 +7740,477 @@ Changes to the PLIST </table> </div> <p>To fix these linker errors, it is often sufficient to say - <code class="literal">LIBS.<em class="replaceable"><code>OperatingSystem</code></em>+= - -l<em class="replaceable"><code>foo</code></em></code> to the package - <code class="filename">Makefile</code> and then say <span><strong class="command">bmake clean; - bmake</strong></span>.</p> + <code class="literal">LIBS.<em class="replaceable"><code>OperatingSystem</code></em>+= + -l<em class="replaceable"><code>foo</code></em></code> to the package + <code class="filename">Makefile</code> and then say <span><strong class="command">bmake clean; + bmake</strong></span>.</p> +</div> +<div class="sect2" lang="en"> +<div class="titlepage"><div><div><h3 class="title"> +<a name="out-of-memory"></a>17.5.4. Running out of memory</h3></div></div></div> +<p>Sometimes packages fail to build because the compiler runs + into an operating system specific soft limit. With the + <code class="varname">UNLIMIT_RESOURCES</code> variable pkgsrc can be told + to unlimit the resources. Currently, the allowed values are + “<span class="quote">datasize</span>” and “<span class="quote">stacksize</span>” (or both). + Setting this variable is similar to running the shell builtin + <span><strong class="command">ulimit</strong></span> command to raise the maximum data + segment size or maximum stack size of a process, respectively, to + their hard limits.</p> </div> </div> <div class="sect1" lang="en"> <div class="titlepage"><div><div><h2 class="title" style="clear: both"> -<a name="fixes.install"></a>17.5. Fixing problems in the <span class="emphasis"><em>install</em></span> phase</h2></div></div></div> +<a name="fixes.install"></a>17.6. Fixing problems in the <span class="emphasis"><em>install</em></span> phase</h2></div></div></div> <div class="sect2" lang="en"> <div class="titlepage"><div><div><h3 class="title"> -<a name="install-scripts"></a>17.5.1. Creating needed directories</h3></div></div></div> +<a name="install-scripts"></a>17.6.1. Creating needed directories</h3></div></div></div> <p>The BSD-compatible <span><strong class="command">install</strong></span> supplied - with some operating systems cannot create more than one - directory at a time. As such, you should call - <code class="literal">${INSTALL_*_DIR}</code> like this:</p> + with some operating systems cannot create more than one + directory at a time. As such, you should call + <code class="literal">${INSTALL_*_DIR}</code> like this:</p> <pre class="programlisting"> - ${INSTALL_DATA_DIR} ${PREFIX}/dir1 - ${INSTALL_DATA_DIR} ${PREFIX}/dir2 -</pre> + ${INSTALL_DATA_DIR} ${PREFIX}/dir1 + ${INSTALL_DATA_DIR} ${PREFIX}/dir2 + </pre> <p>You can also just append “<span class="quote"><code class="literal">dir1 - dir2</code></span>” to the - <code class="varname">INSTALLATION_DIRS</code> variable, which will - automatically do the right thing.</p> + dir2</code></span>” to the + <code class="varname">INSTALLATION_DIRS</code> variable, which will + automatically do the right thing.</p> </div> <div class="sect2" lang="en"> <div class="titlepage"><div><div><h3 class="title"> -<a name="where-to-install-documentation"></a>17.5.2. Where to install documentation</h3></div></div></div> +<a name="where-to-install-documentation"></a>17.6.2. Where to install documentation</h3></div></div></div> <p>In general, documentation should be installed into - <code class="filename">${PREFIX}/share/doc/${PKGBASE}</code> or - <code class="filename">${PREFIX}/share/doc/${PKGNAME}</code> (the - latter includes the version number of the package).</p> + <code class="filename">${PREFIX}/share/doc/${PKGBASE}</code> or + <code class="filename">${PREFIX}/share/doc/${PKGNAME}</code> (the latter + includes the version number of the package).</p> <p>Many modern packages using GNU autoconf allow to set the - directory where HTML documentation is installed with the - “<span class="quote">--with-html-dir</span>” option. Sometimes using this - flag is needed because otherwise the documentation ends up in - <code class="filename">${PREFIX}/share/doc/html</code> or other - places.</p> -<p>An exception to the above is that library API - documentation generated with the <a href="ftp://ftp.NetBSD.org/pub/NetBSD/packages/pkgsrc/textproc/gtk-doc/README.html" target="_top"><code class="filename">textproc/gtk-doc</code></a> tools, for use by - special browsers (devhelp) should be left at their default - location, which is - <code class="filename">${PREFIX}/share/gtk-doc</code>. Such - documentation can be recognized from files ending in - <code class="filename">.devhelp</code> or - <code class="filename">.devhelp2</code>. (It is also acceptable to - install such files in - <code class="filename">${PREFIX}/share/doc/${PKGBASE}</code> or - <code class="filename">${PREFIX}/share/doc/${PKGNAME}</code>; the - <code class="filename">.devhelp*</code> file must be directly in that - directory then, no additional - subdirectory level is allowed in this case. This is usually - achieved by using - “<span class="quote">--with-html-dir=${PREFIX}/share/doc</span>”. - <code class="filename">${PREFIX}/share/gtk-doc</code> is preferred - though.)</p> + directory where HTML documentation is installed with the + “<span class="quote">--with-html-dir</span>” option. Sometimes using this flag + is needed because otherwise the documentation ends up in + <code class="filename">${PREFIX}/share/doc/html</code> or other + places.</p> +<p>An exception to the above is that library API documentation + generated with the <a href="ftp://ftp.NetBSD.org/pub/NetBSD/packages/pkgsrc/textproc/gtk-doc/README.html" target="_top"><code class="filename">textproc/gtk-doc</code></a> tools, for use by special + browsers (devhelp) should be left at their default location, which + is <code class="filename">${PREFIX}/share/gtk-doc</code>. Such + documentation can be recognized from files ending in + <code class="filename">.devhelp</code> or <code class="filename">.devhelp2</code>. + (It is also acceptable to install such files in + <code class="filename">${PREFIX}/share/doc/${PKGBASE}</code> or + <code class="filename">${PREFIX}/share/doc/${PKGNAME}</code>; the + <code class="filename">.devhelp*</code> file must be directly in that + directory then, no additional subdirectory level is allowed in + this case. This is usually achieved by using + “<span class="quote">--with-html-dir=${PREFIX}/share/doc</span>”. + <code class="filename">${PREFIX}/share/gtk-doc</code> is preferred + though.)</p> </div> <div class="sect2" lang="en"> <div class="titlepage"><div><div><h3 class="title"> -<a name="installing-score-files"></a>17.5.3. Installing score files</h3></div></div></div> +<a name="installing-score-files"></a>17.6.3. Installing score files</h3></div></div></div> <p>Certain packages, most of them in the games category, install - a score file that allows all users on the system to record their - highscores. In order for this to work, the binaries need to be - installed setgid and the score files owned by the appropriate - group and/or owner (traditionally the "games" user/group). The - following variables, documented in more detail in - <code class="filename">mk/defaults/mk.conf</code>, control this - behaviour: <code class="varname">SETGIDGAME</code>, - <code class="varname">GAMEDATAMODE</code>, <code class="varname">GAMEGRP</code>, - <code class="varname">GAMEMODE</code>, <code class="varname">GAMEOWN</code>.</p> + a score file that allows all users on the system to record their + highscores. In order for this to work, the binaries need to be + installed setgid and the score files owned by the appropriate + group and/or owner (traditionally the "games" user/group). The + following variables, documented in more detail in + <code class="filename">mk/defaults/mk.conf</code>, control this + behaviour: <code class="varname">SETGIDGAME</code>, + <code class="varname">GAMEDATAMODE</code>, <code class="varname">GAMEGRP</code>, + <code class="varname">GAMEMODE</code>, <code class="varname">GAMEOWN</code>.</p> <p>Note that per default, setgid installation of games is - disabled; setting <code class="varname">SETGIDGAME=YES</code> will set all - the other variables accordingly.</p> + disabled; setting <code class="varname">SETGIDGAME=YES</code> will set all + the other variables accordingly.</p> <p>A package should therefor never hard code file ownership or - access permissions but rely on <code class="varname">INSTALL_GAME</code> and - <code class="varname">INSTALL_GAME_DATA</code> to set these - correctly.</p> + access permissions but rely on <code class="varname">INSTALL_GAME</code> and + <code class="varname">INSTALL_GAME_DATA</code> to set these + correctly.</p> </div> <div class="sect2" lang="en"> <div class="titlepage"><div><div><h3 class="title"> -<a name="perl-scripts"></a>17.5.4. Packages containing perl scripts</h3></div></div></div> -<p> - If your package contains interpreted perl scripts, set - <code class="varname">REPLACE_PERL</code> to ensure that the proper - interpreter path is set. <code class="varname">REPLACE_PERL</code> should - contain a list of scripts, relative to - <code class="varname">WRKSRC</code>, that you want adjusted.</p> -</div> -<div class="sect2" lang="en"> -<div class="titlepage"><div><div><h3 class="title"> -<a name="hardcoded-paths"></a>17.5.5. Packages with hardcoded paths to other interpreters</h3></div></div></div> -<p> - Your package may also contain scripts with hardcoded paths to - other interpreters besides (or as well as) perl. To correct the - full pathname to the script interpreter, you need to set the - following definitions in your <code class="filename">Makefile</code> (we - shall use <span><strong class="command">tclsh</strong></span> in this example):</p> +<a name="hardcoded-paths"></a>17.6.4. Packages with hardcoded paths to other interpreters</h3></div></div></div> +<p>Your package may also contain scripts with hardcoded paths to + other interpreters besides (or as well as) perl. To correct the + full pathname to the script interpreter, you need to set the + following definitions in your <code class="filename">Makefile</code> (we + shall use <span><strong class="command">tclsh</strong></span> in this example):</p> <pre class="programlisting"> - REPLACE_INTERPRETER+= tcl - REPLACE.tcl.old= .*/bin/tclsh - REPLACE.tcl.new= ${PREFIX}/bin/tclsh - REPLACE_FILES.tcl= # list of tcl scripts which need to be fixed, - # relative to ${WRKSRC}, just as in REPLACE_PERL -</pre> + REPLACE_INTERPRETER+= tcl + REPLACE.tcl.old= .*/bin/tclsh + REPLACE.tcl.new= ${PREFIX}/bin/tclsh + REPLACE_FILES.tcl= # list of tcl scripts which need to be fixed, + # relative to ${WRKSRC}, just as in REPLACE_PERL + </pre> <div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"> <h3 class="title">Note</h3> <p>Before March 2006, these variables were called - <code class="varname">_REPLACE.*</code> and - <code class="varname">_REPLACE_FILES.*</code>.</p> + <code class="varname">_REPLACE.*</code> and + <code class="varname">_REPLACE_FILES.*</code>.</p> </div> </div> <div class="sect2" lang="en"> <div class="titlepage"><div><div><h3 class="title"> -<a name="perl-modules"></a>17.5.6. Packages installing perl modules</h3></div></div></div> +<a name="perl-modules"></a>17.6.5. Packages installing perl modules</h3></div></div></div> <p>Makefiles of packages providing perl5 modules should include - the Makefile fragment - <code class="filename">../../lang/perl5/module.mk</code>. It provides a - <span><strong class="command">do-configure</strong></span> target for the standard perl - configuration for such modules as well as various hooks to tune - this configuration. See comments in this file for - details.</p> + the Makefile fragment + <code class="filename">../../lang/perl5/module.mk</code>. It provides a + <span><strong class="command">do-configure</strong></span> target for the standard perl + configuration for such modules as well as various hooks to tune + this configuration. See comments in this file for + details.</p> <p>Perl5 modules will install into different places depending - on the version of perl used during the build process. To - address this, pkgsrc will append lines to the - <code class="filename">PLIST</code> corresponding to the files listed in - the installed <code class="filename">.packlist</code> file generated by - most perl5 modules. This is invoked by defining - <code class="varname">PERL5_PACKLIST</code> to a space-separated list of - paths to packlist files, e.g.:</p> + on the version of perl used during the build process. To + address this, pkgsrc will append lines to the + <code class="filename">PLIST</code> corresponding to the files listed in + the installed <code class="filename">.packlist</code> file generated by + most perl5 modules. This is invoked by defining + <code class="varname">PERL5_PACKLIST</code> to a space-separated list of + paths to packlist files, e.g.:</p> <pre class="programlisting"> - PERL5_PACKLIST= ${PERL5_SITEARCH}/auto/Pg/.packlist -</pre> + PERL5_PACKLIST= ${PERL5_SITEARCH}/auto/Pg/.packlist + </pre> <p>The variables <code class="varname">PERL5_SITELIB</code>, - <code class="varname">PERL5_SITEARCH</code>, and - <code class="varname">PERL5_ARCHLIB</code> represent the three locations - in which perl5 modules may be installed, and may be used by - perl5 packages that don't have a packlist. These three - variables are also substituted for in the - <code class="filename">PLIST</code>.</p> + <code class="varname">PERL5_SITEARCH</code>, and + <code class="varname">PERL5_ARCHLIB</code> represent the three locations + in which perl5 modules may be installed, and may be used by + perl5 packages that don't have a packlist. These three + variables are also substituted for in the + <code class="filename">PLIST</code>.</p> </div> <div class="sect2" lang="en"> <div class="titlepage"><div><div><h3 class="title"> -<a name="faq.info-files"></a>17.5.7. Packages installing info files</h3></div></div></div> +<a name="faq.info-files"></a>17.6.6. Packages installing info files</h3></div></div></div> <p>Some packages install info files or use the - “<span class="quote">makeinfo</span>” or “<span class="quote">install-info</span>” - commands. <code class="varname">INFO_FILES</code> should be defined in - the package Makefile so that <code class="filename">INSTALL</code> and - <code class="filename">DEINSTALL</code> scripts will be generated to - handle registration of the info files in the Info directory - file. The “<span class="quote">install-info</span>” command used for the info - files registration is either provided by the system, or by a - special purpose package automatically added as dependency if - needed.</p> + “<span class="quote">makeinfo</span>” or “<span class="quote">install-info</span>” + commands. <code class="varname">INFO_FILES</code> should be defined in + the package Makefile so that <code class="filename">INSTALL</code> and + <code class="filename">DEINSTALL</code> scripts will be generated to + handle registration of the info files in the Info directory + file. The “<span class="quote">install-info</span>” command used for the info + files registration is either provided by the system, or by a + special purpose package automatically added as dependency if + needed.</p> <p><code class="varname">PKGINFODIR</code> is the directory under - <code class="filename">${PREFIX}</code> where info files are primarily - located. <code class="varname">PKGINFODIR</code> defaults to - “<span class="quote">info</span>” and can be overridden by the user.</p> + <code class="filename">${PREFIX}</code> where info files are primarily + located. <code class="varname">PKGINFODIR</code> defaults to + “<span class="quote">info</span>” and can be overridden by the user.</p> <p>The info files for the package should be listed in the - package <code class="filename">PLIST</code>; however any split info files - need not be listed.</p> + package <code class="filename">PLIST</code>; however any split info files + need not be listed.</p> <p>A package which needs the “<span class="quote">makeinfo</span>” command - at build time must add “<span class="quote">makeinfo</span>” to - <code class="varname">USE_TOOLS</code> in its Makefile. If a minimum - version of the “<span class="quote">makeinfo</span>” command is needed it - should be noted with the <code class="varname">TEXINFO_REQD</code> - variable in the package <code class="filename">Makefile</code>. By - default, a minimum version of 3.12 is required. If the system - does not provide a <span><strong class="command">makeinfo</strong></span> command or if it - does not match the required minimum, a build dependency on the - <a href="ftp://ftp.NetBSD.org/pub/NetBSD/packages/pkgsrc/devel/gtexinfo/README.html" target="_top"><code class="filename">devel/gtexinfo</code></a> package will - be added automatically.</p> + at build time must add “<span class="quote">makeinfo</span>” to + <code class="varname">USE_TOOLS</code> in its Makefile. If a minimum + version of the “<span class="quote">makeinfo</span>” command is needed it + should be noted with the <code class="varname">TEXINFO_REQD</code> + variable in the package <code class="filename">Makefile</code>. By + default, a minimum version of 3.12 is required. If the system + does not provide a <span><strong class="command">makeinfo</strong></span> command or if it + does not match the required minimum, a build dependency on the + <a href="ftp://ftp.NetBSD.org/pub/NetBSD/packages/pkgsrc/devel/gtexinfo/README.html" target="_top"><code class="filename">devel/gtexinfo</code></a> package will + be added automatically.</p> <p>The build and installation process of the software provided - by the package should not use the - <span><strong class="command">install-info</strong></span> command as the registration of - info files is the task of the package - <code class="filename">INSTALL</code> script, and it must use the - appropriate <span><strong class="command">makeinfo</strong></span> command.</p> + by the package should not use the + <span><strong class="command">install-info</strong></span> command as the registration of + info files is the task of the package + <code class="filename">INSTALL</code> script, and it must use the + appropriate <span><strong class="command">makeinfo</strong></span> command.</p> <p>To achieve this goal, the pkgsrc infrastructure creates - overriding scripts for the <span><strong class="command">install-info</strong></span> and - <span><strong class="command">makeinfo</strong></span> commands in a directory listed early - in <code class="varname">PATH</code>.</p> + overriding scripts for the <span><strong class="command">install-info</strong></span> and + <span><strong class="command">makeinfo</strong></span> commands in a directory listed early + in <code class="varname">PATH</code>.</p> <p>The script overriding <span><strong class="command">install-info</strong></span> has - no effect except the logging of a message. The script overriding - <span><strong class="command">makeinfo</strong></span> logs a message and according to the - value of <code class="varname">TEXINFO_REQD</code> either runs the appropriate - <span><strong class="command">makeinfo</strong></span> command or exit on error.</p> + no effect except the logging of a message. The script overriding + <span><strong class="command">makeinfo</strong></span> logs a message and according to the + value of <code class="varname">TEXINFO_REQD</code> either runs the appropriate + <span><strong class="command">makeinfo</strong></span> command or exit on error.</p> </div> <div class="sect2" lang="en"> <div class="titlepage"><div><div><h3 class="title"> -<a name="manpages"></a>17.5.8. Packages installing man pages</h3></div></div></div> +<a name="manpages"></a>17.6.7. Packages installing man pages</h3></div></div></div> <p>All packages that install manual pages should install them - into the same directory, so that there is one common place to - look for them. In pkgsrc, this place is - <code class="literal">${PREFIX}/${PKGMANDIR}</code>, and this expression - should be used in packages. The default for - <code class="varname">PKGMANDIR</code> is - “<span class="quote"><code class="filename">man</code></span>”. Another often-used - value is “<span class="quote"><code class="filename">share/man</code></span>”.</p> + into the same directory, so that there is one common place to look + for them. In pkgsrc, this place is + <code class="literal">${PREFIX}/${PKGMANDIR}</code>, and this expression + should be used in packages. The default for + <code class="varname">PKGMANDIR</code> is + “<span class="quote"><code class="filename">man</code></span>”. Another often-used value + is “<span class="quote"><code class="filename">share/man</code></span>”.</p> <div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"> <h3 class="title">Note</h3> -<p>The support for a custom - <code class="varname">PKGMANDIR</code> is far from complete.</p> +<p>The support for a custom <code class="varname">PKGMANDIR</code> + is far from complete.</p> </div> <p>The <code class="filename">PLIST</code> files can just use - <code class="filename">man/</code> as the top level directory for the man - page file entries, and the pkgsrc framework will convert as - needed. In all other places, the correct - <code class="varname">PKGMANDIR</code> must be used.</p> -<p> Packages that are - configured with <code class="varname">GNU_CONFIGURE</code> set as - “<span class="quote">yes</span>”, by default will use the - <code class="filename">./configure</code> - --mandir switch to set where the man pages should be installed. - The path is <code class="varname">GNU_CONFIGURE_MANDIR</code> which defaults - to <code class="varname">${PREFIX}/${PKGMANDIR}</code>. - </p> -<p> - Packages that use <code class="varname">GNU_CONFIGURE</code> but do not - use --mandir, can set <code class="varname">CONFIGURE_HAS_MANDIR</code> - to “<span class="quote">no</span>”. - Or if the <code class="filename">./configure</code> script uses - a non-standard use of --mandir, you can set - <code class="varname">GNU_CONFIGURE_MANDIR</code> as needed. - </p> + <code class="filename">man/</code> as the top level directory for the man + page file entries, and the pkgsrc framework will convert as + needed. In all other places, the correct + <code class="varname">PKGMANDIR</code> must be used.</p> +<p>Packages that are + configured with <code class="varname">GNU_CONFIGURE</code> set as + “<span class="quote">yes</span>”, by default will use the + <code class="filename">./configure</code> + --mandir switch to set where the man pages should be installed. + The path is <code class="varname">GNU_CONFIGURE_MANDIR</code> which defaults + to <code class="varname">${PREFIX}/${PKGMANDIR}</code>.</p> +<p>Packages that use <code class="varname">GNU_CONFIGURE</code> but do not + use --mandir, can set <code class="varname">CONFIGURE_HAS_MANDIR</code> + to “<span class="quote">no</span>”. + Or if the <code class="filename">./configure</code> script uses + a non-standard use of --mandir, you can set + <code class="varname">GNU_CONFIGURE_MANDIR</code> as needed.</p> <p>See <a href="#manpage-compression" title="11.5. Man page compression">Section 11.5, “Man page compression”</a> for - information on installation of compressed manual pages. - </p> + information on installation of compressed manual pages.</p> </div> <div class="sect2" lang="en"> <div class="titlepage"><div><div><h3 class="title"> -<a name="gconf2-data-files"></a>17.5.9. Packages installing GConf2 data files</h3></div></div></div> -<p> - If a package installs <code class="filename">.schemas</code> or - <code class="filename">.entries</code> files, used by GConf2, - you need to take some extra steps to make sure they get registered - in the database: -</p> +<a name="gconf2-data-files"></a>17.6.8. Packages installing GConf2 data files</h3></div></div></div> +<p>If a package installs <code class="filename">.schemas</code> or + <code class="filename">.entries</code> files, used by GConf2, + you need to take some extra steps to make sure they get registered + in the database:</p> <div class="orderedlist"><ol type="1"> <li><p>Include <code class="filename">../../devel/GConf2/schemas.mk</code> - instead of its <code class="filename">buildlink3.mk</code> file. This - takes care of rebuilding the GConf2 database at installation and - deinstallation time, and tells the package where to install - GConf2 data files using some standard configure arguments. It - also disallows any access to the database directly from the - package.</p></li> + instead of its <code class="filename">buildlink3.mk</code> file. This + takes care of rebuilding the GConf2 database at installation and + deinstallation time, and tells the package where to install + GConf2 data files using some standard configure arguments. It + also disallows any access to the database directly from the + package.</p></li> <li><p>Ensure that the package installs its - <code class="filename">.schemas</code> files under - <code class="filename">${PREFIX}/share/gconf/schemas</code>. If they get - installed under <code class="filename">${PREFIX}/etc</code>, you will - need to manually patch the package.</p></li> + <code class="filename">.schemas</code> files under + <code class="filename">${PREFIX}/share/gconf/schemas</code>. If they get + installed under <code class="filename">${PREFIX}/etc</code>, you will + need to manually patch the package.</p></li> <li><p>Check the PLIST and remove any entries under the etc/gconf - directory, as they will be handled automatically. See - <a href="#faq.conf" title="7.14. How do I change the location of configuration files?">Section 7.14, “How do I change the location of configuration files?”</a> for more information.</p></li> + directory, as they will be handled automatically. See + <a href="#faq.conf" title="7.14. How do I change the location of configuration files?">Section 7.14, “How do I change the location of configuration files?”</a> for more information.</p></li> <li><p>Define the <code class="varname">GCONF2_SCHEMAS</code> variable in - your <code class="filename">Makefile</code> with a list of all - <code class="filename">.schemas</code> files installed by the package, if - any. Names must not contain any directories in them.</p></li> + your <code class="filename">Makefile</code> with a list of all + <code class="filename">.schemas</code> files installed by the package, if + any. Names must not contain any directories in them.</p></li> <li><p>Define the <code class="varname">GCONF2_ENTRIES</code> variable in - your <code class="filename">Makefile</code> with a - list of all <code class="filename">.entries</code> files installed by the - package, if any. Names must not contain any directories in - them.</p></li> + your <code class="filename">Makefile</code> with a + list of all <code class="filename">.entries</code> files installed by the + package, if any. Names must not contain any directories in + them.</p></li> </ol></div> </div> <div class="sect2" lang="en"> <div class="titlepage"><div><div><h3 class="title"> -<a name="scrollkeeper-data-files"></a>17.5.10. Packages installing scrollkeeper data files</h3></div></div></div> -<p> - If a package installs <code class="filename">.omf</code> files, used by - scrollkeeper, you need to take some extra steps to make sure they - get registered in the database: -</p> +<a name="scrollkeeper-data-files"></a>17.6.9. Packages installing scrollkeeper data files</h3></div></div></div> +<p>If a package installs <code class="filename">.omf</code> files, used by + scrollkeeper, you need to take some extra steps to make sure they + get registered in the database:</p> <div class="orderedlist"><ol type="1"> <li><p>Include - <code class="filename">../../textproc/scrollkeeper/omf.mk</code> - instead of its <code class="filename">buildlink3.mk</code> file. This - takes care of rebuilding the scrollkeeper database at - installation and deinstallation time, and disallows any access - to it directly from the package. -</p></li> + <code class="filename">../../textproc/scrollkeeper/omf.mk</code> + instead of its <code class="filename">buildlink3.mk</code> file. This + takes care of rebuilding the scrollkeeper database at + installation and deinstallation time, and disallows any access + to it directly from the package.</p></li> <li><p>Check the PLIST and remove any entries under the - <code class="filename">libdata/scrollkeeper</code> directory, as they - will be handled automatically.</p></li> + <code class="filename">libdata/scrollkeeper</code> directory, as they + will be handled automatically.</p></li> <li><p>Remove the <code class="filename">share/omf</code> directory from - the PLIST. It will be handled by scrollkeeper.</p></li> + the PLIST. It will be handled by scrollkeeper.</p></li> </ol></div> </div> <div class="sect2" lang="en"> <div class="titlepage"><div><div><h3 class="title"> -<a name="x11-fonts"></a>17.5.11. Packages installing X11 fonts</h3></div></div></div> +<a name="x11-fonts"></a>17.6.10. Packages installing X11 fonts</h3></div></div></div> <p>If a package installs font files, you will need to rebuild - the fonts database in the directory where they get installed at - installation and deinstallation time. This can be automatically - done by using the pkginstall framework.</p> + the fonts database in the directory where they get installed at + installation and deinstallation time. This can be automatically + done by using the pkginstall framework.</p> <p>You can list the directories where fonts are installed in the - <code class="varname">FONTS_DIRS.<em class="replaceable"><code>type</code></em></code> - variables, where <em class="replaceable"><code>type</code></em> can be one of - “<span class="quote">ttf</span>”, “<span class="quote">type1</span>” or “<span class="quote">x11</span>”. - Also make sure that the database file - <code class="filename">fonts.dir</code> is not listed in the PLIST.</p> + <code class="varname">FONTS_DIRS.<em class="replaceable"><code>type</code></em></code> + variables, where <em class="replaceable"><code>type</code></em> can be one of + “<span class="quote">ttf</span>”, “<span class="quote">type1</span>” or “<span class="quote">x11</span>”. + Also make sure that the database file + <code class="filename">fonts.dir</code> is not listed in the PLIST.</p> <p>Note that you should not create new directories for fonts; - instead use the standard ones to avoid that the user needs to - manually configure his X server to find them.</p> + instead use the standard ones to avoid that the user needs to + manually configure his X server to find them.</p> </div> <div class="sect2" lang="en"> <div class="titlepage"><div><div><h3 class="title"> -<a name="gtk2-modules"></a>17.5.12. Packages installing GTK2 modules</h3></div></div></div> +<a name="gtk2-modules"></a>17.6.11. Packages installing GTK2 modules</h3></div></div></div> <p>If a package installs GTK2 immodules or loaders, you need to - take some extra steps to get them registered in the GTK2 database - properly:</p> + take some extra steps to get them registered in the GTK2 database + properly:</p> <div class="orderedlist"><ol type="1"> <li><p>Include - <code class="filename">../../x11/gtk2/modules.mk</code> instead of its - <code class="filename">buildlink3.mk</code> file. This takes care of - rebuilding the database at installation and deinstallation time. -</p></li> -<li><p> - Set <code class="varname">GTK2_IMMODULES=YES</code> if - your package installs GTK2 immodules.</p></li> -<li><p> - Set <code class="varname">GTK2_LOADERS=YES</code> if your package installs - GTK2 loaders.</p></li> + <code class="filename">../../x11/gtk2/modules.mk</code> instead of its + <code class="filename">buildlink3.mk</code> file. This takes care of + rebuilding the database at installation and deinstallation time.</p></li> +<li><p>Set <code class="varname">GTK2_IMMODULES=YES</code> if + your package installs GTK2 immodules.</p></li> +<li><p>Set <code class="varname">GTK2_LOADERS=YES</code> if your package installs + GTK2 loaders.</p></li> <li> -<p> - Patch the package to not touch any of the GTK2 databases directly. - These are: - - </p> +<p>Patch the package to not touch any of the GTK2 + databases directly. These are:</p> <div class="itemizedlist"><ul type="disc"> <li><p><code class="filename">libdata/gtk-2.0/gdk-pixbuf.loaders</code></p></li> <li><p><code class="filename">libdata/gtk-2.0/gtk.immodules</code></p></li> </ul></div> -<p> -</p> </li> -<li><p> - Check the PLIST and remove any entries under the - <code class="filename">libdata/gtk-2.0</code> directory, as they will be - handled automatically.</p></li> +<li><p>Check the <code class="filename">PLIST</code> and remove + any entries under the <code class="filename">libdata/gtk-2.0</code> + directory, as they will be handled automatically.</p></li> </ol></div> </div> <div class="sect2" lang="en"> <div class="titlepage"><div><div><h3 class="title"> -<a name="sgml-xml-data"></a>17.5.13. Packages installing SGML or XML data</h3></div></div></div> +<a name="sgml-xml-data"></a>17.6.12. Packages installing SGML or XML data</h3></div></div></div> <p>If a package installs SGML or XML data files that need to be - registered in system-wide catalogs (like DTDs, sub-catalogs, - etc.), you need to take some extra steps: -</p> + registered in system-wide catalogs (like DTDs, sub-catalogs, + etc.), you need to take some extra steps:</p> <div class="orderedlist"><ol type="1"> <li><p>Include - <code class="filename">../../textproc/xmlcatmgr/catalogs.mk</code> in - your <code class="filename">Makefile</code>, which takes care of - registering those files in system-wide catalogs at - installation and deinstallation time.</p></li> + <code class="filename">../../textproc/xmlcatmgr/catalogs.mk</code> in + your <code class="filename">Makefile</code>, which takes care of + registering those files in system-wide catalogs at + installation and deinstallation time.</p></li> <li><p>Set <code class="varname">SGML_CATALOGS</code> to the full path of - any SGML catalogs installed by the package.</p></li> + any SGML catalogs installed by the package.</p></li> <li><p>Set <code class="varname">XML_CATALOGS</code> to the full path of - any XML catalogs installed by the package.</p></li> + any XML catalogs installed by the package.</p></li> <li><p>Set <code class="varname">SGML_ENTRIES</code> to individual entries - to be added to the SGML catalog. These come in groups of - three strings; see xmlcatmgr(1) for more information - (specifically, arguments recognized by the 'add' action). - Note that you will normally not use this variable.</p></li> + to be added to the SGML catalog. These come in groups of + three strings; see xmlcatmgr(1) for more information + (specifically, arguments recognized by the 'add' action). + Note that you will normally not use this variable.</p></li> <li><p>Set <code class="varname">XML_ENTRIES</code> to individual entries - to be added to the XML catalog. These come in groups of three - strings; see xmlcatmgr(1) for more information (specifically, - arguments recognized by the 'add' action). Note that you will - normally not use this variable. -</p></li> + to be added to the XML catalog. These come in groups of three + strings; see xmlcatmgr(1) for more information (specifically, + arguments recognized by the 'add' action). Note that you will + normally not use this variable.</p></li> </ol></div> </div> <div class="sect2" lang="en"> <div class="titlepage"><div><div><h3 class="title"> -<a name="mime-database"></a>17.5.14. Packages installing extensions to the MIME database</h3></div></div></div> +<a name="mime-database"></a>17.6.13. Packages installing extensions to the MIME database</h3></div></div></div> <p>If a package provides extensions to the MIME database by - installing <code class="filename">.xml</code> files inside - <code class="filename">${PREFIX}/share/mime/packages</code>, you - need to take some extra steps to ensure that the database is kept - consistent with respect to these new files: -</p> + installing <code class="filename">.xml</code> files inside + <code class="filename">${PREFIX}/share/mime/packages</code>, you + need to take some extra steps to ensure that the database is kept + consistent with respect to these new files:</p> <div class="orderedlist"><ol type="1"> <li><p>Include - <code class="filename">../../databases/shared-mime-info/mimedb.mk</code> - (avoid using the <code class="filename">buildlink3.mk</code> file from - this same directory, which is reserved for inclusion from - other <code class="filename">buildlink3.mk</code> files). It takes - care of rebuilding the MIME database at installation and - deinstallation time, and disallows any access to it directly - from the package.</p></li> + <code class="filename">../../databases/shared-mime-info/mimedb.mk</code> + (avoid using the <code class="filename">buildlink3.mk</code> file from + this same directory, which is reserved for inclusion from + other <code class="filename">buildlink3.mk</code> files). It takes + care of rebuilding the MIME database at installation and + deinstallation time, and disallows any access to it directly + from the package.</p></li> <li><p>Check the PLIST and remove any entries under the - <code class="filename">share/mime</code> directory, - <span class="emphasis"><em>except</em></span> for files saved under - <code class="filename">share/mime/packages</code>. The former are - handled automatically by - the update-mime-database program, but the latter are - package-dependent and must be removed by the package that - installed them in the first place.</p></li> + <code class="filename">share/mime</code> directory, + <span class="emphasis"><em>except</em></span> for files saved under + <code class="filename">share/mime/packages</code>. The former are + handled automatically by + the update-mime-database program, but the latter are + package-dependent and must be removed by the package that + installed them in the first place.</p></li> <li><p>Remove any <code class="filename">share/mime/*</code> directories - from the PLIST. They will be handled by the shared-mime-info - package.</p></li> + from the PLIST. They will be handled by the shared-mime-info + package.</p></li> </ol></div> </div> <div class="sect2" lang="en"> <div class="titlepage"><div><div><h3 class="title"> -<a name="intltool"></a>17.5.15. Packages using intltool</h3></div></div></div> +<a name="intltool"></a>17.6.14. Packages using intltool</h3></div></div></div> <p>If a package uses intltool during its build, include the - <code class="filename">../../textproc/intltool/buildlink3.mk</code> file, - which forces it to use the intltool package provided by pkgsrc, - instead of the one bundled with the distribution file. -</p> + <code class="filename">../../textproc/intltool/buildlink3.mk</code> file, + which forces it to use the intltool package provided by pkgsrc, + instead of the one bundled with the distribution file.</p> <p>This tracks intltool's build-time dependencies and uses the - latest available version; this way, the package benefits of any - bug fixes that may have appeared since it was released. -</p> + latest available version; this way, the package benefits of any + bug fixes that may have appeared since it was released.</p> </div> <div class="sect2" lang="en"> <div class="titlepage"><div><div><h3 class="title"> -<a name="startup-scripts"></a>17.5.16. Packages installing startup scripts</h3></div></div></div> +<a name="startup-scripts"></a>17.6.15. Packages installing startup scripts</h3></div></div></div> <p>If a package contains a rc.d script, it won't be copied into - the startup directory by default, but you can enable it, by adding - the option <code class="varname">PKG_RCD_SCRIPTS=YES</code> in - <code class="filename">/etc/mk.conf</code>. This option will copy the scripts - into <code class="filename">/etc/rc.d</code> when a package is installed, and - it will automatically remove the scripts when the package is - deinstalled.</p> + the startup directory by default, but you can enable it, by adding + the option <code class="varname">PKG_RCD_SCRIPTS=YES</code> in + <code class="filename">/etc/mk.conf</code>. This option will copy the scripts + into <code class="filename">/etc/rc.d</code> when a package is installed, and + it will automatically remove the scripts when the package is + deinstalled.</p> </div> <div class="sect2" lang="en"> <div class="titlepage"><div><div><h3 class="title"> -<a name="tex-packages"></a>17.5.17. Packages installing TeX modules</h3></div></div></div> +<a name="tex-packages"></a>17.6.16. Packages installing TeX modules</h3></div></div></div> <p>If a package installs TeX packages into the texmf tree, - the <code class="filename">ls-R</code> database of the tree needs to be - updated.</p> + the <code class="filename">ls-R</code> database of the tree needs to be + updated.</p> <div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"> <h3 class="title">Note</h3> <p>Except the main TeX packages such as teTeX-texmf, - packages should install files - into <code class="varname">PKG_LOCALTEXMFPREFIX</code>, - not <code class="varname">PKG_TEXMFPREFIX</code>.</p> + packages should install files + into <code class="varname">PKG_LOCALTEXMFPREFIX</code>, + not <code class="varname">PKG_TEXMFPREFIX</code>.</p> </div> <div class="orderedlist"><ol type="1"> <li><p>Include - <code class="filename">../../print/teTeX/module.mk</code> instead - of <code class="filename">../../mk/tex.buildlink3.mk</code>. This - takes care of rebuilding the <code class="filename">ls-R</code> - database at installation and deinstallation time.</p></li> + <code class="filename">../../print/teTeX/module.mk</code> instead + of <code class="filename">../../mk/tex.buildlink3.mk</code>. This + takes care of rebuilding the <code class="filename">ls-R</code> + database at installation and deinstallation time.</p></li> <li> <p>If your package installs files into a texmf - tree other than the one - at <code class="varname">PKG_LOCALTEXMFPREFIX</code>, - set <code class="varname">TEXMFDIRS</code> to the list of all texmf - trees that need database update.</p> + tree other than the one + at <code class="varname">PKG_LOCALTEXMFPREFIX</code>, + set <code class="varname">TEXMFDIRS</code> to the list of all texmf + trees that need database update.</p> <p>If your package also installs font map files that need - to be registered using <span><strong class="command">updmap</strong></span>, - set <code class="varname">TEX_FONTMAPS</code> to the list of all - such font map files. Then <span><strong class="command">updmap</strong></span> will - be run automatically at installation/deinstallation to - enable/disable font map files for TeX output - drivers.</p> + to be registered using <span><strong class="command">updmap</strong></span>, + set <code class="varname">TEX_FONTMAPS</code> to the list of all + such font map files. Then <span><strong class="command">updmap</strong></span> will + be run automatically at installation/deinstallation to + enable/disable font map files for TeX output + drivers.</p> </li> <li><p>Make sure that none of <code class="filename">ls-R</code> - databases are included in <code class="filename">PLIST</code>, as - they will be removed only by the teTeX-bin package.</p></li> + databases are included in <code class="filename">PLIST</code>, as + they will be removed only by the teTeX-bin package.</p></li> </ol></div> </div> <div class="sect2" lang="en"> <div class="titlepage"><div><div><h3 class="title"> -<a name="hicolor-theme"></a>17.5.18. Packages installing hicolor theme icons</h3></div></div></div> +<a name="emulation-packages"></a>17.6.17. Packages supporting running binaries in + emulation</h3></div></div></div> +<p>There are some packages that provide libraries and + executables for running binaries from a one operating system + on a different one (if the latter supports it). One example + is running Linux binaries on NetBSD.</p> +<p>The <a href="ftp://ftp.NetBSD.org/pub/NetBSD/packages/pkgsrc/pkgtools/rpm2pkg/README.html" target="_top"><code class="filename">pkgtools/rpm2pkg</code></a> + helps in extracting and packaging Linux rpm packages.</p> +<p>The <code class="varname">CHECK_SHLIBS</code> can be set to no to + avoid the <span><strong class="command">check-shlibs</strong></span> target, which tests + if all libraries for each installed executable can be found by + the dynamic linker. Since the standard dynamic linker is run, + this fails for emulation packages, because the libraries used + by the emulation are not in the standard directories.</p> +</div> +<div class="sect2" lang="en"> +<div class="titlepage"><div><div><h3 class="title"> +<a name="hicolor-theme"></a>17.6.18. Packages installing hicolor theme icons</h3></div></div></div> <p>If a package installs images under the - <code class="filename">share/icons/hicolor</code> and/or updates the - <code class="filename">share/icons/hicolor/icon-theme.cache</code> database, - you need to take some extra steps to make sure that the shared - theme directory is handled appropriately and that the cache - database is rebuilt:</p> + <code class="filename">share/icons/hicolor</code> and/or updates the + <code class="filename">share/icons/hicolor/icon-theme.cache</code> + database, you need to take some extra steps to make sure that the + shared theme directory is handled appropriately and that the cache + database is rebuilt:</p> <div class="orderedlist"><ol type="1"> <li><p>Include - <code class="filename">../../graphics/hicolor-icon-theme/buildlink3.mk</code> - instead of its <code class="filename">buildlink3.mk</code> file.</p></li> -<li><p>Check the PLIST and remove the entry that refers to the - theme cache.</p></li> + <code class="filename">../../graphics/hicolor-icon-theme/buildlink3.mk</code>.</p></li> +<li><p>Check the <code class="filename">PLIST</code> and remove the + entry that refers to the theme cache.</p></li> <li><p>Ensure that the PLIST does not remove the shared icon directories from the <code class="filename">share/icons/hicolor</code> hierarchy because they will be handled automatically.</p></li> @@ -8167,7 +8221,7 @@ Changes to the PLIST </div> <div class="sect2" lang="en"> <div class="titlepage"><div><div><h3 class="title"> -<a name="desktop-files"></a>17.5.19. Packages installing desktop files</h3></div></div></div> +<a name="desktop-files"></a>17.6.19. Packages installing desktop files</h3></div></div></div> <p>If a package installs <code class="filename">.desktop</code> files under <code class="filename">share/applications</code> and these include MIME information, you need to take extra steps to ensure that they @@ -8184,6 +8238,32 @@ Changes to the PLIST print-PLIST</strong></span>.</p> </div> </div> +<div class="sect1" lang="en"> +<div class="titlepage"><div><div><h2 class="title" style="clear: both"> +<a name="punting"></a>17.7. Marking packages as having problems</h2></div></div></div> +<p>In some cases one does not have the time to solve a problem + immediately. There are currently two ways to declare that one knows + that a package has problems.</p> +<div class="itemizedlist"><ul type="disc"> +<li><p>The first way is to plainly mark it as broken. For + this, one just sets the variable <code class="varname">BROKEN</code> to the + reason why the package is broken (similar to the + <code class="varname">RESTRICTED</code> variable). A user trying to build + the package will immediately be shown this message, and the build + will not be even tried.</p></li> +<li><p>After each pkgsrc freeze period (a time when the + tree is stabilized and a new pkgsrc branch is cut), the packages + that were not building in the official branch build on the latest + NetBSD release will be marked as broken on that branch. This is + done by setting the <code class="varname">BROKEN_IN</code> variable to the + branch name (or appending the branch name to it). If a user tries + to build such a package and the build fails, the user gets a + message that says that the package was broken on the respective + branch(es).</p></li> +</ul></div> +<p>Both types of packages are removed from pkgsrc in irregular + intervals.</p> +</div> </div> <div class="chapter" lang="en"> <div class="titlepage"><div><div><h2 class="title"> @@ -8205,8 +8285,7 @@ Changes to the PLIST </li> <li><p>Edit the <code class="filename">Makefile</code> as requested.</p></li> <li><p>Fill in the <code class="filename">DESCR</code> file</p></li> -<li><p>Run <span><strong class="command">make configure</strong></span> - </p></li> +<li><p>Run <span><strong class="command">make configure</strong></span></p></li> <li><p>Add any dependencies glimpsed from documentation and the configure step to the package's <code class="filename">Makefile</code>.</p></li> @@ -8224,7 +8303,7 @@ Changes to the PLIST phase. <span><strong class="command">mkpatches</strong></span>, <span><strong class="command">patchdiff</strong></span> and <span><strong class="command">pkgvi</strong></span> are from the <a href="ftp://ftp.NetBSD.org/pub/NetBSD/packages/pkgsrc/pkgtools/pkgdiff/README.html" target="_top"><code class="filename">pkgtools/pkgdiff</code></a> - package. </p> + package.</p> </li> <li><p>Look at the <code class="filename">Makefile</code>, fix if necessary; see <a href="#components.Makefile" title="9.1. Makefile">Section 9.1, “<code class="filename">Makefile</code>”</a>.</p></li> @@ -8303,11 +8382,18 @@ Changes to the PLIST runs well; see <a href="#debug" title="Chapter 18. Debugging">Chapter 18, <i>Debugging</i></a> and the rest of this document. Next, generate an uuencoded gzipped <a href="http://netbsd.gw.com/cgi-bin/man-cgi?tar+1+NetBSD-current"><span class="citerefentry"><span class="refentrytitle">tar</span>(1)</span></a> archive that contains all files that make up the package. - Finally, <span><strong class="command">send-pr</strong></span> with category - “<span class="quote">pkg</span>”, a synopsis which includes the package name - and version number, a short description of your package - (contents of the COMMENT variable or DESCR file are OK) and - attach the archive to your PR.</p> + Finally, send this package to the pkgsrc bug tracking system, + either with the <a href="http://netbsd.gw.com/cgi-bin/man-cgi?send-pr+1+NetBSD-current"><span class="citerefentry"><span class="refentrytitle">send-pr</span>(1)</span></a> command, or if you don't have + that, go to the web page + <a href="http://www.NetBSD.org/Misc/send-pr.html" target="_top">http://www.NetBSD.org/Misc/send-pr.html</a>, + which contains some instructions and a link to a form, where you + can submit packages.</p> +<p>In the form of the problem report, the category should be + “<span class="quote">pkg</span>”, the synopsis should include the package name + and version number, and the description field should contain a + short description of your package (contents of the COMMENT + variable or DESCR file are OK). The uuencoded package data should + go into the “<span class="quote">fix</span>” field.</p> <p>If you want to submit several packages, please send a separate PR for each one, it's easier for us to track things that way.</p> @@ -8352,70 +8438,52 @@ Changes to the PLIST <div class="sect1" lang="en"> <div class="titlepage"><div><div><h2 class="title" style="clear: both"> <a name="committing-importing"></a>19.4. Committing: Importing a package into CVS</h2></div></div></div> -<p> - This section is only of interest for pkgsrc developers with write +<p>This section is only of interest for pkgsrc developers with write access to the pkgsrc repository. Please remember that cvs imports files relative to the current working directory, and that the pathname that you give the <span><strong class="command">cvs import</strong></span> command is so that it knows where to place the files in the repository. Newly created packages should be imported with a vendor tag of “<span class="quote">TNF</span>” and a release tag of - “<span class="quote">pkgsrc-base</span>”, e.g: -</p> + “<span class="quote">pkgsrc-base</span>”, e.g:</p> <pre class="programlisting"> <code class="prompt">$</code> cd .../pkgsrc/category/pkgname <code class="prompt">$</code> cvs import pkgsrc/category/pkgname TNF pkgsrc-base </pre> -<p> - Remember to move the directory from which you imported out of +<p>Remember to move the directory from which you imported out of the way, or cvs will complain the next time you “<span class="quote">cvs update</span>” your source tree. Also don't forget to add the new - package to the category's <code class="filename">Makefile</code>. -</p> -<p> - The commit message of the initial import should include part of the + package to the category's <code class="filename">Makefile</code>.</p> +<p>The commit message of the initial import should include part of the <code class="filename">DESCR</code> file, so people reading the mailing lists know - what the package is/does. -</p> -<p> - For new packages, “<span class="quote">cvs import</span>” is preferred to “<span class="quote">cvs + what the package is/does.</p> +<p>For new packages, “<span class="quote">cvs import</span>” is preferred to “<span class="quote">cvs add</span>” because the former gets everything with a single command, - and provides a consistent tag. -</p> + 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="updating-package"></a>19.5. Updating a package to a newer version</h2></div></div></div> -<p> - Please always put a concise, appropriate and relevant summary of the +<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> + 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 +<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> + the package.</p></li> </ul></div> -<p> - Please also recognize that, just because a new version of a package +<p>Please also recognize that, just because a new version of a package has been released, it should not automatically be upgraded in the CVS repository. We prefer to be conservative in the packages that are included in pkgsrc - development or beta packages are not really the best thing for most places in which pkgsrc is used. Please use your judgement about what should go into pkgsrc, and bear in mind that - stability is to be preferred above new and possibly untested features. -</p> + 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"> @@ -8424,13 +8492,9 @@ Changes to the PLIST <li><p>Make a copy of the directory somewhere else.</p></li> <li> <p>Remove all CVS dirs.</p> -<p> - Alternatively to the first two steps you can also do: -</p> +<p>Alternatively to the first two steps you can also do:</p> <pre class="screen"><code class="prompt">%</code> <strong class="userinput"><code>cvs -d user@cvs.NetBSD.org:/cvsroot export -D today pkgsrc/category/package</code></strong></pre> -<p> - and use that for further work. -</p> +<p>and use that for further work.</p> </li> <li><p>Fix <code class="varname">CATEGORIES</code> and any <code class="varname">DEPENDS</code> paths that just did “<span class="quote">../package</span>” @@ -8442,8 +8506,6 @@ place.</p></li> </p> <pre class="screen"><code class="prompt">%</code> <strong class="userinput"><code>cd /usr/pkgsrc</code></strong> <code class="prompt">%</code> <strong class="userinput"><code>grep /package */*/Makefile* */*/buildlink*</code></strong></pre> -<p> -</p> </li> <li><p>Fix paths in packages from step 5 to point to new location.</p></li> <li><p><span><strong class="command">cvs rm (-f)</strong></span> the package at the old location.</p></li> @@ -8452,9 +8514,7 @@ place.</p></li> <li> <p>Commit the changed and removed files:</p> <pre class="screen"><code class="prompt">%</code> <strong class="userinput"><code>cvs commit oldcategory/package oldcategory/Makefile newcategory/Makefile</code></strong></pre> -<p> - (and any packages from step 5, of course). -</p> +<p>(and any packages from step 5, of course).</p> </li> </ol></div> </div> @@ -8469,36 +8529,36 @@ place.</p></li> <code class="literal">pkgsrc-users</code> mailing list.</p> <div class="qandaset"> <dl> -<dt>20.1. <a href="#id2698635">What is the difference between +<dt>20.1. <a href="#id2699100">What is the difference between MAKEFLAGS, .MAKEFLAGS and MAKE_FLAGS?</a> </dt> -<dt>20.2. <a href="#id2698672">What is the difference between +<dt>20.2. <a href="#id2699137">What is the difference between MAKE, GMAKE and MAKE_PROGRAM?</a> </dt> -<dt>20.3. <a href="#id2698710">What is the difference between +<dt>20.3. <a href="#id2699175">What is the difference between CC, PKG_CC and PKGSRC_COMPILER?</a> </dt> -<dt>20.4. <a href="#id2698747">What is the difference between +<dt>20.4. <a href="#id2699212">What is the difference between BUILDLINK_LDFLAGS, BUILDLINK_LDADD and BUILDLINK_LIBS?</a> </dt> -<dt>20.5. <a href="#id2698765">Why does make show-var +<dt>20.5. <a href="#id2699230">Why does make show-var VARNAME=BUILDLINK_PREFIX.foo say it's empty?</a> </dt> -<dt>20.6. <a href="#id2698861">What does +<dt>20.6. <a href="#id2699258">What does ${MASTER_SITE_SOURCEFORGE:=package/} mean? I don't understand the := inside it.</a> </dt> -<dt>20.7. <a href="#id2699004">Which mailing lists are there for package +<dt>20.7. <a href="#id2699401">Which mailing lists are there for package developers?</a> </dt> -<dt>20.8. <a href="#id2699041">Where is the pkgsrc +<dt>20.8. <a href="#id2699437">Where is the pkgsrc documentation?</a> </dt> </dl> @@ -8507,7 +8567,7 @@ place.</p></li> <tbody> <tr class="question"> <td align="left" valign="top"> -<a name="id2698635"></a><a name="id2698636"></a><b>20.1.</b> +<a name="id2699100"></a><a name="id2699101"></a><b>20.1.</b> </td> <td align="left" valign="top"><p>What is the difference between <code class="varname">MAKEFLAGS</code>, <code class="varname">.MAKEFLAGS</code> and @@ -8523,7 +8583,7 @@ place.</p></li> </tr> <tr class="question"> <td align="left" valign="top"> -<a name="id2698672"></a><a name="id2698673"></a><b>20.2.</b> +<a name="id2699137"></a><a name="id2699138"></a><b>20.2.</b> </td> <td align="left" valign="top"><p>What is the difference between <code class="varname">MAKE</code>, <code class="varname">GMAKE</code> and @@ -8541,7 +8601,7 @@ place.</p></li> </tr> <tr class="question"> <td align="left" valign="top"> -<a name="id2698710"></a><a name="id2698711"></a><b>20.3.</b> +<a name="id2699175"></a><a name="id2699176"></a><b>20.3.</b> </td> <td align="left" valign="top"><p>What is the difference between <code class="varname">CC</code>, <code class="varname">PKG_CC</code> and @@ -8559,7 +8619,7 @@ place.</p></li> </tr> <tr class="question"> <td align="left" valign="top"> -<a name="id2698747"></a><a name="id2698748"></a><b>20.4.</b> +<a name="id2699212"></a><a name="id2699213"></a><b>20.4.</b> </td> <td align="left" valign="top"><p>What is the difference between <code class="varname">BUILDLINK_LDFLAGS</code>, @@ -8572,7 +8632,7 @@ place.</p></li> </tr> <tr class="question"> <td align="left" valign="top"> -<a name="id2698765"></a><a name="id2698766"></a><b>20.5.</b> +<a name="id2699230"></a><a name="id2699232"></a><b>20.5.</b> </td> <td align="left" valign="top"><p>Why does <span><strong class="command">make show-var VARNAME=BUILDLINK_PREFIX.<em class="replaceable"><code>foo</code></em></strong></span> @@ -8588,7 +8648,7 @@ place.</p></li> </tr> <tr class="question"> <td align="left" valign="top"> -<a name="id2698861"></a><a name="id2698862"></a><b>20.6.</b> +<a name="id2699258"></a><a name="id2699259"></a><b>20.6.</b> </td> <td align="left" valign="top"><p>What does <code class="literal">${MASTER_SITE_SOURCEFORGE:=package/}</code> mean? I @@ -8612,7 +8672,7 @@ place.</p></li> </tr> <tr class="question"> <td align="left" valign="top"> -<a name="id2699004"></a><a name="id2699005"></a><b>20.7.</b> +<a name="id2699401"></a><a name="id2699402"></a><b>20.7.</b> </td> <td align="left" valign="top"><p>Which mailing lists are there for package developers?</p></td> @@ -8637,7 +8697,7 @@ place.</p></li> </tr> <tr class="question"> <td align="left" valign="top"> -<a name="id2699041"></a><a name="id2699042"></a><b>20.8.</b> +<a name="id2699437"></a><a name="id2699438"></a><b>20.8.</b> </td> <td align="left" valign="top"><p>Where is the pkgsrc documentation?</p></td> @@ -8830,24 +8890,24 @@ solution is given. After applying the solution be sure to <tbody> <tr> <td>Installs OMF files under <code class="filename">share/omf</code>.</td> -<td>See <a href="#scrollkeeper-data-files" title="17.5.10. Packages installing scrollkeeper data files">Section 17.5.10, “Packages installing scrollkeeper data files”</a>.</td> +<td>See <a href="#scrollkeeper-data-files" title="17.6.9. Packages installing scrollkeeper data files">Section 17.6.9, “Packages installing scrollkeeper data files”</a>.</td> </tr> <tr> <td>Installs icons under the <code class="filename">share/icons/hicolor</code> hierarchy or updates <code class="filename">share/icons/hicolor/icon-theme.cache</code>.</td> -<td>See <a href="#hicolor-theme" title="17.5.18. Packages installing hicolor theme icons">Section 17.5.18, “Packages installing hicolor theme icons”</a>.</td> +<td>See <a href="#hicolor-theme" title="17.6.18. Packages installing hicolor theme icons">Section 17.6.18, “Packages installing hicolor theme icons”</a>.</td> </tr> <tr> <td>Installs files under <code class="filename">share/mime/packages</code>.</td> -<td>See <a href="#mime-database" title="17.5.14. Packages installing extensions to the MIME database">Section 17.5.14, “Packages installing extensions to the MIME database”</a>.</td> +<td>See <a href="#mime-database" title="17.6.13. Packages installing extensions to the MIME database">Section 17.6.13, “Packages installing extensions to the MIME database”</a>.</td> </tr> <tr> <td>Installs <code class="filename">.desktop</code> files under <code class="filename">share/applications</code> and these include MIME information.</td> -<td>See <a href="#desktop-files" title="17.5.19. Packages installing desktop files">Section 17.5.19, “Packages installing desktop files”</a>.</td> +<td>See <a href="#desktop-files" title="17.6.19. Packages installing desktop files">Section 17.6.19, “Packages installing desktop files”</a>.</td> </tr> </tbody> </table></div> @@ -9181,8 +9241,8 @@ details.</p> <a name="infr.design.intf.proc"></a>22.5.1. Procedures with parameters</h3></div></div></div> <p>In a traditional imperative programming language some of the <code class="filename">.mk</code> files could be described as - procedures. They take some input parameters and—after - inclusion—provide a result in output parameters. Since all + procedures. They take some input parameters and—after + inclusion—provide a result in output parameters. Since all variables in <code class="filename">Makefile</code>s have global scope care must be taken not to use parameter names that have already another meaning. For example, <code class="varname">PKGNAME</code> is a diff --git a/doc/pkgsrc.txt b/doc/pkgsrc.txt index 4ebd34584b8..8db7c89562d 100644 --- a/doc/pkgsrc.txt +++ b/doc/pkgsrc.txt @@ -296,33 +296,43 @@ II. The pkgsrc developer's guide 17.3.2. Using libtool on GNU packages that already support libtool 17.3.3. GNU Autoconf/Automake - 17.4. Fixing problems in the build phase - - 17.4.1. Compiling C and C++ code conditionally - 17.4.2. How to handle compiler bugs - 17.4.3. Undefined reference to "..." - - 17.5. Fixing problems in the install phase - - 17.5.1. Creating needed directories - 17.5.2. Where to install documentation - 17.5.3. Installing score files - 17.5.4. Packages containing perl scripts - 17.5.5. Packages with hardcoded paths to other interpreters - 17.5.6. Packages installing perl modules - 17.5.7. Packages installing info files - 17.5.8. Packages installing man pages - 17.5.9. Packages installing GConf2 data files - 17.5.10. Packages installing scrollkeeper data files - 17.5.11. Packages installing X11 fonts - 17.5.12. Packages installing GTK2 modules - 17.5.13. Packages installing SGML or XML data - 17.5.14. Packages installing extensions to the MIME database - 17.5.15. Packages using intltool - 17.5.16. Packages installing startup scripts - 17.5.17. Packages installing TeX modules - 17.5.18. Packages installing hicolor theme icons - 17.5.19. Packages installing desktop files + 17.4. Programming languages + + 17.4.1. C, C++, and Fortran + 17.4.2. Java + 17.4.3. Packages containing perl scripts + 17.4.4. Other programming languages + + 17.5. Fixing problems in the build phase + + 17.5.1. Compiling C and C++ code conditionally + 17.5.2. How to handle compiler bugs + 17.5.3. Undefined reference to "..." + 17.5.4. Running out of memory + + 17.6. Fixing problems in the install phase + + 17.6.1. Creating needed directories + 17.6.2. Where to install documentation + 17.6.3. Installing score files + 17.6.4. Packages with hardcoded paths to other interpreters + 17.6.5. Packages installing perl modules + 17.6.6. Packages installing info files + 17.6.7. Packages installing man pages + 17.6.8. Packages installing GConf2 data files + 17.6.9. Packages installing scrollkeeper data files + 17.6.10. Packages installing X11 fonts + 17.6.11. Packages installing GTK2 modules + 17.6.12. Packages installing SGML or XML data + 17.6.13. Packages installing extensions to the MIME database + 17.6.14. Packages using intltool + 17.6.15. Packages installing startup scripts + 17.6.16. Packages installing TeX modules + 17.6.17. Packages supporting running binaries in emulation + 17.6.18. Packages installing hicolor theme icons + 17.6.19. Packages installing desktop files + + 17.7. Marking packages as having problems 18. Debugging 19. Submitting and Committing @@ -965,6 +975,7 @@ Installing the bootstrap kit from source should be as simple as: # cd pkgsrc/bootstrap # ./bootstrap + See Chapter 2, Where to get pkgsrc and how to keep it up-to-date for other ways to get pkgsrc before bootstrapping. The given bootstrap command will use the defaults of /usr/pkg for the prefix where programs will be installed in, and / @@ -1079,6 +1090,7 @@ with the FreeBSD userland tools. There are several steps: # mv pkg_delete pkg_delete.orig # mv pkg_info pkg_info.orig + 3. An example /etc/mk.conf file will be placed in /etc/mk.conf.example file when you use the bootstrap script. @@ -1174,7 +1186,8 @@ the csh and ksh startup shortcuts) is "interix". Most systems don't have a termcap/terminfo entry for it, but the following .termcap entry provides adequate emulation in most cases: - interix:kP=\E[S:kN=\E[T:kH=\E[U:dc@:DC@:tc=pcansi: + interix:kP=\E[S:kN=\E[T:kH=\E[U:dc@:DC@:tc=pcansi: + 3.3.3.4. Limitations of the Interix platform @@ -1232,13 +1245,14 @@ packages currently assume that the user named "root" is the privileged user. To accommodate these, you may create such a user; make sure it is in the local group Administrators (or your language equivalent). -"pkg_add" creates directories of mode 0755, not 0775, in $PKG_DBDIR. For the -time being, install packages as the local Administrator (or your language +pkg_add creates directories of mode 0755, not 0775, in $PKG_DBDIR. For the time +being, install packages as the local Administrator (or your language equivalent), or run the following command after installing a package to work around the issue: # chmod -R g+w $PKG_DBDIR + 3.3.4. IRIX You will need a working C compiler, either gcc or SGI's MIPS and MIPSpro @@ -1250,10 +1264,10 @@ Please note that you will need IRIX 6.5.17 or higher, as this is the earliest version of IRIX providing support for if_indextoname(3), if_nametoindex(3), etc. -At this point in time, pkgsrc only supports one ABI at a time. That is, you can -not switch between the old 32-bit ABI, the new 32-bit ABI and the 64-bit ABI. -If you start out using "abi=n32", that's what all your packages will be built -with. +At this point in time, pkgsrc only supports one ABI at a time. That is, you +cannot switch between the old 32-bit ABI, the new 32-bit ABI and the 64-bit +ABI. If you start out using "abi=n32", that's what all your packages will be +built with. Therefore, please make sure that you have no conflicting CFLAGS in your environment or the /etc/mk.conf. Particularly, make sure that you do not try to @@ -1272,7 +1286,8 @@ for details. If you are using SGI's MIPSPro compiler, please set - PKGSRC_COMPILER= mipspro + PKGSRC_COMPILER= mipspro + in /etc/mk.conf. Otherwise, pkgsrc will assume you are using gcc and may end up passing invalid flags to the compiler. Note that bootstrap should create an @@ -1294,8 +1309,9 @@ Compiler). gcc is the default. icc 8.0 and 8.1 on i386 have been tested. To bootstrap using icc, assuming the default icc installation directory: - env CC=/opt/intel_cc_80/bin/icc LDFLAGS=-static-libcxa \ - ac_cv___attribute__=yes ./bootstrap + env CC=/opt/intel_cc_80/bin/icc LDFLAGS=-static-libcxa \ + ac_cv___attribute__=yes ./bootstrap + Note @@ -1309,13 +1325,15 @@ __attribute__ is assumed supported by the compiler. After bootstrapping, you should set PKGSRC_COMPILER in /etc/mk.conf: - PKGSRC_COMPILER= icc + PKGSRC_COMPILER= icc + The default installation directory for icc is /opt/intel_cc_80, which is also the pkgsrc default. If you have installed it into a different directory, set ICCBASE in /etc/mk.conf: - ICCBASE= /opt/icc + ICCBASE= /opt/icc + pkgsrc uses the static linking method of the runtime libraries provided by icc, so binaries can be run on other systems which do not have the shared libraries @@ -1347,16 +1365,18 @@ with the OpenBSD userland tools. There are several steps: # mv pkg_delete pkg_delete.orig # mv pkg_info pkg_info.orig + 3. An example /etc/mk.conf file will be placed in /etc/mk.conf.example file when you use the bootstrap script. OpenBSD's make program uses /etc/mk.conf as well. You can work around this by enclosing all the pkgsrc-specific parts of the file with: - .ifdef BSD_PKG_MK - # pkgsrc stuff, e.g. insert defaults/mk.conf or similar here - .else - # OpenBSD stuff - .endif + .ifdef BSD_PKG_MK + # pkgsrc stuff, e.g. insert defaults/mk.conf or similar here + .else + # OpenBSD stuff + .endif + 3.3.7. Solaris @@ -1410,9 +1430,10 @@ You will need at least the following packages installed (from WorkShop 5.0) You should set CC, CXX and optionally, CPP in /etc/mk.conf, e.g.: - CC= cc - CXX= CC - CPP= /usr/ccs/lib/cpp + CC= cc + CXX= CC + CPP= /usr/ccs/lib/cpp + 3.3.7.3. Buildling 64-bit binaries with SunPro @@ -1422,21 +1443,24 @@ programs in the bootstrap kit (bmake), the CFLAGS variable is not honored, even if it is set in the environment. To work around this bug, you can create a simple shell script called cc64 and put it somewhere in the PATH: - #! /bin/sh - exec /opt/SUNWspro/bin/cc -xtarget=ultra -xarch=v9 ${1+"$@"} + #! /bin/sh + exec /opt/SUNWspro/bin/cc -xtarget=ultra -xarch=v9 ${1+"$@"} + Then, pass the definition for CC in the environment of the bootstrap command: - $ cd bootstrap - $ CC=cc64 ./bootstrap + $ cd bootstrap + $ CC=cc64 ./bootstrap + After bootstrapping, there are two alternative ways, depending on whether you want to find bugs in packages or get your system ready quickly. If you just want a running system, add the following lines to your mk.conf file: - CC= cc64 - CXX= CC64 - PKGSRC_COMPILER= sunpro + CC= cc64 + CXX= CC64 + PKGSRC_COMPILER= sunpro + This way, all calls to the compiler will be intercepted by the above wrapper and therefore get the necessary ABI options automatically. (Don't forget to @@ -1445,12 +1469,13 @@ create the shell script CC64, too.) To find packages that ignore the user-specified CFLAGS and CXXFLAGS, add the following lines to your mk.conf file: - CC= cc - CXX= CC - PKGSRC_COMPILER= sunpro - CFLAGS= -xtarget=ultra -xarch=v9 - CXXFLAGS= -xtarget=ultra -xarch=v9 - LDFLAGS= -xtarget=ultra -xarch=v9 + CC= cc + CXX= CC + PKGSRC_COMPILER= sunpro + CFLAGS= -xtarget=ultra -xarch=v9 + CXXFLAGS= -xtarget=ultra -xarch=v9 + LDFLAGS= -xtarget=ultra -xarch=v9 + Packages that don't use the flags provided in the configuration file will try to build 32-bit binaries and fail during linking. Detecting this is useful to @@ -1463,8 +1488,9 @@ Sometimes, when using libtool, /bin/ksh crashes with a segmentation fault. The workaround is to use another shell for the configure scripts, for example by installing shells/bash and adding the following lines to your mk.conf: - CONFIG_SHELL= ${LOCALBASE}/bin/bash - WRAPPER_SHELL= ${LOCALBASE}/bin/bash + CONFIG_SHELL= ${LOCALBASE}/bin/bash + WRAPPER_SHELL= ${LOCALBASE}/bin/bash + Then, rebuild the devel/libtool-base package. @@ -2037,6 +2063,7 @@ and run make package: # cd misc/figlet # make package + 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 pkg_* tools to manipulate it. Binary packages are created by default in /usr/pkgsrc/packages, @@ -2080,14 +2107,15 @@ mk.conf for details of the default settings. You will want to ensure that ACCEPTABLE_LICENSES meet your local policy. As used in this example, _ACCEPTABLE=yes accepts all licenses. - 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 + 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 + Some options that are especially useful for bulk builds can be found at the top lines of the file mk/bulk/bsd.bulk-pkg.mk. The most useful options of these are @@ -2126,7 +2154,7 @@ tasks at the end of the pre-build stage. If the file pre-build.local exists in usual pre-build stage. An example use of pre-build.local is to have the line: echo "I do not have enough disk space to build this pig." \ - > misc/openoffice/$BROKENF + > misc/openoffice/$BROKENF to prevent the system from trying to build a particular package which requires nearly 3 GB of disk space. @@ -2142,10 +2170,11 @@ 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: - ( cd /usr/pkgsrc/security/ssh ; make bulk-install ) - if [ -f /usr/pkg/etc/rc.d/sshd ]; then + ( cd /usr/pkgsrc/security/ssh ; make bulk-install ) + if [ -f /usr/pkg/etc/rc.d/sshd ]; then /usr/pkg/etc/rc.d/sshd - fi + fi + 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 @@ -2165,6 +2194,7 @@ libs installed in /usr/local, etc. then become root and type: # cd /usr/pkgsrc # sh mk/bulk/build + If for some reason your last build didn't complete (power failure, system panic, ...), you can continue it by running: @@ -2258,7 +2288,7 @@ src/etc, be sure the following items are present and properly configured: 6. /usr/src (system sources, e. g. for sysutils/aperture): # ln -s ../disk1/cvs . - # ln -s cvs/src-2.0 src + # ln -s cvs/src-2.0 src 7. Create /var/db/pkg (not part of default install): @@ -2273,6 +2303,7 @@ src/etc, be sure the following items are present and properly configured: # cd /usr/sandbox/usr # cvs -d anoncvs@anoncvs.NetBSD.org:/cvsroot checkout -d -P pkgsrc + Do not mount/link this to the copy of your pkgsrc tree you do development in, as this will likely cause problems! @@ -2289,6 +2320,7 @@ steps: # cd /usr/sandbox/usr/pkgsrc # sh mk/bulk/do-sandbox-build + 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 /usr/sandbox/usr/pkgsrc/packages (wherever that points/mounts to/ @@ -2360,6 +2392,7 @@ chroot-# rm $HOME/.ssh/id-dsa* chroot-# ssh-keygen -t dsa chroot-# cat $HOME/.ssh/id-dsa.pub + Now take the output of id-dsa.pub and append it to your ~/.ssh/authorized_keys file on ftp.NetBSD.org. You can remove the key after the upload is done! @@ -2375,6 +2408,7 @@ chroot-# exit # cd /usr/sandbox/usr/pkgsrc # sh mk/bulk/do-sandbox-upload + The upload process may take quite some time. Use ls(1) or du(1) on the FTP server to monitor progress of the upload. The upload script will take care of not uploading restricted packages and putting vulnerable packages into the @@ -2383,7 +2417,7 @@ vulnerable subdirectory. After the upload has ended, first thing is to revoke ssh access: nbftp% vi ~/.ssh/authorized_keys -Gdd:x! + Gdd:x! Use whatever is needed to remove the key you've entered before! Last, move the uploaded packages out of the upload directory to have them accessible to @@ -2394,6 +2428,7 @@ nbftp% mv upload/* . nbftp% rmdir upload nbftp% chmod 755 . + 6.4. Creating a multiple CD-ROM packages collection After your pkgsrc bulk-build has completed, you may wish to create a CD-ROM set @@ -2413,6 +2448,7 @@ ISO 9660 images. # pkg_add /usr/pkgsrc/packages/All/cdpack # cdpack /usr/pkgsrc/packages/All /u2/images + If you wish to include a common set of files (COPYRIGHT, README, etc.) on each CD in the collection, then you need to create a directory which contains these files. e.g. @@ -2425,6 +2461,7 @@ files. e.g. # echo "echo Hello world" >> /tmp/common/bin/myscript # chmod 755 /tmp/common/bin/myscript + Now create the images: # cdpack -x /tmp/common /usr/pkgsrc/packages/All /u2/images @@ -2950,33 +2987,43 @@ Table of Contents 17.3.2. Using libtool on GNU packages that already support libtool 17.3.3. GNU Autoconf/Automake - 17.4. Fixing problems in the build phase - - 17.4.1. Compiling C and C++ code conditionally - 17.4.2. How to handle compiler bugs - 17.4.3. Undefined reference to "..." - - 17.5. Fixing problems in the install phase - - 17.5.1. Creating needed directories - 17.5.2. Where to install documentation - 17.5.3. Installing score files - 17.5.4. Packages containing perl scripts - 17.5.5. Packages with hardcoded paths to other interpreters - 17.5.6. Packages installing perl modules - 17.5.7. Packages installing info files - 17.5.8. Packages installing man pages - 17.5.9. Packages installing GConf2 data files - 17.5.10. Packages installing scrollkeeper data files - 17.5.11. Packages installing X11 fonts - 17.5.12. Packages installing GTK2 modules - 17.5.13. Packages installing SGML or XML data - 17.5.14. Packages installing extensions to the MIME database - 17.5.15. Packages using intltool - 17.5.16. Packages installing startup scripts - 17.5.17. Packages installing TeX modules - 17.5.18. Packages installing hicolor theme icons - 17.5.19. Packages installing desktop files + 17.4. Programming languages + + 17.4.1. C, C++, and Fortran + 17.4.2. Java + 17.4.3. Packages containing perl scripts + 17.4.4. Other programming languages + + 17.5. Fixing problems in the build phase + + 17.5.1. Compiling C and C++ code conditionally + 17.5.2. How to handle compiler bugs + 17.5.3. Undefined reference to "..." + 17.5.4. Running out of memory + + 17.6. Fixing problems in the install phase + + 17.6.1. Creating needed directories + 17.6.2. Where to install documentation + 17.6.3. Installing score files + 17.6.4. Packages with hardcoded paths to other interpreters + 17.6.5. Packages installing perl modules + 17.6.6. Packages installing info files + 17.6.7. Packages installing man pages + 17.6.8. Packages installing GConf2 data files + 17.6.9. Packages installing scrollkeeper data files + 17.6.10. Packages installing X11 fonts + 17.6.11. Packages installing GTK2 modules + 17.6.12. Packages installing SGML or XML data + 17.6.13. Packages installing extensions to the MIME database + 17.6.14. Packages using intltool + 17.6.15. Packages installing startup scripts + 17.6.16. Packages installing TeX modules + 17.6.17. Packages supporting running binaries in emulation + 17.6.18. Packages installing hicolor theme icons + 17.6.19. Packages installing desktop files + + 17.7. Marking packages as having problems 18. Debugging 19. Submitting and Committing @@ -3096,18 +3143,24 @@ for example from where to get it, how to configure, build, and install it. A package Makefile contains several sections that describe the package. In the first section there are the following variables, which should appear -exactly in the order given here. The ordering and grouping of variables is +exactly in the order given here. The order and grouping of the variables is mostly historical and has no further meaning. * DISTNAME is the basename of the distribution file to be downloaded from the package's website. * PKGNAME is the name of the package, as used by pkgsrc. You only need to - provide it if it differs from DISTNAME. Usually it is the directory name - together with the version number. It must match the regular expression ^ - [A-Za-z0-9][A-Za-z0-9-_.+]*$, that is, it starts with a letter or digit, - and contains only letters, digits, dashes, underscores, dots and plus - signs. + provide it if DISTNAME (which is the default) is not a good name for the + package in pkgsrc. Usually it is the pkgsrc directory name together with + the version number. It must match the regular expression ^[A-Za-z0-9] + [A-Za-z0-9-_.+]*$, that is, it starts with a letter or digit, and contains + only letters, digits, dashes, underscores, dots and plus signs. + + * SVR4_PKGNAME is the name of the package file to create if the PKGNAME isn't + unique on a SVR4 system. The default is PKGNAME, which may be shortened + when you use pkgtools/gensolpkg. Only add SVR4_PKGNAME if PKGNAME does not + produce an unique package name on a SVR4 system. The length of SVR4_PKGNAME + is limited to 5 characters. * CATEGORIES is a list of categories which the package fits in. You can choose any of the top-level directories of pkgsrc for it. @@ -3115,14 +3168,15 @@ mostly historical and has no further meaning. Currently the following values are available for CATEGORIES. If more than one is used, they need to be separated by spaces: - archivers cross geography meta-pkgs security - audio databases graphics misc shells - benchmarks devel ham multimedia sysutils - biology editors inputmethod net textproc - cad emulators lang news time - chat finance mail parallel wm - comms fonts math pkgtools www - converters games mbone print x11 + archivers cross geography meta-pkgs security + audio databases graphics misc shells + benchmarks devel ham multimedia sysutils + biology editors inputmethod net textproc + cad emulators lang news time + chat finance mail parallel wm + comms fonts math pkgtools www + converters games mbone print x11 + * MASTER_SITES, DYNAMIC_MASTER_SITES, DIST_SUBDIR, EXTRACT_SUFX and DISTFILES are discussed in detail in Section 15.5, "The fetch phase". @@ -3161,11 +3215,11 @@ Other variables that affect the build: If a package doesn't create a subdirectory for itself (most GNU software does, for instance), but extracts itself in the current directory, you - should set WRKSRC= ${WRKDIR}. + should set WRKSRC=${WRKDIR}. If a package doesn't create a subdirectory with the name of DISTNAME but some different name, set WRKSRC to point to the proper name in ${WRKDIR}, - for example WRKSRC= ${WRKDIR}/${DISTNAME}/unix. See lang/tcl and x11/tk for + for example WRKSRC=${WRKDIR}/${DISTNAME}/unix. See lang/tcl and x11/tk for other examples. The name of the working directory created by pkgsrc is taken from the @@ -3184,7 +3238,7 @@ Please pay attention to the following gotchas: * Replace /usr/local with "${PREFIX}" in all files (see patches, below). - * If the package installs any info files, see Section 17.5.7, "Packages + * If the package installs any info files, see Section 17.6.6, "Packages installing info files". 9.2. distinfo @@ -3234,14 +3288,27 @@ make a whole set of patches. You just have to backup files before you edit them to filename.orig, e.g. with cp -p filename filename.orig or, easier, by using pkgvi again from the same package. If you upgrade a package this way, you can easily compare the new set of patches with the previously existing one with -patchdiff. +patchdiff. Copy the patches you want to use or update from the work/.newpatches +directory to patches/. When you have finished a package, remember to generate the checksums for the patch files by using the make makepatchsum command, see Section 9.2, "distinfo" . +When adding a patch that corrects a problem in the distfile (rather than e.g. +enforcing pkgsrc's view of where man pages should go), send the patch as a bug +report to the maintainer. This benefits non-pkgsrc users of the package, and +usually makes it possible to remove the patch in future version. + +If you want to share patches between multiple packages in pkgsrc, e.g. because +they use the same distfiles, set PATCHDIR to the path where the patch files can +be found, e.g.: + + PATCHDIR= ${.CURDIR}/../xemacs/patches + + Patch files that are distributed by the author or other maintainers can be -listed in $PATCHFILES. +listed in PATCHFILES. If it is desired to store any patches that should not be committed into pkgsrc, they can be kept outside the pkgsrc tree in the $LOCALPATCHES directory. The @@ -3269,7 +3336,7 @@ from other OSes (e.g. Linux implementing kqueue), something that the above checks cannot take into account. Of course, checking for features generally involves more work on the -developer's side, but the resulting changes are clearner and there are chances +developer's side, but the resulting changes are cleaner and there are chances they will work on many other platforms. Not to mention that there are higher chances of being later integrated into the mainstream sources. Remember: It doesn't work unless it is right! @@ -3278,32 +3345,32 @@ Some typical examples: Table 9.1. Patching examples -+-----------------------------------------------------------------------------------------------+ -| Where | Incorrect | Correct | -|---------+------------------------------+------------------------------------------------------| -| |case ${target_os} in | | -|configure| netbsd*) have_kvm=yes ;;|AC_CHECK_LIB(kvm, kvm_open, have_kvm=yes, have_kvm=no)| -|script | *) have_kvm=no ;;| | -| | esac | | -| | | | -|---------+------------------------------+------------------------------------------------------| -| |#if defined(__NetBSD__) |#if defined(HAVE_SYS_EVENT_H) | -|C source | # include <sys/event.h> | # include <sys/event.h> | -|file | #endif | #endif | -| | | | -|---------+------------------------------+------------------------------------------------------| -| |int |int | -| | monitor_file(...) | monitor_file(...) | -| | { | { | -| | #if defined(__NetBSD__) | #if defined(HAVE_KQUEUE) | -|C source | int fd = kqueue(); | int fd = kqueue(); | -|file | ... | ... | -| | #else | #else | -| | ... | ... | -| | #endif | #endif | -| | } | } | -| | | | -+-----------------------------------------------------------------------------------------------+ ++---------------------------------------------------------------------------------------------------------+ +| Where | Incorrect | Correct | +|---------+----------------------------------------+------------------------------------------------------| +| |case ${target_os} in | | +|configure| netbsd*) have_kvm=yes ;;|AC_CHECK_LIB(kvm, kvm_open, have_kvm=yes, have_kvm=no)| +|script | *) have_kvm=no ;;| | +| | esac | | +| | | | +|---------+----------------------------------------+------------------------------------------------------| +| |#if defined(__NetBSD__) |#if defined(HAVE_SYS_EVENT_H) | +|C source | # include <sys/event.h>| # include <sys/event.h> | +|file | #endif | #endif | +| | | | +|---------+----------------------------------------+------------------------------------------------------| +| |int |int | +| | monitor_file(...) | monitor_file(...) | +| | { | { | +| | #if defined(__NetBSD__) | #if defined(HAVE_KQUEUE) | +|C source | int fd = kqueue(); | int fd = kqueue(); | +|file | ... | ... | +| | #else | #else | +| | ... | ... | +| | #endif | #endif | +| | } | } | +| | | | ++---------------------------------------------------------------------------------------------------------+ For more information, please read the Making packager-friendly software article @@ -3355,7 +3422,8 @@ INSTALL extraction and before files are moved in place, the second time after the files to install are moved in place. This can be used to do any custom procedures not possible with @exec commands in PLIST. See pkg_add(1) and - pkg_create(1) for more information. + pkg_create(1) for more information. See also Section 13.1, "Files and + directories outside the installation prefix". DEINSTALL @@ -3373,9 +3441,15 @@ MESSAGE can modify variables in it easily by using MESSAGE_SUBST in the package's Makefile: - MESSAGE_SUBST+= SOMEVAR="somevalue" + MESSAGE_SUBST+= SOMEVAR="somevalue" + + + replaces "${SOMEVAR}" with "somevalue" in MESSAGE. By default, substitution + is performed for PKGNAME, PKGBASE, PREFIX, LOCALBASE, X11PREFIX, X11BASE, + PKG_SYSCONFDIR, ROOT_GROUP, and ROOT_GROUP. - replaces "${SOMEVAR}" with "somevalue" in MESSAGE. + You can display a different or additional files by setting the MESSAGE_SRC + variable. Its default is MESSAGE, if the file exists. ALTERNATIVES @@ -3432,11 +3506,17 @@ directory gets removed completely on clean. The default is ${.CURDIR}/work or $ 9.7. files/* 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 "${CP}" +configuration or building, you could place these files here and use a ${CP} command in the "pre-configure" target to achieve this. Alternatively, you could simply diff the file against /dev/null and use the patch mechanism to manage the creation of this file. +If you want to share files in this way with other packages, set the FILESDIR +variable to point to the other package's files directory, e.g.: + + FILESDIR=${.CURDIR}/../xemacs/files + + Chapter 10. Programming in Makefiles Table of Contents @@ -3705,7 +3785,8 @@ the PLIST file (or files, see below!). Be sure to add a RCS ID line as the first thing in any PLIST file you write: - @comment $NetBSD$ + @comment $NetBSD$ + 11.2. Semi-automatic PLIST generation @@ -3729,12 +3810,14 @@ scripting you like to it, but be careful with quoting. For example, to get all files inside the libdata/foo directory removed from the resulting PLIST: - PRINT_PLIST_AWK+= /^libdata\/foo/ { next; } + PRINT_PLIST_AWK+= /^libdata\/foo/ { next; } + And to get all the @dirrm lines referring to a specific (shared) directory converted to @comments: - PRINT_PLIST_AWK+= /^@dirrm share\/specific/ { print "@comment " $$0; next; } + PRINT_PLIST_AWK+= /^@dirrm share\/specific/ { print "@comment " $$0; next; } + 11.4. Variable substitution in PLIST @@ -3774,7 +3857,8 @@ If you want to change other variables not listed above, you can add variables and their expansions to this variable in the following way, similar to MESSAGE_SUBST (see Section 9.5, "Optional files"): - PLIST_SUBST+= SOMEVAR="somevalue" + PLIST_SUBST+= SOMEVAR="somevalue" + This replaces all occurrences of "${SOMEVAR}" in the PLIST with "somevalue". @@ -3790,7 +3874,8 @@ the PLIST file is done on a copy of it, not PLIST itself. To use one or more files as source for the PLIST used in generating the binary package, set the variable PLIST_SRC to the names of that file(s). The files are -later concatenated using cat(1), and order of things is important. +later concatenated using cat(1), and the order of things is important. The +default for PLIST_SRC is ${PKGDIR}/PLIST. 11.7. Platform-specific and differing PLISTs @@ -3819,7 +3904,8 @@ Within pkgsrc, you'll find both approaches. If a directory is shared by a few unrelated packages, it's often not worth to add an extra package to remove it. Therefore, one simply does: - @unexec ${RMDIR} %D/path/to/shared/directory 2>/dev/null || ${TRUE} + @unexec ${RMDIR} %D/path/to/shared/directory 2>/dev/null || ${TRUE} + in the PLISTs of all affected packages, instead of the regular "@dirrm" line. @@ -3836,8 +3922,9 @@ solutions are available: From now on, we'll discuss the second solution. To get an idea of the *-dirs packages available, issue: - % cd .../pkgsrc - % ls -d */*-dirs + % cd .../pkgsrc + % ls -d */*-dirs + Their use from other packages is very simple. The USE_DIRS variable takes a list of package names (without the "-dirs" part) together with the required @@ -3846,7 +3933,8 @@ version number (always pick the latest one when writing new packages). For example, if a package installs files under share/applications, it should have the following line in it: - USE_DIRS+= xdg-1.1 + USE_DIRS+= xdg-1.1 + After regenerating the PLIST using make print-PLIST, you should get the right (commented out) lines. @@ -3909,18 +3997,21 @@ The process of converting packages to use the buildlink3 framework If a dependency on a particular package is required for its libraries and headers, then we replace: - DEPENDS+= foo>=1.1.0:../../category/foo + DEPENDS+= foo>=1.1.0:../../category/foo + with - .include "../../category/foo/buildlink3.mk" + .include "../../category/foo/buildlink3.mk" + The buildlink3.mk files usually define the required dependencies. If you need a newer version of the dependency when using buildlink3.mk files, then you can define it in your Makefile; for example: - BUILDLINK_API_DEPENDS.foo+= foo>=1.1.0 - .include "../../category/foo/buildlink3.mk" + BUILDLINK_API_DEPENDS.foo+= foo>=1.1.0 + .include "../../category/foo/buildlink3.mk" + There are several buildlink3.mk files in pkgsrc/mk that handle special package issues: @@ -3968,32 +4059,34 @@ following command will generate a good starting point for buildlink3.mk files: % cd pkgsrc/category/pkgdir % createbuildlink >buildlink3.mk + 12.2.1. Anatomy of a buildlink3.mk file The following real-life example buildlink3.mk is taken from pkgsrc/graphics/ tiff: - # $NetBSD: buildlink3.mk,v 1.7 2004/03/18 09:12:12 jlam Exp $ + # $NetBSD: buildlink3.mk,v 1.7 2004/03/18 09:12:12 jlam Exp $ - BUILDLINK_DEPTH:= ${BUILDLINK_DEPTH}+ - TIFF_BUILDLINK3_MK:= ${TIFF_BUILDLINK3_MK}+ + BUILDLINK_DEPTH:= ${BUILDLINK_DEPTH}+ + TIFF_BUILDLINK3_MK:= ${TIFF_BUILDLINK3_MK}+ - .if !empty(BUILDLINK_DEPTH:M+) - BUILDLINK_DEPENDS+= tiff - .endif + .if !empty(BUILDLINK_DEPTH:M+) + BUILDLINK_DEPENDS+= tiff + .endif + + BUILDLINK_PACKAGES:= ${BUILDLINK_PACKAGES:Ntiff} + BUILDLINK_PACKAGES+= tiff - BUILDLINK_PACKAGES:= ${BUILDLINK_PACKAGES:Ntiff} - BUILDLINK_PACKAGES+= tiff + .if !empty(TIFF_BUILDLINK3_MK:M+) + BUILDLINK_API_DEPENDS.tiff+= tiff>=3.6.1 + BUILDLINK_PKGSRCDIR.tiff?= ../../graphics/tiff + .endif # TIFF_BUILDLINK3_MK - .if !empty(TIFF_BUILDLINK3_MK:M+) - BUILDLINK_API_DEPENDS.tiff+= tiff>=3.6.1 - BUILDLINK_PKGSRCDIR.tiff?= ../../graphics/tiff - .endif # TIFF_BUILDLINK3_MK + .include "../../devel/zlib/buildlink3.mk" + .include "../../graphics/jpeg/buildlink3.mk" - .include "../../devel/zlib/buildlink3.mk" - .include "../../graphics/jpeg/buildlink3.mk" + BUILDLINK_DEPTH:= ${BUILDLINK_DEPTH:S/+$//} - BUILDLINK_DEPTH:= ${BUILDLINK_DEPTH:S/+$//} The header and footer manipulate BUILDLINK_DEPTH, which is common across all buildlink3.mk files and is used to track at what depth we are including @@ -4115,44 +4208,45 @@ The only requirements of a builtin.mk file for pkg are: The following is the recommended template for builtin.mk files: - .if !defined(IS_BUILTIN.foo) - # - # IS_BUILTIN.foo is set to "yes" or "no" depending on whether "foo" - # genuinely exists in the system or not. - # - IS_BUILTIN.foo?= no + .if !defined(IS_BUILTIN.foo) + # + # IS_BUILTIN.foo is set to "yes" or "no" depending on whether "foo" + # genuinely exists in the system or not. + # + IS_BUILTIN.foo?= no + + # BUILTIN_PKG.foo should be set here if "foo" is built-in and its package + # version can be determined. + # + . if !empty(IS_BUILTIN.foo:M[yY][eE][sS]) + BUILTIN_PKG.foo?= foo-1.0 + . endif + .endif # IS_BUILTIN.foo + + .if !defined(USE_BUILTIN.foo) + USE_BUILTIN.foo?= ${IS_BUILTIN.foo} + . if defined(BUILTIN_PKG.foo) + . for _depend_ in ${BUILDLINK_API_DEPENDS.foo} + . if !empty(USE_BUILTIN.foo:M[yY][eE][sS]) + USE_BUILTIN.foo!= \ + if ${PKG_ADMIN} pmatch '${_depend_}' ${BUILTIN_PKG.foo}; then \ + ${ECHO} "yes"; \ + else \ + ${ECHO} "no"; \ + fi + . endif + . endfor + . endif + .endif # USE_BUILTIN.foo + + CHECK_BUILTIN.foo?= no + .if !empty(CHECK_BUILTIN.foo:M[nN][oO]) + # + # Here we place code that depends on whether USE_BUILTIN.foo is set to + # "yes" or "no". + # + .endif # CHECK_BUILTIN.foo - # BUILTIN_PKG.foo should be set here if "foo" is built-in and its package - # version can be determined. - # - . if !empty(IS_BUILTIN.foo:M[yY][eE][sS]) - BUILTIN_PKG.foo?= foo-1.0 - . endif - .endif # IS_BUILTIN.foo - - .if !defined(USE_BUILTIN.foo) - USE_BUILTIN.foo?= ${IS_BUILTIN.foo} - . if defined(BUILTIN_PKG.foo) - . for _depend_ in ${BUILDLINK_API_DEPENDS.foo} - . if !empty(USE_BUILTIN.foo:M[yY][eE][sS]) - USE_BUILTIN.foo!= \ - if ${PKG_ADMIN} pmatch '${_depend_}' ${BUILTIN_PKG.foo}; then \ - ${ECHO} "yes"; \ - else \ - ${ECHO} "no"; \ - fi - . endif - . endfor - . endif - .endif # USE_BUILTIN.foo - - CHECK_BUILTIN.foo?= no - .if !empty(CHECK_BUILTIN.foo:M[nN][oO]) - # - # Here we place code that depends on whether USE_BUILTIN.foo is set to - # "yes" or "no". - # - .endif # CHECK_BUILTIN.foo The first section sets IS_BUILTIN.pkg depending on if pkg really exists in the base system. This should not be a base system software with similar @@ -4193,8 +4287,9 @@ neither or in both variables, then PREFER_PKGSRC has precedence over PREFER_NATIVE. For example, to require using pkgsrc versions of software for all but the most basic bits on a NetBSD system, you can set: - PREFER_PKGSRC= yes - PREFER_NATIVE= getopt skey tcp_wrappers + PREFER_PKGSRC= yes + PREFER_NATIVE= getopt skey tcp_wrappers + A package must have a builtin.mk file to be listed in PREFER_NATIVE, otherwise it is simply ignored in that list. @@ -4262,14 +4357,27 @@ belong to a package. The names used in it are relative to the installation prefix (${PREFIX}), which means that it cannot register files outside this directory (absolute path names are not allowed). Despite this restriction, some packages need to install files outside this location; e.g., under ${VARBASE} or -${PKG_SYSCONFDIR}. +${PKG_SYSCONFDIR}. The only way to achieve this is to create such files during +installation time by using installation scripts. + +The generic installation scripts are shell scripts that can contain arbitrary +code. The list of scripts to execute is taken from the INSTALL_FILE variable, +which defaults to INSTALL. A similar variable exists for package removal +(DEINSTALL_FILE, whose default is DEINSTALL). These scripts can run arbitrary +commands, so they have the potential to create and manage files anywhere in the +file system. -The only way to achieve this is to create such files during installation time -by using the installation scripts. These scripts can run arbitrary commands, so -they have the potential to create and manage files anywhere in the file system. -Here is where pkginstall comes into play: it provides generic scripts to -abstract the manipulation of such files and directories based on variables set -in the package's Makefile. The rest of this section describes these variables. +Using these general installation files is not recommended, but may be needed in +some special cases. One reason for avoiding them is that the user has to trust +the packager that there is no unwanted or simply erroneous code included in the +installation script. Also, previously there were many similar scripts for the +same functionality, and fixing a common error involved finding and changing all +of them. + +The pkginstall framework offers another, standardized way. It provides generic +scripts to abstract the manipulation of such files and directories based on +variables set in the package's Makefile. The rest of this section describes +these variables. 13.1.1. Directory manipulation @@ -4792,15 +4900,17 @@ When choosing which of these variables to use, follow the following rules: The following lines are taken from pkgsrc/wm/scwm/Makefile: - EVAL_PREFIX+= GTKDIR=gtk+ - CONFIGURE_ARGS+= --with-guile-prefix=${LOCALBASE:Q} - CONFIGURE_ARGS+= --with-gtk-prefix=${GTKDIR:Q} - CONFIGURE_ARGS+= --enable-multibyte + EVAL_PREFIX+= GTKDIR=gtk+ + CONFIGURE_ARGS+= --with-guile-prefix=${LOCALBASE:Q} + CONFIGURE_ARGS+= --with-gtk-prefix=${GTKDIR:Q} + CONFIGURE_ARGS+= --enable-multibyte + Specific defaults can be defined for the packages evaluated using EVAL_PREFIX, by using a definition of the form: - GTKDIR_DEFAULT= ${LOCALBASE} + GTKDIR_DEFAULT= ${LOCALBASE} + where GTKDIR corresponds to the first definition in the EVAL_PREFIX pair. @@ -5066,17 +5176,17 @@ For building a package, a rough equivalent of the following code is executed. .for d in ${BUILD_DIRS} cd ${WRKSRC} && cd ${d} && env ${MAKE_ENV} \ ${MAKE_PROGRAM} ${BUILD_MAKE_FLAGS} \ - -f ${MAKEFILE} ${BUILD_TARGET} + -f ${MAKE_FILE} ${BUILD_TARGET} .endfor BUILD_DIRS (default: ".") is a list of pathnames relative to WRKSRC. In each of these directories, MAKE_PROGRAM is run with the environment MAKE_ENV and -arguments BUILD_MAKE_FLAGS. The variables MAKE_ENV, BUILD_MAKE_FLAGS, MAKEFILE +arguments BUILD_MAKE_FLAGS. The variables MAKE_ENV, BUILD_MAKE_FLAGS, MAKE_FILE and BUILD_TARGET may all be changed by the package. The default value of MAKE_PROGRAM is "gmake" if USE_TOOLS contains "gmake", -"make" otherwise. The default value of MAKEFILE is "Makefile", and BUILD_TARGET -defaults to "all". +"make" otherwise. The default value of MAKE_FILE is "Makefile", and +BUILD_TARGET defaults to "all". 15.13. The test phase @@ -5094,7 +5204,7 @@ consistency checks, registering the package, and so on. .for d in ${INSTALL_DIRS} cd ${WRKSRC} && cd ${d} && env ${MAKE_ENV} \ ${MAKE_PROGRAM} ${INSTALL_MAKE_FLAGS} \ - -f ${MAKEFILE} ${BUILD_TARGET} + -f ${MAKE_FILE} ${BUILD_TARGET} .endfor The variable's meanings are analogous to the ones in the build phase. @@ -5285,6 +5395,7 @@ clean-update # make clean CLEANDEPENDS=YES # make update + The following variables can be used either on the command line or in /etc/ mk.conf to alter the behaviour of make clean-update: @@ -5331,7 +5442,8 @@ cdrom-readme show-distfiles This target shows which distfiles and patchfiles are needed to build the - package. (DISTFILES and PATCHFILES, but not patches/*) + package (ALLFILES, which contains all DISTFILES and PATCHFILES, but not + patches/*). show-downlevel @@ -5506,33 +5618,43 @@ Table of Contents 17.3.2. Using libtool on GNU packages that already support libtool 17.3.3. GNU Autoconf/Automake -17.4. Fixing problems in the build phase - - 17.4.1. Compiling C and C++ code conditionally - 17.4.2. How to handle compiler bugs - 17.4.3. Undefined reference to "..." - -17.5. Fixing problems in the install phase - - 17.5.1. Creating needed directories - 17.5.2. Where to install documentation - 17.5.3. Installing score files - 17.5.4. Packages containing perl scripts - 17.5.5. Packages with hardcoded paths to other interpreters - 17.5.6. Packages installing perl modules - 17.5.7. Packages installing info files - 17.5.8. Packages installing man pages - 17.5.9. Packages installing GConf2 data files - 17.5.10. Packages installing scrollkeeper data files - 17.5.11. Packages installing X11 fonts - 17.5.12. Packages installing GTK2 modules - 17.5.13. Packages installing SGML or XML data - 17.5.14. Packages installing extensions to the MIME database - 17.5.15. Packages using intltool - 17.5.16. Packages installing startup scripts - 17.5.17. Packages installing TeX modules - 17.5.18. Packages installing hicolor theme icons - 17.5.19. Packages installing desktop files +17.4. Programming languages + + 17.4.1. C, C++, and Fortran + 17.4.2. Java + 17.4.3. Packages containing perl scripts + 17.4.4. Other programming languages + +17.5. Fixing problems in the build phase + + 17.5.1. Compiling C and C++ code conditionally + 17.5.2. How to handle compiler bugs + 17.5.3. Undefined reference to "..." + 17.5.4. Running out of memory + +17.6. Fixing problems in the install phase + + 17.6.1. Creating needed directories + 17.6.2. Where to install documentation + 17.6.3. Installing score files + 17.6.4. Packages with hardcoded paths to other interpreters + 17.6.5. Packages installing perl modules + 17.6.6. Packages installing info files + 17.6.7. Packages installing man pages + 17.6.8. Packages installing GConf2 data files + 17.6.9. Packages installing scrollkeeper data files + 17.6.10. Packages installing X11 fonts + 17.6.11. Packages installing GTK2 modules + 17.6.12. Packages installing SGML or XML data + 17.6.13. Packages installing extensions to the MIME database + 17.6.14. Packages using intltool + 17.6.15. Packages installing startup scripts + 17.6.16. Packages installing TeX modules + 17.6.17. Packages supporting running binaries in emulation + 17.6.18. Packages installing hicolor theme icons + 17.6.19. Packages installing desktop files + +17.7. Marking packages as having problems 17.1. General operation @@ -5583,11 +5705,13 @@ The INTERACTIVE_STAGE 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 Makefile, e.g.: - INTERACTIVE_STAGE= build + INTERACTIVE_STAGE= build + Multiple interactive stages can be specified: - INTERACTIVE_STAGE= configure install + INTERACTIVE_STAGE= configure install + 17.1.4. Handling licenses @@ -5613,23 +5737,26 @@ Denoting that a package is covered by a particular license is done by placing the license in pkgsrc/licenses and setting the LICENSE variable to a string identifying the license, e.g. in graphics/xv: - LICENSE= xv-license + LICENSE= xv-license + When trying to build, the user will get a notice that the package is covered by a license which has not been accepted: - % make - ===> xv-3.10anb9 has an unacceptable license: xv-license. - ===> To view the license, enter "/usr/bin/make show-license". - ===> To indicate acceptance, add this line to your /etc/mk.conf: - ===> ACCEPTABLE_LICENSES+=xv-license - *** Error code 1 + % make + ===> xv-3.10anb9 has an unacceptable license: xv-license. + ===> To view the license, enter "/usr/bin/make show-license". + ===> To indicate acceptance, add this line to your /etc/mk.conf: + ===> ACCEPTABLE_LICENSES+=xv-license + *** Error code 1 + The license can be viewed with make show-license, and if it is considered appropriate, the line printed above can be added to /etc/mk.conf to indicate acceptance of the particular license: - ACCEPTABLE_LICENSES+=xv-license + ACCEPTABLE_LICENSES+=xv-license + When adding a package with a new license, the license text should be added to pkgsrc/licenses for displaying. A list of known licenses can be seen in this @@ -5677,7 +5804,8 @@ set to note these restrictions: Distfiles may not be placed on FTP. Set this variable to ${RESTRICTED} if re-distribution of the source code or other distfile(s) via the Internet is - not allowed. + not allowed. If this variable is not set, the distfile(s) will be mirrored + on ftp.NetBSD.org. Please note that the use of NO_PACKAGE, IGNORE, NO_CDROM, or other generic make variables to denote restrictions is deprecated, because they unconditionally @@ -5703,7 +5831,8 @@ should be noted as a BUILD_DEPENDS. The format for a BUILD_DEPENDS and a DEPENDS definition is: - <pre-req-package-name>:../../<category>/<pre-req-package> + <pre-req-package-name>:../../<category>/<pre-req-package> + Please note that the "pre-req-package-name" may include any of the wildcard version numbers recognized by pkg_info(1). @@ -5711,22 +5840,26 @@ version numbers recognized by pkg_info(1). 1. If your package needs another package's binaries or libraries to build or run, and if that package has a buildlink3.mk file available, use it: - .include "../../graphics/jpeg/buildlink3.mk" + .include "../../graphics/jpeg/buildlink3.mk" + 2. If your package needs to use another package to build itself and there is no buildlink3.mk file available, use the BUILD_DEPENDS definition: - BUILD_DEPENDS+= autoconf-2.13:../../devel/autoconf + BUILD_DEPENDS+= autoconf-2.13:../../devel/autoconf + 3. If your package needs a library with which to link and again there is no buildlink3.mk file available, this is specified using the DEPENDS definition. For example: - DEPENDS+= xpm-3.4j:../../graphics/xpm + DEPENDS+= xpm-3.4j:../../graphics/xpm + You can also use wildcards in package dependences: - DEPENDS+= xpm-[0-9]*:../../graphics/xpm + DEPENDS+= xpm-[0-9]*:../../graphics/xpm + Note that such wildcard dependencies are retained when creating binary packages. The dependency is checked when installing the binary package and @@ -5739,7 +5872,8 @@ version numbers recognized by pkg_info(1). Wildcards can also be used to specify that a package will only build against a certain minimum version of a pre-requisite: - DEPENDS+= tiff>=3.5.4:../../graphics/tiff + DEPENDS+= tiff>=3.5.4:../../graphics/tiff + This means that the package will build against version 3.5.4 of the tiff library or newer. Such a dependency may be warranted if, for example, the @@ -5751,7 +5885,8 @@ version numbers recognized by pkg_info(1). ABI changes that do not prevent a package from building correctly. Such recommendations can be expressed using ABI_DEPENDS: - ABI_DEPENDS+= tiff>=3.6.1:../../graphics/tiff + ABI_DEPENDS+= tiff>=3.6.1:../../graphics/tiff + In addition to the above DEPENDS line, this denotes that while a package will build against tiff>=3.5.4, at least version 3.6.1 is recommended. @@ -5779,7 +5914,8 @@ version numbers recognized by pkg_info(1). variable. The print/lyx package needs to be able to execute the latex binary from the teTeX package when it runs, and that is specified: - DEPENDS+= teTeX-[0-9]*:../../print/teTeX + DEPENDS+= teTeX-[0-9]*:../../print/teTeX + The comment about wildcard dependencies from previous paragraph applies here, too. @@ -5808,11 +5944,13 @@ In this case you can set CONFLICTS to a space-separated list of packages For example, x11/Xaw3d and x11/Xaw-Xpm install the same shared library, thus you set in pkgsrc/x11/Xaw3d/Makefile: - CONFLICTS= Xaw-Xpm-[0-9]* + CONFLICTS= Xaw-Xpm-[0-9]* + and in pkgsrc/x11/Xaw-Xpm/Makefile: - CONFLICTS= Xaw3d-[0-9]* + CONFLICTS= Xaw3d-[0-9]* + Packages will automatically conflict with other packages with the name prefix and a different version string. "Xaw3d-1.5" e.g. will automatically conflict @@ -5861,18 +5999,23 @@ a weekly cron job. When making fixes to an existing package it can be useful to change the version number in PKGNAME. To avoid conflicting with future versions by the original author, a "nb1", "nb2", ... suffix can be used on package versions by setting -PKGREVISION=1 (2, ...). The "nb" is treated like a "." by the pkg tools. e.g. +PKGREVISION=1 (2, ...). The "nb" is treated like a "." by the package tools. +e.g. + + DISTNAME= foo-17.42 + PKGREVISION= 9 - DISTNAME= foo-17.42 - PKGREVISION= 9 -will result in a PKGNAME of "foo-17.42nb9". +will result in a PKGNAME of "foo-17.42nb9". If you want to use the original +value of PKGNAME without the "nbX" suffix, e.g. for setting DIST_SUBDIR, use +PKGNAME_NOREV. When a new release of the package is released, the PKGREVISION should be removed, e.g. on a new minor release of the above package, things should be like: - DISTNAME= foo-17.43 + DISTNAME= foo-17.43 + PKGREVISION should be incremented for any non-trivial change in the resulting binary package. Without a PKGREVISION bump, someone with the previous version @@ -5882,16 +6025,19 @@ trivial that no reasonable person would want to upgrade", and this is the rough test for when increasing PKGREVISION is appropriate. Examples of changes that do not merit increasing PKGREVISION are: -Changing HOMEPAGE, MAINTAINER, or comments in Makefile. -Changing build variables if the resulting binary package is the same. -Changing DESCR. -Adding PKG_OPTIONS if the default options don't change. + Changing HOMEPAGE, MAINTAINER, + or comments in Makefile. + Changing build variables if the resulting binary package is the same. + Changing DESCR. + Adding PKG_OPTIONS if the default options don't change. + Examples of changes that do merit an increase to PKGREVISION include: -Security fixes -Changes or additions to a patch file -Changes to the PLIST + Security fixes + Changes or additions to a patch file + Changes to the PLIST + PKGREVISION must also be incremented when dependencies have ABI changes. @@ -5902,13 +6048,14 @@ replacement text varies, patches alone cannot help. This is where the SUBST framework comes in. It provides an easy-to-use interface for replacing text in files. Example: - SUBST_CLASSES+= fix-paths - SUBST_STAGE.fix-paths= pre-configure - SUBST_MESSAGE.fix-paths= Fixing absolute paths. - SUBST_FILES.fix-paths= src/*.c - SUBST_FILES.fix-paths+= scripts/*.sh - SUBST_SED.fix-paths= -e 's,"/usr/local,"${PREFIX},g' - SUBST_SED.fix-paths+= -e 's,"/var/log,"${VARBASE}/log,g' + SUBST_CLASSES+= fix-paths + SUBST_STAGE.fix-paths= pre-configure + SUBST_MESSAGE.fix-paths= Fixing absolute paths. + SUBST_FILES.fix-paths= src/*.c + SUBST_FILES.fix-paths+= scripts/*.sh + SUBST_SED.fix-paths= -e 's,"/usr/local,"${PREFIX},g' + SUBST_SED.fix-paths+= -e 's,"/var/log,"${VARBASE}/log,g' + SUBST_CLASSES is a list of identifiers that are used to identify the different SUBST blocks that are defined. The SUBST framework is heavily used by pkgsrc, @@ -5959,9 +6106,10 @@ information to apply for a password, or must pay for the source, or whatever, you can set FETCH_MESSAGE to a list of lines that are displayed to the user before aborting the build. Example: - FETCH_MESSAGE= "Please download the files" - FETCH_MESSAGE+= " "${DISTFILES:Q} - FETCH_MESSAGE+= "manually from "${MASTER_SITES:Q}"." + FETCH_MESSAGE= "Please download the files" + FETCH_MESSAGE+= " "${DISTFILES:Q} + FETCH_MESSAGE+= "manually from "${MASTER_SITES:Q}"." + 17.2.2. How to handle modified distfiles with the 'old' name @@ -5972,13 +6120,14 @@ checksum will no longer match. The contents of the new distfile should be compared against the old one before changing anything, to make sure the distfile was really updated on purpose, and that no trojan horse or so crept in. Then, the correct way to work around this is to set DIST_SUBDIR to a unique -directory name, usually based on PKGNAME_NOREV. In case this happens more -often, PKGNAME can be used (thus including the nbX suffix) or a date stamp can -be appended, like ${PKGNAME_NOREV}-YYYYMMDD. Do not forget regenerating the -distinfo file after that, since it contains the DIST_SUBDIR path in the -filenames. Furthermore, a mail to the package's authors seems appropriate -telling them that changing distfiles after releases without changing the file -names is not good practice. +directory name, usually based on PKGNAME_NOREV. All DISTFILES and PATCHFILES +for this package will be put in that subdirectory of the local distfiles +directory. In case this happens more often, PKGNAME can be used (thus including +the nbX suffix) or a date stamp can be appended, like ${PKGNAME_NOREV} +-YYYYMMDD. Do not forget regenerating the distinfo file after that, since it +contains the DIST_SUBDIR path in the filenames. Furthermore, a mail to the +package's authors seems appropriate telling them that changing distfiles after +releases without changing the file names is not good practice. 17.3. Fixing problems in the configure phase @@ -5993,7 +6142,7 @@ devel/libtool pkg can help here, as it just "knows" how to build both static and dynamic libraries from a set of source files, thus being platform-independent. -Here's how to use libtool in a pkg in seven simple steps: +Here's how to use libtool in a package in seven simple steps: 1. Add USE_LIBTOOL=yes to the package Makefile. @@ -6006,8 +6155,9 @@ Here's how to use libtool in a pkg in seven simple steps: 3. For the linking of the library, remove any "ar", "ranlib", and "ld -Bshareable" commands, and instead use: - ${LIBTOOL} --mode=link ${CC} -o ${.TARGET:.a=.la} ${OBJS:.o=.lo} \ - -rpath ${PREFIX}/lib -version-info major:minor + ${LIBTOOL} --mode=link ${CC} -o ${.TARGET:.a=.la} ${OBJS:.o=.lo} \ + -rpath ${PREFIX}/lib -version-info major:minor + Note that the library is changed to have a .la extension, and the objects are changed to have a .lo extension. Change OBJS as necessary. This @@ -6018,22 +6168,23 @@ Here's how to use libtool in a pkg in seven simple steps: From the libtool manual: - So, libtool library versions are described by three integers: + So, libtool library versions are described by three integers: - CURRENT - The most recent interface number that this library implements. + CURRENT + The most recent interface number that this library implements. - REVISION - The implementation number of the CURRENT interface. + REVISION + The implementation number of the CURRENT interface. - AGE - The difference between the newest and oldest interfaces that - this library implements. In other words, the library implements - all the interface numbers in the range from number `CURRENT - - AGE' to `CURRENT'. + AGE + The difference between the newest and oldest interfaces that + this library implements. In other words, the library implements + all the interface numbers in the range from number `CURRENT - + AGE' to `CURRENT'. + + If two libraries have identical CURRENT and AGE numbers, then the + dynamic linker chooses the library with the greater REVISION number. - If two libraries have identical CURRENT and AGE numbers, then the - dynamic linker chooses the library with the greater REVISION number. The "-release" option will produce different results for a.out and ELF (excluding symlinks) in only one case. An ELF library of the form @@ -6058,18 +6209,21 @@ Here's how to use libtool in a pkg in seven simple steps: (such as "-L../somelib"), because it expects you to change that argument to be the .la file. e.g. - ${LIBTOOL} --mode=link ${CC} -o someprog -L../somelib -lsomelib + ${LIBTOOL} --mode=link ${CC} -o someprog -L../somelib -lsomelib + should be changed to: - ${LIBTOOL} --mode=link ${CC} -o someprog ../somelib/somelib.la + ${LIBTOOL} --mode=link ${CC} -o someprog ../somelib/somelib.la + and it will do the right thing with the libraries. 6. When installing libraries, preface the install(1) or cp(1) command with "$ {LIBTOOL} --mode=install", and change the library name to .la. e.g. - ${LIBTOOL} --mode=install ${BSD_INSTALL_DATA} ${SOMELIB:.a=.la} ${PREFIX}/lib + ${LIBTOOL} --mode=install ${BSD_INSTALL_DATA} ${SOMELIB:.a=.la} ${PREFIX}/lib + This will install the static .a, shared library, any needed symlinks, and run ldconfig(8). @@ -6119,27 +6273,29 @@ executed in a pre-configure target. For packages that need only autoconf: - AUTOCONF_REQD= 2.50 # if default version is not good enough - USE_TOOLS+= autoconf # use "autoconf213" for autoconf-2.13 - ... + AUTOCONF_REQD= 2.50 # if default version is not good enough + USE_TOOLS+= autoconf # use "autoconf213" for autoconf-2.13 + ... - pre-configure: - cd ${WRKSRC}; autoconf + pre-configure: + cd ${WRKSRC}; autoconf + + ... - ... and for packages that need automake and autoconf: - AUTOMAKE_REQD= 1.7.1 # if default version is not good enough - USE_TOOLS+= automake # use "automake14" for automake-1.4 - ... + AUTOMAKE_REQD= 1.7.1 # if default version is not good enough + USE_TOOLS+= automake # use "automake14" for automake-1.4 + ... + + pre-configure: + cd ${WRKSRC}; \ + aclocal; autoheader; \ + automake -a --foreign -i; autoconf - pre-configure: - cd ${WRKSRC}; \ - aclocal; autoheader; \ - automake -a --foreign -i; autoconf + ... - ... Packages which use GNU Automake will almost certainly require GNU Make. @@ -6149,7 +6305,56 @@ automake sequence. This is prevented by touching various files in the configure stage. If this causes problems with your package you can set AUTOMAKE_OVERRIDE= NO in the package Makefile. -17.4. Fixing problems in the build phase +17.4. Programming languages + +17.4.1. C, C++, and Fortran + +Compilers for the C, C++, and Fortran languages comes with the NetBSD base +system. By default, pkgsrc assumes that a package is written in C and will hide +all other compilers (via the wrapper framework, see Chapter 12, Buildlink +methodology). + +To declare which language's compiler a package needs, set the USE_LANGUAGES +variable. Allowed values currently are "c", "c++", and "fortran" (and any +combination). The default is "c". Packages using GNU configure scripts, even if +written in C++, usually need a C compiler for the configure phase. + +17.4.2. Java + +If a program is written in Java, use the Java framework in pkgsrc. The package +must include ../../mk/java-vm.mk. This Makefile fragment provides the following +variables: + + * USE_JAVA defines if a build dependency on the JDK is added. If USE_JAVA is + set to "run", then there is only a runtime dependency on the JDK. The + default is "yes", which also adds a build dependency on the JDK. + + * Set USE_JAVA2 to declare that a package needs a Java2 implementation. The + supported values are "yes", "1.4", and "1.5". "yes" accepts any Java2 + implementation, "1.4" insists on versions 1.4 or above, and "1.5" only + accepts versions 1.5 or above. This variable is not set by default. + +17.4.3. Packages containing perl scripts + +If your package contains interpreted perl scripts, add "perl" to the USE_TOOLS +variable and set REPLACE_PERL to ensure that the proper interpreter path is +set. REPLACE_PERL should contain a list of scripts, relative to WRKSRC, that +you want adjusted. Every occurrence of */bin/perl will be replaced with the +full path to the perl executable. + +If a particular version of perl is needed, set the PERL5_REQD variable to the +version number. The default is "5.0". + +See Section 17.6.5, "Packages installing perl modules" for information about +handling perl modules. + +17.4.4. Other programming languages + +Currently, there is no special handling for other languages in pkgsrc. If a +compiler package provides a buildlink3.mk file, include that, otherwise just +add a (build) dependency on the appropriate compiler package. + +17.5. Fixing problems in the build phase The most common failures when building a package are that some platforms do not provide certain header files, functions or libraries, or they provide the @@ -6157,7 +6362,7 @@ functions in a library that the original package author didn't know. To work around this, you can rewrite the source code in most cases so that it does not use the missing functions or provides a replacement function. -17.4.1. Compiling C and C++ code conditionally +17.5.1. Compiling C and C++ code conditionally If a package already comes with a GNU configure script, the preferred way to fix the build failure is to change the configure script, not the code. In the @@ -6174,7 +6379,7 @@ the compiler that is used. For example, if you want to conditionally compile code on Solaris, don't use __sun__, as the SunPro compiler does not define it. Use __sun instead. -17.4.1.1. C preprocessor macros to identify the operating system +17.5.1.1. C preprocessor macros to identify the operating system To distinguish between 4.4 BSD-derived systems and the rest of the world, you should use the following code. @@ -6197,19 +6402,19 @@ macros. OpenBSD __OpenBSD__ Solaris sun, __sun -17.4.1.2. C preprocessor macros to identify the hardware architecture +17.5.1.2. C preprocessor macros to identify the hardware architecture i386 i386, __i386, __i386__ MIPS __mips SPARC sparc, __sparc -17.4.1.3. C preprocessor macros to identify the compiler +17.5.1.3. C preprocessor macros to identify the compiler GCC __GNUC__ (major version), __GNUC_MINOR__ SunPro __SUNPRO_C (0x570 for version 5.7) SunPro C++ __SUNPRO_CC (0x580 for version 5.8) -17.4.2. How to handle compiler bugs +17.5.2. How to handle compiler bugs Some source files trigger bugs in the compiler, based on combinations of compiler version and architecture and almost always relation to optimisation @@ -6220,7 +6425,7 @@ Typically, a workaround involves testing the MACHINE_ARCH and compiler version, disabling optimisation for that combination of file, MACHINE_ARCH and compiler, and documenting it in pkgsrc/doc/HACKS. See that file for a number of examples. -17.4.3. Undefined reference to "..." +17.5.3. Undefined reference to "..." This compiler error often means that a package did not link to a shared library it needs. The following functions are known to cause this error message over @@ -6247,21 +6452,31 @@ and over. To fix these linker errors, it is often sufficient to say LIBS.OperatingSystem+ = -lfoo to the package Makefile and then say bmake clean; bmake. -17.5. Fixing problems in the install phase +17.5.4. Running out of memory + +Sometimes packages fail to build because the compiler runs into an operating +system specific soft limit. With the UNLIMIT_RESOURCES variable pkgsrc can be +told to unlimit the resources. Currently, the allowed values are "datasize" and +"stacksize" (or both). Setting this variable is similar to running the shell +builtin ulimit command to raise the maximum data segment size or maximum stack +size of a process, respectively, to their hard limits. + +17.6. Fixing problems in the install phase -17.5.1. Creating needed directories +17.6.1. Creating needed directories The BSD-compatible install supplied with some operating systems cannot create more than one directory at a time. As such, you should call ${INSTALL_*_DIR} like this: - ${INSTALL_DATA_DIR} ${PREFIX}/dir1 - ${INSTALL_DATA_DIR} ${PREFIX}/dir2 + ${INSTALL_DATA_DIR} ${PREFIX}/dir1 + ${INSTALL_DATA_DIR} ${PREFIX}/dir2 + You can also just append "dir1 dir2" to the INSTALLATION_DIRS variable, which will automatically do the right thing. -17.5.2. Where to install documentation +17.6.2. Where to install documentation In general, documentation should be installed into ${PREFIX}/share/doc/$ {PKGBASE} or ${PREFIX}/share/doc/${PKGNAME} (the latter includes the version @@ -6282,7 +6497,7 @@ then, no additional subdirectory level is allowed in this case. This is usually achieved by using "--with-html-dir=${PREFIX}/share/doc". ${PREFIX}/share/ gtk-doc is preferred though.) -17.5.3. Installing score files +17.6.3. Installing score files Certain packages, most of them in the games category, install a score file that allows all users on the system to record their highscores. In order for this to @@ -6297,30 +6512,25 @@ SETGIDGAME=YES will set all the other variables accordingly. A package should therefor never hard code file ownership or access permissions but rely on INSTALL_GAME and INSTALL_GAME_DATA to set these correctly. -17.5.4. Packages containing perl scripts - -If your package contains interpreted perl scripts, set REPLACE_PERL to ensure -that the proper interpreter path is set. REPLACE_PERL should contain a list of -scripts, relative to WRKSRC, that you want adjusted. - -17.5.5. Packages with hardcoded paths to other interpreters +17.6.4. Packages with hardcoded paths to other interpreters Your package may also contain scripts with hardcoded paths to other interpreters besides (or as well as) perl. To correct the full pathname to the script interpreter, you need to set the following definitions in your Makefile (we shall use tclsh in this example): - REPLACE_INTERPRETER+= tcl - REPLACE.tcl.old= .*/bin/tclsh - REPLACE.tcl.new= ${PREFIX}/bin/tclsh - REPLACE_FILES.tcl= # list of tcl scripts which need to be fixed, - # relative to ${WRKSRC}, just as in REPLACE_PERL + REPLACE_INTERPRETER+= tcl + REPLACE.tcl.old= .*/bin/tclsh + REPLACE.tcl.new= ${PREFIX}/bin/tclsh + REPLACE_FILES.tcl= # list of tcl scripts which need to be fixed, + # relative to ${WRKSRC}, just as in REPLACE_PERL + Note Before March 2006, these variables were called _REPLACE.* and _REPLACE_FILES.*. -17.5.6. Packages installing perl modules +17.6.5. Packages installing perl modules Makefiles of packages providing perl5 modules should include the Makefile fragment ../../lang/perl5/module.mk. It provides a do-configure target for the @@ -6333,14 +6543,15 @@ to the PLIST corresponding to the files listed in the installed .packlist file generated by most perl5 modules. This is invoked by defining PERL5_PACKLIST to a space-separated list of paths to packlist files, e.g.: - PERL5_PACKLIST= ${PERL5_SITEARCH}/auto/Pg/.packlist + PERL5_PACKLIST= ${PERL5_SITEARCH}/auto/Pg/.packlist + The variables PERL5_SITELIB, PERL5_SITEARCH, and PERL5_ARCHLIB 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 PLIST. -17.5.7. Packages installing info files +17.6.6. Packages installing info files Some packages install info files or use the "makeinfo" or "install-info" commands. INFO_FILES should be defined in the package Makefile so that INSTALL @@ -6375,7 +6586,7 @@ message. The script overriding makeinfo logs a message and according to the value of TEXINFO_REQD either runs the appropriate makeinfo command or exit on error. -17.5.8. Packages installing man pages +17.6.7. Packages installing man pages All packages that install manual pages should install them into the same directory, so that there is one common place to look for them. In pkgsrc, this @@ -6403,7 +6614,7 @@ use of --mandir, you can set GNU_CONFIGURE_MANDIR as needed. See Section 11.5, "Man page compression" for information on installation of compressed manual pages. -17.5.9. Packages installing GConf2 data files +17.6.8. Packages installing GConf2 data files If a package installs .schemas or .entries files, used by GConf2, you need to take some extra steps to make sure they get registered in the database: @@ -6430,7 +6641,7 @@ take some extra steps to make sure they get registered in the database: .entries files installed by the package, if any. Names must not contain any directories in them. -17.5.10. Packages installing scrollkeeper data files +17.6.9. Packages installing scrollkeeper data files If a package installs .omf files, used by scrollkeeper, you need to take some extra steps to make sure they get registered in the database: @@ -6446,7 +6657,7 @@ extra steps to make sure they get registered in the database: 3. Remove the share/omf directory from the PLIST. It will be handled by scrollkeeper. -17.5.11. Packages installing X11 fonts +17.6.10. Packages installing X11 fonts If a package installs font files, you will need to rebuild the fonts database in the directory where they get installed at installation and deinstallation @@ -6460,7 +6671,7 @@ Note that you should not create new directories for fonts; instead use the standard ones to avoid that the user needs to manually configure his X server to find them. -17.5.12. Packages installing GTK2 modules +17.6.11. Packages installing GTK2 modules If a package installs GTK2 immodules or loaders, you need to take some extra steps to get them registered in the GTK2 database properly: @@ -6483,7 +6694,7 @@ steps to get them registered in the GTK2 database properly: 5. Check the PLIST and remove any entries under the libdata/gtk-2.0 directory, as they will be handled automatically. -17.5.13. Packages installing SGML or XML data +17.6.12. Packages installing SGML or XML data If a package installs SGML or XML data files that need to be registered in system-wide catalogs (like DTDs, sub-catalogs, etc.), you need to take some @@ -6509,7 +6720,7 @@ extra steps: (specifically, arguments recognized by the 'add' action). Note that you will normally not use this variable. -17.5.14. Packages installing extensions to the MIME database +17.6.13. Packages installing extensions to the MIME database If a package provides extensions to the MIME database by installing .xml files inside ${PREFIX}/share/mime/packages, you need to take some extra steps to @@ -6530,7 +6741,7 @@ ensure that the database is kept consistent with respect to these new files: 3. Remove any share/mime/* directories from the PLIST. They will be handled by the shared-mime-info package. -17.5.15. Packages using intltool +17.6.14. Packages using intltool If a package uses intltool during its build, include the ../../textproc/ intltool/buildlink3.mk file, which forces it to use the intltool package @@ -6540,7 +6751,7 @@ This tracks intltool's build-time dependencies and uses the latest available version; this way, the package benefits of any bug fixes that may have appeared since it was released. -17.5.16. Packages installing startup scripts +17.6.15. Packages installing startup scripts If a package contains a rc.d script, it won't be copied into the startup directory by default, but you can enable it, by adding the option @@ -6548,7 +6759,7 @@ PKG_RCD_SCRIPTS=YES in /etc/mk.conf. This option will copy the scripts into / etc/rc.d when a package is installed, and it will automatically remove the scripts when the package is deinstalled. -17.5.17. Packages installing TeX modules +17.6.16. Packages installing TeX modules If a package installs TeX packages into the texmf tree, the ls-R database of the tree needs to be updated. @@ -6574,15 +6785,28 @@ into PKG_LOCALTEXMFPREFIX, not PKG_TEXMFPREFIX. 3. Make sure that none of ls-R databases are included in PLIST, as they will be removed only by the teTeX-bin package. -17.5.18. Packages installing hicolor theme icons +17.6.17. Packages supporting running binaries in emulation + +There are some packages that provide libraries and executables for running +binaries from a one operating system on a different one (if the latter supports +it). One example is running Linux binaries on NetBSD. + +The pkgtools/rpm2pkg helps in extracting and packaging Linux rpm packages. + +The CHECK_SHLIBS can be set to no to avoid the check-shlibs target, which tests +if all libraries for each installed executable can be found by the dynamic +linker. Since the standard dynamic linker is run, this fails for emulation +packages, because the libraries used by the emulation are not in the standard +directories. + +17.6.18. Packages installing hicolor theme icons If a package installs images under the share/icons/hicolor and/or updates the share/icons/hicolor/icon-theme.cache database, you need to take some extra steps to make sure that the shared theme directory is handled appropriately and that the cache database is rebuilt: - 1. Include ../../graphics/hicolor-icon-theme/buildlink3.mk instead of its - buildlink3.mk file. + 1. Include ../../graphics/hicolor-icon-theme/buildlink3.mk. 2. Check the PLIST and remove the entry that refers to the theme cache. @@ -6592,7 +6816,7 @@ that the cache database is rebuilt: The best way to verify that the PLIST is correct with respect to the last two points is to regenerate it using make print-PLIST. -17.5.19. Packages installing desktop files +17.6.19. Packages installing desktop files If a package installs .desktop files under share/applications and these include MIME information, you need to take extra steps to ensure that they are @@ -6606,6 +6830,26 @@ registered into the MIME database: The best way to verify that the PLIST is correct with respect to the last point is to regenerate it using make print-PLIST. +17.7. Marking packages as having problems + +In some cases one does not have the time to solve a problem immediately. There +are currently two ways to declare that one knows that a package has problems. + + * The first way is to plainly mark it as broken. For this, one just sets the + variable BROKEN to the reason why the package is broken (similar to the + RESTRICTED variable). A user trying to build the package will immediately + be shown this message, and the build will not be even tried. + + * After each pkgsrc freeze period (a time when the tree is stabilized and a + new pkgsrc branch is cut), the packages that were not building in the + official branch build on the latest NetBSD release will be marked as broken + on that branch. This is done by setting the BROKEN_IN variable to the + branch name (or appending the branch name to it). If a user tries to build + such a package and the build fails, the user gets a message that says that + the package was broken on the respective branch(es). + +Both types of packages are removed from pkgsrc in irregular intervals. + Chapter 18. Debugging To check out all the gotchas when building a package, here are the steps that I @@ -6713,10 +6957,16 @@ Section 6.3.8, "Uploading results of a bulk build". First, check that your package is complete, compiles and runs well; see Chapter 18, Debugging and the rest of this document. Next, generate an uuencoded gzipped tar(1) archive that contains all files that make up the -package. Finally, send-pr with category "pkg", a synopsis which includes the -package name and version number, a short description of your package (contents -of the COMMENT variable or DESCR file are OK) and attach the archive to your -PR. +package. Finally, send this package to the pkgsrc bug tracking system, either +with the send-pr(1) command, or if you don't have that, go to the web page +http://www.NetBSD.org/Misc/send-pr.html, which contains some instructions and a +link to a form, where you can submit packages. + +In the form of the problem report, the category should be "pkg", the synopsis +should include the package name and version number, and the description field +should contain a short description of your package (contents of the COMMENT +variable or DESCR file are OK). The uuencoded package data should go into the +"fix" field. If you want to submit several packages, please send a separate PR for each one, it's easier for us to track things that way. @@ -7066,19 +7316,19 @@ Table 21.1. PLIST handling for GNOME packages +-----------------------------------------------------------------------------+ | If the package... | Then... | |-------------------------------------------+---------------------------------| -| |See Section 17.5.10, "Packages | +| |See Section 17.6.9, "Packages | |Installs OMF files under share/omf. |installing scrollkeeper data | | |files". | |-------------------------------------------+---------------------------------| -|Installs icons under the share/icons/ |See Section 17.5.18, "Packages | +|Installs icons under the share/icons/ |See Section 17.6.18, "Packages | |hicolor hierarchy or updates share/icons/ |installing hicolor theme icons". | |hicolor/icon-theme.cache. | | |-------------------------------------------+---------------------------------| -| |See Section 17.5.14, "Packages | +| |See Section 17.6.13, "Packages | |Installs files under share/mime/packages. |installing extensions to the MIME| | |database". | |-------------------------------------------+---------------------------------| -|Installs .desktop files under share/ |See Section 17.5.19, "Packages | +|Installs .desktop files under share/ |See Section 17.6.19, "Packages | |applications and these include MIME |installing desktop files". | |information. | | +-----------------------------------------------------------------------------+ |