Table of Contents
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.
To use binary packages, you need some tools to manage
them. On NetBSD, these tools are already installed. On all
other operating systems, you need to install them first. For
the following platforms, prebuilt versions of the package
tools are available and can simply be downloaded and unpacked
in the /
directory:
These prebuilt package tools use /usr/pkg
for the base directory, and
/var/db/pkg
for the database of installed
packages. If you cannot use these directories for whatever
reasons (maybe because you're not root), you have to build
the package tools yourself, which is explained in Section 3.1,
“Bootstrapping pkgsrc”.
To install binary packages, you first need to know from where to get them. You can get them on CD-ROMs, DVDs, or via FTP or HTTP.
For NetBSD, the binary packages are made available on
ftp.NetBSD.org
and its mirrors, in
the directory /pub/NetBSD/packages/
. For
OSVERSION
/ARCH
/OSVERSION
, you
should insert the output of uname -r, and for ARCH
the output of
uname -p.
For some other platforms, binary packages can be found at the following locations:
In each of these directories, there is a subdirectory
All
that contains all the binary
packages. Further, there are subdirectories for categories
that contain symbolic links that point to the actual binary
package in ../All
. This directory layout is used for
all package repositories, no matter if they are accessed
via HTTP, FTP, NFS, CD-ROM, or the local filesystem.
If you have the files on a CD-ROM or downloaded them to your hard disk, you can install them with the following command (be sure to su to root first):
#
pkg_add /path/to/package.tgz
If you have FTP access and you don't want to download the packages via FTP prior to installation, you can do this automatically by giving pkg_add an FTP URL:
#
pkg_add ftp://ftp.NetBSD.org/pub/NetBSD/packages/<OSVERSION>/<ARCH>/All/package.tgz
Note that any prerequisite packages needed to run the package in question will be installed, too, assuming they are present where you install from.
To save some typing, you can set the PKG_PATH
environment variable to a
semicolon-separated list of paths (including remote URLs);
trailing slashes are not allowed.
Additionally to the All
directory there exists a vulnerable
directory to which binary
packages with known vulnerabilities are moved, since
removing them could cause missing dependencies. To use
these packages, add the vulnerable
directory to your PKG_PATH
. However, you should run
security/audit-packages
regularly,
especially after installing new packages, and verify that
the vulnerabilities are acceptable for your configuration.
An example PKG_PATH
would be:
ftp://ftp.NetBSD.org/pub/NetBSD/packages/<OSVERSION>/<ARCH>/All;ftp://ftp.NetBSD.org/pub/NetBSD/packages/<OSVERSION>/<ARCH>/vulnerable
Please note that semicolon (';') is a shell meta-character,
so you'll probably have to quote it.
After you've installed packages, be sure to have
/usr/pkg/bin
and /usr/pkg/sbin
in your PATH
so you can actually start the just
installed program.
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.
This 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.
To build packages from source on a NetBSD system the “comp” and the “text” distribution sets must be installed. If you want to build X11-related packages the “xbase” and “xcomp” distribution sets are required, too.
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.
You can overwrite some of the major distribution sites
to fit to sites that are close to your own. Have a look at
pkgsrc/mk/defaults/mk.conf
to find
some examples — in particular, look for the
MASTER_SORT
, MASTER_SORT_REGEX
and INET_COUNTRY
definitions. This may save
some of your bandwidth and time.
You can change these settings either in your shell's
environment, or, if you want to keep the settings, by
editing the /etc/mk.conf
file, and adding the
definitions there.
If you don't have a permanent Internet connection and
you want to know which files to download,
make
fetch-list will tell you what you'll need.
Put these distfiles into /usr/pkgsrc/distfiles
.
Assuming that the distfile has been fetched (see previous section), become root and change into the relevant directory and run make.
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, and
#
make install
to install the various components into the correct places on your system. Installing the package on your system requires you to be root. However, pkgsrc has a just-in-time-su feature, which allows you to only become root for the actual installation step
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 /etc/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 /etc/mk.conf
to save having to remember
to set them each time you want to use pkgsrc.
Occasionally, people want to “look under the covers” to see what is going on when a package is building or being installed. This may be for debugging purposes, or out of simple curiosity. A number of utility values have been added to help with this.
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.
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 can not use several
directories for the same purpose. Doing so will result in
pkgsrc not being able to properly detect your installed
packages, and fail miserably. Note also that precompiled
binary packages are usually built with the default
LOCALBASE
of /usr/pkg
, and that you should
not install any if
you use a non-standard LOCALBASE
.
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.
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.