path: root/pkgsrc.txt

The NetBSD Packages Collection (pkgsrc)

Alistair Crooks

   <agc@NetBSD.org>

Hubert Feyrer

   <hubertf@NetBSD.org>

   $NetBSD: pkgsrc.txt,v 1.2 2003/06/23 13:27:58 grant Exp $

   Copyright © 1994-2003 The NetBSD Foundation, Inc

   Abstract

   Information  about  using  the  NetBSD  package  system  and  building
   packages.
     _________________________________________________________________

   Table of Contents

   1. Introduction

        1.1. Introduction
        1.2. Overview
        1.3. Terminology
        1.4. Typography

   I. pkgsrc user's guide

        2. Using pkgsrc on systems other than NetBSD

              2.1. Bootstrapping pkgsrc
              2.2. Platform specific notes

        3. Using The NetBSD package system

              3.1. Working with binary packages
              3.2. Building packages from source

        4. Creating binary packages

              4.1. Building a single binary package
              4.2. Settings for creation of binary packages
              4.3. Doing a bulk build of all packages
              4.4. Creating a multiple CD-ROM packages collection

   II. pkgsrc developer's guide

        5. Package components - files, directories and contents

              5.1. Makefile
              5.2. distinfo
              5.3. patches/*
              5.4. Other mandatory files
              5.5. Optional files
              5.6. work*
              5.7. files/*
              5.8. Portability of packages

        6. PLIST issues

              6.1. Miscellaneous
              6.2. PLIST_SRC
              6.3. PLIST_SUBST
              6.4. Perl5 modules
              6.5. User Interaction

        7. Notes on fixes for packages

              7.1. CPP defines
              7.2. Shared libraries - libtool
              7.3. Using libtool on GNU packages that already support
                      libtool

              7.4. GNU Autoconf/Automake
              7.5. Package configuration files
              7.6. Feedback to the author

        8. The build process

              8.1. Program location
              8.2. Main targets
              8.3. Other helpful targets

        9. buildlink2 methodology

              9.1. Converting packages to use buildlink2
              9.2. Writing buildlink2.mk files

        10. Debugging
        11. FAQs & features of the package system

              11.1. Packages using GNU autoconf
              11.2. Other distrib methods than .tar.gz
              11.3. Packages not creating their own subdirectory
              11.4. Custom configuration process
              11.5. Packages not building in their DISTNAME directory
              11.6. How to fetch all distfiles at once
              11.7. How to fetch files from behind a firewall
              11.8. If your patch contains an RCS ID
              11.9. How to pull in variables from /etc/mk.conf
              11.10. Is there a mailing list for pkg-related discussion?
              11.11. How do I tell make fetch to do passive FTP?
              11.12. Dependencies on other packages
              11.13. Conflicts with other packages
              11.14. Software which has a WWW Home Page
              11.15. How to handle modified distfiles with the 'old' name

              11.16. What does "Don't know how to make
                      /usr/share/tmac/tmac.andoc" mean?

              11.17. How to handle incrementing versions when fixing an
                      existing package

              11.18. Could not find bsd.own.mk - what's wrong?
              11.19. Restricted packages
              11.20. Packages using (n)curses
              11.21. Automated security check
              11.22. What's the proper way to create an account from a
                      package?

              11.23. How to handle compiler bugs
              11.24. Packages providing info files
              11.25. Packages whose distfiles aren't available for plain
                      downloading

              11.26. Configuration files handling and placement
              11.27. Packages providing login shells
              11.28. Packages providing locale catalogues
              11.29. Using 'sudo' with pkgsrc
              11.30. Packages containing perl scripts
              11.31. Packages that cannot or should not be built

        12. Submitting and Committing

              12.1. Submitting your packages
              12.2. Committing: Importing a package into CVS
              12.3. Updating a Package to a Newer Version
              12.4. Moving a Package in pkgsrc

   A. A simple example of a package: bison

        A.1. files
        A.2. Steps for building, installing, packaging

   B. Build logs

        B.1. Building top
        B.2. Packaging top

   C. Layout of the FTP server's package archive

Chapter 1. Introduction

   Table of Contents

   1.1. Introduction
   1.2. Overview
   1.3. Terminology
   1.4. Typography

1.1. Introduction

   The  NetBSD  package  system,  pkgsrc,  is  a  framework  for building
   third-party software on NetBSD and other UNIX-like systems. It is used
   to  enable  such  freely available software to be configured and built
   easily on supported platforms.

   Once  the  software  has  been built, it is manipulated with the pkg_*
   tools  so  that  installation  and  de-installation,  printing  of  an
   inventory of all installed packages and retrieval of one-line comments
   or more verbose descriptions are all simple.

   pkgsrc currently contains over 3500 packages, including:
     * www/apache - The Apache web server
     * www/mozilla - The Mozilla web browser
     * x11/gnome - The GNOME Desktop Environment
     * x11/kde3 - The K Desktop Environment

   ...just to name a few.

   pkgsrc has built-in support for handling varying dependencies, such as
   pthreads  and  X11,  and  extended  features such as IPv6 support on a
   range of platforms.

   pkgsrc  was  originally  developed  on  NetBSD,  and  now supports the
   following platforms:
     * Darwin (Mac OS X)
     * FreeBSD
     * IRIX
     * Linux
     * NetBSD (of course)
     * OpenBSD
     * Solaris

1.2. Overview

   This  document  is  divided  into  two parts. The first, pkgsrc user's
   guide,  describes  how  one can use one of the packages in the Package
   Collection,  either  by installing a precompiled binary package, or by
   building  one's  own  copy using the NetBSD package system. The second
   part,  pkgsrc  developer's guide, explains how to prepare a package so
   it can be easily built by other NetBSD users without knowing about the
   package's building details.

1.3. Terminology

   There  has  been a lot of talk about "ports", "packages", etc. so far.
   Here  is  a  description  of  all  the  terminology  used  within this
   document.
     * Package
       A  set  of  files  and  building instructions that describe what's
       necessary  to  build  a certain piece of software using the NetBSD
       package   system.   Packages   are   traditionally   stored  under
       /usr/pkgsrc.
     * The NetBSD package system
       This  is the part of the NetBSD operating system handling building
       (compiling), installing, and removing of packages.
     * Distfile
       This  term  describes  the  file or files that are provided by the
       author of the piece of freely available software to distribute his
       work.  All  the changes necessary to build on NetBSD are reflected
       in  the corresponding package. Usually the distfile is in the form
       of  a  compressed  tar-archive, but other types are possible, too.
       Distfiles are stored below /usr/pkgsrc/distfiles.
     * Port
       This  is  the  term  used  by  FreeBSD  people  for what we call a
       package.  In  NetBSD  terminology,  "port"  refers  to a different
       architecture.
     * Precompiled (binary) package
       A  set  of  binaries  built  by  the  NetBSD package system from a
       distfile using the NetBSD package system 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
       generated  in  /usr/pkgsrc/packages  by the NetBSD package system;
       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.
     * Program
       The  piece  of  software to be installed which will be constructed
       from  all  the files in the Distfile by the actions defined in the
       corresponding package.

1.4. Typography

   When  giving  examples for commands, shell prompts are used to show if
   the  command  should/can  be  issued  as  root,  or  if  "normal" user
   privileges are sufficient. We use a "#" for root's shell prompt, and a
   "%" for users' shell prompt, assuming they use the C-shell or tcsh.

pkgsrc user's guide

   Table of Contents

   2. Using pkgsrc on systems other than NetBSD

        2.1. Bootstrapping pkgsrc
        2.2. Platform specific notes

   3. Using The NetBSD package system

        3.1. Working with binary packages
        3.2. Building packages from source

   4. Creating binary packages

        4.1. Building a single binary package
        4.2. Settings for creation of binary packages
        4.3. Doing a bulk build of all packages
        4.4. Creating a multiple CD-ROM packages collection

Chapter 2. Using pkgsrc on systems other than NetBSD

   Table of Contents

   2.1. Bootstrapping pkgsrc
   2.2. Platform specific notes

2.1. Bootstrapping pkgsrc

   For Operating Systems other than NetBSD, we provide a bootstrap kit to
   build  the  required  tools to use pkgsrc on your platform. As well as
   native  NetBSD  support, pkgsrc and the bootstrap kit have support for
   the following operating systems:
     * Darwin (Mac OS X)
     * FreeBSD
     * IRIX
     * Linux
     * OpenBSD
     * Solaris

   Support for other platforms is under development.

   Installing the bootstrap kit should be as simple as:
# cvs checkout othersrc/bootstrap-pkgsrc
# cd othersrc/bootstrap-pkgsrc
# ./bootstrap

   This  will use the defaults of /usr/pkg for the prefix and /var/db/pkg
   for  the  package  database  directory. However, these can also be set
   using command-line parameters.

   Binary packages for the pkgsrc tools and an initial set of packages is
   available  for supported platforms. An up-to-date list of these can be
   found on www.pkgsrc.org.

2.2. Platform specific notes

   Here are some platform-specific notes you should be aware of.

2.2.1. Darwin (Mac OS X)

   Darwin  5.x  and  6.x  are  supported.  There are two methods of using
   pkgsrc on Mac OS X, by using a disk image, or a UFS partition.

   If  you  already  have a UFS partition, or have a spare partition that
   you  can  format  as UFS, it is recommended to use that instead of the
   disk  image.  It'll be somewhat faster and will mount automatically at
   boot time, where you must manually mount a disk image.

Note

   You cannot use a HFS+ file system for pkgsrc, because pkgsrc currently
   requires the filesystem to be case-sensitive, and HFS+ is not.

2.2.1.1. Using a disk image

   Create the disk image:
# cd bootstrap-pkgsrc
# ./ufsdiskimage create ~/Documents/NetBSD 512 # megabytes - season to taste
# ./ufsdiskimage mount ~/Documents/NetBSD
# sudo chown `id -u`:`id -g` /Volumes/NetBSD

   That's it!

2.2.1.2. Using a UFS partition

   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 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 --pkgsrc=/Volumes/ufs/pkgsrc

   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  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".

   The  problem  is that none of the disk tools will let you touch a disk
   that  is  booted  from. You can unmount the partition, but even if you
   newfs  it,  the  partition  type will be incorrect and the automounter
   won't  mount  it.  It  can be mounted manually, but it won't appear in
   Finder.

   You'll  need  to boot off of the OS X Installation (User) CD. When the
   Installation  program  starts,  go  up  to  the  menu  and select Disk
   Utility.  Now, you will be able to select the partition you want to be
   UFS,  and  Format  it  Apple  UFS.  Quit  the  Disk  Utility, quit the
   installer which will reboot your machine. The new UFS file system will
   appear in Finder.

   Be  aware that the permissions on the new file system will be writable
   by root only.

   This  note  is  as  of  10.2 (Jaguar) and applies to earlier versions.
   Hopefully Apple will fix Disk Utility in 10.3 (Panther).

2.2.2. FreeBSD

   FreeBSD 4.7 and 5.0 have been tested and are supported, other versions
   may work.

   Care  should  be taken so that the tools that this kit installs do not
   conflict with the FreeBSD userland tools. There are several steps:
    1. FreeBSD  stores  its  ports  pkg  database  in  /var/db/pkg. It is
       therefore  recommended  that you choose a different location (e.g.
       /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 good idea to move them out of the way to avoid confusion, e.g.

# cd /usr/sbin
# mv pkg_add pkg_add.orig
# mv pkg_create pkg_create.orig
# mv pkg_delete pkg_delete.orig
# mv pkg_info pkg_info.orig

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

2.2.3. IRIX

   IRIX 6.5 is tested and supported, other versions may work.

   You  will  need  a  working  C  compiler, either gcc or SGI's MIPS and
   MIPSpro  compiler  (cc/c89).  Please  set  the CC environment variable
   according to your preference.

   Please  make  sure  that  you  have  no  conflicting  CFLAGS  in  your
   environment  or  the /etc/mk.conf. Particularly, make sure that you do
   not  try to link n32 object files with lib64 or vice versa. Check your
   /etc/compiler.defaults!

2.2.4. OpenBSD

   OpenBSD 3.0 and 3.2 are tested and supported.

   Care  should  be taken so that the tools that this kit installs do not
   conflict with the OpenBSD userland tools. There are several steps:
    1. OpenBSD  stores  its  ports  pkg  database  in  /var/db/pkg. It is
       therefore  recommended  that you choose a different location (e.g.
       /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 good idea to move them out of the way to avoid confusion, e.g.

# cd /usr/sbin
# mv pkg_add pkg_add.orig
# mv pkg_create pkg_create.orig
# mv pkg_delete pkg_delete.orig
# mv pkg_info pkg_info.orig

    3. An    example    /etc/mk.conf    file    will    be    placed   in
       /etc/mk.conf.example  file  when  you  use  the  bootstrap script.
       OpenBSD's  make  program  uses  /etc/mk.conf as well. You can work
       around this by enclosing all the pkgsrc specific parts of the file
       with:

.ifdef BSD_PKG_MK
# pkgsrc stuff, e.g. insert bsd.pkg.defaults.mk or similar here
.else
# OpenBSD stuff
.endif

2.2.5. Solaris

   Solaris  2.6  through  9  are  supported.  You  will  need a working C
   compiler. Both gcc 2.95.3 and Sun WorkShop 5 have been tested.

   The  following  packages  are  required on Solaris 8 for the bootstrap
   process and to build packages.
     * SUNWsprot
     * SUNWarc
     * SUNWbtool
     * SUNWtoo
     * SUNWlibm

   Please note the use of GNU binutils on Solaris is not supported.

2.2.5.1. If you are using gcc

   It  makes  life much simpler if you only use the same gcc consistently
   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 package,
   then remove gcc used during bootstrapping.

2.2.5.2. If you are using Sun WorkShop

   You will need at least the following packages installed (from WorkShop
   5.0)
     * SPROcc - Sun WorkShop Compiler C 5.0
     * SPROcpl - Sun WorkShop Compiler C++ 5.0
     * SPROild - Sun WorkShop Incremental Linker
     * SPROlang - Sun WorkShop Compilers common components

   You should set CC, CXX and optionally, CPP in /etc/mk.conf, eg.
CC=     cc
CXX=    CC
CPP=    /usr/ccs/lib/cpp

   You may also want to build 64-bit binaries, eg.
   CFLAGS= -xtarget=ultra -xarch=v9

   Whichever  compiler you use, please ensure the compiler tools and your
   $prefix  are  in  your  PATH. This includes /usr/ccs/{bin,lib} and eg.
   /usr/pkg/{bin,sbin}.

Chapter 3. Using The NetBSD package system

   Table of Contents

   3.1. Working with binary packages
   3.2. Building packages from source

3.1. Working with binary packages

   This section describes how to find, retrieve and install a precompiled
   binary  package  that  someone  else already prepared for your type of
   machine.

3.1.1. How to get binary packages

   Precompiled  packages  are stored on ftp.NetBSD.org and its mirrors in
   the  directory  /pub/NetBSD/packages  for anonymous FTP access. Please
   pick  the  right  subdirectory there as indicated by uname -p. In that
   directory,   there   is  a  subdirectory  for  each  category  plus  a
   subdirectory All which includes the actual binaries in .tgz files. The
   category subdirectories use symbolic links to those files (this is the
   same directory layout as in /usr/pkgsrc/packages).

   This  same directory layout applies for CDROM distributions, only that
   the  directory  may be rooted somewhere else, probably somewhere below
   /cdrom.  Please  consult  your  CDROMs  documentation  for  the  exact
   location.

3.1.2. Installing binary packages

   If you have the files on a CDROM or downloaded them to your hard disk,
   you can install them with the following command (be sure to su to root
   first):
   # pkg_add /path/to/package.tgz

   If you have FTP access and you don't want to download the packages via
   FTP  prior  to  installation,  you can do this automatically by giving
   pkg_add an FTP URL:
# pkg_add ftp://ftp.NetBSD.org/pub/NetBSD/packages/<OS Ver>/<arch>/All/package.
tgz

   If  there is any doubt, the uname utility can be used to determine the
   <OS Ver>, and <arch> by running uname -rp.

   Also  note that any prerequisite packages needed to run the package in
   question  will  be installed, too, assuming they are present where you
   install from.

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

3.1.3. A word of warning

   Please  pay  very  careful attention to the warnings expressed in that
   manual  page  about the inherent dangers of installing binary packages
   which  you did not create yourself, and the security holes that can be
   introduced onto your system by indiscriminate adding of such files.

3.2. Building packages from source

   This  assumes  that  the package is already part of the NetBSD package
   system. If it is not, see Part II.

3.2.1. Requirements

   To  build  packages  from source on a NetBSD system the "comp" and the
   "text"  distribution  sets must be installed. If you want to build X11
   related  packages  the  "xbase"  and  "xcomp"  distribution  sets  are
   required, too.

3.2.1.1. Where to get pkgsrc

   There  are three ways to get pkgsrc. Either as a tar file, via SUP, or
   via CVS. All three ways are described here.

   To  get  the  package  source going, you need to get the pkgsrc.tar.gz
   file from ftp.NetBSD.org and unpack it into /usr/pkgsrc.

   As  an  alternative,  you  can  get  pkgsrc  via  the  Software Update
   Protocol, SUP. To do so, make sure your supfile has a line
   release=pkgsrc

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

   To  get  pkgsrc  via  CVS,  make  sure  you have cvs installed. If not
   present  on  your  system,  it  can  be found as precompiled binary on
   ftp.NetBSD.org.  To  do  an  initial (full) checkout of pkgsrc, do the
   following steps:
% setenv CVSROOT anoncvs@anoncvs.NetBSD.org:/cvsroot
% setenv CVS_RSH ssh
% cd /usr
% cvs checkout -P pkgsrc

   This  will  create  the  pkgsrc  directory  in  your /usr, and all the
   package  source  will  be  stored  under /usr/pkgsrc. To update pkgsrc
   after  the  initial checkout, make sure you have CVS_RSH set as above,
   then do:
% cd /usr/pkgsrc
% cvs -q update -dP

   Please  also  note  that it is possible to have multiple copies of the
   pkgsrc  hierarchy in use at any one time - all work is done relatively
   within the pkgsrc tree.

3.2.1.2. Fetching distfiles

   There  is  one  gotcha:  The  distribution  file  (i.e. the unmodified
   source)  must  exist on your system for the packages system to be able
   to  build  it.  If  it  does  not,  then  ftp  is  used  to  fetch the
   distribution files 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/bsd.pkg.defaults.mk  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,
   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.

3.2.1.3. How to build and install

   Once  the  distfile(s)  have  been  fetched,  building a package is as
   simple as changing into the package directory and running make:
% cd editors/vim
% make

   Installing  the  package  on  your  system  requires  you  to be root.
   However,  pkgsrc  has  a  just-in-time su feature, which allows you to
   only become root for the actual installation step. e.g.
% make install
===> Installing for top-3.5beta5
===> Becoming root@mofo to install top-3.5beta5.
/usr/bin/su Password: <password>
[...installation continues...]

   Taking  the top system 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, simply 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
   LOCALBASE=/usr/local  in your environment. Please note that you should
   use  a  root  which is dedicated to packages and not shared with other
   programs (ie, do not try and use LOCALBASE=/usr). Also, you should not
   try  to  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.

   There  is,  of  course,  one  exception  to  this  -  X11 packages are
   traditionally  installed  in  the  X11  tree.  The  definition used to
   identify the root of the X11 tree is the X11BASE definition.

   It  is  possible  to  install  X11 packages in the LOCALBASE tree, for
   which   you   must   install  the  pkgtools/xpkgwedge  package  -  see
   Section 8.1, "Program location" for further details.

   Some packages look in /etc/mk.conf to alter some configuration options
   at  build time. Have a look at pkgsrc/mk/bsd.pkg.defaults.mk to get an
   overview  of  what will be set there by default. Environment variables
   such  as  LOCALBASE,  and  X11BASE  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
   for  debugging  purposes,  or  out  of  simple  curiosity. A number of
   utility values have been added to help with this.
    1. If  you  invoke the make(1) command with PKG_DEBUG_LEVEL=2, then a
       huge amount of information will be displayed. For example,

% make patch PKG_DEBUG_LEVEL=2

       will  show  all the commands that are invoked, up to and including
       the "patch" stage.
    2. If  you  want  to  know the value of a certain make(1) definition,
       then  the  VARNAME  definition should be used, in conjunction with
       the show-var target. e.g.

% make show-var VARNAME=DISTFILES

       will show the expansion of the make(1) variable DISTFILES.

   If  you want to de-install and re-install a binary package that you've
   created (see next section), that you put into pkgsrc/packages manually
   or  that's  located  on  a  remote  FTP  server,  you  can use the the
   "bin-install"  target.  This target will install a binary package - if
   available  -  via  pkg_add, else do a make package. The list of remote
   FTP sites searched is kept in the variable BINPKG_SITE, which defaults
   to ftp.NetBSD.org. Any flags that should be added to pkg_add(8) can be
   put into BIN_INSTALL_FLAGS. See pkgsrc/mk/bsd.pkg.defaults.mk for more
   details.

   A final word of warning: If you setup a system that has a non-standard
   setting  for  LOCALBASE  (or X11BASE, for that matter), be sure to set
   that  before  any  packages  are installed, as you can not use several
   directories  for  the same purpose. Doing so will result in pkgsrc not
   being  able  to  properly  detect  your  installed  packages, and fail
   miserably.  Note  also  that  precompiled  binary packages are usually
   built  with the default LOCALBASE of /usr/pkg, and that you should not
   install any if you use a non-standard LOCALBASE.

Chapter 4. Creating binary packages

   Table of Contents

   4.1. Building a single binary package
   4.2. Settings for creation of binary packages
   4.3. Doing a bulk build of all packages
   4.4. Creating a multiple CD-ROM packages collection

4.1. Building a single binary package

   Once  you  have built and installed a package, you can create a binary
   package which can be installed on another system with pkg_add(1). This
   saves having to build the same package on a group of hosts and wasting
   CPU  time.  It also provides a simple means for others to install your
   package, should you distribute it.

   Create a binary package:
# cd sysutils/top
# make package

   This  will  build  and install your package (if not already done), and
   then  build a binary package from what was installed. You can then use
   the  pkg_*  tools  to  manipulate  it.  Binary packages are created by
   default  in  /usr/pkgsrc/packages,  in the form of a gzip or bzip2 tar
   file. See Section B.2, "Packaging top" for a continuation of the above
   sysutils/top example.

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

4.2. Settings for creation of binary packages

   See Section 8.3, "Other helpful targets".

4.3. Doing a bulk build of all packages

   If  you  want  to  get a full set of precompiled binary packages, this
   section  describes  how  to  get them. Beware that the bulk build will
   remove  all currently installed packages from your your system! Having
   a FTP server configured either on the machine doing the bulk builds or
   on  a  nearby  NFS  server  can help to make the packages available to
   everyone.  See  ftpd(8)  for more information. If you use a remote NFS
   server's  storage,  be sure to not actually compile on NFS storage, as
   this slows things down a lot.

4.3.1. Configuration

4.3.1.1. /etc/mk.conf

   You    may   want   to   set   things   in   /etc/mk.conf.   Look   at
   pkgsrc/mk/bsd.pkg.defaults.mk for details of the default settings. You
   will  want  to ensure that ACCEPTABLE_LICENSES meet your local policy.
   As used in this example, _ACCEPTABLE=yes accepts all licenses.
PACKAGES?=      ${_PKGSRCDIR}/packages/${MACHINE_ARCH}
WRKOBJDIR?=     /usr/tmp/pkgsrc   # build here instead of in pkgsrc
BSDSRCDIR=      /usr/src
BSDXSRCDIR=     /usr/xsrc         # for x11/xservers
OBJHOSTNAME?=   yes               # use work.`hostname`
FAILOVER_FETCH= yes               # insist on the correct checksum
PKG_DEVELOPER?= yes
_ACCEPTABLE=    yes

   If you wish to use xpkgwedge for the entire build, then add:
   BULK_PREREQ+= pkgtools/xpkgwedge

   Other packages which must be installed during the bulk build to modify
   the  build  behaviour  may  be added to the BULK_PREREQ variable. Note
   that  currently  the only package for which BULK_PREREQ makes sense is
   xpkgwedge.

4.3.1.2. build.conf

   In  pkgsrc/mk/bulk, copy "build.conf-example" to "build.conf" and edit
   it,  following the comments in that file. This is the config file that
   determines  where  log  files  are generated after the build, where to
   mail  the build report, where your pkgsrc is located and which user to
   su(8) to do a cvs update.

4.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 (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:
# echo "I do not have enough disk space to build this pig." \
    > pkgsrc/games/crafty-book-enormous/$BROKENF

   to  prevent the system from trying to build a particular package which
   requires nearly 3 Gb of disk space.

4.3.2. Other environmental considerations

   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  shell in the password
   file),  or  (re-)install it via pkg_add 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:
( cd /usr/pkgsrc/security/ssh ; make bulk-install )
if [ -f /usr/pkg/etc/rc.d/sshd ]; then
    /usr/pkg/etc/rc.d/sshd
fi

   Not doing so will result in you being not able to log in via ssh after
   the bulk build is finished or if the machine gets rebooted or crashes.
   You have been warned! :)

4.3.3. Operation

   Make sure you don't need any of the packages still installed.

Warning

   During the bulk build, all packages will be removed!

   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:
# cd /usr/pkgsrc
# sh mk/bulk/build

   If  for  some  reason  your last build didn't complete (power failure,
   system panic, ...), you can continue it by running:
   # sh mk/bulk/build restart

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

4.3.4. What it does

   The bulk builds consist of three steps:
    1. pre-build
       The  script updates your pkgsrc via (anon)cvs, then cleans out any
       broken distfiles, and removes all packages installed.
    2. the bulk build
       This  is  basically "make bulk-package" with an optimised order in
       which  packages  will  be built. Packages that don't require other
       packages  will be built first, and packages with many depends will
       be built later.
    3. post-build
       Generates a report that's placed in the directory 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 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 broken
   builds  to not waste time trying to rebuild them, and they can be used
   to debug these broken package builds later.

4.3.5. Disk space requirements

   Currently, roughly the following requirements are valid for 1.5/i386:
     * 1500MB - distfiles (NFS ok)
     * 1000MB - full set of all binaries (NFS ok)
     * 1500MB - temp space for compiling (local disk recommended)

   For 1.5/alpha:
     * 1300MB - full set of all binaries (NFS ok)

   Note  that  all  pkgs  will be de-installed as soon as they are turned
   into  a binary package, and that work-sources are removed, so there is
   no  huge  demand  to  disk space. Afterwards, if the package is needed
   again,  it  will be installed via "pkg_add" instead of building again,
   so there are no cycles wasted by recompiling.

4.3.6. Setting up a sandbox for chroot'ed builds

   If  you  don't  want  all  the pkgs nuked from a machine (rendering it
   useless  for  anything but pkg compiling), there is the possibility of
   doing the pkg bulk build inside a chroot environment.

   The  first  step  to  do  so  is  setting  up  a  chroot sandbox, e.g.
   /usr/sandbox. 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 are present and properly configured:
     * kernel

# cp /netbsd /usr/sandbox

     * /dev/*

# cd /usr/sandbox/dev ; sh MAKEDEV all

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

# cp /etc/resolv.conf /usr/sandbox/etc

     * working(!) mail config (hostname, sendmail.cf):

# cp /etc/mail/sendmail.cf /usr/sandbox/etc/mail

     * /etc/localtime (for security/smtpd):

# ln -sf /usr/share/zoneinfo/GMT /usr/sandbox/etc/localtime

     * /usr/src (system sources, for sysutils/aperture, net/ppp-mppe):

# ln -s ../disk1/cvs .
# ln -s cvs/src-1.6 src
# ln -s cvs/pkgsrc .

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

# mkdir /usr/sandbox/var/db/pkg

     * create /usr/pkg (not part of default install):

# mkdir /usr/sandbox/usr/pkg

     * checkout pkgsrc into /usr/sandbox/usr/pkgsrc:

# cd /usr/sandbox/usr
# cvs -d anoncvs@anoncvs.NetBSD.org:/cvsroot checkout -d -P pkgsrc

     * edit /etc/mk.conf, see Section 4.3.1.1, "/etc/mk.conf".
     * adjust mk/bulk/build.conf to suit your needs.

Note

   Don't forget to install X.

   If  you  are  a  developer  and  want  to  upload the resulting binary
   packages  to  ftp.NetBSD.org,  be  sure  you  are  using the default X
   version  for  your architecture and release (that is XFree86 3.3.6 for
   1.5.x,  and  XFree86  4.2.1  for NetBSD 1.6.1 on cats, i386 and macppc
   ports, 3.3.6 on all other ports).

   The  next  thing  you  need  is  a fresh checkout of pkgsrc (e.g. from
   anoncvs).  Do  not mount/link this to the copy of your pkgsrc tree you
   do  development  in,  as  this  will  likely  cause  problems!  Adjust
   .../pkgsrc/packages  and  .../pkgsrc/distfiles to point to some places
   outside the sandbox if you want to make the files public.

   When  the  chroot  sandbox  is setup, you can start the build with the
   following steps:
# cd /usr/sandbox/usr/pkgsrc
# sh mk/bulk/do-sandbox-build

   This  will just jump inside the sandbox and start building. At the end
   of the build, mail will be sent with the results of the build. Created
   binary pkgs will be in /usr/sandbox/usr/pkgsrc/packages (wherever that
   points/mounts to/from).

4.4. Creating a multiple CD-ROM packages collection

   After  your  bulk pkgsrc build has completed, you may wish to create a
   CD-ROM  set  of  the resulting binary packages to assist in installing
   packages  on  other  machines.  The 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
   given package on the same CD as that package.

4.4.1. Example of cdpack

   Complete documentation for cdpack is found in cdpack(1). 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 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, etc.)
   on  each  CD  in  the  collection, then you need to create a directory
   which contains these files. e.g.
# mkdir /tmp/common
# echo "This is a README" > /tmp/common/README
# echo "Another file" > /tmp/common/COPYING
# mkdir /tmp/common/bin
# echo "#!/bin/sh" > /tmp/common/bin/myscript
# echo "echo Hello world" >> /tmp/common/bin/myscript
# chmod 755 /tmp/common/bin/myscript

   Now create the images:
   # cdpack -x /tmp/common /usr/pkgsrc/packages/All /u2/images

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

pkgsrc developer's guide

   Table of Contents

   5. Package components - files, directories and contents

        5.1. Makefile
        5.2. distinfo
        5.3. patches/*
        5.4. Other mandatory files
        5.5. Optional files
        5.6. work*
        5.7. files/*
        5.8. Portability of packages

   6. PLIST issues

        6.1. Miscellaneous
        6.2. PLIST_SRC
        6.3. PLIST_SUBST
        6.4. Perl5 modules
        6.5. User Interaction

   7. Notes on fixes for packages

        7.1. CPP defines
        7.2. Shared libraries - libtool
        7.3. Using libtool on GNU packages that already support libtool
        7.4. GNU Autoconf/Automake
        7.5. Package configuration files
        7.6. Feedback to the author

   8. The build process

        8.1. Program location
        8.2. Main targets
        8.3. Other helpful targets

   9. buildlink2 methodology

        9.1. Converting packages to use buildlink2
        9.2. Writing buildlink2.mk files

   10. Debugging
   11. FAQs & features of the package system

        11.1. Packages using GNU autoconf
        11.2. Other distrib methods than .tar.gz
        11.3. Packages not creating their own subdirectory
        11.4. Custom configuration process
        11.5. Packages not building in their DISTNAME directory
        11.6. How to fetch all distfiles at once
        11.7. How to fetch files from behind a firewall
        11.8. If your patch contains an RCS ID
        11.9. How to pull in variables from /etc/mk.conf
        11.10. Is there a mailing list for pkg-related discussion?
        11.11. How do I tell make fetch to do passive FTP?
        11.12. Dependencies on other packages
        11.13. Conflicts with other packages
        11.14. Software which has a WWW Home Page
        11.15. How to handle modified distfiles with the 'old' name
        11.16. What does "Don't know how to make
                /usr/share/tmac/tmac.andoc" mean?

        11.17. How to handle incrementing versions when fixing an
                existing package

        11.18. Could not find bsd.own.mk - what's wrong?
        11.19. Restricted packages
        11.20. Packages using (n)curses
        11.21. Automated security check
        11.22. What's the proper way to create an account from a package?

        11.23. How to handle compiler bugs
        11.24. Packages providing info files
        11.25. Packages whose distfiles aren't available for plain
                downloading

        11.26. Configuration files handling and placement
        11.27. Packages providing login shells
        11.28. Packages providing locale catalogues
        11.29. Using 'sudo' with pkgsrc
        11.30. Packages containing perl scripts
        11.31. Packages that cannot or should not be built

   12. Submitting and Committing

        12.1. Submitting your packages
        12.2. Committing: Importing a package into CVS
        12.3. Updating a Package to a Newer Version
        12.4. Moving a Package in pkgsrc

Chapter 5. Package components - files, directories and contents

   Table of Contents

   5.1. Makefile
   5.2. distinfo
   5.3. patches/*
   5.4. Other mandatory files
   5.5. Optional files
   5.6. work*
   5.7. files/*
   5.8. Portability of packages

   Whenever  you're  preparing  a  package,  there  are a number of files
   involved which are described in the following sections.

5.1. Makefile

   Building,  installation  and  creation  of  a  binary  package are all
   controlled by the package's Makefile.

   There  is a Makefile for each package. This file includes the standard
   bsd.pkg.mk  file  (referenced  as ../../mk/bsd.pkg.mk), which sets all
   the  definitions  and actions necessary for the package to compile and
   install  itself.  The  mandatory  variables  are  the  DISTNAME  which
   specifies the base name of the distribution file to be downloaded from
   the  site  on  the  Internet,  MASTER_SITES which specifies that site,
   CATEGORIES  which denotes the categories into which the package falls,
   PKGNAME which is the name of the package, the MAINTAINER name, and the
   COMMENT  variable,  which should contain a one-line description of the
   package  (the  package  name  should  not  appear,  it  will  be added
   automatically).  The  maintainer  variable is there so that anyone who
   quibbles  with  the (always completely correct) decisions taken by the
   guy who maintains the port can complain vigorously.

   The MASTER_SITES may be set to one of the predefined sites:
${MASTER_SITE_XCONTRIB}
${MASTER_SITE_GNU}
${MASTER_SITE_PERL_CPAN}
${MASTER_SITE_TEX_CTAN}
${MASTER_SITE_SUNSITE}
${MASTER_SITE_GNOME}
${MASTER_SITE_SOURCEFORGE}

   If  one  of  these  predefined  sites  is  chosen, you may require the
   ability to specify a subdirectory of that site. Since these macros may
   expand  to  more  than  one  actual  site,  you must use the following
   construct to specify a subdirectory:
   ${MASTER_SITE_GNU:=subdirectory/name/}

   Note the trailing slash after the subdirectory name.

Note

   MASTER_SITE_SUBDIR has been deprecated and should no longer be used.

   If  the  package  has  multiple  DISTFILES or multiple PATCHFILES from
   different sites, set SITES_foo to a list of URI's where file "foo" may
   be found. "foo" includes the suffix, e.g.
DISTFILES=      ${DISTNAME}${EXTRACT_SUFX}
DISTFILES+=     foo-file.tar.gz
SITES_foo-file.tar.gz=http://www.somewhere.com/somehow/ \
        http://www.somewhereelse.com/mirror/somehow/

   Note  that  the  normal  default  setting  of  DISTFILES  must be made
   explicit  if  you  want  to add to it (rather than replace it), as you
   usually would.

   Currently  the  following values are available for CATEGORIES. If more
   than one is used, they need to be separated by spaces:
archivers  audio      benchmarks   biology       cad
chat       comms      converters   cross         databases
devel      editors    emulators    finance       fonts
games      graphics   ham          japanese      lang
mail       math       mbone        misc          net
news       parallel   print        security      shells
sysutils   textproc   time         wm            www
x11

   Please pay attention to the following gotchas:
     * Add  MANCOMPRESSED if manpages are installed in compressed form by
       the package; see comment in bsd.pkg.mk.
     * Replace  /usr/local  with  "${PREFIX}"  in all files (see patches,
       below).
     * If  the  package  installs  any  info  files,  see  Section 11.24,
       "Packages providing info files".
     * Adjust  MAINTAINER  to be either yourself, if you plan to maintain
       the  package  for  future  updates,  or  set  it  to  the  default
       maintainer <tech-pkg@NetBSD.org>.
     * If  there  exists a home page for the software in question, please
       add  the  variable  HOMEPAGE  right after MAINTAINER. The value of
       this variable should be the URL for the home page.
     * Be  sure to set the COMMENT variable to a short description of the
       package.

5.2. distinfo

   Most  important, the mandatory message digest, or checksum, of all the
   distfiles needed for the package to compile, confirming they match the
   original  file  distributed  by  the  author.  This  ensures  that the
   distfile  retrieved  from  the  Internet has not been corrupted during
   transfer or altered by a malign force to introduce a security hole. It
   is best generated using the make makesum command. The digest algorithm
   used  was,  at  one  stage, md5, but that was felt lacking compared to
   sha1,  and  so sha1 is now the default algorithm. The distfile size is
   also  generated  and stored in new distinfo files. The pkgtools/digest
   utility  calculates  all  of  the digests in the distinfo file, and it
   provides  various  different  algorithms.  At  the  current  time, the
   algorithms provided are: md5, rmd160, sha1, sha256, sha384 and sha512.

   Some  packages  have different sets of distfiles on a per architecture
   basis  (a  good  example is 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.

   The  message digest/checksum for all the official patches found in the
   patches/  directory  (see Section 5.3, "patches/*") for the package is
   also stored in the distinfo file. This is a message digest/checksum of
   all  lines  in  the  patch file except the NetBSD RCS Id. This file is
   generated by invoking make makepatchsum.

5.3. patches/*

   This directory contains files that are used by the patch(1) command to
   modify the sources as distributed in the distribution file into a form
   that  will  compile and run perfectly on NetBSD. The files are applied
   successively   in   alphabetic   order   (as   returned   by  a  shell
   "patches/patch-*"  glob  expansion),  so  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).  Furthermore, do not put changes for more
   than  one  file  into  a  single  patch-file, as this will make future
   modifications more difficult.

   Similar,  a  file should be patched at most once, not several times by
   several  different  patches.  If  a  file  needs several patches, they
   should be combined into one file.

   One important thing to mention is to pay attention that no RCS IDs get
   stored  in  the  patch  files, as these will cause problems when later
   checked  into the NetBSD CVS tree. Use the 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 cp -p filename
   filename.orig or, easier, by using pkgvi 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 5.2, "distinfo".

   If  it  is  desired  to store any patches that should not be committed
   into  pkgsrc,  they  can  be  kept  outside  the  pkgsrc  tree  in the
   $LOCALPATCHES  directory. The 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  example  if  you want to keep a private
   patch for 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.

5.4. Other mandatory files

     * 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
       This file governs the files that are installed on your system: all
       the  binaries, manual pages, etc. There are other directives which
       may  be entered in this file, to control the creation and deletion
       of directories, and the location of inserted files.

5.5. Optional files

     * INSTALL
       Shell  script  invoked  twice  during  pkg_add.  First  time after
       package extraction and before files are moved in place, the second
       time  after  the  files to install are moved in place. This can be
       used  to do any custom procedures not possible with @exec commands
       in PLIST. See pkg_add(1) and pkg_create(1) for more information.
     * 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
       Display  this  file  after installation of the package. Useful for
       things  like  legal  notices  on almost-free software, etc. Please
       note  that  you  can  modify  variables  in  it  easily  by  using
       MESSAGE_SUBST in the package's Makefile:

MESSAGE_SUBST+=  SOMEVAR="somevalue"

       replaces "${SOMEVAR}" with "somevalue" in MESSAGE.

5.6. work*

   When  you  type  make  the  distribution  files are unpacked into this
   directory. It can be removed by running make clean.

   This directory is also used to keep various timestamp files.

5.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 the creation of this file.

5.8. Portability of packages

   One  appealing  feature  of  pkgsrc  is that it runs on many different
   platforms.  As  a  result,  it is important to ensure, where possible,
   that  packages  in  pkgsrc  are  portable.  There  are some particular
   details you should pay attention to while working on pkgsrc.

5.8.1. ${INSTALL}, ${INSTALL_DATA_DIR}, ...

   The  BSD-compatible  install supplied with some operating systems will
   not  perform  more  than  one operation at a time. As such, you should
   call "${INSTALL}", etc. like this:
${INSTALL_DATA_DIR} ${PREFIX}/dir1
${INSTALL_DATA_DIR} ${PREFIX}/dir2

Chapter 6. PLIST issues

   Table of Contents

   6.1. Miscellaneous
   6.2. PLIST_SRC
   6.3. PLIST_SUBST
   6.4. Perl5 modules
   6.5. User Interaction

   This  section  addresses  some  special  issues  that one needs to pay
   attention to when dealing with the PLIST file (or files, see below!).

6.1. Miscellaneous

     * NetBSD RCS Id
       Be  sure to add a RCS ID line as the first thing in any PLIST file
       you write:

@comment $NetBSD: pkgsrc.txt,v 1.2 2003/06/23 13:27:58 grant Exp $

     * ${MACHINE_ARCH}, ${MACHINE_GNU_ARCH}
       Some  packages  like  emacs and perl embed information about which
       architecture  they  were  built  on  into the pathnames where they
       install   their   file.   To  handle  this  case,  PLIST  will  be
       preprocessed    before    actually    used,    and    the   symbol
       "${MACHINE_ARCH}"  will  be  replaced  by what uname -p gives. The
       same  is  done  if  the  string ${MACHINE_GNU_ARCH} is embedded in
       PLIST  somewhere  -  use  this  on packages that have GNU autoconf
       created configure scripts.
       Legacy note: There used to be a symbol "<$ARCH>" that was replaced
       by  the output of uname -m, but that's no longer supported and has
       been removed.
     * ${OPSYS}, ${LOWER_OPSYS}, ${OS_VERSION}
       Some  packages  want  to  embed  the OS name and version into some
       paths. To do this, use these variables in the PLIST:
          + ${OPSYS} - output of "uname -s"
          + ${LOWER_OPSYS} - lowercase common name (eg. "solaris")
          + ${OS_VERSION} - "uname -r"
     * ${PKGLOCALEDIR}
       Packages  that  install locale files should list them in the PLIST
       as    "${PKGLOCALEDIR}/locale/de/LC_MESSAGES/..."    instead    of
       "share/locale/de/LC_MESSAGES/...".  This properly handles the fact
       that  different  OS's expect locale files to be either in share or
       lib by default.
     * Manpage-compression
       Manpages should be installed in compressed form if MANZ is set (in
       bsd.own.mk),  and  uncompressed  otherwise.  To handle this in the
       PLIST file, the suffix ".gz" is appended/removed automatically for
       manpages 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.
     * Platform specific and differing PLISTs
       Some  packages decide to install a different set of files based on
       the   operating  system  being  used.  These  differences  can  be
       automatically handled by using the following files:
          + PLIST.common
          + PLIST.${OPSYS}
          + PLIST.common_end
       If  PLIST.${OPSYS}  exists, these files are used instead of PLIST.
       This  allows  packages  which  behave  in  this  way to be handled
       gracefully.  Manually  overriding  PLIST_SRC for other more exotic
       uses is also possible.
     * 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 below
       for more information on this target.

6.2. PLIST_SRC

   To  use  one  or more files as source for the PLIST used in generating
   the  binary  package,  set the variable PLIST_SRC to the names of that
   file(s).  The  files are later concatenated using cat(1), and order of
   things is important.

6.3. PLIST_SUBST

   Similar  to MESSAGE_SUBST (see above), you can add variables and their
   expansions to this variable in the following way:
   PLIST_SUBST+=    SOMEVAR="somevalue"

   which  replaces  all  occurrences  of  "${SOMEVAR}"  in the PLIST with
   "somevalue". For the values which are replaced by default, please look
   in bsd.pkg.mk (and search for PLIST_SUBST).

6.4. Perl5 modules

   Makefile  of  packages  providing  perl5  modules  should  include the
   makefile  fragment  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 details.

   Perl5  modules  will  install  into  different places depending on the
   version  of  perl  used during the build process. To address this, the
   NetBSD packages system will append lines to the 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:
   PERL5_PACKLIST= ${PERL5_SITEARCH}/auto/Pg/.packlist

   The   variables   PERL5_SITELIB,   PERL5_SITEARCH,  and  PERL5_ARCHLIB
   represent the three locations in which perl5 modules may be installed,
   and  may  be  used by perl5 packages that don't have a packlist. These
   three variables are also substituted for in the PLIST.

6.5. User Interaction

   Occasionally, packages require interaction from the user, and this can
   be in a number of ways:
     * help in fetching the distfiles
     * help to configure the package before it is built
     * help during the build process
     * help during the installation of a package

   The  INTERACTIVE_STAGE  definition  is  provided  to notify the pkgsrc
   mechanism  of  an  interactive  stage  which  will be needed, and this
   should be set in the package's Makefile. e.g.
   INTERACTIVE_STAGE= build

   Multiple interactive stages can be specified:
   INTERACTIVE_STAGE= configure install

Chapter 7. Notes on fixes for packages

   Table of Contents

   7.1. CPP defines
   7.2. Shared libraries - libtool
   7.3. Using libtool on GNU packages that already support libtool
   7.4. GNU Autoconf/Automake
   7.5. Package configuration files
   7.6. Feedback to the author

7.1. CPP defines

   To  port  an  application  to  NetBSD,  it's usually necessary for the
   compiler  to  be able to judge the system on which it's compiling, and
   we use definitions so that the C pre-processor can do this.

   To  test  whether  you  are  working  on a 4.4 BSD-derived system, you
   should  use  the  BSD definition, which is defined in <sys/param.h> on
   said systems.
   #include <sys/param.h>

   and  then  you  can surround the BSD-specific parts of your port using
   the conditional:
#if (defined(BSD) && BSD >= 199306)
  ...
#endif

   Please  use  the  "__NetBSD__"  definition  sparingly - it should only
   apply  to  features  of  NetBSD that are not present in other 4.4-lite
   derived BSDs.

7.2. Shared libraries - libtool

   pkgsrc supports many different machines, with different object formats
   like  a.out  and  ELF,  and varying abilities to do shared library and
   dynamic  loading  at  all.  To  accompany  this,  varying commands and
   options  have  to  be  passed to the compiler, linker, etc. to get the
   Right Thing, which can be pretty annoying especially if you don't have
   all  the  machines  at your hand to test things. The devel/libtool pkg
   can help here, as it just "knows" how to build both static and dynamic
   libraries from a set of source files, thus being platform independent.

   Here's how to use libtool in a pkg in seven simple steps:
    1. Add USE_LIBTOOL=yes to the package Makefile.
    2. For  library  objects,  use  "${LIBTOOL}  --mode=compile ${CC}" in
       place  of  "${CC}". You could even add it to the definition of CC,
       if  only  libraries  are being built in a given Makefile. This one
       command  will  build  both PIC and non-PIC library objects, so you
       need not have separate shared and non-shared library rules.
    3. For the linking of the library, remove any "ar", "ranlib", and "ld
       -Bshareable" commands, and use instead:

${LIBTOOL} --mode=link ${CC} -o ${.TARGET:.a=.la} ${OBJS:.o=.lo} -rpath ${PREFI
X}/lib -version-info major:minor

       Note  that the library is changed to have a .la extension, and the
       objects  are  changed  to  have  a  .lo  extension. Change OBJS as
       necessary.   This   automatically   creates   all   of   the   .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
       shared library version.
       The "-release" option will produce different results for a.out and
       ELF  (excluding  symlinks) in only one case. An ELF library of the
       form    "libfoo-release.so.x.y"    will    have   a   symlink   of
       "libfoo.so.x.y"   on   an   a.out   platform.   This   is  handled
       automatically.
       The  "-rpath  argument"  is  the  install directory of the library
       being built.
       In  the  PLIST, include all of the .a, .la, and .so, .so.major and
       .so.major.minor files.
    4. 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.
       PLIST gets the foo.so entry.
    5. When  linking  programs that depend on these libraries before they
       are  installed,  preface  the  cc  or  ld  line  with  "${LIBTOOL}
       --mode=link",  and  it  will find the correct libraries (static or
       shared),  but  please  be aware that libtool will not allow you to
       specify a relative path in -L (such as "-L../somelib"), because it
       expects you to change that argument to be the .la file. e.g.

${LIBTOOL} --mode=link ${CC} -o someprog -L../somelib -lsomelib

       should be changed to:

${LIBTOOL} --mode=link ${CC} -o someprog ../somelib/somelib.la

       and it will do the right thing with the libraries.
    6. When  installing libraries, preface the install or cp command with
       "${LIBTOOL}  --mode=install",  and change the library name to .la.
       e.g.

${LIBTOOL} --mode=install ${BSD_INSTALL_DATA} ${SOMELIB:.a=.la} ${PREFIX}/lib

       This  will  install  the  static  .a,  shared  library, any needed
       symlinks, and run ldconfig.

7.3. Using libtool on GNU packages that already support libtool

   Add  USE_LIBTOOL=yes  and  LTCONFIG_OVERRIDE=${WRKSRC}/ltconfig to the
   package Makefile as the quick way to bypass the pkg's own libtool. The
   pkg's  own  libtool  is  created  by  ltconfig  script at do-configure
   target.   If   USE_LIBTOOL  and  LTCONFIG_OVERRIDE  are  defined,  the
   specified  ltconfig  is overridden, using devel/libtool instead of the
   pkg's own libtool. For newer versions of libtool (without ltconfig) it
   may be necessary to use LIBTOOL_OVERRIDE=${WRKSRC}/libtool instead.

   If  your  package  makes  use  of the platform independent library for
   loading dynamic shared objects, that comes with libtool (libltdl), you
   should include the libtool buildlink2.mk (and set USE_BUILDLINK2=YES).

   Some packages use libtool incorrectly so that the package may not work
   or build in some circumstances. Some of the more common errors are:
     * The  inclusion of a shared object (-module) as a dependent library
       in an executable or library. This in itself isn't a problem if one
       of two things has been done:
         1. The  shared  object  is  named correctly, i.e. libfoo.la, not
            foo.la
         2. The -dlopen option is used when linking an executable.
     * The  use  of  libltdl  without the correct calls to initialisation
       routines.  The function lt_dlinit() should be called and the macro
       LTDL_SET_PRELOADED_SYMBOLS included in executables.

7.4. GNU Autoconf/Automake

   If  a  package  needs  GNU  autoconf  or  automake  to  be executed to
   regenerate  the  configure  script and Makefile.in makefile templates,
   then  they  should be executed in a pre-configure target. Two Makefile
   fragments     are     provided     in     pkgsrc/mk/autoconf.mk    and
   pkgsrc/mk/automake.mk  to  help dealing with these tools. See comments
   in these files for details.

   For packages that need only autoconf:
AUTOCONF_REQD=  2.50    # if default version is not good enough
...

pre-configure:
        cd ${WRKSRC}; ${AUTOCONF}

...
.include "../../mk/autoconf.mk"

   and for packages that need automake and autoconf:
AUTOMAKE_REQD=  1.7.1   # if default version is not good enough
...

pre-configure:
        cd ${WRKSRC};                                           \
        ${ACLOCAL};                                             \
        ${AUTOHEADER};                                          \
        ${AUTOMAKE} -a --foreign -i;                            \
        ${AUTOCONF}

...
.include "../mk/automake.mk"

   There are times when the configure process makes additional changes to
   the  generated  files,  which  then causes the build process to try to
   re-execute  the  automake  sequence.  This  is  prevented  by touching
   various  files  in  the  configure stage. If this causes problems with
   your package you can set AUTOMAKE_OVERRIDE=NO in the package Makefile.

7.5. Package configuration files

   Packages  should  be  taught  to look for their configuration files in
   ${PKG_SYSCONFDIR},  which is passed through to the configure and build
   processes. PKG_SYSCONFDIR may be customized in various ways by setting
   other make variables:
     * PKG_SYSCONFBASE  is  the  main  config  directory  under which all
       package  configuration  files  are  to  be found. This defaults to
       ${PREFIX}/etc, but may be overridden in /etc/mk.conf.
     * PKG_SYSCONFSUBDIR  is  the  subdirectory  of PKG_SYSCONFBASE under
       which  the  configuration  files  for  a particular package may be
       found,  e.g. the Apache configuration files may all be found under
       the  httpd/ subdirectory of ${PKG_SYSCONFBASE}. This should be set
       in the package Makefile.
     * By default,
       PKG_SYSCONFDIR=${PKG_SYSCONFBASE}/${PKG_SYSCONFSUBDIR},  but  this
       may  be overridden by setting PKG_SYSCONFDIR.${PKG_SYSCONFVAR} for
       a particular package, where PKG_SYSCONFVAR defaults to ${PKGBASE}.
       This is not meant to be set by a package Makefile, but is reserved
       for  users  who  wish to override the PKG_SYSCONFDIR setting for a
       particular package with a special location.

   The only variables that users should customize are PKG_SYSCONFBASE and
   PKG_SYSCONFDIR.${PKG_SYSCONFVAR}.  Users  will  typically  want to set
   PKG_SYSCONFBASE  to  /etc,  or  to  accept  the  default  location  of
   ${PREFIX}/etc.

7.6. Feedback to the author

   If  you  have found any bugs in the package you make available, if you
   had to do special steps to make it run under NetBSD or if you enhanced
   the  software  in  various other ways, be sure to report these changes
   back to the original author of the program! With that kind of support,
   the  next  release  of  the  program  can incorporate these fixes, and
   people not using the NetBSD packages system can win from your efforts.

   Support the idea of free software!

Chapter 8. The build process

   Table of Contents

   8.1. Program location
   8.2. Main targets
   8.3. Other helpful targets

   The  basic steps for building a program are always the same. First the
   program's  source  (distfile)  must be brought to the local system and
   then  extracted.  After  any patches to compile properly on NetBSD are
   applied,  the  software  can  be  configured,  then  built (usually by
   compiling),  and  finally the generated binaries, etc. can be put into
   place  on  the  system.  These  are exactly the steps performed by the
   NetBSD  package system, which is implemented as a series of targets in
   a central Makefile, pkgsrc/mk/bsd.pkg.mk.

8.1. Program location

   Before outlining the process performed by the NetBSD package system in
   the  next  section,  here's  a  brief discussion on where programs are
   installed, and which variables influence this.

   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  for  pkgs  in  the  "cross"  category, though its value
   becomes  that of X11BASE if USE_IMAKE or USE_X11BASE is set. The value
   of  PREFIX  needs  to  be put into the various places in the program's
   source  where  paths  to  these  files  are  encoded. See Section 5.3,
   "patches/*"  and  Section 7.2,  "Shared  libraries - libtool" for more
   details.

   When  choosing  which  of these variables to use, follow the following
   rules:
     * PREFIX always points to the location where the current pkg will be
       installed.  When  referring  to a pkg's own installation path, use
       "${PREFIX}".
     * LOCALBASE  is where all non-X11 pkgs are installed. If you need to
       construct a -I or -L argument to the compiler to find includes and
       libraries installed by another non-X11 pkg, use "${LOCALBASE}".
     * X11BASE  is where the actual X11 distribution (from xsrc, etc.) is
       installed.  When  looking  for  standard  X11  includes (not those
       installed by a pkg), use "${X11BASE}".
     * X11 based pkgs are special in that they may be installed in either
       X11BASE or LOCALBASE. To install X11 packages in LOCALBASE, simply
       install  pkgtools/xpkgwedge.  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  use  both  "${X11BASE}"  and
       "${LOCALBASE}".
     * X11PREFIX  should be used to refer to the installed location of an
       X11  package. X11PREFIX will be set to X11BASE if xpkgwedge is not
       installed, and to LOCALBASE if xpkgwedge is installed.
     * If  xpkgwedge  is  installed, it is possible to have some packages
       installed  in  X11BASE  and  some  in  LOCALBASE. To determine the
       prefix  of an installed package, the EVAL_PREFIX definition can be
       used.  It  takes  pairs in the format "DIRNAME=<package>", and the
       make(1)  variable  DIRNAME  will  be  set  to  the  prefix  of the
       installed  package  <package>, or "${X11PREFIX}" if the package is
       not installed.
       This is best illustrated by example.
       The following lines are taken from pkgsrc/wm/scwm/Makefile:

EVAL_PREFIX+=           GTKDIR=gtk+
CONFIGURE_ARGS+=        --with-guile-prefix=${LOCALBASE}        \
                        --with-gtk-prefix="${GTKDIR}"           \
                        --enable-multibyte

       Specific  defaults can be defined for the packages evaluated using
       EVAL_PREFIX, by using a definition of the form:

GTKDIR_DEFAULT= ${LOCALBASE}

       where   GTKDIR   corresponds   to  the  first  definition  in  the
       EVAL_PREFIX pair.

8.2. Main targets

   The  main  targets used during the build process defined in bsd.pkg.mk
   are:
     * fetch
       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 are not
       present,  an  attempt will be made to fetch them using commands of
       the form:

${FETCH_CMD} ${FETCH_BEFORE_ARGS} ${site}${file} ${FETCH_AFTER_ARGS}

       where ${site} varies through several possibilities in turn: first,
       MASTER_SITE_OVERRIDE  is tried, then the sites specified in either
       SITES_file  if  defined,  else  MASTER_SITES  or  PATCH_SITES,  as
       applies,  then  finally the value of MASTER_SITE_BACKUP. The order
       of  all except the first can be optionally sorted by the user, via
       setting either MASTER_SORT_AWK or MASTER_SORT_REGEX.
     * checksum
       After the distfile(s) are fetched, their checksum is generated and
       compared  with  the  checksums stored in the distinfo file. If the
       checksums don't match, the build is aborted. This is to ensure the
       same  distfile  is used for building, and that the distfile wasn't
       changed, e.g. by some malign force, deliberately changed distfiles
       on the master distribution site or network lossage.
     * extract
       When  the  distfiles are present on the local system, they need to
       be  extracted,  as they are usually in the form of some compressed
       archive  format,  most  commonly  .tar.gz.  If  only  some  of the
       distfiles  need  to  be uncompressed, the files to be uncompressed
       should  be  put  into  EXTRACT_ONLY.  If  the distfiles are not in
       .tar.gz  format,  they  can  be  extracted by setting EXTRACT_CMD,
       EXTRACT_BEFORE_ARGS and/or EXTRACT_AFTER_ARGS.
     * patch
       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) can be handed in PATCH_DIST_ARGS. See
       Section 5.3, "patches/*" for more details.
       By  default  patch  is  given  special args to make it fail if the
       patches with some lines of fuzz. Please fix (regen) the patches so
       that they apply cleanly. The rationale behind this is that patches
       that  apply  cleanly  may end up being applied in the wrong place,
       and cause severe harm there.
     * configure
       Most  pieces  of  software  need  information on the header files,
       system  calls, and library routines which are available in NetBSD.
       This  is  the  process  known  as  configuration,  and  is usually
       automated.  In  most  cases, a script is supplied with the source,
       and   its  invocation  results  in  generation  of  header  files,
       Makefiles, etc.
       If  the program's distfile contains its own configure script, this
       can  be  invoked by setting HAS_CONFIGURE. If the configure script
       is  a  GNU  autoconf  script,  GNU_CONFIGURE  should  be specified
       instead. In either case, any arguments to the configure script can
       be  specified  in  the  CONFIGURE_ARGS variable, and the configure
       script's  name  can  be set in CONFIGURE_SCRIPT if it differs from
       the default "configure".
       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 being run, set USE_X11BASE instead!)
     * build
       Once  configuration  has taken place, the software can be built on
       NetBSD  by invoking $MAKE_PROGRAM on $MAKEFILE with $ALL_TARGET as
       the  target  to  build.  The  default  MAKE_PROGRAM  is "gmake" if
       USE_GMAKE  is set, "make" otherwise. MAKEFILE is set to "Makefile"
       by  default,  and  ALL_TARGET  defaults  to  "all".  Any  of these
       variables can be set to change the default build process.
     * install
       Once  the  build stage has completed, the final step is to install
       the   software  in  public  directories,  for  users.  As  in  the
       build-target, $MAKE_PROGRAM is invoked on $MAKEFILE here, but with
       the  $INSTALL_TARGET  instead,  the latter defaulting to "install"
       (plus "install.man", if USE_IMAKE is set).

   If  no  target  is  specified, the default is "build". If a subsequent
   stage  is  requested,  all prior stages are made: e.g. make build will
   also perform the equivalent of:
make fetch
make checksum
make extract
make patch
make configure
make build

8.3. Other helpful targets

     * pre/post-*
       For any of the main targets described in the previous section, two
       auxiliary  targets  exist with "pre-" and "post-" used as a prefix
       for  the  main target's name. These targets are invoked before and
       after  the  main target is called, allowing extra configuration or
       installation  steps, for example, which program's configure script
       or install target omitted.
     * do-*
       Should  one  of  the  main  targets do the wrong thing, and should
       there  be  no  variable  to fix this, you can redefine it with the
       do-*  target.  (Note  that redefining the target itself instead of
       the  do-*  target  is  a bad idea, as the pre-* and post-* targets
       won't  be  called  anymore,  etc.) You will not usually need to do
       this.
     * reinstall
       If  you  did  a  make  install  and  you noticed some file was not
       installed  properly,  you  can  repeat  the installation with this
       target, which will ignore the "already installed" flag.
     * deinstall
       This  target  does  a  pkg_delete(1)  in  the  current  directory,
       effectively de-installing the package. The following variables can
       be  used either on the command line or in /etc/mk.conf to tune the
       behaviour:
          + PKG_VERBOSE
            Add a "-v" to the pkg_delete(1) command.
          + DEINSTALLDEPENDS
            Remove  all  packages  that  require  (depend  on)  the given
            package.  This  can  be  used to remove any packages that may
            have  been  pulled  in  by  a  given  package,  e.g.  if make
            deinstall  DEINSTALLDEPENDS=1 is done in pkgsrc/x11/kde, this
            is  likely  to  remove whole KDE. Works by adding "-R" to the
            pkg_delete command line.
     * update
       This target causes the current package to be updated to the latest
       version.   The  package  and  all  depending  packages  first  get
       de-installed,  then current versions of the corresponding packages
       get  compiled  and  installed.  This is similar to manually noting
       which  packages  are currently installed, then performing a series
       of  make  deinstall and make install (or whatever UPDATE_TARGET is
       set to) for these packages.
       You can use the "update" target to resume package updating in case
       a  previous  make update was interrupted for some reason. However,
       in  this  case,  make  sure you don't call make clean or otherwise
       remove  the  list  of  dependent packages in WRKDIR. Otherwise you
       lose the ability to automatically update the current package along
       with the dependent packages you have installed.
       Resuming  an interrupted make update will only work as long as the
       package  tree remains unchanged. If the source code for one of the
       packages to be updated has been changed, resuming 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 make update:
          + UPDATE_TARGET
            Install target to recursively use for the updated package and
            the  dependent  packages.  Defaults to DEPENDS_TARGET if set,
            "install"   otherwise  for  make  update.  e.g.  make  update
            UPDATE_TARGET=package
          + NOCLEAN
            Don't  clean  up  after updating. Useful if you want to leave
            the   work   sources  of  the  updated  packages  around  for
            inspection or other purposes. Be sure you eventually clean up
            the  source tree (see the "clean-update" target below) or you
            may run into troubles with old source code still lying around
            on your next make or make update.
          + REINSTALL
            Deinstall    each    package    before   installing   (making
            DEPENDS_TARGET).  This may be necessary if the "clean-update"
            target  (see  below)  was called after interrupting a running
            make update.
          + DEPENDS_TARGET
            Allows  you  to disable recursion and hardcode the target for
            packages.  The  default  is  "update"  for the update target,
            facilitating  a  recursive  update  of prerequisite packages.
            Only  set  DEPENDS_TARGET  if  you  want to disable recursive
            updates.  Use  UPDATE_TARGET  instead  to just set a specific
            target  for  each  package to be installed during make update
            (see above).
     * clean-update
       Clean  the  source tree for all packages that would get updated if
       make  update  was  called  from the current directory. This target
       should not be used if the current package (or any of its depending
       packages) have already been de-installed (e.g., after calling make
       update) or you may lose some packages you intended to update. As a
       rule  of thumb: only use this target before the first time you run
       make  update  and  only if you have a dirty package tree (e.g., if
       you used NOCLEAN).
       If  you  unsure  about  whether  your tree is clean you can either
       perform  a make clean at the top of the tree, or use the following
       sequence of commands from the directory of the package you want to
       update  (before  running make update for the first time, otherwise
       you lose all the packages you wanted to update!):

# make clean-update
# make clean CLEANDEPENDS=YES
# make update

       The  following variables can be used either on the command line or
       in /etc/mk.conf to alter the behaviour of make clean-update:
          + CLEAR_DIRLIST
            After  make clean, do not reconstruct the list of directories
            to  update  for  this  package.  Only use this if make update
            successfully  installed  all  packages  you wanted to update.
            Normally,  this is done automatically on make update, but may
            have been suppressed by the NOCLEAN variable (see above).
     * info
       This  target invokes pkg_info for the current package. You can use
       this to check which version of a package is installed.
     * readme
       This  target  generates  a  README.html  file, which can be viewed
       using  a  browser such as www/navigator or www/lynx. 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  on  the  local  machine,  in  the  directory
       /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 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 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   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/*)
     * 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  version  of  pkgsrc, then a warning message is
       displayed. This target can be used to show which of your installed
       packages  are  downlevel,  and so the old versions can be deleted,
       and the current ones added.
     * show-pkgsrc-dir
       This target shows the directory in the pkgsrc hierarchy from which
       the  package  can be built and installed. This may not be the same
       directory  as  the  one from which the package was installed. This
       target  is  intended  to be used by people who may wish to upgrade
       many  packages  on  a  single  host,  and  can be invoked from the
       top-level  pkgsrc  Makefile by using the "show-host-specific-pkgs"
       target.
     * show-installed-depends
       This  target  shows  which  installed  packages  match the current
       package's DEPENDS. Useful if out of date DEPENDS are causing build
       problems.
     * check-shlibs
       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.
     * 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
       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 diff the output
       of this command against an already 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 "find -newer" won't catch them!
     * bulk-package
       Used  to  do bulk builds. If an appropriate binary package already
       exists,  no  action  is  taken.  If not, this target will compile,
       install  and  package  it (and it's depends, if PKG_DEPENDS is set
       properly.  See  Section 4.3.1, "Configuration". After creating the
       binary  package,  the sources, the just-installed package and it's
       required packages are removed, preserving free disk space.
     * bulk-install
       Used  during  bulk-installs  to  install  required packages. If an
       appropriate  binary package is available, it will be installed via
       pkg_add.  If  not,  make  bulk-package  will  be executed, but the
       installed binary not be removed. A binary package is "appropriate"
       to be installed via pkg_add if:
          + 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.

Chapter 9. buildlink2 methodology

   Table of Contents

   9.1. Converting packages to use buildlink2
   9.2. Writing buildlink2.mk files

   buildlink2  is  a  pkgsrc  framework  that  controls  what headers and
   libraries  are seen by a package's configure and build processes. This
   is implemented in a two step process:
    1. Symlink headers and libraries for dependencies into BUILDLINK_DIR,
       which by default is a subdirectory of WRKDIR.
    2. Create  wrapper  scripts  that  are  used  in  place of the normal
       compiler   tools   that   translate  "-I${LOCALBASE}/include"  and
       "-L${LOCALBASE}/lib" into references to BUILDLINK_DIR.

   This  normalizes  the  environment in which a package is built so that
   the  package may be built consistently despite what may other software
   may installed. Please refer to pkgsrc/mk/buildlink2/buildlink2.txt for
   some    FAQs    and    answers    regarding    buildlink2,    and   to
   pkgsrc/mk/buildlink2/README  for  a  description  of how buildlink2 is
   implemented in pkgsrc.

9.1. Converting packages to use buildlink2

   The  process of converting packages to use the buildlink2 framework is
   fairly    straightforward.    The   package   Makefile   must   define
   USE_BUILDLINK2.  If a dependency on a particular package, e.g. foo, is
   required for its libraries and headers, then we replace:
   DEPENDS+=       foo>=1.1.0:../../category/foo

   with
   .include "../../category/foo/buildlink2.mk"

   There are several buildlink2.mk files in pkgsrc/mk that handle special
   package issues:
     * motif.buildlink2.mk    checks    for   a   system-provided   Motif
       installation or adds a dependency on x11/lesstif or x11/openmotif;
     * ossaudio.buildlink2.mk  defines several variables that may be used
       by packages that use the Open Sound System (OSS) API;
     * pthread.buildlink2.mk  uses  the  value of PTHREAD_OPTS and checks
       for native pthreads or adds a dependency on devel/pth as needed;
     * xaw.buildlink2.mk   uses   the  value  of  XAW_TYPE  to  choose  a
       particular Athena widgets library.

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

9.2. Writing buildlink2.mk files

   A  simple  example  of a buildlink2.mk file for a mythical package foo
   follows:
BUILDLINK_PACKAGES+=          foo
BUILDLINK_PKGBASE.foo=        foo
BUILDLINK_DEPENDS.foo?=       foo>=1.0
BUILDLINK_PKGSRCDIR.foo?=     ../../category/foo

EVAL_PREFIX+=                 BUILDLINK_PREFIX.foo=foo
BUILDLINK_PREFIX.foo_DEFAULT= ${LOCALBASE}
BUILDLINK_FILES.foo=          include/foo.h
BUILDLINK_FILES.foo+=         include/bar.h
BUILDLINK_FILES.foo+=         lib/libfoo.*

BUILDLINK_TARGETS+=           foo-buildlink

foo-buildlink: _BUILDLINK_USE

   The  first  section  controls  how the dependency on foo is added. The
   dependency is constructed from four parts:
    1. BUILDLINK_PACKAGES  is  the  global  list  of  packages  for which
       dependencies will be added by buildlink2;
    2. BUILDLINK_DEPENDS.foo  is  the  actual  dependency recorded in the
       installed package;
    3. BUILDLINK_PKGSRCDIR.foo   is   the  location  of  the  foo  pkgsrc
       directory;
    4. BUILDLINK_DEPMETHOD.foo  (not shown above) controls whether we use
       BUILD_DEPENDS or DEPENDS to add the foo dependency, where the full
       dependency is added if BUILDLINK_DEPMETHOD.foo contains "full".

   The second section controls which files are linked into BUILDLINK_DIR:
    1. BUILDLINK_PREFIX.foo  is  the  installation  prefix of the package
       which we derive by using EVAL_PREFIX;
    2. BUILDLINK_FILES.foo  is  a  list  of  files  (shell globs allowed)
       relative   to  the  BUILDLINK_PREFIX.foo  directory  and  will  be
       symlinked into BUILDLINK_DIR;
    3. BUILDLINK_FILES_CMD.foo (not shown above) is a shell pipeline that
       outputs  a  list  of  files  relative  to the BUILDLINK_PREFIX.foo
       directory and will be symlinked into BUILDLINK_DIR.

   The  remaining  parts  create the "foo-buildlink" target that actually
   performs  the  symlinking  and  adds  the  "foo-buildlink"  target  to
   BUILDLINK_TARGETS,  which  is the global list of targets to execute at
   do-buildlink time.

Chapter 10. Debugging

   To  check  out  all  the gotchas when building a package, here are the
   steps that I do in order to get a package working. Please note this is
   basically  the  same  as  what was explained in the previous sections,
   only with some debugging aids.
     * Be sure to set PKG_DEVELOPER=1 in /etc/mk.conf
     * Install pkgtools/url2pkg and run

# url2pkg http://www.example.com/path/to/distfile.tar.gz

     * Edit the Makefile as requested.
     * Fill in DESCR
     * Run make configure
     * Add  any  dependencies  glimpsed  from  the  configure step to the
       package's Makefile.
     * Make the package compile, doing multiple rounds of

# make
# pkgvi ${WRKSRC}/some/file/that/does/not/compile
# mkpatches
# patchdiff
# mv ${WRKDIR}/.newpatches/* patches
# make mps
# make clean

       Doing as non-root user will ensure that no files are modified that
       shouldn't be, especially during the build phase.
     * Look at Makefile, fix if necessary; see Section 5.1, "Makefile".
     * Generate a PLIST:

# make install
# make print-PLIST > PLIST
# make deinstall
# make install
# make deinstall

       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.
     * Now  that  the  PLIST  is OK, install the package again and make a
       binary package:

# make reinstall && make package

     * Delete the installed package:

# pkg_delete blub

     * Repeat the above find command, which shouldn't find anything now:

# make print-PLIST

     * Reinstall the binary package:

# pkgadd .../blub.tgz

     * Play with it. Make sure everything works.
     * Run  pkglint  from  pkgtools/pkglint,  and  fix  the  problems  it
       reports.

# pkglint

     * Submit  (or  commit,  if  you  have  cvs  access); see Chapter 12,
       Submitting and Committing.

Chapter 11. FAQs & features of the package system

   Table of Contents

   11.1. Packages using GNU autoconf
   11.2. Other distrib methods than .tar.gz
   11.3. Packages not creating their own subdirectory
   11.4. Custom configuration process
   11.5. Packages not building in their DISTNAME directory
   11.6. How to fetch all distfiles at once
   11.7. How to fetch files from behind a firewall
   11.8. If your patch contains an RCS ID
   11.9. How to pull in variables from /etc/mk.conf
   11.10. Is there a mailing list for pkg-related discussion?
   11.11. How do I tell make fetch to do passive FTP?
   11.12. Dependencies on other packages
   11.13. Conflicts with other packages
   11.14. Software which has a WWW Home Page
   11.15. How to handle modified distfiles with the 'old' name
   11.16. What does "Don't know how to make /usr/share/tmac/tmac.andoc"
          mean?

   11.17. How to handle incrementing versions when fixing an existing
          package

   11.18. Could not find bsd.own.mk - what's wrong?
   11.19. Restricted packages
   11.20. Packages using (n)curses
   11.21. Automated security check
   11.22. What's the proper way to create an account from a package?
   11.23. How to handle compiler bugs
   11.24. Packages providing info files
   11.25. Packages whose distfiles aren't available for plain downloading

   11.26. Configuration files handling and placement
   11.27. Packages providing login shells
   11.28. Packages providing locale catalogues
   11.29. Using 'sudo' with pkgsrc
   11.30. Packages containing perl scripts
   11.31. Packages that cannot or should not be built

11.1. Packages using GNU autoconf

   If  your  package uses GNU autoconf created configure scripts, add the
   following to your package's Makefile:
   GNU_CONFIGURE= yes

   Note  that this appends "--prefix=${PREFIX}" to CONFIGURE_ARGS, so you
   don't have to do that yourself, but may not be desired.

11.2. Other distrib methods than .tar.gz

   If  your  package  uses  a different distribution method from .tar.gz,
   take a look at the package for editors/sam, which uses a gzipped shell
   archive  (shar),  but the quick solution is to set EXTRACT_SUFX to the
   name after the DISTNAME field, and add the following to your package's
   Makefile:
EXTRACT_SUFX=   .msg.gz
EXTRACT_CMD=            zcat
EXTRACT_BEFORE_ARGS=
EXTRACT_AFTER_ARGS=     |sh

11.3. Packages not creating their own subdirectory

   Your  package  doesn't  create  a  subdirectory  for  itself (like GNU
   software  does,  for  instance),  but  extracts  itself in the current
   directory: see editors/sam again, but the quick answer is:
   WRKSRC=         ${WRKDIR}

   Please note that the old:
   NO_WRKSUBDIR=   yes

   has been deprecated and should not be used.

11.4. Custom configuration process

   Your  package  uses  a  weird  Configure script, eg. sysutils/top. The
   quick answer is:
HAS_CONFIGURE=          yes
CONFIGURE_SCRIPT=       Configure
CONFIGURE_ARGS+=        netbsd13

11.5. Packages not building in their DISTNAME directory

   Your  package  builds  in a different directory from its base DISTNAME
   (see lang/tcl and x11/tk).
   WRKSRC=         ${WRKDIR}/${DISTNAME}/unix

11.6. How to fetch all distfiles at once

   You  would  like  to download all the distfiles in a single batch from
   work  or  university,  where  you  can't run a make fetch. 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, carry the
   resulting  list to your machine at work/school and use it there If you
   don't  have  a NetBSD-compatible ftp(1) (like lukemftp) at work, don't
   forget to set FETCH_CMD to something that fetches an URL:

   At home:
% cd /usr/pkgsrc
% make fetch-list FETCH_CMD=wget DISTDIR=/tmp/distfiles >/tmp/fetch.sh
% scp /tmp/fetch.sh work:/tmp

   At work:
   % sh /tmp/fetch.sh

   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 architecture), you
   can  do  so  by using the above-mentioned make fetch-list approach, or
   fetch the distfiles directly by running:
   % make mirror-distfiles

   If you even decide to ignore NO_{SRC,BIN}_ON_{FTP,CDROM}, then you can
   get everything by running:
   % make fetch NO_SKIP=yes

11.7. How to fetch files from behind a firewall

   If  you  are  sitting  behind  a  firewall which does not allow direct
   connections  to  Internet  hosts  (i.e.  non-NAT), you may specify the
   relevant  proxy  hosts.  This is done using an environment variable in
   the  form of a URL e.g. in Amdahl, the machine "orpheus.amdahl.com" is
   one of the firewalls, and it uses port 80 as the proxy port number. So
   the proxy environment variables are:
ftp_proxy=ftp://orpheus.amdahl.com:80/
http_proxy=http://orpheus.amdahl.com:80/

11.8. If your patch contains an RCS ID

   See  Section 5.3, "patches/*" for information on how to remove RCS IDs
   from patch files.

11.9. 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 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 included before that .if* statement.

   Rather  than  have  a number of ad-hoc ways of including /etc/mk.conf,
   should   it   exist,   or  MAKECONF,  should  it  exist,  include  the
   pkgsrc/mk/bsd.prefs.mk   file  in  the  package  Makefile  before  any
   preprocessor-like .if, .ifdef, or .ifndef statements:
.include "../../mk/bsd.prefs.mk"

.if defined(USE_MENUS)
  ...
.endif

11.10. Is there a mailing list for pkg-related discussion?

   Yes,  <tech-pkg@NetBSD.org> is the list for discussing package related
   issues. To subscribe do:
   % echo subscribe tech-pkg | mail majordomo@NetBSD.org

11.11. 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 the first available command from the
   following list:
/usr/bin/fetch
${LOCALBASE}/bsd/bin/ftp
/usr/bin/ftp

   On  a  default  NetBSD  install,  this  will  be  /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: PASSIVE_FETCH=1.

   Having that option present will prevent /usr/bin/ftp from falling back
   to active transfers.

11.12. Dependencies on other packages

   Your  package  may  depend  on  some other package being present - and
   there  are various ways of expressing this dependency. NetBSD supports
   the BUILD_DEPENDS and DEPENDS definitions, as well as dependencies via
   buildlink2.mk (see Chapter 9, buildlink2 methodology).

   The  basic  difference  between the two definitions is as follows: The
   DEPENDS definition registers that pre-requisite in the binary package,
   whilst the BUILD_DEPENDS definition does not.

   This  means  that  if  you  only need a package present whilst you are
   building, it should be noted as a BUILD_DEPENDS.

   The format for a BUILD_DEPENDS and a DEPENDS definition is:
   <pre-req-package-name>:../../<category>/<pre-req-package>

   Please  note  that  the  "pre-req-package-name" may include any of the
   wildcard version numbers recognised by pkg_info(1).
    1. If your package needs to use another package to build itself, this
       is specified using the BUILD_DEPENDS definition.

BUILD_DEPENDS+=  autoconf-2.13:../../devel/autoconf

    2. If  your  package  needs  a  library  with  which to link, this is
       specified  using the DEPENDS definition. An example of this is the
       print/lyx  package,  which  uses  the xpm library, version 3.4j to
       build.

DEPENDS+=       xpm-3.4j:../../graphics/xpm

       You can also use wildcards in package dependences:

DEPENDS+=       xpm-[0-9]*:../../graphics/xpm

       Note  that  such  wildcard dependencies are retained when creating
       binary  packages.  The  dependency  is checked when installing the
       binary  package  and any package which matches the pattern will be
       used. Wildcard dependencies should be used with care.
       The  -[0-9]*  should  be  used  instead of -* to avoid potentially
       ambiguous matches such as tk-postgresql matching a tk-* DEPENDS.
    3. If your package needs some executable to be able to run correctly,
       this  is  specified  using  the  DEPENDS definition. The print/lyx
       package  needs  to  be  able  to execute the latex binary from the
       teTeX package when it runs, and that is specified:

DEPENDS+=        teTeX-[0-9]*:../../print/teTeX

       The  comment  about  wildcard dependencies from previous paragraph
       applies here, too.

   If  your  package  needs  files from another package to build, see the
   first part of the "do-configure" target print/ghostscript5 package (it
   relies  on  the  jpeg  sources being present in source form during the
   build):
if [ ! -e ${_PKGSRCDIR}/graphics/jpeg/${WRKDIR:T}/jpeg-6b ]; then \
        cd ${_PKGSRCDIR}/../../graphics/jpeg && ${MAKE} extract;              \
fi

   If you build any other packages that way, please make sure the working
   files  are  deleted  too when this package's working files are cleaned
   up. The easiest way to do so is by adding a pre-clean target:
pre-clean:
        cd ${_PKGSRCDIR}/../../graphics/jpeg && ${MAKE} clean

   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. 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.

11.13. Conflicts with other packages

   Your  package  may  conflict  with other packages a user might already
   have  installed  on his system, e.g. if your package installs the same
   set of files like another package in our pkgsrc tree.

   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 install provide the same shared
   library, thus you set in pkgsrc/x11/Xaw3d/Makefile:
   CONFLICTS=      Xaw-Xpm-[0-9]*

   and in pkgsrc/x11/Xaw-Xpm/Makefile:
   CONFLICTS=      Xaw3d-[0-9]*

   Packages will automatically conflict with other packages with the name
   prefix   and   a  different  version  string.  "Xaw3d-1.5"  e.g.  will
   automatically conflict with the older version "Xaw3d-1.3".

11.14. Software which has a WWW Home Page

   The NetBSD packages system now supports a variable called HOMEPAGE. If
   the  software  being  packaged  has  a  home page, the Makefile should
   include the URL for that page in the HOMEPAGE variable. The definition
   of  the  variable  should  be  placed immediately after the MAINTAINER
   variable.

11.15. How to handle modified distfiles with the 'old' name

   Sometimes  authors of a software package make some modifications after
   the  software  was  released,  and  they put up a new distfile without
   changing  the  package's  version  number.  If a package is already in
   pkgsrc  at  that  time,  the  md5  checksum  will no longer match. The
   correct  way  to  work  around  this  is  to  update the package's md5
   checksum  to match the package on the master site (beware, any mirrors
   may  not  be  up  to  date  yet!), and to remove the old distfile from
   ftp.NetBSD.org's       /pub/NetBSD/packages/distfiles       directory.
   Furthermore,  a  mail to the package's author seems appropriate making
   sure  the  distfile  was really updated on purpose, and that no trojan
   horse or so crept in.

11.16. What does "Don't know how to make /usr/share/tmac/tmac.andoc" mean?

   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  you don't have installed the "text" set on your
   machine (nroff, ...). It is recommended to do that.

   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.

11.17. How to handle incrementing versions when fixing an existing package

   When  making  fixes  to an existing package it can be useful to change
   the  version  number  in  PKGNAME.  To  avoid  conflicting with future
   versions  by  the  original  author, a "nb1", "nb2", ... suffix can be
   used  on  package versions by setting PKGREVISION=1 (2,. ..). The "nb"
   is treated like a "." by the pkg tools. e.g.
DISTNAME=       foo-17.42
PKGREVISION=    9

   will result in a PKGNAME of "foo-17.42nb9".

   When  a new release of the package is released, the PKGREVISION should
   be  removed.  e.g. on a new minor release of the above package, things
   should be like:
   DISTNAME=       foo-17.43

11.18. Could not find bsd.own.mk - what's wrong?

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

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

11.19. Restricted packages

   Some licenses restrict how software may be re-distributed. In order to
   satisfy  these  restrictions,  the  package  system  defines five make
   variables that can be set to note these restrictions:
     * RESTRICTED
       This   variable  should  be  set  whenever  a  restriction  exists
       (regardless of its kind). Set this variable to a string containing
       the reason for the restriction.
     * NO_BIN_ON_CDROM
       Binaries  may  not  be  placed  on  CD-ROM.  Set  this variable to
       ${RESTRICTED}  whenever  a binary package may not be included on a
       CD-ROM.
     * NO_BIN_ON_FTP
       Binaries  may not be placed on an FTP server. Set this variable to
       ${RESTRICTED}  whenever  a  binary  package  may  not  not be made
       available on the Internet.
     * NO_SRC_ON_CDROM
       Distfiles  may  not  be  placed  on  CD-ROM.  Set this variable to
       ${RESTRICTED}  if  re-distribution  of  the  source  code or other
       distfile(s) is not allowed on CD-ROMs.
     * NO_SRC_ON_FTP
       Distfiles  may  not  be  placed  on  FTP.  Set  this  variable  to
       ${RESTRICTED}  if  re-distribution  of  the  source  code or other
       distfile(s) via the Internet is not allowed.

   Please  note  that  the  use of NO_PACKAGE, IGNORE, NO_CDROM, or other
   generic  make  variables to denote restrictions is deprecated, because
   they unconditionally prevent users from generating binary packages!

11.20. Packages using (n)curses

   Some  packages  need  curses  functionality  that  wasn't  present  in
   NetBSD's own curses prior to 1.4Y.

   If   ../../devel/ncurses/buildlink2.mk  is  included  in  a  package's
   Makefile, then a curses library and headers with ncurses functionality
   are  linked into ${BUILDLINK_DIR} at pre-configure time. If ncurses is
   actually required, then define USE_NCURSES in the package's Makefile.

11.21. Automated security check

   Please  be aware that there can often be bugs in third-party software,
   and  some of these bugs can leave a machine vulnerable to exploitation
   by attackers. In an effort to lessen the exposure, the NetBSD packages
   team  maintains a database of known-exploits to packages which have at
   one  time  been  included  in  pkgsrc.  The database can be downloaded
   automatically,  and  a  security  audit of all packages installed on a
   system can take place. To do this, install the security/audit-packages
   package. It has two components:
    1. "download-vulnerability-list",  an  easy way to download a list of
       the  security vulnerabilities information. This list is kept up to
       date  by the NetBSD security officer and the NetBSD packages team,
       and is distributed from the NetBSD ftp server:
       ftp://ftp.NetBSD.org/pub/NetBSD/packages/distfiles/vulnerabilities
    2. "audit-packages",  an  easy  way  to  audit  the  current machine,
       checking  each  vulnerability  which  is  known.  If  a vulnerable
       package  is  installed,  it  will  be  shown  by output to stdout,
       including  a  description  of the type of vulnerability, and a URL
       containing more information.

   Use of the audit-packages package is strongly recommended.

   The  following  message  is  displayed  as  part of the audit-packages
   installation procedure:
======================================================================
You may wish to have the vulnerabilities file downloaded daily so that
it remains current.  This may be done by adding an appropriate entry
to the root users crontab(5) entry.  For example the entry

# download vulnerabilities file
0 3 * * * ${PREFIX}/sbin/download-vulnerability-list >/dev/null 2>&1

will update the vulnerability list every day at 3AM.

In addition, you may wish to run the package audit from the daily
security script.  This may be accomplished by adding the following
lines to /etc/security.local

if [ -x ${PREFIX}/sbin/audit-packages ]; then
        ${PREFIX}/sbin/audit-packages
fi
======================================================================

   Note to package developers: When a vulnerability is found, this should
   be   noted  in  localsrc/security/advisories/pkg-vulnerabilities,  and
   after   the   commit   of   that   file,   it   should  be  copied  to
   /pub/NetBSD/packages/distfiles/vulnerabilities on ftp.NetBSD.org.

11.22. What's the proper way to create an account from a package?

   There  are  two  make  variables  used  to  control  the  creation  of
   package-specific  groups  and  users at pre-install time. The first is
   PKG_GROUPS,  which  is  a  list of group[:groupid] elements, where the
   groupid  is  optional.  The  second  is  PKG_USERS, which is a list of
   elements of the form:
   user:group[:[userid][:[description][:[home][:shell]]]]

   where only the user and group are required, the rest being optional. A
   simple example is:
PKG_GROUPS=     foogroup
PKG_USERS=      foouser:foogroup

   A more complex example is that creates two groups and two users is:
PKG_GROUPS=     group1 group2:1005
PKG_USERS=      first:group1::First\\ User                      \
                second:group2::Second\\ User:/home/second:${SH}

   By  default,  a  new  user  will have home directory /nonexistent, and
   login  shell  /sbin/nologin  unless  they are specified as part of the
   user element.

   The  package  Makefile  must  also include ../../mk/bsd.pkg.install.mk
   prior  to  the  inclusion of bsd.pkg.mk. This will cause the users and
   groups  to  be  created  at  pre-install  time,  and the admin will be
   prompted  to remove them at post-deinstall time. Automatic creation of
   the  users  and  groups  can  be  toggled  on  and  off by setting the
   environment    variable    PKG_CREATE_USERGROUP   prior   to   package
   installation.

11.23. How to handle compiler bugs

   Some  source files trigger bugs in the compiler, based on combinations
   of  compiler  version  and  architecture and almost always relation to
   optimisation being enabled. Common symptoms are gcc internal errors or
   never finishing compiling a file.

   Typically  a workaround involves testing the MACHINE_ARCH and compiler
   version,  disabling  optimisation  for that file/MACHINE_ARCH/compiler
   combination,  and  documenting  it  in  doc/HACKS.  See  doc/HACKS for
   examples.

11.24. Packages providing info files

   Some   packages   install   info   files  or  use  the  "makeinfo"  or
   "install-info" commands. Each info file:
     * is    considered    to    be    installed    in    the   directory
       ${PREFIX}/${INFO_DIR},
     * is registered in the Info directory file
       ${PREFIX}/${INFO_DIR}/dir,
     * and must be listed as a filename in the INFO_FILES variable in the
       package Makefile.

   INFO_DIR  defaults  to  "info"  and  can  be overridden in the package
   Makefile. INSTALL and DEINSTALL scripts will be generated for handling
   registration of the info files in the Info directory file. The command
   "install-info" used for the info files registration is either provided
   by  the system, or by a special purpose package automatically added as
   dependency if needed.

   A  package which need the "makeinfo" command at build time must define
   the variable USE_MAKEINFO 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 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 is added automatically.

   The  installation process of the software provided by the package must
   not  use "install-info", as the registration of info files is the task
   of the package INSTALL sript, and it must use the right "makeinfo".

   If  the  package  use buildlink2 framework no special action should be
   needed to achieve this goal.

   If  the  package does not use the buildlink2 framework patch files are
   likely  to  be  needed  so  the  build and installation process of the
   software  picks  up  the  possibly  dummy  values  of INSTALL_INFO and
   MAKEINFO variables.

Note

   Temporarily,  the  variable  USE_NEW_TEXINFO  must  be  defined in the
   package   Makefile.   Previously,   info   files,  "install-info"  and
   "makeinfo"  were  handled  somewhat  differently and the two ways will
   coexist  for  a  short  period  of  time  until all older packages are
   updated.

11.25. 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 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 example of this usage.

   If  the  download  can't  be  automated,  because the user must submit
   personal  information  to  apply  for  a password, or must pay for the
   source,  or  whatever,  you  can  set  _FETCH_MESSAGE to a macro which
   displays  a  message  explaining the situation. _FETCH_MESSAGE must be
   executable shell commands, not just a message. (Generally, it executes
   ${ECHO}).  As  of  this  writing,  the  following  packages  use this:
   audio/realplayer,             cad/simian,            devel/ipv6socket,
   emulators/vmare-module,                        fonts/acroread-jpnfont,
   sysutils/storage-manager,  www/ap-aolserver,  www/openacs.  Try  to be
   consistent with them.

11.26. Configuration files handling and placement

   The  global  variable  PKG_SYSCONFBASE (and some others) can be set by
   the  system  administrator  in  /etc/mk.conf to define the place where
   configuration files get installed. Therefore, packages must be adapted
   to  support  this  feature.  Keep in mind that you should only install
   files  that  are  strictly  necessary  in the configuration directory,
   files that can go to $PREFIX/share should go there.

   We  will take a look at available variables first (bsd.pkg.mk contains
   more information). PKG_SYSCONFDIR is where the configuration files for
   a  package  may  be  found  (that  is,  the  full  path,  e.g. /etc or
   /usr/pkg/etc). This value may be customized in various ways:
    1. PKG_SYSCONFBASE  is  the  main  config  directory  under which all
       package  configuration files are to be found. Users will typically
       want  to  set  it  to  /etc,  or  accept  the  default location of
       $PREFIX/etc.
    2. PKG_SYSCONFSUBDIR  is  the  subdirectory  of PKG_SYSCONFBASE under
       which  the  configuration  files  for  a particular package may be
       found. Defaults to ${SYSCONFBASE}.
    3. PKG_SYSCONFVAR  is  the  special  suffix  used  to distinguish any
       overriding  values  for  a  particular package (see next item). It
       defaults  to  ${PKGBASE}, but for a collection of related packages
       that  should all have the same PKG_SYSCONFDIR value, it can be set
       in each of the package Makefiles to a common value.
    4. PKG_SYSCONFDIR.${PKG_SYSCONFVAR}    overrides    the    value   of
       ${PKG_SYSCONFDIR}   for   packages   with   the   same  value  for
       PKG_SYSCONFVAR.
       As  an  example,  all  the  various  KDE  packages may want to set
       PKG_SYSCONFVAR  to  "kde"  so admins can set PKG_SYSCONFDIR.kde in
       /etc/mk.conf to define where to install KDE config files.

   Programs'   configuration  directory  should  be  defined  during  the
   configure stage. Packages that use GNU autoconf can usually do this by
   using  the  "--sysconfdir" parameter, but this brings some problems as
   we will see now. When you change this pathname in packages, you should
   not  allow  them  to install files in that directory directly. Instead
   they  need  to  install those files under share/examples/${PKGNAME} so
   PLIST can register them.

   Once  you  have  the  required configuration files in place (under the
   share/examples  directory)  the  variable  CONF_FILES should be set to
   copy them into PKG_SYSCONFDIR. The contents of this variable is formed
   by  pairs  of  filenames;  the first element of the pair specifies the
   file  inside  the  examples  directory  (registered  by PLIST) and the
   second  element  specifies  the  target file. This is done this way to
   allow  binary  packages  to  place  files in the right directory using
   INSTALL/DEINSTALL scripts which are created automatically. The package
   Makefile  must  also  include ../../mk/bsd.pkg.install.mk prior to the
   inclusion  of bsd.pkg.mk to use these automatically generated scripts.
   The  automatic  copying  of config files can be toggled by setting the
   environment variable PKG_CONFIG prior to package installation.

   Here is an example, taken from mail/mutt/Makefile:
EGDIR=          ${PREFIX}/share/doc/mutt/samples
CONF_FILES=     ${EGDIR}/Muttrc ${PKG_SYSCONFDIR}/Muttrc

   As  you  can  see,  this  package  installs configuration files inside
   EGDIR,  which  are  registered  by  PLIST.  After  that,  the variable
   CONF_FILES  lists  the  installed file first and then the target file.
   Users  will  also  get  an  automatic message when files are installed
   using this method.

11.27. Packages providing login shells

   If  the  purpose  of  the  package  is  to  provide a login shell, the
   variable  PKG_SHELL  should  contain  the  full  pathname of the shell
   executable  installed  by this package. The package Makefile also must
   include   ../../mk/bsd.pkg.install.mk   prior   to  the  inclusion  of
   bsd.pkg.mk   to  use  the  automatically  generated  INSTALL/DEINSTALL
   scripts.

   An example taken from shells/zsh:
PKG_SHELL=      ${PREFIX}/bin/zsh
.include "../../mk/bsd.pkg.install.mk"

   The  shell  is  registered  into /etc/shells file automatically in the
   post-install    target    by   the   INSTALL   script   generated   by
   bsd.pkg.install.mk   and  removed  in  the  deinstall  target  by  the
   DEINSTALL script.

11.28. Packages providing locale catalogues

   If  the  package  provides  its  own  locale  catalogues, the variable
   USE_PKGLOCALEDIR  should be defined. It will ensure that the package's
   Makefile  template  files  are  fixed  and point to the correct locale
   directories  (which  may  vary,  depending  on  OS), if necessary. See
   Section 6.1,  "Miscellaneous"  for  details  about  PKGLOCALEDIR. This
   functionality is buildlink2-only.

11.29. Using 'sudo' with pkgsrc

   When  installing  packages as non-root user and using the just-in-time
   su(1)  feature  of  pkgsrc, it can become annoying to type in the root
   password  for each required package installed. To avoid this, the sudo
   package  can be used, which does password caching over a limited time.
   To   use   it,   install  sudo  (either  as  binary  package  or  from
   security/sudo) and then put the following into your /etc/mk.conf:
   SU_CMD=/usr/pkg/bin/sudo /bin/sh -c

11.30. Packages containing perl scripts

   If your package contains interpreted perl scripts, set REPLACE_PERL to
   ensure  that  the  proper interpreter path is set. REPLACE_PERL should
   contain a list of scripts, relative to WRKSRC, that you want adjusted.

11.31. Packages that cannot or should not be built

   There  are  several  reasons  why a package might be instructed to not
   build  under  certain circumstances. If the package builds and runs on
   most  platforms, the exceptions should be noted with NOT_FOR_PLATFORM.
   If  the  package  builds and runs on a small handful of platforms, set
   ONLY_FOR_PLATFORM  instead.  If  the  package  should  be skipped (for
   example,  because  it  provides  functionality already provided by the
   system),  set PKG_SKIP_REASON to a descriptive message. If the package
   should   fail   because   some   preconditions   are   not   met,  set
   PKG_FAIL_REASON to a descriptive message.

   IGNORE  is  deprecated because it didn't provide enough information to
   determine whether the build should fail.

Chapter 12. Submitting and Committing

   Table of Contents

   12.1. Submitting your packages
   12.2. Committing: Importing a package into CVS
   12.3. Updating a Package to a Newer Version
   12.4. Moving a Package in pkgsrc

12.1. Submitting your packages

   You  have  to  separate  between binary and "normal" (source) packages
   here:
     * precompiled binary packages
       Our  policy is that we accept binaries only from NetBSD developers
       to  guarantee  that  the  packages don't contain any trojan horses
       etc.  This  is  not  to  piss anyone off but rather to protect our
       users!  You're still free to put up your home-made binary packages
       and tell the world where to get them.
     * packages
       First,  check  that  your  package  is complete, compiles and runs
       well;  see  Chapter 10,  Debugging  and the rest of this document.
       Next,  generate a gzipped tar-file of all the files needed for the
       package,  preferably  with  all files in a single directory. Place
       this  tar-file  to a place where the package maintainers can fetch
       it  using FTP or HTTP (WWW). Finally, send-pr with category "pkg",
       a  synopsis  which includes the package name and version number, a
       short  description  of  your  package  (contents  of  the  COMMENT
       variable are OK) and the URL of your tar-file.
       You  will  be  notified  if  your PR has been addressed so you can
       remove the tar-file.
       If  you want to submit several packages, please send a separate PR
       for each one, it's easier for us to track things that way.

12.2. Committing: Importing a package into CVS

   This  section  is  only  of  interest for NetBSD developers with write
   access  to  the  NetBSD  pkgsrc  repository.  Please remember that cvs
   imports files relative to the cwd, and that the pathname that you give
   the cvs import command is so that it knows where to place the files in
   the  repository.  Newly  created  packages  should  be imported with a
   vendor tag of "TNF" and a release tag of "pkgsrc-base", e.g:
% cd
.../pkgsrc/<category>/<pkgname>
% cvs import pkgsrc/<category>/<pkgname> TNF pkgsrc-base

   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.

   The  commit  message  of the initial import should include part of the
   DESCR  file, so people reading the mailing lists know what the package
   is/does.

   Please  note all package updates/additions 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.

   For  new  packages, "cvs import" is preferred to "cvs add" because the
   former   gets  everything  with  a  single  command,  and  provides  a
   consistent tag.

12.3. Updating a Package to a Newer Version

   Please  always  put a concise, appropriate and relevant summary of the
   changes between old and new versions into the commit log when updating
   a package. There are various reasons for this:
     * A  URL  is  volatile,  and  can  change  over time. It may go away
       completely   or  its  information  may  be  overwritten  by  newer
       information.
     * Having  the change information between old and new versions in our
       CVS  repository  is  very  useful for people who use either cvs or
       anoncvs.
     * Having  the change information between old and new versions in our
       CVS   repository   is   very   useful  for  people  who  read  the
       pkgsrc-changes  mailing  list,  so  that  they  can  make tactical
       decisions about when to upgrade the package.

   Please  also  recognise  that, just because a new version of a package
   has  been released, it should not automatically be upgraded in the CVS
   repository.  We  prefer  to  be  conservative in the packages that are
   included  in  pkgsrc - development or beta packages are not really the
   best  thing  for  most places in which pkgsrc is used. Please use your
   judgement  about  what  should  go  into pkgsrc, and bear in mind that
   stability is to be preferred above new and possibly untested features.

12.4. Moving a Package in pkgsrc

    1. Make a copy of the directory somewhere else.
    2. Remove all CVS dirs.
       Alternatively to the first two steps you can also do:

% cvs -d user@cvs.NetBSD.org:/cvsroot export -D today pkgsrc/category/package

       and use that for further work.
    3. Fix  CATEGORIES  and  any DEPENDS paths that just did "../package"
       instead of "../../category/package".
    4. cvs import the modified package in the new place.
    5. Check if any package depends on it:

% cd /usr/pkgsrc
% grep /package */*/Makefile* */*/buildlink*

    6. Fix paths in packages from step 5 to point to new location.
    7. cvs rm (-f) the package at the old location.
    8. Remove from oldcategory/Makefile.
    9. Add to newcategory/Makefile.
   10. Commit the changed and removed files:

% cvs commit oldcategory/package oldcategory/Makefile newcategory/Makefile

       (and any packages from step 5, of course).

Appendix A. A simple example of a package: bison

   Table of Contents

   A.1. files
   A.2. Steps for building, installing, packaging

   I  checked  to  find  a  piece of software that wasn't in the packages
   collection, and picked GNU bison. Quite why someone would want to have
   bison  when Berkeley yacc is already present in the tree is beyond me,
   but it's useful for the purposes of this exercise.

A.1. files

A.1.1. Makefile

# $NetBSD: pkgsrc.txt,v 1.2 2003/06/23 13:27:58 grant Exp $
#

DISTNAME=       bison-1.25
CATEGORIES=     devel
MASTER_SITES=   ${MASTER_SITE_GNU}

MAINTAINER=     thorpej@NetBSD.org
HOMEPAGE=       http://www.gnu.org/software/bison/bison.html
COMMENT=        GNU yacc clone

GNU_CONFIGURE=  yes
INFO_FILES=     bison.info

.include "../../mk/bsd.pkg.mk"

A.1.2. DESCR

GNU version of yacc.  Can make re-entrant parsers, and numerous other
improvements.  Why you would want this when Berkeley yacc(1) is part
of the NetBSD source tree is beyond me.

A.1.3. PLIST

@comment $NetBSD: pkgsrc.txt,v 1.2 2003/06/23 13:27:58 grant Exp $
bin/bison
man/man1/bison.1.gz
info/bison.info
info/bison.info-1
info/bison.info-2
info/bison.info-3
info/bison.info-4
info/bison.info-5
share/bison.simple
share/bison.hairy

A.1.4. Checking a package with pkglint

   The  NetBSD  package system comes with 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 pkglint:
% pkglint
OK: checking ./DESCR.
OK: checking Makefile.
OK: checking distinfo.
OK: checking patches/patch-aa.
looks fine.

   Depending on the supplied command line arguments (see pkglint(1)) more
   verbose  checks  will  be  performed.  Use  e.g. pkglint -v for a very
   verbose check.

A.2. Steps for building, installing, packaging

   Create  the  directory  where  the  package  lives, plus any auxiliary
   directories:
# cd /usr/pkgsrc/lang
# mkdir bison
# cd bison
# mkdir patches

   Create  Makefile, DESCR and PLIST (see Chapter 5, 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.
>> Attempting to fetch from ftp://prep.ai.mit.edu/pub/gnu//.
Requesting ftp://prep.ai.mit.edu/pub/gnu//bison-1.25.tar.gz (via ftp://orpheus.
amdahl.com:80/)
ftp: Error retrieving file: 500 Internal error

>> Attempting to fetch from ftp://wuarchive.wustl.edu/systems/gnu//.
Requesting ftp://wuarchive.wustl.edu/systems/gnu//bison-1.25.tar.gz (via ftp://
orpheus.amdahl.com:80/)
ftp: Error retrieving file: 500 Internal error

>> Attempting to fetch from ftp://ftp.freebsd.org/pub/FreeBSD/distfiles//.
Requesting ftp://ftp.freebsd.org/pub/FreeBSD/distfiles//bison-1.25.tar.gz (via
ftp://orpheus.amdahl.com:80/)
Successfully retrieved file.

   Generate the checksum of the distfile into distinfo:
   # make makesum

   Now compile:
# make
>> Checksum OK for bison-1.25.tar.gz.
===>  Extracting for bison-1.25
===>  Patching for bison-1.25
===>   Ignoring empty patch directory
===>  Configuring for bison-1.25
creating cache ./config.cache
checking for gcc... cc
checking whether we are using GNU C... yes
checking for a BSD compatible install... /usr/bin/install -c -o bin -g bin
checking how to run the C preprocessor... cc -E
checking for minix/config.h... no
checking for POSIXized ISC... no
checking whether cross-compiling... no
checking for ANSI C header files... yes
checking for string.h... yes
checking for stdlib.h... yes
checking for memory.h... yes
checking for working const... yes
checking for working alloca.h... no
checking for alloca... yes
checking for strerror... yes
updating cache ./config.cache
creating ./config.status
creating Makefile
===>  Building for bison-1.25
cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -D
HAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include  -g LR0.c
cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -D
HAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include  -g allocate.c
cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -D
HAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include  -g closure.c
cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -D
HAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include  -g conflicts.c
cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -D
HAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include  -g derives.c
cc -c -DXPFILE=\"/usr/pkg/share/bison.simple\"  -DXPFILE1=\"/usr/pkg/share/biso
n.hairy\" -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=
1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1  -g  ./files.c
cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -D
HAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include  -g getargs.c
cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -D
HAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include  -g gram.c
cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -D
HAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include  -g lalr.c
cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -D
HAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include  -g lex.c
cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -D
HAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include  -g main.c
cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -D
HAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include  -g nullable.c
cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -D
HAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include  -g output.c
cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -D
HAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include  -g print.c
cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -D
HAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include  -g reader.c
cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -D
HAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include  -g reduce.c
cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -D
HAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include  -g symtab.c
cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -D
HAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include  -g warshall.c
cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -D
HAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include  -g version.c
cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -D
HAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include  -g getopt.c
cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -D
HAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include  -g getopt1.c
cc  -g -o bison LR0.o allocate.o closure.o conflicts.o derives.o files.o
  getargs.o gram.o lalr.o lex.o                                   main.o nullab
le.o output.o print.o reader.o reduce.o symtab.o   warshall.o version.o getopt.
o getopt1.o
./files.c:240: warning: mktemp() possibly used unsafely, consider using mkstemp
()
rm -f bison.s1
sed -e "/^#line/ s|bison|/usr/pkg/share/bison|" < ./bison.simple > bison.s1

   Everything seems OK, so install the files:
# make install
>> Checksum OK for bison-1.25.tar.gz.
===>  Installing for bison-1.25
sh ./mkinstalldirs /usr/pkg/bin /usr/pkg/share  /usr/pkg/info /usr/pkg/man/man1
rm -f /usr/pkg/bin/bison
cd /usr/pkg/share; rm -f bison.simple bison.hairy
rm -f /usr/pkg/man/man1/bison.1 /usr/pkg/info/bison.info*
install -c  -o bin -g bin -m 555 bison /usr/pkg/bin/bison
/usr/bin/install -c -o bin -g bin -m 644 bison.s1 /usr/pkg/share/bison.simple
/usr/bin/install -c -o bin -g bin -m 644 ./bison.hairy /usr/pkg/share/bison.hai
ry
cd .; for f in bison.info*;  do /usr/bin/install -c -o bin -g bin -m 644 $f /us
r/pkg/info/$f; done
/usr/bin/install -c -o bin -g bin -m 644 ./bison.1 /usr/pkg/man/man1/bison.1
===>  Registering installation for bison-1.25

   You  can  now  use bison, and also - if you decide so - remove it with
   pkg_delete bison. Should you decide that you want a binary package, do
   this now:
# make package
>> Checksum OK for bison-1.25.tar.gz.
===>  Building package for bison-1.25
Creating package bison-1.25.tgz
Registering depends:.
Creating gzip'd tar ball in '/u/pkgsrc/lang/bison/bison-1.25.tgz'

   Now  that  you  don't need the source and object files any more, clean
   up:
# make clean
===>  Cleaning for bison-1.25

Appendix B. Build logs

   Table of Contents

   B.1. Building top
   B.2. Packaging top

B.1. Building top

# make
>> top-3.5beta5.tar.gz doesn't seem to exist on this system.
>> Attempting to fetch from ftp://ftp.groupsys.com/pub/top/.
Requesting ftp://ftp.groupsys.com/pub/top/top-3.5beta5.tar.gz (via ftp://orpheu
s.amdahl.com:80/)
Successfully retrieved file.
>> Checksum OK for top-3.5beta5.tar.gz.
===>  Extracting for top-3.5beta5
===>  Patching for top-3.5beta5
===>  Applying NetBSD patches for top-3.5beta5
===>  Configuring for top-3.5beta5
/bin/cp /u/pkgsrc/sysutils/top/files/defaults /u/pkgsrc/sysutils/top/work/top-3
.5beta5/.defaults
chmod a-x /u/pkgsrc/sysutils/top/work/top-3.5beta5/install

Reading configuration from last time...

Using these settings:
        Bourne Shell   /bin/sh
          C compiler   cc
    Compiler options   -DHAVE_GETOPT -O
         Awk command   awk
     Install command   /usr/bin/install

              Module   netbsd13
             LoadMax   5.0
        Default TOPN   -1
        Nominal TOPN   18
       Default Delay   2
Random passwd access   yes
          Table Size   47
               Owner   root
         Group Owner   kmem
                Mode   2755
       bin directory   $(PREFIX)/bin
       man directory   $(PREFIX)/man/man1
       man extension   1
       man style       man

Building Makefile...
Building top.local.h...
Building top.1...
Doing a "make clean".
rm -f *.o top core core.* sigdesc.h
To create the executable, type "make".
To install the executable, type "make install".
===>  Building for top-3.5beta5
cc -DHAVE_GETOPT -DORDER -DHAVE_GETOPT -O  -c top.c
awk -f sigconv.awk /usr/include/sys/signal.h >sigdesc.h
cc -DHAVE_GETOPT -DORDER -DHAVE_GETOPT -O  -c commands.c
cc -DHAVE_GETOPT -DORDER -DHAVE_GETOPT -O  -c display.c
cc -DHAVE_GETOPT -DORDER -DHAVE_GETOPT -O  -c screen.c
cc -DHAVE_GETOPT -DORDER -DHAVE_GETOPT -O  -c username.c
cc -DHAVE_GETOPT -DORDER -DHAVE_GETOPT -O  -c utils.c
utils.c: In function `errmsg':
utils.c:348: warning: return discards `const' from pointer target type
cc -DHAVE_GETOPT -DORDER -DHAVE_GETOPT -O  -c version.c
cc -DHAVE_GETOPT -DORDER -DHAVE_GETOPT -O  -c getopt.c
cc "-DOSREV=12G" -DHAVE_GETOPT -DORDER -DHAVE_GETOPT -O -c machine.c
rm -f top
cc -o top top.o commands.o display.o screen.o username.o  utils.o version.o get
opt.o machine.o -ltermcap -lm -lkvm
#
# make install
>> Checksum OK for top-3.5beta5.tar.gz.
===>  Installing for top-3.5beta5
/usr/bin/install -o root -m 2755 -g kmem top /usr/pkg/bin
/usr/bin/install top.1 /usr/pkg/man/man1/top.1
strip /usr/pkg/bin/top
===>  Registering installation for top-3.5beta5

B.2. Packaging top

# make package
>> Checksum OK for top-3.5beta5.tar.gz.
===>  Building package for top-3.5beta5
Creating package top-3.5beta5.tgz
Registering depends:.
Creating gzip'd tar ball in '/u/pkgsrc/sysutils/top/top-3.5beta5.tgz'

Appendix C. Layout of the FTP server's package archive

   Layout for precompiled binary packages on ftp.NetBSD.org:
/pub/NetBSD/packages/
                README
                distfiles/
                pkgsrc -> /pub/NetBSD/NetBSD-current/pkgsrc
                1.6/
                        i386/
                                All/
                                archivers/
                                        foo -> ../All/foo
                                ...
                        m68k/
                                All/
                                archivers/
                                        foo -> ../All/foo
                                ...
                        amiga -> m68k
                        atari -> m68k
                        ...