One of the many reasons to love FreeBSD is its ports collection.
Nearly 10,000 applications are available, and any installation is a mere
clean away. In today's article, I'd like to share some of my favorite
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.
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:
Networking, and then
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
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 192.168.2.0 -mask 255.255.255.0
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
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
% nfsiod -n 4
Then, check to see if you can access the package repository. In my example, 192.168.2.12 is the machine containing the packages:
% mount 192.168.2.12:/usr/ports/packages /mnt % ls /mnt All Latest ipv6 mail python www
You'll note that subdirectories were created for
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-188.8.131.52d.tbz
I'll now try to add a package:
% pkg_add /mnt/www/lynx-184.108.40.206d.tbz
Once I receive my prompt back, I'll check that the application did indeed install:
% pkg_info | grep lynx lynx-220.127.116.11d 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
% cd % umount /mnt
Okay, what else can one do with ports? I've already shown you one way to
view a port's dependencies using
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-18.104.22.168 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.
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:
Port:dvdauthor-0.5.3 Path:/usr/ports/multimedia/dvdauthor Info:Makes a DVD file structure from one or more MPEG2 streams Maint:pb@FreeBSD.org Index:multimedia 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 png-1.2.5_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
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
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.
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-22.214.171.124d
will show the one-line comment for
lynx-126.96.36.199d. If you'd
rather read the long description, use
-d instead of
If you're like me and hate typing, or, for that matter, remembering the
version number of an application, include
% pkg_info -xc lynx
The above command will show the one-line comment of every application that
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.
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-188.8.131.52d: Files: /usr/local/man/man1/lynx.1.gz /usr/local/bin/lynx /usr/local/etc/lynx.cfg.default /usr/local/share/doc/lynx/CHANGES <snip>
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
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
head instead of
% pkg_info -xL lynx | head
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
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: AbiWord-gnome-1.0.5 flashplugin-mozilla-0.4.10_2 <snip>
Ahh, looks like this application is useful, after all. But, don't worry. If
you did try to uninstall this application,
complain because it is required by those other applications. However, it is
always nice to be aware of these things ahead of time.
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.
Yet another way to find out what software is installed on your system is to
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:
=: the application is up to date.
<: there is a newer version of the application available.
>: your index may be out of date.
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 "="
man pkg_version if you didn't catch the difference between
If you prefer a more verbose output than
>, 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
cvsup section.) If for some reason you're
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 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 © 2009 O'Reilly Media, Inc.