DragonFly BSD



DragonFly, up to and including version 3.4, used pkgsrc to manage third party software packages. DragonFly switched to dports at the 3.6 release.

This page is still useful for anyone wanting to use pkgsrc, but the recommended packaging method is dports, which is covered in a similar document here:


pkgsrc on DragonFly

DragonFly uses a specially crafted Makefile in /usr and a git mirror of the official pkgsrc repository to make pkgsrc distribution more user-friendly.

The basics of the pkgsrc system can be found in NetBSD's Pkgsrc Guide, and can be considered the canonical resource.



Pkgsrc is a packaging system that was originally created for NetBSD. It has been ported to DragonFly, along with other operating systems. Pkgsrc is very similar to FreeBSD's ports mechanism.


The pkgsrc collection supplies a collection of files designed to automate the process of compiling an application from source code. Remember that there are a number of steps you would normally carry out if you compiled a program yourself (downloading, unpacking, patching, compiling, installing). The files that make up a pkgsrc source collection contain all the necessary information to allow the system to do this for you. You run a handful of simple commands and the source code for the application is automatically downloaded, extracted, patched, compiled, and installed for you. In fact, the pkgsrc source subsystem can also be used to generate packages which can later be manipulated with pkg_add and the other package management commands that will be introduced shortly.

Pkgsrc understands dependencies. Suppose you want to install an application that depends on a specific library being installed. Both the application and the library have been made available through the pkgsrc collection. If you use the pkg_add command or the pkgsrc subsystem to add the application, both will notice that the library has not been installed, and automatically install the library first. You might be wondering why pkgsrc® bothers with both. Binary packages and the source tree both have their own strengths, and which one you use will depend on your own preference.

Binary Package Benefits

Pkgsrc source Benefits

To keep track of pkgsrc releases subscribe to the NetBSD pkgsrc users mailing list and the NetBSD pkgsrc users mailing list. It's also useful to watch the DragonFly User related mailing list as errors with pkgsrc on DragonFly should be reported there.

Warning: Before installing any application, you should check http://www.pkgsrc.org/ for security issues related to your application.

Audit-packages will automatically check all installed applications for known vulnerabilities, a check will be also performed before any application build. Meanwhile, you can use the command audit-packages -d after you have installed some packages.

Note: Binary packages and source packages are effectively the same software and can be manipulated with the same pkg_* tools.

Installing pkgsrc

The basic pkgsrc tools are provided with every DragonFly system as part of installation. However, you still need to download the pkgsrc tree for building applications with these tools.

Set GITHOST in /etc/make.conf or set it as an environment variable to select a different download location, if desired. See mirrors page for available mirrors.

This downloads the stable version of the pkgsrc tree from the default mirror, if you didn't set GITHOST. As root:

# cd /usr
# make pkgsrc-create

to fetch the intial pkgsrc repository from the net, or

# cd /usr
# make pkgsrc-update

to update.

Note: If your DragonFly install is not up to date, you might have ended up with an old release of the pkgsrc tree.

# cd /usr/pkgsrc
# git branch

will show what release you are on. See Tracking the stable branch for more information.

Tracking the stable branch

There are quarterly releases of pkgsrc that are specifically designed for stability. You should in general follow these, rather than the bleeding edge pkgsrc. When a new branch is out you need to set up a local branch tracking that one. 'make pkgsrc-update' will not do this for you.

To see the available remote branches:

# cd /usr/pkgsrc 
# git pull
# git branch -r

To create a local branch, tracking the remote quarterly release:

# cd /usr/pkgsrc 
# git branch pkgsrc-2010Q4 origin/pkgsrc-2010Q4

Branch naming format is 'pkgsrc-YYYYQX', where YYYY is the year and QX is quarters 1-4 of the year. Check pkgsrc.org to see the name of the latest stable branch.

After adding a new branch, it can be downloaded with:

# cd /usr/pkgsrc 
# git checkout pkgsrc-2010Q4
# git pull

Dealing with pkgsrc packages

The following section explains how to find, install and remove pkgsrc packages.

Finding Your Application

Before you can install any applications you need to know what you want, and what the application is called. DragonFly's list of available applications is growing all the time. Fortunately, there are a number of ways to find what you want:

