diff options
| author | grant <grant> | 2003-06-23 07:41:44 +0000 |
|---|---|---|
| committer | grant <grant> | 2003-06-23 07:41:44 +0000 |
| commit | f77d2c13ba7c0be95ca8120c81d2405bf1ae4a51 (patch) | |
| tree | cec7c927cdab5855bc9b35af018f5c8cedec5552 | |
| parent | 6f7e7209bc9d390cd7ca94a36f219e6be0ee7b6f (diff) | |
| download | pkgsrc-f77d2c13ba7c0be95ca8120c81d2405bf1ae4a51.tar.gz | |
deprecate Packages.txt.
now point users at documentation on the web and provide a copy of the
single file HTML and plain-text output.
| -rw-r--r-- | Packages.txt | 2965 | ||||
| -rw-r--r-- | pkgsrc.html | 5198 | ||||
| -rw-r--r-- | pkgsrc.txt | 3234 |
3 files changed, 8442 insertions, 2955 deletions
diff --git a/Packages.txt b/Packages.txt index 6a4e8ae1fbd..a1b07a5e1d9 100644 --- a/Packages.txt +++ b/Packages.txt @@ -1,2960 +1,15 @@ -# $NetBSD: Packages.txt,v 1.295 2003/06/19 21:41:13 seb Exp $ -########################################################################### +$Id: Packages.txt,v 1.296 2003/06/23 07:41:45 grant Exp $ - ========================== - Documentation on the - NetBSD Package System - ========================== +The pkgsrc documentation now lives on the NetBSD web site. - Hubert Feyrer, Alistair Crooks +Full documentation, one file per chapter: + http://www.NetBSD.org/Documentation/pkgsrc/ +Full documentation in a single file: + http://www.NetBSD.org/Documentation/pkgsrc/pkgsrc.html -Table of contents: -================== +Full documentation in a single plain-text file: + http://www.NetBSD.org/Documentation/pkgsrc/pkgsrc.txt -Run this command to produce a table of contents: - sed '/^.====/{g;p;};h;d' Packages.txt - - - 0 Intro - ======= - -There is a lot of software freely available for Unix based systems, which -usually runs on NetBSD, too, sometimes with some modifications. The NetBSD -packages collection incorporates any such changes necessary to make that -software run on NetBSD, and makes the installation (and re-installation) of -the software package easy by means of a single command. - -The NetBSD package system is used to enable such freely available -third-party software to be built easily on NetBSD hosts. 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. - -Both the NetBSD packages collection and the NetBSD package system are -derived from FreeBSD. - - - 0.1 Overview - ============ - -This document is divided into two parts. The first, "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 copy using the NetBSD package system. The -second part, "Package Constructor'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. - - - 0.2 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. - - * NetBSD RCS IDs: - Some files in a package contain RCS IDs to reflect which version of - that file this is (inserted automatically by cvs). These IDs are used - in several examples within this document, but as this document itself - is managed by CVS, it can't list the RCS IDs in plaintext. Instead, the - $s are written as <$>, resulting in <$>NetBSD<$> and <$>Id<$>. - - - 0.3 Typography - ============== - -Right now this document is written in plain ASCII text, and there's not -much typography applied here. It's being moved to DocBook. - -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. - - -==================== -Part I: User's Guide -==================== - - 1 Installing a precompiled binary package - ========================================= - -This section describes how to find, retrieve and install a precompiled -binary package that someone else already prepared for your type of machine. - - - 1.1 Where to get - ================ - -Precompiled packages are stored on ftp.netbsd.org and its mirrors in the -directory /pub/NetBSD/packages for anon 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 CDROM's documentation for the exact location! - - - 1.2 How to use - ============== - -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. - - - 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. - - - 2 Installing by Building - ======================== - -This assumes that the package is already part of the NetBSD package system. -If it is not, then you are advised to read part II of this document, -"Package Constructor's Guide". - - - 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. - - - 2.2 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://ftp.netbsd.org/pub/NetBSD-current/tar_files/pkgsrc.tar.gz and -unpack it into /usr. - -As an alternative, you can get pkgsrc via the Software Update Protocol, -SUP. To do so, make sure your supfile has a line saying "release=pkgsrc" in -it, see the examples in /usr/share/examples/supfiles, and that the -directory /usr/pkgsrc does exist. Then, simply start "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. - - - 2.3 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(1) 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. - - - 2.4 How to build and install - ============================ - -Assuming that the distfile has been fetched (see previous section), become -root and change into the relevant directory. Then you can type - - % make - -at the shell prompt to build the various components of the package, and - - # make install - -at the shell prompt to install the various components into the correct -places on your system. - -Taking the top system utility as an example, we can install it on our -system by building as shown in appendix A.1. - -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, for example, 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 xpkgwedge package -(pkgsrc/pkgtools/xpkgwedge) - see section 7.1 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. As a worked 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, and do a "make package" else. 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. - - - 3 Making precompiled packages - ============================= - - - 3.1 Packaging a single package - ============================== - -Once you have built and installed the package as mentioned above, you can -build it into a "binary package" - you might want to do this so that you -can use the binaries you have just built on another NetBSD system, or to -provide a simple means for others to use your binary package instead of -wasting CPU time - this is done by changing to the appropriate directory in -the pkgsrc tree, and typing the command - - # make package - -at the shell prompt. This will build and install your package (if not -already done), and then construct a binary package out of the results so -that you can use the pkg_* tools to manipulate this. The binary package is -stored under /usr/pkgsrc/packages, it's in the form of a gzipped file at -the present time. See appendix A.2 for a continuation of the above top -example. - -Please see the "submitting" section later in this document on how to submit -such a binary package. - - - 3.2 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. - - - 3.2.1 Configuration - =================== - - 3.2.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 make sure that ACCEPTABLE_LICENSES meet your local -policy: - - 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. - - 3.2.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 to do a 'cvs update'. - - 3.2.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 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. - - 3.2.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 a OS version below 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! :) - - - 3.2.3 Operation - =============== - -Make sure you don't need any of the packages still installed. -BEWARE: 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. - - - 3.2.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. - - - 3.2.5 Disk space requirements - ============================= - -Currently, roughly the following requirements are valid for -1.5/i386: - - * Distfiles: 1500MB (NFS ok) - * Full set of all binaries: 1000MB (NFS ok) - * Temp space for compiling: 1500MB (local disk recommended) - -For 1.5/alpha: - - * Full set of all binaries: 1300MB (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. - - - 3.2.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 src/etc, make 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 from cvs, into /usr/sandbox/usr/pkgsrc - cvs -d cvs.netbsd.org:/cvsroot co pkgsrc - * /usr/pkgsrc/packages & .../distfiles (point outside of sandbox) - * /etc/mk.conf, see 3.2.1.1 - * adjust .../mk/bulk/build.conf - -!!! Don't forget to install X !!! -If you are a developer and want to upload the resulting binary packages -to ftp.netbsd.org, make sure you are using the default X version for your -architecture and release (up to 1.6, that is 3.3.6 for all architectures). - -Next thing you will want to is make sure /usr/sandbox/usr/pkgsrc contains 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. - -Then, configure .../pkgsrc/mk/bulk/build.conf to fit your needs! - -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 thrash^Wbuilding. -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). - - - 3.3 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 package pkgsrc/pkgtools/cdpack provides a simple tool for -creating the ISO 9660 images. `cdpack' arranges the packages on the CD-ROM's -in a way that keeps all the dependencies for given package on the same -CD as that package. - - - 3.3.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. For example - - # 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 with - - # cdpack -x /tmp/common /usr/pkgsrc/packages/All /u2/images - -and each image will contain "README", "COPYING", and "bin/myscript" -in their root directories. - - -==================================== -Part II: Package Constructor's Guide -==================================== - - 4 Package components - files, directories and contents - ====================================================== - -Whenever you're preparing a package, there are a number of files involved -which are described in the following sections. - - - 4.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 fields 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_APACHE} - ${MASTER_SITE_DEBIAN} - ${MASTER_SITE_GNOME} - ${MASTER_SITE_GNU} - ${MASTER_SITE_GNUSTEP} - ${MASTER_SITE_MOZILLA} - ${MASTER_SITE_PERL_CPAN} - ${MASTER_SITE_SOURCEFORGE} - ${MASTER_SITE_SUNSITE} - ${MASTER_SITE_R_CRAN} - ${MASTER_SITE_SUSE} - ${MASTER_SITE_TEX_CTAN} - ${MASTER_SITE_XCONTRIB} - ${MASTER_SITE_XEMACS} - -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.) Use of the deprecated -MASTER_SITE_SUBDIR will not work. - -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 - -See the NetBSD packages(7) manual page for a description of all available -options and variables. - -Please pay attention to the following gotchas: - - - Add MANCOMPRESSED (if not already there) if manpages are installed in - compressed form by the package; see comment in bsd.pkg.mk - - Replace /usr/local by ${PREFIX} in all files (see patches below) - - If the package installs any info files, see the section `Packages providing - info files' in this document. - - Adjust MAINTAINER to be either yourself, if you plan to maintain the - package for future updates, or set it to the default MAINTAINER - packages@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. - - Please also set the COMMENT variable to a short description of the - package. - - - 4.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 pkgsrc/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 pkgsrc/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 4.3) 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". - - - 4.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. To avoid this, use either -the "-U 2" or "-U 1" option to diff, or let the 'pkgdiff' command -from pkgsrc/pkgtools/pkgdiff help you. - -If you don't want to worry about the problems in the last two paragraphs -yourself, use pkgdiff from the pkgsrc/pkgtools/pkgdiff package, which takes -care of any RCS Ids by itself. - -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 4.2. - -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 the "normal" -pkgsrc patches are applied. - - - 4.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. - - - 4.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} - - in MESSAGE with "somevalue" before displaying the message. - - - 4.6 work/* - ========== - -When you type "make" the distribution files are unpacked into this -directory. It can be removed by typing - - # make clean - -at the shell prompt. Also, this directory is used to keep various -timestamp files. - - - 4.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 PLIST* issues - =============== - -This section addresses some special issues that one needs to pay attention -to when dealing with the PLIST file (or files, see below!). - - - 5.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<$> - - * ${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 OSes 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. - - - 5.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. - - 5.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). - - 5.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. - - 5.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 - - - 6 Notes on fixes for packages - ============================= - - 6.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. - - 6.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 "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 ${PREFIX}/lib -version-info major:minor - - Note that the library is changed to have a .la extension, and the - objects are changed to have a .lo extension. Change OBJS as necessary. - This automatically creates all of the .a, .so.major.minor, and ELF - symlinks (if necessary) in the build directory. Be sure to include - the -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. - - PLIST should include all of the .a, .la and so, .so.major and - .so.major.minor entries. - -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. For example: - - ${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 DTRT with the libraries. - -6. When installing libraries, preface the install or cp command with - "${LIBTOOL} --mode=install", and change the library name to .la. For - example: - - ${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. In your PLIST, include all of the .a, .la, and so, .so.major and - .so.major.minor files (this is a change from the previous behaviour). - - - 6.3 Using libtool on GNU packages that already support libtool - ============================================================== - -Add USE_LIBTOOL=yes and LIBTOOL_OVERRIDE=${WRKSRC}/libtool to the -package Makefile as the quick way to bypass the pkg's own libtool. -For older libtool using packages, libtool is made by ltconfig script -during the do-configure step; you can check the libtool script -location by doing "make configure; find work*/ -name libtool". - -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 to YES). - -Some packages use libtool incorrectly so that the package may not work or -build in some circumstances. Some 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 and 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. - - - 6.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 to NO in the package Makefile. - - - 6.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 is meant to be set in a package Makefile. - -* By default PKG_SYSCONFDIR=${PKG_SYSCONFBASE}/${PKG_SYSCONFSUBDIR}, but - the default 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. - - - 6.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! - - - 7 The build process - =================== - -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. - - - 7.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 ${PREFIX} -needs to be put into the various places in the program's source where paths -to these files are encoded; see sections 4.3 and 6.2 for details on this. - -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 the xpkgwedge package (pkgsrc/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. - - 7.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. - - * 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 4.3 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 - - - 7.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 a "-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 call "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 - e.g. 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 navigator (pkgsrc/www/navigator) or lynx - (pkgsrc/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 - target "show-host-specific-pkgs" - - * 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 3.2.1). 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 - - - 8 buildlink2 methodology - ======================== - -"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 into ${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. - - - 8.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. - - - 8.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. - - - 9 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. - - * Make sure PKG_DEVELOPER=1 is in /etc/mk.conf - * Create a new directory, and run - - # url2pkg http://www.example.com/path/to/distfile.tar.gz - - You'll need to have pkgsrc/pkgtools/url2pkg installed for that. - * Edit the Makefile as requested. - * Fill in DESCR - * ``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 - [ mkpatches, patchdiff and pkgvi are from pkgsrc/pkgtools/pkgdiff ] - - Doing as non-root user will assure that no files are modified that - shouldn't, esp. not during the build phase. - * Look at Makefile, fix if necessary; see section 4.1. - * 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 brings up 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: - - # pkg_add ..../blub.tgz - - * Play with it. Make sure everything works. - * Run pkglint from pkgsrc/pkgtools/pkglint, and fix the problems it reports. - - # pkglint - - * Submit (or commit, if you have cvs access); see section 11. - - - 10 FAQs & features of the package system - ======================================== - - 10.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, and this may not be what you want. - - - 10.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 pkgsrc/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 - - - 10.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 -pkgsrc/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. - - - 10.4 Custom configuration process - ================================= - -Your package uses a weird Configure script: See the top package, but the -quick answer is: - - HAS_CONFIGURE= yes - CONFIGURE_SCRIPT= Configure - CONFIGURE_ARGS+= netbsd13 - - - 10.5 Packages not building in their DISTNAME directory - ====================================================== - -Your package builds in a different directory from its base DISTNAME - see -tcl and tk packages: - - WRKSRC= ${WRKDIR}/${DISTNAME}/unix - - - 10.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". But there's no archive of -the distfiles on ftp.netbsd.org and the one on ftp.freebsd.org contains -many distfiles for which there are no ports (yet). - -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 - % 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 typing: - - % make mirror-distfiles - -If you even decide to ignore NO_{SRC,BIN}_ON_{FTP,CDROM}, then you can -get all & everything by typing - - % make fetch NO_SKIP=yes - - - 10.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 look like: - - ftp_proxy=ftp://orpheus.amdahl.com:80/ - http_proxy=http://orpheus.amdahl.com:80/ - - - 10.8 If your patch contains an RCS ID - ===================================== - -See section 4.3 on how to remove RCS IDs from patch files. - - - 10.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 - -If you wish to set the CFLAGS variable in /etc/mk.conf please make sure -to use: - - CFLAGS+= -your -flags - -Using 'CFLAGS=' (ie without the '+') may lead to problems with packages -that need to add their own flags. Also, you may want to take a look at -the devel/cpuflags package, if you're interested in optimization for the -current CPU. - - - 10.10 Is there a mailing list for pkg-related discussion? - ========================================================= - -Yes. We are using tech-pkg@netbsd.org for discussing package related -issues. To subscribe do: - - % echo subscribe tech-pkg | mail majordomo@netbsd.org - - - 10.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. - - - 10.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 section 8). - -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). - -(a) 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 - -(b) If your package needs a library with which to link, this is specified -using the DEPENDS definition. An example of this is the pkgsrc/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-* DEPEND. - -(c) If your package needs some executable to be able to run correctly, this -is specified using the DEPENDS definition. The pkgsrc/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 pkgsrc/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 -pkgsrc/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 -pkgsrc/devel/gettext-m4 package. - - - 10.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 pkgsrc/x11/Xaw3d and pkgsrc/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". - - - 10.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. - - - 10.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. - - - 10.16 What does "Don't know how to make /usr/share/tmac/tmac.andoc" mean? - ========================================================================= - -When compiling the pkgsrc/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 pkg_install package, you can get away with setting -NOMAN=YES either in the environment or in /etc/mk.conf. - - - 10.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 - - - 10.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 /: - - # tar --unlink -pvxf .../comp.tgz - -comp.tgz is part of every NetBSD release, please get the one matching -the release you have installed (determine via "uname -r"). - - - 10.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! - - - 10.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: - USE_NCURSES= # redrawwin -The comment should indicate which functions are missing. - - - 10.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 -pkgsrc/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. - - - 10.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 set USE_PKGINSTALL to "YES" 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. - - - 10.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. - - - 10.24 Packages providing info files - =================================== - -Some packages install info files or use the makeinfo or install-info -commands. Each info files: - - 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. - -The installation process of the software provided by the package must not -use the install-info as the registration of info files -is the task of the package INSTALL SCRIPT, and it must use -the right makeinfo command. - -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 dummys- values of INSTALL_INFO and MAKEINFO in the -environment. - -*NOTE* Temporally 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. - - 10.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. - - - 10.26 Using pkgsrc on non-NetBSD (Darwin, FreeBSD, IRIX, Linux, OpenBSD, Solaris) - ================================================================================= - -In order to use pkgsrc on a non-NetBSD operating system, you must first -bootstrap the necessary utilities (BSD make, pkg_*, ...). See -http://www.netbsd.org/Documentation/software/packages.html#bootstrap -for information on boostrapping. Binary bootstrap-kits are available from that -URL as well. If your Operating System is not yet supported, we encourage you to -port the bootstrap-kit and submit your changes. - - - 10.27 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 set USE_PKGINSTALL -to "YES" 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. - - - 10.28 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 set USE_PKGINSTALL to "YES" -prior to the inclusion of bsd.pkg.mk to use the automatically generated -INSTALL/DEINSTALL scripts. - -An example taken from shells/zsh: - - USE_PKGINSTALL= YES - PKG_SHELL= ${PREFIX}/bin/zsh - -The shell is registered into /etc/shells file automatically in the -post-install step by the auto-generated INSTALL script and removed in the -deinstall step by the DEINSTALL script. - - - 10.29 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 also section 5.1 for -details about ${PKGLOCALEDIR}. This functionality is buildlink2-only. - - - 10.30 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 -pkgsrc/security/sudo) and then put the following into your /etc/mk.conf: - - SU_CMD=/usr/pkg/bin/sudo /bin/sh -c - - - 10.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. - - - 10.32 Packages which should not be deleted, once installed - ========================================================== - -To ensure that a package may not be deleted, once it has been installed, -the PKG_PRESERVE definition should be set in the package Makefile. This -will be carried into any binary package that is made from this pkgsrc -entry. A "preserved" package will not be deleted using pkg_delete(1), -unless the "-f" option is used. - - 10.33 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 Submitting & Committing - ========================== - - 11.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 - section 9 and the rest of this document. Next, generate an uuencoded - gzipped tar(1) archive, preferably with all files in a single directory. - Finally, send-pr(1) with category "pkg", a synopsis which includes the - package name and version number, a short description of your package - (contents of the COMMENT variable or DESCR file are OK) and attach the - archive to your PR. - - 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. - - - 11.2 Committing: Importing the 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 - -and 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. - - - 11.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. - - - 11.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. - - - 12 A simple example of a package: bison - ======================================= - -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. - - - 12.1 files - ========== - -The file contents in this section must be used without the "> " prefix. - - - 12.1.1 Makefile - =============== - - # <$>NetBSD<$> - - DISTNAME= bison-1.25 - CATEGORIES= devel - MASTER_SITES= ${MASTER_SITE_GNU} - MAINTAINER= thorpej@netbsd.org - HOMEPAGE= http://www.gnu.org/software/bison/bison.html - COMMENT= GNU yacc clone - - GNU_CONFIGURE= yes - INFO_FILES= bison.info - - .include "../../mk/bsd.pkg.mk" - - - 12.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. - - - 12.1.3 PLIST - ================ - - @comment <$>NetBSD<$> - bin/bison - man/man1/bison.1.gz - info/bison.info - info/bison.info-1 - info/bison.info-2 - info/bison.info-3 - info/bison.info-4 - info/bison.info-5 - share/bison.simple - share/bison.hairy - - - 12.1.4 Checking a package "pkglint" - =================================== - -The NetBSD package system comes with a tool called "pkglint" (located in the -directory "pkgsrc/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 "man pkglint") more -verbose checks will be performed. Use e.g. "pkglint -v" for a very verbose -check. - - - 12.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 pkg - -Create Makefile, DESCR and PLIST as in section 11.1, -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 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include -g LR0.c - cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include -g allocate.c - cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include -g closure.c - cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include -g conflicts.c - cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include -g derives.c - cc -c -DXPFILE=\"/usr/pkg/share/bison.simple\" -DXPFILE1=\"/usr/pkg/share/bison.hairy\" -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -g ./files.c - cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include -g getargs.c - cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include -g gram.c - cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include -g lalr.c - cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include -g lex.c - cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include -g main.c - cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include -g nullable.c - cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include -g output.c - cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include -g print.c - cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include -g reader.c - cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include -g reduce.c - cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include -g symtab.c - cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include -g warshall.c - cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include -g version.c - cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include -g getopt.c - cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include -g getopt1.c - cc -g -o bison LR0.o allocate.o closure.o conflicts.o derives.o files.o getargs.o gram.o lalr.o lex.o main.o nullable.o output.o print.o reader.o reduce.o symtab.o warshall.o version.o getopt.o getopt1.o - ./files.c:240: warning: mktemp() possibly used unsafely, consider using mkstemp() - rm -f bison.s1 - sed -e "/^#line/ s|bison|/usr/pkg/share/bison|" < ./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.hairy - cd .; for f in bison.info*; do /usr/bin/install -c -o bin -g bin -m 644 $f /usr/pkg/info/$f; done - /usr/bin/install -c -o bin -g bin -m 644 ./bison.1 /usr/pkg/man/man1/bison.1 - ===> Registering installation for bison-1.25 - -You can now use bison, and also - if you decide so - remove it with -"pkg_delete bison-1.25". 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 A: build logs -====================== - - A.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://orpheus.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 getopt.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 - # - - - A.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 B: 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.5/ - i386/ - All/ - archivers/ - foo -> ../All/foo - ... - m68k/ - All/ - archivers/ - foo -> ../All/foo - ... - amiga -> m68k - atari -> m68k - ... - - -To create: - - cd /usr/pkgsrc ; make install ; make package - - upload /usr/pkgsrc/packages to - ftp://ftp.netbsd.org/pub/NetBSD/packages/\ - `uname -r | sed 's@\.\([0-9]*\)[\._].*@\.\1@'`/`uname -p` - - if necessary ln -s `uname -m` `uname -p` - -Disk space needed: unknown. - -Packages for a release version of NetBSD should be uploaded to the -directory major.minor corresponding to the appropriate release. Packages -for NetBSD with versions such as "1.5.1" should be uploaded to the "1.5" -directory, stripping the tiny number off the directory name. For packages -that need to be tightly coupled with the OS Version, such as LKM's, you -may create a major.minor.tiny release directory, and place those packages -therein. Such packages should be marked with the variable -"OSVERSION_SPECIFIC=yes" to mark them in some way for binary package -builders. - - -########################################################################### -# Local Variables: -# mode: Text -# fill-column: 75 -# sentence-end-double-space: nil -# End: +pkgsrc.txt and pkgsrc.html are also provided in the top level pkgsrc +directory (this directory). diff --git a/pkgsrc.html b/pkgsrc.html new file mode 100644 index 00000000000..c3e5cabd26b --- /dev/null +++ b/pkgsrc.html @@ -0,0 +1,5198 @@ +<html> +<head> +<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"> +<title>The NetBSD Packages Collection (pkgsrc)</title> +<link rel="stylesheet" href="/NetBSD.css" type="text/css"> +<meta name="generator" content="DocBook XSL Stylesheets V1.60.1"> +<meta name="description" content="Information about using the NetBSD package system and + building packages."> +</head> +<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="book" lang="en"> +<div class="titlepage"> +<div> +<div><h1 class="title"> +<a name="id2856616"></a>The NetBSD Packages Collection (pkgsrc)</h1></div> +<div><div class="authorgroup"> +<div class="author"> +<h3 class="author"> +<span class="firstname">Alistair</span> <span class="surname">Crooks</span> +</h3> +<div class="affiliation"><div class="address"><p><tt class="email"><<a href="mailto:agc@NetBSD.org">agc@NetBSD.org</a>></tt></p></div></div> +</div> +<div class="author"> +<h3 class="author"> +<span class="firstname">Hubert</span> <span class="surname">Feyrer</span> +</h3> +<div class="affiliation"><div class="address"><p><tt class="email"><<a href="mailto:hubertf@NetBSD.org">hubertf@NetBSD.org</a>></tt></p></div></div> +</div> +</div></div> +<div><p class="releaseinfo">$NetBSD: pkgsrc.html,v 1.1 2003/06/23 07:41:44 grant Exp $</p></div> +<div><p class="copyright">Copyright © 1994-2003 The NetBSD Foundation, Inc</p></div> +<div><div class="abstract"> +<p class="title"><b>Abstract</b></p> +<p>Information about using the NetBSD package system and + building packages.</p> +</div></div> +</div> +<div></div> +<hr> +</div> +<div class="toc"> +<p><b>Table of Contents</b></p> +<dl> +<dt>1. <a href="#introduction">Introduction</a> +</dt> +<dd><dl> +<dt>1.1. <a href="#id2862064">Introduction</a> +</dt> +<dt>1.2. <a href="#overview">Overview</a> +</dt> +<dt>1.3. <a href="#terminology">Terminology</a> +</dt> +<dt>1.4. <a href="#typography">Typography</a> +</dt> +</dl></dd> +<dt>I. <a href="#users-guide">pkgsrc user's guide</a> +</dt> +<dd><dl> +<dt>2. <a href="#platforms">Using pkgsrc on systems other than NetBSD</a> +</dt> +<dd><dl> +<dt>2.1. <a href="#id2862465">Bootstrapping pkgsrc</a> +</dt> +<dt>2.2. <a href="#id2863843">Platform specific notes</a> +</dt> +</dl></dd> +<dt>3. <a href="#using">Using The NetBSD package system</a> +</dt> +<dd><dl> +<dt>3.1. <a href="#getting%20started">Working with binary packages</a> +</dt> +<dt>3.2. <a href="#id2937398">Building packages from source</a> +</dt> +</dl></dd> +<dt>4. <a href="#binary">Creating binary packages</a> +</dt> +<dd><dl> +<dt>4.1. <a href="#id2936710">Building a single binary package</a> +</dt> +<dt>4.2. <a href="#id2939394">Settings for creation of binary packages</a> +</dt> +<dt>4.3. <a href="#id2939411">Doing a bulk build of all packages</a> +</dt> +<dt>4.4. <a href="#id2940945">Creating a multiple CD-ROM packages collection</a> +</dt> +</dl></dd> +</dl></dd> +<dt>II. <a href="#developers-guide">pkgsrc developer's guide</a> +</dt> +<dd><dl> +<dt>5. <a href="#components">Package components - files, directories and contents</a> +</dt> +<dd><dl> +<dt>5.1. <a href="#components.Makefile">Makefile</a> +</dt> +<dt>5.2. <a href="#components.distinfo">distinfo</a> +</dt> +<dt>5.3. <a href="#components.patches">patches/*</a> +</dt> +<dt>5.4. <a href="#id2943680">Other mandatory files</a> +</dt> +<dt>5.5. <a href="#id2943718">Optional files</a> +</dt> +<dt>5.6. <a href="#id2943959">work*</a> +</dt> +<dt>5.7. <a href="#id2943990">files/*</a> +</dt> +<dt>5.8. <a href="#id2944093">Portability of packages</a> +</dt> +</dl></dd> +<dt>6. <a href="#plist">PLIST issues</a> +</dt> +<dd><dl> +<dt>6.1. <a href="#plist.misc">Miscellaneous</a> +</dt> +<dt>6.2. <a href="#id2945543">PLIST_SRC</a> +</dt> +<dt>6.3. <a href="#id2945566">PLIST_SUBST</a> +</dt> +<dt>6.4. <a href="#id2945697">Perl5 modules</a> +</dt> +<dt>6.5. <a href="#id2945836">User Interaction</a> +</dt> +</dl></dd> +<dt>7. <a href="#fixes">Notes on fixes for packages</a> +</dt> +<dd><dl> +<dt>7.1. <a href="#id2944290">CPP defines</a> +</dt> +<dt>7.2. <a href="#fixes.libtool">Shared libraries - libtool</a> +</dt> +<dt>7.3. <a href="#id2947315">Using libtool on GNU packages that already support libtool</a> +</dt> +<dt>7.4. <a href="#id2947414">GNU Autoconf/Automake</a> +</dt> +<dt>7.5. <a href="#id2947454">Package configuration files</a> +</dt> +<dt>7.6. <a href="#id2947668">Feedback to the author</a> +</dt> +</dl></dd> +<dt>8. <a href="#build">The build process</a> +</dt> +<dd><dl> +<dt>8.1. <a href="#build.prefix">Program location</a> +</dt> +<dt>8.2. <a href="#id2949108">Main targets</a> +</dt> +<dt>8.3. <a href="#build.helpful-targets">Other helpful targets</a> +</dt> +</dl></dd> +<dt>9. <a href="#buildlink2">buildlink2 methodology</a> +</dt> +<dd><dl> +<dt>9.1. <a href="#id2953172">Converting packages to use buildlink2</a> +</dt> +<dt>9.2. <a href="#id2953308">Writing buildlink2.mk files</a> +</dt> +</dl></dd> +<dt>10. <a href="#debug">Debugging</a> +</dt> +<dt>11. <a href="#features">FAQs & features of the package system</a> +</dt> +<dd><dl> +<dt>11.1. <a href="#id2952494">Packages using GNU autoconf</a> +</dt> +<dt>11.2. <a href="#id2954262">Other distrib methods than .tar.gz</a> +</dt> +<dt>11.3. <a href="#id2954307">Packages not creating their own subdirectory</a> +</dt> +<dt>11.4. <a href="#id2955763">Custom configuration process</a> +</dt> +<dt>11.5. <a href="#id2955785">Packages not building in their DISTNAME directory</a> +</dt> +<dt>11.6. <a href="#id2955896">How to fetch all distfiles at once</a> +</dt> +<dt>11.7. <a href="#id2956076">How to fetch files from behind a firewall</a> +</dt> +<dt>11.8. <a href="#id2956098">If your patch contains an RCS ID</a> +</dt> +<dt>11.9. <a href="#id2956116">How to pull in variables from /etc/mk.conf</a> +</dt> +<dt>11.10. <a href="#id2956180">Is there a mailing list for pkg-related discussion?</a> +</dt> +<dt>11.11. <a href="#id2956204">How do I tell make fetch to do passive FTP?</a> +</dt> +<dt>11.12. <a href="#id2956350">Dependencies on other packages</a> +</dt> +<dt>11.13. <a href="#id2956571">Conflicts with other packages</a> +</dt> +<dt>11.14. <a href="#id2956642">Software which has a WWW Home Page</a> +</dt> +<dt>11.15. <a href="#id2956667">How to handle modified distfiles with the 'old' name</a> +</dt> +<dt>11.16. <a href="#id2956764">What does "Don't know how to make /usr/share/tmac/tmac.andoc" mean?</a> +</dt> +<dt>11.17. <a href="#id2956809">How to handle incrementing versions when fixing an existing +package</a> +</dt> +<dt>11.18. <a href="#id2956956">Could not find bsd.own.mk - what's wrong?</a> +</dt> +<dt>11.19. <a href="#id2957027">Restricted packages</a> +</dt> +<dt>11.20. <a href="#id2957213">Packages using (n)curses</a> +</dt> +<dt>11.21. <a href="#id2957255">Automated security check</a> +</dt> +<dt>11.22. <a href="#id2957425">What's the proper way to create an account from a package?</a> +</dt> +<dt>11.23. <a href="#id2957593">How to handle compiler bugs</a> +</dt> +<dt>11.24. <a href="#features.info-files">Packages providing info files</a> +</dt> +<dt>11.25. <a href="#id2957793">Packages whose distfiles aren't available for plain downloading</a> +</dt> +<dt>11.26. <a href="#id2957953">Configuration files handling and placement</a> +</dt> +<dt>11.27. <a href="#id2958470">Packages providing login shells</a> +</dt> +<dt>11.28. <a href="#id2958558">Packages providing locale catalogues</a> +</dt> +<dt>11.29. <a href="#id2958592">Using 'sudo' with pkgsrc</a> +</dt> +<dt>11.30. <a href="#id2958621">Packages containing perl scripts</a> +</dt> +<dt>11.31. <a href="#id2958648">Packages that cannot or should not be built</a> +</dt> +</dl></dd> +<dt>12. <a href="#submit">Submitting and Committing</a> +</dt> +<dd><dl> +<dt>12.1. <a href="#id2960258">Submitting your packages</a> +</dt> +<dt>12.2. <a href="#id2961824">Committing: Importing a package into CVS</a> +</dt> +<dt>12.3. <a href="#id2962087">Updating a Package to a Newer Version</a> +</dt> +<dt>12.4. <a href="#id2962208">Moving a Package in pkgsrc</a> +</dt> +</dl></dd> +<dt>13. <a href="#examples">A simple example of a package: bison</a> +</dt> +<dd><dl> +<dt>13.1. <a href="#id2961656">files</a> +</dt> +<dt>13.2. <a href="#id2963176">Steps for building, installing, packaging</a> +</dt> +</dl></dd> +</dl></dd> +<dt>A. <a href="#logs">Build logs</a> +</dt> +<dd><dl> +<dt>A.1. <a href="#logs.building">Building top</a> +</dt> +<dt>A.2. <a href="#logs.package">Packaging top</a> +</dt> +</dl></dd> +<dt>B. <a href="#ftp-layout">Layout of the FTP server's package archive</a> +</dt> +</dl> +</div> +<div class="chapter" lang="en"> +<div class="titlepage"> +<div><div><h2 class="title"> +<a name="introduction"></a>Chapter 1. Introduction</h2></div></div> +<div></div> +</div> +<div class="toc"> +<p><b>Table of Contents</b></p> +<dl> +<dt>1.1. <a href="#id2862064">Introduction</a> +</dt> +<dt>1.2. <a href="#overview">Overview</a> +</dt> +<dt>1.3. <a href="#terminology">Terminology</a> +</dt> +<dt>1.4. <a href="#typography">Typography</a> +</dt> +</dl> +</div> +<div class="sect1" lang="en"> +<div class="titlepage"> +<div><div><h2 class="title" style="clear: both"> +<a name="id2862064"></a>1.1. Introduction</h2></div></div> +<div></div> +</div> +<p>The NetBSD package system, <span class="emphasis"><em>pkgsrc</em></span>, +is a framework for building third-party software on NetBSD and other +UNIX-like systems. It is used to enable such freely available +software to be configured and built easily on supported platforms.</p> +<p>Once the software +has been built, it is manipulated with the pkg_* tools so that installation +and de-installation, printing of an inventory of all installed packages and +retrieval of one-line comments or more verbose descriptions are all +simple.</p> +<p>pkgsrc currently contains over 3500 packages, including:</p> +<div class="itemizedlist"><ul type="disc"> +<li> +<a xmlns:html="http://www.w3.org/1999/xhtml" href="ftp://ftp.netbsd.org/pub/NetBSD/packages/pkgsrc/www/apache/README.html" class="pkgname">www/apache</a> - The Apache web server</li> +<li> +<a xmlns:html="http://www.w3.org/1999/xhtml" href="ftp://ftp.netbsd.org/pub/NetBSD/packages/pkgsrc/www/mozilla/README.html" class="pkgname">www/mozilla</a> - The Mozilla web browser</li> +<li> +<a xmlns:html="http://www.w3.org/1999/xhtml" href="ftp://ftp.netbsd.org/pub/NetBSD/packages/pkgsrc/x11/gnome/README.html" class="pkgname">x11/gnome</a> - The GNOME Desktop Environment</li> +<li> +<a xmlns:html="http://www.w3.org/1999/xhtml" href="ftp://ftp.netbsd.org/pub/NetBSD/packages/pkgsrc/x11/kde3/README.html" class="pkgname">x11/kde3</a> - The K Desktop Environment</li> +</ul></div> +<p>...just to name a few.</p> +<p>pkgsrc has built-in support for handling varying dependencies, +such as pthreads and X11, and extended features such as IPv6 support on +a range of platforms.</p> +<p>pkgsrc was originally developed on NetBSD, and now supports the +following platforms:</p> +<div class="itemizedlist"><ul type="disc"> +<li> +<a href="http://developer.apple.com/darwin/" target="_top">Darwin</a> + (<a href="http://www.apple.com/macosx/" target="_top">MacOS X</a>)</li> +<li><a href="http://www.FreeBSD.org/" target="_top">FreeBSD</a></li> +<li><a href="http://www.sgi.com/software/irix6.5/" target="_top">IRIX</a></li> +<li><a href="http://www.linux.org/" target="_top">Linux</a></li> +<li> +<a href="http://www.NetBSD.org/" target="_top">NetBSD</a> (of + course)</li> +<li><a href="http://www.openbsd.org/" target="_top">OpenBSD</a></li> +<li><a href="http://www.sun.com/solaris/" target="_top">Solaris</a></li> +</ul></div> +</div> +<div class="sect1" lang="en"> +<div class="titlepage"> +<div><div><h2 class="title" style="clear: both"> +<a name="overview"></a>1.2. Overview</h2></div></div> +<div></div> +</div> +<p> +This document is divided into two parts. The first, <a href="#users-guide" title="Part I. pkgsrc user's guide">pkgsrc user's guide</a>, +describes how one can use one of the packages in the Package +Collection, either by installing a precompiled binary package, or +by building one's own copy using the NetBSD package system. The +second part, <a href="#developers-guide" title="Part II. pkgsrc developer's guide">pkgsrc developer's guide</a>, explains how to prepare +a package so it can be easily built by other NetBSD users without +knowing about the package's building details. +</p> +</div> +<div class="sect1" lang="en"> +<div class="titlepage"> +<div><div><h2 class="title" style="clear: both"> +<a name="terminology"></a>1.3. Terminology</h2></div></div> +<div></div> +</div> +<p> +There has been a lot of talk about “<span class="quote">ports</span>”, +“<span class="quote">packages</span>”, etc. so far. Here is a description of all the +terminology used within this document. +</p> +<div class="itemizedlist"><ul type="disc"> +<li> +<p><span class="emphasis"><em>Package</em></span></p> +<p> +A set of files and building instructions that describe what's necessary +to build a certain piece of software using the NetBSD package +system. Packages are traditionally stored under +<tt class="filename">/usr/pkgsrc</tt>. +</p> +</li> +<li> +<p><span class="emphasis"><em>The NetBSD package system</em></span></p> +<p> +This is the part of the NetBSD operating system handling building +(compiling), installing, and removing of packages. +</p> +</li> +<li> +<p><span class="emphasis"><em>Distfile</em></span></p> +<p> +This term describes the file or files that are provided by the author +of the piece of freely available software to distribute his work. All +the changes necessary to build on NetBSD are reflected in the +corresponding package. Usually the distfile is in the form of a +compressed tar-archive, but other types are possible, too. Distfiles +are stored below <tt class="filename">/usr/pkgsrc/distfiles</tt>. +</p> +</li> +<li> +<p><span class="emphasis"><em>Port</em></span></p> +<p> +This is the term used by FreeBSD people for what we call a package. +In NetBSD terminology, “<span class="quote">port</span>” refers to a different +architecture. +</p> +</li> +<li> +<p><span class="emphasis"><em>Precompiled (binary) package</em></span></p> +<p> +A set of binaries built by the NetBSD package system from a distfile +using the NetBSD package system and stuffed together in a single +<tt class="filename">.tgz</tt> file so it can be installed on machines of the +same machine architecture without the need to recompile. Packages are +generated in <tt class="filename">/usr/pkgsrc/packages</tt> by the NetBSD +package system; there is also an archive on <a href="ftp://ftp.NetBSD.org/pub/NetBSD/packages/" target="_top">ftp.NetBSD.org</a>. +</p> +<p> +Sometimes, this is referred to by the term “<span class="quote">package</span>” too, +especially in the context of precompiled packages. +</p> +</li> +<li> +<p><span class="emphasis"><em>Program</em></span></p> +<p> +The piece of software to be installed which will be constructed from +all the files in the Distfile by the actions defined in the +corresponding package. +</p> +</li> +</ul></div> +</div> +<div class="sect1" lang="en"> +<div class="titlepage"> +<div><div><h2 class="title" style="clear: both"> +<a name="typography"></a>1.4. Typography</h2></div></div> +<div></div> +</div> +<p> +When giving examples for commands, shell prompts are used to show if the +command should/can be issued as root, or if “<span class="quote">normal</span>” user +privileges are sufficient. We use a “<span class="quote">#</span>” for root's shell +prompt, and a “<span class="quote">%</span>” for users' shell prompt, assuming they use +the C-shell or tcsh. +</p> +</div> +</div> +<div class="part" lang="en"> +<div class="titlepage"> +<div><div><h1 class="title"> +<a name="users-guide"></a>pkgsrc user's guide</h1></div></div> +<div></div> +</div> +<div class="toc"> +<p><b>Table of Contents</b></p> +<dl> +<dt>2. <a href="#platforms">Using pkgsrc on systems other than NetBSD</a> +</dt> +<dd><dl> +<dt>2.1. <a href="#id2862465">Bootstrapping pkgsrc</a> +</dt> +<dt>2.2. <a href="#id2863843">Platform specific notes</a> +</dt> +</dl></dd> +<dt>3. <a href="#using">Using The NetBSD package system</a> +</dt> +<dd><dl> +<dt>3.1. <a href="#getting%20started">Working with binary packages</a> +</dt> +<dt>3.2. <a href="#id2937398">Building packages from source</a> +</dt> +</dl></dd> +<dt>4. <a href="#binary">Creating binary packages</a> +</dt> +<dd><dl> +<dt>4.1. <a href="#id2936710">Building a single binary package</a> +</dt> +<dt>4.2. <a href="#id2939394">Settings for creation of binary packages</a> +</dt> +<dt>4.3. <a href="#id2939411">Doing a bulk build of all packages</a> +</dt> +<dt>4.4. <a href="#id2940945">Creating a multiple CD-ROM packages collection</a> +</dt> +</dl></dd> +</dl> +</div> +<div class="chapter" lang="en"> +<div class="titlepage"> +<div><div><h2 class="title"> +<a name="platforms"></a>Chapter 2. Using pkgsrc on systems other than NetBSD</h2></div></div> +<div></div> +</div> +<div class="toc"> +<p><b>Table of Contents</b></p> +<dl> +<dt>2.1. <a href="#id2862465">Bootstrapping pkgsrc</a> +</dt> +<dt>2.2. <a href="#id2863843">Platform specific notes</a> +</dt> +</dl> +</div> +<div class="sect1" lang="en"> +<div class="titlepage"> +<div><div><h2 class="title" style="clear: both"> +<a name="id2862465"></a>2.1. Bootstrapping pkgsrc</h2></div></div> +<div></div> +</div> +<p> +For Operating Systems other than NetBSD, we provide a bootstrap kit to +build the required tools to use pkgsrc on your platform. As well as +native NetBSD support, pkgsrc and the bootstrap kit have support for +the following operating systems: +</p> +<div class="itemizedlist"><ul type="disc"> +<li>Darwin (MacOS X)</li> +<li>FreeBSD</li> +<li>IRIX</li> +<li>Linux</li> +<li>OpenBSD</li> +<li>Solaris</li> +</ul></div> +<p> +Support for other platforms is under development. +</p> +<p> +Installing the bootstrap kit should be as simple as: +</p> +<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre><tt class="prompt">#</tt> <b class="userinput"><tt>cvs checkout othersrc/bootstrap-pkgsrc</tt></b> +<tt class="prompt">#</tt> <b class="userinput"><tt>cd othersrc/bootstrap-pkgsrc</tt></b> +<tt class="prompt">#</tt> <b class="userinput"><tt>./bootstrap</tt></b></pre></td></tr></table> +<p> +This will use the defaults of <tt class="filename">/usr/pkg</tt> for the +<span class="emphasis"><em>prefix</em></span> +and <tt class="filename">/var/db/pkg</tt> for the package database directory. +However, these can also be set using command-line parameters. +</p> +<p> +Binary packages for the pkgsrc tools and an initial set of packages is +available for supported platforms. An up-to-date list of these can be +found on <a href="../../software/packages.html" target="_top">www.pkgsrc.org</a>. +</p> +</div> +<div class="sect1" lang="en"> +<div class="titlepage"> +<div><div><h2 class="title" style="clear: both"> +<a name="id2863843"></a>2.2. Platform specific notes</h2></div></div> +<div></div> +</div> +<p> +Here are some platform-specific notes you should be aware of. +</p> +<div class="sect2" lang="en"> +<div class="titlepage"> +<div><div><h3 class="title"> +<a name="id2863854"></a>2.2.1. Darwin (Mac OS X)</h3></div></div> +<div></div> +</div> +<p> +Darwin 5.x and 6.x are supported. There are two methods of using +pkgsrc on Mac OS X, by using a <a href="#platform.osx-image" title="2.2.1.1. Using a disk image">disk +image</a>, or a <a href="#platform.osx-ufs" title="2.2.1.2. Using a UFS partition">UFS +partition</a>. +</p> +<p> +If you already have a UFS partition, or have a spare partition +that you can format as UFS, it is recommended to use that instead of +the disk image. It'll be somewhat faster and will mount automatically +at boot time, where you must manually mount a disk image. +</p> +<div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"> +<h3 class="title">Note</h3> +You cannot use a HFS+ file system for pkgsrc, because pkgsrc currently +requires the filesystem to be case-sensitive, and HFS+ is not. +</div> +<div class="sect3" lang="en"> +<div class="titlepage"> +<div><div><h4 class="title"> +<a name="platform.osx-image"></a>2.2.1.1. Using a disk image</h4></div></div> +<div></div> +</div> +<p> +Create the disk image: +</p> +<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre><tt class="prompt">#</tt> <b class="userinput"><tt>cd bootstrap-pkgsrc</tt></b> +<tt class="prompt">#</tt> <b class="userinput"><tt>./ufsdiskimage create ~/Documents/NetBSD 512</tt></b> # megabytes - season to taste +<tt class="prompt">#</tt> <b class="userinput"><tt>./ufsdiskimage mount ~/Documents/NetBSD</tt></b> +<tt class="prompt">#</tt> <b class="userinput"><tt>sudo chown `id -u`:`id -g` /Volumes/NetBSD</tt></b></pre></td></tr></table> +<p> +That's it! +</p> +</div> +<div class="sect3" lang="en"> +<div class="titlepage"> +<div><div><h4 class="title"> +<a name="platform.osx-ufs"></a>2.2.1.2. Using a UFS partition</h4></div></div> +<div></div> +</div> +<p> +By default, <tt class="filename">/usr</tt> will be on your root file +system, normally HFS+. It is possible to use the default +<span class="emphasis"><em>prefix</em></span> of <tt class="filename">/usr/pkg</tt> +by symlinking <tt class="filename">/usr/pkg</tt> to a directory on a UFS +file system. Obviously, another symlink is required if you want to +place the package database directory outside the +<span class="emphasis"><em>prefix</em></span>. e.g. + +</p> +<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre><tt class="prompt">#</tt> <b class="userinput"><tt>./bootstrap --pkgdbdir=/usr/pkg/pkgdb --pkgsrc=/Volumes/ufs/pkgsrc</tt></b></pre></td></tr></table> +<p> +</p> +<p> +If you created your partitions at the time of installing Mac OS X +and formatted the target partition as UFS, it should automatically +mount on <tt class="filename">/Volumes/<volume name></tt> when the +machine boots. If you are (re)formatting a partition as UFS, you need +to ensure that the partition map correctly reflects +“<span class="quote">Apple_UFS</span>” and not “<span class="quote">Apple_HFS</span>”. +</p> +<p> +The problem is that none of the disk tools will let you touch a +disk that is booted from. You can unmount the partition, but even if +you newfs it, the partition type will be incorrect and the +automounter won't mount it. It can be mounted manually, but it won't +appear in Finder. +</p> +<p> +You'll need to boot off of the OS X Installation (User) CD. When +the Installation program starts, go up to the menu and select Disk +Utility. Now, you will be able to select the partition you want +to be UFS, and Format it Apple UFS. Quit the Disk Utility, quit the +installer which will reboot your machine. The new UFS file system +will appear in Finder. +</p> +<p> +Be aware that the permissions on the new file system will be writable +by root only. +</p> +<p> +This note is as of 10.2 (Jaguar) and applies to earlier versions. +Hopefully Apple will fix Disk Utility in 10.3 (Panther). +</p> +</div> +</div> +<div class="sect2" lang="en"> +<div class="titlepage"> +<div><div><h3 class="title"> +<a name="id2865702"></a>2.2.2. FreeBSD</h3></div></div> +<div></div> +</div> +<p> +FreeBSD 4.7 and 5.0 have been tested and are supported, other versions +may work. +</p> +<p> +Care should be taken so that the tools that this kit installs do not conflict +with the FreeBSD userland tools. There are several steps: +</p> +<div class="orderedlist"><ol type="1"> +<li><p> +FreeBSD stores its ports pkg database in +<tt class="filename">/var/db/pkg</tt>. It is therefore +recommended that you choose a different location (e.g. +<tt class="filename">/usr/pkgdb</tt>) by +using the --pkgdbdir option to the bootstrap script. +</p></li> +<li> +<p> +If you do not intend to use the FreeBSD ports tools, it's probably a +good idea to move them out of the way to avoid confusion, e.g. +</p> +<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre><tt class="prompt">#</tt> <b class="userinput"><tt>cd /usr/sbin</tt></b> +<tt class="prompt">#</tt> <b class="userinput"><tt>mv pkg_add pkg_add.orig</tt></b> +<tt class="prompt">#</tt> <b class="userinput"><tt>mv pkg_create pkg_create.orig</tt></b> +<tt class="prompt">#</tt> <b class="userinput"><tt>mv pkg_delete pkg_delete.orig</tt></b> +<tt class="prompt">#</tt> <b class="userinput"><tt>mv pkg_info pkg_info.orig</tt></b></pre></td></tr></table> +</li> +<li><p> +An example <tt class="filename">/etc/mk.conf</tt> file will be placed in +<tt class="filename">/etc/mk.conf.example</tt> file +when you use the bootstrap script. +</p></li> +</ol></div> +</div> +<div class="sect2" lang="en"> +<div class="titlepage"> +<div><div><h3 class="title"> +<a name="id2935473"></a>2.2.3. IRIX</h3></div></div> +<div></div> +</div> +<p> +IRIX 6.5 is tested and supported, other versions may work. +</p> +<p> +You will need a working C compiler, either gcc or SGI's MIPS +and MIPSpro compiler (cc/c89). Please set the <tt class="varname">CC</tt> +environment variable according to your preference. +</p> +<p> +Please make sure that you have no conflicting +<tt class="varname">CFLAGS</tt> in your environment or the +<tt class="filename">/etc/mk.conf</tt>. Particularly, make sure that you do +not try to link n32 object files with lib64 or vice versa. Check your +<tt class="filename">/etc/compiler.defaults</tt>! +</p> +</div> +<div class="sect2" lang="en"> +<div class="titlepage"> +<div><div><h3 class="title"> +<a name="id2935518"></a>2.2.4. OpenBSD</h3></div></div> +<div></div> +</div> +<p> +OpenBSD 3.0 and 3.2 are tested and supported. +</p> +<p> +Care should be taken so that the tools that this kit installs do not conflict +with the OpenBSD userland tools. There are several steps: +</p> +<div class="orderedlist"><ol type="1"> +<li><p> +OpenBSD stores its ports pkg database in +<tt class="filename">/var/db/pkg</tt>. It is therefore +recommended that you choose a different location (e.g. +<tt class="filename">/usr/pkgdb</tt>) by +using the --pkgdbdir option to the bootstrap script. +</p></li> +<li> +<p> +If you do not intend to use the OpenBSD ports tools, it's probably a +good idea to move them out of the way to avoid confusion, e.g. +</p> +<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre><tt class="prompt">#</tt> <b class="userinput"><tt>cd /usr/sbin</tt></b> +<tt class="prompt">#</tt> <b class="userinput"><tt>mv pkg_add pkg_add.orig</tt></b> +<tt class="prompt">#</tt> <b class="userinput"><tt>mv pkg_create pkg_create.orig</tt></b> +<tt class="prompt">#</tt> <b class="userinput"><tt>mv pkg_delete pkg_delete.orig</tt></b> +<tt class="prompt">#</tt> <b class="userinput"><tt>mv pkg_info pkg_info.orig</tt></b></pre></td></tr></table> +</li> +<li> +<p> +An example <tt class="filename">/etc/mk.conf</tt> file will be placed in +<tt class="filename">/etc/mk.conf.example</tt> file +when you use the bootstrap script. OpenBSD's make program uses +<tt class="filename">/etc/mk.conf</tt> +as well. You can work around this by enclosing all the pkgsrc specific parts +of the file with: +</p> +<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre>.ifdef BSD_PKG_MK +# pkgsrc stuff, e.g. insert bsd.pkg.defaults.mk or similar here +.else +# OpenBSD stuff +.endif</pre></td></tr></table> +</li> +</ol></div> +</div> +<div class="sect2" lang="en"> +<div class="titlepage"> +<div><div><h3 class="title"> +<a name="id2935748"></a>2.2.5. Solaris</h3></div></div> +<div></div> +</div> +<p> +Solaris 2.6 through 9 are supported. You will need a working C +compiler. Both gcc 2.95.3 and Sun WorkShop 5 have been tested. +</p> +<p> +The following packages are required on Solaris 8 for the bootstrap +process and to build packages. +</p> +<div class="itemizedlist"><ul type="disc"> +<li>SUNWsprot</li> +<li>SUNWarc</li> +<li>SUNWbtool</li> +<li>SUNWtoo</li> +<li>SUNWlibm</li> +</ul></div> +<p> +Please note the use of GNU binutils on Solaris is +<span class="emphasis"><em>not</em></span> supported. +</p> +<div class="sect3" lang="en"> +<div class="titlepage"> +<div><div><h4 class="title"> +<a name="id2935793"></a>2.2.5.1. If you are using gcc</h4></div></div> +<div></div> +</div> +<p> +It makes life much simpler if you only use the same gcc consistently +for building all packages. +</p> +<p> +It is recommended that an external gcc be used only for bootstrapping, +then either build gcc from <a xmlns:html="http://www.w3.org/1999/xhtml" href="ftp://ftp.netbsd.org/pub/NetBSD/packages/pkgsrc/lang/gcc/README.html" class="pkgname">lang/gcc</a> or install a binary gcc +package, then remove gcc used during bootstrapping. +</p> +</div> +<div class="sect3" lang="en"> +<div class="titlepage"> +<div><div><h4 class="title"> +<a name="id2935811"></a>2.2.5.2. If you are using Sun WorkShop</h4></div></div> +<div></div> +</div> +<p> +You will need at least the following packages installed (from WorkShop +5.0) +</p> +<div class="itemizedlist"><ul type="disc"> +<li>SPROcc - Sun WorkShop Compiler C 5.0</li> +<li>SPROcpl - Sun WorkShop Compiler C++ 5.0</li> +<li>SPROild - Sun WorkShop Incremental Linker</li> +<li>SPROlang - Sun WorkShop Compilers common components</li> +</ul></div> +<p> +You should set <tt class="varname">CC</tt>, <tt class="varname">CXX</tt> and +optionally, <tt class="varname">CPP</tt> in <tt class="filename">/etc/mk.conf</tt>, +eg. +</p> +<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre>CC= cc +CXX= CC +CPP= /usr/ccs/lib/cpp</pre></td></tr></table> +<p> +You may also want to build 64-bit binaries, eg. +</p> +<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre>CFLAGS= -xtarget=ultra -xarch=v9</pre></td></tr></table> +</div> +<p> +Whichever compiler you use, please ensure the compiler tools and +your $prefix are in your <tt class="varname">PATH</tt>. This includes +<tt class="filename">/usr/ccs/{bin,lib}</tt> +and eg. <tt class="filename">/usr/pkg/{bin,sbin}</tt>. +</p> +</div> +</div> +</div> +<div class="chapter" lang="en"> +<div class="titlepage"> +<div><div><h2 class="title"> +<a name="using"></a>Chapter 3. Using The NetBSD package system</h2></div></div> +<div></div> +</div> +<div class="toc"> +<p><b>Table of Contents</b></p> +<dl> +<dt>3.1. <a href="#getting%20started">Working with binary packages</a> +</dt> +<dt>3.2. <a href="#id2937398">Building packages from source</a> +</dt> +</dl> +</div> +<div class="sect1" lang="en"> +<div class="titlepage"> +<div><div><h2 class="title" style="clear: both"> +<a name="getting started"></a>3.1. Working with binary packages</h2></div></div> +<div></div> +</div> +<p> +This section describes how to find, retrieve and install a precompiled +binary package that someone else already prepared for your type of machine. +</p> +<div class="sect2" lang="en"> +<div class="titlepage"> +<div><div><h3 class="title"> +<a name="id2935275"></a>3.1.1. How to get binary packages</h3></div></div> +<div></div> +</div> +<p> +Precompiled packages are stored on ftp.NetBSD.org and its mirrors in the +directory <tt class="filename">/pub/NetBSD/packages</tt> for anonymous FTP access. +Please pick the right +subdirectory there as indicated by <b class="command">uname -p</b>. In that +directory, there is a subdirectory for each category plus a subdirectory +<tt class="filename">All</tt> which includes +the actual binaries in <tt class="filename">.tgz</tt> files. The category +subdirectories use symbolic +links to those files (this is the same directory layout as in +<tt class="filename">/usr/pkgsrc/packages</tt>). +</p> +<p> +This same directory layout applies for CDROM distributions, only that the +directory may be rooted somewhere else, probably somewhere below +<tt class="filename">/cdrom</tt>. Please consult your CDROMs documentation for +the exact location. +</p> +</div> +<div class="sect2" lang="en"> +<div class="titlepage"> +<div><div><h3 class="title"> +<a name="id2935328"></a>3.1.2. Installing binary packages</h3></div></div> +<div></div> +</div> +<p> +If you have the files on a CDROM or downloaded them to your hard disk, you +can install them with the following command (be sure to +<b class="command">su</b> to root first): +</p> +<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre><tt class="prompt">#</tt> <b class="userinput"><tt>pkg_add /path/to/package.tgz</tt></b></pre></td></tr></table> +<p> +If you have FTP access and you don't want to download the packages via FTP +prior to installation, you can do this automatically by giving +<b class="command">pkg_add</b> an FTP URL: +</p> +<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre><tt class="prompt">#</tt> <b class="userinput"><tt>pkg_add ftp://ftp.NetBSD.org/pub/NetBSD/packages/<OS Ver>/<arch>/All/package.tgz</tt></b></pre></td></tr></table> +<p> +If there is any doubt, the uname utility can be used to determine the +<OS Ver>, and <arch> by running <b class="command">uname -rp</b>. +</p> +<p> +Also note that any prerequisite packages needed to run the package in +question will be installed, too, assuming they are present where you install +from. +</p> +<p> +After you've installed packages, be sure to have +<tt class="filename">/usr/pkg/bin</tt> in your <tt class="varname">PATH</tt> +so you can actually start the just installed program. +</p> +</div> +<div class="sect2" lang="en"> +<div class="titlepage"> +<div><div><h3 class="title"> +<a name="id2937385"></a>3.1.3. A word of warning</h3></div></div> +<div></div> +</div> +<p> +Please pay very careful attention to the warnings expressed in that manual +page about the inherent dangers of installing binary packages which you did +not create yourself, and the security holes that can be introduced onto +your system by indiscriminate adding of such files. +</p> +</div> +</div> +<div class="sect1" lang="en"> +<div class="titlepage"> +<div><div><h2 class="title" style="clear: both"> +<a name="id2937398"></a>3.2. Building packages from source</h2></div></div> +<div></div> +</div> +<p> +This assumes that the package is already part of the NetBSD package system. +If it is not, see <a href="#developers-guide" title="Part II. pkgsrc developer's guide">Part II</a>. +</p> +<div class="sect2" lang="en"> +<div class="titlepage"> +<div><div><h3 class="title"> +<a name="id2937412"></a>3.2.1. Requirements</h3></div></div> +<div></div> +</div> +<p> +To build packages from source on a NetBSD system the +“<span class="quote">comp</span>” and the “<span class="quote">text</span>” +distribution sets must be installed. If you want to build X11 related +packages the “<span class="quote">xbase</span>” and “<span class="quote">xcomp</span>” distribution +sets are required, too. +</p> +<div class="sect3" lang="en"> +<div class="titlepage"> +<div><div><h4 class="title"> +<a name="id2937440"></a>3.2.1.1. Where to get pkgsrc</h4></div></div> +<div></div> +</div> +<p> +There are three ways to get pkgsrc. Either as a tar file, via SUP, or +via CVS. All three ways are described here. +</p> +<p> +To get the package source going, you need to get the pkgsrc.tar.gz file +from <a href="ftp://ftp.NetBSD.org/pub/NetBSD-current/tar_files/pkgsrc.tar.gz" target="_top">ftp.NetBSD.org</a> and unpack it into <tt class="filename">/usr/pkgsrc</tt>. +</p> +<p> +As an alternative, you can get pkgsrc via the Software Update Protocol, +SUP. To do so, make sure your supfile has a line + +</p> +<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre>release=pkgsrc</pre></td></tr></table> +<p> + +in it, see the examples in +<tt class="filename">/usr/share/examples/supfiles</tt>, and that the +<tt class="filename">/usr/pkgsrc</tt> directory exists. Then, simply run +<b class="command">sup -v /path/to/your/supfile</b>. +</p> +<p> +To get pkgsrc via CVS, make sure you have cvs installed. If not present on +your system, it can be found as precompiled binary on ftp.NetBSD.org. +To do an initial (full) checkout of pkgsrc, do the following steps: +</p> +<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre><tt class="prompt">%</tt> <b class="userinput"><tt>setenv CVSROOT anoncvs@anoncvs.NetBSD.org:/cvsroot</tt></b> +<tt class="prompt">%</tt> <b class="userinput"><tt>setenv CVS_RSH ssh</tt></b> +<tt class="prompt">%</tt> <b class="userinput"><tt>cd /usr</tt></b> +<tt class="prompt">%</tt> <b class="userinput"><tt>cvs checkout -P pkgsrc</tt></b></pre></td></tr></table> +<p> +This will create the <tt class="filename">pkgsrc</tt> directory in your +<tt class="filename">/usr</tt>, and all the package source will be stored +under <tt class="filename">/usr/pkgsrc</tt>. To update pkgsrc +after the initial checkout, make sure you have +<tt class="varname">CVS_RSH</tt> set as above, then do: +</p> +<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre><tt class="prompt">%</tt> <b class="userinput"><tt>cd /usr/pkgsrc</tt></b> +<tt class="prompt">%</tt> <b class="userinput"><tt>cvs -q update -dP</tt></b></pre></td></tr></table> +<p> +Please also note that it is possible to have multiple copies of the +pkgsrc hierarchy in use at any one time - all work is done relatively +within the pkgsrc tree. +</p> +</div> +<div class="sect3" lang="en"> +<div class="titlepage"> +<div><div><h4 class="title"> +<a name="id2937693"></a>3.2.1.2. Fetching distfiles</h4></div></div> +<div></div> +</div> +<p> +There is one gotcha: The distribution file (i.e. the unmodified source) +must exist on your system for the packages system to be able to build it. +If it does not, then <b class="command">ftp</b> is used to fetch the +distribution files automatically. +</p> +<p> +You can overwrite some of the major distribution sites to fit to sites +that are close to your own. Have a look at +<tt class="filename">pkgsrc/mk/bsd.pkg.defaults.mk</tt> to find some examples +- in particular, look for the <tt class="varname">MASTER_SORT</tt>, +<tt class="varname">MASTER_SORT_REGEX</tt> and +<tt class="varname">INET_COUNTRY</tt> definitions. This may save some of your +bandwidth and time. +</p> +<p> +You can change these settings either in your shell's environment, or, +if you want to keep the settings, by editing the +<tt class="filename">/etc/mk.conf</tt> file, +and adding the definitions there. +</p> +<p> +If you don't have a permanent Internet connection and you want to know +which files to download, <b class="command">make fetch-list</b> will tell you +what you'll need. Put these distfiles into +<tt class="filename">/usr/pkgsrc/distfiles</tt>. +</p> +</div> +<div class="sect3" lang="en"> +<div class="titlepage"> +<div><div><h4 class="title"> +<a name="id2937763"></a>3.2.1.3. How to build and install</h4></div></div> +<div></div> +</div> +<p> +Once the distfile(s) have been fetched, building a package is as +simple as changing into the package directory and running make: + +</p> +<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre><tt class="prompt">%</tt> <b class="userinput"><tt>cd editors/vim</tt></b> +<tt class="prompt">%</tt> <b class="userinput"><tt>make</tt></b></pre></td></tr></table> +<p> +</p> +<p> +Installing the package on your system requires you to be root. +However, pkgsrc has a <span class="emphasis"><em>just-in-time</em></span> su feature, +which allows you to only become root for the actual installation step. +e.g. + +</p> +<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre><tt class="prompt">%</tt> <b class="userinput"><tt>make install</tt></b> +===> Installing for top-3.5beta5 +===> Becoming root@mofo to install top-3.5beta5. +/usr/bin/su Password: <b class="userinput"><tt><password></tt></b> +[...installation continues...]</pre></td></tr></table> +<p> +</p> +<p> +Taking the top system utility as an example, we can install it on our +system by building as shown in <a href="#logs" title="Appendix A. Build logs">Appendix A, <i>Build logs</i></a>. +</p> +<p> +The program is installed under the default root of the packages tree - +<tt class="filename">/usr/pkg</tt>. Should this not conform to your tastes, +simply set the <tt class="varname">LOCALBASE</tt> +variable in your environment, and it will use that value as the root of +your packages tree. So, to use <tt class="filename">/usr/local</tt>, set +<tt class="varname">LOCALBASE=/usr/local</tt> in your environment. Please note +that you should use a root which is +dedicated to packages and not shared with other programs (ie, do not try +and use <tt class="varname">LOCALBASE=/usr</tt>). Also, you should not try to +add any of your own files or directories (such as <tt class="filename">src/</tt>, +<tt class="filename">obj/</tt>, or <tt class="filename">pkgsrc/</tt>) below the +<tt class="varname">LOCALBASE</tt> tree. This is to prevent possible conflicts +between programs and other files installed by the package system and +whatever else may have been installed there. +</p> +<p> +There is, of course, one exception to this - X11 packages are traditionally +installed in the X11 tree. The definition used to identify the root of the +X11 tree is the <tt class="varname">X11BASE</tt> definition. +</p> +<p> +It is possible to install X11 packages in the +<tt class="varname">LOCALBASE</tt> tree, for which you must install the +<a xmlns:html="http://www.w3.org/1999/xhtml" href="ftp://ftp.netbsd.org/pub/NetBSD/packages/pkgsrc/pkgtools/xpkgwedge/README.html" class="pkgname">pkgtools/xpkgwedge</a> package - see <a href="#build.prefix" title="8.1. Program location">Section 8.1, “Program location”</a> for further details. +</p> +<p> +Some packages look in <tt class="filename">/etc/mk.conf</tt> to alter some +configuration options at build time. Have a look at +<tt class="filename">pkgsrc/mk/bsd.pkg.defaults.mk</tt> to +get an overview of what will be set there by default. Environment +variables such as <tt class="varname">LOCALBASE</tt>, and +<tt class="varname">X11BASE</tt> can be set in <tt class="filename">/etc/mk.conf</tt> to +save having to remember to set them each time you want to use pkgsrc. +</p> +<p> +Occasionally, people want to “<span class="quote">look under the covers</span>” to see +what is going on when a package is building or being installed. This may be +for debugging purposes, or out of simple curiosity. A number of utility +values have been added to help with this. +</p> +<div class="orderedlist"><ol type="1"> +<li> +<p> +If you invoke the make(1) command with <tt class="varname">PKG_DEBUG_LEVEL=2</tt>, +then a huge amount of information will be displayed. For example, +</p> +<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre><tt class="prompt">%</tt> <b class="userinput"><tt>make patch PKG_DEBUG_LEVEL=2</tt></b></pre></td></tr></table> +<p> +will show all the commands that are invoked, up to and including the +“<span class="quote">patch</span>” stage. +</p> +</li> +<li> +<p> +If you want to know the value of a certain make(1) definition, then +the <tt class="varname">VARNAME</tt> definition should be used, in conjunction +with the show-var target. e.g. +</p> +<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre><tt class="prompt">%</tt> <b class="userinput"><tt>make show-var VARNAME=DISTFILES</tt></b></pre></td></tr></table> +<p> +will show the expansion of the make(1) variable +<tt class="varname">DISTFILES</tt>. +</p> +</li> +</ol></div> +<p> +If you want to de-install and re-install a binary package that you've +created (see next section), that you put into pkgsrc/packages manually or +that's located on a remote FTP server, you can use the the "bin-install" +target. This target will install a binary package - if available - via +<b class="command">pkg_add</b>, else do a <b class="command">make package</b>. +The list of remote +FTP sites searched is kept in the variable +<tt class="varname">BINPKG_SITE</tt>, which defaults to +ftp.NetBSD.org. Any flags that should be added to pkg_add(8) can be put +into <tt class="varname">BIN_INSTALL_FLAGS</tt>. See <tt class="filename">pkgsrc/mk/bsd.pkg.defaults.mk</tt> for more details. +</p> +<p> +A final word of warning: If you setup a system that has a non-standard +setting for <tt class="varname">LOCALBASE</tt> (or +<tt class="varname">X11BASE</tt>, for that matter), be sure to set that +before any packages are installed, as you can not use several directories +for the same purpose. Doing so will result in pkgsrc not being able to +properly detect your installed packages, and fail miserably. Note also that +precompiled binary packages are usually built with the default +<tt class="varname">LOCALBASE</tt> of +<tt class="filename">/usr/pkg</tt>, and that you should <span class="emphasis"><em>not</em></span> +install any if you use a non-standard <tt class="varname">LOCALBASE</tt>. +</p> +</div> +</div> +</div> +</div> +<div class="chapter" lang="en"> +<div class="titlepage"> +<div><div><h2 class="title"> +<a name="binary"></a>Chapter 4. Creating binary packages</h2></div></div> +<div></div> +</div> +<div class="toc"> +<p><b>Table of Contents</b></p> +<dl> +<dt>4.1. <a href="#id2936710">Building a single binary package</a> +</dt> +<dt>4.2. <a href="#id2939394">Settings for creation of binary packages</a> +</dt> +<dt>4.3. <a href="#id2939411">Doing a bulk build of all packages</a> +</dt> +<dt>4.4. <a href="#id2940945">Creating a multiple CD-ROM packages collection</a> +</dt> +</dl> +</div> +<div class="sect1" lang="en"> +<div class="titlepage"> +<div><div><h2 class="title" style="clear: both"> +<a name="id2936710"></a>4.1. Building a single binary package</h2></div></div> +<div></div> +</div> +<p> + Once you have built and installed a package, you can create a + <span class="emphasis"><em>binary package</em></span> which can be installed on another + system with pkg_add(1). This saves having to build the same package on + a group of hosts and wasting CPU time. It also provides a simple means + for others to install your package, should you distribute it. +</p> +<p> + Create a binary package: +</p> +<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre><tt class="prompt">#</tt> <b class="userinput"><tt>cd sysutils/top</tt></b> +<tt class="prompt">#</tt> <b class="userinput"><tt>make package</tt></b></pre></td></tr></table> +<p> + This will build and install your package (if not already done), and then + build a binary package from what was installed. You can then use the + <b class="command">pkg_*</b> tools to manipulate it. Binary packages are + created by default in <tt class="filename">/usr/pkgsrc/packages</tt>, in the + form of a gzip or bzip2 tar file. See <a href="#logs.package" title="A.2. Packaging top">Section A.2, “Packaging top”</a> for + a continuation of the above <a xmlns:html="http://www.w3.org/1999/xhtml" href="ftp://ftp.netbsd.org/pub/NetBSD/packages/pkgsrc/sysutils/top/README.html" class="pkgname">sysutils/top</a> example. +</p> +<p> + See <a href="#submit" title="Chapter 12. Submitting and Committing">Chapter 12, <i>Submitting and Committing</i></a> for information on how to submit such a + binary package. +</p> +</div> +<div class="sect1" lang="en"> +<div class="titlepage"> +<div><div><h2 class="title" style="clear: both"> +<a name="id2939394"></a>4.2. Settings for creation of binary packages</h2></div></div> +<div></div> +</div> +<p> + See <a href="#build.helpful-targets" title="8.3. Other helpful targets">Section 8.3, “Other helpful targets”</a>. +</p> +</div> +<div class="sect1" lang="en"> +<div class="titlepage"> +<div><div><h2 class="title" style="clear: both"> +<a name="id2939411"></a>4.3. Doing a bulk build of all packages</h2></div></div> +<div></div> +</div> +<p> + If you want to get a full set of precompiled binary packages, this section + describes how to get them. Beware that the bulk build will remove all + currently installed packages from your your system! Having a FTP server + configured either on the machine doing the bulk builds or on a nearby NFS + server can help to make the packages available to everyone. See ftpd(8) for + more information. If you use a remote NFS server's storage, be sure to not + actually compile on NFS storage, as this slows things down a lot. +</p> +<div class="sect2" lang="en"> +<div class="titlepage"> +<div><div><h3 class="title"> +<a name="id2939422"></a>4.3.1. Configuration</h3></div></div> +<div></div> +</div> +<div class="sect3" lang="en"> +<div class="titlepage"> +<div><div><h4 class="title"> +<a name="binary.mk.conf"></a>4.3.1.1. /etc/mk.conf</h4></div></div> +<div></div> +</div> +<p> + You may want to set things in <tt class="filename">/etc/mk.conf</tt>. + Look at <tt class="filename">pkgsrc/mk/bsd.pkg.defaults.mk</tt> for + details of the default settings. You will want to ensure that + <tt class="varname">ACCEPTABLE_LICENSES</tt> meet your local policy. + As used in this example, <tt class="varname">_ACCEPTABLE=yes</tt> + accepts <span class="emphasis"><em>all</em></span> licenses. +</p> +<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre>PACKAGES?= ${_PKGSRCDIR}/packages/${MACHINE_ARCH} +WRKOBJDIR?= /usr/tmp/pkgsrc # build here instead of in pkgsrc +BSDSRCDIR= /usr/src +BSDXSRCDIR= /usr/xsrc # for x11/xservers +OBJHOSTNAME?= yes # use work.`hostname` +FAILOVER_FETCH= yes # insist on the correct checksum +PKG_DEVELOPER?= yes +_ACCEPTABLE= yes</pre></td></tr></table> +<p> + If you wish to use xpkgwedge for the entire build, then add: +</p> +<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre>BULK_PREREQ+= pkgtools/xpkgwedge</pre></td></tr></table> +<p> + Other packages which must be installed during the bulk build to modify the + build behaviour may be added to the <tt class="varname">BULK_PREREQ</tt> variable. + Note that currently the only package for which + <tt class="varname">BULK_PREREQ</tt> makes sense is xpkgwedge. +</p> +</div> +<div class="sect3" lang="en"> +<div class="titlepage"> +<div><div><h4 class="title"> +<a name="id2939736"></a>4.3.1.2. build.conf</h4></div></div> +<div></div> +</div> +<p> + In <tt class="filename">pkgsrc/mk/bulk</tt>, copy + “<span class="quote">build.conf-example</span>” to “<span class="quote">build.conf</span>” and + edit it, following the comments in that file. This is the config + file that determines where log files are generated after the build, + where to mail the build report, where your pkgsrc is located and + which user to su(8) to do a <b class="command">cvs update</b>. +</p> +</div> +<div class="sect3" lang="en"> +<div class="titlepage"> +<div><div><h4 class="title"> +<a name="id2939767"></a>4.3.1.3. pre-build.local</h4></div></div> +<div></div> +</div> +<p> + It is possible to configure the bulk build to perform certain site + specific tasks at the end of the pre-build stage. If the file + <tt class="filename">pre-build.local</tt> exists in + <tt class="filename">/usr/pkgsrc/mk/bulk</tt> it will be executed + (as a sh(1) script) at the end of the usual pre-build stage. An + example use of <tt class="filename">pre-build.local</tt> is to have the + line: +</p> +<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre><tt class="prompt">#</tt> <b class="userinput"><tt>echo "I do not have enough disk space to build this pig." \ + > pkgsrc/games/crafty-book-enormous/$BROKENF</tt></b></pre></td></tr></table> +<p> + to prevent the system from trying to build a particular package + which requires nearly 3 Gb of disk space. +</p> +</div> +</div> +<div class="sect2" lang="en"> +<div class="titlepage"> +<div><div><h3 class="title"> +<a name="id2939817"></a>4.3.2. Other environmental considerations</h3></div></div> +<div></div> +</div> +<p> + As <tt class="filename">/usr/pkg</tt> will be completely deleted at the + start of bulk builds, make sure your login shell is placed somewhere + else. Either drop it into <tt class="filename">/usr/local/bin</tt> + (and adjust your login shell in the password file), or (re-)install + it via <b class="command">pkg_add</b> from + <tt class="filename">/etc/rc.local</tt>, so you can login after a reboot + (remember that your current process won't die if the package is + removed, you just can't start any new instances of the shell any more). + Also, if you use NetBSD earlier than 1.5, or you still want to use the + pkgsrc version of ssh for some reason, be sure to install ssh before + starting it from rc.local: +</p> +<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre>( cd /usr/pkgsrc/security/ssh ; make bulk-install ) +if [ -f /usr/pkg/etc/rc.d/sshd ]; then + /usr/pkg/etc/rc.d/sshd +fi</pre></td></tr></table> +<p> + Not doing so will result in you being not able to log in via ssh + after the bulk build is finished or if the machine gets rebooted + or crashes. You have been warned! :) +</p> +</div> +<div class="sect2" lang="en"> +<div class="titlepage"> +<div><div><h3 class="title"> +<a name="id2939943"></a>4.3.3. Operation</h3></div></div> +<div></div> +</div> +<p> + Make sure you don't need any of the packages still installed. + </p> +<div class="warning" style="margin-left: 0.5in; margin-right: 0.5in;"> +<h3 class="title">Warning</h3> + During the bulk build, <span class="emphasis"><em>all packages will be + removed!</em></span> +</div> +<p> + Be sure to remove all other things that might + interfere with builds, like some libs installed in + <tt class="filename">/usr/local</tt>, etc. then become root and type: +</p> +<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre><tt class="prompt">#</tt> <b class="userinput"><tt>cd /usr/pkgsrc</tt></b> +<tt class="prompt">#</tt> <b class="userinput"><tt>sh mk/bulk/build</tt></b></pre></td></tr></table> +<p> + If for some reason your last build didn't complete (power failure, + system panic, ...), you can continue it by running: +</p> +<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre><tt class="prompt">#</tt> <b class="userinput"><tt>sh mk/bulk/build restart</tt></b></pre></td></tr></table> +<p> + At the end of the bulk run, you will get a summary via mail, and find + build logs in the directory specified by <tt class="varname">FTP</tt> in the + <tt class="filename">build.conf</tt> file. +</p> +</div> +<div class="sect2" lang="en"> +<div class="titlepage"> +<div><div><h3 class="title"> +<a name="id2940032"></a>4.3.4. What it does</h3></div></div> +<div></div> +</div> +<p> + The bulk builds consist of three steps: +</p> +<div class="orderedlist"><ol type="1"> +<li>pre-build +<p> + The script updates your pkgsrc via (anon)cvs, then cleans + out any broken distfiles, and removes all packages installed. +</p> +</li> +<li>the bulk build +<p> + This is basically “<span class="quote">make bulk-package</span>” with an optimised + order in which packages will be built. Packages that don't require + other packages will be built first, and packages with many depends + will be built later. +</p> +</li> +<li>post-build +<p> + Generates a report that's placed in the directory specified + in the <tt class="filename">build.conf</tt> file named + <tt class="filename">broken.html</tt>, a short version of + that report will also be mailed to the build's admin. +</p> +</li> +</ol></div> +<p> + During the build, a list of broken packages will be compiled in + <tt class="filename">/usr/pkgsrc/.broken</tt> (or + <tt class="filename">.../.broken.${MACHINE}</tt> if + <tt class="varname">OBJMACHINE</tt> is set), + individual build logs of broken builds can be found in the package's + directory. These files are used by the bulk-targets to mark broken builds + to not waste time trying to rebuild them, and they can be used to debug + these broken package builds later. +</p> +</div> +<div class="sect2" lang="en"> +<div class="titlepage"> +<div><div><h3 class="title"> +<a name="id2940189"></a>4.3.5. Disk space requirements</h3></div></div> +<div></div> +</div> +<p> + Currently, roughly the following requirements are valid for + 1.5/i386: +</p> +<div class="itemizedlist"><ul type="disc"> +<li>1500MB - distfiles (NFS ok)</li> +<li>1000MB - full set of all binaries (NFS ok)</li> +<li>1500MB - temp space for compiling (local disk recommended)</li> +</ul></div> +<p> + For 1.5/alpha: +</p> +<div class="itemizedlist"><ul type="disc"><li>1300MB - full set of all binaries (NFS ok)</li></ul></div> +<p> + Note that all pkgs will be de-installed as soon as they are turned into a + binary package, and that work-sources are removed, so there is no huge + demand to disk space. Afterwards, if the package is needed again, it will + be installed via “<span class="quote">pkg_add</span>” instead of building again, so + there are no cycles wasted by recompiling. +</p> +</div> +<div class="sect2" lang="en"> +<div class="titlepage"> +<div><div><h3 class="title"> +<a name="id2940316"></a>4.3.6. Setting up a sandbox for chroot'ed builds</h3></div></div> +<div></div> +</div> +<p> + If you don't want all the pkgs nuked from a machine (rendering it useless + for anything but pkg compiling), there is the possibility of doing the pkg + bulk build inside a chroot environment. +</p> +<p> + The first step to do so is setting up a chroot sandbox, e.g. <tt class="filename">/usr/sandbox</tt>. + After extracting all the sets from a NetBSD installation or doing a + <b class="command">make distribution DESTDIR=/usr/sandbox</b> in + <tt class="filename">/usr/src/etc</tt>, be sure the following + items are present and properly configured: +</p> +<div class="itemizedlist"><ul type="disc"> +<li> +kernel +<p> +</p> +<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre><tt class="prompt">#</tt> <b class="userinput"><tt>cp /netbsd /usr/sandbox</tt></b></pre></td></tr></table> +<p> +</p> +</li> +<li> +<tt class="filename">/dev/*</tt><p> +</p> +<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre><tt class="prompt">#</tt> <b class="userinput"><tt>cd /usr/sandbox/dev ; sh MAKEDEV all</tt></b></pre></td></tr></table> +<p> +</p> +</li> +<li> +<tt class="filename">/etc/resolv.conf</tt> (for <a xmlns:html="http://www.w3.org/1999/xhtml" href="ftp://ftp.netbsd.org/pub/NetBSD/packages/pkgsrc/security/smtpd/README.html" class="pkgname">security/smtpd</a> and mail): +<p> +</p> +<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre><tt class="prompt">#</tt> <b class="userinput"><tt>cp /etc/resolv.conf /usr/sandbox/etc</tt></b></pre></td></tr></table> +<p> +</p> +</li> +<li> +working(!) mail config (hostname, sendmail.cf): +<p> +</p> +<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre><tt class="prompt">#</tt> <b class="userinput"><tt>cp /etc/mail/sendmail.cf /usr/sandbox/etc/mail</tt></b></pre></td></tr></table> +<p> +</p> +</li> +<li> +<tt class="filename">/etc/localtime</tt> (for <a xmlns:html="http://www.w3.org/1999/xhtml" href="ftp://ftp.netbsd.org/pub/NetBSD/packages/pkgsrc/security/smtpd/README.html" class="pkgname">security/smtpd</a>): +<p> +</p> +<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre><tt class="prompt">#</tt> <b class="userinput"><tt>ln -sf /usr/share/zoneinfo/GMT /usr/sandbox/etc/localtime</tt></b></pre></td></tr></table> +<p> +</p> +</li> +<li> +<tt class="filename">/usr/src</tt> (system sources, for <a xmlns:html="http://www.w3.org/1999/xhtml" href="ftp://ftp.netbsd.org/pub/NetBSD/packages/pkgsrc/sysutils/aperture/README.html" class="pkgname">sysutils/aperture</a>, +<a xmlns:html="http://www.w3.org/1999/xhtml" href="ftp://ftp.netbsd.org/pub/NetBSD/packages/pkgsrc/net/ppp-mppe/README.html" class="pkgname">net/ppp-mppe</a>): +<p> +</p> +<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre><tt class="prompt">#</tt> <b class="userinput"><tt>ln -s ../disk1/cvs .</tt></b> +<tt class="prompt">#</tt> <b class="userinput"><tt>ln -s cvs/src-1.6 src</tt></b> +<tt class="prompt">#</tt> <b class="userinput"><tt>ln -s cvs/pkgsrc .</tt></b></pre></td></tr></table> +<p> +</p> +</li> +<li> +create <tt class="filename">/var/db/pkg</tt> (not part of default install): +<p> +</p> +<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre><tt class="prompt">#</tt> <b class="userinput"><tt>mkdir /usr/sandbox/var/db/pkg</tt></b></pre></td></tr></table> +<p> +</p> +</li> +<li> +create <tt class="filename">/usr/pkg</tt> (not part of default install): +<p> +</p> +<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre><tt class="prompt">#</tt> <b class="userinput"><tt>mkdir /usr/sandbox/usr/pkg</tt></b></pre></td></tr></table> +<p> +</p> +</li> +<li> +checkout pkgsrc into +<tt class="filename">/usr/sandbox/usr/pkgsrc</tt>: +<p> +</p> +<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre><tt class="prompt">#</tt> <b class="userinput"><tt>cd /usr/sandbox/usr</tt></b> +<tt class="prompt">#</tt> <b class="userinput"><tt>cvs -d anoncvs@anoncvs.NetBSD.org:/cvsroot checkout -d -P pkgsrc</tt></b></pre></td></tr></table> +<p> +</p> +</li> +<li> +edit <tt class="filename">/etc/mk.conf</tt>, see <a href="#binary.mk.conf" title="4.3.1.1. /etc/mk.conf">Section 4.3.1.1, “/etc/mk.conf”</a>. +</li> +<li> +adjust <tt class="filename">mk/bulk/build.conf</tt> to suit your needs. +</li> +</ul></div> +<div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"> +<h3 class="title">Note</h3> + Don't forget to install X. +</div> +<p> + If you are a developer and want to upload the resulting binary packages + to ftp.NetBSD.org, be sure you are using the default X version for your + architecture and release (that is XFree86 3.3.6 for 1.5.x, and XFree86 + 4.2.1 for NetBSD 1.6.1 on <a href="../../Ports/cats/" target="_top">cats</a>, + <a href="../../Ports/i386/" target="_top">i386</a> and <a href="../../Ports/macppc/" target="_top">macppc</a> ports, 3.3.6 on all other + ports). +</p> +<p> + The next thing you need is a <span class="emphasis"><em>fresh checkout of pkgsrc</em></span> + (e.g. from anoncvs). Do not mount/link this to the copy of your pkgsrc tree + you do development in, as this will likely cause problems! Adjust + <tt class="filename">.../pkgsrc/packages</tt> and + <tt class="filename">.../pkgsrc/distfiles</tt> to point to some places + outside the sandbox if you want to make the files public. +</p> +<p> + When the chroot sandbox is setup, you can start the build with the following + steps: +</p> +<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre><tt class="prompt">#</tt> <b class="userinput"><tt>cd /usr/sandbox/usr/pkgsrc</tt></b> +<tt class="prompt">#</tt> <b class="userinput"><tt>sh mk/bulk/do-sandbox-build</tt></b></pre></td></tr></table> +<p> + This will just jump inside the sandbox and start building. + At the end of the build, mail will be sent with the results of the build. + Created binary pkgs will be in + <tt class="filename">/usr/sandbox/usr/pkgsrc/packages</tt> (wherever + that points/mounts to/from). +</p> +</div> +</div> +<div class="sect1" lang="en"> +<div class="titlepage"> +<div><div><h2 class="title" style="clear: both"> +<a name="id2940945"></a>4.4. Creating a multiple CD-ROM packages collection</h2></div></div> +<div></div> +</div> +<p> + After your bulk pkgsrc build has completed, you may wish to create a CD-ROM + set of the resulting binary packages to assist in installing packages on + other machines. The <a xmlns:html="http://www.w3.org/1999/xhtml" href="ftp://ftp.netbsd.org/pub/NetBSD/packages/pkgsrc/pkgtools/cdpack/README.html" class="pkgname">pkgtools/cdpack</a> package provides a simple + tool for creating the ISO 9660 images. <b class="command">cdpack</b> arranges + the packages on the CD-ROMs in a way that keeps all the dependencies for + given package on the same CD as that package. +</p> +<div class="sect2" lang="en"> +<div class="titlepage"> +<div><div><h3 class="title"> +<a name="id2940966"></a>4.4.1. Example of cdpack</h3></div></div> +<div></div> +</div> +<p> + Complete documentation for cdpack is found in cdpack(1). The following + short example assumes that the binary packages are left in + <tt class="filename">/usr/pkgsrc/packages/All</tt> and that sufficient disk + space exists in <tt class="filename">/u2</tt> to hold the ISO 9660 images. +</p> +<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre><tt class="prompt">#</tt> <b class="userinput"><tt>mkdir /u2/images</tt></b> +<tt class="prompt">#</tt> <b class="userinput"><tt>pkg_add /usr/pkgsrc/packages/All/cdpack</tt></b> +<tt class="prompt">#</tt> <b class="userinput"><tt>cdpack /usr/pkgsrc/packages/All /u2/images</tt></b></pre></td></tr></table> +<p> + If you wish to include a common set of files + (<tt class="filename">COPYRIGHT</tt>, <tt class="filename">README</tt>, etc.) + on each CD in the collection, then you need to create a directory which + contains these files. e.g. +</p> +<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre><tt class="prompt">#</tt> <b class="userinput"><tt>mkdir /tmp/common</tt></b> +<tt class="prompt">#</tt> <b class="userinput"><tt>echo "This is a README" > /tmp/common/README</tt></b> +<tt class="prompt">#</tt> <b class="userinput"><tt>echo "Another file" > /tmp/common/COPYING</tt></b> +<tt class="prompt">#</tt> <b class="userinput"><tt>mkdir /tmp/common/bin</tt></b> +<tt class="prompt">#</tt> <b class="userinput"><tt>echo "#!/bin/sh" > /tmp/common/bin/myscript</tt></b> +<tt class="prompt">#</tt> <b class="userinput"><tt>echo "echo Hello world" >> /tmp/common/bin/myscript</tt></b> +<tt class="prompt">#</tt> <b class="userinput"><tt>chmod 755 /tmp/common/bin/myscript</tt></b></pre></td></tr></table> +<p> + Now create the images: +</p> +<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre><tt class="prompt">#</tt> <b class="userinput"><tt>cdpack -x /tmp/common /usr/pkgsrc/packages/All /u2/images</tt></b></pre></td></tr></table> +<p> + Each image will contain <tt class="filename">README</tt>, + <tt class="filename">COPYING</tt>, and <tt class="filename">bin/myscript</tt> + in their root directories. +</p> +</div> +</div> +</div> +</div> +<div class="part" lang="en"> +<div class="titlepage"> +<div><div><h1 class="title"> +<a name="developers-guide"></a>pkgsrc developer's guide</h1></div></div> +<div></div> +</div> +<div class="toc"> +<p><b>Table of Contents</b></p> +<dl> +<dt>5. <a href="#components">Package components - files, directories and contents</a> +</dt> +<dd><dl> +<dt>5.1. <a href="#components.Makefile">Makefile</a> +</dt> +<dt>5.2. <a href="#components.distinfo">distinfo</a> +</dt> +<dt>5.3. <a href="#components.patches">patches/*</a> +</dt> +<dt>5.4. <a href="#id2943680">Other mandatory files</a> +</dt> +<dt>5.5. <a href="#id2943718">Optional files</a> +</dt> +<dt>5.6. <a href="#id2943959">work*</a> +</dt> +<dt>5.7. <a href="#id2943990">files/*</a> +</dt> +<dt>5.8. <a href="#id2944093">Portability of packages</a> +</dt> +</dl></dd> +<dt>6. <a href="#plist">PLIST issues</a> +</dt> +<dd><dl> +<dt>6.1. <a href="#plist.misc">Miscellaneous</a> +</dt> +<dt>6.2. <a href="#id2945543">PLIST_SRC</a> +</dt> +<dt>6.3. <a href="#id2945566">PLIST_SUBST</a> +</dt> +<dt>6.4. <a href="#id2945697">Perl5 modules</a> +</dt> +<dt>6.5. <a href="#id2945836">User Interaction</a> +</dt> +</dl></dd> +<dt>7. <a href="#fixes">Notes on fixes for packages</a> +</dt> +<dd><dl> +<dt>7.1. <a href="#id2944290">CPP defines</a> +</dt> +<dt>7.2. <a href="#fixes.libtool">Shared libraries - libtool</a> +</dt> +<dt>7.3. <a href="#id2947315">Using libtool on GNU packages that already support libtool</a> +</dt> +<dt>7.4. <a href="#id2947414">GNU Autoconf/Automake</a> +</dt> +<dt>7.5. <a href="#id2947454">Package configuration files</a> +</dt> +<dt>7.6. <a href="#id2947668">Feedback to the author</a> +</dt> +</dl></dd> +<dt>8. <a href="#build">The build process</a> +</dt> +<dd><dl> +<dt>8.1. <a href="#build.prefix">Program location</a> +</dt> +<dt>8.2. <a href="#id2949108">Main targets</a> +</dt> +<dt>8.3. <a href="#build.helpful-targets">Other helpful targets</a> +</dt> +</dl></dd> +<dt>9. <a href="#buildlink2">buildlink2 methodology</a> +</dt> +<dd><dl> +<dt>9.1. <a href="#id2953172">Converting packages to use buildlink2</a> +</dt> +<dt>9.2. <a href="#id2953308">Writing buildlink2.mk files</a> +</dt> +</dl></dd> +<dt>10. <a href="#debug">Debugging</a> +</dt> +<dt>11. <a href="#features">FAQs & features of the package system</a> +</dt> +<dd><dl> +<dt>11.1. <a href="#id2952494">Packages using GNU autoconf</a> +</dt> +<dt>11.2. <a href="#id2954262">Other distrib methods than .tar.gz</a> +</dt> +<dt>11.3. <a href="#id2954307">Packages not creating their own subdirectory</a> +</dt> +<dt>11.4. <a href="#id2955763">Custom configuration process</a> +</dt> +<dt>11.5. <a href="#id2955785">Packages not building in their DISTNAME directory</a> +</dt> +<dt>11.6. <a href="#id2955896">How to fetch all distfiles at once</a> +</dt> +<dt>11.7. <a href="#id2956076">How to fetch files from behind a firewall</a> +</dt> +<dt>11.8. <a href="#id2956098">If your patch contains an RCS ID</a> +</dt> +<dt>11.9. <a href="#id2956116">How to pull in variables from /etc/mk.conf</a> +</dt> +<dt>11.10. <a href="#id2956180">Is there a mailing list for pkg-related discussion?</a> +</dt> +<dt>11.11. <a href="#id2956204">How do I tell make fetch to do passive FTP?</a> +</dt> +<dt>11.12. <a href="#id2956350">Dependencies on other packages</a> +</dt> +<dt>11.13. <a href="#id2956571">Conflicts with other packages</a> +</dt> +<dt>11.14. <a href="#id2956642">Software which has a WWW Home Page</a> +</dt> +<dt>11.15. <a href="#id2956667">How to handle modified distfiles with the 'old' name</a> +</dt> +<dt>11.16. <a href="#id2956764">What does "Don't know how to make /usr/share/tmac/tmac.andoc" mean?</a> +</dt> +<dt>11.17. <a href="#id2956809">How to handle incrementing versions when fixing an existing +package</a> +</dt> +<dt>11.18. <a href="#id2956956">Could not find bsd.own.mk - what's wrong?</a> +</dt> +<dt>11.19. <a href="#id2957027">Restricted packages</a> +</dt> +<dt>11.20. <a href="#id2957213">Packages using (n)curses</a> +</dt> +<dt>11.21. <a href="#id2957255">Automated security check</a> +</dt> +<dt>11.22. <a href="#id2957425">What's the proper way to create an account from a package?</a> +</dt> +<dt>11.23. <a href="#id2957593">How to handle compiler bugs</a> +</dt> +<dt>11.24. <a href="#features.info-files">Packages providing info files</a> +</dt> +<dt>11.25. <a href="#id2957793">Packages whose distfiles aren't available for plain downloading</a> +</dt> +<dt>11.26. <a href="#id2957953">Configuration files handling and placement</a> +</dt> +<dt>11.27. <a href="#id2958470">Packages providing login shells</a> +</dt> +<dt>11.28. <a href="#id2958558">Packages providing locale catalogues</a> +</dt> +<dt>11.29. <a href="#id2958592">Using 'sudo' with pkgsrc</a> +</dt> +<dt>11.30. <a href="#id2958621">Packages containing perl scripts</a> +</dt> +<dt>11.31. <a href="#id2958648">Packages that cannot or should not be built</a> +</dt> +</dl></dd> +<dt>12. <a href="#submit">Submitting and Committing</a> +</dt> +<dd><dl> +<dt>12.1. <a href="#id2960258">Submitting your packages</a> +</dt> +<dt>12.2. <a href="#id2961824">Committing: Importing a package into CVS</a> +</dt> +<dt>12.3. <a href="#id2962087">Updating a Package to a Newer Version</a> +</dt> +<dt>12.4. <a href="#id2962208">Moving a Package in pkgsrc</a> +</dt> +</dl></dd> +<dt>13. <a href="#examples">A simple example of a package: bison</a> +</dt> +<dd><dl> +<dt>13.1. <a href="#id2961656">files</a> +</dt> +<dt>13.2. <a href="#id2963176">Steps for building, installing, packaging</a> +</dt> +</dl></dd> +</dl> +</div> +<div class="chapter" lang="en"> +<div class="titlepage"> +<div><div><h2 class="title"> +<a name="components"></a>Chapter 5. Package components - files, directories and contents</h2></div></div> +<div></div> +</div> +<div class="toc"> +<p><b>Table of Contents</b></p> +<dl> +<dt>5.1. <a href="#components.Makefile">Makefile</a> +</dt> +<dt>5.2. <a href="#components.distinfo">distinfo</a> +</dt> +<dt>5.3. <a href="#components.patches">patches/*</a> +</dt> +<dt>5.4. <a href="#id2943680">Other mandatory files</a> +</dt> +<dt>5.5. <a href="#id2943718">Optional files</a> +</dt> +<dt>5.6. <a href="#id2943959">work*</a> +</dt> +<dt>5.7. <a href="#id2943990">files/*</a> +</dt> +<dt>5.8. <a href="#id2944093">Portability of packages</a> +</dt> +</dl> +</div> +<p> + Whenever you're preparing a package, there are a number of files + involved which are described in the following sections. +</p> +<div class="sect1" lang="en"> +<div class="titlepage"> +<div><div><h2 class="title" style="clear: both"> +<a name="components.Makefile"></a>5.1. Makefile</h2></div></div> +<div></div> +</div> +<p> + Building, installation and creation of a binary package are all + controlled by the package's <tt class="filename">Makefile</tt>. +</p> +<p> + There is a Makefile for each package. This file includes the standard + <tt class="filename">bsd.pkg.mk</tt> file (referenced as + <tt class="filename">../../mk/bsd.pkg.mk</tt>), which sets all the + definitions and actions necessary for the package to compile and + install itself. The mandatory variables are the + <tt class="varname">DISTNAME</tt> which specifies the base name + of the distribution file to be downloaded from the site on the + Internet, <tt class="varname">MASTER_SITES</tt> which specifies that site, + <tt class="varname">CATEGORIES</tt> which denotes the + categories into which the package falls, <tt class="varname">PKGNAME</tt> + which is the name of the package, the <tt class="varname">MAINTAINER</tt> + name, and the <tt class="varname">COMMENT</tt> variable, which should + contain a one-line description of the package (the package name + should not appear, it will be added automatically). The maintainer + variable is there so that anyone who quibbles with the (always + completely correct) decisions taken by the guy who maintains the + port can complain vigorously. +</p> +<p> + The <tt class="varname">MASTER_SITES</tt> may be set to one of the + predefined sites: +</p> +<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre>${MASTER_SITE_XCONTRIB} +${MASTER_SITE_GNU} +${MASTER_SITE_PERL_CPAN} +${MASTER_SITE_TEX_CTAN} +${MASTER_SITE_SUNSITE} +${MASTER_SITE_GNOME} +${MASTER_SITE_SOURCEFORGE}</pre></td></tr></table> +<p> + If one of these predefined sites is chosen, you may require the + ability to specify a subdirectory of that site. Since these macros + may expand to more than one actual site, you + <span class="emphasis"><em>must</em></span> use the following construct to specify a + subdirectory: +</p> +<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre>${MASTER_SITE_GNU:=subdirectory/name/}</pre></td></tr></table> +<p> + Note the trailing slash after the subdirectory name. +</p> +<div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"> +<h3 class="title">Note</h3> +<tt class="varname">MASTER_SITE_SUBDIR</tt> has been deprecated and + <span class="emphasis"><em>should no longer be used</em></span>. +</div> +<p> + If the package has multiple <tt class="varname">DISTFILES</tt> or multiple + <tt class="varname">PATCHFILES</tt> from different + sites, set <tt class="varname">SITES_foo</tt> to a list of URI's where file + “<span class="quote">foo</span>” may be found. “<span class="quote">foo</span>” + includes the suffix, e.g. +</p> +<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre>DISTFILES= ${DISTNAME}${EXTRACT_SUFX} +DISTFILES+= foo-file.tar.gz +SITES_foo-file.tar.gz=http://www.somewhere.com/somehow/ \ + http://www.somewhereelse.com/mirror/somehow/</pre></td></tr></table> +<p> + Note that the normal default setting of <tt class="varname">DISTFILES</tt> + must be made explicit if you want to add to it (rather than replace + it), as you usually would. +</p> +<p> + Currently the following values are available for + <tt class="varname">CATEGORIES</tt>. If more than + one is used, they need to be separated by spaces: +</p> +<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre>archivers audio benchmarks biology cad +chat comms converters cross databases +devel editors emulators finance fonts +games graphics ham japanese lang +mail math mbone misc net +news parallel print security shells +sysutils textproc time wm www +x11</pre></td></tr></table> +<p> + Please pay attention to the following gotchas: +</p> +<div class="itemizedlist"><ul type="disc"> +<li><p> + Add <tt class="varname">MANCOMPRESSED</tt> if manpages are installed in + compressed form by the package; see comment in bsd.pkg.mk. +</p></li> +<li><p> + Replace <tt class="filename">/usr/local</tt> with + “<span class="quote">${PREFIX}</span>” in all files (see patches, below). +</p></li> +<li><p> + If the package installs any info files, see + <a href="#features.info-files" title="11.24. Packages providing info files">Section 11.24, “Packages providing info files”</a>. +</p></li> +<li><p> + Adjust <tt class="varname">MAINTAINER</tt> to be either yourself, if you plan + to maintain the package for future updates, or set it to the default + maintainer <tt class="email"><<a href="mailto:tech-pkg@NetBSD.org">tech-pkg@NetBSD.org</a>></tt>. +</p></li> +<li><p> + If there exists a home page for the software in question, please + add the variable <tt class="varname">HOMEPAGE</tt> right after + <tt class="varname">MAINTAINER</tt>. The value of this + variable should be the URL for the home page. +</p></li> +<li><p> + Be sure to set the <tt class="varname">COMMENT</tt> variable to a short + description of the package. +</p></li> +</ul></div> +</div> +<div class="sect1" lang="en"> +<div class="titlepage"> +<div><div><h2 class="title" style="clear: both"> +<a name="components.distinfo"></a>5.2. distinfo</h2></div></div> +<div></div> +</div> +<p> + Most important, the mandatory message digest, or checksum, of all the + distfiles needed for the package to compile, confirming they match the + original file distributed by the author. This ensures that the + distfile retrieved from the Internet has not been corrupted during + transfer or altered by a malign force to introduce a security hole. + It is best generated using the <b class="command">make makesum</b> command. + The digest algorithm used was, at one stage, md5, but that was felt + lacking compared to sha1, and so sha1 is now the default algorithm. + The distfile size is also generated and stored in new distinfo files. + The <a xmlns:html="http://www.w3.org/1999/xhtml" href="ftp://ftp.netbsd.org/pub/NetBSD/packages/pkgsrc/pkgtools/digest/README.html" class="pkgname">pkgtools/digest</a> utility calculates all of the digests + in the distinfo file, and it provides various different algorithms. + At the current time, the algorithms provided are: + <span class="emphasis"><em>md5</em></span>, <span class="emphasis"><em>rmd160</em></span>, + <span class="emphasis"><em>sha1</em></span>, <span class="emphasis"><em>sha256</em></span>, + <span class="emphasis"><em>sha384</em></span> and <span class="emphasis"><em>sha512</em></span>. +</p> +<p> + Some packages have different sets of distfiles on a per architecture + basis (a good example is <a xmlns:html="http://www.w3.org/1999/xhtml" href="ftp://ftp.netbsd.org/pub/NetBSD/packages/pkgsrc/www/navigator/README.html" class="pkgname">www/navigator</a>). These are kept in the + same distinfo file and care should be taken when upgrading such a + package to ensure distfile information is not lost. +</p> +<p> + The message digest/checksum for all the official patches found in the + <tt class="filename">patches/</tt> directory (see <a href="#components.patches" title="5.3. patches/*">Section 5.3, “patches/*”</a>) for the package is also stored in + the <tt class="filename">distinfo</tt> file. This is a message + digest/checksum of all lines in the patch file except the NetBSD RCS Id. + This file is generated by invoking <b class="command">make makepatchsum</b>. +</p> +</div> +<div class="sect1" lang="en"> +<div class="titlepage"> +<div><div><h2 class="title" style="clear: both"> +<a name="components.patches"></a>5.3. patches/*</h2></div></div> +<div></div> +</div> +<p> + This directory contains files that are used by the patch(1) command to + modify the sources as distributed in the distribution file into a form + that will compile and run perfectly on NetBSD. The files are applied + successively in alphabetic order (as returned by a shell + “<span class="quote">patches/patch-*</span>” glob expansion), so + <tt class="filename">patch-aa</tt> is applied before + <tt class="filename">patch-ab</tt>, etc. +</p> +<p> + The <tt class="filename">patch-??</tt> files should be in + <b class="command">diff -bu</b> format, and apply without a fuzz to avoid + problems (To force patches to apply + with fuzz you can set <tt class="varname">PATCH_FUZZ_FACTOR=-F2</tt>). + Furthermore, do not put changes for more than one file into a single + patch-file, as this will make future modifications more difficult. +</p> +<p> + Similar, a file should be patched at most once, not several times by + several different patches. If a file needs several patches, they should + be combined into one file. +</p> +<p> + One important thing to mention is to pay attention that no RCS IDs + get stored in the patch files, as these will cause problems when + later checked into the NetBSD CVS tree. Use the + <a xmlns:html="http://www.w3.org/1999/xhtml" href="ftp://ftp.netbsd.org/pub/NetBSD/packages/pkgsrc/pkgtools/pkgdiff/README.html" class="pkgname">pkgtools/pkgdiff</a> package to avoid these problems. +</p> +<p> + For even more automation, we recommend using mkpatches from the same + package to make a whole set of patches. You just have to backup files + before you edit them to <tt class="filename">filename.orig</tt>, e.g. with + <b class="command">cp -p filename filename.orig</b> or, easier, by using + <b class="command">pkgvi</b> from the same package. If you upgrade a package + this way, you can easily compare the new set of patches with the + previously existing one with patchdiff. +</p> +<p> + When you have finished a package, remember to generate the checksums + for the patch files by using the <b class="command">make makepatchsum</b> + command, see <a href="#components.distinfo" title="5.2. distinfo">Section 5.2, “distinfo”</a>. +</p> +<p> + If it is desired to store any patches that should not be committed into + pkgsrc, they can be kept outside the pkgsrc tree in the + <tt class="filename">$LOCALPATCHES</tt> + directory. The directory tree there is expected to have the same + “<span class="quote">category/package</span>” structure as pkgsrc, and patches are + expected to be stored inside these dirs (also known as + <tt class="filename">$LOCALPATCHES/$PKGPATH</tt>). For + example if you want to keep a private patch for + <tt class="filename">pkgsrc/graphics/png</tt>, keep + it in <tt class="filename">$LOCALPATCHES/graphics/png/mypatch</tt>. All + files in the named directory are expected to be patch files, and + <span class="emphasis"><em>they are applied after pkgsrc patches are applied</em></span>. +</p> +</div> +<div class="sect1" lang="en"> +<div class="titlepage"> +<div><div><h2 class="title" style="clear: both"> +<a name="id2943680"></a>5.4. Other mandatory files</h2></div></div> +<div></div> +</div> +<div class="itemizedlist"><ul type="disc"> +<li> +<tt class="filename">DESCR</tt><p> + A multi-line description of the piece of software. This should include + any credits where they are due. Please bear in mind that others do not + share your sense of humour (or spelling idiosyncrasies), and that others + will read everything that you write here. +</p> +</li> +<li> +<tt class="filename">PLIST</tt><p> + This file governs the files that are installed on your system: all the + binaries, manual pages, etc. There are other directives which may be + entered in this file, to control the creation and deletion of + directories, and the location of inserted files. +</p> +</li> +</ul></div> +</div> +<div class="sect1" lang="en"> +<div class="titlepage"> +<div><div><h2 class="title" style="clear: both"> +<a name="id2943718"></a>5.5. Optional files</h2></div></div> +<div></div> +</div> +<div class="itemizedlist"><ul type="disc"> +<li> +<tt class="filename">INSTALL</tt><p> + Shell script invoked twice during pkg_add. First time after package + extraction and before files are moved in place, the second time after + the files to install are moved in place. This can be used to do any + custom procedures not possible with @exec commands in + <tt class="filename">PLIST</tt>. See + pkg_add(1) and pkg_create(1) for more information. +</p> +</li> +<li> +<tt class="filename">DEINSTALL</tt><p> + This script is executed before and after any files are removed. It is + this script's responsibility to clean up any additional messy details + around the package's installation, since all pkg_delete knows is how to + delete the files created in the original distribution. See pkg_delete(1) + and pkg_create(1) for more information. +</p> +</li> +<li> +<tt class="filename">MESSAGE</tt><p> + Display this file after installation of the package. + Useful for things like legal notices on almost-free software, etc. + Please note that you can modify variables in it easily by using + <tt class="varname">MESSAGE_SUBST</tt> in the package's Makefile: +</p> +<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre>MESSAGE_SUBST+= SOMEVAR="somevalue"</pre></td></tr></table> +<p> + replaces "${SOMEVAR}" with “<span class="quote">somevalue</span>” in + <tt class="filename">MESSAGE</tt>. +</p> +</li> +</ul></div> +</div> +<div class="sect1" lang="en"> +<div class="titlepage"> +<div><div><h2 class="title" style="clear: both"> +<a name="id2943959"></a>5.6. <tt class="filename">work*</tt></h2></div></div> +<div></div> +</div> +<p> + When you type <b class="command">make</b> the distribution files are + unpacked into this directory. It can be removed by running + <b class="command">make clean</b>. +</p> +<p> + This directory is also used to keep various timestamp files. +</p> +</div> +<div class="sect1" lang="en"> +<div class="titlepage"> +<div><div><h2 class="title" style="clear: both"> +<a name="id2943990"></a>5.7. <tt class="filename">files/*</tt></h2></div></div> +<div></div> +</div> +<p> + If you have any files that you wish to be placed in the package prior + to configuration or building, you could place these files here and use + a “<span class="quote">${CP}</span>” command in the pre-configure target to achieve + this. Alternatively, you could simply diff the file against + <tt class="filename">/dev/null</tt> and use the patch mechanism to manage + the creation of this file. +</p> +</div> +<div class="sect1" lang="en"> +<div class="titlepage"> +<div><div><h2 class="title" style="clear: both"> +<a name="id2944093"></a>5.8. Portability of packages</h2></div></div> +<div></div> +</div> +<p> + One appealing feature of pkgsrc is that it runs on many different + platforms. As a result, it is important to ensure, where possible, + that packages in pkgsrc are portable. There are some particular + details you should pay attention to while working on pkgsrc. +</p> +<div class="sect2" lang="en"> +<div class="titlepage"> +<div><div><h3 class="title"> +<a name="id2944103"></a>5.8.1. ${INSTALL}, ${INSTALL_DATA_DIR}, ...</h3></div></div> +<div></div> +</div> +<p> + The BSD-compatible <b class="command">install</b> supplied with some + operating systems will not perform more than one operation at a time. + As such, you should call “<span class="quote">${INSTALL}</span>”, etc. like this: +</p> +<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre>${INSTALL_DATA_DIR} ${PREFIX}/dir1 +${INSTALL_DATA_DIR} ${PREFIX}/dir2</pre></td></tr></table> +</div> +</div> +</div> +<div class="chapter" lang="en"> +<div class="titlepage"> +<div><div><h2 class="title"> +<a name="plist"></a>Chapter 6. PLIST issues</h2></div></div> +<div></div> +</div> +<div class="toc"> +<p><b>Table of Contents</b></p> +<dl> +<dt>6.1. <a href="#plist.misc">Miscellaneous</a> +</dt> +<dt>6.2. <a href="#id2945543">PLIST_SRC</a> +</dt> +<dt>6.3. <a href="#id2945566">PLIST_SUBST</a> +</dt> +<dt>6.4. <a href="#id2945697">Perl5 modules</a> +</dt> +<dt>6.5. <a href="#id2945836">User Interaction</a> +</dt> +</dl> +</div> +<p> +This section addresses some special issues that one needs to pay attention +to when dealing with the <tt class="filename">PLIST</tt> file (or files, see below!). +</p> +<div class="sect1" lang="en"> +<div class="titlepage"> +<div><div><h2 class="title" style="clear: both"> +<a name="plist.misc"></a>6.1. Miscellaneous</h2></div></div> +<div></div> +</div> +<div class="itemizedlist"><ul type="disc"> +<li> +<p>NetBSD RCS Id</p> +<p> + Be sure to add a RCS ID line as the first thing in any + <tt class="filename">PLIST</tt> file you write: +</p> +<p> +</p> +<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre>@comment $NetBSD: pkgsrc.html,v 1.1 2003/06/23 07:41:44 grant Exp $</pre></td></tr></table> +<p> +</p> +</li> +<li> +<p>${MACHINE_ARCH}, ${MACHINE_GNU_ARCH}</p> +<p> + Some packages like emacs and perl embed information about which + architecture they were built on into the pathnames where they install + their file. To handle this case, PLIST will be preprocessed before + actually used, and the symbol "${MACHINE_ARCH}" will be replaced by + what <b class="command">uname -p</b> gives. The same is done if the string + ${MACHINE_GNU_ARCH} is embedded in PLIST somewhere - use this on + packages that have GNU autoconf created configure scripts. +</p> +<p> + Legacy note: There used to be a symbol "<$ARCH>" that was replaced by + the output of <b class="command">uname -m</b>, but that's no longer supported + and has been removed. +</p> +</li> +<li> +<p>${OPSYS}, ${LOWER_OPSYS}, ${OS_VERSION}</p> +<p> + Some packages want to embed the OS name and version into some paths. + To do this, use these variables in the <tt class="filename">PLIST</tt>: +</p> +<div class="itemizedlist"><ul type="circle"> +<li>${OPSYS} - output of "uname -s"</li> +<li>${LOWER_OPSYS} - lowercase common name (eg. "solaris")</li> +<li>${OS_VERSION} - "uname -r"</li> +</ul></div> +</li> +<li> +<p>${PKGLOCALEDIR}</p> +<p> + Packages that install locale files should list them in the PLIST as + “<span class="quote">${PKGLOCALEDIR}/locale/de/LC_MESSAGES/...</span>” instead of + “<span class="quote">share/locale/de/LC_MESSAGES/...</span>”. This properly handles + the fact that different OS's expect locale files to be either in + <tt class="filename">share</tt> or <tt class="filename">lib</tt> by default. +</p> +</li> +<li> +<p>Manpage-compression</p> +<p> + Manpages should be installed in compressed form if + <tt class="varname">MANZ</tt> is set (in <tt class="filename">bsd.own.mk</tt>), + and uncompressed otherwise. To handle this in the + <tt class="filename">PLIST</tt> file, the suffix “<span class="quote">.gz</span>” is + appended/removed automatically for manpages according to + <tt class="varname">MANZ</tt> and <tt class="varname">MANCOMPRESSED</tt> being set + or not, see above for details. This modification of the + <tt class="filename">PLIST</tt> file is done on a copy of it, not + <tt class="filename">PLIST</tt> itself. +</p> +</li> +<li> +<p>Platform specific and differing PLISTs</p> +<p> + Some packages decide to install a different set of files based on + the operating system being used. These differences can be + automatically handled by using the following files: +</p> +<div class="itemizedlist"><ul type="circle"> +<li><tt class="filename">PLIST.common</tt></li> +<li><tt class="filename">PLIST.${OPSYS}</tt></li> +<li><tt class="filename">PLIST.common_end</tt></li> +</ul></div> +<p> + If <tt class="filename">PLIST.${OPSYS}</tt> exists, these files are used + instead of <tt class="filename">PLIST</tt>. This allows packages which + behave in this way to be handled gracefully. Manually overriding + <tt class="varname">PLIST_SRC</tt> for other more exotic uses is also + possible. +</p> +</li> +<li> +<p>Semi-automatic <tt class="filename">PLIST</tt> generation</p> +<p> + You can use the <b class="command">make print-PLIST</b> command to output + a PLIST that matches any new files since the package was extracted. + See below for more information on this target. +</p> +</li> +</ul></div> +</div> +<div class="sect1" lang="en"> +<div class="titlepage"> +<div><div><h2 class="title" style="clear: both"> +<a name="id2945543"></a>6.2. PLIST_SRC</h2></div></div> +<div></div> +</div> +<p> +To use one or more files as source for the <tt class="filename">PLIST</tt> used +in generating the binary package, set the variable +<tt class="varname">PLIST_SRC</tt> to the names of that file(s). +The files are later concatenated using cat(1), and order of things is +important. +</p> +</div> +<div class="sect1" lang="en"> +<div class="titlepage"> +<div><div><h2 class="title" style="clear: both"> +<a name="id2945566"></a>6.3. PLIST_SUBST</h2></div></div> +<div></div> +</div> +<p> +Similar to <tt class="varname">MESSAGE_SUBST</tt> (see above), you can add +variables and their expansions to this variable in the following way: +</p> +<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre>PLIST_SUBST+= SOMEVAR="somevalue"</pre></td></tr></table> +<p> +which replaces all occurrences of “<span class="quote">${SOMEVAR}</span>” in the +<tt class="filename">PLIST</tt> with “<span class="quote">somevalue</span>”. +For the values which are replaced by default, please look in +<tt class="filename">bsd.pkg.mk</tt> (and search for +<span class="emphasis"><em>PLIST_SUBST</em></span>). +</p> +</div> +<div class="sect1" lang="en"> +<div class="titlepage"> +<div><div><h2 class="title" style="clear: both"> +<a name="id2945697"></a>6.4. Perl5 modules</h2></div></div> +<div></div> +</div> +<p> +Makefile of packages providing perl5 modules should include the +makefile fragment <tt class="filename">lang/perl5/module.mk</tt>. It provides +a do-configure +target for the standard perl configuration for such modules as well +as various hooks to tune this configuration. See comments in this +file for details. +</p> +<p> +Perl5 modules will install into different places depending on the version +of perl used during the build process. To address this, the NetBSD +packages system will append lines to the <tt class="filename">PLIST</tt> +corresponding to the files +listed in the installed .packlist file generated by most perl5 modules. +This is invoked by defining <tt class="varname">PERL5_PACKLIST</tt> to a +space-separated list of paths to packlist files: +</p> +<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre>PERL5_PACKLIST= ${PERL5_SITEARCH}/auto/Pg/.packlist</pre></td></tr></table> +<p> +The variables <tt class="varname">PERL5_SITELIB</tt>, +<tt class="varname">PERL5_SITEARCH</tt>, and <tt class="varname">PERL5_ARCHLIB</tt> +represent the three locations in which perl5 modules may be installed, and +may be used by perl5 packages that don't have a packlist. These three +variables are also substituted for in the <tt class="filename">PLIST</tt>. +</p> +</div> +<div class="sect1" lang="en"> +<div class="titlepage"> +<div><div><h2 class="title" style="clear: both"> +<a name="id2945836"></a>6.5. User Interaction</h2></div></div> +<div></div> +</div> +<p> +Occasionally, packages require interaction from the user, and this can be +in a number of ways: +</p> +<div class="itemizedlist"><ul type="disc"> +<li>help in fetching the distfiles</li> +<li>help to configure the package before it is built</li> +<li>help during the build process</li> +<li>help during the installation of a package</li> +</ul></div> +<p> +The <tt class="varname">INTERACTIVE_STAGE</tt> definition is provided to notify +the pkgsrc mechanism of an interactive stage which will be needed, and +this should be set in the package's <tt class="filename">Makefile</tt>. e.g. +</p> +<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre>INTERACTIVE_STAGE= build</pre></td></tr></table> +<p> +Multiple interactive stages can be specified: +</p> +<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre>INTERACTIVE_STAGE= configure install</pre></td></tr></table> +</div> +</div> +<div class="chapter" lang="en"> +<div class="titlepage"> +<div><div><h2 class="title"> +<a name="fixes"></a>Chapter 7. Notes on fixes for packages</h2></div></div> +<div></div> +</div> +<div class="toc"> +<p><b>Table of Contents</b></p> +<dl> +<dt>7.1. <a href="#id2944290">CPP defines</a> +</dt> +<dt>7.2. <a href="#fixes.libtool">Shared libraries - libtool</a> +</dt> +<dt>7.3. <a href="#id2947315">Using libtool on GNU packages that already support libtool</a> +</dt> +<dt>7.4. <a href="#id2947414">GNU Autoconf/Automake</a> +</dt> +<dt>7.5. <a href="#id2947454">Package configuration files</a> +</dt> +<dt>7.6. <a href="#id2947668">Feedback to the author</a> +</dt> +</dl> +</div> +<div class="sect1" lang="en"> +<div class="titlepage"> +<div><div><h2 class="title" style="clear: both"> +<a name="id2944290"></a>7.1. CPP defines</h2></div></div> +<div></div> +</div> +<p> + To port an application to NetBSD, it's usually necessary for the + compiler to be able to judge the system on which it's compiling, and + we use definitions so that the C pre-processor can do this. +</p> +<p> + To test whether you are working on a 4.4 BSD-derived system, you + should use the BSD definition, which is defined in + <tt class="filename"><sys/param.h></tt> on said systems. +</p> +<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre>#include <sys/param.h></pre></td></tr></table> +<p> + and then you can surround the BSD-specific parts of your port using + the conditional: +</p> +<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre>#if (defined(BSD) && BSD >= 199306) + ... +#endif</pre></td></tr></table> +<p> + Please use the “<span class="quote">__NetBSD__</span>” definition sparingly - it + should only apply to features of NetBSD that are not present in other + 4.4-lite derived BSDs. +</p> +</div> +<div class="sect1" lang="en"> +<div class="titlepage"> +<div><div><h2 class="title" style="clear: both"> +<a name="fixes.libtool"></a>7.2. Shared libraries - libtool</h2></div></div> +<div></div> +</div> +<p> + pkgsrc supports many different machines, with different object formats + like a.out and ELF, and varying abilities to do shared library and + dynamic loading at all. To accompany this, varying commands and options + have to be passed to the compiler, linker, etc. to get the Right Thing, + which can be pretty annoying especially if you don't have all the + machines at your hand to test things. The <a xmlns:html="http://www.w3.org/1999/xhtml" href="ftp://ftp.netbsd.org/pub/NetBSD/packages/pkgsrc/devel/libtool/README.html" class="pkgname">devel/libtool</a> pkg + can help here, as it just “<span class="quote">knows</span>” how to build both static + and dynamic libraries from a set of source files, thus being platform + independent. +</p> +<p> + Here's how to use libtool in a pkg in seven simple steps: +</p> +<div class="orderedlist"><ol type="1"> +<li><p> + Add <tt class="varname">USE_LIBTOOL=yes</tt> to the package Makefile. +</p></li> +<li><p> + For library objects, use “<span class="quote">${LIBTOOL} --mode=compile + ${CC}</span>” in place of “<span class="quote">${CC}</span>”. You could even + add it to the definition of <tt class="varname">CC</tt>, if only + libraries are being built in a given Makefile. This one command + will build both PIC and non-PIC library objects, so you need not + have separate shared and non-shared library rules. +</p></li> +<li> +<p> + For the linking of the library, remove any “<span class="quote">ar</span>”, + “<span class="quote">ranlib</span>”, and “<span class="quote">ld -Bshareable</span>” commands, + and use instead: +</p> +<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre>${LIBTOOL} --mode=link ${CC} -o ${.TARGET:.a=.la} ${OBJS:.o=.lo} -rpath ${PREFIX}/lib -version-info major:minor</pre></td></tr></table> +<p> + Note that the library is changed to have a <tt class="filename">.la</tt> + extension, and the objects are changed to have a + <tt class="filename">.lo</tt> extension. Change <tt class="varname">OBJS</tt> + as necessary. This automatically creates all of the + <tt class="filename">.a</tt>, <tt class="filename">.so.major.minor</tt>, + and ELF symlinks (if necessary) in the build directory. Be sure + to include “<span class="quote">-version-info</span>”, especially when major + and minor are zero, as libtool will otherwise strip off the + shared library version. +</p> +<p> + The “<span class="quote">-release</span>” option will produce different results for + a.out and ELF (excluding symlinks) in only one case. An ELF library of + the form + “<span class="quote">libfoo-release.so.<span class="emphasis"><em>x</em></span>.<span class="emphasis"><em>y</em></span></span>” + will have a symlink of + “<span class="quote">libfoo.so.<span class="emphasis"><em>x</em></span>.<span class="emphasis"><em>y</em></span></span>” + on an a.out platform. This is handled automatically. +</p> +<p> + The “<span class="quote">-rpath argument</span>” is the install directory of the + library being built. +</p> +<p> + In the <tt class="filename">PLIST</tt>, include all of the + <tt class="filename">.a</tt>, <tt class="filename">.la</tt>, and + <tt class="filename">.so</tt>, + <tt class="filename">.so.<span class="emphasis"><em>major</em></span></tt> and + <tt class="filename">.so.<span class="emphasis"><em>major</em></span>.<span class="emphasis"><em>minor</em></span></tt> + files. +</p> +</li> +<li> +<p> + When linking shared object (<tt class="filename">.so</tt>) files, + i.e. files that are loaded via dlopen(3), NOT shared libraries, + use “<span class="quote">-module -avoid-version</span>” to prevent them + getting version tacked on. +</p> +<p> + <tt class="filename">PLIST</tt> gets the <tt class="filename">foo.so</tt> + entry. +</p> +</li> +<li> +<p> + When linking programs that depend on these libraries + <span class="emphasis"><em>before</em></span> they are installed, preface the + <b class="command">cc</b> or <b class="command">ld</b> line with + “<span class="quote">${LIBTOOL} --mode=link</span>”, and + it will find the correct libraries (static or shared), but + please be aware that libtool will not allow you to specify + a relative path in -L (such as “<span class="quote">-L../somelib</span>”), + because it expects you to change that argument to be the + <tt class="filename">.la</tt> file. e.g. +</p> +<div class="informalexample"><table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre>${LIBTOOL} --mode=link ${CC} -o someprog -L../somelib -lsomelib</pre></td></tr></table></div> +<p> + should be changed to: +</p> +<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre>${LIBTOOL} --mode=link ${CC} -o someprog ../somelib/somelib.la</pre></td></tr></table> +<p> + and it will do the right thing with the libraries. +</p> +</li> +<li> +<p> + When installing libraries, preface the <b class="command">install</b> + or <b class="command">cp</b> command with + “<span class="quote">${LIBTOOL} --mode=install</span>”, and change the library + name to <tt class="filename">.la</tt>. e.g. +</p> +<div class="informalexample"><table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre>${LIBTOOL} --mode=install ${BSD_INSTALL_DATA} ${SOMELIB:.a=.la} ${PREFIX}/lib</pre></td></tr></table></div> +<p> + This will install the static <tt class="filename">.a</tt>, shared + library, any needed symlinks, and run <b class="command">ldconfig</b>. +</p> +</li> +</ol></div> +</div> +<div class="sect1" lang="en"> +<div class="titlepage"> +<div><div><h2 class="title" style="clear: both"> +<a name="id2947315"></a>7.3. Using libtool on GNU packages that already support libtool</h2></div></div> +<div></div> +</div> +<p> + Add <tt class="varname">USE_LIBTOOL=yes</tt> and + <tt class="varname">LTCONFIG_OVERRIDE=${WRKSRC}/ltconfig</tt> to the + package Makefile as the quick way to bypass the pkg's own + <span class="emphasis"><em>libtool</em></span>. The pkg's own + <span class="emphasis"><em>libtool</em></span> is created by ltconfig script at + do-configure target. If <tt class="varname">USE_LIBTOOL</tt> and + <tt class="varname">LTCONFIG_OVERRIDE</tt> are defined, the specified + ltconfig is overridden, using <a xmlns:html="http://www.w3.org/1999/xhtml" href="ftp://ftp.netbsd.org/pub/NetBSD/packages/pkgsrc/devel/libtool/README.html" class="pkgname">devel/libtool</a> instead of + the pkg's own libtool. For newer versions of libtool (without + ltconfig) it may be necessary to use + <tt class="varname">LIBTOOL_OVERRIDE=${WRKSRC}/libtool</tt> instead. +</p> +<p> + If your package makes use of the platform independent library + for loading dynamic shared objects, that comes with libtool + (libltdl), you should include the libtool buildlink2.mk (and + set <tt class="varname">USE_BUILDLINK2=YES</tt>). +</p> +<p> + Some packages use libtool incorrectly so that the package may not work or + build in some circumstances. Some of the more common errors are: +</p> +<div class="itemizedlist"><ul type="disc"> +<li> + The inclusion of a shared object (-module) as a dependent library in an + executable or library. This in itself isn't a problem if one of two things + has been done: + <div class="orderedlist"><ol type="1"> +<li>The shared object is named correctly, i.e. + <tt class="filename">libfoo.la</tt>, not + <tt class="filename">foo.la</tt> +</li> +<li>The -dlopen option is used when linking an executable.</li> +</ol></div> +</li> +<li> + The use of libltdl without the correct calls to initialisation routines. + The function lt_dlinit() should be called and the macro + LTDL_SET_PRELOADED_SYMBOLS included in executables. +</li> +</ul></div> +</div> +<div class="sect1" lang="en"> +<div class="titlepage"> +<div><div><h2 class="title" style="clear: both"> +<a name="id2947414"></a>7.4. GNU Autoconf/Automake</h2></div></div> +<div></div> +</div> +<p> + If a package needs GNU autoconf or automake to be executed + to regenerate the configure script and Makefile.in makefile + templates, then they should be executed in a pre-configure + target. Two Makefile fragments are provided in + pkgsrc/mk/autoconf.mk and pkgsrc/mk/automake.mk to help + dealing with these tools. See comments in these files for + details. +</p> +<p> + For packages that need only autoconf: +</p> +<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre>AUTOCONF_REQD= 2.50 # if default version is not good enough +... + +pre-configure: + cd ${WRKSRC}; ${AUTOCONF} + +... +.include "../../mk/autoconf.mk"</pre></td></tr></table> +<p> +and for packages that need automake and autoconf: +</p> +<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre>AUTOMAKE_REQD= 1.7.1 # if default version is not good enough +... + +pre-configure: + cd ${WRKSRC}; \ + ${ACLOCAL}; \ + ${AUTOHEADER}; \ + ${AUTOMAKE} -a --foreign -i; \ + ${AUTOCONF} + +... +.include "../mk/automake.mk"</pre></td></tr></table> +<p> + There are times when the configure process makes additional + changes to the generated files, which then causes the build + process to try to re-execute the automake sequence. This is + prevented by touching various files in the configure stage. If + this causes problems with your package you can set + <tt class="varname">AUTOMAKE_OVERRIDE=NO</tt> in the package + Makefile. +</p> +</div> +<div class="sect1" lang="en"> +<div class="titlepage"> +<div><div><h2 class="title" style="clear: both"> +<a name="id2947454"></a>7.5. Package configuration files</h2></div></div> +<div></div> +</div> +<p> + Packages should be taught to look for their configuration + files in <tt class="varname">${PKG_SYSCONFDIR}</tt>, which is passed + through to the configure and build processes. + <tt class="varname">PKG_SYSCONFDIR</tt> may be customized in various + ways by setting other make variables: +</p> +<div class="itemizedlist"><ul type="disc"> +<li><p> + <tt class="varname">PKG_SYSCONFBASE</tt> is the main config directory + under which all package configuration files are to be found. + This defaults to <tt class="filename">${PREFIX}/etc</tt>, but may + be overridden in <tt class="filename">/etc/mk.conf</tt>. +</p></li> +<li><p> + <tt class="varname">PKG_SYSCONFSUBDIR</tt> is the subdirectory of + <tt class="varname">PKG_SYSCONFBASE</tt> under which the + configuration files for a particular package may be found, e.g. + the Apache configuration files may all be found under the + <tt class="filename">httpd/</tt> subdirectory of + <tt class="varname">${PKG_SYSCONFBASE}</tt>. This should be set in + the package Makefile. +</p></li> +<li><p> + By default, + <tt class="varname">PKG_SYSCONFDIR=${PKG_SYSCONFBASE}/${PKG_SYSCONFSUBDIR}</tt>, + but this may be overridden by setting + <tt class="varname">PKG_SYSCONFDIR.${PKG_SYSCONFVAR}</tt> for a + particular package, where <tt class="varname">PKG_SYSCONFVAR</tt> + defaults to <tt class="varname">${PKGBASE}</tt>. This is not meant to + be set by a package Makefile, but is reserved for users who wish + to override the <tt class="varname">PKG_SYSCONFDIR</tt> setting for + a particular package with a special location. +</p></li> +</ul></div> +<p> + The only variables that users should customize are + <tt class="varname">PKG_SYSCONFBASE</tt> and + <tt class="varname">PKG_SYSCONFDIR.${PKG_SYSCONFVAR}</tt>. + Users will typically want to set + <tt class="varname">PKG_SYSCONFBASE</tt> to + <tt class="filename">/etc</tt>, or to accept the default location + of <tt class="filename">${PREFIX}/etc</tt>. +</p> +</div> +<div class="sect1" lang="en"> +<div class="titlepage"> +<div><div><h2 class="title" style="clear: both"> +<a name="id2947668"></a>7.6. Feedback to the author</h2></div></div> +<div></div> +</div> +<p> + If you have found any bugs in the package you make available, + if you had to do special steps to make it run under NetBSD or + if you enhanced the software in various other ways, be sure + to report these changes back to the original author of the + program! With that kind of support, the next release of the + program can incorporate these fixes, and people not using the + NetBSD packages system can win from your efforts. +</p> +<p> + Support the idea of free software! +</p> +</div> +</div> +<div class="chapter" lang="en"> +<div class="titlepage"> +<div><div><h2 class="title"> +<a name="build"></a>Chapter 8. The build process</h2></div></div> +<div></div> +</div> +<div class="toc"> +<p><b>Table of Contents</b></p> +<dl> +<dt>8.1. <a href="#build.prefix">Program location</a> +</dt> +<dt>8.2. <a href="#id2949108">Main targets</a> +</dt> +<dt>8.3. <a href="#build.helpful-targets">Other helpful targets</a> +</dt> +</dl> +</div> +<p> + The basic steps for building a program are always the same. First the + program's source (<span class="emphasis"><em>distfile</em></span>) must be brought to the + local system and then extracted. After any patches to compile properly + on NetBSD are applied, the software can be configured, then built + (usually by compiling), and finally the generated binaries, etc. can be + put into place on the system. These are exactly the steps performed by + the NetBSD package system, which is implemented as a series of targets + in a central Makefile, <tt class="filename">pkgsrc/mk/bsd.pkg.mk</tt>. +</p> +<div class="sect1" lang="en"> +<div class="titlepage"> +<div><div><h2 class="title" style="clear: both"> +<a name="build.prefix"></a>8.1. Program location</h2></div></div> +<div></div> +</div> +<p> + Before outlining the process performed by the NetBSD package system in + the next section, here's a brief discussion on where programs are + installed, and which variables influence this. +</p> +<p> + The automatic variable <tt class="varname">PREFIX</tt> indicates where all + files of the final program shall be installed. It is usually set to + <tt class="varname">LOCALBASE</tt> (<tt class="filename">/usr/pkg</tt>), or + <tt class="varname">CROSSBASE</tt> for pkgs in the “<span class="quote">cross</span>” + category, though its value becomes that of <tt class="varname">X11BASE</tt> if + <tt class="varname">USE_IMAKE</tt> or <tt class="varname">USE_X11BASE</tt> is set. + The value of <tt class="varname">PREFIX</tt> needs to be put into the various + places in the program's source where paths to these files are encoded. + See <a href="#components.patches" title="5.3. patches/*">Section 5.3, “patches/*”</a> and <a href="#fixes.libtool" title="7.2. Shared libraries - libtool">Section 7.2, “Shared libraries - libtool”</a> for more details. +</p> +<p> + When choosing which of these variables to use, follow the following rules: +</p> +<div class="itemizedlist"><ul type="disc"> +<li><p> + <tt class="varname">PREFIX</tt> always points to the location where the current + pkg will be installed. When referring to a pkg's own installation path, + use “<span class="quote">${PREFIX}</span>”. +</p></li> +<li><p> + <tt class="varname">LOCALBASE</tt> is where all non-X11 pkgs are installed. + If you need to construct a -I or -L argument to the compiler to find + includes and libraries installed by another non-X11 pkg, use + “<span class="quote">${LOCALBASE}</span>”. +</p></li> +<li><p> + <tt class="varname">X11BASE</tt> is where the actual X11 distribution (from + xsrc, etc.) is installed. When looking for + <span class="emphasis"><em>standard</em></span> X11 includes (not + those installed by a pkg), use “<span class="quote">${X11BASE}</span>”. +</p></li> +<li><p> + X11 based pkgs are special in that they may be installed in either + <tt class="varname">X11BASE</tt> or <tt class="varname">LOCALBASE</tt>. To install X11 + packages in <tt class="varname">LOCALBASE</tt>, simply install + <a xmlns:html="http://www.w3.org/1999/xhtml" href="ftp://ftp.netbsd.org/pub/NetBSD/packages/pkgsrc/pkgtools/xpkgwedge/README.html" class="pkgname">pkgtools/xpkgwedge</a>. If you need to find includes or libraries + installed by a pkg that has <tt class="varname">USE_IMAKE</tt> or + <tt class="varname">USE_X11BASE</tt> in its pkg Makefile, you need to + use <span class="emphasis"><em>both</em></span> “<span class="quote">${X11BASE}</span>” and + “<span class="quote">${LOCALBASE}</span>”. +</p></li> +<li><p> + <tt class="varname">X11PREFIX</tt> should be used to refer to the installed + location of an X11 package. <tt class="varname">X11PREFIX</tt> will be set to + <tt class="varname">X11BASE</tt> if xpkgwedge is not installed, + and to <tt class="varname">LOCALBASE</tt> if xpkgwedge is installed. +</p></li> +<li> +<p> + If xpkgwedge is installed, it is possible to have some packages installed + in <tt class="varname">X11BASE</tt> and some in <tt class="varname">LOCALBASE</tt>. + To determine the prefix of an installed package, the + <tt class="varname">EVAL_PREFIX</tt> definition can be used. It takes pairs in the + format “<span class="quote">DIRNAME=<package></span>”, and the make(1) variable + <tt class="varname">DIRNAME</tt> will be set to the prefix of the installed + package <package>, or “<span class="quote">${X11PREFIX}</span>” if the package is + not installed. +</p> +<p> + This is best illustrated by example. +</p> +<p> + The following lines are taken from + <tt class="filename">pkgsrc/wm/scwm/Makefile</tt>: +</p> +<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre>EVAL_PREFIX+= GTKDIR=gtk+ +CONFIGURE_ARGS+= --with-guile-prefix=${LOCALBASE} \ + --with-gtk-prefix="${GTKDIR}" \ + --enable-multibyte</pre></td></tr></table> +<p> + Specific defaults can be defined for the packages evaluated using + <tt class="varname">EVAL_PREFIX</tt>, by using a definition of the form: +</p> +<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre>GTKDIR_DEFAULT= ${LOCALBASE}</pre></td></tr></table> +<p> + where <tt class="varname">GTKDIR</tt> corresponds to the first definition in + the <tt class="varname">EVAL_PREFIX</tt> pair. +</p> +</li> +</ul></div> +</div> +<div class="sect1" lang="en"> +<div class="titlepage"> +<div><div><h2 class="title" style="clear: both"> +<a name="id2949108"></a>8.2. Main targets</h2></div></div> +<div></div> +</div> +<p> + The main targets used during the build process defined in +<tt class="filename">bsd.pkg.mk</tt> are: +</p> +<div class="itemizedlist"><ul type="disc"> +<li> +<p>fetch</p> +<p> + This will check if the file(s) given in the variables + <tt class="varname">DISTFILES</tt> and <tt class="varname">PATCHFILES</tt> (as + defined in the package's Makefile) are present on the + local system in <tt class="filename">/usr/pkgsrc/distfiles</tt>. If they + are not present, an attempt will be made to fetch them using commands + of the form: +</p> +<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre>${FETCH_CMD} ${FETCH_BEFORE_ARGS} ${site}${file} ${FETCH_AFTER_ARGS}</pre></td></tr></table> +<p> + where ${site} varies through several possibilities in turn: first, + <tt class="varname">MASTER_SITE_OVERRIDE</tt> is tried, then the sites + specified in either <tt class="varname">SITES_file</tt> if defined, else + <tt class="varname">MASTER_SITES</tt> or <tt class="varname">PATCH_SITES</tt>, as + applies, then finally the value of + <tt class="varname">MASTER_SITE_BACKUP</tt>. The order of all except the + first can be optionally sorted by the user, via setting either + <tt class="varname">MASTER_SORT_AWK</tt> or + <tt class="varname">MASTER_SORT_REGEX</tt>. +</p> +</li> +<li> +<p>checksum</p> +<p> + After the distfile(s) are fetched, their checksum is generated and + compared with the checksums stored in the distinfo file. If the + checksums don't match, the build is aborted. This is to ensure the same + distfile is used for building, and that the distfile wasn't changed, + e.g. by some malign force, deliberately changed distfiles on the master + distribution site or network lossage. +</p> +</li> +<li> +<p>extract</p> +<p> + When the distfiles are present on the local system, they need to be + extracted, as they are usually in the form of some compressed archive + format, most commonly <tt class="filename">.tar.gz</tt>. If only some of + the distfiles need to be uncompressed, the files to be uncompressed + should be put into <tt class="varname">EXTRACT_ONLY</tt>. If the distfiles + are not in <tt class="filename">.tar.gz</tt> format, they can be + extracted by setting <tt class="varname">EXTRACT_CMD</tt>, + <tt class="varname">EXTRACT_BEFORE_ARGS</tt> and/or + <tt class="varname">EXTRACT_AFTER_ARGS</tt>. +</p> +</li> +<li> +<p>patch</p> +<p> + After extraction, all the patches named by the + <tt class="varname">PATCHFILES</tt>, those present in the patches + subdirectory of the package as well as in $LOCALPATCHES/$PKGPATH (e.g. + <tt class="filename">/usr/local/patches/graphics/png</tt>) are applied. + Patchfiles ending in <tt class="filename">.Z</tt> or + <tt class="filename">.gz</tt> are uncompressed before they are applied, + files ending in <tt class="filename">.orig</tt> or + <tt class="filename">.rej</tt> are ignored. Any special options to patch(1) + can be handed in <tt class="varname">PATCH_DIST_ARGS</tt>. + See <a href="#components.patches" title="5.3. patches/*">Section 5.3, “patches/*”</a> for more details. +</p> +<p> + By default patch is given special args to make it fail if the + patches with some lines of fuzz. Please fix (regen) the patches + so that they apply cleanly. The rationale behind this is that + patches that apply cleanly may end up being applied in the wrong + place, and cause severe harm there. +</p> +</li> +<li> +<p>configure</p> +<p> + Most pieces of software need information on the header files, + system calls, and library routines which are available in NetBSD. + This is the process known as configuration, and is usually + automated. In most cases, a script is supplied with the source, + and its invocation results in generation of header files, + Makefiles, etc. +</p> +<p> + If the program's distfile contains its own configure script, this can + be invoked by setting <tt class="varname">HAS_CONFIGURE</tt>. If the + configure script is a GNU autoconf script, + <tt class="varname">GNU_CONFIGURE</tt> should be specified instead. In either + case, any arguments to the configure script can be specified in the + <tt class="varname">CONFIGURE_ARGS</tt> variable, and the configure script's + name can be set in <tt class="varname">CONFIGURE_SCRIPT</tt> if it differs + from the default “<span class="quote">configure</span>”. +</p> +<p> + If the program uses an Imakefile for configuration, the appropriate + steps can be invoked by setting <tt class="varname">USE_IMAKE</tt> to + “<span class="quote">YES</span>”. (If you only want the package installed in + <tt class="varname">$X11PREFIX</tt> but xmkmf not being run, set + <tt class="varname">USE_X11BASE</tt> instead!) +</p> +</li> +<li> +<p>build</p> +<p> + Once configuration has taken place, the software can be built on + NetBSD by invoking <tt class="varname">$MAKE_PROGRAM</tt> on + <tt class="varname">$MAKEFILE</tt> with <tt class="varname">$ALL_TARGET</tt> as + the target to build. The default <tt class="varname">MAKE_PROGRAM</tt> is + “<span class="quote">gmake</span>” if <tt class="varname">USE_GMAKE</tt> is set, + “<span class="quote">make</span>” otherwise. <tt class="varname">MAKEFILE</tt> is set to + “<span class="quote">Makefile</span>” by default, and <tt class="varname">ALL_TARGET</tt> + defaults to “<span class="quote">all</span>”. Any of these variables can be set to + change the default build process. +</p> +</li> +<li> +<p>install</p> +<p> + Once the build stage has completed, the final step is to install + the software in public directories, for users. As in the + build-target, <tt class="varname">$MAKE_PROGRAM</tt> is invoked on + <tt class="varname">$MAKEFILE</tt> here, but with the + <tt class="varname">$INSTALL_TARGET</tt> instead, the latter defaulting to + “<span class="quote">install</span>” (plus “<span class="quote">install.man</span>”, if + <tt class="varname">USE_IMAKE</tt> is set). +</p> +</li> +</ul></div> +<p> + If no target is specified, the default is “<span class="quote">build</span>”. + If a subsequent stage is requested, all prior stages are made: e.g. + <b class="command">make build</b> will also perform the equivalent of: +</p> +<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre>make fetch +make checksum +make extract +make patch +make configure +make build</pre></td></tr></table> +</div> +<div class="sect1" lang="en"> +<div class="titlepage"> +<div><div><h2 class="title" style="clear: both"> +<a name="build.helpful-targets"></a>8.3. Other helpful targets</h2></div></div> +<div></div> +</div> +<div class="itemizedlist"><ul type="disc"> +<li> +<p>pre/post-*</p> +<p> + For any of the main targets described in the previous section, two + auxiliary targets exist with “<span class="quote">pre-</span>” and + “<span class="quote">post-</span>” used as a prefix + for the main target's name. These targets are invoked before and + after the main target is called, allowing extra configuration or + installation steps, for example, which program's configure script + or install target omitted. +</p> +</li> +<li> +<p>do-*</p> +<p> + Should one of the main targets do the wrong thing, and should there + be no variable to fix this, you can redefine it with the do-* + target. (Note that redefining the target itself instead of the + do-* target is a bad idea, as the pre-* and post-* targets won't be + called anymore, etc.) You will not usually need to do this. +</p> +</li> +<li> +<p>reinstall</p> +<p> + If you did a <b class="command">make install</b> and you noticed some file + was not installed properly, you can repeat the installation with this + target, which will ignore the “<span class="quote">already installed</span>” flag. +</p> +</li> +<li> +<p>deinstall</p> +<p> + This target does a pkg_delete(1) in the current directory, + effectively de-installing the package. The following variables can + be used either on the command line or in + <tt class="filename">/etc/mk.conf</tt> to tune the behaviour: +</p> +<div class="itemizedlist"><ul type="circle"> +<li> +<p><tt class="varname">PKG_VERBOSE</tt></p> +<p> + Add a "-v" to the pkg_delete(1) command. +</p> +</li> +<li> +<p><tt class="varname">DEINSTALLDEPENDS</tt></p> +<p> + Remove all packages that require (depend on) the given package. + This can be used to remove any packages that may have been pulled in + by a given package, e.g. if <b class="command">make deinstall + DEINSTALLDEPENDS=1</b> is done in + <tt class="filename">pkgsrc/x11/kde</tt>, this is likely to remove whole + KDE. Works by adding “<span class="quote">-R</span>” to the pkg_delete command line. +</p> +</li> +</ul></div> +</li> +<li> +<p>update</p> +<p> + This target causes the current package to be updated to the latest + version. The package and all depending packages first get de-installed, + then current versions of the corresponding packages get compiled and + installed. This is similar to manually noting which packages are + currently installed, then performing a series of <b class="command">make + deinstall</b> and <b class="command">make install</b> (or whatever + <tt class="varname">UPDATE_TARGET</tt> is set to) for these packages. +</p> +<p> + You can use the “<span class="quote">update</span>” target to resume package + updating in case a previous <b class="command">make update</b> was interrupted + for some reason. However, in this case, make sure you don't call + <b class="command">make clean</b> or otherwise remove the list of dependent + packages in <tt class="varname">WRKDIR</tt>. Otherwise you lose the + ability to automatically update the current package along with the + dependent packages you have installed. +</p> +<p> + Resuming an interrupted <b class="command">make update</b> will only work as + long as the package tree remains unchanged. If the source code for + one of the packages to be updated has been changed, resuming + <b class="command">make update</b> will most certainly fail! +</p> +<p> + The following variables can be used either on the command line or in + <tt class="filename">/etc/mk.conf</tt> to alter the behaviour of + <b class="command">make update</b>: +</p> +<div class="itemizedlist"><ul type="circle"> +<li> +<tt class="varname">UPDATE_TARGET</tt><p> + Install target to recursively use for the updated package and the + dependent packages. Defaults to <tt class="varname">DEPENDS_TARGET</tt> if set, + “<span class="quote">install</span>” otherwise for <b class="command">make update</b>. + e.g. <b class="command">make update UPDATE_TARGET=package</b> +</p> +</li> +<li> +<tt class="varname">NOCLEAN</tt><p> + Don't clean up after updating. Useful if you want to leave the + work sources of the updated packages around for inspection or + other purposes. Be sure you eventually clean up the source + tree (see the “<span class="quote">clean-update</span>” target below) or you may + run into troubles with old source code still lying around on your + next <b class="command">make</b> or <b class="command">make update</b>. +</p> +</li> +<li> +<tt class="varname">REINSTALL</tt><p> + Deinstall each package before installing (making + <tt class="varname">DEPENDS_TARGET</tt>). This may be necessary if the + “<span class="quote">clean-update</span>” target (see below) was called after + interrupting a running <b class="command">make update</b>. +</p> +</li> +<li> +<tt class="varname">DEPENDS_TARGET</tt><p> + Allows you to disable recursion and hardcode the target for + packages. The default is “<span class="quote">update</span>” for the update target, + facilitating a recursive update of prerequisite packages. + Only set <tt class="varname">DEPENDS_TARGET</tt> if you want to disable + recursive updates. Use <tt class="varname">UPDATE_TARGET</tt> instead to just + set a specific target for each package to be installed during + <b class="command">make update</b> (see above). +</p> +</li> +</ul></div> +</li> +<li> +<p>clean-update</p> +<p> + Clean the source tree for all packages that would get updated if + <b class="command">make update</b> was called from the current directory. + This target should not be used if the current package (or any of its + depending packages) have already been de-installed (e.g., after calling + <b class="command">make update</b>) or you may lose some packages you intended + to update. As a rule of thumb: only use this target + <span class="emphasis"><em>before</em></span> the first time you run + <b class="command">make update</b> and only if you have a dirty package tree + (e.g., if you used <tt class="varname">NOCLEAN</tt>). +</p> +<p> + If you unsure about whether your tree is clean you can either perform + a <b class="command">make clean</b> at the top of the tree, or use the + following sequence of commands from the directory of the package you + want to update (<span class="emphasis"><em>before</em></span> running + <b class="command">make update</b> for the first time, otherwise you lose + all the packages you wanted to update!): +</p> +<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre><tt class="prompt">#</tt> <b class="userinput"><tt>make clean-update</tt></b> +<tt class="prompt">#</tt> <b class="userinput"><tt>make clean CLEANDEPENDS=YES</tt></b> +<tt class="prompt">#</tt> <b class="userinput"><tt>make update</tt></b></pre></td></tr></table> +<p> + The following variables can be used either on the command line or in + <tt class="filename">/etc/mk.conf</tt> to alter the behaviour of + <b class="command">make clean-update</b>: +</p> +<div class="itemizedlist"><ul type="circle"><li> +<tt class="varname">CLEAR_DIRLIST</tt><p> + After <b class="command">make clean</b>, do not reconstruct the list of + directories to update for this package. Only use this if <b class="command">make + update</b> successfully installed all packages you wanted to + update. Normally, this is done automatically on <b class="command">make + update</b>, but may have been suppressed by the +<tt class="varname">NOCLEAN</tt> variable (see above). +</p> +</li></ul></div> +</li> +<li> +<p>info</p> +<p> + This target invokes <b class="command">pkg_info</b> for the current + package. You can use this to check which version of a package is + installed. +</p> +</li> +<li> +<p>readme</p> +<p> + This target generates a <tt class="filename">README.html</tt> file, which + can be viewed using a browser such as <a xmlns:html="http://www.w3.org/1999/xhtml" href="ftp://ftp.netbsd.org/pub/NetBSD/packages/pkgsrc/www/navigator/README.html" class="pkgname">www/navigator</a> or + <a xmlns:html="http://www.w3.org/1999/xhtml" href="ftp://ftp.netbsd.org/pub/NetBSD/packages/pkgsrc/www/lynx/README.html" class="pkgname">www/lynx</a>. The generated files contain references to any + packages which are in the <tt class="varname">PACKAGES</tt> directory on + the local host. The generated files can be made to refer to URLs based on + <tt class="varname">FTP_PKG_URL_HOST</tt> and + <tt class="varname">FTP_PKG_URL_DIR</tt>. For example, if I wanted to generate + <tt class="filename">README.html</tt> files which pointed to binary packages + on the local machine, in the directory + <tt class="filename">/usr/packages</tt>, set + <tt class="varname">FTP_PKG_URL_HOST=file://localhost</tt> and + <tt class="varname">FTP_PKG_URL_DIR=/usr/packages</tt>. The + <tt class="varname">${PACKAGES}</tt> directory and its subdirectories will be + searched for all the binary packages. +</p> +</li> +<li> +<p>readme-all</p> +<p> + Use this target to create a file <tt class="filename">README-all.html</tt> + which contains a list of all packages currently available in the NetBSD + Packages Collection, together with the category they belong to and a + short description. This file is compiled from the + <tt class="filename">pkgsrc/*/README.html</tt> files, so be sure to run + this <span class="emphasis"><em>after</em></span> a <b class="command">make readme</b>. +</p> +</li> +<li> +<p>cdrom-readme</p> +<p> + This is very much the same as the “<span class="quote">readme</span>” target (see + above), but is to be used when generating a pkgsrc tree to be written + to a CD-ROM. This target also produces + <tt class="filename">README.html</tt> files, and can be made to refer + to URLs based on <tt class="varname">CDROM_PKG_URL_HOST</tt> and + <tt class="varname">CDROM_PKG_URL_DIR</tt>. +</p> +</li> +<li> +<p>show-distfiles</p> +<p> + This target shows which distfiles and patchfiles are needed to build + the package. (<tt class="varname">DISTFILES</tt> and + <tt class="varname">PATCHFILES</tt>, but not <tt class="filename">patches/*</tt>) +</p> +</li> +<li> +<p>show-downlevel</p> +<p> + This target shows nothing if the package is not installed. If a version + of this package is installed, but is not the version provided in this + version of pkgsrc, then a warning message is displayed. This target can + be used to show which of your installed packages are downlevel, and so + the old versions can be deleted, and the current ones added. +</p> +</li> +<li> +<p>show-pkgsrc-dir</p> +<p> + This target shows the directory in the pkgsrc hierarchy from which the + package can be built and installed. This may not be the same directory + as the one from which the package was installed. This target is intended + to be used by people who may wish to upgrade many packages on a single + host, and can be invoked from the top-level pkgsrc Makefile by using the + “<span class="quote">show-host-specific-pkgs</span>” target. +</p> +</li> +<li> +<p>show-installed-depends</p> +<p> + This target shows which installed packages match the current package's + <tt class="varname">DEPENDS</tt>. Useful if out of date DEPENDS are + causing build problems. +</p> +</li> +<li> +<p>check-shlibs</p> +<p> + After a package is installed, check all its binaries and (on ELF + platforms) shared libraries to see if they find the shared libs they need. + Run by default if <tt class="varname">PKG_DEVELOPER</tt> is set in + <tt class="filename">/etc/mk.conf</tt>. +</p> +</li> +<li> +<p>print-PLIST</p> +<p> + After a “<span class="quote">make install</span>” from a new or upgraded pkg, this + prints out an attempt to generate a new <tt class="filename">PLIST</tt> from + a <b class="command">find -newer work/.extract_done</b>. + An attempt is made to care for shared libs etc., but it is + <span class="emphasis"><em>strongly</em></span> recommended to review the result before + putting it into <tt class="filename">PLIST</tt>. On upgrades, it's useful to + diff the output of this command against an already existing + <tt class="filename">PLIST</tt> file. +</p> +<p> + If the package installs files via tar(1) or other methods that don't + update file access times, be sure to add these files manually to your + <tt class="filename">PLIST</tt>, as “<span class="quote">find -newer</span>” won't catch + them! +</p> +</li> +<li> +<p>bulk-package</p> +<p> + Used to do bulk builds. If an appropriate binary package already exists, + no action is taken. If not, this target will compile, install and + package it (and it's depends, if <tt class="varname">PKG_DEPENDS</tt> is + set properly. See <a href="#binary.configuration">Section 4.3.1, “Configuration”</a>. + After creating the binary + package, the sources, the just-installed package and it's required + packages are removed, preserving free disk space. +</p> +</li> +<li> +<p>bulk-install</p> +<p> + Used during bulk-installs to install required packages. If an + appropriate binary package is available, it will be installed via + pkg_add. If not, <b class="command">make bulk-package</b> will be executed, + but the installed binary not be removed. A binary package is + “<span class="quote">appropriate</span>” to be installed via <b class="command">pkg_add</b> + if: +</p> +<div class="itemizedlist"><ul type="circle"> +<li>None of the package's files (<tt class="filename">Makefile</tt>, + ...) were modified since it was built.</li> +<li>None of the package's required (binary) packages were + modified since it was built.</li> +</ul></div> +</li> +</ul></div> +</div> +</div> +<div class="chapter" lang="en"> +<div class="titlepage"> +<div><div><h2 class="title"> +<a name="buildlink2"></a>Chapter 9. buildlink2 methodology</h2></div></div> +<div></div> +</div> +<div class="toc"> +<p><b>Table of Contents</b></p> +<dl> +<dt>9.1. <a href="#id2953172">Converting packages to use buildlink2</a> +</dt> +<dt>9.2. <a href="#id2953308">Writing buildlink2.mk files</a> +</dt> +</dl> +</div> +<p> +buildlink2 is a pkgsrc framework that controls what headers and libraries +are seen by a package's configure and build processes. This is implemented +in a two step process: +</p> +<div class="orderedlist"><ol type="1"> +<li><p> +Symlink headers and libraries for dependencies into +<tt class="varname">BUILDLINK_DIR</tt>, which by default is a subdirectory +of <tt class="varname">WRKDIR</tt>. +</p></li> +<li><p> +Create wrapper scripts that are used in place of the normal compiler +tools that translate “<span class="quote">-I${LOCALBASE}/include</span>” and +“<span class="quote">-L${LOCALBASE}/lib</span>” into references to +<tt class="varname">BUILDLINK_DIR</tt>. +</p></li> +</ol></div> +<p> +This normalizes the environment in which a package is built so that the +package may be built consistently despite what may other software may +installed. Please refer to +<tt class="filename">pkgsrc/mk/buildlink2/buildlink2.txt</tt> for some +FAQs and answers regarding buildlink2, and to +<tt class="filename">pkgsrc/mk/buildlink2/README</tt> +for a description of how buildlink2 is implemented in pkgsrc. +</p> +<div class="sect1" lang="en"> +<div class="titlepage"> +<div><div><h2 class="title" style="clear: both"> +<a name="id2953172"></a>9.1. Converting packages to use buildlink2</h2></div></div> +<div></div> +</div> +<p> +The process of converting packages to use the buildlink2 framework is +fairly straightforward. The package <tt class="filename">Makefile</tt> must +define <tt class="varname">USE_BUILDLINK2</tt>. +If a dependency on a particular package, e.g. foo, is required for its +libraries and headers, then we replace: +</p> +<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre>DEPENDS+= foo>=1.1.0:../../category/foo</pre></td></tr></table> +<p> +with +</p> +<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre>.include "../../category/foo/buildlink2.mk"</pre></td></tr></table> +<p> +There are several buildlink2.mk files in <tt class="filename">pkgsrc/mk</tt> +that handle special package issues: +</p> +<div class="itemizedlist"><ul type="disc"> +<li><p> + <tt class="filename">motif.buildlink2.mk</tt> checks for a system-provided + Motif installation or adds a dependency on <a xmlns:html="http://www.w3.org/1999/xhtml" href="ftp://ftp.netbsd.org/pub/NetBSD/packages/pkgsrc/x11/lesstif/README.html" class="pkgname">x11/lesstif</a> or + <a xmlns:html="http://www.w3.org/1999/xhtml" href="ftp://ftp.netbsd.org/pub/NetBSD/packages/pkgsrc/x11/openmotif/README.html" class="pkgname">x11/openmotif</a>; +</p></li> +<li><p> + <tt class="filename">ossaudio.buildlink2.mk</tt> defines several variables + that may be used by packages that use the Open Sound System (OSS) API; +</p></li> +<li><p> + <tt class="filename">pthread.buildlink2.mk</tt> uses the value of + <tt class="varname">PTHREAD_OPTS</tt> and checks for native pthreads or adds + a dependency on <a xmlns:html="http://www.w3.org/1999/xhtml" href="ftp://ftp.netbsd.org/pub/NetBSD/packages/pkgsrc/devel/pth/README.html" class="pkgname">devel/pth</a> as needed; +</p></li> +<li><p> + <tt class="filename">xaw.buildlink2.mk</tt> uses the value of + <tt class="varname">XAW_TYPE</tt> to choose a particular Athena widgets + library. +</p></li> +</ul></div> +<p> +The comments in those buildlink2.mk files provide a more complete +description of how to use them properly. +</p> +</div> +<div class="sect1" lang="en"> +<div class="titlepage"> +<div><div><h2 class="title" style="clear: both"> +<a name="id2953308"></a>9.2. Writing buildlink2.mk files</h2></div></div> +<div></div> +</div> +<p> +A simple example of a buildlink2.mk file for a mythical package foo +follows: +</p> +<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre>BUILDLINK_PACKAGES+= foo +BUILDLINK_PKGBASE.foo= foo +BUILDLINK_DEPENDS.foo?= foo>=1.0 +BUILDLINK_PKGSRCDIR.foo?= ../../category/foo + +EVAL_PREFIX+= BUILDLINK_PREFIX.foo=foo +BUILDLINK_PREFIX.foo_DEFAULT= ${LOCALBASE} +BUILDLINK_FILES.foo= include/foo.h +BUILDLINK_FILES.foo+= include/bar.h +BUILDLINK_FILES.foo+= lib/libfoo.* + +BUILDLINK_TARGETS+= foo-buildlink + +foo-buildlink: _BUILDLINK_USE</pre></td></tr></table> +<p> +The first section controls how the dependency on foo is added. The +dependency is constructed from four parts: +</p> +<div class="orderedlist"><ol type="1"> +<li><p> + <tt class="varname">BUILDLINK_PACKAGES</tt> is the global list of packages + for which dependencies will be added by buildlink2; +</p></li> +<li><p> + <tt class="varname">BUILDLINK_DEPENDS.foo</tt> is the actual dependency + recorded in the installed package; +</p></li> +<li><p> + <tt class="varname">BUILDLINK_PKGSRCDIR.foo</tt> is the location of the + foo pkgsrc directory; +</p></li> +<li><p> + <tt class="varname">BUILDLINK_DEPMETHOD.foo</tt> (not shown above) controls + whether we use <tt class="varname">BUILD_DEPENDS</tt> or + <tt class="varname">DEPENDS</tt> to add the foo dependency, where the + full dependency is added if + <tt class="varname">BUILDLINK_DEPMETHOD.foo</tt> contains “<span class="quote">full</span>”. +</p></li> +</ol></div> +<p> +The second section controls which files are linked into +<tt class="varname">BUILDLINK_DIR</tt>: +</p> +<div class="orderedlist"><ol type="1"> +<li><p> + <tt class="varname">BUILDLINK_PREFIX.foo</tt> is the installation prefix of + the package which we derive by using <tt class="varname">EVAL_PREFIX</tt>; +</p></li> +<li><p> + <tt class="varname">BUILDLINK_FILES.foo</tt> is a list of files (shell globs + allowed) relative to the <tt class="varname">BUILDLINK_PREFIX.foo</tt> + directory and will be symlinked into <tt class="varname">BUILDLINK_DIR</tt>; +</p></li> +<li><p> + <tt class="varname">BUILDLINK_FILES_CMD.foo</tt> (not shown above) is a + shell pipeline that outputs a list of files relative to the + <tt class="varname">BUILDLINK_PREFIX.foo</tt> directory and will be symlinked + into <tt class="varname">BUILDLINK_DIR</tt>. +</p></li> +</ol></div> +<p> +The remaining parts create the “<span class="quote">foo-buildlink</span>” target that +actually performs the symlinking and adds the +“<span class="quote">foo-buildlink</span>” target to +<tt class="varname">BUILDLINK_TARGETS</tt>, which is the global list of targets +to execute at do-buildlink time. +</p> +</div> +</div> +<div class="chapter" lang="en"> +<div class="titlepage"> +<div><div><h2 class="title"> +<a name="debug"></a>Chapter 10. Debugging</h2></div></div> +<div></div> +</div> +<p> +To check out all the gotchas when building a package, here are the steps +that I do in order to get a package working. Please note this is basically +the same as what was explained in the previous sections, only with some +debugging aids. +</p> +<div class="itemizedlist"><ul type="disc"> +<li><p> +Be sure to set <tt class="varname">PKG_DEVELOPER=1</tt> in <tt class="filename">/etc/mk.conf</tt> +</p></li> +<li> +<p> +Install <a xmlns:html="http://www.w3.org/1999/xhtml" href="ftp://ftp.netbsd.org/pub/NetBSD/packages/pkgsrc/pkgtools/url2pkg/README.html" class="pkgname">pkgtools/url2pkg</a> and run +</p> +<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre><tt class="prompt">#</tt> <b class="userinput"><tt>url2pkg http://www.example.com/path/to/distfile.tar.gz</tt></b></pre></td></tr></table> +</li> +<li><p> +Edit the <tt class="filename">Makefile</tt> as requested. +</p></li> +<li><p>Fill in <tt class="filename">DESCR</tt> +</p></li> +<li><p> +Run <b class="command">make configure</b> +</p></li> +<li><p> +Add any dependencies glimpsed from the configure step to the +package's <tt class="filename">Makefile</tt>. +</p></li> +<li> +<p> +Make the package compile, doing multiple rounds of +</p> +<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre><tt class="prompt">#</tt> <b class="userinput"><tt>make</tt></b> +<tt class="prompt">#</tt> <b class="userinput"><tt>pkgvi ${WRKSRC}/some/file/that/does/not/compile</tt></b> +<tt class="prompt">#</tt> <b class="userinput"><tt>mkpatches</tt></b> +<tt class="prompt">#</tt> <b class="userinput"><tt>patchdiff</tt></b> +<tt class="prompt">#</tt> <b class="userinput"><tt>mv ${WRKDIR}/.newpatches/* patches</tt></b> +<tt class="prompt">#</tt> <b class="userinput"><tt>make mps</tt></b> +<tt class="prompt">#</tt> <b class="userinput"><tt>make clean</tt></b></pre></td></tr></table> +<p> +Doing as non-root user will ensure that no files are modified that +shouldn't be, especially during the build phase. +</p> +</li> +<li><p> +Look at <tt class="filename">Makefile</tt>, fix if necessary; see <a href="#components.Makefile" title="5.1. Makefile">Section 5.1, “Makefile”</a>. +</p></li> +<li> +<p> +Generate a <tt class="filename">PLIST</tt>: +</p> +<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre><tt class="prompt">#</tt> <b class="userinput"><tt>make install</tt></b> +<tt class="prompt">#</tt> <b class="userinput"><tt>make print-PLIST > PLIST</tt></b> +<tt class="prompt">#</tt> <b class="userinput"><tt>make deinstall</tt></b> +<tt class="prompt">#</tt> <b class="userinput"><tt>make install</tt></b> +<tt class="prompt">#</tt> <b class="userinput"><tt>make deinstall</tt></b></pre></td></tr></table> +<p> +You usually need to be root to do this. Look if there are any files left: +</p> +<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre><tt class="prompt">#</tt> <b class="userinput"><tt>make print-PLIST</tt></b></pre></td></tr></table> +<p> +If this reveals any files that are missing in +<tt class="filename">PLIST</tt>, add them. +</p> +</li> +<li> +<p> +Now that the <tt class="filename">PLIST</tt> is OK, install the package again +and make a binary package: +</p> +<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre><tt class="prompt">#</tt> <b class="userinput"><tt>make reinstall && make package</tt></b></pre></td></tr></table> +</li> +<li> +<p> +Delete the installed package: +</p> +<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre><tt class="prompt">#</tt> <b class="userinput"><tt>pkg_delete blub</tt></b></pre></td></tr></table> +</li> +<li> +<p> +Repeat the above find command, which shouldn't find anything now: +</p> +<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre><tt class="prompt">#</tt> <b class="userinput"><tt>make print-PLIST</tt></b></pre></td></tr></table> +</li> +<li> +<p> +Reinstall the binary package: +</p> +<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre><tt class="prompt">#</tt> <b class="userinput"><tt>pkgadd .../blub.tgz</tt></b></pre></td></tr></table> +</li> +<li><p> +Play with it. Make sure everything works. +</p></li> +<li> +<p> +Run <b class="command">pkglint</b> from <a xmlns:html="http://www.w3.org/1999/xhtml" href="ftp://ftp.netbsd.org/pub/NetBSD/packages/pkgsrc/pkgtools/pkglint/README.html" class="pkgname">pkgtools/pkglint</a>, and fix the +problems it reports. +</p> +<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre><tt class="prompt">#</tt> <b class="userinput"><tt>pkglint</tt></b></pre></td></tr></table> +</li> +<li><p> +Submit (or commit, if you have cvs access); see <a href="#submit" title="Chapter 12. Submitting and Committing">Chapter 12, <i>Submitting and Committing</i></a>. +</p></li> +</ul></div> +</div> +<div class="chapter" lang="en"> +<div class="titlepage"> +<div><div><h2 class="title"> +<a name="features"></a>Chapter 11. FAQs & features of the package system</h2></div></div> +<div></div> +</div> +<div class="toc"> +<p><b>Table of Contents</b></p> +<dl> +<dt>11.1. <a href="#id2952494">Packages using GNU autoconf</a> +</dt> +<dt>11.2. <a href="#id2954262">Other distrib methods than .tar.gz</a> +</dt> +<dt>11.3. <a href="#id2954307">Packages not creating their own subdirectory</a> +</dt> +<dt>11.4. <a href="#id2955763">Custom configuration process</a> +</dt> +<dt>11.5. <a href="#id2955785">Packages not building in their DISTNAME directory</a> +</dt> +<dt>11.6. <a href="#id2955896">How to fetch all distfiles at once</a> +</dt> +<dt>11.7. <a href="#id2956076">How to fetch files from behind a firewall</a> +</dt> +<dt>11.8. <a href="#id2956098">If your patch contains an RCS ID</a> +</dt> +<dt>11.9. <a href="#id2956116">How to pull in variables from /etc/mk.conf</a> +</dt> +<dt>11.10. <a href="#id2956180">Is there a mailing list for pkg-related discussion?</a> +</dt> +<dt>11.11. <a href="#id2956204">How do I tell make fetch to do passive FTP?</a> +</dt> +<dt>11.12. <a href="#id2956350">Dependencies on other packages</a> +</dt> +<dt>11.13. <a href="#id2956571">Conflicts with other packages</a> +</dt> +<dt>11.14. <a href="#id2956642">Software which has a WWW Home Page</a> +</dt> +<dt>11.15. <a href="#id2956667">How to handle modified distfiles with the 'old' name</a> +</dt> +<dt>11.16. <a href="#id2956764">What does "Don't know how to make /usr/share/tmac/tmac.andoc" mean?</a> +</dt> +<dt>11.17. <a href="#id2956809">How to handle incrementing versions when fixing an existing +package</a> +</dt> +<dt>11.18. <a href="#id2956956">Could not find bsd.own.mk - what's wrong?</a> +</dt> +<dt>11.19. <a href="#id2957027">Restricted packages</a> +</dt> +<dt>11.20. <a href="#id2957213">Packages using (n)curses</a> +</dt> +<dt>11.21. <a href="#id2957255">Automated security check</a> +</dt> +<dt>11.22. <a href="#id2957425">What's the proper way to create an account from a package?</a> +</dt> +<dt>11.23. <a href="#id2957593">How to handle compiler bugs</a> +</dt> +<dt>11.24. <a href="#features.info-files">Packages providing info files</a> +</dt> +<dt>11.25. <a href="#id2957793">Packages whose distfiles aren't available for plain downloading</a> +</dt> +<dt>11.26. <a href="#id2957953">Configuration files handling and placement</a> +</dt> +<dt>11.27. <a href="#id2958470">Packages providing login shells</a> +</dt> +<dt>11.28. <a href="#id2958558">Packages providing locale catalogues</a> +</dt> +<dt>11.29. <a href="#id2958592">Using 'sudo' with pkgsrc</a> +</dt> +<dt>11.30. <a href="#id2958621">Packages containing perl scripts</a> +</dt> +<dt>11.31. <a href="#id2958648">Packages that cannot or should not be built</a> +</dt> +</dl> +</div> +<div class="sect1" lang="en"> +<div class="titlepage"> +<div><div><h2 class="title" style="clear: both"> +<a name="id2952494"></a>11.1. Packages using GNU autoconf</h2></div></div> +<div></div> +</div> +<p> +If your package uses GNU autoconf created configure scripts, add the following +to your package's <tt class="filename">Makefile</tt>: +</p> +<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre>GNU_CONFIGURE= yes</pre></td></tr></table> +<p> +Note that this appends “<span class="quote">--prefix=${PREFIX}</span>” to +<tt class="varname">CONFIGURE_ARGS</tt>, so you don't +have to do that yourself, but may not be desired. +</p> +</div> +<div class="sect1" lang="en"> +<div class="titlepage"> +<div><div><h2 class="title" style="clear: both"> +<a name="id2954262"></a>11.2. Other distrib methods than .tar.gz</h2></div></div> +<div></div> +</div> +<p> +If your package uses a different distribution method from +<tt class="filename">.tar.gz</tt>, take a +look at the package for <a xmlns:html="http://www.w3.org/1999/xhtml" href="ftp://ftp.netbsd.org/pub/NetBSD/packages/pkgsrc/editors/sam/README.html" class="pkgname">editors/sam</a>, which uses a gzipped shell archive +(shar), but the quick solution is to set +<tt class="varname">EXTRACT_SUFX</tt> to the name after the +<tt class="varname">DISTNAME</tt> field, and add the following to your +package's <tt class="filename">Makefile</tt>: +</p> +<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre>EXTRACT_SUFX= .msg.gz +EXTRACT_CMD= zcat +EXTRACT_BEFORE_ARGS= +EXTRACT_AFTER_ARGS= |sh</pre></td></tr></table> +</div> +<div class="sect1" lang="en"> +<div class="titlepage"> +<div><div><h2 class="title" style="clear: both"> +<a name="id2954307"></a>11.3. Packages not creating their own subdirectory</h2></div></div> +<div></div> +</div> +<p> +Your package doesn't create a subdirectory for itself (like GNU software +does, for instance), but extracts itself in the current directory: see +<a xmlns:html="http://www.w3.org/1999/xhtml" href="ftp://ftp.netbsd.org/pub/NetBSD/packages/pkgsrc/editors/sam/README.html" class="pkgname">editors/sam</a> again, but the quick answer is: +</p> +<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre>WRKSRC= ${WRKDIR}</pre></td></tr></table> +<p> +Please note that the old: +</p> +<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre>NO_WRKSUBDIR= yes</pre></td></tr></table> +<p> +has been deprecated and should not be used. +</p> +</div> +<div class="sect1" lang="en"> +<div class="titlepage"> +<div><div><h2 class="title" style="clear: both"> +<a name="id2955763"></a>11.4. Custom configuration process</h2></div></div> +<div></div> +</div> +<p> +Your package uses a weird Configure script, eg. +<a xmlns:html="http://www.w3.org/1999/xhtml" href="ftp://ftp.netbsd.org/pub/NetBSD/packages/pkgsrc/sysutils/top/README.html" class="pkgname">sysutils/top</a>. The quick answer is: +</p> +<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre>HAS_CONFIGURE= yes +CONFIGURE_SCRIPT= Configure +CONFIGURE_ARGS+= netbsd13</pre></td></tr></table> +</div> +<div class="sect1" lang="en"> +<div class="titlepage"> +<div><div><h2 class="title" style="clear: both"> +<a name="id2955785"></a>11.5. Packages not building in their DISTNAME directory</h2></div></div> +<div></div> +</div> +<p> +Your package builds in a different directory from its base +<tt class="varname">DISTNAME</tt> (see <a xmlns:html="http://www.w3.org/1999/xhtml" href="ftp://ftp.netbsd.org/pub/NetBSD/packages/pkgsrc/lang/tcl/README.html" class="pkgname">lang/tcl</a> and +<a xmlns:html="http://www.w3.org/1999/xhtml" href="ftp://ftp.netbsd.org/pub/NetBSD/packages/pkgsrc/x11/tk/README.html" class="pkgname">x11/tk</a>). +</p> +<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre>WRKSRC= ${WRKDIR}/${DISTNAME}/unix</pre></td></tr></table> +</div> +<div class="sect1" lang="en"> +<div class="titlepage"> +<div><div><h2 class="title" style="clear: both"> +<a name="id2955896"></a>11.6. How to fetch all distfiles at once</h2></div></div> +<div></div> +</div> +<p> +You would like to download all the distfiles in a single batch from work or +university, where you can't run a <b class="command">make fetch</b>. There +is an archive of distfiles on <a href="ftp://ftp.NetBSD.org/pub/NetBSD/packages/distfiles/" target="_top">ftp.NetBSD.org</a>, +but downloading the entire directory may not be appropriate. +</p> +<p> +The answer here is to do a <b class="command">make fetch-list</b> in +<tt class="filename">/usr/pkgsrc</tt>, carry the +resulting list to your machine at work/school and use it there If you don't +have a NetBSD-compatible ftp(1) (like lukemftp) at work, don't forget to +set <tt class="varname">FETCH_CMD</tt> to something that fetches an URL: +</p> +<p> +At home: +</p> +<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre><tt class="prompt">%</tt> <b class="userinput"><tt>cd /usr/pkgsrc</tt></b> +<tt class="prompt">%</tt> <b class="userinput"><tt>make fetch-list FETCH_CMD=wget DISTDIR=/tmp/distfiles >/tmp/fetch.sh</tt></b> +<tt class="prompt">%</tt> <b class="userinput"><tt>scp /tmp/fetch.sh work:/tmp</tt></b></pre></td></tr></table> +<p> +At work: +</p> +<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre><tt class="prompt">%</tt> <b class="userinput"><tt>sh /tmp/fetch.sh</tt></b></pre></td></tr></table> +<p> +then tar up <tt class="filename">/tmp/distfiles</tt> and take it home. +</p> +<p> +If you have a machine running NetBSD, and you want to get +<span class="emphasis"><em>all</em></span> distfiles +(even ones that aren't for your machine architecture), you can do so by +using the above-mentioned <b class="command">make fetch-list</b> approach, or +fetch the distfiles directly by running: +</p> +<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre><tt class="prompt">%</tt> <b class="userinput"><tt>make mirror-distfiles</tt></b></pre></td></tr></table> +<p> +If you even decide to ignore <tt class="varname">NO_{SRC,BIN}_ON_{FTP,CDROM}</tt>, +then you can get everything by running: +</p> +<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre><tt class="prompt">%</tt> <b class="userinput"><tt>make fetch NO_SKIP=yes</tt></b></pre></td></tr></table> +</div> +<div class="sect1" lang="en"> +<div class="titlepage"> +<div><div><h2 class="title" style="clear: both"> +<a name="id2956076"></a>11.7. How to fetch files from behind a firewall</h2></div></div> +<div></div> +</div> +<p> +If you are sitting behind a firewall which does not allow direct connections +to Internet hosts (i.e. non-NAT), you may specify the relevant proxy hosts. +This is done using an environment variable in the form of a URL +e.g. in Amdahl, the machine “<span class="quote">orpheus.amdahl.com</span>” is one of +the firewalls, and it uses port 80 as the proxy port number. So the proxy +environment variables are: +</p> +<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre>ftp_proxy=ftp://orpheus.amdahl.com:80/ +http_proxy=http://orpheus.amdahl.com:80/</pre></td></tr></table> +</div> +<div class="sect1" lang="en"> +<div class="titlepage"> +<div><div><h2 class="title" style="clear: both"> +<a name="id2956098"></a>11.8. If your patch contains an RCS ID</h2></div></div> +<div></div> +</div> +<p> +See <a href="#components.patches" title="5.3. patches/*">Section 5.3, “patches/*”</a> for information on how to +remove RCS IDs from patch files. +</p> +</div> +<div class="sect1" lang="en"> +<div class="titlepage"> +<div><div><h2 class="title" style="clear: both"> +<a name="id2956116"></a>11.9. How to pull in variables from /etc/mk.conf</h2></div></div> +<div></div> +</div> +<p> +The problem with package-defined variables that can be overridden via +<tt class="varname">MAKECONF</tt> or <tt class="filename">/etc/mk.conf</tt> is that make(1) expands a variable as it is +used, but evaluates preprocessor like statements (.if, .ifdef and +.ifndef) as they are read. So, to use any variable (which may be set +in <tt class="filename">/etc/mk.conf</tt>) in one of the .if* statements, the file +<tt class="filename">/etc/mk.conf</tt> +must be included before that .if* statement. +</p> +<p> +Rather than have a number of ad-hoc ways of including +<tt class="filename">/etc/mk.conf</tt>, +should it exist, or <tt class="varname">MAKECONF</tt>, should it exist, include the +<tt class="filename">pkgsrc/mk/bsd.prefs.mk</tt> file in the package Makefile before any +preprocessor-like .if, .ifdef, or .ifndef statements: +</p> +<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre>.include "../../mk/bsd.prefs.mk" + +.if defined(USE_MENUS) + ... +.endif</pre></td></tr></table> +</div> +<div class="sect1" lang="en"> +<div class="titlepage"> +<div><div><h2 class="title" style="clear: both"> +<a name="id2956180"></a>11.10. Is there a mailing list for pkg-related discussion?</h2></div></div> +<div></div> +</div> +<p> +Yes, <tt class="email"><<a href="mailto:tech-pkg@NetBSD.org">tech-pkg@NetBSD.org</a>></tt> is the list for discussing package +related issues. To subscribe do: +</p> +<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre>% echo subscribe tech-pkg | mail majordomo@NetBSD.org</pre></td></tr></table> +</div> +<div class="sect1" lang="en"> +<div class="titlepage"> +<div><div><h2 class="title" style="clear: both"> +<a name="id2956204"></a>11.11. How do I tell <b class="command">make fetch</b> to do passive FTP?</h2></div></div> +<div></div> +</div> +<p> +This depends on which utility is used to retrieve distfiles. From +<tt class="filename">bsd.pkg.mk</tt>, <tt class="varname">FETCH_CMD</tt> is assigned +the first available command from the following list: +</p> +<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre>/usr/bin/fetch +${LOCALBASE}/bsd/bin/ftp +/usr/bin/ftp</pre></td></tr></table> +<p> +On a default NetBSD install, this will be +<tt class="filename">/usr/bin/ftp</tt>, which automatically +tries passive connections first, and falls back to active connections if the +server refuses to do passive. For the other tools, add the following to your +<tt class="filename">/etc/mk.conf</tt> file: +<tt class="varname">PASSIVE_FETCH=1</tt>. +</p> +<p> +Having that option present will prevent +<tt class="filename">/usr/bin/ftp</tt> from falling back to +active transfers. +</p> +</div> +<div class="sect1" lang="en"> +<div class="titlepage"> +<div><div><h2 class="title" style="clear: both"> +<a name="id2956350"></a>11.12. Dependencies on other packages</h2></div></div> +<div></div> +</div> +<p> +Your package may depend on some other package being present - and there are +various ways of expressing this dependency. NetBSD supports the +<tt class="varname">BUILD_DEPENDS</tt> and <tt class="varname">DEPENDS</tt> definitions, +as well as dependencies via +<tt class="filename">buildlink2.mk</tt> (see <a href="#buildlink2" title="Chapter 9. buildlink2 methodology">Chapter 9, <i>buildlink2 methodology</i></a>). +</p> +<p> +The basic difference between the two definitions is as follows: The +<tt class="varname">DEPENDS</tt> definition registers that pre-requisite in the binary package, +whilst the <tt class="varname">BUILD_DEPENDS</tt> definition does not. +</p> +<p> +This means that if you only need a package present whilst you are building, +it should be noted as a <tt class="varname">BUILD_DEPENDS</tt>. +</p> +<p> +The format for a <tt class="varname">BUILD_DEPENDS</tt> and a +<tt class="varname">DEPENDS</tt> definition is: +</p> +<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre><pre-req-package-name>:../../<category>/<pre-req-package></pre></td></tr></table> +<p> +Please note that the “<span class="quote">pre-req-package-name</span>” may include any of the wildcard +version numbers recognised by pkg_info(1). +</p> +<div class="orderedlist"><ol type="1"> +<li> +<p> +If your package needs to use another package to build itself, this +is specified using the <tt class="varname">BUILD_DEPENDS</tt> definition. +</p> +<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre>BUILD_DEPENDS+= autoconf-2.13:../../devel/autoconf</pre></td></tr></table> +</li> +<li> +<p> +If your package needs a library with which to link, this is specified +using the <tt class="varname">DEPENDS</tt> definition. An example of this is +the <a xmlns:html="http://www.w3.org/1999/xhtml" href="ftp://ftp.netbsd.org/pub/NetBSD/packages/pkgsrc/print/lyx/README.html" class="pkgname">print/lyx</a> +package, which uses the xpm library, version 3.4j to build. +</p> +<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre>DEPENDS+= xpm-3.4j:../../graphics/xpm</pre></td></tr></table> +<p> +You can also use wildcards in package dependences: +</p> +<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre>DEPENDS+= xpm-[0-9]*:../../graphics/xpm</pre></td></tr></table> +<p> +Note that such wildcard dependencies are retained when creating binary +packages. The dependency is checked when installing the binary +package and any package which matches the pattern will be used. +Wildcard dependencies should be used with care. +</p> +<p> +The -[0-9]* should be used instead of -* to avoid potentially +ambiguous matches such as tk-postgresql matching a tk-* +<tt class="varname">DEPENDS</tt>. +</p> +</li> +<li> +<p> +If your package needs some executable to be able to run correctly, this +is specified using the <tt class="varname">DEPENDS</tt> definition. The +<a xmlns:html="http://www.w3.org/1999/xhtml" href="ftp://ftp.netbsd.org/pub/NetBSD/packages/pkgsrc/print/lyx/README.html" class="pkgname">print/lyx</a> package needs +to be able to execute the latex binary from the teTeX package when it runs, +and that is specified: +</p> +<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre>DEPENDS+= teTeX-[0-9]*:../../print/teTeX</pre></td></tr></table> +<p> +The comment about wildcard dependencies from previous paragraph +applies here, too. +</p> +</li> +</ol></div> +<p> +If your package needs files from another package to build, see the +first part of the “<span class="quote">do-configure</span>” target +<a xmlns:html="http://www.w3.org/1999/xhtml" href="ftp://ftp.netbsd.org/pub/NetBSD/packages/pkgsrc/print/ghostscript5/README.html" class="pkgname">print/ghostscript5</a> package +(it relies on the jpeg sources being present in source form during the +build): +</p> +<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre>if [ ! -e ${_PKGSRCDIR}/graphics/jpeg/${WRKDIR:T}/jpeg-6b ]; then \ + cd ${_PKGSRCDIR}/../../graphics/jpeg && ${MAKE} extract; \ +fi</pre></td></tr></table> +<p> +If you build any other packages that way, please make sure the working +files are deleted too when this package's working files are cleaned up. +The easiest way to do so is by adding a pre-clean target: +</p> +<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre>pre-clean: + cd ${_PKGSRCDIR}/../../graphics/jpeg && ${MAKE} clean</pre></td></tr></table> +<p> +Please also note the <tt class="varname">BUILD_USES_MSGFMT</tt> and +<tt class="varname">BUILD_USES_GETTEXT_M4</tt> definitions, +which are provided as convenience definitions. The former works out whether +msgfmt(1) is part of the base system, and, if it isn't, installs the +<a xmlns:html="http://www.w3.org/1999/xhtml" href="ftp://ftp.netbsd.org/pub/NetBSD/packages/pkgsrc/devel/gettext/README.html" class="pkgname">devel/gettext</a> package. The latter adds a build dependency on either an +installed version of an older gettext package, or if it isn't, installs the +<a xmlns:html="http://www.w3.org/1999/xhtml" href="ftp://ftp.netbsd.org/pub/NetBSD/packages/pkgsrc/devel/gettext-m4/README.html" class="pkgname">devel/gettext-m4</a> package. +</p> +</div> +<div class="sect1" lang="en"> +<div class="titlepage"> +<div><div><h2 class="title" style="clear: both"> +<a name="id2956571"></a>11.13. Conflicts with other packages</h2></div></div> +<div></div> +</div> +<p> +Your package may conflict with other packages a user might already have +installed on his system, e.g. if your package installs the same set of +files like another package in our pkgsrc tree. +</p> +<p> +In this case you can set <tt class="varname">CONFLICTS</tt> to a space separated +list of packages (including version string) your package conflicts with. +</p> +<p> +For example <a xmlns:html="http://www.w3.org/1999/xhtml" href="ftp://ftp.netbsd.org/pub/NetBSD/packages/pkgsrc/x11/Xaw3d/README.html" class="pkgname">x11/Xaw3d</a> and +<a xmlns:html="http://www.w3.org/1999/xhtml" href="ftp://ftp.netbsd.org/pub/NetBSD/packages/pkgsrc/x11/Xaw-Xpm/README.html" class="pkgname">x11/Xaw-Xpm</a> install provide the +same shared library, thus you set in +<tt class="filename">pkgsrc/x11/Xaw3d/Makefile</tt>: +</p> +<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre>CONFLICTS= Xaw-Xpm-[0-9]*</pre></td></tr></table> +<p> +and in <tt class="filename">pkgsrc/x11/Xaw-Xpm/Makefile</tt>: +</p> +<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre>CONFLICTS= Xaw3d-[0-9]*</pre></td></tr></table> +<p> +Packages will automatically conflict with other packages with the name prefix +and a different version string. “<span class="quote">Xaw3d-1.5</span>” e.g. will automatically conflict +with the older version “<span class="quote">Xaw3d-1.3</span>”. +</p> +</div> +<div class="sect1" lang="en"> +<div class="titlepage"> +<div><div><h2 class="title" style="clear: both"> +<a name="id2956642"></a>11.14. Software which has a WWW Home Page</h2></div></div> +<div></div> +</div> +<p> +The NetBSD packages system now supports a variable called +<tt class="varname">HOMEPAGE</tt>. +If the software being packaged has a home page, the Makefile should +include the URL for that page in the <tt class="varname">HOMEPAGE</tt> variable. +The definition of the variable should be placed immediately after the +<tt class="varname">MAINTAINER</tt> variable. +</p> +</div> +<div class="sect1" lang="en"> +<div class="titlepage"> +<div><div><h2 class="title" style="clear: both"> +<a name="id2956667"></a>11.15. How to handle modified distfiles with the 'old' name</h2></div></div> +<div></div> +</div> +<p> +Sometimes authors of a software package make some modifications after the +software was released, and they put up a new distfile without changing the +package's version number. If a package is already in pkgsrc at that time, +the md5 checksum will no longer match. The correct way to work around this +is to update the package's md5 checksum to match the package on the master +site (beware, any mirrors may not be up to date yet!), and to remove the +old distfile from ftp.NetBSD.org's +<tt class="filename">/pub/NetBSD/packages/distfiles</tt> directory. +Furthermore, a mail to the package's author seems appropriate making sure +the distfile was really updated on purpose, and that no trojan horse or so +crept in. +</p> +</div> +<div class="sect1" lang="en"> +<div class="titlepage"> +<div><div><h2 class="title" style="clear: both"> +<a name="id2956764"></a>11.16. What does "Don't know how to make /usr/share/tmac/tmac.andoc" mean?</h2></div></div> +<div></div> +</div> +<p> +When compiling the <a xmlns:html="http://www.w3.org/1999/xhtml" href="ftp://ftp.netbsd.org/pub/NetBSD/packages/pkgsrc/pkgtools/pkg_install/README.html" class="pkgname">pkgtools/pkg_install</a> package, you get the error +from make that it doesn't know how to make +<tt class="filename">/usr/share/tmac/tmac.andoc</tt>? This +indicates that you don't have installed the “<span class="quote">text</span>” set on your machine +(nroff, ...). It is recommended to do that. +</p> +<p> +In the case of the <a xmlns:html="http://www.w3.org/1999/xhtml" href="ftp://ftp.netbsd.org/pub/NetBSD/packages/pkgsrc/pkgtools/pkg_install/README.html" class="pkgname">pkgtools/pkg_install</a> package, you can get +away with setting <tt class="varname">NOMAN=YES</tt> either in the environment +or in <tt class="filename">/etc/mk.conf</tt>. +</p> +</div> +<div class="sect1" lang="en"> +<div class="titlepage"> +<div><div><h2 class="title" style="clear: both"> +<a name="id2956809"></a>11.17. How to handle incrementing versions when fixing an existing +package</h2></div></div> +<div></div> +</div> +<p> +When making fixes to an existing package it can be useful to change +the version number in <tt class="varname">PKGNAME</tt>. To avoid conflicting with +future versions +by the original author, a “<span class="quote">nb1</span>”, “<span class="quote">nb2</span>”, ... suffix +can be used on package +versions by setting <tt class="varname">PKGREVISION=1</tt> (2,. ..). The +“<span class="quote">nb</span>” is treated like a “<span class="quote">.</span>” by the pkg tools. e.g. +</p> +<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre>DISTNAME= foo-17.42 +PKGREVISION= 9</pre></td></tr></table> +<p> +will result in a <tt class="varname">PKGNAME</tt> of “<span class="quote">foo-17.42nb9</span>”. +</p> +<p> +When a new release of the package is released, the +<tt class="varname">PKGREVISION</tt> should be +removed. e.g. on a new minor release of the above package, things should +be like: +</p> +<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre>DISTNAME= foo-17.43</pre></td></tr></table> +</div> +<div class="sect1" lang="en"> +<div class="titlepage"> +<div><div><h2 class="title" style="clear: both"> +<a name="id2956956"></a>11.18. Could not find bsd.own.mk - what's wrong?</h2></div></div> +<div></div> +</div> +<p> +You didn't install the compiler set, <tt class="filename">comp.tgz</tt>, when +you installed your NetBSD machine. Please get it and install it, by +extracting it in <tt class="filename">/</tt>: +</p> +<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre><tt class="prompt">#</tt> <b class="userinput"><tt>cd /</tt></b> +<tt class="prompt">#</tt> <b class="userinput"><tt>tar --unlink -zxvpf .../comp.tgz</tt></b></pre></td></tr></table> +<p> +<tt class="filename">comp.tgz</tt> is part of every NetBSD release. Get +the one that corresponds to your release (determine via +<b class="command">uname -r</b>). +</p> +</div> +<div class="sect1" lang="en"> +<div class="titlepage"> +<div><div><h2 class="title" style="clear: both"> +<a name="id2957027"></a>11.19. Restricted packages</h2></div></div> +<div></div> +</div> +<p> +Some licenses restrict how software may be re-distributed. In order to +satisfy these restrictions, the package system defines five make variables +that can be set to note these restrictions: +</p> +<div class="itemizedlist"><ul type="disc"> +<li> +<p><tt class="varname">RESTRICTED</tt></p> +<p> + This variable should be set whenever a restriction exists + (regardless of its kind). Set this variable to a string + containing the reason for the restriction. +</p> +</li> +<li> +<p><tt class="varname">NO_BIN_ON_CDROM</tt></p> +<p> + Binaries may not be placed on CD-ROM. Set this variable to + <tt class="varname">${RESTRICTED}</tt> whenever a binary package may not + be included on a CD-ROM. +</p> +</li> +<li> +<p><tt class="varname">NO_BIN_ON_FTP</tt></p> +<p> + Binaries may not be placed on an FTP server. Set this + variable to <tt class="varname">${RESTRICTED}</tt> whenever a binary package + may not not be made available on the Internet. +</p> +</li> +<li> +<p><tt class="varname">NO_SRC_ON_CDROM</tt></p> +<p> + Distfiles may not be placed on CD-ROM. Set this variable to + <tt class="varname">${RESTRICTED}</tt> if re-distribution of the source code + or other distfile(s) is not allowed on CD-ROMs. +</p> +</li> +<li> +<p><tt class="varname">NO_SRC_ON_FTP</tt></p> +<p> + Distfiles may not be placed on FTP. Set this variable to + <tt class="varname">${RESTRICTED}</tt> if re-distribution of the source + code or other distfile(s) via the Internet is not allowed. +</p> +</li> +</ul></div> +<p> +Please note that the use of <tt class="varname">NO_PACKAGE</tt>, +<tt class="varname">IGNORE</tt>, <tt class="varname">NO_CDROM</tt>, or other generic +make variables to denote restrictions is deprecated, because they +unconditionally prevent users from generating binary packages! +</p> +</div> +<div class="sect1" lang="en"> +<div class="titlepage"> +<div><div><h2 class="title" style="clear: both"> +<a name="id2957213"></a>11.20. Packages using (n)curses</h2></div></div> +<div></div> +</div> +<p> +Some packages need curses functionality that wasn't present in NetBSD's own +curses prior to 1.4Y. +</p> +<p> +If <tt class="filename">../../devel/ncurses/buildlink2.mk</tt> is included in +a package's <tt class="filename">Makefile</tt>, +then a curses library and headers with ncurses functionality are linked +into <tt class="varname">${BUILDLINK_DIR}</tt> at pre-configure time. If +ncurses is actually required, then define <tt class="varname">USE_NCURSES</tt> +in the package's <tt class="filename">Makefile</tt>. +</p> +</div> +<div class="sect1" lang="en"> +<div class="titlepage"> +<div><div><h2 class="title" style="clear: both"> +<a name="id2957255"></a>11.21. Automated security check</h2></div></div> +<div></div> +</div> +<p> +Please be aware that there can often be bugs in third-party software, +and some of these bugs can leave a machine vulnerable to exploitation +by attackers. In an effort to lessen the exposure, the NetBSD +packages team maintains a database of known-exploits to packages which +have at one time been included in pkgsrc. The database can be +downloaded automatically, and a security audit of all packages +installed on a system can take place. To do this, install the +<a xmlns:html="http://www.w3.org/1999/xhtml" href="ftp://ftp.netbsd.org/pub/NetBSD/packages/pkgsrc/security/audit-packages/README.html" class="pkgname">security/audit-packages</a> package. It has two components: +</p> +<div class="orderedlist"><ol type="1"> +<li> +<p> + “<span class="quote">download-vulnerability-list</span>”, an easy way to download a list of the + security vulnerabilities information. This list is kept up to date by + the NetBSD security officer and the NetBSD packages team, and is + distributed from the NetBSD ftp server: +</p> +<p> +<a href="ftp://ftp.NetBSD.org/pub/NetBSD/packages/distfiles/vulnerabilities" target="_top">ftp://ftp.NetBSD.org/pub/NetBSD/packages/distfiles/vulnerabilities</a> +</p> +</li> +<li><p> + “<span class="quote">audit-packages</span>”, an easy way to audit the current machine, checking + each vulnerability which is known. If a vulnerable package is + installed, it will be shown by output to stdout, including a + description of the type of vulnerability, and a URL containing more + information. +</p></li> +</ol></div> +<p> +Use of the audit-packages package is strongly recommended. +</p> +<p> +The following message is displayed as part of the audit-packages +installation procedure: +</p> +<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre> +====================================================================== +You may wish to have the vulnerabilities file downloaded daily so that +it remains current. This may be done by adding an appropriate entry +to the root users crontab(5) entry. For example the entry + +# download vulnerabilities file +0 3 * * * ${PREFIX}/sbin/download-vulnerability-list >/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 +====================================================================== +</pre></td></tr></table> +<p> +Note to package developers: When a vulnerability is found, this should be +noted in +<tt class="filename">localsrc/security/advisories/pkg-vulnerabilities</tt>, and after the +commit of that file, it should be copied to +<tt class="filename">/pub/NetBSD/packages/distfiles/vulnerabilities</tt> on ftp.NetBSD.org. +</p> +</div> +<div class="sect1" lang="en"> +<div class="titlepage"> +<div><div><h2 class="title" style="clear: both"> +<a name="id2957425"></a>11.22. What's the proper way to create an account from a package?</h2></div></div> +<div></div> +</div> +<p> +There are two make variables used to control the creation of package-specific +groups and users at pre-install time. The first is +<tt class="varname">PKG_GROUPS</tt>, which is a +list of group[:groupid] elements, where the groupid is optional. The second +is <tt class="varname">PKG_USERS</tt>, which is a list of elements of the form: +</p> +<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre>user:group[:[userid][:[description][:[home][:shell]]]]</pre></td></tr></table> +<p> +where only the user and group are required, the rest being optional. A +simple example is: +</p> +<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre>PKG_GROUPS= foogroup +PKG_USERS= foouser:foogroup</pre></td></tr></table> +<p> +A more complex example is that creates two groups and two users is: +</p> +<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre>PKG_GROUPS= group1 group2:1005 +PKG_USERS= first:group1::First\\ User \ + second:group2::Second\\ User:/home/second:${SH}</pre></td></tr></table> +<p> +By default, a new user will have home directory +<tt class="filename">/nonexistent</tt>, and login shell +<tt class="filename">/sbin/nologin</tt> unless they are specified as part of +the user element. +</p> +<p> +The package Makefile must also include +<tt class="filename">../../mk/bsd.pkg.install.mk</tt> prior to +the inclusion of <tt class="filename">bsd.pkg.mk</tt>. This will cause the users and groups to be +created at pre-install time, and the admin will be prompted to remove them at +post-deinstall time. Automatic creation of the users and groups can be +toggled on and off by setting the environment variable +<tt class="varname">PKG_CREATE_USERGROUP</tt> prior to package installation. +</p> +</div> +<div class="sect1" lang="en"> +<div class="titlepage"> +<div><div><h2 class="title" style="clear: both"> +<a name="id2957593"></a>11.23. How to handle compiler bugs</h2></div></div> +<div></div> +</div> +<p> +Some source files trigger bugs in the compiler, based on combinations +of compiler version and architecture and almost always relation to +optimisation being enabled. Common symptoms are gcc internal errors +or never finishing compiling a file. +</p> +<p> +Typically a workaround involves testing the <tt class="varname">MACHINE_ARCH</tt> +and compiler version, disabling optimisation for that +file/<tt class="varname">MACHINE_ARCH</tt>/compiler +combination, and documenting it in <tt class="filename">doc/HACKS</tt>. See +<tt class="filename">doc/HACKS</tt> for examples. +</p> +</div> +<div class="sect1" lang="en"> +<div class="titlepage"> +<div><div><h2 class="title" style="clear: both"> +<a name="features.info-files"></a>11.24. Packages providing info files</h2></div></div> +<div></div> +</div> +<p> +Some packages install info files or use the “<span class="quote">makeinfo</span>” +or “<span class="quote">install-info</span>” commands. Each info file: +</p> +<div class="itemizedlist"><ul type="disc"> +<li>is considered to be installed in the directory + <tt class="filename">${PREFIX}/${INFO_DIR}</tt>,</li> +<li>is registered in the Info directory file + <tt class="filename">${PREFIX}/${INFO_DIR}/dir</tt>,</li> +<li>and must be listed as a filename in the + <tt class="varname">INFO_FILES</tt> variable in the package + Makefile.</li> +</ul></div> +<p> +</p> +<p> +<tt class="varname">INFO_DIR</tt> defaults to “<span class="quote">info</span>” and can be +overridden in the package Makefile. <tt class="filename">INSTALL</tt> and +<tt class="filename">DEINSTALL</tt> scripts will be generated for handling +registration of the info files in the Info directory file. The command +“<span class="quote">install-info</span>” used for the info files registration is +either provided by the system, or by a special purpose package +automatically added as dependency if needed. +</p> +<p> +A package which need the “<span class="quote">makeinfo</span>” command at build +time must define the variable <tt class="varname">USE_MAKEINFO</tt> in its +Makefile. If a minimum version of the “<span class="quote">makeinfo</span>” command +is needed it should be noted with the <tt class="varname">TEXINFO_REQD</tt> +variable in the package Makefile. By default, a minimum version of 3.12 +is required. If the system does not provide a “<span class="quote">makeinfo</span>” +command or if it does not match the required minimum, a build dependency +on the <a xmlns:html="http://www.w3.org/1999/xhtml" href="ftp://ftp.netbsd.org/pub/NetBSD/packages/pkgsrc/devel/gtexinfo/README.html" class="pkgname">devel/gtexinfo</a> package is added automatically. +</p> +<p> +The installation process of the software provided by the package must not +use “<span class="quote">install-info</span>”, as the registration of info files +is the task of the package INSTALL sript, and it must use +the right “<span class="quote">makeinfo</span>”. +</p> +<p> +If the package use buildlink2 framework no special action should be needed +to achieve this goal. +</p> +<p> +If the package does not use the buildlink2 framework patch files are likely +to be needed so the build and installation process of the software +picks up the <span class="emphasis"><em>possibly dummy</em></span> values of +<tt class="varname">INSTALL_INFO</tt> and <tt class="varname">MAKEINFO</tt> +variables. +</p> +<div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"> +<h3 class="title">Note</h3> +Temporarily, the variable <tt class="varname">USE_NEW_TEXINFO</tt> must be +defined in the package Makefile. Previously, info files, +“<span class="quote">install-info</span>” and “<span class="quote">makeinfo</span>” +were handled somewhat differently and the two ways will coexist for +a short period of time until all older packages are updated. +</div> +</div> +<div class="sect1" lang="en"> +<div class="titlepage"> +<div><div><h2 class="title" style="clear: both"> +<a name="id2957793"></a>11.25. Packages whose distfiles aren't available for plain downloading</h2></div></div> +<div></div> +</div> +<p> +If you need to download from a dynamic URL you can set +<tt class="varname">DYNAMIC_MASTER_SITES</tt> +and a <b class="command">make fetch</b> will call +<tt class="filename">files/getsite.sh</tt> with the name of each file +to download as an argument, expecting it to output the URL of the directory +from which to download it. <a xmlns:html="http://www.w3.org/1999/xhtml" href="ftp://ftp.netbsd.org/pub/NetBSD/packages/pkgsrc/graphics/ns-cult3d/README.html" class="pkgname">graphics/ns-cult3d</a> is an example of this usage. +</p> +<p> +If the download can't be automated, because the user must submit personal +information to apply for a password, or must pay for the source, or whatever, +you can set <tt class="varname">_FETCH_MESSAGE</tt> to a macro which displays +a message explaining the situation. <tt class="varname">_FETCH_MESSAGE</tt> must +be executable shell commands, not just a message. (Generally, it executes +<tt class="varname">${ECHO}</tt>). As of this writing, the following +packages use this: <a xmlns:html="http://www.w3.org/1999/xhtml" href="ftp://ftp.netbsd.org/pub/NetBSD/packages/pkgsrc/audio/realplayer/README.html" class="pkgname">audio/realplayer</a>, +<a xmlns:html="http://www.w3.org/1999/xhtml" href="ftp://ftp.netbsd.org/pub/NetBSD/packages/pkgsrc/cad/simian/README.html" class="pkgname">cad/simian</a>, <a xmlns:html="http://www.w3.org/1999/xhtml" href="ftp://ftp.netbsd.org/pub/NetBSD/packages/pkgsrc/devel/ipv6socket/README.html" class="pkgname">devel/ipv6socket</a>, +<a xmlns:html="http://www.w3.org/1999/xhtml" href="ftp://ftp.netbsd.org/pub/NetBSD/packages/pkgsrc/emulators/vmare-module/README.html" class="pkgname">emulators/vmare-module</a>, +<a xmlns:html="http://www.w3.org/1999/xhtml" href="ftp://ftp.netbsd.org/pub/NetBSD/packages/pkgsrc/fonts/acroread-jpnfont/README.html" class="pkgname">fonts/acroread-jpnfont</a>, +<a xmlns:html="http://www.w3.org/1999/xhtml" href="ftp://ftp.netbsd.org/pub/NetBSD/packages/pkgsrc/sysutils/storage-manager/README.html" class="pkgname">sysutils/storage-manager</a>, +<a xmlns:html="http://www.w3.org/1999/xhtml" href="ftp://ftp.netbsd.org/pub/NetBSD/packages/pkgsrc/www/ap-aolserver/README.html" class="pkgname">www/ap-aolserver</a>, <a xmlns:html="http://www.w3.org/1999/xhtml" href="ftp://ftp.netbsd.org/pub/NetBSD/packages/pkgsrc/www/openacs/README.html" class="pkgname">www/openacs</a>. Try to be consistent +with them. +</p> +</div> +<div class="sect1" lang="en"> +<div class="titlepage"> +<div><div><h2 class="title" style="clear: both"> +<a name="id2957953"></a>11.26. Configuration files handling and placement</h2></div></div> +<div></div> +</div> +<p> +The global variable <tt class="varname">PKG_SYSCONFBASE</tt> (and some others) +can be set by the system administrator in <tt class="filename">/etc/mk.conf</tt> +to define the place where +configuration files get installed. Therefore, packages must be adapted to +support this feature. Keep in mind that you should only install files that +are strictly necessary in the configuration directory, files that can +go to <tt class="filename">$PREFIX/share</tt> should go there. +</p> +<p> +We will take a look at available variables first +(<tt class="filename">bsd.pkg.mk</tt> contains more +information). <tt class="varname">PKG_SYSCONFDIR</tt> is where the +configuration files for a package +may be found (that is, the full path, e.g. <tt class="filename">/etc</tt> +or <tt class="filename">/usr/pkg/etc</tt>). This +value may be customized in various ways: +</p> +<div class="orderedlist"><ol type="1"> +<li><p> + <tt class="varname">PKG_SYSCONFBASE</tt> is the main config directory under + which all package configuration files are to be found. Users will + typically want to set it to <tt class="filename">/etc</tt>, or accept the + default location of <tt class="filename">$PREFIX/etc</tt>. +</p></li> +<li><p> + <tt class="varname">PKG_SYSCONFSUBDIR</tt> is the subdirectory of + <tt class="varname">PKG_SYSCONFBASE</tt> under which + the configuration files for a particular package may be found. Defaults + to <tt class="varname">${SYSCONFBASE}</tt>. +</p></li> +<li><p> + <tt class="varname">PKG_SYSCONFVAR</tt> is the special suffix used to + distinguish any overriding values for a particular package + (see next item). It defaults to <tt class="varname">${PKGBASE}</tt>, but + for a collection of related packages that should all have the same + <tt class="varname">PKG_SYSCONFDIR</tt> value, it can be set in each of + the package Makefiles to a common value. +</p></li> +<li> +<p> + <tt class="varname">PKG_SYSCONFDIR.${PKG_SYSCONFVAR}</tt> overrides the value of + <tt class="varname">${PKG_SYSCONFDIR}</tt> for packages with the same value + for <tt class="varname">PKG_SYSCONFVAR</tt>. +</p> +<p> + As an example, all the various KDE packages may want to set + <tt class="varname">PKG_SYSCONFVAR</tt> to “<span class="quote">kde</span>” so admins can + set <tt class="varname">PKG_SYSCONFDIR.kde</tt> in + <tt class="filename">/etc/mk.conf</tt> to define where to install KDE + config files. +</p> +</li> +</ol></div> +<p> +Programs' configuration directory should be defined during the configure +stage. Packages that use GNU autoconf can usually do this by using the +“<span class="quote">--sysconfdir</span>” parameter, but this brings some problems as +we will see now. +When you change this pathname in packages, you should not allow them to +install files in that directory directly. Instead they need to install +those files under <tt class="filename">share/examples/${PKGNAME}</tt> so +<tt class="filename">PLIST</tt> can register them. +</p> +<p> +Once you have the required configuration files in place (under the +<tt class="filename">share/examples</tt> directory) the variable +<tt class="varname">CONF_FILES</tt> should be set to copy +them into <tt class="varname">PKG_SYSCONFDIR</tt>. The contents of this variable +is formed by pairs +of filenames; the first element of the pair specifies the file inside the +examples directory (registered by <tt class="filename">PLIST</tt>) and the +second element specifies +the target file. This is done this way to allow binary packages to place +files in the right directory using +<tt class="filename">INSTALL</tt>/<tt class="filename">DEINSTALL</tt> scripts which are +created automatically. The package <tt class="filename">Makefile</tt> must also +include <tt class="filename">../../mk/bsd.pkg.install.mk</tt> prior to the +inclusion of <tt class="filename">bsd.pkg.mk</tt> to use +these automatically generated scripts. The automatic copying of config +files can be toggled by setting the environment variable +<tt class="varname">PKG_CONFIG</tt> prior to package installation. +</p> +<p> +Here is an example, taken from mail/mutt/Makefile: +</p> +<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre>EGDIR= ${PREFIX}/share/doc/mutt/samples +CONF_FILES= ${EGDIR}/Muttrc ${PKG_SYSCONFDIR}/Muttrc</pre></td></tr></table> +<p> +As you can see, this package installs configuration files inside +<tt class="varname">EGDIR</tt>, which are registered by +<tt class="filename">PLIST</tt>. After that, the variable +<tt class="varname">CONF_FILES</tt> lists +the installed file first and then the target file. Users will also get an +automatic message when files are installed using this method. +</p> +</div> +<div class="sect1" lang="en"> +<div class="titlepage"> +<div><div><h2 class="title" style="clear: both"> +<a name="id2958470"></a>11.27. Packages providing login shells</h2></div></div> +<div></div> +</div> +<p> +If the purpose of the package is to provide a login shell, the variable +<tt class="varname">PKG_SHELL</tt> should contain the full pathname of the +shell executable installed by this package. The package +<tt class="filename">Makefile</tt> also must include +<tt class="filename">../../mk/bsd.pkg.install.mk</tt> prior to the inclusion of +<tt class="filename">bsd.pkg.mk</tt> to use the +automatically generated +<tt class="filename">INSTALL</tt>/<tt class="filename">DEINSTALL</tt> scripts. +</p> +<p> +An example taken from shells/zsh: +</p> +<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre>PKG_SHELL= ${PREFIX}/bin/zsh +.include "../../mk/bsd.pkg.install.mk"</pre></td></tr></table> +<p> +The shell is registered into <tt class="filename">/etc/shells</tt> file automatically in the +post-install target by the <tt class="filename">INSTALL</tt> script generated +by <tt class="filename">bsd.pkg.install.mk</tt> and removed in the deinstall +target by the <tt class="filename">DEINSTALL</tt> script. +</p> +</div> +<div class="sect1" lang="en"> +<div class="titlepage"> +<div><div><h2 class="title" style="clear: both"> +<a name="id2958558"></a>11.28. Packages providing locale catalogues</h2></div></div> +<div></div> +</div> +<p> +If the package provides its own locale catalogues, the variable +<tt class="varname">USE_PKGLOCALEDIR</tt> should be defined. It will ensure +that the package's <tt class="filename">Makefile</tt> template files are fixed +and point to the correct locale directories +(which may vary, depending on OS), if necessary. See <a href="#plist.misc" title="6.1. Miscellaneous">Section 6.1, “Miscellaneous”</a> for details about <tt class="varname">PKGLOCALEDIR</tt>. +This functionality is buildlink2-only. +</p> +</div> +<div class="sect1" lang="en"> +<div class="titlepage"> +<div><div><h2 class="title" style="clear: both"> +<a name="id2958592"></a>11.29. Using 'sudo' with pkgsrc</h2></div></div> +<div></div> +</div> +<p> +When installing packages as non-root user and using the just-in-time +su(1) feature of pkgsrc, it can become annoying to type in the root +password for each required package installed. To avoid this, the sudo +package can be used, which does password caching over a limited time. +To use it, install sudo (either as binary package or from +<a xmlns:html="http://www.w3.org/1999/xhtml" href="ftp://ftp.netbsd.org/pub/NetBSD/packages/pkgsrc/security/sudo/README.html" class="pkgname">security/sudo</a>) and then put the following +into your <tt class="filename">/etc/mk.conf</tt>: +</p> +<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre>SU_CMD=/usr/pkg/bin/sudo /bin/sh -c</pre></td></tr></table> +</div> +<div class="sect1" lang="en"> +<div class="titlepage"> +<div><div><h2 class="title" style="clear: both"> +<a name="id2958621"></a>11.30. Packages containing perl scripts</h2></div></div> +<div></div> +</div> +<p> +If your package contains interpreted perl scripts, set +<tt class="varname">REPLACE_PERL</tt> to ensure that the proper interpreter +path is set. <tt class="varname">REPLACE_PERL</tt> should contain a list of +scripts, relative to <tt class="varname">WRKSRC</tt>, that you want adjusted. +</p> +</div> +<div class="sect1" lang="en"> +<div class="titlepage"> +<div><div><h2 class="title" style="clear: both"> +<a name="id2958648"></a>11.31. Packages that cannot or should not be built</h2></div></div> +<div></div> +</div> +<p> +There are several reasons why a package might be instructed to not +build under certain circumstances. If the package builds and runs +on most platforms, the exceptions should be noted with +<tt class="varname">NOT_FOR_PLATFORM</tt>. If the package builds and runs on +a small handful of platforms, set <tt class="varname">ONLY_FOR_PLATFORM</tt> +instead. If the package should be skipped (for example, because it +provides functionality already provided by the system), set +<tt class="varname">PKG_SKIP_REASON</tt> to a descriptive message. If +the package should fail because some preconditions are not met, +set <tt class="varname">PKG_FAIL_REASON</tt> to a descriptive message. +</p> +<p> +<tt class="varname">IGNORE</tt> is deprecated because it didn't provide enough +information to determine whether the build should fail. +</p> +</div> +</div> +<div class="chapter" lang="en"> +<div class="titlepage"> +<div><div><h2 class="title"> +<a name="submit"></a>Chapter 12. Submitting and Committing</h2></div></div> +<div></div> +</div> +<div class="toc"> +<p><b>Table of Contents</b></p> +<dl> +<dt>12.1. <a href="#id2960258">Submitting your packages</a> +</dt> +<dt>12.2. <a href="#id2961824">Committing: Importing a package into CVS</a> +</dt> +<dt>12.3. <a href="#id2962087">Updating a Package to a Newer Version</a> +</dt> +<dt>12.4. <a href="#id2962208">Moving a Package in pkgsrc</a> +</dt> +</dl> +</div> +<div class="sect1" lang="en"> +<div class="titlepage"> +<div><div><h2 class="title" style="clear: both"> +<a name="id2960258"></a>12.1. Submitting your packages</h2></div></div> +<div></div> +</div> +<p> +You have to separate between binary and “<span class="quote">normal</span>” (source) +packages here: +</p> +<div class="itemizedlist"><ul type="disc"> +<li> +<p>precompiled binary packages</p> +<p> + Our policy is that we accept binaries only from NetBSD developers to + guarantee that the packages don't contain any trojan horses etc. + This is not to piss anyone off but rather to protect our users! + You're still free to put up your home-made binary packages and tell + the world where to get them. +</p> +</li> +<li> +<p>packages</p> +<p> + First, check that your package is complete, compiles and runs well; + see <a href="#debug" title="Chapter 10. Debugging">Chapter 10, <i>Debugging</i></a> and the rest of this document. Next, + generate a gzipped + tar-file of all the files needed for the package, preferably with all + files in a single directory. Place this tar-file to a place where the + package maintainers can fetch it using FTP or HTTP (WWW). Finally, + <b class="command">send-pr</b> with category “<span class="quote">pkg</span>”, a + synopsis which includes the package name and version number, a short + description of your package (contents of the <tt class="varname">COMMENT</tt> + variable are OK) and the URL of your tar-file. +</p> +<p> + You will be notified if your PR has been addressed so you can remove + the tar-file. +</p> +<p> + If you want to submit several packages, please send a separate PR for + each one, it's easier for us to track things that way. +</p> +</li> +</ul></div> +</div> +<div class="sect1" lang="en"> +<div class="titlepage"> +<div><div><h2 class="title" style="clear: both"> +<a name="id2961824"></a>12.2. Committing: Importing a package into CVS</h2></div></div> +<div></div> +</div> +<p> + This section is only of interest for NetBSD developers with write + access to the NetBSD pkgsrc repository. Please remember that cvs + imports files relative to the cwd, and that the pathname that you + give the <b class="command">cvs import</b> command is so that it knows where + to place the files in the repository. Newly created packages should be + imported with a vendor tag of “<span class="quote">TNF</span>” and a release tag of + “<span class="quote">pkgsrc-base</span>”, e.g: +</p> +<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre><tt class="prompt">%</tt> <b class="userinput"><tt>cd +.../pkgsrc/<category>/<pkgname></tt></b> +<tt class="prompt">%</tt> <b class="userinput"><tt>cvs import pkgsrc/<category>/<pkgname> TNF pkgsrc-base</tt></b></pre></td></tr></table> +<p> + Remember to move the directory from which you imported out of + the way, or cvs will complain the next time you “<span class="quote">cvs + update</span>” your source tree. Also don't forget to add the new + package to the category's <tt class="filename">Makefile</tt>. +</p> +<p> + The commit message of the initial import should include part of the + <tt class="filename">DESCR</tt> file, so people reading the mailing lists know + what the package is/does. +</p> +<p> + Please note all package updates/additions in + <tt class="filename">pkgsrc/doc/CHANGES</tt>. It's very + important to keep this file up to date and conforming to the existing + format, because it will be used by scripts to automatically update pages on + <a href="http://www.NetBSD.org/" target="_top">www.NetBSD.org</a> and other sites. +</p> +<p> + For new packages, “<span class="quote">cvs import</span>” is preferred to “<span class="quote">cvs + add</span>” because the former gets everything with a single command, + and provides a consistent tag. +</p> +</div> +<div class="sect1" lang="en"> +<div class="titlepage"> +<div><div><h2 class="title" style="clear: both"> +<a name="id2962087"></a>12.3. Updating a Package to a Newer Version</h2></div></div> +<div></div> +</div> +<p> + Please always put a concise, appropriate and relevant summary of the + changes between old and new versions into the commit log when updating + a package. There are various reasons for this: +</p> +<div class="itemizedlist"><ul type="disc"> +<li><p> + A URL is volatile, and can change over time. It may go away completely + or its information may be overwritten by newer information. +</p></li> +<li><p> + Having the change information between old and new versions in our CVS + repository is very useful for people who use either cvs or anoncvs. +</p></li> +<li><p> + Having the change information between old and new versions in our CVS + repository is very useful for people who read the pkgsrc-changes mailing + list, so that they can make tactical decisions about when to upgrade + the package. +</p></li> +</ul></div> +<p> + Please also recognise that, just because a new version of a package + has been released, it should not automatically be upgraded in the CVS + repository. We prefer to be conservative in the packages that are + included in pkgsrc - development or beta packages are not really the + best thing for most places in which pkgsrc is used. Please use your + judgement about what should go into pkgsrc, and bear in mind that + stability is to be preferred above new and possibly untested features. +</p> +</div> +<div class="sect1" lang="en"> +<div class="titlepage"> +<div><div><h2 class="title" style="clear: both"> +<a name="id2962208"></a>12.4. Moving a Package in pkgsrc</h2></div></div> +<div></div> +</div> +<div class="orderedlist"><ol type="1"> +<li>Make a copy of the directory somewhere else.</li> +<li> +<p>Remove all CVS dirs.</p> +<p> + Alternatively to the first two steps you can also do: +</p> +<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre><tt class="prompt">%</tt> <b class="userinput"><tt>cvs -d user@cvs.NetBSD.org:/cvsroot export -D today pkgsrc/category/package</tt></b></pre></td></tr></table> +<p> + and use that for further work. +</p> +</li> +<li>Fix <tt class="varname">CATEGORIES</tt> and any +<tt class="varname">DEPENDS</tt> paths that just did “<span class="quote">../package</span>” +instead of “<span class="quote">../../category/package</span>”. +</li> +<li> +<b class="command">cvs import</b> the modified package in the new +place.</li> +<li> +<p>Check if any package depends on it: +</p> +<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre><tt class="prompt">%</tt> <b class="userinput"><tt>cd /usr/pkgsrc</tt></b> +<tt class="prompt">%</tt> <b class="userinput"><tt>grep /package */*/Makefile* */*/buildlink*</tt></b></pre></td></tr></table> +<p> +</p> +</li> +<li>Fix paths in packages from step 5 to point to new location.</li> +<li> +<b class="command">cvs rm (-f)</b> the package at the old location.</li> +<li>Remove from <tt class="filename">oldcategory/Makefile</tt>.</li> +<li>Add to <tt class="filename">newcategory/Makefile</tt>.</li> +<li> +<p>Commit the changed and removed files:</p> +<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre><tt class="prompt">%</tt> <b class="userinput"><tt>cvs commit oldcategory/package oldcategory/Makefile newcategory/Makefile</tt></b></pre></td></tr></table> +<p> + (and any packages from step 5, of course). +</p> +</li> +</ol></div> +</div> +</div> +<div class="chapter" lang="en"> +<div class="titlepage"> +<div><div><h2 class="title"> +<a name="examples"></a>Chapter 13. A simple example of a package: bison</h2></div></div> +<div></div> +</div> +<div class="toc"> +<p><b>Table of Contents</b></p> +<dl> +<dt>13.1. <a href="#id2961656">files</a> +</dt> +<dt>13.2. <a href="#id2963176">Steps for building, installing, packaging</a> +</dt> +</dl> +</div> +<p> +I checked to find a piece of software that wasn't in the packages +collection, and picked GNU bison. Quite why someone would want to have +<b class="command">bison</b> when Berkeley <b class="command">yacc</b> is already +present in the tree is beyond me, but it's useful for the purposes of +this exercise. +</p> +<div class="sect1" lang="en"> +<div class="titlepage"> +<div><div><h2 class="title" style="clear: both"> +<a name="id2961656"></a>13.1. files</h2></div></div> +<div></div> +</div> +<div class="sect2" lang="en"> +<div class="titlepage"> +<div><div><h3 class="title"> +<a name="id2961662"></a>13.1.1. Makefile</h3></div></div> +<div></div> +</div> +<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre># $NetBSD: pkgsrc.html,v 1.1 2003/06/23 07:41:44 grant Exp $ +# + +DISTNAME= bison-1.25 +CATEGORIES= devel +MASTER_SITES= ${MASTER_SITE_GNU} + +MAINTAINER= thorpej@NetBSD.org +HOMEPAGE= http://www.gnu.org/software/bison/bison.html +COMMENT= GNU yacc clone + +GNU_CONFIGURE= yes +INFO_FILES= bison.info + +.include "../../mk/bsd.pkg.mk"</pre></td></tr></table> +</div> +<div class="sect2" lang="en"> +<div class="titlepage"> +<div><div><h3 class="title"> +<a name="id2961676"></a>13.1.2. DESCR</h3></div></div> +<div></div> +</div> +<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre>GNU version of yacc. Can make re-entrant parsers, and numerous other +improvements. Why you would want this when Berkeley yacc(1) is part +of the NetBSD source tree is beyond me.</pre></td></tr></table> +</div> +<div class="sect2" lang="en"> +<div class="titlepage"> +<div><div><h3 class="title"> +<a name="id2961689"></a>13.1.3. PLIST</h3></div></div> +<div></div> +</div> +<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre>@comment $NetBSD: pkgsrc.html,v 1.1 2003/06/23 07:41:44 grant Exp $ +bin/bison +man/man1/bison.1.gz +info/bison.info +info/bison.info-1 +info/bison.info-2 +info/bison.info-3 +info/bison.info-4 +info/bison.info-5 +share/bison.simple +share/bison.hairy</pre></td></tr></table> +</div> +<div class="sect2" lang="en"> +<div class="titlepage"> +<div><div><h3 class="title"> +<a name="id2961703"></a>13.1.4. Checking a package with <b class="command">pkglint</b></h3></div></div> +<div></div> +</div> +<p> +The NetBSD package system comes with <a xmlns:html="http://www.w3.org/1999/xhtml" href="ftp://ftp.netbsd.org/pub/NetBSD/packages/pkgsrc/pkgtools/pkglint/README.html" class="pkgname">pkgtools/pkglint</a> +which helps to check the contents of these +files. After installation it is quite easy to use, just change to the +directory of the package you wish to examine and execute +<b class="command">pkglint</b>: +</p> +<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre><tt class="prompt">%</tt> <b class="userinput"><tt>pkglint</tt></b> +OK: checking ./DESCR. +OK: checking Makefile. +OK: checking distinfo. +OK: checking patches/patch-aa. +looks fine.</pre></td></tr></table> +<p> +Depending on the supplied command line arguments (see pkglint(1)) more +verbose checks will be performed. Use e.g. <b class="command">pkglint +-v</b> for a very verbose check. +</p> +</div> +</div> +<div class="sect1" lang="en"> +<div class="titlepage"> +<div><div><h2 class="title" style="clear: both"> +<a name="id2963176"></a>13.2. Steps for building, installing, packaging</h2></div></div> +<div></div> +</div> +<p> +Create the directory where the package lives, plus any auxiliary directories: +</p> +<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre><tt class="prompt">#</tt> <b class="userinput"><tt>cd /usr/pkgsrc/lang</tt></b> +<tt class="prompt">#</tt> <b class="userinput"><tt>mkdir bison</tt></b> +<tt class="prompt">#</tt> <b class="userinput"><tt>cd bison</tt></b> +<tt class="prompt">#</tt> <b class="userinput"><tt>mkdir patches</tt></b></pre></td></tr></table> +<p> +Create <tt class="filename">Makefile</tt>, <tt class="filename">DESCR</tt> and +<tt class="filename">PLIST</tt> (see <a href="#components" title="Chapter 5. Package components - files, directories and contents">Chapter 5, <i>Package components - files, directories and contents</i></a>) +then continue with fetching the distfile: +</p> +<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre><tt class="prompt">#</tt> <b class="userinput"><tt>make fetch</tt></b> +>> 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.</pre></td></tr></table> +<p> +Generate the checksum of the distfile into <tt class="filename">distinfo</tt>: +</p> +<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre><tt class="prompt">#</tt> <b class="userinput"><tt>make makesum</tt></b></pre></td></tr></table> +<p> +Now compile: +</p> +<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre><tt class="prompt">#</tt> <b class="userinput"><tt>make</tt></b> +>> 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 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include -g LR0.c +cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include -g allocate.c +cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include -g closure.c +cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include -g conflicts.c +cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include -g derives.c +cc -c -DXPFILE=\"/usr/pkg/share/bison.simple\" -DXPFILE1=\"/usr/pkg/share/bison.hairy\" -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -g ./files.c +cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include -g getargs.c +cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include -g gram.c +cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include -g lalr.c +cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include -g lex.c +cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include -g main.c +cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include -g nullable.c +cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include -g output.c +cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include -g print.c +cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include -g reader.c +cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include -g reduce.c +cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include -g symtab.c +cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include -g warshall.c +cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include -g version.c +cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include -g getopt.c +cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include -g getopt1.c +cc -g -o bison LR0.o allocate.o closure.o conflicts.o derives.o files.o getargs.o gram.o lalr.o lex.o main.o nullable.o output.o print.o reader.o reduce.o symtab.o warshall.o version.o getopt.o getopt1.o +./files.c:240: warning: mktemp() possibly used unsafely, consider using mkstemp() +rm -f bison.s1 +sed -e "/^#line/ s|bison|/usr/pkg/share/bison|" < ./bison.simple > bison.s1</pre></td></tr></table> +<p> +Everything seems OK, so install the files: +</p> +<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre><tt class="prompt">#</tt> <b class="userinput"><tt>make install</tt></b> +>> 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.hairy +cd .; for f in bison.info*; do /usr/bin/install -c -o bin -g bin -m 644 $f /usr/pkg/info/$f; done +/usr/bin/install -c -o bin -g bin -m 644 ./bison.1 /usr/pkg/man/man1/bison.1 +===> Registering installation for bison-1.25</pre></td></tr></table> +<p> +You can now use bison, and also - if you decide so - remove it with +<b class="command">pkg_delete bison</b>. Should you decide that you want a +binary package, do this now: +</p> +<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre><tt class="prompt">#</tt> <b class="userinput"><tt>make package</tt></b> +>> 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'</pre></td></tr></table> +<p> +Now that you don't need the source and object files any more, clean up: +</p> +<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre><tt class="prompt">#</tt> <b class="userinput"><tt>make clean</tt></b> +===> Cleaning for bison-1.25</pre></td></tr></table> +</div> +</div> +</div> +<div class="appendix" lang="en"> +<div class="titlepage"> +<div><div><h2 class="title"> +<a name="logs"></a>Appendix A. Build logs</h2></div></div> +<div></div> +</div> +<div class="toc"> +<p><b>Table of Contents</b></p> +<dl> +<dt>A.1. <a href="#logs.building">Building top</a> +</dt> +<dt>A.2. <a href="#logs.package">Packaging top</a> +</dt> +</dl> +</div> +<div class="sect1" lang="en"> +<div class="titlepage"> +<div><div><h2 class="title" style="clear: both"> +<a name="logs.building"></a>A.1. Building top</h2></div></div> +<div></div> +</div> +<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre><tt class="prompt">#</tt> <b class="userinput"><tt>make</tt></b> +>> 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://orpheus.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 getopt.o machine.o -ltermcap -lm -lkvm +<tt class="prompt">#</tt> +<tt class="prompt">#</tt> <b class="userinput"><tt>make install</tt></b> +>> 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</pre></td></tr></table> +</div> +<div class="sect1" lang="en"> +<div class="titlepage"> +<div><div><h2 class="title" style="clear: both"> +<a name="logs.package"></a>A.2. Packaging top</h2></div></div> +<div></div> +</div> +<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre><tt class="prompt">#</tt> <b class="userinput"><tt>make package</tt></b> +>> 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'</pre></td></tr></table> +</div> +</div> +<div class="appendix" lang="en"> +<div class="titlepage"> +<div><div><h2 class="title"> +<a name="ftp-layout"></a>Appendix B. Layout of the FTP server's package archive</h2></div></div> +<div></div> +</div> +<p> +Layout for precompiled binary packages on ftp.NetBSD.org: +</p> +<table xmlns:html="http://www.w3.org/1999/xhtml" class="programlisting"><tr><td><pre> +/pub/NetBSD/packages/ + README + distfiles/ + pkgsrc -> /pub/NetBSD/NetBSD-current/pkgsrc + 1.6/ + i386/ + All/ + archivers/ + foo -> ../All/foo + ... + m68k/ + All/ + archivers/ + foo -> ../All/foo + ... + amiga -> m68k + atari -> m68k + ... +</pre></td></tr></table> +</div> +</div></body> +</html> diff --git a/pkgsrc.txt b/pkgsrc.txt new file mode 100644 index 00000000000..b53a2830ce5 --- /dev/null +++ b/pkgsrc.txt @@ -0,0 +1,3234 @@ + +The NetBSD Packages Collection (pkgsrc) + +Alistair Crooks + + <agc@NetBSD.org> + +Hubert Feyrer + + <hubertf@NetBSD.org> + + $NetBSD: pkgsrc.txt,v 1.1 2003/06/23 07:41:44 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 + + 13. A simple example of a package: bison + + 13.1. files + 13.2. Steps for building, installing, packaging + + A. Build logs + + A.1. Building top + A.2. Packaging top + + B. 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 (MacOS 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 (MacOS 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 A, 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 A.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 + + 13. A simple example of a package: bison + + 13.1. files + 13.2. Steps for building, installing, packaging + +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.1 2003/06/23 07:41:44 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). + +Chapter 13. A simple example of a package: bison + + Table of Contents + + 13.1. files + 13.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. + +13.1. files + +13.1.1. Makefile + +# $NetBSD: pkgsrc.txt,v 1.1 2003/06/23 07:41:44 grant Exp $ +# + +DISTNAME= bison-1.25 +CATEGORIES= devel +MASTER_SITES= ${MASTER_SITE_GNU} + +MAINTAINER= thorpej@NetBSD.org +HOMEPAGE= http://www.gnu.org/software/bison/bison.html +COMMENT= GNU yacc clone + +GNU_CONFIGURE= yes +INFO_FILES= bison.info + +.include "../../mk/bsd.pkg.mk" + +13.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. + +13.1.3. PLIST + +@comment $NetBSD: pkgsrc.txt,v 1.1 2003/06/23 07:41:44 grant Exp $ +bin/bison +man/man1/bison.1.gz +info/bison.info +info/bison.info-1 +info/bison.info-2 +info/bison.info-3 +info/bison.info-4 +info/bison.info-5 +share/bison.simple +share/bison.hairy + +13.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. + +13.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 A. Build logs + + Table of Contents + + A.1. Building top + A.2. Packaging top + +A.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 + +A.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 B. 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 + ... |