From 5a9336d3765b06113d88160726784195a7d227c0 Mon Sep 17 00:00:00 2001 From: rillig Date: Mon, 29 May 2006 08:55:59 +0000 Subject: regen, this time with valid HTML. --- doc/pkgsrc.html | 1537 ++++++++++++++++++++++++++++--------------------------- doc/pkgsrc.txt | 153 +++--- 2 files changed, 854 insertions(+), 836 deletions(-) diff --git a/doc/pkgsrc.html b/doc/pkgsrc.html index 14370e1ab02..b66c8fc8b8c 100644 --- a/doc/pkgsrc.html +++ b/doc/pkgsrc.html @@ -35,7 +35,8 @@

Copyright © 1994-2006 The NetBSD Foundation, Inc

-

$NetBSD: pkgsrc.xml,v 1.18 2006/05/19 22:05:09 rillig Exp $

+

$NetBSD: pkgsrc.xml,v 1.18 2006/05/19 22:05:09 rillig Exp $

+

Abstract

pkgsrc is a centralized package management system for Unix-like operating systems. This guide provides information for @@ -153,17 +154,17 @@

8. Package components - files, directories and contents
-
8.1. Makefile
-
8.2. distinfo
+
8.1. Makefile
+
8.2. distinfo
8.3. patches/*
8.4. Other mandatory files
8.5. Optional files
-
8.6. work*
-
8.7. files/*
+
8.6. work*
+
8.7. files/*
-
9. Programming in Makefiles
+
9. Programming in Makefiles
-
9.1. Makefile variables
+
9.1. Makefile variables
9.1.1. Naming conventions
9.2. Code snippets
@@ -177,7 +178,7 @@
10. PLIST issues
10.1. RCS ID
-
10.2. Semi-automatic PLIST generation
+
10.2. Semi-automatic PLIST generation
10.3. Tweaking output of make print-PLIST
10.4. Variable substitution in PLIST
10.5. Man page compression
@@ -188,14 +189,14 @@
11. Buildlink methodology
11.1. Converting packages to use buildlink3
-
11.2. Writing buildlink3.mk files
+
11.2. Writing buildlink3.mk files
11.2.1. Anatomy of a buildlink3.mk file
-
11.2.2. Updating BUILDLINK_API_DEPENDS.pkg in buildlink3.mk files
+
11.2.2. Updating BUILDLINK_API_DEPENDS.pkg in buildlink3.mk files
-
11.3. Writing builtin.mk files
+
11.3. Writing builtin.mk files
-
11.3.1. Anatomy of a builtin.mk file
+
11.3.1. Anatomy of a builtin.mk file
11.3.2. Global preferences for native or pkgsrc software
@@ -224,7 +225,7 @@
13. Options handling
13.1. Global default options
-
13.2. Converting packages to use bsd.options.mk
+
13.2. Converting packages to use bsd.options.mk
13.3. Option Names
14. The build process
@@ -366,7 +367,17 @@
B.1. Building figlet
B.2. Packaging figlet
-
C. Layout of the FTP server's package archive
+
C. Directory layout of the pkgsrc FTP server
+
+
C.1. bootstrap-pkgsrc: Bootstrap kits
+
C.2. distfiles: The distributed source files
+
C.3. iso: Currently empty
+
C.4. misc: Miscellaneous things
+
C.5. packages*: Binary packages
+
C.6. current, +200xQy: +source packages
+
D. Editing guidelines for the pkgsrc guide
D.1. Targets
@@ -406,13 +417,13 @@

pkgsrc currently contains several thousand packages, including:

...just to name a few.

@@ -467,7 +478,7 @@ that describe what's necessary to build a certain piece of software using pkgsrc. Packages are traditionally stored under - /usr/pkgsrc.

+ /usr/pkgsrc.

The NetBSD package system

This is the former name of “pkgsrc”. It is @@ -484,7 +495,7 @@ the distfile is in the form of a compressed tar-archive, but other types are possible, too. Distfiles are usually stored below - /usr/pkgsrc/distfiles.

+ /usr/pkgsrc/distfiles.

Port

This is the term used by FreeBSD and OpenBSD people for what we call a package. @@ -493,11 +504,11 @@

Precompiled/binary package

A set of binaries built with pkgsrc from a distfile - and stuffed together in a single .tgz + and stuffed together in a single .tgz file so it can be installed on machines of the same machine architecture without the need to recompile. Packages are usually generated in - /usr/pkgsrc/packages; there is also + /usr/pkgsrc/packages; there is also an archive on ftp.NetBSD.org.

Sometimes, this is referred to by the term “package” too, especially in the context of precompiled packages.

@@ -529,7 +540,7 @@ package maintainer creates packages as described in Part II, “The pkgsrc developer's guide”.

infrastructure developers

These people are involved in all those files - that live in the mk/ directory and below. + that live in the mk/ directory and below. Only these people should need to read through Part III, “The pkgsrc infrastructure internals”, though others might be curious, too.

@@ -662,8 +673,8 @@

The most common location where pkgsrc is installed is - /usr/pkgsrc for the “package - sources” and /usr/pkg for the + /usr/pkgsrc for the “package + sources” and /usr/pkg for the installed binary packages. You are though free to install the sources and binary packages wherever you want in your filesystem, provided that both paths do not contain white-space @@ -689,15 +700,15 @@

The primary download location for all pkgsrc files is ftp://ftp.NetBSD.org/pub/pkgsrc/. There are a number of subdirectories for different purposes, which are - described in detail in Appendix C, Layout of the FTP server's package archive.

+ described in detail in Appendix C, Directory layout of the pkgsrc FTP server.

The tar file for the current branch is in the directory - current and is called pkgsrc.tar.gz. + current and is called pkgsrc.tar.gz. It is autogenerated daily.

The tar file for the stable branch 2006Q1 is in the - directory 2006Q1 and is also called pkgsrc.tar.gz.

+ directory 2006Q1 and is also called pkgsrc.tar.gz.

After downloading the tar file, change to the directory where you want to have pkgsrc. This is usually - /usr. Then, run tar xfz + /usr. Then, run tar xfz pkgsrc.tar.gz to extract the files.

@@ -714,8 +725,8 @@

in it, see the examples in - /usr/share/examples/supfiles, and that the - /usr/pkgsrc directory exists. Then, simply + /usr/share/examples/supfiles, and that the + /usr/pkgsrc directory exists. Then, simply run sup -v /path/to/your/supfile.

@@ -738,12 +749,12 @@

Then, you change to the directory where you want to have your copy of pkgsrc. In most cases this is - /usr. In that directory you run the + /usr. In that directory you run the checkout command, which is cvs -q checkout -P pkgsrc for the current branch and cvs -q checkout -rpkgsrc-2006Q1 -P pkgsrc for the stable branch. This command will create a directory called - pkgsrc with all the pkgsrc files in + pkgsrc with all the pkgsrc files in it.

@@ -851,9 +862,9 @@

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 + /usr/pkg for the prefix where programs will be installed in, - and /var/db/pkg for the package database + and /var/db/pkg for the package database directory where pkgsrc will do its internal bookkeeping. However, these can also be set using command-line arguments.

@@ -861,7 +872,7 @@ available for supported platforms. An up-to-date list of these can be found on www.pkgsrc.org. Note that this only works for privileged builds that install - into /usr/pkg.

+ into /usr/pkg.

Note

The bootstrap installs a bmake tool. @@ -908,17 +919,17 @@

3.2.1.2. Using a UFS partition

-

By default, /usr will be on your root file +

By default, /usr will be on your root file system, normally HFS+. It is possible to use the default - prefix of /usr/pkg - by symlinking /usr/pkg to a directory on a UFS + prefix of /usr/pkg + by symlinking /usr/pkg to a directory on a UFS file system. Obviously, another symlink is required if you want to place the package database directory outside the prefix. e.g.

# ./bootstrap --pkgdbdir /usr/pkg/pkgdb

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 /Volumes/<volume name> when the + mount on /Volumes/<volume name> when the machine boots. If you are (re)formatting a partition as UFS, you need to ensure that the partition map correctly reflects “Apple_UFS” and not “Apple_HFS”.

@@ -949,9 +960,9 @@ with the FreeBSD userland tools. There are several steps:

  1. FreeBSD stores its ports pkg database in - /var/db/pkg. It is therefore + /var/db/pkg. It is therefore recommended that you choose a different location (e.g. - /usr/pkgdb) by + /usr/pkgdb) by using the --pkgdbdir option to the bootstrap script.

  2. If you do not intend to use the FreeBSD ports tools, it's probably a @@ -962,8 +973,8 @@ # mv pkg_delete pkg_delete.orig # mv pkg_info pkg_info.orig

    3. -

  3. An example /etc/mk.conf file will be placed in - /etc/mk.conf.example file +

  4. An example /etc/mk.conf file will be placed in + /etc/mk.conf.example file when you use the bootstrap script.

@@ -1093,10 +1104,10 @@

Interix has no native support for audio output. For audio support, pkgsrc uses the esound client/server audio system on Interix. Unlike on most platforms, the - audio/esound package does + audio/esound package does not contain the esd server component. To output audio via an Interix host, the - emulators/cygwin_esound package + emulators/cygwin_esound package must also be installed.

  • @@ -1150,16 +1161,16 @@ 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 + /etc/mk.conf. Particularly, make sure that you do not try to link n32 object files with lib64 or vice versa. Check your - /etc/compiler.defaults!

    + /etc/compiler.defaults!

    If you have the actual pkgsrc tree mounted via NFS from a different host, please make sure to set WRKOBJDIR to a local directory, as it appears that IRIX linker occasionally runs into issues when trying to link over a network-mounted file system.

    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 pkgsrc/mk/defaults/mk.conf and, of + setup. Please see pkgsrc/mk/defaults/mk.conf and, of course, your compiler's man pages for details.

    If you are using SGI's MIPSPro compiler, please set @@ -1169,14 +1180,14 @@

    - in /etc/mk.conf. Otherwise, pkgsrc will assume you + 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 appropriate mk.conf.example by + bootstrap should create an appropriate mk.conf.example by default.

    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 PATH to not include the location of gcc (often - /usr/freeware/bin), and (important) pass the + /usr/freeware/bin), and (important) pass the '--preserve-path' flag.

    • @@ -1207,15 +1218,15 @@ overridden so that __attribute__ is assumed supported by the compiler.

    After bootstrapping, you should set PKGSRC_COMPILER - in /etc/mk.conf:

    + in /etc/mk.conf:

         PKGSRC_COMPILER=        icc

    The default installation directory for icc is - /opt/intel_cc_80, which + /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:

    + /etc/mk.conf:

         ICCBASE=                /opt/icc
    @@ -1237,9 +1248,9 @@ with the OpenBSD userland tools. There are several steps:

    1. OpenBSD stores its ports pkg database in - /var/db/pkg. It is therefore + /var/db/pkg. It is therefore recommended that you choose a different location (e.g. - /usr/pkgdb) by + /usr/pkgdb) by using the --pkgdbdir option to the bootstrap script.

    2. If you do not intend to use the OpenBSD ports tools, it's probably a @@ -1251,10 +1262,10 @@ # mv pkg_info pkg_info.orig

    3. -

      An example /etc/mk.conf file will be placed in - /etc/mk.conf.example file +

      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 + /etc/mk.conf as well. You can work around this by enclosing all the pkgsrc-specific parts of the file with:

      @@ -1286,8 +1297,8 @@
 	not supported.
      
 
      Whichever compiler you use, please ensure the compiler tools and
 	  your $prefix are in your PATH. This includes
-	  /usr/ccs/{bin,lib}
-	  and e.g. /usr/pkg/{bin,sbin}.
      
+	  /usr/ccs/{bin,lib}
+	  and e.g. /usr/pkg/{bin,sbin}.
      
 
      
 
      
 3.2.7.1. If you are using gcc
      
@@ -1295,7 +1306,7 @@
 	  for building all packages.
      
 
      It is recommended that an external gcc be used only for bootstrapping,
 	  then either build gcc from
-	  lang/gcc or install a binary gcc
+	  lang/gcc or install a binary gcc
 	  package, then remove gcc used during bootstrapping.
      
 
      Binary packages of gcc can be found through http://www.sun.com/bigadmin/common/freewareSearch.html.
      
 
      
@@ -1315,7 +1326,7 @@
 		- Sun WorkShop Compilers common components

    You should set CC, CXX and - optionally, CPP in /etc/mk.conf, + optionally, CPP in /etc/mk.conf, e.g.:

         CC=     cc
@@ -1329,10 +1340,10 @@
 
    Building 64-bit binaries is a little trickier. First, you
 	need to bootstrap pkgsrc in 64-bit mode. One problem here is
 	that while building one of the programs in the bootstrap kit
-	(bmake), the CFLAGS
+	(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
+	called cc64 and put it somewhere in the
 	PATH:
    
 
         #! /bin/sh
@@ -1347,7 +1358,7 @@
 
    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
+	add the following lines to your mk.conf
 	file:
    
 
         CC=                     cc64
@@ -1357,10 +1368,10 @@
 
    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
-	CC64, too.)
    
+	CC64, too.)
    
 
    To find packages that ignore the user-specified
 	CFLAGS and CXXFLAGS, add
-	the following lines to your mk.conf
+	the following lines to your mk.conf
 	file:
    
 
         CC=                     cc
@@ -1380,15 +1391,15 @@
 
    
 3.2.7.4. Common problems
    
 
    Sometimes, when using libtool,
-	/bin/ksh crashes with a segmentation fault.
+	/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:
    
+	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
 
    
-
    Then, rebuild the devel/libtool-base package.
    
+
    Then, rebuild the devel/libtool-base package.
    @@ -1428,7 +1439,7 @@ operating systems, you need to install them first. For the following platforms, prebuilt versions of the package tools are available and can simply be downloaded and unpacked in the - / directory:

    + / directory:

    @@ -1442,18 +1453,18 @@ - + - +
    Solaris 9ftp://ftp0.mh.bbc.co.uk/pub/pkgsrc/packages/bootstrap-pkgsrc/ftp://ftp0.mh.bbc.co.uk/pub/pkgsrc/packages/bootstrap-pkgsrc/
    Solaris 10http://public.enst.fr/pkgsrc/packages/bootstrap-pkgsrc/http://public.enst.fr/pkgsrc/packages/bootstrap-pkgsrc/

    These prebuilt package tools use - /usr/pkg for the base directory, and - /var/db/pkg for the database of installed + /usr/pkg for the base directory, and + /var/db/pkg for the database of installed packages. If you cannot use these directories for whatever reasons (maybe because you're not root), you have to build the package tools yourself, which is explained in Section 3.1, “Bootstrapping pkgsrc”.

    @@ -1464,9 +1475,9 @@ where to get them. You can get them on CD-ROMs, DVDs, or via FTP or HTTP.

    For NetBSD, the binary packages are made available on - ftp.NetBSD.org and its mirrors, in the + ftp.NetBSD.org and its mirrors, in the directory - /pub/NetBSD/packages/OSVERSION/ARCH/. + /pub/NetBSD/packages/OSVERSION/ARCH/. For OSVERSION, you should insert the output of uname -r, and for ARCH the output of uname @@ -1486,11 +1497,11 @@ Solaris 9 -ftp://ftp0.mh.bbc.co.uk/pub/pkgsrc/packages/ +ftp://ftp0.mh.bbc.co.uk/pub/pkgsrc/packages/ Solaris 10 -http://public.enst.fr/pkgsrc/packages/ +http://public.enst.fr/pkgsrc/packages/ @@ -1498,11 +1509,11 @@

    Most of these directories contain the pkgsrc distribution for multiple platforms. Select the appropriate subdirectories, according to your machine architecture and operating system, - until you find a directory called All. This + until you find a directory called All. This directory contains all the binary packages. Further, there are subdirectories for categories that contain symbolic links that point to the actual binary package in - ../All. This directory layout is used for + ../All. This directory layout is used for all package repositories, no matter if they are accessed via HTTP, FTP, NFS, CD-ROM, or the local filesystem.

    @@ -1525,21 +1536,21 @@ PKG_PATH environment variable to a semicolon-separated list of paths (including remote URLs); trailing slashes are not allowed.

    -

    Additionally to the All directory - there exists a vulnerable directory to +

    Additionally to the All directory + there exists a vulnerable directory to which binary packages with known vulnerabilities are moved, since removing them could cause missing dependencies. To - use these packages, add the vulnerable + use these packages, add the vulnerable directory to your PKG_PATH. However, you should run - security/audit-packages regularly, + security/audit-packages regularly, especially after installing new packages, and verify that the vulnerabilities are acceptable for your configuration. An example PKG_PATH would be: - ftp://ftp.NetBSD.org/pub/NetBSD/packages/<OSVERSION>/<ARCH>/All;ftp://ftp.NetBSD.org/pub/NetBSD/packages/<OSVERSION>/<ARCH>/vulnerable + ftp://ftp.NetBSD.org/pub/NetBSD/packages/<OSVERSION>/<ARCH>/All;ftp://ftp.NetBSD.org/pub/NetBSD/packages/<OSVERSION>/<ARCH>/vulnerable Please note that semicolon (';') is a shell meta-character, so you'll probably have to quote it.

    After you've installed packages, be sure to have - /usr/pkg/bin and /usr/pkg/sbin in your + /usr/pkg/bin and /usr/pkg/sbin in your PATH so you can actually start the just installed program.

    @@ -1582,19 +1593,19 @@ downloaded, pkgsrc will fetch them automatically.

    You can overwrite some of the major distribution sites to fit to sites that are close to your own. Have a look at - pkgsrc/mk/defaults/mk.conf to find some examples + pkgsrc/mk/defaults/mk.conf to find some examples — in particular, look for the MASTER_SORT, MASTER_SORT_REGEX and INET_COUNTRY definitions. This may save some of your bandwidth and time.

    You can change these settings either in your shell's environment, or, if you want to keep the settings, by editing the - /etc/mk.conf file, + /etc/mk.conf file, and adding the definitions there.

    If you don't have a permanent Internet connection and you want to know which files to download, make fetch-list will tell you what you'll need. Put these distfiles into - /usr/pkgsrc/distfiles.

    + /usr/pkgsrc/distfiles.

    @@ -1622,25 +1633,25 @@

    Taking the figlet utility as an example, we can install it on our system by building as shown in Appendix B, Build logs.

    The program is installed under the default root of the packages tree - - /usr/pkg. Should this not conform to your tastes, + /usr/pkg. Should this not conform to your tastes, set the LOCALBASE variable in your environment, and it will use that value as the root of - your packages tree. So, to use /usr/local, set + your packages tree. So, to use /usr/local, set LOCALBASE=/usr/local in your environment. Please note that you should use a directory which is dedicated to packages and not shared with other programs (i.e., do not try and use LOCALBASE=/usr). Also, you should not try to - add any of your own files or directories (such as src/, - obj/, or pkgsrc/) below the + add any of your own files or directories (such as src/, + obj/, or pkgsrc/) below the LOCALBASE tree. This is to prevent possible conflicts between programs and other files installed by the package system and whatever else may have been installed there.

    -

    Some packages look in /etc/mk.conf to alter some +

    Some packages look in /etc/mk.conf to alter some configuration options at build time. Have a look at - pkgsrc/mk/defaults/mk.conf to + pkgsrc/mk/defaults/mk.conf to get an overview of what will be set there by default. Environment variables such as LOCALBASE - can be set in /etc/mk.conf to + can be set in /etc/mk.conf to save having to remember to set them each time you want to use pkgsrc.

    Occasionally, people want to “look under the covers” to see what is going on when a package is building or being installed. This may be @@ -1675,7 +1686,7 @@ BINPKG_SITES, which defaults to ftp.NetBSD.org. Any flags that should be added to pkg_add(1) can be put into BIN_INSTALL_FLAGS. - See pkgsrc/mk/defaults/mk.conf for more details.

    + See pkgsrc/mk/defaults/mk.conf for more details.

    A final word of warning: If you set up a system that has a non-standard setting for LOCALBASE, be sure to set that before any packages are installed, as you can not use several directories @@ -1683,7 +1694,7 @@ properly detect your installed packages, and fail miserably. Note also that precompiled binary packages are usually built with the default LOCALBASE of - /usr/pkg, and that you should not + /usr/pkg, and that you should not install any if you use a non-standard LOCALBASE.

    @@ -1747,36 +1758,36 @@ 5.1. General configuration

    In this section, you can find some variables that apply to all pkgsrc packages. The preferred method of setting these variables - is by setting them in /etc/mk.conf. + is by setting them in /etc/mk.conf.

    • LOCALBASE: Where packages will be installed. The default is - /usr/pkg. Do not mix binary packages + /usr/pkg. Do not mix binary packages with different LOCALBASEs!

    • CROSSBASE: Where “cross” category packages will be installed. The default is - ${LOCALBASE}/cross.

      • + ${LOCALBASE}/cross.

    • X11BASE: Where X11 is installed on the system. The default is - /usr/X11R6.

      • + /usr/X11R6.

    • DISTDIR: Where to store the downloaded copies of the original source distributions used for building pkgsrc packages. The default is - ${PKGSRCDIR}/distfiles.

      • + ${PKGSRCDIR}/distfiles.

    • MASTER_SITE_OVERRIDE: If set, override the packages' MASTER_SITES with this value.

    • MASTER_SITE_BACKUP: Backup location(s) for distribution files and patch files if not found locally or in - ${MASTER_SITES} or - ${PATCH_SITES} respectively. + ${MASTER_SITES} or + ${PATCH_SITES} respectively. The defaults are - ftp://ftp.NetBSD.org/pub/NetBSD/packages/distfiles/${DIST_SUBDIR}/ + ftp://ftp.NetBSD.org/pub/NetBSD/packages/distfiles/${DIST_SUBDIR}/ and - ftp://ftp.freebsd.org/pub/FreeBSD/distfiles/${DIST_SUBDIR}/.

      • + ftp://ftp.freebsd.org/pub/FreeBSD/distfiles/${DIST_SUBDIR}/.

    • BINPKG_SITES: List of sites carrying binary pkgs.

    @@ -1791,14 +1802,14 @@

    • PACKAGES: The top level directory for the binary packages. The default is - ${PKGSRCDIR}/packages.

      • + ${PKGSRCDIR}/packages.

    • WRKOBJDIR: The top level directory where, if defined, the separate working directories will get created, and symbolically - linked to from ${WRKDIR} (see below). + linked to from ${WRKDIR} (see below). This is useful for building packages on several - architectures, then ${PKGSRCDIR} - can be NFS-mounted while ${WRKOBJDIR} + architectures, then ${PKGSRCDIR} + can be NFS-mounted while ${WRKOBJDIR} is local to every architecture. (It should be noted that PKGSRCDIR should not be set by the user — it is an internal definition which refers to the @@ -1812,11 +1823,11 @@ release (“2.0”, etc.) and architecture (“mipsel”, etc.).

    • PKGMAKECONF: Location of - the mk.conf file used by a package's + the mk.conf file used by a package's BSD-style Makefile. If this is not set, MAKECONF is set to - /dev/null to avoid picking up - settings used by builds in /usr/src.

      • + /dev/null to avoid picking up + settings used by builds in /usr/src.

    @@ -1858,7 +1869,7 @@

  • SKIP_AUDIT_PACKAGES: If this is set to “yes”, the automated security checks - (which use the security/audit-packages + (which use the security/audit-packages package) will be entirely skipped for all packages built. Normally you'll want to use ALLOW_VULNERABILITIES instead of this. @@ -1890,7 +1901,7 @@ These options are currently enabled: mozilla ssl

    The following variables can be defined in - /etc/mk.conf to select which options to enable + /etc/mk.conf to select which options to enable for a package: PKG_DEFAULT_OPTIONS, which can be used to select or disable options for all packages that support them, and PKG_OPTIONS.pkgbase, @@ -1921,12 +1932,12 @@ PKG_OPTIONS.apache= suexec

    Before the options framework was introduced, build options were selected by setting a variable (often named USE_FOO) in - /etc/mk.conf for each option. To ease transition + /etc/mk.conf for each option. To ease transition to the options framework for the user, these legacy variables are converted to the appropriate options setting (PKG_OPTIONS.pkgbase) automatically. A warning is issued to prompt the user to - update /etc/mk.conf to use the options framework + update /etc/mk.conf to use the options framework directly. Support for the legacy variables will be removed eventually.

    • @@ -1977,9 +1988,9 @@ PKG_OPTIONS.apache= suexec 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, in the form of a + /usr/pkgsrc/packages, in the form of a gzipped tar file. See Section B.2, “Packaging figlet” for a - continuation of the above misc/figlet example.

    + continuation of the above misc/figlet example.

    See Chapter 18, Submitting and Committing for information on how to submit such a binary package.

    @@ -2008,23 +2019,23 @@ PKG_OPTIONS.apache= suexec 6.3.1. Configuration

    -6.3.1.1. build.conf

    -

    The build.conf file is the main +6.3.1.1. build.conf

    +

    The build.conf 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 - pkgsrc/mk/bulk/build.conf-example. To use - it, copy build.conf-example to - build.conf and edit it, following the + pkgsrc/mk/bulk/build.conf-example. To use + it, copy build.conf-example to + build.conf and edit it, following the comments in that file.

    6.3.1.2. /etc/mk.conf

    You may want to set variables in - /etc/mk.conf. - Look at pkgsrc/mk/defaults/mk.conf for + /etc/mk.conf. + Look at pkgsrc/mk/defaults/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 @@ -2041,7 +2052,7 @@ PKG_OPTIONS.apache= suexec

    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 + mk/bulk/bsd.bulk-pkg.mk. The most useful options of these are briefly described here.

    • If you are on a slow machine, you may want to @@ -2068,11 +2079,11 @@ PKG_OPTIONS.apache= suexec build system from even trying to build them, so possible building errors would not show up.

    • CHECK_FILES - (pkgsrc/mk/bsd.pkg.check.mk) can be set to + (pkgsrc/mk/bsd.pkg.check.mk) can be set to “yes” to check that the installed set of files - matches the PLIST.

      • + matches the PLIST.

    • CHECK_INTERPRETER - (pkgsrc/mk/bsd.pkg.check.mk) can be set to + (pkgsrc/mk/bsd.pkg.check.mk) can be set to “yes” to check that the installed “#!”-scripts will find their interpreter.

      • @@ -2080,15 +2091,15 @@ PKG_OPTIONS.apache= suexec

    -6.3.1.3. pre-build.local

    +6.3.1.3. pre-build.local

    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 - pre-build.local exists in - /usr/pkgsrc/mk/bulk, it will be executed + pre-build.local exists in + /usr/pkgsrc/mk/bulk, it will be executed (as a sh(1) script) at the end of the usual pre-build stage. An example use of - pre-build.local is to have the line:

    + pre-build.local is to have the line:

    echo "I do not have enough disk space to build this pig." \
     > misc/openoffice/$BROKENF

    to prevent the system from trying to build a particular package @@ -2098,18 +2109,18 @@ PKG_OPTIONS.apache= suexec

    6.3.2. Other environmental considerations

    -

    As /usr/pkg will be completely +

    As /usr/pkg will be completely deleted at the start of bulk builds, make sure your login shell is placed somewhere else. Either drop it into - /usr/local/bin (and adjust your login + /usr/local/bin (and adjust your login shell in the passwd file), or (re-)install it via - pkg_add(1) from /etc/rc.local, so + pkg_add(1) from /etc/rc.local, so you can login after a reboot (remember that your current process won't die if the package is removed, you just can't start any new instances of the shell any more). Also, if you use NetBSD earlier than 1.5, or you still want to use the pkgsrc version of ssh for some reason, be sure to install ssh before - starting it from rc.local:

    + starting it from rc.local:

         ( cd /usr/pkgsrc/security/ssh ; make bulk-install )
     if [ -f /usr/pkg/etc/rc.d/sshd ]; then
@@ -2133,7 +2144,7 @@ PKG_OPTIONS.apache=     suexec

    Be sure to remove all other things that might interfere with builds, like some libs installed in - /usr/local, etc. then become root and type:

    + /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 @@ -2143,7 +2154,7 @@ PKG_OPTIONS.apache= suexec

    At the end of the bulk build, you will get a summary via mail, and find build logs in the directory specified by - FTP in the build.conf + FTP in the build.conf file.

    @@ -2168,15 +2179,15 @@ PKG_OPTIONS.apache= suexec
    3. post-build

    Generates a report that's placed in the directory - specified in the build.conf file - named broken.html, a short version + specified in the build.conf file + named broken.html, a short version of that report will also be mailed to the build's admin.

    During the build, a list of broken packages will be compiled - in /usr/pkgsrc/.broken (or - .../.broken.${MACHINE} if + in /usr/pkgsrc/.broken (or + .../.broken.${MACHINE} if OBJMACHINE 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 @@ -2221,14 +2232,14 @@ PKG_OPTIONS.apache= suexec

    The first step is to set up a chroot sandbox, - e.g. /usr/sandbox. This can be done by + e.g. /usr/sandbox. This can be done by using null mounts, or manually.

    There is a shell script called - pkgsrc/mk/bulk/mksandbox which will set + pkgsrc/mk/bulk/mksandbox which will set up the sandbox environment using null mounts. It will also - create a script called sandbox in the + create a script called sandbox in the root of the sandbox environment, which will allow the null mounts to be activated using the sandbox mount command and deactivated using the @@ -2238,7 +2249,7 @@ PKG_OPTIONS.apache= suexec To set up a sandbox environment by hand, after extracting all the sets from a NetBSD installation or doing a make distribution DESTDIR=/usr/sandbox in - /usr/src/etc, be sure the following items + /usr/src/etc, be sure the following items are present and properly configured:

      @@ -2247,11 +2258,11 @@ PKG_OPTIONS.apache= suexec 
      # cp /netbsd /usr/sandbox
    1. -

      /dev/*

      +

      /dev/*

      # cd /usr/sandbox/dev ; sh MAKEDEV all
    2. -

      /etc/resolv.conf (for security/smtpd and mail):

      +

      /etc/resolv.conf (for security/smtpd and mail):

      # cp /etc/resolv.conf /usr/sandbox/etc
    3. @@ -2259,26 +2270,26 @@ PKG_OPTIONS.apache= suexec 
      # cp /etc/mail/sendmail.cf /usr/sandbox/etc/mail
    4. -

      /etc/localtime (for security/smtpd):

      +

      /etc/localtime (for security/smtpd):

      # ln -sf /usr/share/zoneinfo/UTC /usr/sandbox/etc/localtime
    5. -

      /usr/src (system sources, - e. g. for sysutils/aperture):

      +

      /usr/src (system sources, + e. g. for sysutils/aperture):

      # ln -s ../disk1/cvs .
 # ln -s cvs/src-2.0 src
    6. -

      Create /var/db/pkg (not part of default install):

      +

      Create /var/db/pkg (not part of default install):

      # mkdir /usr/sandbox/var/db/pkg
    7. -

      Create /usr/pkg (not part of default install):

      +

      Create /usr/pkg (not part of default install):

      # mkdir /usr/sandbox/usr/pkg

    8. Checkout pkgsrc via cvs into - /usr/sandbox/usr/pkgsrc:

      + /usr/sandbox/usr/pkgsrc:

      # 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 @@ -2286,12 +2297,12 @@ PKG_OPTIONS.apache= suexec

    9. Make - /usr/sandbox/usr/pkgsrc/packages and - .../distfiles point somewhere + /usr/sandbox/usr/pkgsrc/packages and + .../distfiles point somewhere appropriate. NFS- and/or nullfs-mounts may come in handy!

      10. -

    10. Edit /etc/mk.conf, see Section 6.3.1.2, “/etc/mk.conf”.

      11. -

    11. Adjust mk/bulk/build.conf to suit your needs.

      12. +

    12. Edit /etc/mk.conf, see Section 6.3.1.2, “/etc/mk.conf”.

      13. +

    13. Adjust mk/bulk/build.conf to suit your needs.

    When the chroot sandbox is set up, you can start the build with the following steps:

    @@ -2301,17 +2312,17 @@ PKG_OPTIONS.apache= suexec 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 + /usr/sandbox/usr/pkgsrc/packages (wherever that points/mounts to/from).

    6.3.7. Building a partial set of packages

    In addition to building a complete set of all packages in - pkgsrc, the pkgsrc/mk/bulk/build script + pkgsrc, the pkgsrc/mk/bulk/build script may be used to build a subset of the packages contained in pkgsrc. By setting SPECIFIC_PKGS - in /etc/mk.conf, the variables

    + in /etc/mk.conf, the variables

    • SITE_SPECIFIC_PKGS

    • HOST_SPECIFIC_PKGS

      • @@ -2339,18 +2350,18 @@ PKG_OPTIONS.apache= suexec If you would like to automatically create checksum files for the binary packages you intend to upload, remember to set MKSUMS=yes in your - mk/bulk/build.conf. + mk/bulk/build.conf.

      If you would like to PGP sign the checksum files (highly recommended!), remember to set SIGN_AS=username@NetBSD.org in your - mk/bulk/build.conf. This will prompt you for + mk/bulk/build.conf. This will prompt you for your GPG password to sign the files before uploading everything.

      Then, make sure that you have RSYNC_DST - set properly in your mk/bulk/build.conf + set properly in your mk/bulk/build.conf file, i.e. adjust it to something like one of the following: 

      RSYNC_DST=ftp.NetBSD.org:/pub/NetBSD/packages/pkgsrc-200xQy/NetBSD-a.b.c/arch/upload
      @@ -2361,16 +2372,16 @@ PKG_OPTIONS.apache= suexec login "hubertf", I use:

      RSYNC_DST=hubertf@ftp.NetBSD.org:/pub/NetBSD/packages/pkgsrc-200xQy/NetBSD-a.b.c/arch/upload

      - A separate upload directory is used + A separate upload directory is used here to allow "closing" the directory during upload. To do so, run the following command on ftp.NetBSD.org next: 

      nbftp% mkdir -p -m 750 /pub/NetBSD/packages/pkgsrc-200xQy/NetBSD-a.b.c/arch/upload

      - Please note that /pub/NetBSD/packages is + Please note that /pub/NetBSD/packages is only appropriate for packages for the NetBSD operating system. Binary packages for other operating systems should go - into /pub/pkgsrc. + into /pub/pkgsrc.

      Before uploading the binary pkgs, ssh authentication needs to @@ -2383,8 +2394,8 @@ chroot-# rm $HOME/.s 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 + 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!

      @@ -2407,7 +2418,7 @@ chroot-# cat $HOME/. 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 - vulnerable subdirectory. + vulnerable subdirectory.

      After the upload has ended, first thing is to revoke ssh access: @@ -2417,7 +2428,7 @@ 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 + upload directory to have them accessible to everyone: 

      nbftp% cd /pub/NetBSD/packages/pkgsrc-200xQy/NetBSD-a.b.c/arch
@@ -2433,7 +2444,7 @@ nbftp% chmod 755 .
      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 - pkgtools/cdpack package provides + pkgtools/cdpack package provides a simple tool for creating the ISO 9660 images. cdpack arranges the packages on the CD-ROMs in a way that keeps all the dependencies for a given package on the same @@ -2446,15 +2457,15 @@ nbftp% chmod 755 . Complete documentation for cdpack is found in the cdpack(1) man page. The following short example assumes that the binary packages are left in - /usr/pkgsrc/packages/All and that - sufficient disk space exists in /u2 to + /usr/pkgsrc/packages/All and that + sufficient disk space exists in /u2 to hold the ISO 9660 images.

      # mkdir /u2/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, + (COPYRIGHT, README, etc.) on each CD in the collection, then you need to create a directory which contains these files. e.g.

      @@ -2467,8 +2478,8 @@ nbftp% chmod 755 . # chmod 755 /tmp/common/bin/myscript

      Now create the images:

      # cdpack -x /tmp/common /usr/pkgsrc/packages/All /u2/images
      -

      Each image will contain README, - COPYING, and bin/myscript +

      Each image will contain README, + COPYING, and bin/myscript in their root directories.

    @@ -2550,83 +2561,83 @@ it contains items for both pkgsrc users and developers.

    7.2. Where's the pkgviews documentation?

    Pkgviews is tightly integrated with buildlink. You can find a pkgviews User's guide in -pkgsrc/mk/buildlink3/PKGVIEWS_UG.

    +pkgsrc/mk/buildlink3/PKGVIEWS_UG.

    7.3. Utilities for package management (pkgtools)

    -

    The pkgsrc/pkgtools directory pkgtools contains +

    The pkgsrc/pkgtools directory pkgtools contains a number of useful utilities for both users and developers of pkgsrc. This section attempts only to make the reader aware of the utilities and when they might be useful, and not to duplicate the documentation that comes with each package.

    Utilities used by pkgsrc (automatically installed when needed):

    -
    @@ -2646,7 +2657,7 @@ them by setting UNPRIVILEGED_USER and

    As regards bootstrapping, please note that the bootstrap script will ease non-root configuration when given the “--ignore-user-check” flag, as it will choose and -use multiple default directories under ~/pkg as the +use multiple default directories under ~/pkg as the installation targets. These directories can be overriden by the “--prefix” flag provided by the script, as well as some others that allow finer tuning of the tree layout.

    @@ -2657,7 +2668,7 @@ that allow finer tuning of the tree layout.

    By default, resuming transfers in pkgsrc is disabled, but you can enable this feature by adding the option PKG_RESUME_TRANSFERS=YES into -/etc/mk.conf. If, during a fetch step, an incomplete +/etc/mk.conf. If, during a fetch step, an incomplete distfile is found, pkgsrc will try to resume it.

    You can also use a different program than the default ftp(1) by changing the @@ -2666,7 +2677,7 @@ use a different program than the default FETCH_OUTPUT_ARGS if you are not using default values.

    For example, if you want to use -wget to resume downloads, you'll have to use something +wget to resume downloads, you'll have to use something like:

         FETCH_CMD=             wget
@@ -2679,9 +2690,9 @@ like:
    
 
    
 7.6. How can I install/use XFree86 from pkgsrc?
    
 
    If you want to use XFree86 from pkgsrc instead of your system's own
-X11 (/usr/X11R6, /usr/openwin,
+X11 (/usr/X11R6, /usr/openwin,
 ...), you will have to add the following line into
-/etc/mk.conf:
    
+/etc/mk.conf:
    
 
         X11_TYPE=XFree86
 
    
@@ -2690,9 +2701,9 @@ X11 (/us
 
    
 7.7. How can I install/use X.org from pkgsrc?
    
 
    If you want to use X.org from pkgsrc instead of your system's own X11
-(/usr/X11R6, /usr/openwin, ...)
+(/usr/X11R6, /usr/openwin, ...)
 you will have to add the following line into
-/etc/mk.conf:
    
+/etc/mk.conf:
    
 
         X11_TYPE=xorg
 
    
@@ -2722,20 +2733,20 @@ are:
    
 
    
 7.9. How do I tell make fetch to do passive FTP?
    
 
    This depends on which utility is used to retrieve distfiles.  From
-bsd.pkg.mk, FETCH_CMD is assigned
+bsd.pkg.mk, FETCH_CMD is assigned
 the first available command from the following list:
    
 
      
-
    • ${LOCALBASE}/bin/ftp
      • 
-
    • /usr/bin/ftp
      • 
+
    • ${LOCALBASE}/bin/ftp
      • 
+
    • /usr/bin/ftp
      • 
 
    
 
    On a default NetBSD installation, this will be
-/usr/bin/ftp, which automatically tries passive
+/usr/bin/ftp, which automatically tries passive
 connections first, and falls back to active connections if the server
 refuses to do passive.  For the other tools, add the following to your
-/etc/mk.conf file:
+/etc/mk.conf file:
 PASSIVE_FETCH=1.
    
 
    Having that option present will prevent
-/usr/bin/ftp from falling back to active
+/usr/bin/ftp from falling back to active
 transfers.
    @@ -2746,7 +2757,7 @@ work or university, where you can't run a make fet There is an archive of distfiles on ftp.NetBSD.org, but downloading the entire directory may not be appropriate.

    The answer here is to do a make fetch-list in -/usr/pkgsrc or one of its subdirectories, carry the +/usr/pkgsrc or one of its subdirectories, carry the resulting list to your machine at work/school and use it there. If you don't have a NetBSD-compatible ftp(1) (like tnftp) at work, don't forget to set FETCH_CMD to something that fetches a @@ -2757,7 +2768,7 @@ URL:

    % scp /tmp/fetch.sh work:/tmp

    At work:

    % sh /tmp/fetch.sh
    -

    then tar up /tmp/distfiles and take it +

    then tar up /tmp/distfiles and take it home.

    If you have a machine running NetBSD, and you want to get all distfiles (even ones that aren't for your machine @@ -2774,25 +2785,25 @@ by running:

    7.11. What does “Don't know how to make /usr/share/tmac/tmac.andoc” mean?

    -

    When compiling the pkgtools/pkg_install +

    When compiling the pkgtools/pkg_install package, you get the error from make that it doesn't know how to make -/usr/share/tmac/tmac.andoc? This indicates that +/usr/share/tmac/tmac.andoc? This indicates that you don't have installed the “text” set (nroff, ...) from the NetBSD base distribution on your machine. It is recommended to do that to format man pages.

    -

    In the case of the pkgtools/pkg_install package, you +

    In the case of the pkgtools/pkg_install package, you can get away with setting NOMAN=YES either in the -environment or in /etc/mk.conf.

    +environment or in /etc/mk.conf.

    7.12. What does “Could not find bsd.own.mk” mean?

    -

    You didn't install the compiler set, comp.tgz, +

    You didn't install the compiler set, comp.tgz, when you installed your NetBSD machine. Please get and install it, by -extracting it in /:

    +extracting it in /:

    # cd /
 # tar --unlink -zxvpf .../comp.tgz
    -

    comp.tgz is part of every NetBSD release. Get +

    comp.tgz is part of every NetBSD release. Get the one that corresponds to your release (determine via uname -r).

    @@ -2804,8 +2815,8 @@ the one that corresponds to your release (determine via security/sudo) and then put the following -into your /etc/mk.conf:

    +security/sudo) and then put the following +into your /etc/mk.conf:

         .if exists(${LOCALBASE}/bin/sudo)
     SU_CMD=        ${LOCALBASE}/bin/sudo /bin/sh -c
@@ -2817,15 +2828,15 @@ into your 7.14. How do I change the location of configuration files?
 
    As the system administrator, you can choose where configuration files
 are installed.  The default settings make all these files go into
-${PREFIX}/etc or some of its subdirectories; this may
+${PREFIX}/etc or some of its subdirectories; this may
 be suboptimal depending on your expectations (e.g., a read-only,
 NFS-exported PREFIX with a need of per-machine
 configuration of the provided packages).
    
 
    In order to change the defaults, you can modify the
 PKG_SYSCONFBASE variable (in
-/etc/mk.conf) to point to your preferred configuration
-directory; some common examples include /etc or
-/etc/pkg.
    
+/etc/mk.conf) to point to your preferred configuration
+directory; some common examples include /etc or
+/etc/pkg.
    
 
    Furthermore, you can change this value on a per-package basis by
 setting the PKG_SYSCONFDIR.${PKG_SYSCONFVAR} variable.
 PKG_SYSCONFVAR's value usually matches the name of the
@@ -2843,7 +2854,7 @@ attackers.  In an effort to lessen the exposure, the NetBSD packages team
 maintains a database of known-exploits to packages which have at one time
 been included in pkgsrc.  The database can be downloaded automatically, and
 a security audit of all packages installed on a system can take place.  To
-do this, install the security/audit-packages package.  It has two
+do this, install the security/audit-packages package.  It has two
 components:
    
 
      
 
    1. 
@@ -2859,7 +2870,7 @@ components:
      
     including a description of the type of vulnerability, and a URL
     containing more information.
      2. 
 
    
-
    Use of the security/audit-packages
+
    Use of the security/audit-packages
 package is strongly recommended!  After
 “audit-packages” is installed, please read
 the package's message, which you can get by running pkg_info -D
@@ -2874,17 +2885,17 @@ a security check before building any package.  See
 7.16. Why do some packages ignore my CFLAGS?
 
    When you add your own preferences to the
 	CFLAGS variable in your
-	mk.conf, these flags are passed in
-	environment variables to the ./configure
+	mk.conf, these flags are passed in
+	environment variables to the ./configure
 	scripts and to make(1). Some package authors ignore the
 	CFLAGS from the environment variable by
-	overriding them in the Makefiles of their
+	overriding them in the Makefiles of their
 	package.
    
 
    Currently there is no solution to this problem. If you
 	really need the package to use your CFLAGS
 	you should run make patch in the package
-	directory and then inspect any Makefile and
-	Makefile.in for whether they define
+	directory and then inspect any Makefile and
+	Makefile.in for whether they define
 	CFLAGS explicitly. Usually you can remove
 	these lines. But be aware that some “smart”
 	programmers write so bad code that it only works for the
@@ -2901,17 +2912,17 @@ a security check before building any package.  See
 
    
 
    8. Package components - files, directories and contents
    
 
    
-
    8.1. Makefile
    
-
    8.2. distinfo
    
+
    8.1. Makefile
    
+
    8.2. distinfo
    
 
    8.3. patches/*
    
 
    8.4. Other mandatory files
    
 
    8.5. Optional files
    
-
    8.6. work*
    
-
    8.7. files/*
    
+
    8.6. work*
    
+
    8.7. files/*
    
 
    
-
    9. Programming in Makefiles
    
+
    9. Programming in Makefiles
    
 
    
-
    9.1. Makefile variables
    
+
    9.1. Makefile variables
    
 
    9.1.1. Naming conventions
    
 
    9.2. Code snippets
    
 
    
@@ -2925,7 +2936,7 @@ a security check before building any package.  See
 
    10. PLIST issues
    
 
    
 
    10.1. RCS ID
    
-
    10.2. Semi-automatic PLIST generation
    
+
    10.2. Semi-automatic PLIST generation
    
 
    10.3. Tweaking output of make print-PLIST
    
 
    10.4. Variable substitution in PLIST
    
 
    10.5. Man page compression
    
@@ -2936,14 +2947,14 @@ a security check before building any package.  See
 
    11. Buildlink methodology
    
 
    
 
    11.1. Converting packages to use buildlink3
    
-
    11.2. Writing buildlink3.mk files
    
+
    11.2. Writing buildlink3.mk files
    
 
    
 
    11.2.1. Anatomy of a buildlink3.mk file
    
-
    11.2.2. Updating BUILDLINK_API_DEPENDS.pkg in buildlink3.mk files
    
+
    11.2.2. Updating BUILDLINK_API_DEPENDS.pkg in buildlink3.mk files
    
 
    
-
    11.3. Writing builtin.mk files
    
+
    11.3. Writing builtin.mk files
    
 
    
-
    11.3.1. Anatomy of a builtin.mk file
    
+
    11.3.1. Anatomy of a builtin.mk file
    
 
    11.3.2. Global preferences for native or pkgsrc software
    
 
    
 
    
@@ -2972,7 +2983,7 @@ a security check before building any package.  See
 
    13. Options handling
    
 
    
 
    13.1. Global default options
    
-
    13.2. Converting packages to use bsd.options.mk
    
+
    13.2. Converting packages to use bsd.options.mk
    
 
    13.3. Option Names
    
 
    
 
    14. The build process
    
@@ -3074,13 +3085,13 @@ a security check before building any package.  See
 
    
 
    Table of Contents
    
 
    
-
    8.1. Makefile
    
-
    8.2. distinfo
    
+
    8.1. Makefile
    
+
    8.2. distinfo
    
 
    8.3. patches/*
    
 
    8.4. Other mandatory files
    
 
    8.5. Optional files
    
-
    8.6. work*
    
-
    8.7. files/*
    
+
    8.6. work*
    
+
    8.7. files/*
    
 
    
 
    
 
      Whenever you're preparing a package, there are a number of
@@ -3088,14 +3099,14 @@ a security check before building any package.  See
     sections. 
    
 
    
 
    
-8.1. Makefile
    
+8.1. Makefile
    
 
    Building, installation and creation of a binary package are all
-      controlled by the package's Makefile.
-      The Makefile describes various things about
+      controlled by the package's Makefile.
+      The Makefile describes various things about
       a package, for example from where to get it, how to configure,
       build, and install it.
     
    
-
    A package Makefile contains several
+
    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.
@@ -3184,7 +3195,7 @@ a security check before building any package.  See
 
  • 
 
    DISTFILES: Name(s)
 	    of archive file(s) containing distribution. The default is
-	    ${DISTNAME}${EXTRACT_SUFX}. Should only
+	    ${DISTNAME}${EXTRACT_SUFX}. Should only
 	    be set if you have more than one distfile.
    
 
    Note that the normal default setting of
 	    DISTFILES must be made explicit if you
@@ -3194,7 +3205,7 @@ a security check before building any package.  See
 
  • EXTRACT_SUFX: Suffix of the
 	    distribution file, will be appended to
 	    DISTNAME. Defaults to
-	    .tar.gz.
+	    .tar.gz.
 	  
    • 
 
 
    
@@ -3208,8 +3219,8 @@ a security check before building any package.  See
 	  There is no default. pkgsrc will look for them at
 	  PATCH_SITES.
 	  They will automatically be uncompressed before patching if
-	  the names end with .gz or
-	  .Z.
    
+	  the names end with .gz or
+	  .Z.
    
 
  • PATCH_SITES:
 	  Primary location(s) for distribution patch files (see
 	  PATCHFILES below) if not found locally.
    • 
@@ -3241,7 +3252,7 @@ a security check before building any package.  See
 
    • 
 
      WRKSRC: The directory where the
 	  interesting distribution files of the package are found. The
-	  default is ${WRKDIR}/${DISTNAME}, which
+	  default is ${WRKDIR}/${DISTNAME}, which
 	  works for most packages.
      
 
      If a package doesn't create a subdirectory for itself
 	  (most GNU software does, for instance), but extracts itself in
@@ -3250,21 +3261,21 @@ a security check before building any package.  See
 
      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 other examples.
      
+	  ${WRKDIR}, 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 WRKDIR_BASENAME variable. By
-	  default, its value is work. If you want
+	  default, its value is work. 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
 	  WRKDIR_BASENAME individually. If
 	  OBJHOSTNAME is defined in
-	  /etc/mk.conf, the first component of the
+	  /etc/mk.conf, the first component of the
 	  host's name is attached to the directory name. If
 	  OBJMACHINE is defined, the platform name is
-	  attached, which might look like work.i386
-	  or work.sparc.
      
+	  attached, which might look like work.i386
+	  or work.sparc.
      
 
    
 
    
     
    
@@ -3272,8 +3283,8 @@ a security check before building any package.  See
 
      
 
    • Add MANCOMPRESSED if man pages are installed in
           compressed form by the package; see comment in
-          bsd.pkg.mk.
      • 
-
    • Replace /usr/local with
+          bsd.pkg.mk.
      • 
+
    • Replace /usr/local with
           “${PREFIX}” in all files (see patches, below).
      • 
 
    • If the package installs any info files, see
           Section 16.5.7, “Packages installing info files”.
      • 
@@ -3281,23 +3292,23 @@ a security check before building any package.  See
 
    
 
    
 
    
-8.2. distinfo
    
-
    The distinfo file contains the message
+8.2. distinfo
    
+
    The distinfo file contains the message
     digest, or checksum, of each distfile needed for the package. This
     ensures that the distfiles retrieved from the 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.
    
-
    The distinfo file also contains the
+
    The distinfo file also contains the
     checksums for all the patches found in the
-    patches directory (see Section 8.3, “patches/*”).
    
-
    To regenerate the distinfo file, use the
+    patches directory (see Section 8.3, “patches/*”).
    
+
    To regenerate the distinfo file, use the
     make makedistinfo or make mdi
     command.
    
 
    Some packages have different sets of distfiles depending on
-    the platform, for example www/navigator). These are kept in the same
-    distinfo file and care should be taken when
+    the platform, for example www/navigator). These are kept in the same
+    distinfo file and care should be taken when
     upgrading such a package to ensure distfile information is not
     lost.
    
 
@@ -3310,9 +3321,9 @@ a security check before building any package.  See
       that will compile and run perfectly on NetBSD. The files are applied
       successively in alphabetic order (as returned by a shell
       “patches/patch-*” glob expansion), so
-      patch-aa is applied before
-      patch-ab, etc.
    
-
    The patch-* files should be in
+      patch-aa is applied before
+      patch-ab, etc.
    
+
    The patch-* files should be in
       diff -bu format, and apply without a fuzz to avoid
       problems. (To force patches to apply
       with fuzz you can set PATCH_FUZZ_FACTOR=-F2).
@@ -3325,18 +3336,18 @@ a security check before building any package.  See
       get stored in the patch files, as these will cause problems when
       later checked into the NetBSD CVS tree. Use the
       pkgdiff from the
-      pkgtools/pkgdiff package to avoid
+      pkgtools/pkgdiff package to avoid
       these problems.
    
 
    For even more automation, we recommend using mkpatches from the same
       package to make a whole set of patches. You just have to backup files
-      before you edit them to filename.orig, e.g. with
+      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.
    
 
    When you have finished a package, remember to generate the checksums
       for the patch files by using the make makepatchsum
-      command, see Section 8.2, “distinfo”.
    
+      command, see Section 8.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
@@ -3347,14 +3358,14 @@ a security check before building any package.  See
       $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
+      $LOCALPATCHES
       directory. The directory tree there is expected to have the same
       “category/package” structure as pkgsrc, and patches are
       expected to be stored inside these dirs (also known as
-      $LOCALPATCHES/$PKGPATH). For
+      $LOCALPATCHES/$PKGPATH). For
       example, if you want to keep a private patch for
-      pkgsrc/graphics/png, keep
-      it in $LOCALPATCHES/graphics/png/mypatch. All
+      pkgsrc/graphics/png, keep
+      it in $LOCALPATCHES/graphics/png/mypatch. All
       files in the named directory are expected to be patch files, and
       they are applied after pkgsrc patches are applied.
    
 
@@ -3362,12 +3373,12 @@ a security check before building any package.  See
 
    
 8.4. Other mandatory files
    
 
    
-
    DESCR
    
+
    DESCR
    
 
    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.
    
-
    PLIST
    
+
    PLIST
    
 
    
             This file governs the files that are installed on your system: all the
             binaries, manual pages, etc. There are other directives which may be
@@ -3380,22 +3391,22 @@ a security check before building any package.  See
 
    
 8.5. Optional files
    
 
    
-
    INSTALL
    
+
    INSTALL
    
 
    This shell script is invoked twice by pkg_add(1).
             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
-            PLIST. See
+            PLIST. See
             pkg_add(1) and pkg_create(1) for more information.
    
-
    DEINSTALL
    
+
    DEINSTALL
    
 
    This script is executed before and after any files are removed.  It is
             this script's responsibility to clean up any additional messy details
             around the package's installation, since all pkg_delete knows is how to
             delete the files created in the original distribution.
             See pkg_delete(1)
             and pkg_create(1) for more information.
    
-
    MESSAGE
    
+
    MESSAGE
    
 
    
 
    This file is displayed after installation of the package.
             Useful for things like legal notices on almost-free
@@ -3403,47 +3414,47 @@ a security check before building any package.  See
             installing modules for apache, PHP etc.
             Please note that you can modify variables in it easily by using
             MESSAGE_SUBST in the package's
-            Makefile:
    
+            Makefile:
    
 
         MESSAGE_SUBST+=  SOMEVAR="somevalue"
 
    
 
    replaces "${SOMEVAR}" with “somevalue” in
-            MESSAGE.
    
+            MESSAGE.
    
 
    
 
    
 
    
 
    
 
    
-8.6. work*
    
+8.6. work*
    
 
    When you type make, the distribution files are
       unpacked into the directory denoted by
       WRKDIR. It can be removed by running
       make clean. Besides the sources, this
       directory is also used to keep various timestamp files.
       The directory gets removed completely on clean.
-      The default is ${.CURDIR}/work
-      or ${.CURDIR}/work.${MACHINE_ARCH}
+      The default is ${.CURDIR}/work
+      or ${.CURDIR}/work.${MACHINE_ARCH}
       if OBJMACHINE is set.
    
 
 
    
 
    
-8.7. files/*
    
+8.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}” 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
+      /dev/null and use the patch mechanism to manage
       the creation of this file.
    
 
 
 
    
 
    
-Chapter 9. Programming in Makefiles
    
+Chapter 9. Programming in Makefiles
    
 
    
 
    Table of Contents
    
 
    
-
    9.1. Makefile variables
    
+
    9.1. Makefile variables
    
 
    9.1.1. Naming conventions
    
 
    9.2. Code snippets
    
 
    
@@ -3455,29 +3466,29 @@ a security check before building any package.  See
 
    
 
    
 
    
-
    Pkgsrc consists of many Makefile fragments,
+
    Pkgsrc consists of many Makefile fragments,
   each of which forms a well-defined part of the pkgsrc system. Using
   the make(1) system as a programming language for a big system
   like pkgsrc requires some discipline to keep the code correct and
   understandable.
    
-
    The basic ingredients for Makefile
+
    The basic ingredients for Makefile
   programming are variables (which are actually macros) and shell
   commands. Among these shell commands may even be more complex ones
   like awk(1) programs. To make sure that every shell command runs
   as intended it is necessary to quote all variables correctly when they
   are used.
    
 
    This chapter describes some patterns, that appear quite often in
-  Makefiles, including the pitfalls that come along
+  Makefiles, including the pitfalls that come along
   with them.
    
 
    
 
    
-9.1. Makefile variables
    
-
    Makefile variables contain strings that
+9.1. Makefile variables
    
+
    Makefile variables contain strings that
     can be processed using the five operators ``='', ``+='', ``?='',
     ``:='', and ``!='', which are described in the make(1) man
     page.
    
 
    When a variable's value is parsed from a
-    Makefile, the hash character ``#'' and the
+    Makefile, the hash character ``#'' and the
     backslash character ``\'' are handled specially. If a backslash is
     followed by a newline, any whitespace immediately in front of the
     backslash, the backslash, the newline, and any whitespace
@@ -3534,7 +3545,7 @@ a security check before building any package.  See
 
  • All variable names starting with an underscore
 	are reserved for use by the pkgsrc infrastructure. They shall
 	not be used by package
-	Makefiles.
    • 
+	Makefiles.
    
 
  • In .for loops you should use
 	lowercase variable names for the iteration
 	variables.
    • 
@@ -3717,7 +3728,7 @@ a security check before building any package.  See
     VAR:=   ${VAR:N${_othervar_:C/-//}}

    For a more complex code snippet and a workaround, see the - package regress/make-quoting, testcase + package regress/make-quoting, testcase bug1.

    @@ -3729,7 +3740,7 @@ a security check before building any package. See

    Table of Contents

    10.1. RCS ID
    -
    10.2. Semi-automatic PLIST generation
    +
    10.2. Semi-automatic PLIST generation
    10.3. Tweaking output of make print-PLIST
    10.4. Variable substitution in PLIST
    10.5. Man page compression
    @@ -3738,20 +3749,20 @@ a security check before building any package. See
    10.8. Sharing directories between packages
    -

    The PLIST file contains a package's +

    The PLIST file contains a package's “packing list”, i.e. a list of files that belong to - the package (relative to the ${PREFIX} + the package (relative to the ${PREFIX} directory it's been installed in) plus some additional statements - see the pkg_create(1) man page for a full list. This chapter addresses some issues that need attention when - dealing with the PLIST file (or files, see + dealing with the PLIST file (or files, see below!).

    10.1. RCS ID

    Be sure to add a RCS ID line as the first thing in any - PLIST file you write: + PLIST file you write: 

         @comment $NetBSD$
@@ -3759,7 +3770,7 @@ a security check before building any package.  See

    -10.2. Semi-automatic PLIST generation

    +10.2. Semi-automatic PLIST generation

    You can use the make print-PLIST command to output a PLIST that matches any new files since the package was extracted. See Section 14.16, “Other helpful targets” for @@ -3781,7 +3792,7 @@ a security check before building any package. See print-PLIST. You can append any chunk of AWK scripting you like to it, but be careful with quoting.

    For example, to get all files inside the - libdata/foo directory removed from the + libdata/foo directory removed from the resulting PLIST:

         PRINT_PLIST_AWK+=       /^libdata\/foo/ { next; }
@@ -3827,7 +3838,7 @@ a security check before building any package.  See
 
    
 
    Some packages want to embed the OS name and version
             into some paths.  To do this, use these variables in the
-            PLIST:
+            PLIST:
           
    
 
      
 
    • ${OPSYS} - output of “uname -s”
      • 
@@ -3837,7 +3848,7 @@ a security check before building any package.  See
 
    
 
 
     For a complete list of values which are replaced by
-      default, please look in bsd.pkg.mk (and
+      default, please look in bsd.pkg.mk (and
       search for PLIST_SUBST). 
    
 
     If you want to change other variables not listed above, you
       can add variables and their expansions to this variable in the
@@ -3852,19 +3863,19 @@ a security check before building any package.  See
 
    
 10.5. Man page compression
    
 
    Man pages should be installed in compressed form if
-      MANZ is set (in bsd.own.mk),
+      MANZ is set (in bsd.own.mk),
       and uncompressed otherwise. To handle this in the
-      PLIST file, the suffix “.gz” is
+      PLIST file, the suffix “.gz” is
       appended/removed automatically for man pages according to
       MANZ and MANCOMPRESSED being set
       or not, see above for details. This modification of the
-      PLIST file is done on a copy of it, not
-      PLIST itself.
    
+      PLIST file is done on a copy of it, not
+      PLIST itself.
    
 
 
    
 
    
 10.6. Changing PLIST source with PLIST_SRC
    
-
    To use one or more files as source for the PLIST used
+
    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
@@ -3877,11 +3888,11 @@ a security check before building any package.  See
       the operating system being used. These differences can be
       automatically handled by using the following files:
    
 
      
-
    • PLIST.common
      • 
-
    • PLIST.${OPSYS}
      • 
-
    • PLIST.${MACHINE_ARCH}
      • 
-
    • PLIST.${OPSYS}-${MACHINE_ARCH}
      • 
-
    • PLIST.common_end
      • 
+
    • PLIST.common
      • 
+
    • PLIST.${OPSYS}
      • 
+
    • PLIST.${MACHINE_ARCH}
      • 
+
    • PLIST.${OPSYS}-${MACHINE_ARCH}
      • 
+
    • PLIST.common_end
      • 
 
    
 
    
 
    
@@ -3906,9 +3917,9 @@ a security check before building any package.  See
 
      
 
    1.  If the packages have a common dependency, the directory
           can be removed in that.  For example, see
-          textproc/scrollkeeper, which
+          textproc/scrollkeeper, which
 	  removes the shared directory
-	  share/omf. 
      2. 
+	  share/omf. 
      
 
    2.  If the packages using the directory are not related at
           all (they have no common dependencies), a *-dirs package is
           used. 
      3. 
@@ -3925,7 +3936,7 @@ a security check before building any package.  See
       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
+      share/applications, it should have the
       following line in it:
       
      
 
      @@ -3935,9 +3946,9 @@ a security check before building any package.  See
       print-PLIST, you should get the right (commented out)
       lines. 
      
 
       Note that even if your package is using
-      $X11BASE, it must not depend on the
+      $X11BASE, it must not depend on the
       *-x11-dirs packages.  Just specify the name without that part and
-      pkgsrc (in particular, mk/dirs.mk) will take
+      pkgsrc (in particular, mk/dirs.mk) will take
       care of it. 
      
 
    
 
    
@@ -3948,14 +3959,14 @@ a security check before building any package.  See
 
    Table of Contents
    
 
    
 
    11.1. Converting packages to use buildlink3
    
-
    11.2. Writing buildlink3.mk files
    
+
    11.2. Writing buildlink3.mk files
    
 
    
 
    11.2.1. Anatomy of a buildlink3.mk file
    
-
    11.2.2. Updating BUILDLINK_API_DEPENDS.pkg in buildlink3.mk files
    
+
    11.2.2. Updating BUILDLINK_API_DEPENDS.pkg in buildlink3.mk files
    
 
    
-
    11.3. Writing builtin.mk files
    
+
    11.3. Writing builtin.mk files
    
 
    
-
    11.3.1. Anatomy of a builtin.mk file
    
+
    11.3.1. Anatomy of a builtin.mk file
    
 
    11.3.2. Global preferences for native or pkgsrc software
    
 
    
 
    
@@ -3978,8 +3989,8 @@ a security check before building any package.  See
 
    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. /usr/include,
-    /usr/lib, etc., are always searched -- buildlink3 is
+    e.g. /usr/include,
+    /usr/lib, etc., are always searched -- buildlink3 is
     designed to insulate the package build from non-system-supplied
     software. 
    
 
    
@@ -3992,16 +4003,16 @@ a security check before building any package.  See
 
  •  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
-          ${WRKDIR}/.work.log to see if the
+          ${WRKDIR}/.work.log to see if the
           wrappers are being invoked. 
    • 
 
  •  Don't override PREFIX from within
           the package Makefile, e.g. Java VMs, standalone shells,
           etc., because the code to symlink files into
-          ${BUILDLINK_DIR} looks for files
+          ${BUILDLINK_DIR} looks for files
           relative to “pkg_info -qp pkgname”.
 	  
    • 
 
  •  Remember that only the
-          buildlink3.mk files that you list in a
+          buildlink3.mk files that you list in a
           package's Makefile are added as dependencies for that package.
 	  
    • 
 
    
@@ -4022,66 +4033,66 @@ a security check before building any package.  See
     BUILDLINK_API_DEPENDS.foo+=   foo>=1.1.0
     .include "../../category/foo/buildlink3.mk"
    -

    There are several buildlink3.mk - files in pkgsrc/mk +

    There are several buildlink3.mk + files in pkgsrc/mk that handle special package issues:

      -

    • bdb.buildlink3.mk chooses either +

    • bdb.buildlink3.mk chooses either the native or a pkgsrc Berkeley DB implementation based on the values of BDB_ACCEPTED and BDB_DEFAULT.

      • -

    • curses.buildlink3.mk: If the system +

    • curses.buildlink3.mk: If the system comes with neither Curses nor NCurses, this will take care - to install the devel/ncurses package.

      • -

    • krb5.buildlink3.mk uses the value + to install the devel/ncurses package.

      • +

    • krb5.buildlink3.mk uses the value of KRB5_ACCEPTED to choose between adding a dependency on Heimdal or MIT-krb5 for packages that require a Kerberos 5 implementation.

      • -

    • motif.buildlink3.mk checks +

    • motif.buildlink3.mk checks for a system-provided - Motif installation or adds a dependency on x11/lesstif or - x11/openmotif.

      • -

    • oss.buildlink3.mk defines several + Motif installation or adds a dependency on x11/lesstif or + x11/openmotif.

      • +

    • oss.buildlink3.mk defines several variables that may be used by packages that use the Open Sound System (OSS) API.

      • -

    • pgsql.buildlink3.mk will accept +

    • pgsql.buildlink3.mk will accept either Postgres 7.3 or 7.4, whichever is found installed. See the file for more information.

      • -

    • pthread.buildlink3.mk uses the value of +

    • pthread.buildlink3.mk uses the value of PTHREAD_OPTS and checks for native pthreads or adds - a dependency on devel/pth as needed.

      • -

    • xaw.buildlink3.mk uses the value of + a dependency on devel/pth as needed.

      • +

    • xaw.buildlink3.mk uses the value of XAW_TYPE to choose a particular Athena widgets library.

    -

    The comments in those buildlink3.mk +

    The comments in those buildlink3.mk files provide a more complete description of how to use them properly.

    -11.2. Writing buildlink3.mk files

    -

    A package's buildlink3.mk file is +11.2. Writing buildlink3.mk files

    +

    A package's buildlink3.mk file is included by Makefiles to indicate the need to compile and link against header files and libraries provided by the package. A - buildlink3.mk file should always provide + buildlink3.mk file should always provide enough information to add the correct type of dependency relationship and include any other - buildlink3.mk files that it needs to find + buildlink3.mk files that it needs to find headers and libraries that it needs in turn.

    -

    To generate an initial buildlink3.mk - file for further editing, Rene Hexel's pkgtools/createbuildlink +

    To generate an initial buildlink3.mk + file for further editing, Rene Hexel's pkgtools/createbuildlink package is highly recommended. For most packages, the following command will generate a good starting point for - buildlink3.mk files:

    + buildlink3.mk files:

    % cd pkgsrc/category/pkgdir
 % createbuildlink >buildlink3.mk

    11.2.1. Anatomy of a buildlink3.mk file

    The following real-life example - buildlink3.mk is taken - from pkgsrc/graphics/tiff:

    + buildlink3.mk is taken + from pkgsrc/graphics/tiff:

         # $NetBSD: buildlink3.mk,v 1.7 2004/03/18 09:12:12 jlam Exp $
 
@@ -4107,21 +4118,21 @@ a security check before building any package.  See

    The header and footer manipulate BUILDLINK_DEPTH, which is common across all - buildlink3.mk files and is used to track + buildlink3.mk files and is used to track at what depth we are including - buildlink3.mk files.

    + buildlink3.mk files.

    The first section controls if the dependency on pkg is added. BUILDLINK_DEPENDS is the global list of packages for which dependencies are added by buildlink3.

    The second section advises pkgsrc that the - buildlink3.mk file for + buildlink3.mk file for pkg has been included at some point. BUILDLINK_PACKAGES is the global list of - packages for which buildlink3.mk files + packages for which buildlink3.mk files have been included. It must always be - appended to within a buildlink3.mk + appended to within a buildlink3.mk file.

    The third section is protected from multiple inclusion and controls how the dependency on pkg is @@ -4155,7 +4166,7 @@ a security check before building any package. See and BUILDLINK_LIBDIRS.pkg (not shown above) are lists of subdirectories of - ${BUILDLINK_PREFIX.pkg} + ${BUILDLINK_PREFIX.pkg} to add to the header and library search paths. These default to “include” and “lib” respectively.

    @@ -4171,40 +4182,40 @@ a security check before building any package. See

    The following variables are all optionally defined within this second section (protected against multiple inclusion) and control which package files are symlinked into - ${BUILDLINK_DIR} and how their names are + ${BUILDLINK_DIR} and how their names are transformed during the symlinking:

    • BUILDLINK_FILES.pkg (not shown above) is a shell glob pattern relative to - ${BUILDLINK_PREFIX.pkg} + ${BUILDLINK_PREFIX.pkg} to be symlinked into - ${BUILDLINK_DIR}, - e.g. include/*.h.

      • + ${BUILDLINK_DIR}, + e.g. include/*.h.

    • BUILDLINK_FILES_CMD.pkg (not shown above) is a shell pipeline that outputs to stdout a list of files relative to - ${BUILDLINK_PREFIX.pkg}. + ${BUILDLINK_PREFIX.pkg}. The resulting files are to be symlinked - into ${BUILDLINK_DIR}. By default, - this takes the +CONTENTS of a + into ${BUILDLINK_DIR}. By default, + this takes the +CONTENTS of a pkg and filters it through ${BUILDLINK_CONTENTS_FILTER.pkg}.

    • BUILDLINK_CONTENTS_FILTER.pkg (not shown above) is a filter command that filters - +CONTENTS input into a list of files + +CONTENTS input into a list of files relative to - ${BUILDLINK_PREFIX.pkg} + ${BUILDLINK_PREFIX.pkg} on stdout. By default for overwrite packages, BUILDLINK_CONTENTS_FILTER.pkg - outputs the contents of the include - and lib directories in the package - +CONTENTS, and for pkgviews packages, + outputs the contents of the include + and lib directories in the package + +CONTENTS, and for pkgviews packages, it outputs any libtool archives in - lib directories. + lib directories.

    • BUILDLINK_TRANSFORM.pkg @@ -4215,20 +4226,20 @@ a security check before building any package. See

    The last section includes any - buildlink3.mk needed for + buildlink3.mk needed for pkg's library dependencies. - Including these buildlink3.mk files + Including these buildlink3.mk files means that the headers and libraries for these dependencies are also symlinked into - ${BUILDLINK_DIR} + ${BUILDLINK_DIR} whenever the pkg - buildlink3.mk + buildlink3.mk file is included.

    -11.2.2. Updating BUILDLINK_API_DEPENDS.pkg in buildlink3.mk files

    +11.2.2. Updating BUILDLINK_API_DEPENDS.pkg in buildlink3.mk files

    The situation that requires increasing the dependency listed in BUILDLINK_API_DEPENDS.pkg @@ -4239,7 +4250,7 @@ a security check before building any package. See 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 PKGREVISIONs - increased and, if they have buildlink3.mk + increased and, if they have buildlink3.mk files, their BUILDLINK_API_DEPENDS.pkg adjusted, too. This is needed so pkgsrc will require the @@ -4274,12 +4285,12 @@ a security check before building any package. See

    -11.3. Writing builtin.mk files

    +11.3. Writing builtin.mk files

    Some packages in pkgsrc install headers and libraries that coincide with headers and libraries present in the base system. - Aside from a buildlink3.mk file, these - packages should also include a builtin.mk + Aside from a buildlink3.mk file, these + packages should also include a builtin.mk file that includes the necessary checks to decide whether using the built-in software or the pkgsrc software is appropriate.

    @@ -4295,16 +4306,16 @@ a security check before building any package. See

  • It should not override any USE_BUILTIN.pkg which is already set before the - builtin.mk file is included. + builtin.mk file is included.

  • It should be written to allow multiple inclusion. This is very important and takes careful - attention to Makefile coding. + attention to Makefile coding.

    • -11.3.1. Anatomy of a builtin.mk file

    +11.3.1. Anatomy of a builtin.mk file

    The following is the recommended template for builtin.mk files: 

    @@ -4354,7 +4365,7 @@ a security check before building any package.  See
         with similar functionality to pkg;
         it should only be “yes” if the actual package is
         included as part of the base system.  This variable is only
-        used internally within the builtin.mk
+        used internally within the builtin.mk
         file. 
    
 
     The second section sets
         BUILTIN_PKG.pkg
@@ -4362,11 +4373,11 @@ a security check before building any package.  See
         system if it exists (if
         IS_BUILTIN.pkg
         is “yes”).  This variable is only used internally
-        within the builtin.mk file. 
    
+        within the builtin.mk file. 
    
 
     The third section sets
         USE_BUILTIN.pkg
         and is required in all
-        builtin.mk files.  The code in this
+        builtin.mk files.  The code in this
         section must make the determination whether the built-in
         software is adequate to satisfy the dependencies listed in
         BUILDLINK_API_DEPENDS.pkg.
@@ -4376,7 +4387,7 @@ a security check before building any package.  See
         BUILDLINK_API_DEPENDS.pkg.
         USE_BUILTIN.pkg
         must be set to the correct value by the
-        end of the builtin.mk file.  Note that
+        end of the builtin.mk file.  Note that
         USE_BUILTIN.pkg
         may be “yes” even if
         IS_BUILTIN.pkg
@@ -4390,7 +4401,7 @@ a security check before building any package.  See
         set in the previous section.  This typically includes, e.g.,
         adding additional dependency restrictions and listing
         additional files to symlink into
-        ${BUILDLINK_DIR} (via
+        ${BUILDLINK_DIR} (via
         BUILDLINK_FILES.pkg).
         
    
 
@@ -4422,7 +4433,7 @@ a security check before building any package.  See
     PREFER_NATIVE=  getopt skey tcp_wrappers

    A package must have a - builtin.mk + builtin.mk file to be listed in PREFER_NATIVE, otherwise it is simply ignored in that list.

    @@ -4480,21 +4491,21 @@ automatically generated by pkginstall.

    12.1. Files and directories outside the installation prefix

    -

    As you already know, the PLIST file holds a list +

    As you already know, the PLIST file holds a list of files and directories that belong to a package. The names used in it -are relative to the installation prefix (${PREFIX}), +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}.

    +${VARBASE} or +${PKG_SYSCONFDIR}.

    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 +Makefile. The rest of this section describes these variables.

    @@ -4527,7 +4538,7 @@ directories anywhere in the file system:

    12.1.2. File manipulation

    Creating non-empty files outside the installation prefix is tricky -because the PLIST forces all files to be inside it. +because the PLIST forces all files to be inside it. To overcome this problem, the only solution is to extract the file in the known place (i.e., inside the installation prefix) and copy it to the appropriate location during installation (done by the installation scripts @@ -4583,20 +4594,20 @@ specifies where configuration files shall be installed. Its contents are set based upon the following variables:

    • PKG_SYSCONFBASE: The configuration's root - directory. Defaults to ${PREFIX}/etc although it may + directory. Defaults to ${PREFIX}/etc although it may be overridden by the user to point to his preferred location (e.g., - /etc, /etc/pkg, etc.). + /etc, /etc/pkg, etc.). Packages must not use it directly.

    • PKG_SYSCONFSUBDIR: A subdirectory of PKG_SYSCONFBASE under which the configuration files for the package being built shall be installed. The definition of this variable only makes sense in the package's - Makefile (i.e., it is not user-customizable).

      + Makefile (i.e., it is not user-customizable).

      As an example, consider the Apache package, - www/apache2, which places its + www/apache2, which places its configuration files under the - httpd/ subdirectory of + httpd/ subdirectory of PKG_SYSCONFBASE. This should be set in the package Makefile.

      • @@ -4619,13 +4630,13 @@ following:

      its value is used.

    • If the previous variable is not defined but PKG_SYSCONFSUBDIR is set in the package's - Makefile, the resulting value is - ${PKG_SYSCONFBASE}/${PKG_SYSCONFSUBDIR}.

      • + Makefile, the resulting value is + ${PKG_SYSCONFBASE}/${PKG_SYSCONFSUBDIR}.

    • Otherwise, it is set to - ${PKG_SYSCONFBASE}.

      • + ${PKG_SYSCONFBASE}.

    -

    It is worth mentioning that ${PKG_SYSCONFDIR} is -automatically added to OWN_DIRS. See Section 12.1.1, “Directory manipulation” what this means.

    +

    It is worth mentioning that ${PKG_SYSCONFDIR} is +automatically added to OWN_DIRS. See Section 12.1.1, “Directory manipulation” what this means.

    @@ -4649,23 +4660,23 @@ unfortunately).

    12.2.3. Patching installations

    As said before, pkginstall automatically handles configuration files. This means that the packages themselves must not -touch the contents of ${PKG_SYSCONFDIR} +touch the contents of ${PKG_SYSCONFDIR} directly. Bad news is that many software installation scripts will, out of the box, mess with the contents of that directory. So what is the correct procedure to fix this issue?

    You must teach the package (usually by manually patching it) to install any configuration files under the examples hierarchy, -share/examples/${PKGBASE}/. This way, the -PLIST registers them and the administrator always +share/examples/${PKGBASE}/. This way, the +PLIST registers them and the administrator always has the original copies available.

    Once the required configuration files are in place (i.e., under the examples hierarchy), the pkginstall framework can use them as master copies during the package installation to update what is in -${PKG_SYSCONFDIR}. To achieve this, the variables +${PKG_SYSCONFDIR}. To achieve this, the variables CONF_FILES and CONF_FILES_PERMS are used. Check out Section 12.1.2, “File manipulation” for information about their syntax and their purpose. Here is an example, taken from the -mail/mutt package:

    +mail/mutt package:

         EGDIR=        ${PREFIX}/share/doc/mutt/samples
     CONF_FILES=   ${EGDIR}/Muttrc ${PKG_SYSCONFDIR}/Muttrc
@@ -4692,10 +4703,10 @@ these files.
    
 
    In order to provide system startup scripts, the package has
 to:
    
 
      
-
    1. Store the script inside ${FILESDIR}, with
+
    2. Store the script inside ${FILESDIR}, with
     the .sh suffix appended.  Considering the
-    print/cups package as an example, it has a
-    cupsd.sh in its files directory.
      3. 
+    print/cups package as an example, it has a
+    cupsd.sh in its files directory.
      
 
    3. 
 
      Tell pkginstall to handle it, appending the name of the script,
     without its extension, to the RCD_SCRIPTS variable.
@@ -4709,12 +4720,12 @@ to:
      
 script in an automated fashion:
      
 
        
 
      1. Process the file found in the files directory applying all the
-    substitutions described in the FILES_SUBST
+    substitutions described in the FILES_SUBST
     variable.
        2. 
 
      2. Copy the script from the files directory to the examples
-    hierarchy, ${PREFIX}/share/examples/rc.d/.  Note
+    hierarchy, ${PREFIX}/share/examples/rc.d/.  Note
     that this master file must be explicitly registered in the
-    PLIST.
        3. 
+    PLIST.
        
 
      3. Add code to the installation scripts to copy the startup script
     from the examples hierarchy into the system-wide startup scripts
     directory.
        4. 
@@ -4725,7 +4736,7 @@ script in an automated fashion:
        
 
        The automatic copying of config files can be toggled by setting the
 environment variable PKG_RCD_SCRIPTS prior to package
 installation.  Note that the scripts will be always copied inside the
-examples hierarchy, ${PREFIX}/share/examples/rc.d/, no
+examples hierarchy, ${PREFIX}/share/examples/rc.d/, no
 matter what the value of this variable is.
        
 
      
 
    
@@ -4747,10 +4758,10 @@ UID for the user.
 PKG_GECOS.user is the user's
 description or comment.
 PKG_HOME.user is the user's
-home directory, and defaults to /nonexistent if not
+home directory, and defaults to /nonexistent if not
 specified.
 PKG_SHELL.user is the user's
-shell, and defaults to /sbinno/login if not specified.
+shell, and defaults to /sbinno/login if not specified.
 
    
 
    Similarly, groups can be created by adding entries to the
 PKG_GROUPS variable, whose syntax is:
    
@@ -4770,14 +4781,14 @@ are automatically hardcoded into the final installation scripts.
    
 
    
 12.5. System shells
    
 
    Packages that install system shells should register them in the shell
-database, /etc/shells, to make things easier to the
+database, /etc/shells, to make things easier to the
 administrator.  This must be done from the installation scripts to keep
 binary packages working on any system.  pkginstall provides an easy way to
 accomplish this task.
    
 
    When a package provides a shell interpreter, it has to set the
 PKG_SHELL variable to its absolute file name.  This will
 add some hooks to the installation scripts to handle it.  Consider the
-following example, taken from shells/zsh:
    
+following example, taken from shells/zsh:
    
 
         PKG_SHELL=      ${PREFIX}/bin/zsh
 
    
@@ -4785,7 +4796,7 @@ following example, taken from 
    
 12.5.1. Disabling shell registration

    The automatic registration of shell interpreters can be disabled by -the administrator by setting the PKG_REGISTER_SHELLS +the administrator by setting the PKG_REGISTER_SHELLS environment variable to NO.

    @@ -4803,7 +4814,7 @@ where type can be one of “fonts/dbz-ttf:

    +installation prefix. Consider the following example, taken from fonts/dbz-ttf:

         FONTS_DIRS.ttf= ${PREFIX}/lib/X11/fonts/TTF
    @@ -4811,7 +4822,7 @@ installation prefix. Consider the following example, taken from

    12.6.1. Disabling automatic update of the fonts databases

    The automatic update of fonts databases can be disabled by -the administrator by setting the PKG_UPDATE_FONTS_DB +the administrator by setting the PKG_UPDATE_FONTS_DB environment variable to NO.

    @@ -4823,12 +4834,12 @@ environment variable to NO.

    Table of Contents

    13.1. Global default options
    -
    13.2. Converting packages to use bsd.options.mk
    +
    13.2. Converting packages to use bsd.options.mk
    13.3. Option Names

    Many packages have the ability to be built to support different -sets of features. bsd.options.mk is a framework +sets of features. bsd.options.mk is a framework in pkgsrc that provides generic handling of those options that determine different ways in which the packages can be built. It's possible for the user to specify exactly which sets of options will be @@ -4840,17 +4851,17 @@ apply.

    Global default options are listed in PKG_DEFAULT_OPTIONS, which is a list of the options that should be built into every package if that option is supported. -This variable should be set in /etc/mk.conf.

    +This variable should be set in /etc/mk.conf.

    -13.2. Converting packages to use bsd.options.mk

    +13.2. Converting packages to use bsd.options.mk

    The following example shows how -bsd.options.mk should be used +bsd.options.mk should be used by the hypothetical ``wibble'' package, either in the package -Makefile, or in a file, -e.g. options.mk, that is included by the -main package Makefile.

    +Makefile, or in a file, +e.g. options.mk, that is included by the +main package Makefile.

         PKG_OPTIONS_VAR=                PKG_OPTIONS.wibble
     PKG_SUPPORTED_OPTIONS=          wibble-foo ldap
@@ -4934,7 +4945,7 @@ build options which are enabled by default.
    
 
  • PKG_OPTIONS_LEGACY_VARS is a list
 of
 “USE_VARIABLE:option”
-pairs that map legacy /etc/mk.conf variables to
+pairs that map legacy /etc/mk.conf variables to
 their option counterparts.  Pairs should be added with
 “+=” to keep the listing of global legacy variables.  A
 warning will be issued if the user uses a legacy
@@ -4961,7 +4972,7 @@ what to use instead.
    • 
 To suggest a default set of options, use
 PKG_SUGGESTED_OPTIONS.
    
 
    PKG_OPTIONS_VAR must be defined before
-including bsd.options.mk.  If none of
+including bsd.options.mk.  If none of
 PKG_SUPPORTED_OPTIONS,
 PKG_OPTIONS_OPTIONAL_GROUPS, and
 PKG_OPTIONS_REQUIRED_GROUPS are defined (as can
@@ -4969,7 +4980,7 @@ happen with platform-specific options if none of them is supported on
 the current platform), PKG_OPTIONS is set to the
 empty list and the package is otherwise treated as not using the
 options framework.
    
-
    After the inclusion of bsd.options.mk, the
+
    After the inclusion of bsd.options.mk, the
 variable PKG_OPTIONS contains the list of selected
 build options, properly filtered to remove unsupported and duplicate
 options.
    
@@ -4997,7 +5008,7 @@ specific to that group, prefix it with the name of the
 “main” package
 (e. g. djbware-errno-hack).
    
 
    For new options, add a line to
-mk/defaults/options.description.  Lines have two
+mk/defaults/options.description.  Lines have two
 fields, separated by tab.  The first field is the option name, the
 second its description.  The description should be a whole sentence
 (starting with an uppercase letter and ending with a period) that
@@ -5058,7 +5069,7 @@ can be put into place on the system.
    
 
    The automatic variable PREFIX indicates
       where all files of the final program shall be installed. It is
       usually set to LOCALBASE
-      (/usr/pkg), or CROSSBASE
+      (/usr/pkg), or CROSSBASE
       for pkgs in the “cross” category.  The value of
       PREFIX needs to be put
       into the various places in the program's source where paths to
@@ -5082,7 +5093,7 @@ can be put into place on the system.
    
 	  either X11BASE or LOCALBASE.
    
 
    Usually, X11 packages should be installed under
 	  LOCALBASE whenever possible.  Note that you will
-	  need to include ../../mk/x11.buildlink3.mk
+	  need to include ../../mk/x11.buildlink3.mk
 	  in them to request the
 	  presence of X11 and to get the right compilation flags.
    
 
    Even though, there are some packages that cannot be installed
@@ -5094,11 +5105,11 @@ can be put into place on the system.
    
 
    Some notes: If you need
 	  to find includes or libraries installed by a pkg that has
 	  USE_IMAKE or USE_X11BASE in
-	  its pkg Makefile, you need to look in
-	  both ${X11BASE} and
-	  ${LOCALBASE}. To force installation of
+	  its pkg Makefile, you need to look in
+	  both ${X11BASE} and
+	  ${LOCALBASE}. To force installation of
 	  all X11 packages in LOCALBASE, the
-	  pkgtools/xpkgwedge package
+	  pkgtools/xpkgwedge package
 	  is enabled by default.
    
 
 
  • X11PREFIX should be used to refer to the installed
@@ -5116,7 +5127,7 @@ can be put into place on the system.
    
 	  not installed.
    
 
    This is best illustrated by example.
    
 
    The following lines are taken from
-	  pkgsrc/wm/scwm/Makefile:
    
+	  pkgsrc/wm/scwm/Makefile:
    
 
         EVAL_PREFIX+=           GTKDIR=gtk+
     CONFIGURE_ARGS+=        --with-guile-prefix=${LOCALBASE:Q}
@@ -5132,10 +5143,10 @@ can be put into place on the system.
    
 	  to the first definition in
 	  the EVAL_PREFIX pair.
    
 
    • 
-
  • Within ${PREFIX}, packages should
+
  • Within ${PREFIX}, packages should
           install files according to hier(7), with the exception that
-          manual pages go into ${PREFIX}/man, not
-          ${PREFIX}/share/man.
    • 
+          manual pages go into ${PREFIX}/man, not
+          ${PREFIX}/share/man.
    
 
 
 
    
@@ -5169,7 +5180,7 @@ the wrappers.
    
 where the distfiles are extracted. It is usually a direct subdirectory
 of WRKDIR, and often it's the only directory entry
 that isn't hidden. This variable may be changed by a package
-Makefile.
    
+Makefile.
    
 
    
 
 
    
@@ -5188,7 +5199,7 @@ the package will be built, but not installed.
    
 
    This will check if the file(s) given in the variables
 	    DISTFILES and PATCHFILES (as
 	    defined in the package's Makefile) are present on the
-	    local system in /usr/pkgsrc/distfiles. If they
+	    local system in /usr/pkgsrc/distfiles. If they
 	    are not present, an attempt will be made to fetch them using commands
 	    of the form:
    
 
    @@ -5225,7 +5236,7 @@ the package will be built, but not installed.
    
 	EXTRACT_ONLY variable to the list of those
 	files.
    
 
    Extracting the files is usually done by a little program,
-	mk/scripts/extract, which already knows how
+	mk/scripts/extract, which already knows how
 	to extract various archive formats, so most likely you will not
 	need to change anything here. But if you need, the following
 	variables may help you:
    
@@ -5233,18 +5244,18 @@ the package will be built, but not installed.
    
 
    EXTRACT_OPTS_{BIN,LHA,PAX,RAR,TAR,ZIP,ZOO}
    
 
    Use these variables to override the default
 	options for an extract command, which are defined in
-	mk/scripts/extract.
    
+	mk/scripts/extract.
    
 
    EXTRACT_USING
    
 
    This variable can be set to
 	pax, tar or an absolute
 	pathname pointing to the command with which tar archives should
 	be extracted.
    
 
    
-
    If the extract program doesn't serve
+
    If the extract program doesn't serve
 	your needs, you can also override the
 	EXTRACT_CMD variable, which holds the command
 	used for extracting the files. This command is executed in the
-	${WRKSRC} directory. During execution of
+	${WRKSRC} directory. During execution of
 	this command, the shell variable extract_file
 	holds the absolute pathname of the file that is going to be
 	extracted.
    
@@ -5258,11 +5269,11 @@ the package will be built, but not installed.
    
 
    After extraction, all the patches named by the
 	    PATCHFILES, those present in the patches
 	    subdirectory of the package as well as in $LOCALPATCHES/$PKGPATH (e.g.
-	    /usr/local/patches/graphics/png) are applied.
-	    Patchfiles ending in .Z or
-	    .gz are uncompressed before they are applied,
-	    files ending in .orig or
-	    .rej are ignored. Any special options to patch(1)
+	    /usr/local/patches/graphics/png) are applied.
+	    Patchfiles ending in .Z or
+	    .gz are uncompressed before they are applied,
+	    files ending in .orig or
+	    .rej are ignored. Any special options to patch(1)
 	    can be handed in PATCH_DIST_ARGS.
 	    See Section 8.3, “patches/*” for more details.
    
 
    By default patch(1) is given special args to make it fail if the
@@ -5347,7 +5358,7 @@ these directories, the configure script is run with the environment
 (default: “./configure”) and
 CONFIGURE_ARGS may all be changed by the
 package.
    
-
    If the program uses an Imakefile for
+
    If the program uses an Imakefile for
 configuration, the appropriate steps can be invoked by setting
 USE_IMAKE to “yes”. (If you only want
 the package installed in ${X11PREFIX} but xmkmf not
@@ -5451,7 +5462,7 @@ of MAKEFILE is “Makefile<
 		assumed, which means that the package claims to create
 		all needed directories itself before installing files to
 		it. Therefore this variable should only be set in
-		Makefiles that are under control of
+		Makefiles that are under control of
 		the package's author.
    
 
 
@@ -5496,7 +5507,7 @@ of MAKEFILE is “Makefile<
 		  This can be used to remove any packages that may have been pulled in
 		  by a given package, e.g. if make deinstall
 		    DEINSTALLDEPENDS=1 is done in
-		  pkgsrc/x11/kde, this is likely to remove whole
+		  pkgsrc/x11/kde, this is likely to remove whole
 		  KDE. Works by adding “-R” to the pkg_delete(1) command line.
    
 
 
@@ -5521,7 +5532,7 @@ of MAKEFILE is “Makefile<
 	    one of the packages to be updated has been changed, resuming
 	    make update will most certainly fail!
    
 
    The following variables can be used either on the command line or in
-	    /etc/mk.conf to alter the behaviour of
+	    /etc/mk.conf to alter the behaviour of
 	    make update:
    
 
    
 
    UPDATE_TARGET
    
@@ -5572,7 +5583,7 @@ of MAKEFILE is “Makefile<
 # 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 + /etc/mk.conf to alter the behaviour of make clean-update:

    CLEAR_DIRLIST
    @@ -5589,40 +5600,40 @@ of MAKEFILE is “Makefile< package. You can use this to check which version of a package is installed.

    readme
    -

    This target generates a README.html file, which +

    This target generates a README.html file, which can be viewed using a browser such as - www/mozilla or - www/links. + www/mozilla or + www/links. The generated files contain references to any packages which are in the PACKAGES directory on the local host. The generated files can be made to refer to URLs based on FTP_PKG_URL_HOST and FTP_PKG_URL_DIR. For example, if I wanted to generate - README.html files which pointed to binary packages + README.html files which pointed to binary packages on the local machine, in the directory - /usr/packages, set + /usr/packages, set FTP_PKG_URL_HOST=file://localhost and FTP_PKG_URL_DIR=/usr/packages. The ${PACKAGES} directory and its subdirectories will be searched for all the binary packages.

    readme-all
    -

    Use this target to create a file README-all.html +

    Use this target to create a file README-all.html 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 - pkgsrc/*/README.html files, so be sure to run + pkgsrc/*/README.html files, so be sure to run this after a make readme.

    cdrom-readme

    This is very much the same as the “readme” target (see above), but is to be used when generating a pkgsrc tree to be written to a CD-ROM. This target also produces - README.html files, and can be made to refer + README.html files, and can be made to refer to URLs based on CDROM_PKG_URL_HOST and CDROM_PKG_URL_DIR.

    show-distfiles

    This target shows which distfiles and patchfiles are needed to build the package. (DISTFILES and - PATCHFILES, but not patches/*)

    + PATCHFILES, but not patches/*)

    show-downlevel

    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 @@ -5644,23 +5655,23 @@ of MAKEFILE is “Makefile<

    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 PKG_DEVELOPER is set in - /etc/mk.conf.

    + /etc/mk.conf.

    print-PLIST

    After a “make install” from a new or upgraded pkg, this prints out an attempt to generate a new - PLIST from a find -newer + PLIST from a find -newer work/.extract_done. An attempt is made to care for shared libs etc., but it is strongly recommended to review the result before putting it into - PLIST. On upgrades, it's useful to + PLIST. On upgrades, it's useful to diff the output of this command against an already - existing PLIST file.

    + existing PLIST file.

    If the package installs files via tar(1) or other methods that don't update file access times, be sure to add these files manually to your - PLIST, as the “find + PLIST, as the “find -newer” command used by this target won't catch them!

    See Section 10.3, “Tweaking output of make print-PLIST” for more @@ -5687,7 +5698,7 @@ of MAKEFILE is “Makefile<

    A binary package is considered “up-to-date” to be installed via pkg_add(1) if:

      -

    • None of the package's files (Makefile, +

    • None of the package's files (Makefile, ...) were modified since it was built.

    • None of the package's required (binary) packages were modified since it was built.

      • @@ -5743,7 +5754,7 @@ The tools used by a package can be listed by running 15.1. Tools for pkgsrc builds

    The default set of tools used by pkgsrc is defined in -bsd.pkg.mk. This includes standard Unix tools, +bsd.pkg.mk. This includes standard Unix tools, such as: cat, awk, chmod, test, and so on. These can be seen by running: @@ -5790,7 +5801,7 @@ tool at run-time, then just use DEPENDS instead.

    When improving or porting pkgsrc to a new platform, have a look at (or create) the corresponding platform specific make file fragment under -pkgsrc/mk/tools/tools.${OPSYS}.mk which defines +pkgsrc/mk/tools/tools.${OPSYS}.mk which defines the name of the common tools. For example:

     .if exists(/usr/bin/bzcat)
@@ -5871,17 +5882,17 @@ TOOLS_PLATFORM.true?=           true                    # shell builtin
 16.1.1. How to pull in variables from /etc/mk.conf
 
    The problem with package-defined variables that can be
         overridden via MAKECONF or
-        /etc/mk.conf is that make(1) expands a
+        /etc/mk.conf is that make(1) expands a
         variable as it is used, but evaluates preprocessor-like
         statements (.if, .ifdef and .ifndef) as they are read.  So, to
         use any variable (which may be set in
-        /etc/mk.conf) in one of the .if*
-        statements, the file /etc/mk.conf must be
+        /etc/mk.conf) in one of the .if*
+        statements, the file /etc/mk.conf must be
         included before that .if* statement.
    
 
    Rather than having a number of ad-hoc ways of including
-        /etc/mk.conf, should it exist, or
+        /etc/mk.conf, should it exist, or
         MAKECONF, should it exist, include the
-        pkgsrc/mk/bsd.prefs.mk file in the package
+        pkgsrc/mk/bsd.prefs.mk file in the package
         Makefile before any preprocessor-like .if, .ifdef, or .ifndef
         statements:
    
 
    @@ -5892,7 +5903,7 @@ TOOLS_PLATFORM.true?=           true                    # shell builtin
     .endif
 
    
 
    If you wish to set the CFLAGS variable
-        in /etc/mk.conf, please make sure to use:
+        in /etc/mk.conf, please make sure to use:
 
 
    
 
    @@ -5903,15 +5914,15 @@ TOOLS_PLATFORM.true?=           true                    # shell builtin
         Using CFLAGS= (i.e. without the
         “+”) may lead to problems with packages that need
         to add their own flags.  Also, you may want to take a look at
-        the devel/cpuflags package if
+        the devel/cpuflags package if
 	you're interested in optimization for the current CPU.
    
 
 
    
 
    
 16.1.2. Where to install documentation
    
 
    Documentation should be installed into
-      ${PREFIX}/share/doc/${PKGBASE} or
-      ${PREFIX}/share/doc/${PKGNAME} (the
+      ${PREFIX}/share/doc/${PKGBASE} or
+      ${PREFIX}/share/doc/${PKGNAME} (the
       latter includes the version number of the package).
    
 
    
 
    
@@ -5970,7 +5981,7 @@ TOOLS_PLATFORM.true?=           true                    # shell builtin
         dependency. pkgsrc supports the BUILD_DEPENDS
         and DEPENDS definitions, the
         USE_TOOLS definition, as well as
-        dependencies via buildlink3.mk, which is
+        dependencies via buildlink3.mk, which is
         the preferred way to handle dependencies, and which uses the
         variables named above. See Chapter 11, Buildlink methodology for more
         information.
    
@@ -5996,7 +6007,7 @@ TOOLS_PLATFORM.true?=           true                    # shell builtin
 
  • 
 
    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:
+            buildlink3.mk file available, use it:
 
    
 
         .include "../../graphics/jpeg/buildlink3.mk"
@@ -6004,7 +6015,7 @@ TOOLS_PLATFORM.true?=           true                    # shell builtin
 
    • 
 
  • 
 
    If your package needs to use another package to build
-            itself and there is no buildlink3.mk
+            itself and there is no buildlink3.mk
             file available, use the BUILD_DEPENDS
             definition:
    
 
    @@ -6013,7 +6024,7 @@ TOOLS_PLATFORM.true?=           true                    # shell builtin
 
    • 
 
  • 
 
    If your package needs a library with which to link and
-	again there is no buildlink3.mk file
+	again there is no buildlink3.mk file
         available, this is specified using the
         DEPENDS definition. For example:
    
 
    @@ -6079,9 +6090,9 @@ TOOLS_PLATFORM.true?=           true                    # shell builtin
 
  • 
 
    If your package needs some executable to be able to run
             correctly and if there's no
-            buildlink3.mk file, this is specified
+            buildlink3.mk file, this is specified
             using the DEPENDS variable. The
-            print/lyx package needs to
+            print/lyx package needs to
 	    be able to execute the latex binary from the teTeX package
 	    when it runs, and that is specified:
    
 
    @@ -6094,17 +6105,17 @@ TOOLS_PLATFORM.true?=           true                    # shell builtin
 
    If your package needs files from another package to build,
 	add the relevant distribution files to
 	DISTFILES, so they will be extracted
-	automatically. See the print/ghostscript package for an example.
+	automatically. See the print/ghostscript package for an example.
 	(It relies on the jpeg sources being present in source form
 	during the build.)
    
 
    Please also note the BUILD_USES_MSGFMT
         and BUILD_USES_GETTEXT_M4 definitions, which
         are provided as convenience definitions.  The former works out
         whether msgfmt(1) is part of the base system, and, if it isn't,
-        installs the devel/gettext package.
+        installs the devel/gettext package.
 	The latter adds a build dependency on either an installed
 	version of an older gettext package, or if it isn't, installs the
-        devel/gettext-m4 package.
    
+        devel/gettext-m4 package.
    
 
    • 
 
    
 
    
@@ -6116,14 +6127,14 @@ TOOLS_PLATFORM.true?=           true                    # shell builtin
 
    In this case you can set CONFLICTS to a
         space-separated list of packages (including version string) your
         package conflicts with.
    
-
    For example, x11/Xaw3d
-        and x11/Xaw-Xpm
+
    For example, x11/Xaw3d
+        and x11/Xaw-Xpm
         install the same shared library, thus you set in
-        pkgsrc/x11/Xaw3d/Makefile:
    
+        pkgsrc/x11/Xaw3d/Makefile:
    
 
         CONFLICTS=      Xaw-Xpm-[0-9]*
 
    
-
    and in pkgsrc/x11/Xaw-Xpm/Makefile:
+
    and in pkgsrc/x11/Xaw-Xpm/Makefile:
 
    
 
         CONFLICTS=      Xaw3d-[0-9]*
@@ -6169,7 +6180,7 @@ TOOLS_PLATFORM.true?=           true                    # shell builtin
 
    
 16.1.8. Handling packages with security problems
    
 
    When a vulnerability is found, this should be noted in
-        localsrc/security/advisories/pkg-vulnerabilities,
+        localsrc/security/advisories/pkg-vulnerabilities,
         and after committing that file, use make upload
 	in the same directory to update the file on ftp.NetBSD.org.
    
 
    After fixing the vulnerability by a patch, its
@@ -6193,7 +6204,7 @@ TOOLS_PLATFORM.true?=           true                    # shell builtin
         MACHINE_ARCH  and compiler version, disabling
         optimisation for that
         file/MACHINE_ARCH/compiler  combination, and
-        documenting it in  pkgsrc/doc/HACKS.  See
+        documenting it in  pkgsrc/doc/HACKS.  See
         that file for a number of examples!
    
 
    
 
    
@@ -6247,10 +6258,10 @@ TOOLS_PLATFORM.true?=           true                    # shell builtin
 16.2.1. Packages whose distfiles aren't available for plain downloading
    
 
    If you need to download from a dynamic URL you can set
         DYNAMIC_MASTER_SITES and a make
-        fetch will call files/getsite.sh
+        fetch will call files/getsite.sh
         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. graphics/ns-cult3d is an
+        it. graphics/ns-cult3d is an
 	example of this usage.
 
    
 
    If the download can't be automated, because the user must
@@ -6279,9 +6290,9 @@ TOOLS_PLATFORM.true?=           true                    # shell builtin
 	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
+	including the nbX suffix) or a date stamp
 	can be appended, like ${PKGNAME_NOREV}-YYYYMMDD.
-	Do not forget regenerating the distinfo file
+	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
@@ -6302,7 +6313,7 @@ TOOLS_PLATFORM.true?=           true                    # shell builtin
         compiler, linker, etc. to get the Right Thing, which can be
         pretty annoying especially if you don't have all the machines
         at your hand to test things.  The
-	devel/libtool pkg
+	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.
    
@@ -6326,12 +6337,12 @@ TOOLS_PLATFORM.true?=           true                    # shell builtin
         -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
+            .la extension, and the objects are
+            changed to have a .lo
             extension. Change OBJS as
             necessary. This automatically creates all of the
-            .a,
-            .so.major.minor, and ELF symlinks (if
+            .a,
+            .so.major.minor, and ELF symlinks (if
             necessary) in the build directory. Be sure to include
             “-version-info”, especially when major and
             minor are zero, as libtool will otherwise strip off the
@@ -6365,18 +6376,18 @@ TOOLS_PLATFORM.true?=           true                    # shell builtin
             automatically.
    
 
    The “-rpath argument” is the install
             directory of the library being built.
    
-
    In the PLIST, include only the
-            .la file, the other files will be
+
    In the PLIST, include only the
+            .la file, the other files will be
 	    added automatically.
    
 
 
  • 
-
    When linking shared object (.so)
+
    When linking shared object (.so)
             files, i.e. files that are loaded via dlopen(3), NOT
             shared libraries, use “-module
             -avoid-version” to prevent them getting version
             tacked on.
    
-
    The PLIST file gets the
-            foo.so entry.
    
+
    The PLIST file gets the
+            foo.so entry.
    
 
    • 
 
  • 
 
    When linking programs that depend on these libraries
@@ -6387,7 +6398,7 @@ TOOLS_PLATFORM.true?=           true                    # shell builtin
             libtool will not allow you to specify a relative path in
             -L (such as “-L../somelib”), because it
             expects you to change that argument to be the
-            .la file. e.g.
    
+            .la file. e.g.
    
 
         ${LIBTOOL} --mode=link ${CC} -o someprog -L../somelib -lsomelib
 
    
@@ -6401,16 +6412,16 @@ TOOLS_PLATFORM.true?=           true                    # shell builtin
 
    When installing libraries, preface the install(1)
             or cp(1) command with “${LIBTOOL}
             --mode=install”, and change the library name to
-            .la. e.g.
    
+            .la. e.g.
    
 
         ${LIBTOOL} --mode=install ${BSD_INSTALL_DATA} ${SOMELIB:.a=.la} ${PREFIX}/lib
 
    
-
    This will install the static .a,
+
    This will install the static .a,
             shared library, any needed symlinks, and run
             ldconfig(8).
    
 
    • 
-
  • In your PLIST, include only
-            the .la
+
  • In your PLIST, include only
+            the .la
             file (this is a change from previous behaviour).
    • 
 
 
@@ -6428,7 +6439,7 @@ TOOLS_PLATFORM.true?=           true                    # shell builtin
         default, it is set to “libtool */libtool
         */*/libtool”.  If this does not match the location of the
         package's libtool script(s), set it as appropriate.
    
-
    If you do not need *.a static
+
    If you do not need *.a static
         libraries built and installed, then use
         SHLIBTOOL_OVERRIDE instead.
    
 
    If your package makes use of the platform-independent library
@@ -6443,8 +6454,8 @@ TOOLS_PLATFORM.true?=           true                    # shell builtin
             has been done:
    
 
      
 
    1. The shared object is named correctly, i.e.
-                libfoo.la, not
-                foo.la
      2. 
+                libfoo.la, not
+                foo.la
      
 
    2. The -dlopen option is used when linking an executable.
      3. 
 
    
 
@@ -6623,7 +6634,7 @@ TOOLS_PLATFORM.true?=           true                    # shell builtin
 
 
    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.:
    
+        this should be set in the package's Makefile, e.g.:
    
 
         INTERACTIVE_STAGE=      build
 
    
@@ -6660,10 +6671,10 @@ TOOLS_PLATFORM.true?=           true                    # shell builtin
 
    
         Denoting that a package is covered by a particular license is
         done by placing the license in
-        pkgsrc/licenses and setting the
+        pkgsrc/licenses and setting the
         LICENSE variable to a string identifying
         the license, e.g. in
-	graphics/xv: 
    
+	graphics/xv: 
    
 
         LICENSE=        xv-license
 
    
@@ -6682,18 +6693,18 @@ TOOLS_PLATFORM.true?=           true                    # shell builtin
 
    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
+          /etc/mk.conf to indicate acceptance of
           the particular license:
    
 
         ACCEPTABLE_LICENSES+=xv-license
 
    
 
    When adding a package with a new license, the license
-          text should be added to pkgsrc/licenses
+          text should be added to pkgsrc/licenses
           for displaying. A list of known licenses can be seen in this
           directory as well as by looking at the list of (commented
           out) ACCEPTABLE_LICENSES variable
           settings in
-          pkgsrc/mk/defaults/mk.conf.
    
+          pkgsrc/mk/defaults/mk.conf.
    
 
    The use of LICENSE=shareware,
 	  LICENSE=no-commercial-use, and similar
 	  language is deprecated because it does not crisply refer to
@@ -6713,7 +6724,7 @@ TOOLS_PLATFORM.true?=           true                    # shell builtin
         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
-        mk/defaults/mk.conf, control this
+        mk/defaults/mk.conf, control this
         behaviour: SETGIDGAME,
         GAMEDATAMODE, GAMEGRP,
         GAMEMODE, GAMEOWN.
    
@@ -6742,7 +6753,7 @@ TOOLS_PLATFORM.true?=           true                    # shell builtin
         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
+        following definitions in your Makefile (we
         shall use tclsh in this example):
    
 
         REPLACE_INTERPRETER+=   tcl
@@ -6763,7 +6774,7 @@ TOOLS_PLATFORM.true?=           true                    # shell builtin
 16.5.6. Packages installing perl modules
 
    Makefiles of packages providing perl5 modules should include
         the Makefile fragment
-        ../../lang/perl5/module.mk.  It provides a
+        ../../lang/perl5/module.mk.  It provides a
         do-configure target for the standard perl
         configuration for such modules as well as various hooks to tune
         this configuration.  See comments in this file for
@@ -6771,8 +6782,8 @@ TOOLS_PLATFORM.true?=           true                    # shell builtin
 
    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
-        PLIST corresponding to the files listed in
-        the installed .packlist file generated by
+        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.:
    
@@ -6785,7 +6796,7 @@ TOOLS_PLATFORM.true?=           true                    # shell builtin
         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.
    
+        PLIST.
    
 
 
    
 
    
@@ -6793,36 +6804,36 @@ TOOLS_PLATFORM.true?=           true                    # shell builtin
 
    Some packages install info files or use the
         “makeinfo”  or “install-info”
 	commands.  INFO_FILES should be defined in
-	the package Makefile so that INSTALL and
-        DEINSTALL scripts will be generated to
+	the package Makefile so that INSTALL and
+        DEINSTALL scripts will be generated to
         handle registration of the info files in the Info directory
         file. The “install-info” command used for the info
         files registration is either provided by the system, or by a
         special purpose package automatically added as dependency if
         needed.
    
 
    PKGINFODIR is the directory under
-	${PREFIX} where info files are primarily
+	${PREFIX} where info files are primarily
 	located. PKGINFODIR defaults to
 	“info” and can be overridden by the user.
    
 
    The info files for the package should be listed in the
-	package PLIST; however any split info files
+	package PLIST; however any split info files
 	need not be listed.
    
 
    A package which needs the “makeinfo” command
         at build time must add “makeinfo” to
         USE_TOOLS in its Makefile. If a minimum
         version of the “makeinfo” command is needed it
         should be noted with the TEXINFO_REQD
-        variable in the package Makefile. By
+        variable in the package Makefile. By
         default, a minimum version of 3.12 is required. If the system
         does not provide a makeinfo command or if it
         does not match the required minimum, a build dependency on the
-        devel/gtexinfo package will
+        devel/gtexinfo package will
 	be added automatically.
    
 
    The build and installation process of the software provided
         by the package should not use the
         install-info command as the registration of
         info files is the task of the package
-        INSTALL script, and it must use the
+        INSTALL script, and it must use the
         appropriate makeinfo command.
    
 
    To achieve this goal, the pkgsrc infrastructure creates
         overriding scripts for the install-info and
@@ -6839,11 +6850,11 @@ TOOLS_PLATFORM.true?=           true                    # shell builtin
 16.5.8. Packages installing man pages
    
 
    Many packages install manual pages. The man pages
 	are installed under ${PREFIX}/${PKGMANDIR}
-	which is /usr/pkg/man by default.
+	which is /usr/pkg/man by default.
 	PKGMANDIR defaults to “man”.
 	For example, you can set PKGMANDIR to
 	“share/man” to have man pages install under
-	/usr/pkg/share/man/ by default.
+	/usr/pkg/share/man/ by default.
       
    
 
    
 
    Note
    
@@ -6851,15 +6862,15 @@ TOOLS_PLATFORM.true?=           true                    # shell builtin
 	is not complete.
       
    
 
    
-
    The PLIST files can just
-	use man/ as the top level directory
+
    The PLIST files can just
+	use man/ as the top level directory
 	for the man page file entries
 	and the pkgsrc framework will convert as needed.
       
    
 
     Packages that are
 	configured with GNU_CONFIGURE set as
 	“yes”, by default will use the
-	./configure
+	./configure
 	--mandir switch to set where the man pages should be installed.
 	The path is GNU_CONFIGURE_MANDIR which defaults
 	to ${PREFIX}/${PKGMANDIR}.
@@ -6868,7 +6879,7 @@ TOOLS_PLATFORM.true?=           true                    # shell builtin
 	Packages that use GNU_CONFIGURE but do not
 	use --mandir, can set CONFIGURE_HAS_MANDIR
 	to “no”.
-	Or if the ./configure script uses
+	Or if the ./configure script uses
 	a non-standard use of --mandir, you can set
 	GNU_CONFIGURE_MANDIR as needed.
       
    
@@ -6880,34 +6891,34 @@ TOOLS_PLATFORM.true?=           true                    # shell builtin
 
    
 16.5.9. Packages installing GConf2 data files
    
 
    
-        If a package installs .schemas or
-        .entries files, used by GConf2,
+        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:
 
    
 
      
-
    1. Include ../../devel/GConf2/schemas.mk
-          instead of its buildlink3.mk file.  This
+
    2. Include ../../devel/GConf2/schemas.mk
+          instead of its buildlink3.mk 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.
      3. 
 
    3. Ensure that the package installs its
-          .schemas files under
-          ${PREFIX}/share/gconf/schemas.  If they get
-          installed under ${PREFIX}/etc, you will
+          .schemas files under
+          ${PREFIX}/share/gconf/schemas.  If they get
+          installed under ${PREFIX}/etc, you will
           need to manually patch the package.
      4. 
 
    4. Check the PLIST and remove any entries under the etc/gconf
           directory, as they will be handled automatically.  See
           Section 7.14, “How do I change the location of configuration files?” for more information.
      5. 
 
    5. Define the GCONF2_SCHEMAS variable in
-          your Makefile with a list of all
-          .schemas files installed by the package, if
+          your Makefile with a list of all
+          .schemas files installed by the package, if
           any.  Names must not contain any directories in them.
      6. 
 
    6. Define the GCONF2_ENTRIES variable in
-          your Makefile with a
-          list of all .entries files installed by the
+          your Makefile with a
+          list of all .entries files installed by the
           package, if any. Names must not contain any directories in
           them.
      7. 
 
    
@@ -6916,22 +6927,22 @@ TOOLS_PLATFORM.true?=           true                    # shell builtin
 
    
 16.5.10. Packages installing scrollkeeper data files
    
 
    
-        If a package installs .omf files, used by
+        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:
 
    
 
      
 
    1. Include
-            ../../textproc/scrollkeeper/omf.mk
-            instead of its buildlink3.mk file.  This
+            ../../textproc/scrollkeeper/omf.mk
+            instead of its buildlink3.mk file.  This
             takes care of rebuilding the scrollkeeper database at
             installation and deinstallation time, and disallows any access
             to it directly from the package.
 
      2. 
 
    2. Check the PLIST and remove any entries under the
-            libdata/scrollkeeper directory, as they
+            libdata/scrollkeeper directory, as they
             will be handled automatically.
      3. 
-
    3. Remove the share/omf directory from
+
    4. Remove the share/omf directory from
             the PLIST.  It will be handled by scrollkeeper.
      5. 
 
    
 
    
@@ -6947,7 +6958,7 @@ TOOLS_PLATFORM.true?=           true                    # shell builtin
         variables, where type can be one of
         “ttf”, “type1” or “x11”.
         Also make sure that the database file
-        fonts.dir is not listed in the PLIST.
    
+        fonts.dir is not listed in the PLIST.
    
 
    Note that you should not create new directories for fonts;
         instead use the standard ones to avoid that the user needs to
         manually configure his X server to find them.
    
@@ -6960,8 +6971,8 @@ TOOLS_PLATFORM.true?=           true                    # shell builtin
         properly:
    
 
      
 
    1. Include
-        ../../x11/gtk2/modules.mk instead of its
-        buildlink3.mk file.  This takes care of
+        ../../x11/gtk2/modules.mk instead of its
+        buildlink3.mk file.  This takes care of
         rebuilding the database at installation and deinstallation time.
 
      2. 
 
    2. 
@@ -6977,15 +6988,15 @@ TOOLS_PLATFORM.true?=           true                    # shell builtin
 
         
      
 
        
-
      • libdata/gtk-2.0/gdk-pixbuf.loaders
        • 
-
      • libdata/gtk-2.0/gtk.immodules
        • 
+
      • libdata/gtk-2.0/gdk-pixbuf.loaders
        • 
+
      • libdata/gtk-2.0/gtk.immodules
        • 
 
      
 
      
 
      
 
      3. 
 
    3. 
         Check the PLIST and remove any entries under the
-        libdata/gtk-2.0 directory, as they will be
+        libdata/gtk-2.0 directory, as they will be
         handled automatically.
      4. 
 
    
 
@@ -6998,8 +7009,8 @@ TOOLS_PLATFORM.true?=           true                    # shell builtin
 
    
 
      
 
    1. Include
-            ../../textproc/xmlcatmgr/catalogs.mk in
-            your Makefile, which takes care of
+            ../../textproc/xmlcatmgr/catalogs.mk in
+            your Makefile, which takes care of
             registering those files in system-wide catalogs at
             installation and deinstallation time.
      2. 
 
    2. Set SGML_CATALOGS to the full path of
@@ -7023,29 +7034,29 @@ TOOLS_PLATFORM.true?=           true                    # shell builtin
 
      
 16.5.14. 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
+        installing .xml files inside
+        ${PREFIX}/share/mime/packages, you
         need to take some extra steps to ensure that the database is kept
         consistent with respect to these new files:
 
      
 
        
 
      1. Include
-            ../../databases/shared-mime-info/mimedb.mk
-            (avoid using the buildlink3.mk file from
+            ../../databases/shared-mime-info/mimedb.mk
+            (avoid using the buildlink3.mk file from
             this same directory, which is reserved for inclusion from
-            other buildlink3.mk files).  It takes
+            other buildlink3.mk files).  It takes
             care of rebuilding the MIME database at installation and
             deinstallation time, and disallows any access to it directly
             from the package.
        2. 
 
      2. Check the PLIST and remove any entries under the
-            share/mime directory,
+            share/mime directory,
             except for files saved under
-            share/mime/packages.  The former are
+            share/mime/packages.  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.
        3. 
-
      3. Remove any share/mime/* directories
+
      4. Remove any share/mime/* directories
             from the PLIST.  They will be handled by the shared-mime-info
             package.
        5. 
 
      
@@ -7054,7 +7065,7 @@ TOOLS_PLATFORM.true?=           true                    # shell builtin
 
      
 16.5.15. Packages using intltool
      
 
      If a package uses intltool during its build, include the
-        ../../textproc/intltool/buildlink3.mk file,
+        ../../textproc/intltool/buildlink3.mk file,
         which forces it to use the intltool package provided by pkgsrc,
         instead of the one bundled with the distribution file.
 
      
@@ -7069,8 +7080,8 @@ TOOLS_PLATFORM.true?=           true                    # shell builtin
 
      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 PKG_RCD_SCRIPTS=YES in
-        /etc/mk.conf. This option will copy the scripts
-        into /etc/rc.d when a package is installed, and
+        /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.
      
 
    
@@ -7078,7 +7089,7 @@ TOOLS_PLATFORM.true?=           true                    # shell builtin
 
    
 16.5.17. Packages installing TeX modules
    
 
    If a package installs TeX packages into the texmf tree,
-        the ls-R database of the tree needs to be
+        the ls-R database of the tree needs to be
         updated.
    
 
    
 
    Note
    
@@ -7089,9 +7100,9 @@ TOOLS_PLATFORM.true?=           true                    # shell builtin
 
    
 
      
 
    1. Include
-            ../../print/teTeX/module.mk instead
-            of ../../mk/tex.buildlink3.mk.  This
-            takes care of rebuilding the ls-R
+            ../../print/teTeX/module.mk instead
+            of ../../mk/tex.buildlink3.mk.  This
+            takes care of rebuilding the ls-R
             database at installation and deinstallation time.
      2. 
 
    2. 
 
      If your package installs files into a texmf
@@ -7107,8 +7118,8 @@ TOOLS_PLATFORM.true?=           true                    # shell builtin
 	    enable/disable font map files for TeX output
 	    drivers.
      
 
      3. 
-
    3. Make sure that none of ls-R
-            databases are included in PLIST, as
+
    4. Make sure that none of ls-R
+            databases are included in PLIST, as
             they will be removed only by the teTeX-bin package.
      5. 
 
    
 
@@ -7135,22 +7146,22 @@ TOOLS_PLATFORM.true?=           true                    # shell builtin
     debugging aids.
    
 
      
 
    • Be sure to set PKG_DEVELOPER=1
-	in /etc/mk.conf
      • 
+	in /etc/mk.conf
      
 
    • 
-
      Install pkgtools/url2pkg,
+
      Install pkgtools/url2pkg,
         create a directory for a new package, change into it, then run
         url2pkg:
      
 
      % mkdir /usr/pkgsrc/category/examplepkg
 % cd /usr/pkgsrc/category/examplepkg
 % url2pkg http://www.example.com/path/to/distfile.tar.gz
      
 
      • 
-
    • Edit the Makefile as requested.
      • 
-
    • Fill in the DESCR file
      • 
+
    • Edit the Makefile as requested.
      • 
+
    • Fill in the DESCR file
      • 
 
    • Run make configure
       
      • 
 
    • Add any dependencies glimpsed from documentation and the
 	configure step to the package's
-	Makefile.
      • 
+	Makefile.
      
 
    • 
 
      Make the package compile, doing multiple rounds of
      
 
      % make
@@ -7164,26 +7175,26 @@ TOOLS_PLATFORM.true?=           true                    # shell builtin
 	shouldn't be, especially during the build
 	phase. mkpatches,
 	patchdiff and pkgvi are
-	from the pkgtools/pkgdiff
+	from the pkgtools/pkgdiff
 	package. 
      
 
      • 
-
    • Look at the Makefile, fix if necessary;
-	see Section 8.1, “Makefile”.
      • 
+
    • Look at the Makefile, fix if necessary;
+	see Section 8.1, “Makefile”.
      • 
 
    • 
-
      Generate a PLIST:
      
+
      Generate a PLIST:
      
 
      # make install
 # make print-PLIST >PLIST
 # make deinstall
 # make install
 # make deinstall
      
-
      You usually need to be root to do this.
+
      You usually need to be root to do this.
 	Look if there are any files left:
      
 
      # make print-PLIST
      
 
      If this reveals any files that are missing in
-	PLIST, add them.
      
+	PLIST, add them.
      
 
      • 
 
    • 
-
      Now that the PLIST is OK,
+
      Now that the PLIST is OK,
 	install the package again and make a binary package:
      
 
      # make reinstall
 # make package
      
@@ -7204,7 +7215,7 @@ TOOLS_PLATFORM.true?=           true                    # shell builtin
 
    • Play with it. Make sure everything works.
      • 
 
    • 
 
      Run pkglint from
-        pkgtools/pkglint,
+        pkgtools/pkglint,
 	and fix the problems it reports:
      
 
      # pkglint
      
 
      • 
@@ -7261,34 +7272,34 @@ TOOLS_PLATFORM.true?=           true                    # shell builtin
 
      
 18.3. General notes when adding, updating, or removing packages
      
 
      Please note all package additions, updates, moves, and
-	removals in pkgsrc/doc/CHANGES. It's very
+	removals in pkgsrc/doc/CHANGES. It's very
 	important to keep this file up to date and conforming to the
 	existing format, because it will be used by scripts to
 	automatically update pages on www.NetBSD.org and other
 	sites. Additionally, check the
-	pkgsrc/doc/TODO file and remove the entry
+	pkgsrc/doc/TODO file and remove the entry
 	for the package you updated or removed, in case it was mentioned
 	there.
      
 
      When the PKGREVISION of a package is
 	bumped, the change should appear in
-	pkgsrc/doc/CHANGES if it is security
+	pkgsrc/doc/CHANGES if it is security
 	related or otherwise relevant. Mass bumps that result from a
 	dependency being updated should not be mentioned. In all other
 	cases it's the developer's decision.
      
 
      There is a make target that helps in creating proper
-  CHANGES entries:  make
+  CHANGES entries:  make
   changes-entry. It uses the optional CTYPE
   and NETBSD_LOGIN_NAME variables. The general
-  usage is to first make sure that your CHANGES
+  usage is to first make sure that your CHANGES
   file is up-to-date (to avoid having to resolve conflicts later-on)
   and then to cd to the package directory.  For
   package updates, make changes-entry is enough.
   For new packages, or package moves or removals, set the
   CTYPE variable on the command line to "Added",
   "Moved", or "Removed".  You can set NETBSD_LOGIN_NAME
-  in /etc/mk.conf if your local login name is
+  in /etc/mk.conf if your local login name is
   not the same as your NetBSD login name. Don't forget to commit
-  the changes to pkgsrc/doc/CHANGES!
      
+  the changes to pkgsrc/doc/CHANGES!
      
 
    
 
    
 
    
@@ -7311,11 +7322,11 @@ TOOLS_PLATFORM.true?=           true                    # shell builtin
   Remember to move the directory from which you imported out of
   the way, or cvs will complain the next time you “cvs
   update” your source tree.  Also don't forget to add the new
-  package to the category's Makefile.
+  package to the category's Makefile.
 
    
 
    
   The commit message of the initial import should include part of the
-  DESCR file, so people reading the mailing lists know
+  DESCR file, so people reading the mailing lists know
   what the package is/does.
 
    
 
    
@@ -7388,8 +7399,8 @@ place.
    
 
 
  • Fix paths in packages from step 5 to point to new location.
    • 
 
  • cvs rm (-f) the package at the old location.
    • 
-
  • Remove from oldcategory/Makefile.
    • 
-
  • Add to newcategory/Makefile.
    • 
+
  • Remove from oldcategory/Makefile.
    • 
+
  • Add to newcategory/Makefile.
    • 
 
  • 
 
    Commit the changed and removed files:
    
 
    % cvs commit oldcategory/package oldcategory/Makefile newcategory/Makefile
    
@@ -7410,24 +7421,24 @@ place.
    • 
 	pkgsrc-users mailing list.
    
 
    
 
    
-
    19.1. What is the difference between
+
    19.1. What is the difference between
 	MAKEFLAGS, .MAKEFLAGS and
 	MAKE_FLAGS?
 
    
-
    19.2. What is the difference between
+
    19.2. What is the difference between
 	MAKE, GMAKE and
 	MAKE_PROGRAM?
 
    
-
    19.3. What is the difference between
+
    19.3. What is the difference between
 	CC, PKG_CC and
 	PKGSRC_COMPILER?
 
    
-
    19.4. What is the difference between
+
    19.4. What is the difference between
 	BUILDLINK_LDFLAGS,
 	BUILDLINK_LDADD and
 	BUILDLINK_LIBS?
 
    
-
    19.5. Why does make show-var
+
    19.5. Why does make show-var
 	VARNAME=BUILDLINK_PREFIX.foo
 	say it's empty?
 
    
@@ -7437,7 +7448,7 @@ place.
    
 
 
 
-19.1.
+19.1.
 
 
    What is the difference between
 	MAKEFLAGS, .MAKEFLAGS and
@@ -7453,7 +7464,7 @@ place.
    
 
 
 
-19.2.
+19.2.
 
 
    What is the difference between
 	MAKE, GMAKE and
@@ -7471,7 +7482,7 @@ place.
    
 
 
 
-19.3.
+19.3.
 
 
    What is the difference between
 	CC, PKG_CC and
@@ -7484,12 +7495,12 @@ place.
    
 	PKG_CC is the path to the compiler wrapper.
 	PKGSRC_COMPILER is not a
 	path to a compiler, but the type of compiler that should be
-	used. See mk/compiler.mk for more
+	used. See mk/compiler.mk for more
 	information about the latter variable.
    
 
 
 
-19.4.
+19.4.
 
 
    What is the difference between
 	BUILDLINK_LDFLAGS,
@@ -7502,7 +7513,7 @@ place.
    
 
 
 
-19.5.
+19.5.
 
 
    Why does make show-var
 	VARNAME=BUILDLINK_PREFIX.foo
@@ -7642,7 +7653,7 @@ place.
    
 
    
 
    
 20.2. Designing interfaces for Makefile fragments
    
-
    Most of the .mk files fall into one
+
    Most of the .mk files fall into one
 	of the following classes. Cases where a file falls into more
 	than one class should be avoided as it often leads to subtle
 	bugs.
    
@@ -7650,10 +7661,10 @@ place.
    
 
    
 20.2.1. Procedures with parameters
    
 
    In a traditional imperative programming language some of
-	the .mk files could be described as
+	the .mk files could be described as
 	procedures. They take some input parameters and—after
 	inclusion—provide a result in output parameters. Since all
-	variables in Makefiles have global scope
+	variables in Makefiles have global scope
 	care must be taken not to use parameter names that have already
 	another meaning. For example, PKGNAME is a
 	bad choice for a parameter name.
    
@@ -7674,8 +7685,8 @@ place.
    
 	call the procedure more than once. That is, the file must not
 	contain multiple-inclusion guards.
    
 
    Examples for procedures are
-	mk/bsd.options.mk and
-	mk/buildlink3/bsd.builtin.mk. To express
+	mk/bsd.options.mk and
+	mk/buildlink3/bsd.builtin.mk. To express
 	that the parameters are evaluated at load time, they should be
 	assigned using the := operator, which should
 	be used only for this purpose.
    
@@ -7689,7 +7700,7 @@ place.
    
 	pkgsrc infrastructure, while other must be included
 	explicitly.
    
 
    An example for action files is
-	mk/subst.mk.
    
+	mk/subst.mk.
    
 
    
 
    
 
    
@@ -7724,16 +7735,16 @@ place.
    
 
    
 
    
 21.2. Running the regression tests
    
-
    You first need to install the pkgtools/pkg_regress package, which
+
    You first need to install the pkgtools/pkg_regress package, which
 	provides the pkg_regress command. Then you
 	can simply run that command, which will run all tests in the
-	regress category.
    
+	regress category.
    
 
    
 
    
 
    
 21.3. Adding a new regression test
    
-
    Every directory in the regress
-	category that contains a file called spec
+
    Every directory in the regress
+	category that contains a file called spec
 	is considered a regression test. This file is a shell program
 	that is included by the pkg_regress command.
 	The following functions can be overridden to suit your
@@ -7809,11 +7820,11 @@ place.
    
 	MyOS in this example), you need to touch the
 	following files:
    
 
    
-
    bootstrap/mods/mk/MyOS.sys.mk
    
+
    bootstrap/mods/mk/MyOS.sys.mk
    
 
    This file contains some basic definitions, for
 	example the name of the C
 	compiler.
    
-
    mk/bsd.prefs.mk
    
+
    mk/bsd.prefs.mk
    
 
    Insert code that defines the variables
 	OPSYS, OS_VERSION,
 	LOWER_OS_VERSION,
@@ -7821,37 +7832,37 @@ place.
    
 	MACHINE_ARCH, OBJECT_FMT,
 	APPEND_ELF, and the other variables that
 	appear in this file.
    
-
    mk/platform/MyOS.mk
    
+
    mk/platform/MyOS.mk
    
 
    This file contains the platform-specific
 	definitions that are used by pkgsrc. Start by copying one of the
 	other files and edit it to your
 	needs.
    
-
    mk/platform/MyOS.pkg.dist
    
+
    mk/platform/MyOS.pkg.dist
    
 
    This file contains a list of directories,
 	together with their permission bits and ownership. These
 	directories will be created automatically with every package
 	that does not explicitly set NO_MTREE. There
 	have been some discussions about whether this file is needed at
 	all, but with no result.
    
-
    mk/platform/MyOS.x11.dist
    
+
    mk/platform/MyOS.x11.dist
    
 
    Just copy one of the pre-existing x11.dist files
 	to your
-	MyOS.x11.dist.
    
-
    mk/tools/bootstrap.mk
    
+	MyOS.x11.dist.
    
+
    mk/tools/bootstrap.mk
    
 
    On some operating systems, the tools that are
 	provided with the base system are not good enough for pkgsrc.
 	For example, there are many versions of sed(1) that have a
 	narrow limit on the line length they can process. Therefore
 	pkgsrc brings its own tools, which can be enabled
 	here.
    
-
    mk/tools/MyOS.mk
    
+
    mk/tools/MyOS.mk
    
 
    This file defines the paths to all the tools
 	that are needed by one or the other package in pkgsrc, as well
 	as by pkgsrc itself. Find out where these tools are on your
 	platform and add them.
    
 
    
 
    Now, you should be able to build some basic packages, like
-	lang/perl5, shells/bash.
    
+	lang/perl5, shells/bash.
    
 
    
 
    
 
    
@@ -7929,7 +7940,7 @@ place.
    
 
    
 A.1.4. Checking a package with pkglint
    
 
    The NetBSD package system comes with
-        pkgtools/pkglint
+        pkgtools/pkglint
 	which helps to check the contents of these
 	files. After installation it is quite easy to use, just change to the
 	directory of the package you wish to examine and execute
@@ -7950,8 +7961,8 @@ looks fine.
    
 # mkdir bison
 # cd bison
 # mkdir patches
    -

    Create Makefile, DESCR and - PLIST (see Chapter 8, Package components - files, directories and contents) +

    Create Makefile, DESCR and + PLIST (see Chapter 8, Package components - files, directories and contents) then continue with fetching the distfile:

    # make fetch
 >> bison-1.25.tar.gz doesn't seem to exist on this system.
@@ -7967,7 +7978,7 @@ ftp: Error retrieving file: 500 Internal error
 Requesting ftp://ftp.freebsd.org/pub/FreeBSD/distfiles//bison-1.25.tar.gz (via ftp://orpheus.amdahl.com:80/)
 Successfully retrieved file.

    Generate the checksum of the distfile into - distinfo:

    + distinfo:

    # make makesum

    Now compile:

    # make
@@ -8167,83 +8178,91 @@ Registering depends:.
 
 
    
 
    
-Appendix C. Layout of the FTP server's package archive
    
-
    Layout for precompiled binary packages on ftp.NetBSD.org:
    
-
    -    /pub/NetBSD/packages/
-        distfiles/
-
-        # Unpacked pkgsrc trees
-        pkgsrc-current -> /pub/NetBSD/NetBSD-current/pkgsrc
-        pkgsrc-2003Q4 -> N/A
-        pkgsrc-2004Q1/pkgsrc
-
-        # pkgsrc archives
-        pkgsrc-current.tar.gz -> ../NetBSD-current/tar_files/pkgsrc.tar.gz
-        pkgsrc-2003Q4.tar.gz -> N/A
-        pkgsrc-2004Q1.tar.gz -> N/A
-
-        # Per pkgsrc-release/OS-release/arch package archives
-        pkgsrc-2003Q4/
-            NetBSD-1.6.2/
-                i386/
-                    All/
-                    archivers/
-                        foo -> ../All/foo
-                    ...
-        pkgsrc-2004Q1/
-            NetBSD-1.6.2/
-                i386/
-                    All/
-                    ...
-            NetBSD-2.0/
-                i386/
-                    All/
-                    ...
-            SunOS-5.9/
-                sparc/
-                    All/
-                    ...
-                x86/
-                    All/
-                    ...
-
-        # Per os-release package archive convenience links
-        NetBSD-1.6.2 -> 1.6.2
-        1.6.2/
-            i386 -> ../pkgsrc-2004Q1/NetBSD-1.6.2/i386
-            m68k/
-                All/
-                archivers/
-                    foo -> ../All/foo
-                ...
-            amiga -> m68k
-            atari -> m68k
-            ...
-
-        2.0 -> NetBSD-2.0       # backward compat, historic
-        NetBSD-2.0/
-            i386 -> ../pkgsrc-2004Q1/NetBSD-2.0/i386
-        SunOS-5.9/
-            sparc -> ../pkgsrc-2004Q1/SunOS-5.9/sparc
-            x86 -> ../pkgsrc-2004Q1/SunOS-5.9/x86
-
    
-
    
-    To create:
    
-
      
-
    1.  Run bulk build, see Section 6.3, “Doing a bulk build of all packages” 
      2. 
-
    2. 
-
       Upload /usr/pkgsrc/packages to 
      
-
      -    ftp://ftp.NetBSD.org/pub/NetBSD/packages/\
-        pkgsrc-2004Q4/\             # pkgsrc-branch
-        `uname -s`-`uname -r`/\     # OS & version
-        `uname -p`                  # architecture
-
      
-
      3. 
-
    3.  If necessary, create a symlink ln -s `uname -m` `uname
-      -p` (amiga -> m68k, ...) 
      4. 
-
    
+Appendix C. Directory layout of the pkgsrc FTP server
    
+
    
+
    Table of Contents
    
+
    
+
    C.1. bootstrap-pkgsrc: Bootstrap kits
    
+
    C.2. distfiles: The distributed source files
    
+
    C.3. iso: Currently empty
    
+
    C.4. misc: Miscellaneous things
    
+
    C.5. packages*: Binary packages
    
+
    C.6. current,
+200xQy:
+source packages
    
+
    
+
    
+
    As in other big projects, the directory layout of pkgsrc
+	is quite complex for newbies. This chapter explains where you
+	find things on the FTP server. The base directory on
+	ftp.NetBSD.org is /pub/pkgsrc.
+	This directory contains some subdirectories, which are explained
+	below.
    
+
    
+
    
+C.1. bootstrap-pkgsrc: Bootstrap kits
    
+
    For those who only want to manage binary packages on
+	systems other than NetBSD, we provide the package management
+	tools in a separate, small tar file.
    
+
    
+
    
+
    
+C.2. distfiles: The distributed source files
    
+
    The directory distfiles contains lots
+	of archive files from all pkgsrc packages, which are mirrored
+	here. The subdirectories are called after their package names
+	and are used when the distributed files have names that don't
+	explicitly contain a version number or are otherwise too generic
+	(for example release.tar.gz).
    
+
    
+
    
+
    
+C.3. iso: Currently empty
    
+
    This directory is currently not in use.
    
+
    
+
    
+
    
+C.4. misc: Miscellaneous things
    
+
    This directory contains things that individual pkgsrc
+	developers find worth publishing.
    
+
    
+
    
+
    
+C.5. packages*: Binary packages
    
+
    These directories contain binary packages. Those
+	directories that have a branch name
+	(200xQy)
+	contain packages from that particular branch. The directory
+	packages contains binary packages from
+	pkgsrc-current. (However, this does not necessarily mean that
+	the packages are still current anymore.)
    
+
    Below the packages* directories are
+	directories that distinguish the packages by operating system
+	and version, the next directory level specifies the hardware
+	architecture.
    
+
    In each of the platform-specific directories, there is a
+	whole binary packages collection. It has a directory called
+	All which contains all binary packages.
+	Besides that, there are various category directories that
+	contain symbolic links to the real binary packages.
    
+
    
+
    
+
    
+C.6. current,
+200xQy:
+source packages
    
+
    These directories contain the “real” pkgsrc,
+	that is the files that define how to create binary packages from
+	source archives.
    
+
    The directory pkgsrc contains a
+	snapshot of the CVS repository, which is updated on a regularly
+	basis. The file pkgsrc.tar.gz contains the
+	same as the directory, ready to be downloaded as a whole.
    
+
    In the directories for the quarterly branches, there is an
+	additional file called
+	pkgsrc-200xQy.tar.gz,
+	which contains the state of pkgsrc when it was branched.
    
+
    
 
 
    
 
    
@@ -8264,29 +8283,29 @@ Registering depends:.
 D.1. Targets
    
 
    
       The pkgsrc guide's source code is stored in
-      pkgsrc/doc/guide/files, and several files are
+      pkgsrc/doc/guide/files, and several files are
       created from it:
     
    
 
      
 
    • 
-          pkgsrc/doc/pkgsrc.txt
+          pkgsrc/doc/pkgsrc.txt
         
      • 
 
    • 
-          pkgsrc/doc/pkgsrc.html
+          pkgsrc/doc/pkgsrc.html
         
      • 
 
    • 
-          http://www.NetBSD.org/Documentation/pkgsrc/:
+          http://www.NetBSD.org/Documentation/pkgsrc/:
   	the documentation on the NetBSD website will be built from
   	pkgsrc and kept up to date on the web server itself. This
   	means you must make sure that your
   	changes haven't broken the build!
         
      • 
 
    • 
-          http://www.NetBSD.org/Documentation/pkgsrc/pkgsrc.pdf:
+          http://www.NetBSD.org/Documentation/pkgsrc/pkgsrc.pdf:
   	  PDF version of the pkgsrc guide.
         
      • 
 
    • 
-          http://www.NetBSD.org/Documentation/pkgsrc/pkgsrc.ps:
+          http://www.NetBSD.org/Documentation/pkgsrc/pkgsrc.ps:
   	  PostScript version of the pkgsrc guide.
         
      • 
 
    
@@ -8307,26 +8326,26 @@ Registering depends:.
           versions. You will need both packages installed, to make sure
           documentation is consistent across all formats. The packages
           can be found in
-          pkgsrc/meta-pkgs/netbsd-doc and
-          pkgsrc/meta-pkgs/netbsd-doc-print.
+          pkgsrc/meta-pkgs/netbsd-doc and
+          pkgsrc/meta-pkgs/netbsd-doc-print.
         
    
 
  • 
           Edit the XML file(s) in
-          pkgsrc/doc/guide/files.
+          pkgsrc/doc/guide/files.
         
    • 
 
  • 
           Run make extract && make do-lint in
-          pkgsrc/doc/guide to check the XML
+          pkgsrc/doc/guide to check the XML
           syntax, and fix it if needed.
         
    • 
 
  • 
           Run make in
-          pkgsrc/doc/guide to build the HTML and
+          pkgsrc/doc/guide to build the HTML and
           ASCII version.
         
    • 
 
  • 
           If all is well, run make install-doc to put
-          the generated files into pkgsrc/doc.
+          the generated files into pkgsrc/doc.
         
    • 
 
  • 
           cvs commit pkgsrc/doc/guide/files
diff --git a/doc/pkgsrc.txt b/doc/pkgsrc.txt
index fcceb281bd6..cac722d9389 100644
--- a/doc/pkgsrc.txt
+++ b/doc/pkgsrc.txt
@@ -347,7 +347,15 @@ B. Build logs
     B.1. Building figlet
     B.2. Packaging figlet
 
-C. Layout of the FTP server's package archive
+C. Directory layout of the pkgsrc FTP server
+
+    C.1. bootstrap-pkgsrc: Bootstrap kits
+    C.2. distfiles: The distributed source files
+    C.3. iso: Currently empty
+    C.4. misc: Miscellaneous things
+    C.5. packages*: Binary packages
+    C.6. current, 200xQy: source packages
+
 D. Editing guidelines for the pkgsrc guide
 
     D.1. Targets
@@ -638,7 +646,7 @@ a tar file, via SUP, or via CVS. All three ways are described here.
 
 The primary download location for all pkgsrc files is ftp://ftp.NetBSD.org/pub/
 pkgsrc/. There are a number of subdirectories for different purposes, which are
-described in detail in Appendix C, Layout of the FTP server's package archive.
+described in detail in Appendix C, Directory layout of the pkgsrc FTP server.
 
 The tar file for the current branch is in the directory current and is called
 pkgsrc.tar.gz. It is autogenerated daily.
@@ -6752,81 +6760,72 @@ Using SrcDir value of /usr/pkg
 Registering depends:.
 #
 
-Appendix C. Layout of the FTP server's package archive
-
-Layout for precompiled binary packages on ftp.NetBSD.org:
-
-    /pub/NetBSD/packages/
-        distfiles/
-
-        # Unpacked pkgsrc trees
-        pkgsrc-current -> /pub/NetBSD/NetBSD-current/pkgsrc
-        pkgsrc-2003Q4 -> N/A
-        pkgsrc-2004Q1/pkgsrc
-
-        # pkgsrc archives
-        pkgsrc-current.tar.gz -> ../NetBSD-current/tar_files/pkgsrc.tar.gz
-        pkgsrc-2003Q4.tar.gz -> N/A
-        pkgsrc-2004Q1.tar.gz -> N/A
-
-        # Per pkgsrc-release/OS-release/arch package archives
-        pkgsrc-2003Q4/
-            NetBSD-1.6.2/
-                i386/
-                    All/
-                    archivers/
-                        foo -> ../All/foo
-                    ...
-        pkgsrc-2004Q1/
-            NetBSD-1.6.2/
-                i386/
-                    All/
-                    ...
-            NetBSD-2.0/
-                i386/
-                    All/
-                    ...
-            SunOS-5.9/
-                sparc/
-                    All/
-                    ...
-                x86/
-                    All/
-                    ...
-
-        # Per os-release package archive convenience links
-        NetBSD-1.6.2 -> 1.6.2
-        1.6.2/
-            i386 -> ../pkgsrc-2004Q1/NetBSD-1.6.2/i386
-            m68k/
-                All/
-                archivers/
-                    foo -> ../All/foo
-                ...
-            amiga -> m68k
-            atari -> m68k
-            ...
-
-        2.0 -> NetBSD-2.0       # backward compat, historic
-        NetBSD-2.0/
-            i386 -> ../pkgsrc-2004Q1/NetBSD-2.0/i386
-        SunOS-5.9/
-            sparc -> ../pkgsrc-2004Q1/SunOS-5.9/sparc
-            x86 -> ../pkgsrc-2004Q1/SunOS-5.9/x86
-
-To create:
-
- 1. Run bulk build, see Section 6.3, "Doing a bulk build of all packages"
-
- 2. Upload /usr/pkgsrc/packages to
-
-        ftp://ftp.NetBSD.org/pub/NetBSD/packages/\
-            pkgsrc-2004Q4/\             # pkgsrc-branch
-            `uname -s`-`uname -r`/\     # OS & version
-            `uname -p`                  # architecture
-
- 3. If necessary, create a symlink ln -s `uname -m` `uname -p` (amiga -> m68k,
-    ...)
+Appendix C. Directory layout of the pkgsrc FTP server
+
+Table of Contents
+
+C.1. bootstrap-pkgsrc: Bootstrap kits
+C.2. distfiles: The distributed source files
+C.3. iso: Currently empty
+C.4. misc: Miscellaneous things
+C.5. packages*: Binary packages
+C.6. current, 200xQy: source packages
+
+As in other big projects, the directory layout of pkgsrc is quite complex for
+newbies. This chapter explains where you find things on the FTP server. The
+base directory on ftp.NetBSD.org is /pub/pkgsrc. This directory contains some
+subdirectories, which are explained below.
+
+C.1. bootstrap-pkgsrc: Bootstrap kits
+
+For those who only want to manage binary packages on systems other than NetBSD,
+we provide the package management tools in a separate, small tar file.
+
+C.2. distfiles: The distributed source files
+
+The directory distfiles contains lots of archive files from all pkgsrc
+packages, which are mirrored here. The subdirectories are called after their
+package names and are used when the distributed files have names that don't
+explicitly contain a version number or are otherwise too generic (for example
+release.tar.gz).
+
+C.3. iso: Currently empty
+
+This directory is currently not in use.
+
+C.4. misc: Miscellaneous things
+
+This directory contains things that individual pkgsrc developers find worth
+publishing.
+
+C.5. packages*: Binary packages
+
+These directories contain binary packages. Those directories that have a branch
+name (200xQy) contain packages from that particular branch. The directory
+packages contains binary packages from pkgsrc-current. (However, this does not
+necessarily mean that the packages are still current anymore.)
+
+Below the packages* directories are directories that distinguish the packages
+by operating system and version, the next directory level specifies the
+hardware architecture.
+
+In each of the platform-specific directories, there is a whole binary packages
+collection. It has a directory called All which contains all binary packages.
+Besides that, there are various category directories that contain symbolic
+links to the real binary packages.
+
+C.6. current, 200xQy: source packages
+
+These directories contain the "real" pkgsrc, that is the files that define how
+to create binary packages from source archives.
+
+The directory pkgsrc contains a snapshot of the CVS repository, which is
+updated on a regularly basis. The file pkgsrc.tar.gz contains the same as the
+directory, ready to be downloaded as a whole.
+
+In the directories for the quarterly branches, there is an additional file
+called pkgsrc-200xQy.tar.gz, which contains the state of pkgsrc when it was
+branched.
 
 Appendix D. Editing guidelines for the pkgsrc guide
 
-- 
cgit v1.2.3