Since DragonFly 1.11 pkg_search(1) is included in the base system. pkg_search(1) searches an already installed pkgsrc INDEX for for a given package name. If pkgsrc is not installed or the INDEX file is missing, it fetches the pkg_summary(5) file.

# pkg_search fvwm
fvwm-2.4.20nb1          Newer version of X11 Virtual window manager
fvwm-2.5.24             Development version of X11 Virtual window manager
fvwm-themes-0.6.2nb8    Configuration framework for fvwm2 with samples
fvwm-wharf-1.0nb1       Copy of AfterStep's Wharf compatible with fvwm2
fvwm1-1.24rnb1          Virtual window manager for X

# pkg_search -v fvwm-2.5
Name    : fvwm-2.5.24-50
Dir     : wm/fvwm-devel                                     
Desc    : Development version of X11 Virtual window manager 
URL     : any                                               
Deps    : perl>#5.0 gettext-lib>0.14.5 [...]

Its also possible to issue the command

# cd /usr/pkgsrc/
# bmake search key='package you are looking for'

from the /usr/pkgsrc directory.

It's also possible to browse website that show all the available pkgsrc packages, such as http://pkgsrc.se/ .

Installing applications

Downloading a binary package is almost always faster than building from source, but not all programs in pkgsrc can be redistributed as a binary. In most cases, you will want to download a binary package if possible, and otherwise build from source if it's not available.

The bin-install target on DragonFly (with pkgsrc from 2011/02/07 and later) will do just that:

# cd /usr/pkgsrc/misc/screen
# bmake bin-install clean

This will download and install the appropriate screen binary package if it exists, and try building from source if it can't complete the download.

Installing applications, source only

Packages are built by going into the appropriate directory and issuing bmake install clean. For example, to build the screen package you need to issue the following commands.

# cd /usr/pkgsrc/misc/screen
# bmake install clean

To find out the options that can affect how a program is built:

# bmake show-options

To change options:

# bmake PKG_OPTIONS.<package_name>="-option1 option2" install clean

Listing an option enables it. Listing an option with a "-" before it disables the option.

To make these option changes permanent for every future build or upgrade of this package, put a similar line in /usr/pkg/etc/mk.conf:

 . PKG_OPTIONS.<package_name>=-option1 option2

Installing applications, binary only

Binary packages can be installed using pkg_radd:

# pkg_radd screen

This program works by setting the PKG_PATH environment variable to the appropriate path for the operating system and architecture to a remote repository of binary packages, and then using pkg_add to get packages. This will install most packages, but will not upgrade packages that are already installed.

You can manually set BINPKG_BASE and use pkg_add to get the same effect, using a different server.

# setenv BINPKG_BASE http://mirror-master.dragonflybsd.org/packages
# pkg_add screen

Issues with pre-built packages

List all installed applications

To obtain a list of all the packages that are installed on your system:

# pkg_info

To see if certain packages have been installed, filter for the name of the package. This example will show all xorg-related packages currently installed on the system:

# pkg_info | grep xorg

Removing packages

If a program was installed as a package:

# pkg_delete packagename

If a package was installed from the source files, you can also change to the directory they were installed from and issue the command:

# bmake deinstall

Note that these methods are effectively interchangeable. Either will work whether the package was originally installed from source or binary.

Remove associated files needed for building a package

To remove the work file from building a package, and the package's dependencies:

# bmake clean clean-depends

This can be combined with other steps:

# bmake install clean clean-depends

Upgrading packages

There's a number of ways to upgrade pkgsrc; some of these are built in and some are packages installable with pkgsrc. This list is not necessarily comprehensive.

Update pkgsrc system packages

Note: Sometimes basic pkgsrc tools; bmake, pkg_install and bootstrap-mk-files need to be upgraded. However, they can't be deleted and replaced since you need that tool to accomplish replacement. The solution is to build a separate package before deletion, and install that package.

# cd /usr/pkgsrc/devel/bmake
# cd /usr/pkgsrc/pkgtools/pkg_install
# cd /usr/pkgsrc/pkgtools/bootstrap-mk-files

# env USE_DESTDIR=yes bmake package
# bmake clean-depends clean

And go to the packages directory and install the binary package with

# cd /usr/pkgsrc/packages/All
# pkg_add -u <pkg_name> (i.e. the name of the .tgz file).

