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.
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”.
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).
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.
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.
The pkg_info shows information about installed packages or binary package files.
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
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.
The pkg_admin executes various administrative functions on the package system.
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.
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.
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.
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_DEVELOPER
s 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.
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.
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.
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 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
.