Uninstalling Packages

Use pkg_delete(1) to uninstall packages:

...............................................................................................

# pkg_delete openuniverse−1.0.b3

#

...............................................................................................

If you want to uninstall a package required by other packages, only do so when you know exactly what you're doing, and why. (For example, you might want to upgrade a dependency package to a newer version.) Don't expect software that requires this package to work once you've uninstalled it, however!

You can use pkg_delete −f to force an uninstall. Pkg_delete will warn you, but will do it anyway.

Package Information

Uninstalling works well when you remember the exact version number of every package you've installed. If you can do that, I commend you. If you're like me, though, you're lucky to remember that you have a piece of software installed on a system, let alone which version it is!

FreeBSD includes pkg_info, a tool to examine installed packages in a more convenient manner than manually scanning /var/db/pkg. Pkg_info(1) uses the contents of /var/db/pkg to do its work, but automatically handles a lot of boring manual searching and sorting for you.

When it is run without any options, pkg_info lists each package installed on your system, along with a brief description of each:

...............................................................................................

# pkg_info
Hermes−1.3.2	Fast pixel formats conversion		library
JX−1.5.3_1	A	C++ application framework and widget library for X11
Mesa−3.4.2_1	A	graphics library similar to	SGI's OpenGL
ORBit−0.5.8_1	High−performance CORBA ORB with support for the C language

XFree86−aoutlibs−3.3.3 XFree86 a.out compatibility libraries

...

...............................................................................................

As you can see, this output will give you the name and version of each package you've installed, so you can uninstall it easily.

Package Info Arguments

You can use various arguments with pkg_info to gather other information about the packages on your system. When you start using arguments, pkg_info requires either a package name to investigate or the −a flag, which means "for all packages."

For example, to learn which packages on your system require other packages, you would use this option:

234

...............................................................................................

# pkg_info −aR

Information for Hermes−1.3.2:

Required by: windowmaker−0.65.0_1 wmakerconf−2.8.1 Information for JX−1.5.3_1: Required by: libjtree−1.1.7_1 libjtoolbar−0.5.4_1 code_crusader−2.1.4_1

...

...............................................................................................

To find out the space needed by the files within a package, use pkg_info −s packagename. (Note that this only includes files installed by the package; files created by the package are another matter entirely. After all, do you count your text files and email messages as part of your office suite?)

Another common question is which package a file came from. You might be browsing through /usr/local/bin and come across a file that you don't recognize, haven't used, and have no idea why it's there. Use the −W flag to pkg_info to perform a sort of "reverse lookup" on files to see which package they came from:

...............................................................................................

# pkg_info −W /usr/local/bin/xwe

/usr/local/bin/xwe was installed by package xwpe−1.5.22a

#

...............................................................................................

Controlling Pkg_add

You can use shell−environment variables to control how package−handling tools behave.

PKG_TMPDIR

The PKG_TMPDIR environment variable controls where pkg_add will unpack its temporary files.

A package is a tarball with some added instructions on how to install things. To install a package, you have to untar it. If you're short on space in the standard directories that pkg_add tries to use, the untar will not finish and the install will fail. By default, pkg_add tries to use the directory given by the environment variable $TMPDIR. If that variable doesn't exist, pkg_add checks for room in /tmp, /var/tmp, and /usr/tmp, in that order.

You can set PKG_TMPDIR to make pkg_add use a different directory, where you do have room:

...............................................................................................

# setenv PKG_TMPDIR /usr/home/mwlucas/garbage

#

...............................................................................................

235

(You can add this line to your .cshrc to have it set every time you log in.)

PACKAGEROOT

The PACKAGEROOT environment variable controls the FTP server used by pkg_add's automatic package fetching. By default, pkg_add −r tries to download everything from ftp.FreeBSD.org, the default server. However, you can frequently get better performance by manually choosing a closer, less heavily used mirror.

Set this PACKAGEROOT with a particular server name and protocol as a URL. For example, to download from ftp3.FreeBSD.org, enter this:

