*Packages*
OpenBSD implements package management in the form of Package files that may be installed and de-installed.
Packages specify dependencies as well as carrying package content and when installed if dependent components are not already installed an attempt to install those dependencies from the same medium as the original package is made.
Packages installed may be listed by pkg_info, packages may be added using pkg_add and deleted using pkg_delete.
Example of pkg_add usage includes..
pkg_add mypackage.tgz
(installs mypackage.tgz from current directory)
pkg_add -v
http://ftp-stud.fht-esslingen.de/pub/OpenB...xpdf-3.01p0.tgz (installs xpdf from the snapshots (-current) feed using http protocol (ftp also supported) from the URL specified above and giving more verbose output.
Both mechanisms will pull dependencies if available in the package source.
*Ports*
I found very early on in using OpenBSD that there are a considerable number of packages that I wanted to run that simply haven't been built for the ARM architecture.
OpenBSD provides as an alternative to the prebuilt packages a build system that allows packages to be build and installed from source. This is known as the Ports tree and offers the distinct advange to users that OpenBSD packages are build by the Ports scripts and may be uninstalled and reinstalled etc using the standard Package tools once they have been built.
The ports tree can be obtained in the format of a rather large tar gzip file called ports.tar.gz (currently approaching 10Mb in its compressed form) so I would suggest hosting package builds upon an NFS server and installing from there.
I actually use a Linux host to hold the ports tree and this is mounted to /mnt/nfs on my OpenBSD based Zaurus. I then have a symbolic link at /usr/ports that points directly at the ports directory under my /mnt/nfs mount (since the ports archive is several directories down from that mount point). The upshot of this (do it however you like) is that the ports archive is directly visible under /usr/ports on the OpenBSD system.
Using the ports tree is fairly simple, simply navigate around the ports tree until you find a directory of scripts for the package that you want, enter that directory and type
make install clean
This will perform the following steps..
1) cleans the any previous build stuff, perhaps you already built an i386 version in this directory.
2) retrieves any source files needed.
3) patches those source files for OpenBSD (and for security etc.)
4) pulls all dependencies not installed and recursively starts at step 1 for the dependencies too
5) configures the source installation.
6) builds the distribution.
7) creates a fake installation environment.
installs the package using the original scripts into the fake environment.
9) packages this up as an OpenBSD package.
10) places the package into the /usr/ports/packages directory hierarchy.
11) installs the package (and all dependencies).
Note though that when working with Ports the dependency resolution will not go to the internet to try to find a pre-built binary package, it will check it's own Packages directory and if the package isn't available it will build from source.
Building from source in this manner with a considerable number of dependencies can take some time. (about a day and a half for xfce4 environment for example and about anouther day for gimp to build even with some of the dependencies prebuilt).
<HINT>
Keep a browser open to a Packages hierarchy on one of the distribution mirrors, if ports shows up a dependency that isn't installed and starts to build it then look for the dependency there. If it exists cancel the make, install the dependency package from the distribution mirror and then restart the make. This can save a LOT of time.
</HINT>
*Stuff that isn't in ports*
You will find that there is a lot of stuff that isn't in ports and potentially you will want to run some of that. It can be done, however, some care is required here.
Let me give you an example of something that I wanted to run because I am teching myself Python.
I wanted wxPython which provides an Abstract GUI toolkit which is Operating System independent.
wxPython is based around a C project called wxWidgets that allow a similar approach within C programs.
The current version of wxPython is 2.6.2.1, the dependencies, however, for this package include Gtk+2.6, however, OpenBSD has withdrawn later versions of gtk than 2.2.6 pending patches to fix various issues.
The leaves you with two options..
1. Compile all the dependencies for 2.6.2.1 wxPython.
2. Use an earlier version of wxPython.
The implications of the first option are massive when you start to drill down into it, especially since compilation is a length process.
Some of the implications are as follows :-
* You will miss out on OpenBSD patches for the dependencies that you build potentially meaning..
a. Patches that change Linux specific API calls and mechanisms to BSD counterparts.
b. Patches that apply important security updates either specific or non specific to BSD environments.
c. Patches that correct a coding ambiguity (such as a signed/unsigned cast) that effects non i386 architectures.
* You will be trying to install a library where one may exist already for the packages that you have...
a. If you overwrite existing libraries you will break them and probably the apps they are dependent on.
b. If you uninstall existing libraries then the package manager dependencies will be broken for other applications.
c. Your dependencies, being broken, will not satisfy dependencies for new packages, either being installed directly or built from the ports tree.
d. If and when you upgrade OpenBSD then you are likely to have much more trouble.
* You will start something compiling that will take a long time to run build and may not run at all after that.
My suggestion is therefore to satisfy all dependencies as best you can within the OpenBSD Packages/Ports tree and only manually build additional packages from a version in dependency sync with the libraries provided by OpenBSD.
In my case this meant using wxPython-2.4.2.4
