The pkgsrc guide Documentation on the NetBSD packages system Alistair Crooks Hubert Feyrer The pkgsrc Developers Copyright 1994-2007 The NetBSD Foundation, Inc $NetBSD: pkgsrc.txt,v 1.14 2008/07/27 19:32:42 jmcneill Exp $ Abstract pkgsrc is a centralized package management system for Unix-like operating systems. This guide provides information for users and developers of pkgsrc. It covers installation of binary and source packages, creation of binary and source packages and a high-level overview about the infrastructure. ------------------------------------------------------------------------------- Table of Contents 1. What is pkgsrc? 1.1. Introduction 1.1.1. Why pkgsrc? 1.1.2. Supported platforms 1.2. Overview 1.3. Terminology 1.3.1. Roles involved in pkgsrc 1.4. Typography I. The pkgsrc user's guide 2. Where to get pkgsrc and how to keep it up-to-date 2.1. Getting pkgsrc for the first time 2.1.1. As tar file 2.1.2. Via SUP 2.1.3. Via anonymous CVS 2.2. Keeping pkgsrc up-to-date 2.2.1. Via tar files 2.2.2. Via CVS 3. Using pkgsrc on systems other than NetBSD 3.1. Binary distribution 3.2. Bootstrapping pkgsrc 3.3. Platform-specific notes 3.3.1. Darwin (Mac OS X) 3.3.2. FreeBSD 3.3.3. Interix 3.3.4. IRIX 3.3.5. Linux 3.3.6. OpenBSD 3.3.7. Solaris 4. Using pkgsrc 4.1. Using binary packages 4.1.1. Finding binary packages 4.1.2. Installing binary packages 4.1.3. Deinstalling packages 4.1.4. Getting information about installed packages 4.1.5. Checking for security vulnerabilities in installed packages 4.1.6. Finding if newer versions of your installed packages are in pkgsrc 4.1.7. Other administrative functions 4.1.8. A word of warning 4.2. Building packages from source 4.2.1. Requirements 4.2.2. Fetching distfiles 4.2.3. How to build and install 5. Configuring pkgsrc 5.1. General configuration 5.2. Variables affecting the build process 5.3. Variables affecting the installation process 5.4. Selecting and configuring the compiler 5.4.1. Selecting the compiler 5.4.2. Additional flags to the compiler (CFLAGS) 5.4.3. Additional flags to the linker (LDFLAGS) 5.5. Developer/advanced settings 5.6. Selecting Build Options 6. Creating binary packages 6.1. Building a single binary package 6.2. Settings for creation of binary packages 7. Creating binary packages for everything in pkgsrc (bulk builds) 7.1. Think first, build later 7.2. Requirements of a bulk build 7.3. Running an old-style bulk build 7.3.1. Configuration 7.3.2. Other environmental considerations 7.3.3. Operation 7.3.4. What it does 7.3.5. Disk space requirements 7.3.6. Setting up a sandbox for chrooted builds 7.3.7. Building a partial set of packages 7.3.8. Uploading results of a bulk build 7.4. Running a pbulk-style bulk build 7.4.1. Configuration 7.5. Creating a multiple CD-ROM packages collection 7.5.1. Example of cdpack 8. Directory layout of the installed files 8.1. File system layout in ${LOCALBASE} 8.2. File system layout in ${VARBASE} 9. Frequently Asked Questions 9.1. Are there any mailing lists for pkg-related discussion? 9.2. Where's the pkgviews documentation? 9.3. Utilities for package management (pkgtools) 9.4. How to use pkgsrc as non-root 9.5. How to resume transfers when fetching distfiles? 9.6. How can I install/use modular X.org from pkgsrc? 9.7. How to fetch files from behind a firewall 9.8. How do I tell make fetch to do passive FTP? 9.9. How to fetch all distfiles at once 9.10. What does "Don't know how to make /usr/share/tmac/tmac.andoc" mean? 9.11. What does "Could not find bsd.own.mk" mean? 9.12. Using 'sudo' with pkgsrc 9.13. How do I change the location of configuration files? 9.14. Automated security checks 9.15. Why do some packages ignore my CFLAGS? 9.16. A package does not build. What shall I do? 9.17. What does "Makefile appears to contain unresolved cvs/rcs/??? merge conflicts" mean? II. The pkgsrc developer's guide 10. Creating a new pkgsrc package from scratch 10.1. Common types of packages 10.1.1. Perl modules 10.1.2. KDE applications 10.2. Examples 10.2.1. How the www/nvu package came into pkgsrc 11. Package components - files, directories and contents 11.1. Makefile 11.2. distinfo 11.3. patches/* 11.3.1. Structure of a single patch file 11.3.2. Creating patch files 11.3.3. Sources where the patch files come from 11.3.4. Patching guidelines 11.3.5. Feedback to the author 11.4. Other mandatory files 11.5. Optional files 11.5.1. Files affecting the binary package 11.5.2. Files affecting the build process 11.5.3. Files affecting nothing at all 11.6. work* 11.7. files/* 12. Programming in Makefiles 12.1. Caveats 12.2. Makefile variables 12.2.1. Naming conventions 12.3. Code snippets 12.3.1. Adding things to a list 12.3.2. Converting an internal list into an external list 12.3.3. Passing variables to a shell command 12.3.4. Quoting guideline 12.3.5. Workaround for a bug in BSD Make 13. PLIST issues 13.1. RCS ID 13.2. Semi-automatic PLIST generation 13.3. Tweaking output of make print-PLIST 13.4. Variable substitution in PLIST 13.5. Man page compression 13.6. Changing PLIST source with PLIST_SRC 13.7. Platform-specific and differing PLISTs 13.8. Sharing directories between packages 14. Buildlink methodology 14.1. Converting packages to use buildlink3 14.2. Writing buildlink3.mk files 14.2.1. Anatomy of a buildlink3.mk file 14.2.2. Updating BUILDLINK_API_DEPENDS.pkg in buildlink3.mk files 14.3. Writing builtin.mk files 14.3.1. Anatomy of a builtin.mk file 14.3.2. Global preferences for native or pkgsrc software 15. The pkginstall framework 15.1. Files and directories outside the installation prefix 15.1.1. Directory manipulation 15.1.2. File manipulation 15.2. Configuration files 15.2.1. How PKG_SYSCONFDIR is set 15.2.2. Telling the software where configuration files are 15.2.3. Patching installations 15.2.4. Disabling handling of configuration files 15.3. System startup scripts 15.3.1. Disabling handling of system startup scripts 15.4. System users and groups 15.5. System shells 15.5.1. Disabling shell registration 15.6. Fonts 15.6.1. Disabling automatic update of the fonts databases 16. Options handling 16.1. Global default options 16.2. Converting packages to use bsd.options.mk 16.3. Option Names 16.4. Determining the options of dependencies 17. The build process 17.1. Introduction 17.2. Program location 17.3. Directories used during the build process 17.4. Running a phase 17.5. The fetch phase 17.5.1. What to fetch and where to get it from 17.5.2. How are the files fetched? 17.6. The checksum phase 17.7. The extract phase 17.8. The patch phase 17.9. The tools phase 17.10. The wrapper phase 17.11. The configure phase 17.12. The build phase 17.13. The test phase 17.14. The install phase 17.15. The package phase 17.16. Cleaning up 17.17. Other helpful targets 18. Tools needed for building or running 18.1. Tools for pkgsrc builds 18.2. Tools needed by packages 18.3. Tools provided by platforms 18.4. Questions regarding the tools 19. Making your package work 19.1. General operation 19.1.1. Portability of packages 19.1.2. How to pull in user-settable variables from mk.conf 19.1.3. User interaction 19.1.4. Handling licenses 19.1.5. Restricted packages 19.1.6. Handling dependencies 19.1.7. Handling conflicts with other packages 19.1.8. Packages that cannot or should not be built 19.1.9. Packages which should not be deleted, once installed 19.1.10. Handling packages with security problems 19.1.11. How to handle incrementing versions when fixing an existing package 19.1.12. Substituting variable text in the package files (the SUBST framework) 19.2. Fixing problems in the fetch phase 19.2.1. Packages whose distfiles aren't available for plain downloading 19.2.2. How to handle modified distfiles with the 'old' name 19.3. Fixing problems in the configure phase 19.3.1. Shared libraries - libtool 19.3.2. Using libtool on GNU packages that already support libtool 19.3.3. GNU Autoconf/Automake 19.4. Programming languages 19.4.1. C, C++, and Fortran 19.4.2. Java 19.4.3. Packages containing perl scripts 19.4.4. Other programming languages 19.5. Fixing problems in the build phase 19.5.1. Compiling C and C++ code conditionally 19.5.2. How to handle compiler bugs 19.5.3. Undefined reference to "..." 19.5.4. Running out of memory 19.6. Fixing problems in the install phase 19.6.1. Creating needed directories 19.6.2. Where to install documentation 19.6.3. Installing highscore files 19.6.4. Adding DESTDIR support to packages 19.6.5. Packages with hardcoded paths to other interpreters 19.6.6. Packages installing perl modules 19.6.7. Packages installing info files 19.6.8. Packages installing man pages 19.6.9. Packages installing GConf data files 19.6.10. Packages installing scrollkeeper data files 19.6.11. Packages installing X11 fonts 19.6.12. Packages installing GTK2 modules 19.6.13. Packages installing SGML or XML data 19.6.14. Packages installing extensions to the MIME database 19.6.15. Packages using intltool 19.6.16. Packages installing startup scripts 19.6.17. Packages installing TeX modules 19.6.18. Packages supporting running binaries in emulation 19.6.19. Packages installing hicolor theme icons 19.6.20. Packages installing desktop files 19.7. Marking packages as having problems 20. Debugging 21. Submitting and Committing 21.1. Submitting binary packages 21.2. Submitting source packages (for non-NetBSD-developers) 21.3. General notes when adding, updating, or removing packages 21.4. Committing: Importing a package into CVS 21.5. Updating a package to a newer version 21.6. Moving a package in pkgsrc 22. Frequently Asked Questions 23. GNOME packaging and porting 23.1. Meta packages 23.2. Packaging a GNOME application 23.3. Updating GNOME to a newer version 23.4. Patching guidelines III. The pkgsrc infrastructure internals 24. Design of the pkgsrc infrastructure 24.1. The meaning of variable definitions 24.2. Avoiding problems before they arise 24.3. Variable evaluation 24.3.1. At load time 24.3.2. At runtime 24.4. How can variables be specified? 24.5. Designing interfaces for Makefile fragments 24.5.1. Procedures with parameters 24.5.2. Actions taken on behalf of parameters 24.6. The order in which files are loaded 24.6.1. The order in bsd.prefs.mk 24.6.2. The order in bsd.pkg.mk 25. Regression tests 25.1. The regression tests framework 25.2. Running the regression tests 25.3. Adding a new regression test 25.3.1. Overridable functions 25.3.2. Helper functions 26. Porting pkgsrc 26.1. Porting pkgsrc to a new operating system 26.2. Adding support for a new compiler A. A simple example package: bison A.1. files A.1.1. Makefile A.1.2. DESCR A.1.3. PLIST A.1.4. Checking a package with pkglint A.2. Steps for building, installing, packaging B. Build logs B.1. Building figlet B.2. Packaging figlet C. Directory layout of the pkgsrc FTP server C.1. bootstrap-pkgsrc: Bootstrap kits C.2. distfiles: The distributed source files C.3. iso: Currently empty C.4. misc: Miscellaneous things C.5. packages: Binary packages C.6. reports: Bulk build reports C.7. current, pkgsrc-200xQy: source packages D. Editing guidelines for the pkgsrc guide D.1. Make targets D.2. Procedure List of Tables 1.1. Platforms supported by pkgsrc 11.1. Patching examples 23.1. PLIST handling for GNOME packages Chapter 1. What is pkgsrc? Table of Contents 1.1. Introduction 1.1.1. Why pkgsrc? 1.1.2. Supported platforms 1.2. Overview 1.3. Terminology 1.3.1. Roles involved in pkgsrc 1.4. Typography 1.1. Introduction There is a lot of software freely available for Unix-based systems, which is usually available in form of the source code. Before such software can be used, it needs to be configured to the local system, compiled and installed, and this is exactly what The NetBSD Packages Collection (pkgsrc) does. pkgsrc also has some basic commands to handle binary packages, so that not every user has to build the packages for himself, which is a time-costly task. pkgsrc currently contains several thousand packages, including: * www/apache - The Apache web server * www/firefox - The Firefox web browser * meta-pkgs/gnome - The GNOME Desktop Environment * meta-pkgs/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. 1.1.1. Why pkgsrc? pkgsrc provides the following key features: * Easy building of software from source as well as the creation and installation of binary packages. The source and latest patches are retrieved from a master or mirror download site, checksum verified, then built on your system. Support for binary-only distributions is available for both native platforms and NetBSD emulated platforms. * All packages are installed in a consistent directory tree, including binaries, libraries, man pages and other documentation. * Package dependencies, including when performing package updates, are handled automatically. The configuration files of various packages are handled automatically during updates, so local changes are preserved. * Like NetBSD, pkgsrc is designed with portability in mind and consists of highly portable code. This allows the greatest speed of development when porting to new a platform. This portability also ensures that pkgsrc is consistent across all platforms. * The installation prefix, acceptable software licenses, international encryption requirements and build-time options for a large number of packages are all set in a simple, central configuration file. * The entire source (not including the distribution files) is freely available under a BSD license, so you may extend and adapt pkgsrc to your needs. Support for local packages and patches is available right out of the box, so you can configure it specifically for your environment. The following principles are basic to pkgsrc: * "It should only work if it's right." ? That means, if a package contains bugs, it's better to find them and to complain about them rather than to just install the package and hope that it works. There are numerous checks in pkgsrc that try to find such bugs: Static analysis tools (pkgtools/ pkglint), build-time checks (portability of shell scripts), and post-installation checks (installed files, references to shared libraries, script interpreters). * "If it works, it should work everywhere" ? Like NetBSD has been ported to many hardware architectures, pkgsrc has been ported to many operating systems. Care is taken that packages behave the same on all platforms. 1.1.2. Supported platforms pkgsrc consists of both a source distribution and a binary distribution for these operating systems. After retrieving the required source or binaries, you can be up and running with pkgsrc in just minutes! pkgsrc was derived from FreeBSD's ports system, and initially developed for NetBSD only. Since then, pkgsrc has grown a lot, and now supports the following platforms: Table 1.1. Platforms supported by pkgsrc +----------------------------------------------------------------+ | Platform |Date Support Added| |---------------------------------------------+------------------| |NetBSD | Aug 1997 | |---------------------------------------------+------------------| |Solaris | Mar 1999 | |---------------------------------------------+------------------| |Linux | Jun 1999 | |---------------------------------------------+------------------| |Darwin (Mac OS X) | Oct 2001 | |---------------------------------------------+------------------| |FreeBSD | Nov 2002 | |---------------------------------------------+------------------| |OpenBSD | Nov 2002 | |---------------------------------------------+------------------| |IRIX | Dec 2002 | |---------------------------------------------+------------------| |BSD/OS | Dec 2003 | |---------------------------------------------+------------------| |AIX | Dec 2003 | |---------------------------------------------+------------------| |Interix (Microsoft Windows Services for Unix)| Mar 2004 | |---------------------------------------------+------------------| |DragonFlyBSD | Oct 2004 | |---------------------------------------------+------------------| |OSF/1 | Nov 2004 | |---------------------------------------------+------------------| |HP-UX | Apr 2007 | +----------------------------------------------------------------+ 1.2. Overview This document is divided into three parts. The first, The 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, The 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. The third part, The pkgsrc infrastructure internals is intended for those who want to understand how pkgsrc is implemented. This document is available in various formats: HTML, PDF, PS, TXT. 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 pkgsrc. Packages are traditionally stored under /usr/pkgsrc. The NetBSD package system This is the former name of "pkgsrc". It is part of the NetBSD operating system and can be bootstrapped to run on non-NetBSD operating systems as well. It handles building (compiling), installing, and removing of packages. Distfile This term describes the file or files that are provided by the author of the piece of 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 usually stored below /usr/pkgsrc/distfiles. Port This is the term used by FreeBSD and OpenBSD people for what we call a package. In NetBSD terminology, "port" refers to a different architecture. Precompiled/binary package A set of binaries built with pkgsrc from a distfile and stuffed together in a single .tgz file so it can be installed on machines of the same machine architecture without the need to recompile. Packages are usually generated in /usr/pkgsrc/packages; there is also 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.3.1. Roles involved in pkgsrc pkgsrc users The pkgsrc users are people who use the packages provided by pkgsrc. Typically they are system administrators. The people using the software that is inside the packages (maybe called "end users") are not covered by the pkgsrc guide. There are two kinds of pkgsrc users: Some only want to install pre-built binary packages. Others build the pkgsrc packages from source, either for installing them directly or for building binary packages themselves. For pkgsrc users Part I, "The pkgsrc user's guide" should provide all necessary documentation. package maintainers A package maintainer creates packages as described in Part II, "The pkgsrc developer's guide". infrastructure developers These people are involved in all those files that live in the mk/ directory and below. Only these people should need to read through Part III, "The pkgsrc infrastructure internals", though others might be curious, too. 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. Part I. The pkgsrc user's guide Table of Contents 2. Where to get pkgsrc and how to keep it up-to-date 2.1. Getting pkgsrc for the first time 2.1.1. As tar file 2.1.2. Via SUP 2.1.3. Via anonymous CVS 2.2. Keeping pkgsrc up-to-date 2.2.1. Via tar files 2.2.2. Via CVS 3. Using pkgsrc on systems other than NetBSD 3.1. Binary distribution 3.2. Bootstrapping pkgsrc 3.3. Platform-specific notes 3.3.1. Darwin (Mac OS X) 3.3.2. FreeBSD 3.3.3. Interix 3.3.4. IRIX 3.3.5. Linux 3.3.6. OpenBSD 3.3.7. Solaris 4. Using pkgsrc 4.1. Using binary packages 4.1.1. Finding binary packages 4.1.2. Installing binary packages 4.1.3. Deinstalling packages 4.1.4. Getting information about installed packages 4.1.5. Checking for security vulnerabilities in installed packages 4.1.6. Finding if newer versions of your installed packages are in pkgsrc 4.1.7. Other administrative functions 4.1.8. A word of warning 4.2. Building packages from source 4.2.1. Requirements 4.2.2. Fetching distfiles 4.2.3. How to build and install 5. Configuring pkgsrc 5.1. General configuration 5.2. Variables affecting the build process 5.3. Variables affecting the installation process 5.4. Selecting and configuring the compiler 5.4.1. Selecting the compiler 5.4.2. Additional flags to the compiler (CFLAGS) 5.4.3. Additional flags to the linker (LDFLAGS) 5.5. Developer/advanced settings 5.6. Selecting Build Options 6. Creating binary packages 6.1. Building a single binary package 6.2. Settings for creation of binary packages 7. Creating binary packages for everything in pkgsrc (bulk builds) 7.1. Think first, build later 7.2. Requirements of a bulk build 7.3. Running an old-style bulk build 7.3.1. Configuration 7.3.2. Other environmental considerations 7.3.3. Operation 7.3.4. What it does 7.3.5. Disk space requirements 7.3.6. Setting up a sandbox for chrooted builds 7.3.7. Building a partial set of packages 7.3.8. Uploading results of a bulk build 7.4. Running a pbulk-style bulk build 7.4.1. Configuration 7.5. Creating a multiple CD-ROM packages collection 7.5.1. Example of cdpack 8. Directory layout of the installed files 8.1. File system layout in ${LOCALBASE} 8.2. File system layout in ${VARBASE} 9. Frequently Asked Questions 9.1. Are there any mailing lists for pkg-related discussion? 9.2. Where's the pkgviews documentation? 9.3. Utilities for package management (pkgtools) 9.4. How to use pkgsrc as non-root 9.5. How to resume transfers when fetching distfiles? 9.6. How can I install/use modular X.org from pkgsrc? 9.7. How to fetch files from behind a firewall 9.8. How do I tell make fetch to do passive FTP? 9.9. How to fetch all distfiles at once 9.10. What does "Don't know how to make /usr/share/tmac/tmac.andoc" mean? 9.11. What does "Could not find bsd.own.mk" mean? 9.12. Using 'sudo' with pkgsrc 9.13. How do I change the location of configuration files? 9.14. Automated security checks 9.15. Why do some packages ignore my CFLAGS? 9.16. A package does not build. What shall I do? 9.17. What does "Makefile appears to contain unresolved cvs/rcs/??? merge conflicts" mean? Chapter 2. Where to get pkgsrc and how to keep it up-to-date Table of Contents 2.1. Getting pkgsrc for the first time 2.1.1. As tar file 2.1.2. Via SUP 2.1.3. Via anonymous CVS 2.2. Keeping pkgsrc up-to-date 2.2.1. Via tar files 2.2.2. Via CVS Before you download and extract the files, you need to decide where you want to extract them. When using pkgsrc as root user, pkgsrc is usually installed in / usr/pkgsrc. You are though free to install the sources and binary packages wherever you want in your filesystem, provided that the pathname does not contain white-space or other characters that are interpreted specially by the shell and some other programs. A safe bet is to use only letters, digits, underscores and dashes. 2.1. Getting pkgsrc for the first time Before you download any pkgsrc files, you should decide whether you want the current branch or the stable branch. The latter is forked on a quarterly basis from the current branch and only gets modified for security updates. The names of the stable branches are built from the year and the quarter, for example 2007Q4. The second step is to decide how you want to download pkgsrc. You can get it as a tar file, via SUP, or via CVS. All three ways are described here. 2.1.1. As tar file The primary download location for all pkgsrc files is ftp://ftp.NetBSD.org/pub/ pkgsrc/. There are a number of subdirectories for different purposes, which are described in detail in Appendix C, Directory layout of the pkgsrc FTP server. The tar file for the current branch is in the directory current and is called pkgsrc.tar.gz. It is autogenerated daily. The tar file for the stable branch 2007Q4 is in the directory pkgsrc-2007Q4 and is also called pkgsrc-2007Q4.tar.gz. To download a pkgsrc stable tarball, run: $ ftp ftp://ftp.NetBSD.org/pub/pkgsrc/pkgsrc-200xQy/pkgsrc-200xQy.tar.gz Where pkgsrc-200xQy is the stable branch to be downloaded, for example, "pkgsrc-2007Q4". Then, extract it with: $ tar -xzf pkgsrc-200xQy.tar.gz -C /usr This will create the directory pkgsrc/ in /usr/ and all the package source will be stored under /usr/pkgsrc/. To download pkgsrc-current, run: $ ftp ftp://ftp.NetBSD.org/pub/pkgsrc/current/pkgsrc.tar.gz 2.1.2. Via SUP As an alternative to the tar file, 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. 2.1.3. Via anonymous CVS To do an initial (full) checkout of pkgsrc, you first have to set some environment variables. For the C-Shell, type: % setenv CVSROOT anoncvs@anoncvs.NetBSD.org:/cvsroot % setenv CVS_RSH ssh Or, the same for the bourne shell: $ export CVSROOT="anoncvs@anoncvs.NetBSD.org:/cvsroot" $ export CVS_RSH="ssh" By default, CVS doesn't do things like most people would expect it to do. But there is a way to convince CVS, by creating a file called .cvsrc in your home directory and saving the following lines to it. This file will save you lots of headache and some bug reports, so we strongly recommend it. You can find an explanation of this file in the CVS documentation. # recommended CVS configuration file from the pkgsrc guide checkout -P update -dP release -d diff -upN cvs -q -z3 rdiff -u To fetch a specific pkgsrc stable branch from scratch, run: $ cd /usr $ cvs checkout -r pkgsrc-200xQy -P pkgsrc Where pkgsrc-200xQy is the stable branch to be checked out, for example, "pkgsrc-2007Q4" This will create the directory pkgsrc/ in your /usr/ directory and all the package source will be stored under /usr/pkgsrc/. To fetch the pkgsrc current branch, run: $ cd /usr $ cvs checkout -P pkgsrc 2.2. Keeping pkgsrc up-to-date The preferred way to keep pkgsrc up-to-date is via CVS (which also works if you have first installed it via a tar file). It saves bandwidth and hard disk activity, compared to downloading the tar file again. 2.2.1. Via tar files Warning When updating from a tar file, you first need to completely remove the old pkgsrc directory. Otherwise those files that have been removed from pkgsrc in the mean time will not be removed on your local disk, resulting in inconsistencies. When removing the old files, any changes that you have done to the pkgsrc files will be lost after updating. Therefore updating via CVS is strongly recommended. Note that by default the distfiles and the binary packages are saved in the pkgsrc tree, so don't forget to rescue them before updating. You can also configure pkgsrc to use other than the default directories by setting the DISTDIR and PACKAGES variables. See Chapter 5, Configuring pkgsrc for the details. To update pkgsrc from a tar file, download the tar file as explained above. Then, make sure that you have not made any changes to the files in the pkgsrc directory. Remove the pkgsrc directory and extract the new tar file. Done. 2.2.2. Via CVS To update pkgsrc via CVS, make sure the environment variable CVS_RSH is set as above. Then, change to the pkgsrc directory and run cvs: $ cd /usr/pkgsrc $ cvs update -dP 2.2.2.1. Switching between different pkgsrc branches When updating pkgsrc, the CVS program keeps track of the branch you selected. But if you, for whatever reason, want to switch from the stable branch to the current one, you can do it by adding the option "-A" after the "update" keyword. To switch from the current branch back to the stable branch, add the "-rpkgsrc-2007Q4" option. 2.2.2.2. What happens to my changes when updating? When you update pkgsrc, the CVS program will only touch those files that are registered in the CVS repository. That means that any packages that you created on your own will stay unmodified. If you change files that are managed by CVS, later updates will try to merge your changes with those that have been done by others. See the CVS manual, chapter "update" for details. Chapter 3. Using pkgsrc on systems other than NetBSD Table of Contents 3.1. Binary distribution 3.2. Bootstrapping pkgsrc 3.3. Platform-specific notes 3.3.1. Darwin (Mac OS X) 3.3.2. FreeBSD 3.3.3. Interix 3.3.4. IRIX 3.3.5. Linux 3.3.6. OpenBSD 3.3.7. Solaris 3.1. Binary distribution See Section 4.1, "Using binary packages". 3.2. Bootstrapping pkgsrc Installing the bootstrap kit from source should be as simple as: # env CVS_RSH=ssh cvs -d anoncvs@anoncvs.NetBSD.org:/cvsroot checkout pkgsrc # cd pkgsrc/bootstrap # ./bootstrap See Chapter 2, Where to get pkgsrc and how to keep it up-to-date for other ways to get pkgsrc before bootstrapping. The given bootstrap command will use the defaults of /usr/pkg for the prefix where programs will be installed in, and / var/db/pkg for the package database directory where pkgsrc will do its internal bookkeeping. However, these can also be set using command-line arguments. Note The bootstrap installs a bmake tool. Use this bmake when building via pkgsrc. For examples in this guide, use bmake instead of "make". 3.3. Platform-specific notes Here are some platform-specific notes you should be aware of. 3.3.1. Darwin (Mac OS X) Darwin 5.x and up are supported. There are two methods of using pkgsrc on Mac OS X, by using a disk image, or a UFS or HFSX partition. Before you start, you will need to download and install the Mac OS X Developer Tools from Apple's Developer Connection. See http://developer.apple.com/macosx/ for details. Also, make sure you install X11 for Mac OS X and the X11 SDK from http://www.apple.com/macosx/x11/download/ if you intend to build packages that use the X11 Window System. If you already have a UFS or HFSX partition, or have a spare partition that you can format as UFS or HFSX, 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 an ordinary HFS+ file system for pkgsrc, because pkgsrc currently requires the file system to be case-sensitive. You can, however, use a case-sensitive HFS+ (aka HFSX) file system as found in Darwin 7.0 and newer. 3.3.1.1. Using a disk image Create the disk image: # cd pkgsrc/bootstrap # ./darwindiskimage create ~/Documents/NetBSD 1024 # megabytes - season to taste # ./darwindiskimage mount ~/Documents/NetBSD # sudo chown `id -u`:`id -g` /Volumes/NetBSD Note darwindiskimage will mount the filesystem nosuid, which will cause problems for packages that depend on setgid. In the case of UFS, it will also mount the filesystem asynchronous, which is somewhat dangerous according to the mount(8) man page. In the case of HFSX, it will disable journaling. Allow suid: # sudo mount -u -o suid /Volumes/NetBSD Changing the build directory: After bootstrapping you need to change the default package build directory to somewhere outside the disk image so it doesn't get filled up in the process of building packages. Add something like that to mk.conf. WRKOBJDIR?= /tmp/pkgsrc # build here instead of in pkgsrc 3.3.1.2. Using a UFS or HFSX 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 or HFSX file system. Obviously, another symlink is required if you want to place the package database directory outside the prefix. e.g. # ./bootstrap --pkgdbdir /usr/pkg/pkgdb If you created your partitions at the time of installing Mac OS X and formatted the target partition as UFS or HFSX, it should automatically mount on /Volumes/ when the machine boots. If you are (re)formatting a partition as UFS or HFSX, you need to ensure that the partition map correctly reflects "Apple_UFS" or "Apple_HFSX" 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 or HFSX, and Format it Apple UFS or HFSX. Quit the Disk Utility, quit the installer which will reboot your machine. The new UFS or HFSX 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). 3.3.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 mk.conf file will be placed in /etc/mk.conf.example file when you use the bootstrap script. 3.3.3. Interix Interix is a POSIX-compatible subsystem for the Windows NT kernel, providing a Unix-like environment with a tighter kernel integration than available with Cygwin. It is part of the Windows Services for Unix package, available for free for any licensed copy of Windows 2000, XP (not including XP Home), or 2003. SFU can be downloaded from http://www.microsoft.com/windows/sfu/. Services for Unix 3.5 has been tested. 3.0 or 3.1 may work, but are not officially supported. (The main difference in 3.0/3.1 is lack of pthreads, but other parts of libc may also be lacking.) Services for Unix Applications (aka SUA) is an integrated component of Windows Server 2003 R2 and Windows Vista. As of this writing, SUA's Interix 5.x subsystem has not yet been tested with pkgsrc. 3.3.3.1. When installing Interix/SFU At an absolute minimum, the following packages must be installed from the Windows Services for Unix 3.5 distribution in order to use pkgsrc: * Utilities -> Base Utilities * Interix GNU Components -> (all) * Remote Connectivity * Interix SDK When using pkgsrc on Interix, DO NOT install the Utilities subcomponent "UNIX Perl". That is Perl 5.6 without shared module support, installed to /usr/local, and will only cause confusion. Instead, install Perl 5.8 from pkgsrc (or from a binary package). The Remote Connectivity subcomponent "Windows Remote Shell Service" does not need to be installed, but Remote Connectivity itself should be installed in order to have a working inetd. During installation you may be asked whether to enable setuid behavior for Interix programs, and whether to make pathnames default to case-sensitive. Setuid should be enabled, and case-sensitivity MUST be enabled. (Without case-sensitivity, a large number of packages including perl will not build.) NOTE: Newer Windows service packs change the way binary execution works (via the Data Execution Prevention feature). In order to use pkgsrc and other gcc-compiled binaries reliably, a hotfix containing POSIX.EXE, PSXDLL.DLL, PSXRUN.EXE, and PSXSS.EXE (899522 or newer) must be installed. Hotfixes are available from Microsoft through a support contract; however, Debian Interix Port has made most Interix hotfixes available for personal use from http:// www.debian-interix.net/hotfixes/. In addition to the hotfix noted above, it may be necessary to disable Data Execution Prevention entirely to make Interix functional. This may happen only with certain types of CPUs; the cause is not fully understood at this time. If gcc or other applications still segfault repeatedly after installing one of the hotfixes note above, the following option can be added to the appropriate "boot.ini" line on the Windows boot drive: /NoExecute=AlwaysOff (WARNING, this will disable DEP completely, which may be a security risk if applications are often run as a user in the Administrators group!) 3.3.3.2. What to do if Interix/SFU is already installed If SFU is already installed and you wish to alter these settings to work with pkgsrc, note the following things. * To uninstall UNIX Perl, use Add/Remove Programs, select Microsoft Windows Services for UNIX, then click Change. In the installer, choose Add or Remove, then uncheck Utilities->UNIX Perl. * To enable case-sensitivity for the file system, run REGEDIT.EXE, and change the following registry key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\kernel Set the DWORD value "obcaseinsensitive" to 0; then reboot. * To enable setuid binaries (optional), run REGEDIT.EXE, and change the following registry key: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Services for UNIX Set the DWORD value "EnableSetuidBinaries" to 1; then reboot. 3.3.3.3. Important notes for using pkgsrc The package manager (either the pkgsrc "su" user, or the user running "pkg_add") must be a member of the local Administrators group. Such a user must also be used to run the bootstrap. This is slightly relaxed from the normal pkgsrc requirement of "root". The package manager should use a umask of 002. "make install" will automatically complain if this is not the case. This ensures that directories written in /var/db/pkg are Administrators-group writeable. The popular Interix binary packages from http://www.interopsystems.com/ use an older version of pkgsrc's pkg_* tools. Ideally, these should NOT be used in conjunction with pkgsrc. If you choose to use them at the same time as the pkgsrc packages, ensure that you use the proper pkg_* tools for each type of binary package. The TERM setting used for DOS-type console windows (including those invoked by the csh and ksh startup shortcuts) is "interix". Most systems don't have a termcap/terminfo entry for it, but the following .termcap entry provides adequate emulation in most cases: interix:kP=\E[S:kN=\E[T:kH=\E[U:dc@:DC@:tc=pcansi: 3.3.3.4. Limitations of the Interix platform Though Interix suffices as a familiar and flexible substitute for a full Unix-like platform, it has some drawbacks that should be noted for those desiring to make the most of Interix. * X11: Interix comes with the standard set of X11R6 client libraries, and can run X11 based applications, but it does not come with an X server. Some options are StarNet X-Win32, Hummingbird Exceed (available in a trimmed version for Interix from Interop Systems as the Interop X Server), and the free X11 server included with Cygwin. * X11 acceleration: Because Interix runs in a completely different NT subsystem from Win32 applications, it does not currently support various X11 protocol extensions for acceleration (such as MIT-SHM or DGA). Most interactive applications to a local X server will run reasonably fast, but full motion video and other graphics intensive applications may require a faster-than-expected CPU. * Audio: Interix has no native support for audio output. For audio support, pkgsrc uses the esound client/server audio system on Interix. Unlike on most platforms, the audio/esound package does not contain the esd server component. To output audio via an Interix host, the emulators/cygwin_esound package must also be installed. * CD/DVDs, USB, and SCSI: Direct device access is not currently supported in Interix, so it is not currently possible to access CD/DVD drives, USB devices, or SCSI devices through non-filesystem means. Among other things, this makes it impossible to use Interix directly for CD/DVD burning. * Tape drives: Due to the same limitations as for CD-ROMs and SCSI devices, tape drives are also not directly accessible in Interix. However, support is in work to make tape drive access possible by using Cygwin as a bridge (similarly to audio bridged via Cygwin's esound server). 3.3.3.5. Known issues for pkgsrc on Interix It is not necessary, in general, to have a "root" user on the Windows system; any member of the local Administrators group will suffice. However, some packages currently assume that the user named "root" is the privileged user. To accommodate these, you may create such a user; make sure it is in the local group Administrators (or your language equivalent). pkg_add creates directories of mode 0755, not 0775, in $PKG_DBDIR. For the time being, install packages as the local Administrator (or your language equivalent), or run the following command after installing a package to work around the issue: # chmod -R g+w $PKG_DBDIR 3.3.4. IRIX You will need a working C compiler, either gcc or SGI's MIPS and MIPSpro compiler (cc/c89). Please set the CC environment variable according to your preference. If you do not have a license for the MIPSpro compiler suite, you can download a gcc tardist file from http://freeware.sgi.com/. Please note that you will need IRIX 6.5.17 or higher, as this is the earliest version of IRIX providing support for if_indextoname(3), if_nametoindex(3), etc. At this point in time, pkgsrc only supports one ABI at a time. That is, you cannot switch between the old 32-bit ABI, the new 32-bit ABI and the 64-bit ABI. If you start out using "abi=n32", that's what all your packages will be built with. Therefore, please make sure that you have no conflicting CFLAGS in your environment or the 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! If you have the actual pkgsrc tree mounted via NFS from a different host, please make sure to set WRKOBJDIR to a local directory, as it appears that IRIX linker occasionally runs into issues when trying to link over a network-mounted file system. The bootstrapping process should set all the right options for programs such as imake(1), but you may want to set some options depending on your local setup. Please see pkgsrc/mk/defaults/mk.conf and, of course, your compiler's man pages for details. If you are using SGI's MIPSPro compiler, please set PKGSRC_COMPILER= mipspro in mk.conf. Otherwise, pkgsrc will assume you are using gcc and may end up passing invalid flags to the compiler. Note that bootstrap should create an appropriate mk.conf.example by default. If you have both the MIPSPro compiler chain installed as well as gcc, but want to make sure that MIPSPro is used, please set your PATH to not include the location of gcc (often /usr/freeware/bin), and (important) pass the '--preserve-path' flag. 3.3.5. Linux Some versions of Linux (for example Debian GNU/Linux) need either libtermcap or libcurses (libncurses). Installing the distributions libncurses-dev package (or equivalent) should fix the problem. pkgsrc supports both gcc (GNU Compiler Collection) and icc (Intel C++ Compiler). gcc is the default. icc 8.0 and 8.1 on i386 have been tested. To bootstrap using icc, assuming the default icc installation directory: env CC=/opt/intel_cc_80/bin/icc LDFLAGS=-static-libcxa \ ac_cv___attribute__=yes ./bootstrap Note icc 8.1 needs the `-i-static' argument instead of -static-libcxa. icc supports __attribute__, but the GNU configure test uses a nested function, which icc does not support. #undef'ing __attribute__ has the unfortunate side-effect of breaking many of the Linux header files, which cannot be compiled properly without __attribute__. The test must be overridden so that __attribute__ is assumed supported by the compiler. After bootstrapping, you should set PKGSRC_COMPILER in mk.conf: PKGSRC_COMPILER= icc The default installation directory for icc is /opt/intel_cc_80, which is also the pkgsrc default. If you have installed it into a different directory, set ICCBASE in mk.conf: ICCBASE= /opt/icc pkgsrc uses the static linking method of the runtime libraries provided by icc, so binaries can be run on other systems which do not have the shared libraries installed. Libtool, however, extracts a list of libraries from the ld(1) command run when linking a C++ shared library and records it, throwing away the -Bstatic and -Bdynamic options interspersed between the libraries. This means that libtool-linked C++ shared libraries will have a runtime dependency on the icc libraries until this is fixed in libtool. 3.3.6. 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 mk.conf file will be placed in /etc/mk.conf.example file when you use the bootstrap script. OpenBSD's make program uses mk.conf as well. You can work around this by enclosing all the pkgsrc-specific parts of the file with: .ifdef BSD_PKG_MK # pkgsrc stuff, e.g. insert defaults/mk.conf or similar here .else # OpenBSD stuff .endif 3.3.7. Solaris Solaris 2.6 through 9 are supported on both x86 and sparc. You will need a working C compiler. Both gcc 2.95.3 and Sun WorkShop 5 have been tested. The following packages are required on Solaris 8 for the bootstrap process and to build packages. * SUNWsprot * SUNWarc * SUNWbtool * SUNWtoo * SUNWlibm Please note that the use of GNU binutils on Solaris is not supported, as of June 2006. Whichever compiler you use, please ensure the compiler tools and your $prefix are in your PATH. This includes /usr/ccs/{bin,lib} and e.g. /usr/pkg/ {bin,sbin}. 3.3.7.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. Binary packages of gcc can be found through http://www.sunfreeware.com/. 3.3.7.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 the following variables in your mk.conf file: CC= cc CXX= CC CPP= cc -E CXXCPP= CC -E Note The CPP setting might break some packages that use the C preprocessor for processing things other than C source code. 3.3.7.3. Building 64-bit binaries with SunPro To build 64-bit packages, you just need to have the following lines in your mk.conf file: PKGSRC_COMPILER= sunpro ABI= 64 Note This setting has been tested for the SPARC architecture. Intel and AMD machines need some more work. 3.3.7.4. Common problems Sometimes, when using libtool, /bin/ksh crashes with a segmentation fault. The workaround is to use another shell for the configure scripts, for example by installing shells/bash and adding the following lines to your mk.conf: CONFIG_SHELL= ${LOCALBASE}/bin/bash WRAPPER_SHELL= ${LOCALBASE}/bin/bash Then, rebuild the devel/libtool-base package. Chapter 4. Using pkgsrc Table of Contents 4.1. Using binary packages 4.1.1. Finding binary packages 4.1.2. Installing binary packages 4.1.3. Deinstalling packages 4.1.4. Getting information about installed packages 4.1.5. Checking for security vulnerabilities in installed packages 4.1.6. Finding if newer versions of your installed packages are in pkgsrc 4.1.7. Other administrative functions 4.1.8. A word of warning 4.2. Building packages from source 4.2.1. Requirements 4.2.2. Fetching distfiles 4.2.3. How to build and install Basically, there are two ways of using pkgsrc. The first is to only install the package tools and to use binary packages that someone else has prepared. This is the "pkg" in pkgsrc. The second way is to install the "src" of pkgsrc, too. Then you are able to build your own packages, and you can still use binary packages from someone else. 4.1. Using binary packages On the ftp.NetBSD.org server and its mirrors, there are collections of binary packages, ready to be installed. These binary packages have been built using the default settings for the directories, that is: * /usr/pkg for LOCALBASE, where most of the files are installed, * /usr/pkg/etc for configuration files, * /var for VARBASE, where those files are installed that may change after installation. If you cannot use these directories for whatever reasons (maybe because you're not root), you cannot use these binary packages, but have to build the packages yourself, which is explained in Section 3.2, "Bootstrapping pkgsrc". 4.1.1. Finding binary packages To install binary packages, you first need to know from where to get them. The first place where you should look is on the main pkgsrc FTP server in the directory /pub/pkgsrc/packages. This directory contains binary packages for multiple platforms. First, select your operating system. (Ignore the directories with version numbers attached to it, they just exist for legacy reasons.) Then, select your hardware architecture, and in the third step, the OS version and the "version" of pkgsrc. In this directory, you often find a file called bootstrap.tar.gz which contains the package management tools. If the file is missing, it is likely that your operating system already provides those tools. Download the file and extract it in the / directory. It will create the directories /usr/pkg (containing the tools for managing binary packages) and /var/db/pkg (the database of installed packages). 4.1.2. Installing binary packages In the directory from the last section, there is a subdirectory called All, which contains all the binary packages that are available for the platform, excluding those that may not be distributed via FTP or CDROM (depending on which medium you are using), and the ones that have vulnerabilities and therefore are considered insecure to install without thinking before. To install packages directly from an FTP or HTTP server, run the following commands in a Bourne-compatible shell (be sure to su to root first): # PATH="/usr/pkg/sbin:$PATH" # PKG_PATH="ftp://ftp.NetBSD.org/pub/pkgsrc/packages/OPSYS/ARCH/VERSIONS/All" # export PATH PKG_PATH Instead of URLs, you can also use local paths, for example if you are installing from a set of CDROMs, DVDs or an NFS-mounted repository. If you want to install packages from multiple sources, you can separate them by a semicolon in PKG_PATH. After these preparations, installing a package is very easy: # pkg_add openoffice2 # pkg_add kde-3.5.7 # pkg_add ap2-php5-* Note that any prerequisite packages needed to run the package in question will be installed, too, assuming they are present where you install from. As mentioned above, packages for which vulnerabilities get known are not stored in the All subdirectory. They don't get deleted since that could be very frustrating if many other packages depend on it. Instead, they are moved to the vulnerable subdirectory. So you may need to add this directory to the PKG_PATH variable. However, you should run audit-packages regularly, especially after installing new packages, and verify that the vulnerabilities are acceptable for your configuration. After you've installed packages, be sure to have /usr/pkg/bin and /usr/pkg/sbin in your PATH so you can actually start the just installed program. 4.1.3. Deinstalling packages To deinstall a package, it does not matter whether it was installed from source code or from a binary package. The pkg_delete command does not know it anyway. To delete a package, you can just run pkg_delete package-name. The package name can be given with or without version number. Wildcards can also be used to deinstall a set of packages, for example *emacs*. Be sure to include them in quotes, so that the shell does not expand them before pkg_delete sees them. The -r option is very powerful: it removes all the packages that require the package in question and then removes the package itself. For example: # pkg_delete -r jpeg will remove jpeg and all the packages that used it; this allows upgrading the jpeg package. 4.1.4. Getting information about installed packages The pkg_info shows information about installed packages or binary package files. 4.1.5. Checking for security vulnerabilities in installed packages The NetBSD Security-Officer and Packages Groups maintain a list of known security vulnerabilities to packages which are (or have been) included in pkgsrc. The list is available from the NetBSD FTP site at ftp://ftp.NetBSD.org/ pub/pkgsrc/distfiles/vulnerabilities. Through security/audit-packages, this list can be downloaded automatically, and a security audit of all packages installed on a system can take place. There are two components to security/audit-packages. The first component, "download-vulnerability-list", is for downloading the list of vulnerabilities from the NetBSD FTP site. The second component, "audit-packages", checks to see if any of your installed packages are vulnerable. If a package is vulnerable, you will see output similar to the following: Package samba-2.0.9 has a local-root-shell vulnerability, see http://www.samba.org/samba/whatsnew/macroexploit.html One can set up security/audit-packages to download the vulnerabilities file daily, and include a package audit in the daily security script. Details on this are located in the MESSAGE file for security/audit-packages. 4.1.6. Finding if newer versions of your installed packages are in pkgsrc Install pkgtools/lintpkgsrc and run lintpkgsrc with the "-i" argument to check if your packages are up-to-date, e.g. % lintpkgsrc -i ... Version mismatch: 'tcsh' 6.09.00 vs 6.10.00 You can then use make update to update the package on your system and rebuild any dependencies. 4.1.7. Other administrative functions The pkg_admin executes various administrative functions on the package system. 4.1.8. A word of warning Please pay very careful attention to the warnings expressed in the pkg_add(1) 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. The same warning of course applies to every package you install from source when you haven't completely read and understood the source code of the package, the compiler that is used to build the package and all the other tools that are involved. 4.2. Building packages from source After obtaining pkgsrc, the pkgsrc directory now contains a set of packages, organized into categories. You can browse the online index of packages, or run make readme from the pkgsrc directory to build local README.html files for all packages, viewable with any web browser such as www/lynx or www/firefox. The default prefix for installed packages is /usr/pkg. If you wish to change this, you should do so by setting LOCALBASE in mk.conf. You should not try to use multiple different LOCALBASE definitions on the same system (inside a chroot is an exception). The rest of this chapter assumes that the package is already in pkgsrc. If it is not, see Part II, "The pkgsrc developer's guide" for instructions how to create your own packages. 4.2.1. Requirements To build packages from source, you need a working C compiler. On NetBSD, you need to install the "comp" and the "text" distribution sets. If you want to build X11-related packages, the "xbase" and "xcomp" distribution sets are required, too. 4.2.2. Fetching distfiles The first step for building a package is downloading the distfiles (i.e. the unmodified source). If they have not yet been downloaded, pkgsrc will fetch them automatically. If you have all files that you need in the distfiles directory, you don't need to connect. If the distfiles are on CD-ROM, you can mount the CD-ROM on /cdrom and add: DISTDIR=/cdrom/pkgsrc/distfiles to your mk.conf. By default a list of distribution sites will be randomly intermixed to prevent huge load on servers which holding popular packages (for example, SourceForge.net mirrors). Thus, every time when you need to fetch yet another distfile all the mirrors will be tried in new (random) order. You can turn this feature off by setting MASTER_SORT_RANDOM=NO (for PKG_DEVELOPERs it's already disabled). You can overwrite some of the major distribution sites to fit to sites that are close to your own. By setting one or two variables you can modify the order in which the master sites are accessed. MASTER_SORT contains a whitespace delimited list of domain suffixes. MASTER_SORT_REGEX is even more flexible, it contains a whitespace delimited list of regular expressions. It has higher priority than MASTER_SORT. Have a look at pkgsrc/mk/defaults/mk.conf to find some examples. 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 mk.conf file, and adding the definitions there. If a package depends on many other packages (such as meta-pkgs/kde3), the build process may alternate between periods of downloading source, and compiling. To ensure you have all the source downloaded initially you can run the command: % make fetch-list | sh which will output and run a set of shell commands to fetch the necessary files into the distfiles directory. You can also choose to download the files manually. 4.2.3. How to build and install Once the software has downloaded, any patches will be applied, then it will be compiled for you. This may take some time depending on your computer, and how many other packages the software depends on and their compile time. Note If using bootstrap or pkgsrc on a non-NetBSD system, use the pkgsrc bmake command instead of "make" in the examples in this guide. For example, type % cd misc/figlet % make at the shell prompt to build the various components of the package. The next stage is to actually install the newly compiled program onto your system. Do this by entering: % make install while you are still in the directory for whatever package you are installing. Installing the package on your system may require 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. That's it, the software should now be installed and setup for use. You can now enter: % make clean to remove the compiled files in the work directory, as you shouldn't need them any more. If other packages were also added to your system (dependencies) to allow your program to compile, you can tidy these up also with the command: % make clean-depends Taking the figlet utility as an example, we can install it on our system by building as shown in Appendix B, Build logs. The program is installed under the default root of the packages tree - /usr/ pkg. Should this not conform to your tastes, 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 directory which is dedicated to packages and not shared with other programs (i.e., do not try and use LOCALBASE=/usr). Also, you should not try to add any of your own files or directories (such as src/, obj/, or pkgsrc/) below the LOCALBASE tree. This is to prevent possible conflicts between programs and other files installed by the package system and whatever else may have been installed there. Some packages look in mk.conf to alter some configuration options at build time. Have a look at pkgsrc/mk/defaults/mk.conf to get an overview of what will be set there by default. Environment variables such as LOCALBASE can be set in 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. to show the expansion of the make(1) variable LOCALBASE: % make show-var VARNAME=LOCALBASE /usr/pkg % If you want to install a binary package that you've either created yourself (see next section), that you put into pkgsrc/packages manually or that is located on a remote FTP server, you can use the "bin-install" target. This target will install a binary package - if available - via pkg_add(1), else do a make package. The list of remote FTP sites searched is kept in the variable BINPKG_SITES, which defaults to ftp.NetBSD.org. Any flags that should be added to pkg_add(1) can be put into BIN_INSTALL_FLAGS. See pkgsrc/mk/defaults/mk.conf for more details. A final word of warning: If you set up a system that has a non-standard setting for LOCALBASE, be sure to set that before any packages are installed, as you cannot 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 5. Configuring pkgsrc Table of Contents 5.1. General configuration 5.2. Variables affecting the build process 5.3. Variables affecting the installation process 5.4. Selecting and configuring the compiler 5.4.1. Selecting the compiler 5.4.2. Additional flags to the compiler (CFLAGS) 5.4.3. Additional flags to the linker (LDFLAGS) 5.5. Developer/advanced settings 5.6. Selecting Build Options The whole pkgsrc system is configured in a single file, usually called mk.conf. In which directory pkgsrc looks for that file depends on the installation. On NetBSD, when you use make(1) from the base system, it is in the directory /etc /. In all other cases the default location is ${PREFIX}/etc/, depending on where you told the bootstrap program to install the binary packages. During the bootstrap, an example configuration file is created. To use that, you have to create the directory ${PREFIX}/etc and copy the example file there. The format of the configuration file is that of the usual BSD-style Makefiles. The whole pkgsrc configuration is done by setting variables in this file. Note that you can define all kinds of variables, and no special error checking (for example for spelling mistakes) takes place, so you have to try it out to see if it works. 5.1. General configuration In this section, you can find some variables that apply to all pkgsrc packages. A complete list of the variables that can be configured by the user is available in mk/defaults/mk.conf, together with some comments that describe each variable's intent. * LOCALBASE: Where packages will be installed. The default is /usr/pkg. Do not mix binary packages with different LOCALBASEs! * CROSSBASE: Where "cross" category packages will be installed. The default is ${LOCALBASE}/cross. * X11BASE: Where X11 is installed on the system. The default is /usr/X11R6. * DISTDIR: Where to store the downloaded copies of the original source distributions used for building pkgsrc packages. The default is $ {PKGSRCDIR}/distfiles. * PKG_DBDIR: Where the database about installed packages is stored. The default is /var/db/pkg. * MASTER_SITE_OVERRIDE: If set, override the packages' MASTER_SITES with this value. * MASTER_SITE_BACKUP: Backup location(s) for distribution files and patch files if not found locally or in ${MASTER_SITES} or ${PATCH_SITES} respectively. The defaults are ftp://ftp.NetBSD.org/pub/NetBSD/packages/ distfiles/${DIST_SUBDIR}/ and ftp://ftp.freebsd.org/pub/FreeBSD/distfiles/$ {DIST_SUBDIR}/. * BINPKG_SITES: List of sites carrying binary pkgs. rel and arch are replaced with OS release ("2.0", etc.) and architecture ("mipsel", etc.). * ACCEPTABLE_LICENSES: List of acceptable licenses. Whenever you try to build a package whose license is not in this list, you will get an error message that includes instructions on how to change this variable. 5.2. Variables affecting the build process XXX * PACKAGES: The top level directory for the binary packages. The default is $ {PKGSRCDIR}/packages. * WRKOBJDIR: The top level directory where, if defined, the separate working directories will get created, and symbolically linked to from ${WRKDIR} (see below). This is useful for building packages on several architectures, then ${PKGSRCDIR} can be NFS-mounted while ${WRKOBJDIR} is local to every architecture. (It should be noted that PKGSRCDIR should not be set by the user ? it is an internal definition which refers to the root of the pkgsrc tree. It is possible to have many pkgsrc tree instances.) * LOCALPATCHES: Directory for local patches that aren't part of pkgsrc. See Section 11.3, "patches/*" for more information. * PKGMAKECONF: Location of the mk.conf file used by a package's BSD-style Makefile. If this is not set, MAKECONF is set to /dev/null to avoid picking up settings used by builds in /usr/src. * DEPENDS_TARGET: By default, dependencies are only installed, and no binary package is created for them. You can set this variable to package to automatically create binary packages after installing dependencies. 5.3. Variables affecting the installation process A growing number of packages support installation into a subdirectory of WRKDIR. This allows a package to be built, before the actual filesystem is touched. DESTDIR support exists in two variations: * Basic DESTDIR support means that the package installation and packaging is still run as root. * Full DESTDIR support can run the complete build, installation and packaging as normal user. Root privileges are only needed to add packages. To use the DESTDIR support, set either USE_DESTDIR=yes to use the basic support for packages that offer it or USE_DESTDIR=full to get the full support with fallback to basic support. USE_DESTDIR=full needs pkgtools/pkg_install version 20070802 (or newer). It might become the default DESTDIR support later. DESTDIR support changes the behaviour of various targets slightly. To install a package after building it, use package-install. package and install don't do that any longer. package-install can be used as DEPENDS_TARGET. bin-install will ask for the root password to install the package and fail, package-install will ask again. With basic DESTDIR support, make clean needs to be run as root. 5.4. Selecting and configuring the compiler 5.4.1. Selecting the compiler By default, pkgsrc will use GCC to build packages. This may be overridden by setting the following variables in /etc/mk.conf: PKGSRC_COMPILER: This is a list of values specifying the chain of compilers to invoke when building packages. Valid values are: * distcc: distributed C/C++ (chainable) * ccache: compiler cache (chainable) * gcc: GNU C/C++ Compiler * mipspro: Silicon Graphics, Inc. MIPSpro (n32/n64) * mipspro: Silicon Graphics, Inc. MIPSpro (o32) * sunpro: Sun Microsystems, Inc. WorkShip/Forte/Sun ONE Studio The default is "gcc". You can use ccache and/or distcc with an appropriate PKGSRC_COMPILER setting, e.g. "ccache gcc". This variable should always be terminated with a value for a real compiler. Note that only one real compiler should be listed (e.g. "sunpro gcc" is not allowed). GCC_REQD: This specifies the minimum version of GCC to use when building packages. If the system GCC doesn't satisfy this requirement, then pkgsrc will build and install one of the GCC packages to use instead. 5.4.2. Additional flags to the compiler (CFLAGS) If you wish to set the CFLAGS variable, please make sure to use the += operator instead of the = operator: CFLAGS+= -your -flags Using CFLAGS= (i.e. without the "+") may lead to problems with packages that need to add their own flags. Also, you may want to take a look at the devel/ cpuflags package if you're interested in optimization for the current CPU. 5.4.3. Additional flags to the linker (LDFLAGS) If you want to pass flags to the linker, both in the configure step and the build step, you can do this in two ways. Either set LDFLAGS or LIBS. The difference between the two is that LIBS will be appended to the command line, while LDFLAGS come earlier. LDFLAGS is pre-loaded with rpath settings for ELF machines depending on the setting of USE_IMAKE or the inclusion of mk/ x11.buildlink3.mk. As with CFLAGS, if you do not wish to override these settings, use the += operator: LDFLAGS+= -your -linkerflags 5.5. Developer/advanced settings XXX * PKG_DEVELOPER: Run some sanity checks that package developers want: o make sure patches apply with zero fuzz o run check-shlibs to see that all binaries will find their shared libs. * PKG_DEBUG_LEVEL: The level of debugging output which is displayed whilst making and installing the package. The default value for this is 0, which will not display the commands as they are executed (normal, default, quiet operation); the value 1 will display all shell commands before their invocation, and the value 2 will display both the shell commands before their invocation, and their actual execution progress with set -x will be displayed. 5.6. Selecting Build Options Some packages have build time options, usually to select between different dependencies, enable optional support for big dependencies or enable experimental features. To see which options, if any, a package supports, and which options are mutually exclusive, run make show-options, for example: The following options are supported by this package: ssl Enable SSL support. Exactly one of the following gecko options is required: firefox Use firefox as gecko rendering engine. mozilla Use mozilla as gecko rendering engine. At most one of the following database options may be selected: mysql Enable support for MySQL database. pgsql Enable support for PostgreSQL database. These options are enabled by default: firefox These options are currently enabled: mozilla ssl The following variables can be defined in mk.conf to select which options to enable for a package: PKG_DEFAULT_OPTIONS, which can be used to select or disable options for all packages that support them, and PKG_OPTIONS.pkgbase, which can be used to select or disable options specifically for package pkgbase . Options listed in these variables are selected, options preceded by "-" are disabled. A few examples: $ grep "PKG.*OPTION" mk.conf PKG_DEFAULT_OPTIONS= -arts -dvdread -esound PKG_OPTIONS.kdebase= debug -sasl PKG_OPTIONS.apache= suexec It is important to note that options that were specifically suggested by the package maintainer must be explicitely removed if you do not wish to include the option. If you are unsure you can view the current state with make show-options. The following settings are consulted in the order given, and the last setting that selects or disables an option is used: 1. the default options as suggested by the package maintainer 2. the options implied by the settings of legacy variables (see below) 3. PKG_DEFAULT_OPTIONS 4. PKG_OPTIONS.pkgbase For groups of mutually exclusive options, the last option selected is used, all others are automatically disabled. If an option of the group is explicitly disabled, the previously selected option, if any, is used. It is an error if no option from a required group of options is selected, and building the package will fail. Before the options framework was introduced, build options were selected by setting a variable (often named USE_FOO) in mk.conf for each option. To ease transition to the options framework for the user, these legacy variables are converted to the appropriate options setting (PKG_OPTIONS.pkgbase) automatically. A warning is issued to prompt the user to update mk.conf to use the options framework directly. Support for the legacy variables will be removed eventually. Chapter 6. Creating binary packages Table of Contents 6.1. Building a single binary package 6.2. Settings for creation of binary packages 6.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. To create a binary package, change into the appropriate directory in pkgsrc, and run make package: # cd misc/figlet # make package This will build and install your package (if not already done), and then build a binary package from what was installed. You can then use the pkg_* tools to manipulate it. Binary packages are created by default in /usr/pkgsrc/packages, in the form of a gzipped tar file. See Section B.2, "Packaging figlet" for a continuation of the above misc/figlet example. See Chapter 21, Submitting and Committing for information on how to submit such a binary package. 6.2. Settings for creation of binary packages See Section 17.17, "Other helpful targets". Chapter 7. Creating binary packages for everything in pkgsrc (bulk builds) Table of Contents 7.1. Think first, build later 7.2. Requirements of a bulk build 7.3. Running an old-style bulk build 7.3.1. Configuration 7.3.2. Other environmental considerations 7.3.3. Operation 7.3.4. What it does 7.3.5. Disk space requirements 7.3.6. Setting up a sandbox for chrooted builds 7.3.7. Building a partial set of packages 7.3.8. Uploading results of a bulk build 7.4. Running a pbulk-style bulk build 7.4.1. Configuration 7.5. Creating a multiple CD-ROM packages collection 7.5.1. Example of cdpack When you have multiple machines that should run the same packages, it is wasted time if they all build their packages themselves from source. There are two ways of getting a set of binary packages: The old bulk build system, or the new (as of 2007) parallel bulk build (pbulk) system. This chapter describes how to set them up so that the packages are most likely to be usable later. 7.1. Think first, build later Since a bulk build takes several days or even weeks to finish, you should think about the setup before you start everything. Pay attention to at least the following points: * If you want to upload the binary packages to ftp.NetBSD.org, make sure the setup complies to the requirements for binary packages: o To end up on ftp.NetBSD.org, the packages must be built by a NetBSD developer on a trusted machine (that is, where you and only you have root access). o Packages on ftp.NetBSD.org should only be created from the stable branches (like 2007Q1), so that users browsing the available collections can see at a glance how old the packages are. o The packages must be built as root, since some packages require set-uid binaries at runtime, and creating those packages as unprivileged user doesn't work well at the moment. * Make sure that the bulk build cannot break anything in your system. Most bulk builds run as root, so they should be run at least in a chroot environment or something even more restrictive, depending on what the operating system provides. There have been numerous cases where certain packages tried to install files outside the LOCALBASE or wanted to edit some files in /etc. Furthermore, the bulk builds install and deinstall packages in /usr/pkg (or whatever LOCALBASE is) during their operation, so be sure that you don't need any package during the build. 7.2. Requirements of a bulk build A complete bulk build requires lots of disk space. Some of the disk space can be read-only, some other must be writable. Some can be on remote filesystems (such as NFS) and some should be local. Some can be temporary filesystems, others must survive a sudden reboot. * 10 GB for the distfiles (read-write, remote, temporary) * 10 GB for the binary packages (read-write, remote, permanent) * 400 MB for the pkgsrc tree (read-only, remote, permanent) * 5 GB for LOCALBASE (read-write, local, temporary for pbulk, permanent for old-bulk) * 5 GB for the log files (read-write, remote, permanent) * 5 GB for temporary files (read-write, local, temporary) 7.3. Running an old-style bulk build Warning The rest of this section is rather old. Don't rely on it too much. 7.3.1. Configuration 7.3.1.1. build.conf The build.conf file is the main configuration file for bulk builds. You can configure how your copy of pkgsrc is kept up to date, how the distfiles are downloaded, how the packages are built and how the report is generated. You can find an annotated example file in pkgsrc/mk/bulk/build.conf-example. To use it, copy build.conf-example to build.conf and edit it, following the comments in that file. 7.3.1.2. mk.conf You may want to set variables in mk.conf. Look at pkgsrc/mk/defaults/mk.conf for details of the default settings. You will want to ensure that ACCEPTABLE_LICENSES meet your local policy. As used in this example, _ACCEPTABLE=yes completely bypasses the license check. PACKAGES?= ${_PKGSRCDIR}/packages/${MACHINE_ARCH} WRKOBJDIR?= /usr/tmp/pkgsrc # build here instead of in pkgsrc BSDSRCDIR= /usr/src BSDXSRCDIR= /usr/xsrc # for x11/xservers OBJHOSTNAME?= yes # use work.`hostname` FAILOVER_FETCH= yes # insist on the correct checksum PKG_DEVELOPER?= yes _ACCEPTABLE= yes Some options that are especially useful for bulk builds can be found at the top lines of the file mk/bulk/bsd.bulk-pkg.mk. The most useful options of these are briefly described here. * If you are on a slow machine, you may want to set USE_BULK_BROKEN_CHECK to "no". * If you are doing bulk builds from a read-only copy of pkgsrc, you have to set BULKFILESDIR to the directory where all log files are created. Otherwise the log files are created in the pkgsrc directory. * Another important variable is BULK_PREREQ, which is a list of packages that should be always available while building other packages. Some other options are scattered in the pkgsrc infrastructure: * ALLOW_VULNERABLE_PACKAGES should be set to yes. The purpose of the bulk builds is creating binary packages, no matter if they are vulnerable or not. When uploading the packages to a public server, the vulnerable packages will be put into a directory of their own. Leaving this variable unset would prevent the bulk build system from even trying to build them, so possible building errors would not show up. * CHECK_FILES (pkgsrc/mk/check/check-files.mk) can be set to "yes" to check that the installed set of files matches the PLIST. * CHECK_INTERPRETER (pkgsrc/mk/check/check-interpreter.mk) can be set to "yes" to check that the installed "#!"-scripts will find their interpreter. * PKGSRC_RUN_TEST can be set to "yes" to run each package's self-test before installing it. Note that some packages make heavy use of "good" random numbers, so you need to assure that the machine on which you are doing the bulk builds is not completely idle. Otherwise some test programs will seem to hang, while they are just waiting for new random data to be available. 7.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." \ > misc/openoffice/$BROKENF to prevent the system from trying to build a particular package which requires nearly 3 GB of disk space. 7.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 passwd file), or (re-)install it via pkg_add(1) from /etc/rc.local, so you can login after a reboot (remember that your current process won't die if the package is removed, you just can't start any new instances of the shell any more). Also, if you use NetBSD earlier than 1.5, or you still want to use the pkgsrc version of ssh for some reason, be sure to install ssh before starting it from rc.local: (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! :) 7.3.3. Operation Make sure you don't need any of the packages still installed. Warning During the bulk build, all packages, their configuration files and some more files from /var, /home and possibly other locations will be removed! So don't run a bulk build with privileges that might harm your system. 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 build, you will get a summary via mail, and find build logs in the directory specified by FTP in the build.conf file. 7.3.4. What it does The bulk builds consist of three steps: 1. pre-build The script updates your pkgsrc tree 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 dependencies 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. 7.3.5. Disk space requirements Currently, roughly the following requirements are valid for NetBSD 2.0/i386: * 10 GB - distfiles (NFS ok) * 8 GB - full set of all binaries (NFS ok) * 5 GB - temp space for compiling (local disk recommended) Note that all pkgs will be de-installed as soon as they are turned into a binary package, and that sources are removed, so there is no excessively huge demand to disk space. Afterwards, if the package is needed again, it will be installed via pkg_add(1) instead of building again, so there are no cycles wasted by recompiling. 7.3.6. Setting up a sandbox for chrooted builds If you don't want all the packages nuked from a machine (rendering it useless for anything but pkg compiling), there is the possibility of doing the package bulk build inside a chroot environment. The first step is to set up a chroot sandbox, e.g. /usr/sandbox. This can be done by using null mounts, or manually. There is a shell script called pkgsrc/mk/bulk/mksandbox which will set up the sandbox environment using null mounts. It will also create a script called sandbox in the root of the sandbox environment, which will allow the null mounts to be activated using the sandbox mount command and deactivated using the sandbox umount command. To set up a sandbox environment by hand, after extracting all the sets from a NetBSD installation or doing a make distribution DESTDIR=/usr/sandbox in /usr/ src/etc, be sure the following items are present and properly configured: 1. Kernel # cp /netbsd /usr/sandbox 2. /dev/* # cd /usr/sandbox/dev ; sh MAKEDEV all 3. /etc/resolv.conf (for security/smtpd and mail): # cp /etc/resolv.conf /usr/sandbox/etc 4. Working(!) mail config (hostname, sendmail.cf): # cp /etc/mail/sendmail.cf /usr/sandbox/etc/mail 5. /etc/localtime (for security/smtpd): # ln -sf /usr/share/zoneinfo/UTC /usr/sandbox/etc/localtime 6. /usr/src (system sources, e. g. for sysutils/aperture): # ln -s ../disk1/cvs . # ln -s cvs/src-2.0 src 7. Create /var/db/pkg (not part of default install): # mkdir /usr/sandbox/var/db/pkg 8. Create /usr/pkg (not part of default install): # mkdir /usr/sandbox/usr/pkg 9. Checkout pkgsrc via cvs into /usr/sandbox/usr/pkgsrc: # cd /usr/sandbox/usr # cvs -d anoncvs@anoncvs.NetBSD.org:/cvsroot checkout -d -P pkgsrc Do not mount/link this to the copy of your pkgsrc tree you do development in, as this will likely cause problems! 10. Make /usr/sandbox/usr/pkgsrc/packages and .../distfiles point somewhere appropriate. NFS- and/or nullfs-mounts may come in handy! 11. Edit mk.conf, see Section 7.3.1.2, "mk.conf". 12. Adjust mk/bulk/build.conf to suit your needs. When the chroot sandbox is set up, you can start the build with the following steps: # 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). 7.3.7. Building a partial set of packages In addition to building a complete set of all packages in pkgsrc, the pkgsrc/mk /bulk/build script may be used to build a subset of the packages contained in pkgsrc. By setting SPECIFIC_PKGS in mk.conf, the variables * SITE_SPECIFIC_PKGS * HOST_SPECIFIC_PKGS * GROUP_SPECIFIC_PKGS * USER_SPECIFIC_PKGS will define the set of packages which should be built. The bulk build code will also include any packages which are needed as dependencies for the explicitly listed packages. One use of this is to do a bulk build with SPECIFIC_PKGS in a chroot sandbox periodically to have a complete set of the binary packages needed for your site available without the overhead of building extra packages that are not needed. 7.3.8. Uploading results of a bulk build This section describes how pkgsrc developers can upload binary pkgs built by bulk builds to ftp.NetBSD.org. If you would like to automatically create checksum files for the binary packages you intend to upload, remember to set MKSUMS=yes in your mk/bulk/ build.conf. If you would like to PGP sign the checksum files (highly recommended!), remember to set SIGN_AS=username@NetBSD.org in your mk/bulk/build.conf. This will prompt you for your GPG password to sign the files before uploading everything. Then, make sure that you have RSYNC_DST set properly in your mk/bulk/build.conf file, i.e. adjust it to something like one of the following: RSYNC_DST=ftp.NetBSD.org:/pub/NetBSD/packages/packages-200xQy/NetBSD-a.b.c/arch/upload Please use appropriate values for "packages-200xQy", "NetBSD-a.b.c" and "arch" here. If your login on ftp.NetBSD.org is different from your local login, write your login directly into the variable, e.g. my local account is "feyrer", but for my login "hubertf", I use: RSYNC_DST=hubertf@ftp.NetBSD.org:/pub/NetBSD/packages/packages-200xQy/NetBSD-a.b.c/arch/upload A separate upload directory is used here to allow "closing" the directory during upload. To do so, run the following command on ftp.NetBSD.org next: nbftp% mkdir -p -m 750 /pub/NetBSD/packages/packages-200xQy/NetBSD-a.b.c/arch/upload Please note that /pub/NetBSD/packages is only appropriate for packages for the NetBSD operating system. Binary packages for other operating systems should go into /pub/pkgsrc. Before uploading the binary pkgs, ssh authentication needs to be set up. This example shows how to set up temporary keys for the root account inside the sandbox (assuming that no keys should be present there usually): # chroot /usr/sandbox chroot-# rm $HOME/.ssh/id-dsa* chroot-# ssh-keygen -t dsa chroot-# cat $HOME/.ssh/id-dsa.pub Now take the output of id-dsa.pub and append it to your ~/.ssh/authorized_keys file on ftp.NetBSD.org. You can remove the key after the upload is done! Next, test if your ssh connection really works: chroot-# ssh ftp.NetBSD.org date Use "-l yourNetBSDlogin" here as appropriate! Now after all this works, you can exit the sandbox and start the upload: chroot-# exit # cd /usr/sandbox/usr/pkgsrc # sh mk/bulk/do-sandbox-upload The upload process may take quite some time. Use ls(1) or du(1) on the FTP server to monitor progress of the upload. The upload script will take care of not uploading restricted packages and putting vulnerable packages into the vulnerable subdirectory. After the upload has ended, first thing is to revoke ssh access: nbftp% vi ~/.ssh/authorized_keys Gdd:x! Use whatever is needed to remove the key you've entered before! Last, move the uploaded packages out of the upload directory to have them accessible to everyone: nbftp% cd /pub/NetBSD/packages/packages-200xQy/NetBSD-a.b.c/arch nbftp% mv upload/* . nbftp% rmdir upload nbftp% chmod 755 . 7.4. Running a pbulk-style bulk build 7.4.1. Configuration TODO; see pkgsrc/doc/HOWTO-pbulk for more information. 7.5. Creating a multiple CD-ROM packages collection After your pkgsrc bulk-build has completed, you may wish to create a CD-ROM set of the resulting binary packages to assist in installing packages on other machines. The pkgtools/cdpack package provides a simple tool for creating the ISO 9660 images. cdpack arranges the packages on the CD-ROMs in a way that keeps all the dependencies for a given package on the same CD as that package. 7.5.1. Example of cdpack Complete documentation for cdpack is found in the cdpack(1) man page. The following short example assumes that the binary packages are left in /usr/ pkgsrc/packages/All and that sufficient disk space exists in /u2 to 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. Chapter 8. Directory layout of the installed files Table of Contents 8.1. File system layout in ${LOCALBASE} 8.2. File system layout in ${VARBASE} The files that are installed by pkgsrc are organized in a way that is similar to what you find in the /usr directory of the base system. But some details are different. This is because pkgsrc initially came from FreeBSD and had adopted its file system hierarchy. Later it was largely influenced by NetBSD. But no matter which operating system you are using pkgsrc with, you can expect the same layout for pkgsrc. There are mainly four root directories for pkgsrc, which are all configurable in the bootstrap/bootstrap script. When pkgsrc has been installed as root, the default locations are: LOCALBASE= /usr/pkg PKG_SYSCONFBASE= /usr/pkg/etc VARBASE= /var PKG_DBDIR= /var/db/pkg In unprivileged mode (when pkgsrc has been installed as any other user), the default locations are: LOCALBASE= ${HOME}/pkg PKG_SYSCONFBASE= ${HOME}/pkg/etc VARBASE= ${HOME}/pkg/var PKG_DBDIR= ${HOME}/pkg/var/db/pkg What these four directories are for, and what they look like is explained below. * LOCALBASE corresponds to the /usr directory in the base system. It is the "main" directory where the files are installed and contains the well-known subdirectories like bin, include, lib, share and sbin. * VARBASE corresponds to /var in the base system. Some programs (especially games, network daemons) need write access to it during normal operation. * PKG_SYSCONFDIR corresponds to /etc in the base system. It contains configuration files of the packages, as well as pkgsrc's mk.conf itself. 8.1. File system layout in ${LOCALBASE} The following directories exist in a typical pkgsrc installation in $ {LOCALBASE}. bin Contains executable programs that are intended to be directly used by the end user. emul Contains files for the emulation layers of various other operating systems, especially for NetBSD. etc (the usual location of ${PKG_SYSCONFDIR}) Contains the configuration files. include Contains headers for the C and C++ programming languages. info Contains GNU info files of various packages. lib Contains shared and static libraries. libdata Contains data files that don't change after installation. Other data files belong into ${VARBASE}. libexec Contains programs that are not intended to be used by end users, such as helper programs or network daemons. libexec/cgi-bin Contains programs that are intended to be executed as CGI scripts by a web server. man (the usual value of ${PKGMANDIR}) Contains brief documentation in form of manual pages. sbin Contains programs that are intended to be used only by the super-user. share Contains platform-independent data files that don't change after installation. share/doc Contains documentation files provided by the packages. share/examples Contains example files provided by the packages. Among others, the original configuration files are saved here and copied to ${PKG_SYSCONFDIR} during installation. share/examples/rc.d Contains the original files for rc.d scripts. var (the usual location of ${VARBASE}) Contains files that may be modified after installation. 8.2. File system layout in ${VARBASE} db/pkg (the usual location of ${PKG_DBDIR}) Contains information about the currently installed packages. games Contains highscore files. log Contains log files. run Contains informational files about daemons that are currently running. Chapter 9. Frequently Asked Questions Table of Contents 9.1. Are there any mailing lists for pkg-related discussion? 9.2. Where's the pkgviews documentation? 9.3. Utilities for package management (pkgtools) 9.4. How to use pkgsrc as non-root 9.5. How to resume transfers when fetching distfiles? 9.6. How can I install/use modular X.org from pkgsrc? 9.7. How to fetch files from behind a firewall 9.8. How do I tell make fetch to do passive FTP? 9.9. How to fetch all distfiles at once 9.10. What does "Don't know how to make /usr/share/tmac/tmac.andoc" mean? 9.11. What does "Could not find bsd.own.mk" mean? 9.12. Using 'sudo' with pkgsrc 9.13. How do I change the location of configuration files? 9.14. Automated security checks 9.15. Why do some packages ignore my CFLAGS? 9.16. A package does not build. What shall I do? 9.17. What does "Makefile appears to contain unresolved cvs/rcs/??? merge conflicts" mean? This section contains hints, tips & tricks on special things in pkgsrc that we didn't find a better place for in the previous chapters, and it contains items for both pkgsrc users and developers. 9.1. Are there any mailing lists for pkg-related discussion? The following mailing lists may be of interest to pkgsrc users: * pkgsrc-users: This is a general purpose list for most issues regarding pkgsrc, regardless of platform, e.g. soliciting user help for pkgsrc configuration, unexpected build failures, using particular packages, upgrading pkgsrc installations, questions regarding the pkgsrc release branches, etc. General announcements or proposals for changes that impact the pkgsrc user community, e.g. major infrastructure changes, new features, package removals, etc., may also be posted. * pkgsrc-bulk: A list where the results of pkgsrc bulk builds are sent and discussed. * pkgsrc-changes: This list is for those who are interested in getting a commit message for every change committed to pkgsrc. It is also available in digest form, meaning one daily message containing all commit messages for changes to the package source tree in that 24 hour period. To subscribe, do: % echo subscribe listname | mail majordomo@NetBSD.org Archives for all these mailing lists are available from http:// mail-index.NetBSD.org/. 9.2. Where's the pkgviews documentation? Pkgviews is tightly integrated with buildlink. You can find a pkgviews User's guide in pkgsrc/mk/buildlink3/PKGVIEWS_UG. 9.3. Utilities for package management (pkgtools) The directory pkgsrc/pkgtools contains a number of useful utilities for both users and developers of pkgsrc. This section attempts only to make the reader aware of the utilities and when they might be useful, and not to duplicate the documentation that comes with each package. Utilities used by pkgsrc (automatically installed when needed): * pkgtools/x11-links: Symlinks for use by buildlink. OS tool augmentation (automatically installed when needed): * pkgtools/digest: Calculates various kinds of checksums (including SHA1). * pkgtools/libnbcompat: Compatibility library for pkgsrc tools. * pkgtools/mtree: Installed on non-BSD systems due to lack of native mtree. * pkgtools/pkg_install: Up-to-date replacement for /usr/sbin/pkg_install, or for use on operating systems where pkg_install is not present. Utilities used by pkgsrc (not automatically installed): * pkgtools/pkg_tarup: Create a binary package from an already-installed package. Used by make replace to save the old package. * pkgtools/dfdisk: Adds extra functionality to pkgsrc, allowing it to fetch distfiles from multiple locations. It currently supports the following methods: multiple CD-ROMs and network FTP/HTTP connections. * pkgtools/xpkgwedge: Put X11 packages someplace else (enabled by default). * devel/cpuflags: Determine the best compiler flags to optimise code for your current CPU and compiler. Utilities for keeping track of installed packages, being up to date, etc: * pkgtools/pkg_chk: Reports on packages whose installed versions do not match the latest pkgsrc entries. * pkgtools/pkgdep: Makes dependency graphs of packages, to aid in choosing a strategy for updating. * pkgtools/pkgdepgraph: Makes graphs from the output of pkgtools/pkgdep (uses graphviz). * pkgtools/pkglint: The pkglint(1) program checks a pkgsrc entry for errors. * pkgtools/lintpkgsrc: The lintpkgsrc(1) program does various checks on the complete pkgsrc system. * pkgtools/pkgsurvey: Report what packages you have installed. Utilities for people maintaining or creating individual packages: * pkgtools/pkgdiff: Automate making and maintaining patches for a package (includes pkgdiff, pkgvi, mkpatches, etc.). * pkgtools/rpm2pkg, pkgtools/url2pkg: Aids in converting to pkgsrc. * pkgtools/gensolpkg: Convert pkgsrc to a Solaris package. Utilities for people maintaining pkgsrc (or: more obscure pkg utilities) * pkgtools/pkg_comp: Build packages in a chrooted area. * pkgtools/libkver: Spoof kernel version for chrooted cross builds. 9.4. How to use pkgsrc as non-root If you want to use pkgsrc as non-root user, you can set some variables to make pkgsrc work under these conditions. At the very least, you need to set UNPRIVILEGED to "yes"; this will turn on unprivileged mode and set multiple related variables to allow installation of packages as non-root. In case the defaults are not enough, you may want to tune some other variables used. For example, if the automatic user/group detection leads to incorrect values (or not the ones you would like to use), you can change them by setting UNPRIVILEGED_USER and UNPRIVILEGED_GROUP respectively. As regards bootstrapping, please note that the bootstrap script will ease non-root configuration when given the "--ignore-user-check" flag, as it will choose and use multiple default directories under ~/pkg as the installation targets. These directories can be overridden by the "--prefix" flag provided by the script, as well as some others that allow finer tuning of the tree layout. 9.5. How to resume transfers when fetching distfiles? By default, resuming transfers in pkgsrc is disabled, but you can enable this feature by adding the option PKG_RESUME_TRANSFERS=YES into mk.conf. If, during a fetch step, an incomplete distfile is found, pkgsrc will try to resume it. You can also use a different program than the default ftp(1) by changing the FETCH_CMD variable. Don't forget to set FETCH_RESUME_ARGS and FETCH_OUTPUT_ARGS if you are not using default values. For example, if you want to use wget to resume downloads, you'll have to use something like: FETCH_CMD= wget FETCH_BEFORE_ARGS= --passive-ftp FETCH_RESUME_ARGS= -c FETCH_OUTPUT_ARGS= -O -nc 9.6. How can I install/use modular X.org from pkgsrc? If you want to use modular X.org from pkgsrc instead of your system's own X11 (/usr/X11R6, /usr/openwin, ...) you will have to add the following line into mk.conf: X11_TYPE=modular Note The DragonFly operating system defaults to using modular X.org from pkgsrc. 9.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/ 9.8. 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: * ${LOCALBASE}/bin/ftp * /usr/bin/ftp On a default NetBSD installation, 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 mk.conf file: PASSIVE_FETCH=1. Having that option present will prevent /usr/bin/ftp from falling back to active transfers. 9.9. 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 or one of its subdirectories, carry the resulting list to your machine at work/school and use it there. If you don't have a NetBSD-compatible ftp(1) (like tnftp) at work, don't forget to set FETCH_CMD to something that fetches a 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 9.10. 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 (nroff, ...) from the NetBSD base distribution on your machine. It is recommended to do that to format man pages. In the case of the pkgtools/pkg_install package, you can get away with setting NOMAN=YES either in the environment or in mk.conf. 9.11. What does "Could not find bsd.own.mk" mean? You didn't install the compiler set, comp.tgz, when you installed your NetBSD machine. Please get 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). 9.12. 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 mk.conf, somewhere after the definition of the LOCALBASE variable: .if exists(${LOCALBASE}/bin/sudo) SU_CMD= ${LOCALBASE}/bin/sudo /bin/sh -c .endif 9.13. How do I change the location of configuration files? As the system administrator, you can choose where configuration files are installed. The default settings make all these files go into ${PREFIX}/etc or some of its subdirectories; this may be suboptimal depending on your expectations (e.g., a read-only, NFS-exported PREFIX with a need of per-machine configuration of the provided packages). In order to change the defaults, you can modify the PKG_SYSCONFBASE variable (in mk.conf) to point to your preferred configuration directory; some common examples include /etc or /etc/pkg. Furthermore, you can change this value on a per-package basis by setting the PKG_SYSCONFDIR.${PKG_SYSCONFVAR} variable. PKG_SYSCONFVAR's value usually matches the name of the package you would like to modify, that is, the contents of PKGBASE. Note that after changing these settings, you must rebuild and reinstall any affected packages. 9.14. Automated security checks 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, refer to the following two tools (installed as part of the pkgtools/pkg_install package): 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/pkg-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 these tools is strongly recommended! After "pkg_install" is installed, please read the package's message, which you can get by running pkg_info -D pkg_install. If this package is installed, pkgsrc builds will use it to perform a security check before building any package. See Section 5.2, "Variables affecting the build process" for ways to control this check. 9.15. Why do some packages ignore my CFLAGS? When you add your own preferences to the CFLAGS variable in your mk.conf, these flags are passed in environment variables to the ./configure scripts and to make(1). Some package authors ignore the CFLAGS from the environment variable by overriding them in the Makefiles of their package. Currently there is no solution to this problem. If you really need the package to use your CFLAGS you should run make patch in the package directory and then inspect any Makefile and Makefile.in for whether they define CFLAGS explicitly. Usually you can remove these lines. But be aware that some "smart" programmers write so bad code that it only works for the specific combination of CFLAGS they have chosen. 9.16. A package does not build. What shall I do? 1. Make sure that your copy of pkgsrc is consistent. A case that occurs often is that people only update pkgsrc in parts, because of performance reasons. Since pkgsrc is one large system, not a collection of many small systems, there are sometimes changes that only work when the whole pkgsrc tree is updated. 2. Make sure that you don't have any CVS conflicts. Search for "<<<<<<" or ">>>>>>" in all your pkgsrc files. 3. Make sure that you don't have old copies of the packages extracted. Run make clean clean-depends to verify this. 4. If the problem still exists, write a mail to the pkgsrc-users mailing list. 9.17. What does "Makefile appears to contain unresolved cvs/rcs/??? merge conflicts" mean? You have modified a file from pkgsrc, and someone else has modified that same file afterwards in the CVS repository. Both changes are in the same region of the file, so when you updated pkgsrc, the cvs command marked the conflicting changes in the file. Because of these markers, the file is no longer a valid Makefile. Have a look at that file, and if you don't need your local changes anymore, you can remove that file and run cvs -q update -dP in that directory to download the current version. Part II. The pkgsrc developer's guide This part of the book deals with creating and modifying packages. It starts with a "HOWTO"-like guide on creating a new package. The remaining chapters are more like a reference manual for pkgsrc. Table of Contents 10. Creating a new pkgsrc package from scratch 10.1. Common types of packages 10.1.1. Perl modules 10.1.2. KDE applications 10.2. Examples 10.2.1. How the www/nvu package came into pkgsrc 11. Package components - files, directories and contents 11.1. Makefile 11.2. distinfo 11.3. patches/* 11.3.1. Structure of a single patch file 11.3.2. Creating patch files 11.3.3. Sources where the patch files come from 11.3.4. Patching guidelines 11.3.5. Feedback to the author 11.4. Other mandatory files 11.5. Optional files 11.5.1. Files affecting the binary package 11.5.2. Files affecting the build process 11.5.3. Files affecting nothing at all 11.6. work* 11.7. files/* 12. Programming in Makefiles 12.1. Caveats 12.2. Makefile variables 12.2.1. Naming conventions 12.3. Code snippets 12.3.1. Adding things to a list 12.3.2. Converting an internal list into an external list 12.3.3. Passing variables to a shell command 12.3.4. Quoting guideline 12.3.5. Workaround for a bug in BSD Make 13. PLIST issues 13.1. RCS ID 13.2. Semi-automatic PLIST generation 13.3. Tweaking output of make print-PLIST 13.4. Variable substitution in PLIST 13.5. Man page compression 13.6. Changing PLIST source with PLIST_SRC 13.7. Platform-specific and differing PLISTs 13.8. Sharing directories between packages 14. Buildlink methodology 14.1. Converting packages to use buildlink3 14.2. Writing buildlink3.mk files 14.2.1. Anatomy of a buildlink3.mk file 14.2.2. Updating BUILDLINK_API_DEPENDS.pkg in buildlink3.mk files 14.3. Writing builtin.mk files 14.3.1. Anatomy of a builtin.mk file 14.3.2. Global preferences for native or pkgsrc software 15. The pkginstall framework 15.1. Files and directories outside the installation prefix 15.1.1. Directory manipulation 15.1.2. File manipulation 15.2. Configuration files 15.2.1. How PKG_SYSCONFDIR is set 15.2.2. Telling the software where configuration files are 15.2.3. Patching installations 15.2.4. Disabling handling of configuration files 15.3. System startup scripts 15.3.1. Disabling handling of system startup scripts 15.4. System users and groups 15.5. System shells 15.5.1. Disabling shell registration 15.6. Fonts 15.6.1. Disabling automatic update of the fonts databases 16. Options handling 16.1. Global default options 16.2. Converting packages to use bsd.options.mk 16.3. Option Names 16.4. Determining the options of dependencies 17. The build process 17.1. Introduction 17.2. Program location 17.3. Directories used during the build process 17.4. Running a phase 17.5. The fetch phase 17.5.1. What to fetch and where to get it from 17.5.2. How are the files fetched? 17.6. The checksum phase 17.7. The extract phase 17.8. The patch phase 17.9. The tools phase 17.10. The wrapper phase 17.11. The configure phase 17.12. The build phase 17.13. The test phase 17.14. The install phase 17.15. The package phase 17.16. Cleaning up 17.17. Other helpful targets 18. Tools needed for building or running 18.1. Tools for pkgsrc builds 18.2. Tools needed by packages 18.3. Tools provided by platforms 18.4. Questions regarding the tools 19. Making your package work 19.1. General operation 19.1.1. Portability of packages 19.1.2. How to pull in user-settable variables from mk.conf 19.1.3. User interaction 19.1.4. Handling licenses 19.1.5. Restricted packages 19.1.6. Handling dependencies 19.1.7. Handling conflicts with other packages 19.1.8. Packages that cannot or should not be built 19.1.9. Packages which should not be deleted, once installed 19.1.10. Handling packages with security problems 19.1.11. How to handle incrementing versions when fixing an existing package 19.1.12. Substituting variable text in the package files (the SUBST framework) 19.2. Fixing problems in the fetch phase 19.2.1. Packages whose distfiles aren't available for plain downloading 19.2.2. How to handle modified distfiles with the 'old' name 19.3. Fixing problems in the configure phase 19.3.1. Shared libraries - libtool 19.3.2. Using libtool on GNU packages that already support libtool 19.3.3. GNU Autoconf/Automake 19.4. Programming languages 19.4.1. C, C++, and Fortran 19.4.2. Java 19.4.3. Packages containing perl scripts 19.4.4. Other programming languages 19.5. Fixing problems in the build phase 19.5.1. Compiling C and C++ code conditionally 19.5.2. How to handle compiler bugs 19.5.3. Undefined reference to "..." 19.5.4. Running out of memory 19.6. Fixing problems in the install phase 19.6.1. Creating needed directories 19.6.2. Where to install documentation 19.6.3. Installing highscore files 19.6.4. Adding DESTDIR support to packages 19.6.5. Packages with hardcoded paths to other interpreters 19.6.6. Packages installing perl modules 19.6.7. Packages installing info files 19.6.8. Packages installing man pages 19.6.9. Packages installing GConf data files 19.6.10. Packages installing scrollkeeper data files 19.6.11. Packages installing X11 fonts 19.6.12. Packages installing GTK2 modules 19.6.13. Packages installing SGML or XML data 19.6.14. Packages installing extensions to the MIME database 19.6.15. Packages using intltool 19.6.16. Packages installing startup scripts 19.6.17. Packages installing TeX modules 19.6.18. Packages supporting running binaries in emulation 19.6.19. Packages installing hicolor theme icons 19.6.20. Packages installing desktop files 19.7. Marking packages as having problems 20. Debugging 21. Submitting and Committing 21.1. Submitting binary packages 21.2. Submitting source packages (for non-NetBSD-developers) 21.3. General notes when adding, updating, or removing packages 21.4. Committing: Importing a package into CVS 21.5. Updating a package to a newer version 21.6. Moving a package in pkgsrc 22. Frequently Asked Questions 23. GNOME packaging and porting 23.1. Meta packages 23.2. Packaging a GNOME application 23.3. Updating GNOME to a newer version 23.4. Patching guidelines Chapter 10. Creating a new pkgsrc package from scratch Table of Contents 10.1. Common types of packages 10.1.1. Perl modules 10.1.2. KDE applications 10.2. Examples 10.2.1. How the www/nvu package came into pkgsrc When you find a package that is not yet in pkgsrc, you most likely have a URL from where you can download the source code. Starting with this URL, creating a package involves only a few steps. 1. First, install the packages pkgtools/url2pkg and pkgtools/pkglint. 2. Then, choose one of the top-level directories as the category in which you want to place your package. You can also create a directory of your own (maybe called local). In that category directory, create another directory for your package and change into it. 3. Run the program url2pkg, which will ask you for a URL. Enter the URL of the distribution file (in most cases a .tar.gz file) and watch how the basic ingredients of your package are created automatically. The distribution file is extracted automatically to fill in some details in the Makefile that would otherwise have to be done manually. 4. Examine the extracted files to determine the dependencies of your package. Ideally, this is mentioned in some README file, but things may differ. For each of these dependencies, look where it exists in pkgsrc, and if there is a file called buildlink3.mk in that directory, add a line to your package Makefile which includes that file just before the last line. If the buildlink3.mk file does not exist, add a DEPENDS line to the Makefile, which specifies the version of the dependency and where it can be found in pkgsrc. This line should be placed in the third paragraph. If the dependency is only needed for building the package, but not when using it, use BUILD_DEPENDS instead of DEPENDS. Your package may then look like this: [...] BUILD_DEPENDS+= lua>=5.0:../../lang/lua DEPENDS+= screen-[0-9]*:../../misc/screen DEPENDS+= screen>=4.0:../../misc/screen [...] .include "../../category/package/buildlink3.mk" .include "../../devel/glib2/buildlink3.mk" .include "../../mk/bsd.pkg.mk" 5. Run pkglint to see what things still need to be done to make your package a "good" one. If you don't know what pkglint's warnings want to tell you, try pkglint --explain or pkglint -e, which outputs additional explanations. 6. In many cases the package is not yet ready to build. You can find instructions for the most common cases in the next section, Section 10.1, "Common types of packages". After you have followed the instructions over there, you can hopefully continue here. 7. Run bmake clean to clean the working directory from the extracted files. Besides these files, a lot of cache files and other system information has been saved in the working directory, which may become wrong after you edited the Makefile. 8. Now, run bmake to build the package. For the various things that can go wrong in this phase, consult Chapter 19, Making your package work. 9. When the package builds fine, the next step is to install the package. Run bmake install and hope that everything works. 10. Up to now, the file PLIST, which contains a list of the files that are installed by the package, is nearly empty. Run bmake print-PLIST >PLIST to generate a probably correct list. Check the file using your preferred text editor to see if the list of files looks plausible. 11. Run pkglint again to see if the generated PLIST contains garbage or not. 12. When you ran bmake install, the package has been registered in the database of installed files, but with an empty list of files. To fix this, run bmake deinstall and bmake install again. Now the package is registered with the list of files from PLIST. 13. Run bmake package to create a binary package from the set of installed files. 10.1. Common types of packages 10.1.1. Perl modules Simple Perl modules are handled automatically by url2pkg, including dependencies. 10.1.2. KDE applications KDE applications should always include meta-pkgs/kde3/kde3.mk, which contains numerous settings that are typical of KDE packages. 10.2. Examples 10.2.1. How the www/nvu package came into pkgsrc 10.2.1.1. The initial package Looking at the file pkgsrc/doc/TODO, I saw that the "nvu" package has not yet been imported into pkgsrc. As the description says it has to do with the web, the obvious choice for the category is "www". $ mkdir www/nvu $ cd www/nvu The web site says that the sources are available as a tar file, so I fed that URL to the url2pkg program: $ url2pkg http://cvs.nvu.com/download/nvu-1.0-sources.tar.bz2 My editor popped up, and I added a PKGNAME line below the DISTNAME line, as the package name should not have the word "sources" in it. I also filled in the MAINTAINER, HOMEPAGE and COMMENT fields. Then the package Makefile looked like that: # $NetBSD: pkgsrc.txt,v 1.14 2008/07/27 19:32:42 jmcneill Exp $ # DISTNAME= nvu-1.0-sources PKGNAME= nvu-1.0 CATEGORIES= www MASTER_SITES= http://cvs.nvu.com/download/ EXTRACT_SUFX= .tar.bz2 MAINTAINER= rillig@NetBSD.org HOMEPAGE= http://cvs.nvu.com/ COMMENT= Web Authoring System # url2pkg-marker (please do not remove this line.) .include "../../mk/bsd.pkg.mk" Then, I quit the editor and watched pkgsrc downloading a large source archive: url2pkg> Running "make makesum" ... => Required installed package digest>=20010302: digest-20060826 found => Fetching nvu-1.0-sources.tar.bz2 Requesting http://cvs.nvu.com/download/nvu-1.0-sources.tar.bz2 100% |*************************************| 28992 KB 150.77 KB/s00:00 ETA 29687976 bytes retrieved in 03:12 (150.77 KB/s) url2pkg> Running "make extract" ... => Required installed package digest>=20010302: digest-20060826 found => Checksum SHA1 OK for nvu-1.0-sources.tar.bz2 => Checksum RMD160 OK for nvu-1.0-sources.tar.bz2 work.bacc -