Published on (
 See this if you're having trouble printing code examples

Big Scary Daemons

Fine Control of Ports


Previously in Big Scary Daemons:

Running Commercial Linux Software on FreeBSD

Building Detailed Network Reports with Netflow

Visualizing Network Traffic with Netflow and FlowScan

Monitoring Network Traffic with Netflow

Information Security with Colin Percival

In this episode, we pick up right where I left of in the last article.

The ports system includes other useful options, all documented in The one I use most often is make clean, which removes the port's build directory, source code, and object files. Once every few months, I go to each active system and do cd /usr/ports && make clean; this recursively purges all of the object files on the system and can free up quite a bit of disk space.

The make deinstall and make reinstall commands uninstall and reinstall the software. If you're testing a port, deciding if you want to use a piece of software, or generally mucking around, this is the easiest way to uninstall and reinstall a port. You can't use these targets after make clean.

If you run many FreeBSD systems and like to tweak ports during the build process, make package is your friend. You can compile the software just as you like it in the ports tree, and make package will create a standard FreeBSD package for you. You can copy the package over to other systems and install it at will.

If you have limited bandwidth at one location but lots of bandwidth elsewhere, make fetch-recursive is your friend. You can download the source code for a port and all its dependencies before even starting to build. For a long time, my phone line at home limited my connection speed to 14.4. I had a T1 at work. I could take my laptop in, do a cd /usr/ports/x11/kde2 && make fetch-recursive. When I got home, I could do cd /usr/ports/x11/kde2 && make install clean. When I got up the next day, I had the latest KDE installed. (I use WindowMaker, but kdegames is nice.) This is also useful if you're charged for your time online.

The make fetch-recursive option is kind of dumb; it doesn't check to see if you already have a dependency installed before fetching the source. If you have a metered connection, this isn't a good option.

You can customize your environment to control port-building behavior as well. Rather than specifying each of these on the command line, however, you can set make environment variables in /etc/make.conf. This helps enforce your "system policy" for that machine; you might not touch a system for months and forget where you put things.

PORTSDIR is the location of your ports tree. On more than one occasion I've filled up /usr; slapping in a second hard drive, moving the ports tree, and setting PORTSDIR is a quick and easy fix for this.

WRKPREFIXDIR is where the port creates the "work" directory. The port extracts source code, builds object files, and does all its other work here. If I set WRKPREFIXDIR=/home/mwlucas/work, I can build a port as non-root.

Setting WRKPREFIXDIR makes the port build a subdirectory structure under the selected directory; for example, if I build games/xsol with the environment above, the port actually builds in /usr/home/mwlucas/work/usr/ports/games/xsol/work/xsol-new. I can avoid building the whole subtree by setting NO_WRKSUBDIR, forcing the port to build in WRKPREFIXDIR.

The LOCALBASE, X11BASE, and LINUXBASE directories indicate where to install a port. X11BASE is where X11-based ports go, and LINUXBASE is where Linux-compatibility-based ports go. LOCALBASE is where everything else goes. You can override them all simultaneously with the PREFIX variable. (This doesn't always work in ports that use imake, part of the X11 system.)

The DISTDIR variable is where the port puts and/or checks for the source code. This defaults to /usr/ports/distfiles, but DISTDIR allows you to put it anywhere you like.

By setting WRKPREFIXDIR, PREFIX, and DISTDIR, an administrator can allow unprivileged users to install their own versions of ports. While they can't bind to privileged IP ports or run with greater privileges, they can still do a great deal of experimentation and research with ports.

MASTER_SITES controls where the port fetches its source from. By setting MASTER_SITE to the site of a known good source code tarball, you can control where the port downloads from. For example, if you use the command make MASTER_SITE=, then fetch will attempt to pull the distfile directly from that site.

If you want to pull the distfile directly from a FreeBSD repository, you can specify MASTER_SITE_FREEBSD=YES. The distfile probably exists there. Most FreeBSD mirrors are already heavily loaded, so please avoid this.

Probably the most useful option for maintainers of large FreeBSD networks is MASTER_SITE_OVERRIDE. The network administrator can build a central repository of important distfiles on a local server. The site listed in MASTER_SITE_OVERRIDE is checked for distfiles before any remote sites are contacted. This saves on exterior bandwidth and makes fetching distfiles more reliable.

Other environment variables affect how ports are compiled. Many ports include options to compile with support for various functions or integrate with other ports.

One of the most helpful of these is WITHOUT_X11. Many headless workstations neither run X nor need the X libraries. If you set this, ports that have a choice will build without X. This can keep you from building X on these systems. (Of course, if you build a port that requires X, it'll recursively build XFree86 anyway.)

Software such as QT, GTK, and Gnome are fairly pervasive, and many newer ports give options whether or not to compile with support for them. This is indicated by a string such as USE_QT in the port's makefile. If as a matter of system policy you use QT whenever possible, you can edit /etc/make.conf to include USE_QT=YES.

Some of the most common of these include:


Similarly, some ports allow special configuration if you use Emacs. If you set EMACS_PORT_NAME="emacs", the port will use Emacs 19.34. If you have EMACS_PORT_NAME="emacs20", the port uses Emacs 20.7.

With this information under your belt, you're ready to make some changes to a port. We'll look at that in the next article.

Michael W. Lucas

Read more Big Scary Daemons columns.

Discuss this article in the Operating Systems Forum.

Return to the BSD DevCenter.


Copyright © 2009 O'Reilly Media, Inc.