Updating Ports and Packages


Now that your main system is updated, you can worry about the ports tree and the related packages installed on your system. While they're closely related, we'll consider the ports tree first and then evaluate how to upgrade installed packages.

One important thing to remember is that the ports and packages tree are closely tied to a version of OpenBSD. The ports tree for 3.2 will not run reliably on 3.3, and packages compiled for an older version may not run on a newer version. They might run, and probably will run, most of the time, for most purposes, usually. That's too many potential problems for my tastes, however. Whenever possible, I recommend starting over and reinstalling all software on the system from ports or packages built for the release you are using. That may be a luxury for some users, so we'll discuss some of the problems in upgrading packages.

We'll start by updating the ports tree.

Updating the Ports Tree

If you're installing from CD-ROM or FTP, you can update the ports tree simply by removing the old ports tree and extracting the new one. You might want to keep one old ports tree around for reference, simply because it contains the packages for the software you have installed at the moment. It's always nice to have the option to fall back a software version, in case the latest version has some horrible flaw.

 # cd /usr # mv ports ports-3.2 # tar -xzf /mnt/ports.tar.gz # 

That's it. (If you're installing from source, there are other ways to do this. We'll discuss those when we discuss source installs.)

Updating Installed Packages

The cleanest way to update your installed software is to remove everything you have installed already, and install everything from new packages for the release you are using. This frequently turns out to be far less work than updating everything piecemeal.

Some packages look like reinstalling would be a lot of work for no real gain. For example, the "gmake" package on both OpenBSD 3.1 and 3.2 is at version 3. 79.1. Why rip it out and replace it with something that looks the same? The package for 3.1 was built on an OpenBSD 3.1 system and various system infrastructure has changed since 3.2. Among other things the compiler has been upgraded, which means that although the program name and version is unchanged the actual binary the OpenBSD 3.2 gmake package installs may be quite different than that installed by the 3.1 package. For maximum safety, remove the 3.1 package and install the 3.2 package. On the other hand, the differences probably won't keep it from functioning. You could probably quite easily live with this older package for a few releases until it broke unexpectedly.

Finding Obsolete Packages

Perhaps you want to live with packages that were compiled on an older version of OpenBSD if their version is up-to-date and only upgrade obsolete packages. The biggest problem in this case is finding out which packages are obsolete. This is just tedious on a simple Web server with few packages, but can become a nightmare if you have dozens of packages installed. The simplest way to identify obsolete packages is with the up-to-date script available in /usr/ports/infrastructure/build.

 # ./out-of-date >>> Is /usr/ports/INDEX up-to-date ? 1 >>> Otherwise, this script will find out outdated flavors of packages >>> compared to your installed packages... 2 Update tcsh-6.10.00-static to one of 3 tcsh-6.12.00 tcsh-6.12.00-static Update png-1.2.1 to png-1.2.4 ... # 

If you installed the ports tree by extracting the ports.tar.gz for the release of OpenBSD you are currently running, you can ignore the 1 warning about /usr/ports/INDEX; it only applies if you update your ports tree using CVS.

The script then lists every piece of packaged software on your system that has a newer version available in the ports tree. For example, the 2 tcsh shell has been upgraded from 6.10.00 to 6.12.00. Those changes may or may not be worth updating the package for, but when in doubt, upgrade. The script also lists all the 3 available flavors of the updated package.

Dependencies in Updated Packages

OpenBSD packages that depend on other packages require the exact version of dependent packages. For example, if a package requires tcsh-6.10.00, and you install tcsh-6.12.00, you may find that the other package will not run or will not behave properly.

One problem comes from the fact that packages that are required by other packages record the names of the packages that need them in a file in their /var/db/pkg/ directory, called +REQUIRED_BY. The package tools check for the existence of this file, and will refuse to uninstall a package if it is required by other packages. You can force pkg_delete(1) to uninstall a package by using the "-f" flag to "force" the uninstall, but this will destroy the entire /var/db/pkg entry, included the +REQUIRED_BY file. You can maintain entries in this file by hand, but that is difficult and tedious. [2]

With this maze of documentation for interdependent programs, you're better off just reinstalling all your packages after an upgrade. Your data will stay; just your programs will change.

[2]If you search on the Internet, you will find a few different scripts that are designed to recurse through the ports tree and rebuild all outdated applications and their dependencies. These scripts are not yet mature enough that I'm comfortable recommending any of them, but people are hard at work on this.




Absolute Openbsd(c) Unix for the Practical Paranoid
Absolute OpenBSD: Unix for the Practical Paranoid
ISBN: 1886411999
EAN: 2147483647
Year: 2005
Pages: 298

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net