pkgsrc

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.

Using binary packages

On the dracolinux.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 located in /usr/local/etc/mk.conf, that is:

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.

^ Back to top

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-linux server in the directory /pub/pkgsrc/packages.

^ Back to top

Installing binary packages

In the directory from the last section, there is a subdirectory called All, which contains all the binary packages that are available for the platform, excluding those that may not be distributed via FTP or CDROM (depending on which medium you are using), and the ones that have vulnerabilities and therefore are considered insecure to install without thinking before.

To install packages directly from an FTP or HTTP server, run the following commands in a Bourne-compatible shell (be sure to 'su -' to root first):

export PKG_PATH="http://dracolinux.org/packages/All"

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-*

pkg_add kde amarok kaffeine koffice basket ktorrent

Note that any prerequisite packages needed to run the package in question will be installed, too, assuming they are present where you install from.

As mentioned above, packages for which vulnerabilities get known are not stored in the All subdirectory. They don't get deleted since that could be very frustrating if many other packages depend on it. Instead, they are moved to the vulnerable subdirectory. So you may need to add this directory to the PKG_PATH variable. However, you should run audit-packages regularly, especially after installing new packages, and verify that the vulnerabilities are acceptable for your configuration.

Please read the complete documentation for pkg_add. Also see DracoPKG and pkg_radd.

^ Back to top

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.

^ Back to top

Getting information about installed packages

The pkg_info shows information about installed packages or binary package files.

^ Back to top

Checking for security vulnerabilities

The NetBSD Security-Officer and Packages Groups maintain a list of known security vulnerabilities to packages which are (or have been) included in pkgsrc. The list is available from the NetBSD FTP site at ftp://ftp.NetBSD.org/pub/pkgsrc/distfiles/vulnerabilities.

Through security/audit-packages, this list can be downloaded automatically, and a security audit of all packages installed on a system can take place.

There are two components to security/audit-packages. The first component, 'download-vulnerability-list', is for downloading the list of vulnerabilities from the NetBSD FTP site. The second component, 'audit-packages', checks to see if any of your installed packages are vulnerable. If a package is vulnerable, you will see output similar to the following:

Package samba-2.0.9 has a local-root-shell vulnerability, see

http://www.samba.org/samba/whatsnew/macroexploit.html

One can set up security/audit-packages to download the vulnerabilities file daily, and include a package audit in the daily security script.

^ Back to top

Finding newer versions of your installed packages

Install pkgtools/lintpkgsrc and run lintpkgsrc with the -i argument to check if your packages are up-to-date, e.g.

lintpkgsrc -i

You can then use 'bmake update' to update the package on your system and rebuild any dependencies.

^ Back to top

Other administrative functions

The 'pkg_admin' executes various administrative functions on the package system.

^ Back to top

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 2008Q3.

The second step is to decide how you want to download pkgsrc. You can get it as a tar file or via CVS.

As tar file

The primary download location for all pkgsrc files is ftp://ftp.NetBSD.org/pub/pkgsrc, Draco mirrors stable branches here.

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 2008Q3 is in the directory pkgsrc-2008Q3 and is also called pkgsrc-2008Q3.tar.gz.

To download a pkgsrc stable tarball, run:

ftp ftp://ftp.NetBSD.org/pub/pkgsrc/pkgsrc-200xQy/pkgsrc-200xQy.tar.gz

Where pkgsrc-200xQy is the stable branch to be downloaded, for example, 'pkgsrc-2008Q3'.

Then, extract it with:

tar -xzf pkgsrc-200xQy.tar.gz -C /usr

This will create the directory pkgsrc/ in /usr/ and all the package source will be stored under /usr/pkgsrc/.

To download pkgsrc-current, run:

ftp ftp://ftp.NetBSD.org/pub/pkgsrc/current/pkgsrc.tar.gz

Via anonymous CVS

To do an initial (full) checkout of pkgsrc, you first have to set some environment variables. For the bourne shell, type:

export CVSROOT="anoncvs@anoncvs.NetBSD.org:/cvsroot"

export CVS_RSH="ssh"

By default, CVS doesn't do things like most people would expect it to do. But there is a way to convince CVS, by creating a file called .cvsrc in your home directory and saving the following lines to it. This file will save you lots of headache and some bug reports, so we strongly recommend it. You can find an explanation of this file in the CVS documentation.

# recommended CVS configuration file from the pkgsrc guide

checkout -P

update -dP

release -d

diff -upN

cvs -q -z3

rdiff -u

To fetch a specific pkgsrc stable branch from scratch, run:

cd /usr

cvs checkout -r pkgsrc-200xQy -P pkgsrc

Where pkgsrc-200xQy is the stable branch to be checked out, for example, 'pkgsrc-2008Q3'

This will create the directory pkgsrc/ in your /usr/ directory and all the package source will be stored under /usr/pkgsrc/.

To fetch the pkgsrc current branch, run:

cd /usr

cvs checkout -P pkgsrc

^ Back to top

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.

To update pkgsrc via CVS, make sure the environment variable CVS_RSH is set as above. Then, change to the pkgsrc directory and run cvs:

cd /usr/pkgsrc

cvs update -dP

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-2008Q3' option.

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.

^ Back to top

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 'bmake 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/local. If you wish to change this, you should do so by setting LOCALBASE in mk.conf. Remember to recompile pkgsrc-bootstrap before using the new LOCALBASE.

Requirements

To build packages from source, you need a working C compiler. On Draco, you need to install the 'devel' distribution sets.

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:

bmake 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.

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.

For example, type

cd /usr/pkgsrc/misc/figlet

bmake

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:

bmake 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:

bmake 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:

bmake clean-depends

Note that clean-depends is standard behaviour on Draco.

The programs are installed under the default root of the packages tree - /usr/local. 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 (remember to recompile the pkgsrc-bootstrap). 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.

If you want to install a binary package that you've either created yourself, that you put into pkgsrc/packages manually or that is located on a remote server, you can use the 'bin-install' target. This target will install a binary package - if available - via 'pkg_add', else do a 'bmake package'. The list of remote sites searched is kept in the variable BINPKG_SITES. Any flags that should be added to 'pkg_add' can be put into BIN_INSTALL_FLAGS. See mk.conf for more details.

^ Back to top

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 'bmake show-options'.

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.

It is important to note that options that were specifically suggested by the package maintainer must be explicitely removed if you do not wish to include the option. If you are unsure you can view the current state with bmake 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.

^ Back to top

More ...

This document is just a small part of the complete documentation, read more at pkgsrc.org.

^ Back to top