bmake replace

Performed in the /usr/pkgsrc directory that correlates with the installed package, the software is first built and then replaced.

# cd /usr/pkgsrc/chat/ircII
# bmake replace


pkg_rolling-replace replaces packages one by one and you can use it for a better way of package management. Actually it does bmake replace on one package at a time, sorting the packages being replaced according to their interdependencies, which avoids most duplicate rebuilds. Once pkg_rolling-replace is installed you can update the packages through the following steps.

# cd /usr && make pkgsrc-update
# pkg_rolling-replace -u


Downloads and installs binary packages. Check the mirrors page for sites carrying binary packages to use with pkgin. You can run the following commands to get the packages updated. This assumes that pkgin is already configured. Please consult the documentation and the man page on how to do so.

# pkgin update
# pkgin full-upgrade 


It updates packages by removing them and rebuilding them. Warning: programs are unavailable until a rebuild finishes. If they don't rebuild, it won't work. pkg_chk requires a few steps in order to work correctly. They are listed here.

# pkg_chk -g  # make initial list of installed packages
# pkg_chk -r  # remove all packages that are not up to date and packages that depend on them
# pkg_chk -a  # install all missing packages (use binary packages, this is the default)
# pkg_chk -as # install all missing packages (build from source)

The above process removes all packages at once and installs the missing packages one by one. This can cause longer disruption of services when the removed package has to wait a long time for its turn to get installed.

pkg_add -u

Point at a local or online binary archive location to download and update packages.


This requires that you've set up rpkgmanager first. Read more about rpkgmanager here.

# yes | rpkgmanager.rb

Start pkgsrc applications on system startup

Packages often install rc.d scripts to control software running on startup. To specify where the rc.d scripts from the installed packages should go, add the following lines to your /usr/pkg/etc/mk.conf file:


This option can be set in the environment to activate it for binary packages. These packages will still have to be enabled in /etc/rc.conf/ to run at boot. If these options aren't set, the rc file will be placed in /usr/pkg/share/examples/rc.d/ and will need to be manually copied over to /etc/rc.d.

Many other options can be set in this file; see /usr/pkgsrc/mk/defaults/mk.conf for examples.

Miscellaneous topics

Post-installation Activities

After installing a new application you will normally want to read any documentation it may have included, edit any configuration files that are required, ensure that the application starts at boot time (if it is a daemon), and so on. The exact steps you need to take to configure each application will obviously be different. However, if you have just installed a new application and are wondering What now? These tips might help:

Use pkg_info(1) to find out which files were installed, and where. For example, if you have just installed Foo_Package version 1.0.0, then this command

# pkg_info -L foopackage-1.0.0 | less

will show all the files installed by the package. Pay special attention to files in man/ directories, which will be manual pages, etc/ directories, which will be configuration files, and doc/, which will be more comprehensive documentation. If you are not sure which version of the application was just installed, a command like this

# pkg_info | grep -i foopackage

will find all the installed packages that have foopackage in the package name. Replace foopackage in your command line as necessary.

Once you have identified where the application's manual pages have been installed, review them using man(1). Similarly, look over the sample configuration files, and any additional documentation that may have been provided. If the application has a web site, check it for additional documentation, frequently asked questions, and so forth. If you are not sure of the web site address it may be listed in the output from

# pkg_info foopackage-1.0.0

A WWW: line, if present, should provide a URL for the application's web site.

Dealing with Broken Packages

If you come across a package that does not work for you, there are a few things you can do, including:

  1. Fix it! The pkgsrc Guide includes detailed information on the pkgsrc® infrastructure so that you can fix the occasional broken package or even submit your own!

  2. Send email to the maintainer of the package first. Type bmake maintainer or read the Makefile to find the maintainer's email address. Remember to include the name and version of the port (send the $NetBSD: line from the Makefile) and the output leading up to the error when you email the maintainer. If you do not get a response from the maintainer, you can try users .

  3. Grab a pre-built package from an mirror site near you.

What is WIP?

Packages that can be built within the pkgsrc framework but are not yet necessarily ready for production use can be found in http://pkgsrc-wip.sourceforge.net. These packages need to be downloaded separately; check the website for details. Packages in this collection are in development and may not build successfully.