Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP
Fetching contributors…

Cannot retrieve contributors at this time

9224 lines (6625 sloc) 370.465 kB
The pkgsrc guide
Documentation on the NetBSD packages system
Alistair Crooks
<agc@NetBSD.org>
Hubert Feyrer
<hubertf@NetBSD.org>
The pkgsrc Developers
Copyright 1994-2007 The NetBSD Foundation, Inc
$NetBSD: pkgsrc.xml,v 1.26 2007/09/18 08:17:21 rillig 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 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. Preparation
7.4.2. 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.1.3. Python modules and programs
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 and
BUILDLINK_ABI_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/rarian 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: Adding a package to CVS
21.5. Updating a package to a newer version
21.6. Renaming a package in pkgsrc
21.7. 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. distfiles: The distributed source files
C.2. misc: Miscellaneous things
C.3. packages: Binary packages
C.4. reports: Bulk build reports
C.5. current, pkgsrc-20xxQy: 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 a new 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 |
|---------------------------------------------+------------------|
|Haiku | Sep 2010 |
+----------------------------------------------------------------+
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 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. Preparation
7.4.2. 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 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
2009Q1.
The second step is to decide how you want to download pkgsrc. You can get it as
a tar file or via CVS. Both 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 2009Q1 is in the directory pkgsrc-2009Q1 and
is also called pkgsrc-2009Q1.tar.gz.
To download a pkgsrc stable tarball, run:
$ ftp ftp://ftp.NetBSD.org/pub/pkgsrc/pkgsrc-20xxQy/pkgsrc-20xxQy.tar.gz
Where pkgsrc-20xxQy is the stable branch to be downloaded, for example, "
pkgsrc-2009Q1".
Then, extract it with:
$ tar -xzf pkgsrc-20xxQy.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 anonymous CVS
To fetch a specific pkgsrc stable branch, run:
$ cd /usr && cvs -q -z3 -d anoncvs@anoncvs.NetBSD.org:/cvsroot checkout -r pkgsrc-20xxQy -P pkgsrc
Where pkgsrc-20xxQy is the stable branch to be checked out, for example, "
pkgsrc-2009Q1"
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 -q -z3 -d anoncvs@anoncvs.NetBSD.org:/cvsroot checkout -P pkgsrc
Refer to the list of available mirrors to choose a faster CVS mirror, if
needed.
If you get error messages from rsh, you need to set CVS_RSH variable. E.g.:
$ cd /usr && env CVS_RSH=ssh cvs -q -z3 -d anoncvs@anoncvs.NetBSD.org:/cvsroot checkout -P pkgsrc
Refer to documentation on your command shell how to set CVS_RSH=ssh
permanently. For Bourne shells, you can set it in your .profile or better
globally in /etc/profile:
# set CVS remote shell command
CVS_RSH=ssh
export CVS_RSH
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
cvs -q -z3
checkout -P
update -dP
diff -upN
rdiff -u
release -d
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, change to the pkgsrc directory and run cvs:
$ cd /usr/pkgsrc && cvs update -dP
If you get error messages from rsh, you need to set CVS_RSH variable as
described above. E.g.:
$ cd /usr/pkgsrc && env CVS_RSH=ssh cvs up -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-2009Q3" 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. 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
(an optional package included with the Developer Tools) if you intend to build
packages that use the X11 Window System.
3.3.2. FreeBSD
FreeBSD 8.3 and 9.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 (5.2), Windows Vista and Windows Server 2008 (6.0), Windows 7
and Windows Server 2008 R2 (6.1). As of this writing, the SUA's Interix 6.0
(32bit) and 6.1 (64bit) subsystems have been tested. Other versions may work as
well. The 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 ICCBASE=/opt/intel/cc/10.1.008 ./bootstrap --compiler=icc
Note
For icc 8.0 you must add `LDFLAGS=-static-libcxa' to this.
For icc 8.1 you must add `LDFLAGS=-i-static' instead.
For icc 10.1 neither of these appears to be necessary.
Use a value for ICCBASE that corresponds to the directory where icc is
installed. After bootstrapping, set ICCBASE in mk.conf:
ICCBASE= /opt/intel/cc/10.1.008
The pkgsrc default for ICCBASE is /opt/intel_cc_80. This is the default install
directory for icc 8.0. If you are using a more recent version, be sure to set
the correct path explicitly.
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 5.1 has been tested and supported, other versions may work.
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 10 are supported on both x86 and sparc. You will need a
working C compiler. Both gcc 4.5.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/gcc46 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).
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.
Adding packages might install vulnerable packages. Thus you should run
pkg_admin audit 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 pkg_admin fetch-pkg-vulnerabilities, 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 auditing. The first step, pkg_admin
fetch-pkg-vulnerabilities, is for downloading the list of vulnerabilities from
the NetBSD FTP site. The second step, pkg_admin audit, 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
You may wish to have the vulnerabilities file downloaded daily so that it
remains current. This may be done by adding an appropriate entry to the root
users crontab(5) entry. For example the entry
# download vulnerabilities file
0 3 * * * /usr/sbin/pkg_admin fetch-pkg-vulnerabilities >/dev/null 2>&1
will update the vulnerability list every day at 3AM. You may wish to do this
more often than once a day. In addition, you may wish to run the package audit
from the daily security script. This may be accomplished by adding the
following line to /etc/security.local:
/usr/sbin/pkg_admin audit
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/pkgsrc/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. License names are
case-sensitive. Whenever you try to build a package whose license is not in
this list, you will get an error message. If the license condition is
simple enough, the error message will include specific 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
Most 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.
DESTDIR support is now the default. To switch back to non-DESTDIR, you can set
USE_DESTDIR=no; this setting will be deprecated though, so it's preferable to
convert a package to DESTDIR instead.
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.
Considering the foo/bar package, DESTDIR full support can be tested using the
following commands
$ id
uid=1000(myusername) gid=100(users) groups=100(users),0(wheel)
$ mkdir $HOME/packages
$ cd $PKGSRCDIR/foo/bar
Verify DESTDIR full support, no root privileges should be needed
$ make USE_DESTDIR=yes install
Create a package without root privileges
$ make USE_DESTDIR=yes PACKAGES=$HOME/packages package
For the following command, you must be able to gain root privileges using su(1)
$ make USE_DESTDIR=yes PACKAGES=$HOME/packages package-install
Then, as a simple user
$ make clean
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. You may want to take a look at the devel/cpuflags
package if you're interested in optimization specifically 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 explicitly 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. Preparation
7.4.2. 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 2009Q1), 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
Note
There are two ways of doing a bulk build. The old-style one and the new-style "
pbulk". The latter is the recommended way.
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,
SKIP_LICENSE_CHECK=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
SKIP_LICENSE_CHECK= 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. 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 mksandbox installed by the pkgtools/mksandbox
package, 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/pkgsrc/packages/NetBSD/arch/a.b.c-20xxQy/upload
Please use appropriate values for "20xxQy" (the branch), "a.b.c" (the OS
version) 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/pkgsrc/packages/NetBSD/arch/a.b.c-20xxQy/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/pkgsrc/packages/NetBSD/arch/a.b.c-20xxQy/upload
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 rsa
chroot-# cat $HOME/.ssh/id-rsa.pub
Now take the output of id-rsa.pub and append it to your ~/.ssh/authorized_keys
file on ftp.NetBSD.org. You should 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.
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/pkgsrc/packages/NetBSD/arch/a.b.c-20xxQy
nbftp% mv upload/* .
nbftp% rmdir upload
nbftp% chgrp -R netbsd .
nbftp% find . -type d | xargs chmod 775
7.4. Running a pbulk-style bulk build
Running a pbulk-style bulk build works roughly as follows:
* First, build the pbulk infrastructure in a fresh pkgsrc location.
* Then, build each of the packages from a clean installation directory using
the infrastructure.
7.4.1. Preparation
First, you need to create a pkgsrc installation for the pbulk infrastructure.
No matter on which platform you are (even on NetBSD), you should bootstrap into
its own directory. Let's take the directory /usr/pbulk or $HOME/pbulk for it.
This installation will be bootstrapped and all the tools that are required for
the bulk build will be installed there.
$ cd /usr/pkgsrc
$ ./bootstrap/bootstrap --prefix=/usr/pbulk --varbase=/usr/pbulk/var --workdir=/tmp/pbulk-bootstrap
$ rm -rf /tmp/pbulk-bootstrap
Now the basic environment for the pbulk infrastructure is installed. The
specific tools are still missing. This is a good time to edit the pkgsrc
configuration file /usr/pbulk/etc/mk.conf to fit your needs. Typical things you
might set now are:
* PKG_DEVELOPER=yes, to enable many consistency checks,
* WRKOBJDIR=/tmp/pbulk-outer, to keep /usr/pkgsrc free from any
modifications,
* DISTDIR=/distfiles, to have only one directory in which all distfiles (for
the infrastructure and for the actual packages) are downloaded,
* ACCEPTABLE_LICENSES+=..., to select some licenses additional to the usual
Free/Open Source licenses that are acceptable to you,
* SKIP_LICENSE_CHECK=yes, to bypass the license checks.
Now you are ready to build the rest of the pbulk infrastructure.
$ cd pkgtools/pbulk
$ /usr/pbulk/bin/bmake install
$ rm -rf /tmp/pbulk-outer
Now the pbulk infrastructure is built and installed. It still needs to be
configured, and after some more preparation, we will be able to start the real
bulk build.
7.4.2. Configuration
TODO; see pkgsrc/doc/HOWTO-pbulk for more information.
TODO: continue writing
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_USING variable. You can specify the program by using of ftp, fetch, wget
or curl. Alternatively, fetching can be disabled by using the value manual. A
value of custom disables the system defaults and dependency tracking for the
fetch program. In that case you have to provide FETCH_CMD, FETCH_BEFORE_ARGS,
FETCH_RESUME_ARGS, FETCH_OUTPUT_ARGS, FETCH_AFTER_ARGS.
For example, if you want to use wget to download, you'll have to use something
like:
FETCH_USING= wget
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. pkg_admin fetch-pkg-vulnerabilities, an easy way to download a list of the
security vulnerabilities information. This list is kept up to date by the
pkgsrc security team, and is distributed from the NetBSD ftp server:
ftp://ftp.NetBSD.org/pkgsrc/distfiles/pkg-vulnerabilities
2. pkg_admin audit, an easy way to audit the current machine, checking each
known vulnerability. 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.1.3. Python modules and programs
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 and BUILDLINK_ABI_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/rarian 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: Adding a package to CVS
21.5. Updating a package to a newer version
21.6. Renaming a package in pkgsrc
21.7. 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.1.3. Python modules and programs
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, it must be created first. The
buildlink3.mk file makes sure that the package's include files and
libraries are provided.
If you just need binaries from a package, 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.1.3. Python modules and programs
Python modules and programs packages are easily created using a set of
predefined variables.
Most Python packages use either "distutils" or easy-setup ("eggs"). If the
software uses "distutils", set the PYDISTUTILSPKG variable to "yes" so pkgsrc
will make use of this framework. "distutils" uses a script called setup.py, if
the "distutils" driver is not called setup.py, set the PYSETUP variable to the
name of the script.
If the default Python versions are not supported by the software, set the
PYTHON_VERSIONS_ACCEPTED variable to the Python versions the software is known
to work with, from the most recent to the older one, e.g.
PYTHON_VERSIONS_ACCEPTED= 25 24
If the packaged software is a Python module, include "../../lang/python/
extension.mk". In this case, the package directory should be called "
py-software" and PKGNAME should be set to "${PYPKGPREFIX}-${DISTNAME}", e.g.
DISTNAME= foopymodule-1.2.10
PKGNAME= ${PYPKGPREFIX}-${DISTNAME}
If it is an application, also include "../../lang/python/application.mk" before
"extension.mk".
If the packaged software, either it is an application or a module, is
egg-aware, you only need to include "../../lang/python/egg.mk".
In order to correctly set the path to the Python interpreter, use the
REPLACE_PYTHON variable and set it to the list of files (paths relative to
WRKSRC) that must be corrected. For example :
REPLACE_PYTHON= *.py
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$
#
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 -> /tmp/roland/pkgsrc/www/nvu/work.bacc
===> Installing dependencies for nvu-1.0
===> Overriding tools for nvu-1.0
===> Extracting for nvu-1.0
url2pkg> Adjusting the Makefile.
Remember to correct CATEGORIES, HOMEPAGE, COMMENT, and DESCR when you're done!
Good luck! (See pkgsrc/doc/pkgsrc.txt for some more help :-)
10.2.1.2. Fixing all kinds of problems to make the package work
Now that the package has been extracted, let's see what's inside it. The
package has a README.txt, but that only says something about mozilla, so it's
probably useless for seeing what dependencies this package has. But since there
is a GNU configure script in the package, let's hope that it will complain
about everything it needs.
$ bmake
=> 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
===> Patching for nvu-1.0
===> Creating toolchain wrappers for nvu-1.0
===> Configuring for nvu-1.0
[...]
configure: error: Perl 5.004 or higher is required.
[...]
WARNING: Please add USE_TOOLS+=perl to the package Makefile.
[...]
That worked quite well. So I opened the package Makefile in my editor, and
since it already has a USE_TOOLS line, I just appended "perl" to it. Since the
dependencies of the package have changed now, and since a perl wrapper is
automatically installed in the "tools" phase, I need to build the package from
scratch.
$ bmake clean
===> Cleaning for nvu-1.0
$ bmake
[...]
*** /tmp/roland/pkgsrc/www/nvu/work.bacc/.tools/bin/make is not \
GNU Make. You will not be able to build Mozilla without GNU Make.
[...]
So I added "gmake" to the USE_TOOLS line and tried again (from scratch).
[...]
checking for GTK - version >= 1.2.0... no
*** Could not run GTK test program, checking why...
[...]
Now to the other dependencies. The first question is: Where is the GTK package
hidden in pkgsrc?
$ echo ../../*/gtk*
[many packages ...]
$ echo ../../*/gtk
../../x11/gtk
$ echo ../../*/gtk2
../../x11/gtk2
$ echo ../../*/gtk2/bui*
../../x11/gtk2/buildlink3.mk
The first try was definitely too broad. The second one had exactly one result,
which is very good. But there is one pitfall with GNOME packages. Before GNOME
2 had been released, there were already many GNOME 1 packages in pkgsrc. To be
able to continue to use these packages, the GNOME 2 packages were imported as
separate packages, and their names usually have a "2" appended. So I checked
whether this was the case here, and indeed it was.
Since the GTK2 package has a buildlink3.mk file, adding the dependency is very
easy. I just inserted an .include line before the last line of the package
Makefile, so that it now looks like this:
[...]
.include "../../x11/gtk2/buildlink3.mk"
.include "../../mk/bsd.pkg.mk
After another bmake clean && bmake, the answer was:
[...]
checking for gtk-config... /home/roland/pkg/bin/gtk-config
checking for GTK - version >= 1.2.0... no
*** Could not run GTK test program, checking why...
*** The test program failed to compile or link. See the file config.log for the
*** exact error that occured. This usually means GTK was incorrectly installed
*** or that you have moved GTK since it was installed. In the latter case, you
*** may want to edit the gtk-config script: /home/roland/pkg/bin/gtk-config
configure: error: Test for GTK failed.
[...]
In this particular case, the assumption that "every package prefers GNOME 2"
had been wrong. The first of the lines above told me that this package really
wanted to have the GNOME 1 version of GTK. If the package had looked for GTK2,
it would have looked for pkg-config instead of gtk-config. So I changed the x11
/gtk2 to x11/gtk in the package Makefile, and tried again.
[...]
cc -o xpidl.o -c -DOSTYPE=\"NetBSD3\" -DOSARCH=\"NetBSD\" -I../../../dist/include/xpcom -I../../../dist/include -I/tmp/roland/pkgsrc/www/nvu/work.bacc/mozilla/dist/include/nspr -I/usr/X11R6/include -fPIC -DPIC -I/home/roland/pkg/include -I/usr/include -I/usr/X11R6/include -Wall -W -Wno-unused -Wpointer-arith -Wcast-align -Wno-long-long -pedantic -O2 -I/home/roland/pkg/include -I/usr/include -Dunix -pthread -pipe -DDEBUG -D_DEBUG -DDEBUG_roland -DTRACING -g -I/home/roland/pkg/include/glib/glib-1.2 -I/home/roland/pkg/lib/glib/include -I/usr/pkg/include/orbit-1.0 -I/home/roland/pkg/include -I/usr/include -I/usr/X11R6/include -include ../../../mozilla-config.h -DMOZILLA_CLIENT -Wp,-MD,.deps/xpidl.pp xpidl.c
In file included from xpidl.c:42:
xpidl.h:53:24: libIDL/IDL.h: No such file or directory
In file included from xpidl.c:42:
xpidl.h:132: error: parse error before "IDL_ns"
[...]
The package still does not find all of its dependencies. Now the question is:
Which package provides the libIDL/IDL.h header file?
$ echo ../../*/*idl*
../../devel/py-idle ../../wip/idled ../../x11/acidlaunch
$ echo ../../*/*IDL*
../../net/libIDL
Let's take the one from the second try. So I included the ../../net/libIDL/
buildlink3.mk file and tried again. But the error didn't change. After digging
through some of the code, I concluded that the build process of the package was
broken and couldn't have ever worked, but since the Mozilla source tree is
quite large, I didn't want to fix it. So I added the following to the package
Makefile and tried again:
CPPFLAGS+= -I${BUILDLINK_PREFIX.libIDL}/include/libIDL-2.0
BUILDLINK_TRANSFORM+= -l:IDL:IDL-2
The latter line is needed because the package expects the library libIDL.so,
but only libIDL-2.so is available. So I told the compiler wrapper to rewrite
that on the fly.
The next problem was related to a recent change of the FreeType interface. I
looked up in www/seamonkey which patch files were relevant for this issue and
copied them to the patches directory. Then I retried, fixed the patches so that
they applied cleanly and retried again. This time, everything worked.
10.2.1.3. Installing the package
$ bmake CHECK_FILES=no install
[...]
$ bmake print-PLIST >PLIST
$ bmake deinstall
$ bmake install
Chapter 11. Package components - files, directories and contents
Table of 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/*
Whenever you're preparing a package, there are a number of files involved which
are described in the following sections.
11.1. Makefile
Building, installation and creation of a binary package are all controlled by
the package's Makefile. The Makefile describes various things about a package,
for example from where to get it, how to configure, build, and install it.
A package Makefile contains several sections that describe the package.
In the first section there are the following variables, which should appear
exactly in the order given here. The order and grouping of the variables is
mostly historical and has no further meaning.
* DISTNAME is the basename of the distribution file to be downloaded from the
package's website.
* PKGNAME is the name of the package, as used by pkgsrc. You only need to
provide it if DISTNAME (which is the default) is not a good name for the
package in pkgsrc. Usually it is the pkgsrc directory name together with
the version number. It must match the regular expression ^[A-Za-z0-9]
[A-Za-z0-9-_.+]*$, that is, it starts with a letter or digit, and contains
only letters, digits, dashes, underscores, dots and plus signs.
* SVR4_PKGNAME is the name of the package file to create if the PKGNAME isn't
unique on a SVR4 system. The default is PKGNAME, which may be shortened
when you use pkgtools/gensolpkg. Only add SVR4_PKGNAME if PKGNAME does not
produce an unique package name on a SVR4 system. The length of SVR4_PKGNAME
is limited to 5 characters.
* CATEGORIES is a list of categories which the package fits in. You can
choose any of the top-level directories of pkgsrc for it.
Currently the following values are available for CATEGORIES. If more than
one is used, they need to be separated by spaces:
archivers cross geography meta-pkgs security
audio databases graphics misc shells
benchmarks devel ham multimedia sysutils
biology editors inputmethod net textproc
cad emulators lang news time
chat finance mail parallel wm
comms fonts math pkgtools www
converters games mbone print x11
* MASTER_SITES, DYNAMIC_MASTER_SITES, DIST_SUBDIR, EXTRACT_SUFX and DISTFILES
are discussed in detail in Section 17.5, "The fetch phase".
The second section contains information about separately downloaded patches, if
any.
* PATCHFILES: Name(s) of additional files that contain distribution patches.
There is no default. pkgsrc will look for them at PATCH_SITES. They will
automatically be uncompressed before patching if the names end with .gz or
.Z.
* PATCH_SITES: Primary location(s) for distribution patch files (see
PATCHFILES below) if not found locally.
The third section contains the following variables.
* MAINTAINER is the email address of the person who feels responsible for
this package, and who is most likely to look at problems or questions
regarding this package which have been reported with send-pr(1). Other
developers may contact the MAINTAINER before making changes to the package,
but are not required to do so. When packaging a new program, set MAINTAINER
to yourself. If you really can't maintain the package for future updates,
set it to <pkgsrc-users@NetBSD.org>.
* OWNER should be used instead of MAINTAINER when you do not want other
developers to update or change the package without contacting you first. A
package Makefile should contain one of MAINTAINER or OWNER, but not both.
* HOMEPAGE is a URL where users can find more information about the package.
* COMMENT is a one-line description of the package (should not include the
package name).
Other variables that affect the build:
* WRKSRC: The directory where the interesting distribution files of the
package are found. The default is ${WRKDIR}/${DISTNAME}, which works for
most packages.
If a package doesn't create a subdirectory for itself (most GNU software
does, for instance), but extracts itself in the current directory, you
should set WRKSRC=${WRKDIR}.
If a package doesn't create a subdirectory with the name of DISTNAME but
some different name, set WRKSRC to point to the proper name in ${WRKDIR},
for example WRKSRC=${WRKDIR}/${DISTNAME}/unix. See lang/tcl and x11/tk for
other examples.
The name of the working directory created by pkgsrc is taken from the
WRKDIR_BASENAME variable. By default, its value is work. If you want to use
the same pkgsrc tree for building different kinds of binary packages, you
can change the variable according to your needs. Two other variables handle
common cases of setting WRKDIR_BASENAME individually. If OBJHOSTNAME is
defined in mk.conf, the first component of the host's name is attached to
the directory name. If OBJMACHINE is defined, the platform name is
attached, which might look like work.i386 or work.sparc.
Please pay attention to the following gotchas:
* Add MANCOMPRESSED if man pages are installed in compressed form by the
package. For packages using BSD-style makefiles which honor MANZ, there is
MANCOMPRESSED_IF_MANZ.
* Replace /usr/local with "${PREFIX}" in all files (see patches, below).
* If the package installs any info files, see Section 19.6.7, "Packages
installing info files".
11.2. distinfo
The distinfo file contains the message digest, or checksum, of each distfile
needed for the package. This ensures that the distfiles retrieved from the
Internet have not been corrupted during transfer or altered by a malign force
to introduce a security hole. Due to recent rumor about weaknesses of digest
algorithms, all distfiles are protected using both SHA1 and RMD160 message
digests, as well as the file size.
The distinfo file also contains the checksums for all the patches found in the
patches directory (see Section 11.3, "patches/*").
To regenerate the distinfo file, use the make makedistinfo or make mdi command.
Some packages have different sets of distfiles depending on the platform, for
example lang/openjdk7. These are kept in the same distinfo file and care should
be taken when upgrading such a package to ensure distfile information is not
lost.
11.3. patches/*
Many packages still don't work out-of-the box on the various platforms that are
supported by pkgsrc. Therefore, a number of custom patch files are needed to
make the package work. These patch files are found in the patches/ directory.
In the patch phase, these patches are applied to the files in WRKSRC directory
after extracting them, in alphabetic order.
11.3.1. Structure of a single patch file
The patch-* files should be in diff -bu format, and apply without a fuzz to
avoid problems. (To force patches to apply with fuzz you can set
PATCH_FUZZ_FACTOR=-F2). Furthermore, each patch should contain only changes for
a single file, and no file should be patched by more than one patch file. This
helps to keep future modifications simple.
Each patch file is structured as follows: In the first line, there is the RCS
Id of the patch itself. The second line should be empty for aesthetic reasons.
After that, there should be a comment for each change that the patch does.
There are a number of standard cases:
* Patches for commonly known vulnerabilities should mention the vulnerability
ID (CAN, CVE).
* Patches that change source code should mention the platform and other
environment (for example, the compiler) that the patch is needed for.
In all, the patch should be commented so that any developer who knows the code
of the application can make some use of the patch. Special care should be taken
for the upstream developers, since we generally want that they accept our
patches, so we have less work in the future.
11.3.2. Creating patch files
One important thing to mention is to pay attention that no RCS IDs get stored
in the patch files, as these will cause problems when later checked into the
NetBSD CVS tree. Use the pkgdiff command from the pkgtools/pkgdiff package to
avoid these problems.
For even more automation, we recommend using mkpatches from the same package to
make a whole set of patches. You just have to backup files before you edit them
to filename.orig, e.g. with cp -p filename filename.orig or, easier, by using
pkgvi again from the same package. If you upgrade a package this way, you can
easily compare the new set of patches with the previously existing one with
patchdiff. The files in patches are replaced by new files, so carefully check
if you want to take all the changes.
When you have finished a package, remember to generate the checksums for the
patch files by using the make makepatchsum command, see Section 11.2,
"distinfo".
When adding a patch that corrects a problem in the distfile (rather than e.g.
enforcing pkgsrc's view of where man pages should go), send the patch as a bug
report to the maintainer. This benefits non-pkgsrc users of the package, and
usually makes it possible to remove the patch in future version.
The file names of the patch files are usually of the form patch-
path_to_file__with__underscores.c. Many packages still use the previous
convention patch-[a-z][a-z], but new patches should be of the form containing
the filename. mkpatches included in pkgtools/pkgdiff takes care of the name
automatically.
11.3.3. Sources where the patch files come from
If you want to share patches between multiple packages in pkgsrc, e.g. because
they use the same distfiles, set PATCHDIR to the path where the patch files can
be found, e.g.:
PATCHDIR= ${.CURDIR}/../xemacs/patches
Patch files that are distributed by the author or other maintainers can be
listed in PATCHFILES.
If it is desired to store any patches that should not be committed into pkgsrc,
they can be kept outside the pkgsrc tree in the $LOCALPATCHES directory. The
directory tree there is expected to have the same "category/package" structure
as pkgsrc, and patches are expected to be stored inside these dirs (also known
as $LOCALPATCHES/$PKGPATH). For example, if you want to keep a private patch
for pkgsrc/graphics/png, keep it in $LOCALPATCHES/graphics/png/mypatch. All
files in the named directory are expected to be patch files, and they are
applied after pkgsrc patches are applied.
11.3.4. Patching guidelines
When fixing a portability issue in the code do not use preprocessor magic to
check for the current operating system nor platform. Doing so hurts portability
to other platforms because the OS-specific details are not abstracted
appropriately.
The general rule to follow is: instead of checking for the operating system the
application is being built on, check for the specific features you need. For
example, instead of assuming that kqueue is available under NetBSD and using
the __NetBSD__ macro to conditionalize kqueue support, add a check that detects
kqueue itself ? yes, this generally involves patching the configure script.
There is absolutely nothing that prevents some OSes from adopting interfaces
from other OSes (e.g. Linux implementing kqueue), something that the above
checks cannot take into account.
Of course, checking for features generally involves more work on the
developer's side, but the resulting changes are cleaner and there are chances
they will work on many other platforms. Not to mention that there are higher
chances of being later integrated into the mainstream sources. Remember: It
doesn't work unless it is right!
Some typical examples:
Table 11.1. Patching examples
+-------------------------------------------------------------------------------------------+
| Where | Incorrect | Correct |
|---------+--------------------------+------------------------------------------------------|
| |case ${target_os} in | |
|configure|netbsd*) have_kvm=yes ;; |AC_CHECK_LIB(kvm, kvm_open, have_kvm=yes, have_kvm=no)|
|script |*) have_kvm=no ;; | |
| |esac | |
|---------+--------------------------+------------------------------------------------------|
|C source |#if defined(__NetBSD__) |#if defined(HAVE_SYS_EVENT_H) |
|file |# include <sys/event.h> |# include <sys/event.h> |
| |#endif |#endif |
|---------+--------------------------+------------------------------------------------------|
| |int |int |
| |monitor_file(...) |monitor_file(...) |
| |{ |{ |
| |#if defined(__NetBSD__) |#if defined(HAVE_KQUEUE) |
|C source | int fd = kqueue();| int fd = kqueue(); |
|file | ... | ... |
| |#else |#else |
| | ... | ... |
| |#endif |#endif |
| |} |} |
+-------------------------------------------------------------------------------------------+
For more information, please read the Making packager-friendly software article
(part 1, part 2). It summarizes multiple details on how to make software easier
to package; all the suggestions in it were collected from our experience in
pkgsrc work, so they are possibly helpful when creating patches too.
11.3.5. Feedback to the author
Always, always, always feed back any portability fixes or improvements you do
to a package to the mainstream developers. This is the only way to get their
attention on portability issues and to ensure that future versions can be built
out-of-the box on NetBSD. Furthermore, any user that gets newer distfiles will
get the fixes straight from the packaged code.
This generally involves cleaning up the patches (because sometimes the patches
that are added to pkgsrc are quick hacks), filling bug reports in the
appropriate trackers for the projects and working with the mainstream authors
to accept your changes. It is extremely important that you do it so that the
packages in pkgsrc are kept simple and thus further changes can be done without
much hassle.
When you have done this, please add a URL to the upstream bug report to the
patch comment.
Support the idea of free software!
11.4. Other mandatory files
DESCR
A multi-line description of the piece of software. This should include any
credits where they are due. Please bear in mind that others do not share
your sense of humour (or spelling idiosyncrasies), and that others will
read everything that you write here.
PLIST
This file governs the files that are installed on your system: all the
binaries, manual pages, etc. There are other directives which may be
entered in this file, to control the creation and deletion of directories,
and the location of inserted files. See Chapter 13, PLIST issues for more
information.
11.5. Optional files
11.5.1. Files affecting the binary package
INSTALL
This shell script is invoked twice by pkg_add(1). First time after package
extraction and before files are moved in place, the second time after the
files to install are moved in place. This can be used to do any custom
procedures not possible with @exec commands in PLIST. See pkg_add(1) and
pkg_create(1) for more information. See also Section 15.1, "Files and
directories outside the installation prefix". Please note that you can
modify variables in it easily by using FILES_SUBST in the package's
Makefile:
FILES_SUBST+= SOMEVAR="somevalue"
replaces "@SOMEVAR@" with "somevalue" in the INSTALL. By default,
substitution is performed for PREFIX, LOCALBASE, X11BASE, VARBASE, and a
few others, type make help topic=FILES_SUBST for a complete list.
DEINSTALL
This script is executed before and after any files are removed. It is this
script's responsibility to clean up any additional messy details around the
package's installation, since all pkg_delete knows is how to delete the
files created in the original distribution. See pkg_delete(1) and
pkg_create(1) for more information. The same methods to replace variables
can be used as for the INSTALL file.
MESSAGE
This file is displayed after installation of the package. Useful for things
like legal notices on almost-free software and hints for updating config
files after installing modules for apache, PHP etc. Please note that you
can modify variables in it easily by using MESSAGE_SUBST in the package's
Makefile:
MESSAGE_SUBST+= SOMEVAR="somevalue"
replaces "${SOMEVAR}" with "somevalue" in MESSAGE. By default, substitution
is performed for PKGNAME, PKGBASE, PREFIX, LOCALBASE, X11PREFIX, X11BASE,
PKG_SYSCONFDIR, ROOT_GROUP, and ROOT_USER.
You can display a different or additional files by setting the MESSAGE_SRC
variable. Its default is MESSAGE, if the file exists.
ALTERNATIVES
FIXME: There is no documentation on the alternatives framework.
11.5.2. Files affecting the build process
Makefile.common
This file contains arbitrary things that could also go into a Makefile, but
its purpose is to be used by more than one package. This file should only
be used when the packages that will use the file are known in advance. For
other purposes it is often better to write a *.mk file and give it a good
name that describes what it does.
buildlink3.mk
This file contains the dependency information for the buildlink3 framework
(see Chapter 14, Buildlink methodology).
hacks.mk
This file contains workarounds for compiler bugs and similar things. It is
included automatically by the pkgsrc infrastructure, so you don't need an
extra .include line for it.
options.mk
This file contains the code for the package-specific options (see
Chapter 16, Options handling) that can be selected by the user. If a
package has only one or two options, it is equally acceptable to put the
code directly into the Makefile.
11.5.3. Files affecting nothing at all
README*
These files do not take place in the creation of a package and thus are
purely informative to the package developer.
TODO
This file contains things that need to be done to make the package even
better.
11.6. work*
When you type make, the distribution files are unpacked into the directory
denoted by WRKDIR. It can be removed by running make clean. Besides the
sources, this directory is also used to keep various timestamp files. The
directory gets removed completely on clean. The default is ${.CURDIR}/work or $
{.CURDIR}/work.${MACHINE_ARCH} if OBJMACHINE is set.
11.7. files/*
If you have any files that you wish to be placed in the package prior to
configuration or building, you could place these files here and use a ${CP}
command in the "pre-configure" target to achieve this. Alternatively, you could
simply diff the file against /dev/null and use the patch mechanism to manage
the creation of this file.
If you want to share files in this way with other packages, set the FILESDIR
variable to point to the other package's files directory, e.g.:
FILESDIR=${.CURDIR}/../xemacs/files
Chapter 12. Programming in Makefiles
Table of Contents
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
Pkgsrc consists of many Makefile fragments, each of which forms a well-defined
part of the pkgsrc system. Using the make(1) system as a programming language
for a big system like pkgsrc requires some discipline to keep the code correct
and understandable.
The basic ingredients for Makefile programming are variables (which are
actually macros) and shell commands. Among these shell commands may even be
more complex ones like awk(1) programs. To make sure that every shell command
runs as intended it is necessary to quote all variables correctly when they are
used.
This chapter describes some patterns, that appear quite often in Makefiles,
including the pitfalls that come along with them.
12.1. Caveats
* When you are creating a file as a target of a rule, always write the data
to a temporary file first and finally rename that file. Otherwise there
might occur an error in the middle of generating the file, and when the
user runs make(1) for the second time, the file exists and will not be
regenerated properly. Example:
wrong:
@echo "line 1" > ${.TARGET}
@echo "line 2" >> ${.TARGET}
@false
correct:
@echo "line 1" > ${.TARGET}.tmp
@echo "line 2" >> ${.TARGET}.tmp
@false
@mv ${.TARGET}.tmp ${.TARGET}
When you run make wrong twice, the file wrong will exist, although there
was an error message in the first run. On the other hand, running make
correct gives an error message twice, as expected.
You might remember that make(1) sometimes removes ${.TARGET} in case of
error, but this only happens when it is interrupted, for example by
pressing ^C. This does not happen when one of the commands fails (like
false(1) above).
12.2. Makefile variables
Makefile variables contain strings that can be processed using the five
operators ``='', ``+='', ``?='', ``:='', and ``!='', which are described in the
make(1) man page.
When a variable's value is parsed from a Makefile, the hash character ``#'' and
the backslash character ``\'' are handled specially. If a backslash is followed
by a newline, any whitespace immediately in front of the backslash, the
backslash, the newline, and any whitespace immediately behind the newline are
replaced with a single space. A backslash character and an immediately
following hash character are replaced with a single hash character. Otherwise,
the backslash is passed as is. In a variable assignment, any hash character
that is not preceded by a backslash starts a comment that continues upto the
end of the logical line.
Note: Because of this parsing algorithm the only way to create a variable
consisting of a single backslash is using the ``!='' operator, for example:
BACKSLASH!=echo "\\".
So far for defining variables. The other thing you can do with variables is
evaluating them. A variable is evaluated when it is part of the right side of
the ``:='' or the ``!='' operator, or directly before executing a shell command
which the variable is part of. In all other cases, make(1) performs lazy
evaluation, that is, variables are not evaluated until there's no other way.
The ``modifiers'' mentioned in the man page also evaluate the variable.
Some of the modifiers split the string into words and then operate on the
words, others operate on the string as a whole. When a string is split into
words, it is split as you would expect it from sh(1).
No rule without exception?the .for loop does not follow the shell quoting rules
but splits at sequences of whitespace.
There are several types of variables that should be handled differently.
Strings and two types of lists.
* Strings can contain arbitrary characters. Nevertheless, you should restrict
yourself to only using printable characters. Examples are PREFIX and
COMMENT.
* Internal lists are lists that are never exported to any shell command.
Their elements are separated by whitespace. Therefore, the elements
themselves cannot have embedded whitespace. Any other characters are
allowed. Internal lists can be used in .for loops. Examples are DEPENDS and
BUILD_DEPENDS.
* External lists are lists that may be exported to a shell command. Their
elements can contain any characters, including whitespace. That's why they
cannot be used in .for loops. Examples are DISTFILES and MASTER_SITES.
12.2.1. Naming conventions
* All variable names starting with an underscore are reserved for use by the
pkgsrc infrastructure. They shall not be used by package Makefiles.
* In .for loops you should use lowercase variable names for the iteration
variables.
* All list variables should have a ``plural'' name, e.g. PKG_OPTIONS or
DISTFILES.
12.3. Code snippets
This section presents you with some code snippets you should use in your own
code. If you don't find anything appropriate here, you should test your code
and add it here.
12.3.1. Adding things to a list
STRING= foo * bar `date`
INT_LIST= # empty
ANOTHER_INT_LIST= apache-[0-9]*:../../www/apache
EXT_LIST= # empty
ANOTHER_EXT_LIST= a=b c=d
INT_LIST+= ${STRING} # 1
INT_LIST+= ${ANOTHER_INT_LIST} # 2
EXT_LIST+= ${STRING:Q} # 3
EXT_LIST+= ${ANOTHER_EXT_LIST} # 4
When you add a string to an external list (example 3), it must be quoted. In
all other cases, you must not add a quoting level. You must not merge internal
and external lists, unless you are sure that all entries are correctly
interpreted in both lists.
12.3.2. Converting an internal list into an external list
EXT_LIST= # empty
.for i in ${INT_LIST}
EXT_LIST+= ${i:Q}""
.endfor
This code converts the internal list INT_LIST into the external list EXT_LIST.
As the elements of an internal list are unquoted they must be quoted here. The
reason for appending "" is explained below.
12.3.3. Passing variables to a shell command
Sometimes you may want to print an arbitrary string. There are many ways to get
it wrong and only few that can handle every nastiness.
STRING= foo bar < > * `date` $$HOME ' "
EXT_LIST= string=${STRING:Q} x=second\ item
all:
echo ${STRING} # 1
echo "${STRING}" # 2
echo "${STRING:Q}" # 3
echo ${STRING:Q} # 4
echo x${STRING:Q} | sed 1s,.,, # 5
printf "%s\\n" ${STRING:Q}"" # 6
env ${EXT_LIST} /bin/sh -c 'echo "$$string"; echo "$$x"'
Example 1 leads to a syntax error in the shell, as the characters are just
copied.
Example 2 leads to a syntax error too, and if you leave out the last "
character from ${STRING}, date(1) will be executed. The $HOME shell variable
would be evaluated, too.
Example 3 outputs each space character preceded by a backslash (or not),
depending on the implementation of the echo(1) command.
Example 4 handles correctly every string that does not start with a dash. In
that case, the result depends on the implementation of the echo(1) command. As
long as you can guarantee that your input does not start with a dash, this form
is appropriate.
Example 5 handles even the case of a leading dash correctly.
Example 6 also works with every string and is the light-weight solution, since
it does not involve a pipe, which has its own problems.
The EXT_LIST does not need to be quoted because the quoting has already been
done when adding elements to the list.
As internal lists shall not be passed to the shell, there is no example for it.
12.3.4. Quoting guideline
There are many possible sources of wrongly quoted variables. This section lists
some of the commonly known ones.
* Whenever you use the value of a list, think about what happens to leading
or trailing whitespace. If the list is a well-formed shell expression, you
can apply the :M* modifier to strip leading and trailing whitespace from
each word. The :M operator first splits its argument according to the rules
of the shell, and then creates a new list consisting of all words that
match the shell glob expression *, that is: all. One class of situations
where this is needed is when adding a variable like CPPFLAGS to
CONFIGURE_ARGS. If the configure script invokes other configure scripts, it
strips the leading and trailing whitespace from the variable and then
passes it to the other configure scripts. But these configure scripts
expect the (child) CPPFLAGS variable to be the same as the parent CPPFLAGS.
That's why we better pass the CPPFLAGS value properly trimmed. And here is
how we do it:
CPPFLAGS= # empty
CPPFLAGS+= -Wundef -DPREFIX=\"${PREFIX:Q}\"
CPPFLAGS+= ${MY_CPPFLAGS}
CONFIGURE_ARGS+= CPPFLAGS=${CPPFLAGS:M*:Q}
all:
echo x${CPPFLAGS:Q}x # leading and trailing whitespace
echo x${CONFIGURE_ARGS}x # properly trimmed
* The example above contains one bug: The ${PREFIX} is a properly quoted
shell expression, but there is the C compiler after it, which also expects
a properly quoted string (this time in C syntax). The version above is
therefore only correct if ${PREFIX} does not have embedded backslashes or
double quotes. If you want to allow these, you have to add another layer of
quoting to each variable that is used as a C string literal. You cannot use
the :Q operator for it, as this operator only works for the shell.
* Whenever a variable can be empty, the :Q operator can have surprising
results. Here are two completely different cases which can be solved with
the same trick.
EMPTY= # empty
empty_test:
for i in a ${EMPTY:Q} c; do \
echo "$$i"; \
done
for_test:
.for i in a:\ a:\test.txt
echo ${i:Q}
echo "foo"
.endfor
The first example will only print two of the three lines we might have
expected. This is because ${EMPTY:Q} expands to the empty string, which the
shell cannot see. The workaround is to write ${EMPTY:Q}"". This pattern can
be often found as ${TEST} -z ${VAR:Q} or as ${TEST} -f ${FNAME:Q} (both of
these are wrong).
The second example will only print three lines instead of four. The first
line looks like a:\ echo foo. This is because the backslash of the value a:
\ is interpreted as a line-continuation by make(1), which makes the second
line the arguments of the echo(1) command from the first line. To avoid
this, write ${i:Q}"".
12.3.5. Workaround for a bug in BSD Make
The pkgsrc bmake program does not handle the following assignment correctly. In
case _othervar_ contains a ``-'' character, one of the closing braces is
included in ${VAR} after this code executes.
VAR:= ${VAR:N${_othervar_:C/-//}}
For a more complex code snippet and a workaround, see the package regress/
make-quoting, testcase bug1.
Chapter 13. PLIST issues
Table of Contents
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
The PLIST file contains a package's "packing list", i.e. a list of files that
belong to the package (relative to the ${PREFIX} directory it's been installed
in) plus some additional statements - see the pkg_create(1) man page for a full
list. This chapter addresses some issues that need attention when dealing with
the PLIST file (or files, see below!).
13.1. RCS ID
Be sure to add a RCS ID line as the first thing in any PLIST file you write:
@comment $NetBSD$
13.2. Semi-automatic PLIST generation
You can use the make print-PLIST command to output a PLIST that matches any new
files since the package was extracted. See Section 17.17, "Other helpful
targets" for more information on this target.
13.3. Tweaking output of make print-PLIST
If you have used any of the *-dirs packages, as explained in Section 13.8,
"Sharing directories between packages", you may have noticed that make
print-PLIST outputs a set of @comments instead of real @dirrm lines. You can
also do this for specific directories and files, so that the results of that
command are very close to reality. This helps a lot during the update of
packages.
The PRINT_PLIST_AWK variable takes a set of AWK patterns and actions that are
used to filter the output of print-PLIST. You can append any chunk of AWK
scripting you like to it, but be careful with quoting.
For example, to get all files inside the libdata/foo directory removed from the
resulting PLIST:
PRINT_PLIST_AWK+= /^libdata\/foo/ { next; }