Customizing Ports
OpenBSD includes a variety of hooks to let you easily customize how you get and build ports. If possible, you should use the OpenBSD-provided infrastructure, but there may be cases where that’s not possible. Here, we’ll look at some of the more commonly used customization settings.
Local Distfile Mirrors
While ports provide several places to get source code, you might want to override those sites. Perhaps you share a network with a major mirror site, or you don’t have unfettered Internet access. OpenBSD lets you set your own preferred mirror sites.
Preferred Collection Mirrors
Many software sources can be grouped into collections, which tend to be mirrored together. An example is the official GNU software collection. A GNU mirror site probably has everything in the official GNU collection. The Gnu C Compiler Project has its own set of software and mirrors. There are older software collections, such as SunSITE, and newer ones, such as SourceForge.
Each collection is available from a list of mirror sites. OpenBSD maintains lists of these mirror sites in /usr/ports/infrastructure/templates/network.conf.template. Never edit this file; it’s a core ports file, and upgrading changes it.
For example, here’s a list of mirrors for a smaller project, BerliOS:
…
MASTER_SITE_BERLIOS+=
http://download.berlios.de/
http://download2.berlios.de/
http://spacehopper.org/mirrors/berlios/
…
Several ports want to fetch BerliOS-related software from the main BerliOS download site. The OpenBSD port developers have identified three desirable mirrors, as listed in the variable MASTER_SITE_BERLIOS.
But suppose you have a BerliOS mirror much closer to you. Perhaps it’s not an official mirror, or you’ve managed to finagle access to a nonpublic mirror. It’s closer, it’s faster, and you would prefer to use it. OpenBSD looks at /usr/ports/infrastructure/db/network.conf before the default mirror list. You could copy the default mirror list to this file and edit it, but then you would need to manually synchronize changes during upgrades. That’s work, and therefore morally questionable. Instead, add entries only in network.conf, and include the default network.conf.template.
Suppose you have a private BerliOS mirror at http://www.blackhelicopters.org/berlios/. You would create a network.conf file like this:
MASTER_SITE_BERLIOS+=
http://www.blackhelicopters.org/berlios/
.include "../templates/network.conf.template"
The += used in both network.conf and network.conf.template means “Add this value to variable such-and-such.” More desirable mirrors appear first in the list. This network.conf entry adds the private mirror to the variable MASTER_SITE_BERLIOS, and then calls in network.conf.default, which appends all of the other mirrors. The end result is that the BerliOS mirror list will contain four mirrors: your preferred mirror first and the default OpenBSD-approved mirrors later. If a file does not exist on a mirror, the port will try the other mirrors in order.
I used BerliOS as an example because it has a small mirror list, but the same applies to any other software collection that OpenBSD recognizes. Other collections available at this time are shown in Table 13-1.
|
Collection |
Description |
|
|
Software from the GNU project |
|
|
Software from the GCC project |
|
|
Contributions to the X Window System |
|
|
Older X Window System contributions |
|
|
A collection of Sun software |
|
|
Software hosted by SourceForge |
|
|
Japanese SourceForge mirrors |
|
|
Software from the Gnome project |
|
|
The biggest Perl module collection |
|
|
Software for TeX typesetting |
|
|
Software related to KDE |
|
|
Software development hosted by the FSF |
|
|
Software related to the AfterStep window manager |
|
|
Software related to the Window Maker window manager |
|
|
Software distributed by the FreeBSD Project, but not included in FreeBSD |
|
|
Security software part of the Packet Storm collection |
|
|
Apache Foundation software |
|
|
Parts of the BerliOS Linux project |
|
|
Software from the MySQL project (Oracle) |
|
|
Python software |
|
|
Modules for Ruby |
|
|
JavaScript packages |
|
|
Software from the Internet Software Consortium |
If you have a Debian mirror in your university datacenter, list it in network.conf. If it appears a second time, later in the list, because it’s listed in network.conf.template, so what? Either the distfile is there, in which case you save time and bandwidth, or the distfile isn’t there, in which case you waste 50 milliseconds checking the local mirror a second time.
Fallback Mirrors
OpenBSD supports two fallback mirrors. If all other distfile sources fail, you can check either the OpenBSD or FreeBSD mirrors for the file. Both OpenBSD and FreeBSD tend to mirror distfiles for active ports. This isn’t preferred, because if everyone did this, it would use bandwidth that the projects need for distributing their own software. But if you’re desperate, set MASTER_SITE_OPENBSD and/or MASTER_SITE_FREEBSD to YES in network.conf.
Primary Mirror
You can have the ports system check a particular site first for all distfiles, regardless of the download site listed in the port. Perhaps you have a local mirror where you’ve stuck a whole bunch of distfiles, or you automatically load distfiles from your ports-building machines to a central location. Define this site with the variable MASTER_SITE_OVERRIDE in network.conf.
MASTER_SITE_OVERRIDE=ftp://ftp.mycompany.com/distfiles
Note
I’ve built local distfile mirrors many times, usually when starting a new job. I manage to update the mirror for about six months before some other task supersedes it and the mirror becomes obsolete, so I don’t generally recommend this practice. But if maintaining a local distfile mirror reduces your workload instead of increasing it, enjoy.
Flavors
Some ports can create multiple but slightly different packages through flavors. The Apache 2.2 web server I keep dragging out as an example can be built with or without LDAP support, as can programs with optional X support. Shells can be built in dynamic or static versions. OpenBSD’s official packages are built with the most common choices, but these alternatives are reasonable and occasionally necessary.
To identify the flavors that a port supports, go to the port directory and run make show=FLAVORS. Here’s how to check the flavors of the popular text editor Vim:
# cd /usr/ports/editors/vim # make show=FLAVORS huge gtk2 athena motif no_x11 perl python ruby
You can guess what some of these eight flavors do, but how can you learn about the others? You can check the package’s description file for brief descriptions of each flavor. Here are the descriptions for the Vim flavors, from editors/vim/pkg/DESCR-main:
…
Flavors:
gtk2 - build using the Gtk+2 toolkit (default);
motif - build using the Motif toolkit; athena - build
using the Athena toolkit;
…
Motif? I remember Motif. And now I’m going to try really hard to forget it again. But if you want Motif support in your Vim version, go for it.
To fall back to my ongoing example, here are the flavors for Apache 2:
# cd /usr/ports/www/apache-httpd # make show=FLAVORS ldap
I use LDAP to attach websites to my central authentication system. If I can get LDAP authentication on my web server, I want it.
Building a Flavored Port
Define any desired flavors with the $FLAVOR environment variable, but not in your .profile or .cshrc file, as a port will not build if you request an unrecognized flavor. Define it when you build the port. For example, while still in the apache-httpd directory, I run this command:
# env FLAVOR="ldap" make package
===> Checking files for apache-httpd-2.2.20p1-ldap
>> Fetch http://www.reverse.net/pub/apache/httpd/httpd-2.2.20.tar.gz
…
===> apache-httpd-2.2.20p1-ldap depends on: openldap-client-* - not found
===> Verifying install for openldap-client-* in databases/openldap
…
By your defining the flavor on the command line, the port knows to check for the OpenLDAP client needed to build Apache. When the build finishes, you should get a package file with the flavor appended—in this case, apache-httpd-2.2.20p1-ldap.tgz.
Flavors and Dependencies
When you build a flavored port, the flavor does not propagate to dependencies. You need to check the flavored port’s dependencies to see if they need flavoring as well. For example, my flavored Apache package calls in the OpenLDAP client, which has no flavors, but OpenLDAP calls in cyrus-SASL, and if I check that port, I see this:
# cd /usr/ports/security/cyrus-sasl2 # make show=FLAVORS db4 ldap mysql pgsql sqlite3
Cyrus SASL comes in LDAP flavor, but defining that I want Apache built in LDAP flavor doesn’t mean that cyrus-SASL will also be built with LDAP support. If I need LDAP support in this dependency, I must build it separately. I don’t need it for my environment, so I won’t bother, but check for potential issues like these when building your packages.
If you decide to rebuild a dependent port with a flavor, be sure to rebuild all the ports that depend on that port afterward. Be sure that your packages have correct dependencies using the targets print-build-depends and print-run-depends. Here, I see which ports I’ll need to build for my flavored Apache 2:
# env FLAVOR="ldap" make print-build-depends
This port requires package(s) "metaauto-1.0 gperf-3.0.4 libiconv-1.14 gettext-0.18.1p1 gmake-3.82p1 groff-1.21p8 pcre-8.30 help2man-1.29p0 autoconf-2.65 autoconf-2.68 cyrus-sasl-2.1.25p3 icu4c-4.8.1.1p0 db-4.6.21v0 openldap-client-2.4.31 apr-1.4.6 apr-util-1.4.1-ldap" to build.
I can check the flavors of each of these ports.
Building Multiple Flavors
You can build multiple flavors of one port on the same system. Each package filename includes the flavor, so you can have packages for both the Motif and GTK2 versions of Vim. Carefully inspect the dependencies to verify that each is built with the correct flavoring. For packages with flavored dependencies, I recommend removing every flavored dependency and rebuilding them all again, so that everything gets the correct flavor.
Uninstalling and Reinstalling Flavored Ports
Flavoring a package changes its name. I can’t run pkg_delete apache-httpd because it’s not installed. Query the system for the packages you’ve manually installed, and you’ll see this:
# pkg_info -m
apache-httpd-2.2.20p1-ldap apache HTTP server
…
When working with this package, you must specify the flavor.
# pkg_delete apache-httpd-2.2.20p1-ldap
apache-httpd-2.2.20p1-ldap: ok
…
Similarly, to reinstall a flavored package, specify the flavored package file.