Ports Tricks

by Dru Lavigne

One of the many reasons to love FreeBSD is its ports collection. Nearly 10,000 applications are available, and any installation is a mere make install clean away. In today's article, I'd like to share some of my favorite ports tricks.


Even if you've been using the ports collection for a while, a read through man ports may reveal some tricks you were unaware of. If you have lots of disk space but a slow or intermittent Internet connection, this tip from the manpage is a real gem:

% cd /usr/ports
% make readmes

You may want to go grab some lunch while the command does its thing. When it's finished, you'll have a new file called /usr/ports/README.html. Open that file in your favorite web browser and you'll find some very handy hyperlinks. First, there is a link to the FreeBSD handbook, which can be accessed either offline from your hard disk, or online from the FreeBSD web site. Next, there is a link to the Porter's Handbook. If you've ever wondered at the magic behind a port's Makefile or had the urge to make your own port, this is the file to read.

Next, there is a list of hyperlinks to each of the subdirectories in /usr/ports. Don't let the simplicity fool you. Select a subdirectory and one of its applications. I'll click on Editors->AbiWord2. The resulting page contains hyperlinks to the port's description, web site, and maintainer's email address, as well as the email address of the ports mailing list. It also contains a list of all of the port's dependencies. Granted, all of this information was already on your hard drive, but you can't beat accessing it via one bookmarkable web page that is available offline.

Making a Package Repository

Related Reading

The Complete FreeBSD
Documentation from the Source
By Greg Lehey

Another handy trick is making a package repository. This can be both a time- and bandwidth-saver if you need to install software on multiple machines in a network. It is also ideal for installing software on server machines, as you don't have to install the entire ports collection just to install your required applications.

Pick a machine in your network to contain the package repository. Only this machine will need the ports collection; it won't be required on the rest of the machines in the network. Start by creating a directory to hold the packages:

% mkdir /usr/ports/packages

Then create the packages you need. Here, I'll create two packages:

% cd /usr/ports/www/lynx
% make package
% cd /usr/ports/mail/getmail
% make package

When you use make package, two things happen. One, a package is created and stored in a subdirectory of /usr/ports/packages. Second, the port is installed on the local machine, if it hasn't already been installed. If you don't want to keep the application installed on the machine acting as the package repository, simply type make deinstall once the package has been created.

Once you've populated /usr/ports/packages with the packages required by your network, set up an NFS mount to share the package repository. The easiest way to do this is with stand/sysinstall. On the machine holding the packages:

% /stand/sysinstall

Choose Configure, Networking, and then NFS server. You should see the following message:

Operating as an NFS server means that you must first configure an /etc/exports file to indicate which hosts are allowed certain kinds of access to your local file systems. Press [ENTER] now to invoke an editor on /etc/exports

Unless you've changed your default editor, /etc/exports will be opened in vi. The default file contains some example syntax. I added this line to my file to reflect the network ID used on my network:

/usr/ports/packages -network -mask

Once you've saved your changes, you can reboot to initialize the NFS server. If rebooting isn't an option, follow the directions in the handbook. Then, ensure the NFS server is listening for requests:

% sockstat | grep nfs
root	nfsd	3973	tcp4*:2049	*:*

Next, you'll need to create NFS clients on each machine that is to use the package repository. This time, in /stand/sysinstall, choose NFS client instead of NFS server. You won't be prompted for anything; you'll just check off the box. Once you've exited the utility, type:

% nfsiod -n 4

Then, check to see if you can access the package repository. In my example, is the machine containing the packages:

% mount /mnt
% ls /mnt
All	Latest	ipv6	mail	python	www

You'll note that subdirectories were created for mail/getmail and www/lynx. The ipv6 and python subdirectories were for dependencies of those packages. The All subdirectory is quite handy:

% ls /mnt/All
getmail-3.1.7.tbz	lynx-

I'll now try to add a package:

% pkg_add /mnt/www/lynx-

Once I receive my prompt back, I'll check that the application did indeed install:

% pkg_info | grep lynx
lynx-	A non-graphical, text-based World-Wide Web client

If you're used to installing ports, you'll find that packages don't install their dependencies for you. Rather, they complain when one is missing. For example:

% pkg_add /mnt/mail/getmail-3.1.7.tbz
pkg_add: could not find package python-2.2.3_2 !

Educate your users simply to install the dependency first (in this case, python-2.2.3_2), and then install the desired package. Also, when a user is finished, remind them to cd out of the NFS share and unmount it:

% cd
% umount /mnt

Showing Dependencies

Okay, what else can one do with ports? I've already shown you one way to view a port's dependencies using make readmes.

Another way is to do this:

% cd /usr/ports/graphics/gimp
% make pretty-print-build-depends-list
This port requires package(s) "XFree86-libraries-4.3.0_5 
aalib-1.4.r5_1 cups-base- cups-pstoraster-7.07 expat-1.95.6_1 
fontconfig-2.2.90_3 freetype2-2.1.4_1 gettext-0.11.5_1 
ghostscript-gnu-7.07_3 gimp-print-4.2.5 glib-1.2.10_9 gmake-3.80 
gtk-1.2.10_9 imake-4.3.0_1 jpeg-6b_1 libiconv-1.9.1_1 libijs-0.34 
libtool-1.3.5_1 perl-5.6.1_13 pkgconfig-0.15.0 png-1.2.5_2 
tiff-3.5.7_1" to build.

Searching Ports

