Learn DragonFlyBSD - Package Management: pkg & DPorts

#Introduction

In episode 3 you finished the installation and have a running DragonFlyBSD with HAMMER2 on root. But an operating system without applications is like an empty warehouse. This episode teaches you how to fill that warehouse: installing software, updating it, searching for packages, and — when binary packages aren't enough — building your own from source.

DragonFlyBSD uses two complementary paths. The first is pkg: fast, ready-to-use binary packages. The second is DPorts: a collection of recipes that let you build software from source with full control over options. Understanding when to use which is part of becoming a mature administrator.

#pkg: Binary Packages

#Official Repository

DragonFlyBSD's binary packages are served from pkg.dragonflybsd.org and configured through /etc/pkg/ — usually /etc/pkg.conf. The repository configuration determines where packages come from and how updates are handled. Make sure the repository is active before you begin:

Check the pkg repository configuration

cat /etc/pkg.conf
pkg -v

pkg -v shows the version of pkg itself — version 2.x is the modern standard. Once the repository is configured, the first recommended step is to update the package database.

#Installation and Searching

The basic package management flow:

Update, search, and install packages

pkg update
pkg search htop
pkg install htop

pkg update refreshes the package catalog from the repository. pkg search finds packages by keyword. pkg install installs a package along with its dependencies. There's no manual step for managing dependencies — pkg resolves everything automatically.

#Upgrade and Information

To keep your system up to date, run upgrades periodically:

Upgrade all packages

pkg upgrade

A few other commands you should memorize:

Command	Purpose
`pkg info`	List installed packages
`pkg info pkg-name`	Details of a single package
`pkg which /path/to/bin`	Find the package that owns a file
`pkg remove pkg-name`	Remove a package
`pkg autoremove`	Clean up unused dependencies
`pkg check -d`	Verify dependency integrity

Warning

Always run pkg update before pkg upgrade. Without a fresh catalog, an upgrade can miss new versions or try to install outdated packages from an old catalog. This habit saves production servers.

#Fine-Tuning Package Configuration: `pkg set` & PKG_NOTES

Some packages support additional configuration through variables like PKG_OPTIONS. See the configuration notes with pkg info -D pkg-name, and inspect the options available in the package database with:

View package options and notes

pkg search -q pkg-name
pkg rquery '%n-%v: %N' pkg-name

Advanced configuration like this matters in production — for example, enabling features that aren't in the default build.

#DPorts: Building from Source

#Getting the Ports Tree

DPorts is a collection of Makefiles that describe how to download, patch, compile, and install a piece of software. This tree can be cloned from git or refreshed with pkg install -y dports — there's a package that provides a ready-made tree. It usually lives in /usr/dports.

Clone the DPorts tree

git clone https://github.com/DragonFlyBSD/DPorts.git /usr/dports

Every application has its own directory, for example /usr/dports/sysutils/htop. Inside it there's a Makefile that ties together the entire build process.

#make install clean

To build a port manually, enter the port directory and run make install clean:

Build and install htop from DPorts

cd /usr/dports/sysutils/htop
make
make install clean

make downloads, patches, and compiles; make install clean installs the build result and then cleans up the working files. This gives you full control: you can change build options with make config, which opens an option selection dialog, or by defining variables in /etc/make.conf.

#dsynth: Building Your Own Binary Repository

When you need to build many packages at once — for a mirror or a custom build — do it in parallel with dsynth:

Bulk-build packages with dsynth

dsynth prepare
dsynth build sysutils/htop

dsynth is a workhorse: it builds packages in dependency order, uses many cores at once, and stores the results as a local binary repository. Afterward, you can point pkg at that local repository and enjoy custom builds without repeating compilations.

#Tradeoff: pkg vs Ports

Aspect	pkg (binary)	DPorts (source)
Install speed	Seconds	Minutes to hours
Custom options	Limited to the repo build	Free via `make config`
Updates	`pkg upgrade`	`make update` per port
Best for	Standard systems, learning	Custom builds, niche production

The rule of thumb: for 95% of your needs, pkg is enough. Use DPorts when you need options not available in the binary build, or when you're building an internal repository with dsynth.

#Closing

In this episode 4 you mastered the two package management paths on DragonFlyBSD: pkg for binary packages (pkg update, pkg search, pkg install, pkg upgrade, pkg info) and DPorts for building from source (make install clean, make config, dsynth). You also understand the tradeoffs between the two paths and when to use each.

Key takeaways:

pkg is the main path: pkg update, pkg search, pkg install, pkg upgrade, pkg info.
The official repository at pkg.dragonflybsd.org is configured through /etc/pkg.conf.
DPorts enables source builds with make install clean and make config for custom options.
dsynth builds many packages in parallel and produces your own binary repository.
Use pkg for speed, DPorts for control — the two complement each other.

In the next episode, episode 5, we'll learn about users, groups & doas: creating users with useradd and adduser, removing them with userdel, managing with groupadd, understanding the structure of /etc/passwd and /etc/group, and configuring privileges with su, doas, and sudo.