...............................................................................................

# setenv PACKAGEROOT ftp://ftp3.FreeBSD.org

#

...............................................................................................

PACKAGESITE

PACKAGESITE, another popular environment variable, gives an exact path to check for a package repository. You might choose to use this if you want to use packages from a particular release, or if you have a local package repository. (We'll discuss setting up a local package repository in the "Building Packages" section, later in the chapter.)

Set the PACKAGESITE variable as an absolute URL:

...............................................................................................

# setenv PACKAGESITE ftp://ftp4.FreeBSD.org/pub/FreeBSD/releases/4.4−

STABLE/packages/All

#

...............................................................................................

Package Problems

The package scheme seems like a great system, right? Well, sort of. There are a few problems, specifically lags in the software−porting process and the software−synchronization requirements.

The overwhelming majority of packages is software produced by third parties, folks who release their software on a schedule completely independent of FreeBSD. When they release an updated version of their software, the FreeBSD package is updated. There is a delay between the release of an original software package and the port to FreeBSD. A popular port might be updated in hours, while large or less frequently used ports can languish at an older version for days or weeks.

Also, packages are interdependent, and many rely upon others in order to function properly. When the FreeBSD ports team changes a package, that change cascades through all the dependent packages. That's why you'll see packages with names like windowmaker−0.65.0_1. The _1 shows that a program the package depends on has changed, and so this version of WindowMaker is slightly different than the previous version. These bumped version numbers might also indicate that

236

the port itself was slightly changed; for example, the build process for the FreeBSD port of WindowMaker 0.65.0 has been updated once. (Often these changes are purely internal, and don't affect the software's behavior or performance.)

If you're running a FreeBSD release and only installing software from the CD or the version released with your release, this interdependency isn't much of an issue. After all, the packages built for a release do not change. You might be running an older version of FreeBSD, but want a program that was just released. You might be continually upgrading your system, and have older versions of software.

For example, the package wmakerconf−2.8.1 requires windowmaker−0.65.0_1. That's fine if you have the right package installed, but if you have installed windowmaker−0.65.0 or windowmaker−0.65.0_2, pkg_add will think that you don't have the proper required package installed and will go grab the appropriate WindowMaker. This takes up disk space at best, and overwrites existing software at worst.

One way around this problem is always to use packages from the same date or time. (If you set the PACKAGESITE environment variable to the packages directory for a particular FreeBSD release, you'll always have matching packages.) This is perfectly acceptable in many cases, since you don't always need the latest version of a piece of software when a version just a month or two older will work just fine. In other cases, this practice isn't acceptable because an older version might have security problems or performance issues. In that case, I recommend you use ports instead. Rather than checking for installed programs by the name of the package, ports check for the existence of the program itself. To continue our earlier example, the port for wmakerconf won't check for WindowMaker version 0.65.0_2, it will just look for a program called "window−maker." This makes ports much more flexible.

Forcing an Install

There will be times when you want to use a package where a dependency has changed, and you don't want to upgrade the dependency or use an older package. Don't do it. Programs can crash, badly, if you do.

Still, it is possible to force an install if you want to—after all, dependency changes are frequently minor and do not affect program behavior. The hard part is verifying that your programs will be okay.

Note Before you read further, let me say that you should not be doing this. If you're in this situation, use a port instead. It will take longer, but things will almost certainly work correctly. If this isn't possible, read on.

Should you consider forcing an install? Well, as a very general rule of thumb, if the package name has changed by either adding a trailing underscore and a number, or if this trailing number has been incremented, the package may work. This is no guarantee, mind you, and if things start breaking, you'll have to uninstall the package and do things correctly.

To force an install, first, manually grab the package you want to use. (Be sure you don't have a packages CD−ROM mounted—you don't want the system to go looking for matching dependencies and install them, overwriting your existing software and causing problems.)

Once you've grabbed your package, run pkg_add −f::

237