The ports collection also includes a search feature. This is extremely useful, especially if you already know what type of application you want and wish to know which ports are available to fulfill that need. For example:

% cd /usr/ports
% make search key=dvd | more

The result will be a list of all ports dealing with DVDs. Here is the first result in the search, to give you an idea of the information that can be gathered:

Info:Makes a DVD file structure from one or more MPEG2 streams
B-deps:expat-1.95.6_1 gettext-0.11.5_1 gmake-3.80 libdvdcss-1.2.5
libdvdread-0.9.4 libgnugetopt-1.2 libiconv-1.8_2 
R-deps:libdvdcss-1.2.5 libdvdread-0.9.4 libgnugetopt-1.2 png-1.2.5_2

The "B-deps" are the build dependencies, while the "R-deps" are the run dependencies.

If instead you just want to search for a port's name, use search name= instead. For example, if I know I want to build Netscape and want to see which versions are available, this will do the trick:

% make search name=netscape | more

If you find the search facility useful, it is a good idea to first run make index to ensure your ports index is completely up to date. This is another command that takes a while, so don't execute it if you're in a hurry.

Displaying the Currently Installed Packages and Ports

Let's move on to man pkg_info. This utility is used to display the currently installed packages and ports on a system. Unless you've read this manpage before, you're missing out on a lot of useful switches.

When using pkg_info, you can use -a in combination with other switches to gather information on all installed software. Alternately, specify the name of the particular application you wish to gather information about. For example:

% pkg_info -ac

shows the one-line comment of every installed application, whereas:

% pkg_info -c lynx-

will show the one-line comment for lynx- If you'd rather read the long description, use -d instead of -c.

If you're like me and hate typing, or, for that matter, remembering the version number of an application, include -x:

% pkg_info -xc lynx

The above command will show the one-line comment of every application that starts with lynx. Besides saving your memory cells for other purposes, it's an excellent way to find out if more than one version of lynx happens to be installed on your system.

Reading Post-Installation Messages

After installing a port, it's useful to see if there were any messages, as these often contain configuration instructions. For example, in my previous article, I showed you one way to see the message for /usr/ports/mail/messagewall. Here's an alternate method:

% pkg_info -xD messagewall

A very useful switch is -L, as it gives the full pathname to every file that was installed with the application:

% pkg_info -xL lynx | more
Information for lynx-


From the output, I now know that lynx installed with a manpage, that the location of the application itself is /usr/local/bin/lynx, that there is a default configuration file, and that there is a directory containing documents regarding lynx. Usually, I'm not interested in every file that was installed. Since the ones I'm concerned with are usually at the top of the list, I usually pipe the output to head instead of more:

% pkg_info -xL lynx | head

Checking Dependencies Before Uninstalling

Before uninstalling an application, it is always a good idea to see if any other packages require that application as a dependency. For example, you've typed pkg_info | more and see this application:


You think to yourself, "I don't remember installing, or even ever using, this application. Maybe I should just get rid of it." This command will tell you if it was instead installed by another application that you do need:

% pkg_info -R ORBit-0.5.17
Information for ORBit-0.5.17:

Required by:

Ahh, looks like this application is useful, after all. But, don't worry. If you did try to uninstall this application, pkg_delete would complain because it is required by those other applications. However, it is always nice to be aware of these things ahead of time.

Checking the Disk Space Your Ports Use

What happens if you go a little install-crazy and end up with more applications than disk space? Use the size switch to determine how much space an application's files are using. Send the output to either a pager:

% pkg_info -as | more

or to a file that you can read at your leisure:

% pkg_info -as > sizes

You'll then have an idea of which applications are using the most space so that you can decide which ones are worth uninstalling. Remember, you also have the comment switch and the dependencies switch to help you in your decision.

Checking the Status of Installed Ports

Yet another way to find out what software is installed on your system is to use pkg_version.

pkg_version | more

will list each installed application, in alphabetical order. You'll note that each application is followed by one of these three symbols:

So, to determine which applications require upgrading:

% pkg_version -l "<"

Note that you need to place quotes around the <, or your shell will complain about a missing name for your redirect. If you don't receive any output, congratulations! All of your applications are up to date. If you do receive some output, you know which applications require an upgrade.

Alternately, this command will show all applications that are out of date:

% pkg_version -L "="

See man pkg_version if you didn't catch the difference between -l and -L.

If you prefer a more verbose output than =, <, or >, try this command:

% pkg_version -v | more

Usually, you run pkg_version after using /usr/ports/net/cvsup-without-gui to retrieve the latest ports updates. (See The FreeBSD Handbook's cvsup section.) If for some reason you're not using cvsup, you can still check your installed ports against the latest ports tree:

% pkg_version -v ftp://ftp.freebsd.org/pub/FreeBSD/branches/-current/ports/INDEX \
	| more

Note that that command is one long line. Alternately, use -l or -L with that URL to find your out of date applications.

All of the utilities mentioned in today's article came with your FreeBSD system. In the next article, I'll cover some ports that add even more functionality to the ports collection.

Dru Lavigne is a network and systems administrator, IT instructor, author and international speaker. She has over a decade of experience administering and teaching Netware, Microsoft, Cisco, Checkpoint, SCO, Solaris, Linux, and BSD systems. A prolific author, she pens the popular FreeBSD Basics column for O'Reilly and is author of BSD Hacks and The Best of FreeBSD Basics.

Read more FreeBSD Basics columns.

Return to the BSD DevCenter.

Copyright © 2017 O'Reilly Media, Inc.