DarwinPorts FAQ

This document attempts to answer some frequently asked questions about DarwinPorts.

Author: Jordan K Hubbard

What IS DarwinPorts?

DarwinPorts is probably best described by comparison: It's sort of like the FreeBSD ports collection or fink in that it automates the process of building 3rd party software for Mac OS X. It also tracks all dependency information for a given piece of software and knows how to make it build under Mac OS X and install it to a common location, meaning that software installed via DarwinPorts doesn't simply scatter itself all over the system or require user knowledge of what to install in what order.

How is DarwinPorts implemented?

The DarwinPorts system is almost fully written in Tcl and designed to be embedded into other applications, such as the Cocoa framework dp-cocoa and the Cocoa software browsing front-end (that is based upon dp-cocoa) Ports Manager.app , or web-driven application management mechanisms. Being designed to be highly extensible from the very beginning, it is layered in such a way as to make it fairly future-proof in the face of future design changes and the infrastructure can be versioned independently of the individual ports, meaning that as the system evolves, older things don't just break.

Even though DarwinPorts is written in Tcl, a user also does not need to know Tcl in order to use the system or even to add new ports. Port description files, though they are actually full Tcl programs in their own right, are designed to look like nothing more than a list of key/value pairs.

How does DarwinPorts compare to FreeBSD ports?

FreeBSD ports is essentially implemented as some very impressive but hairy BSD make(1)'s macros and can be a little opaque and non-extensible from the perspective of someone looking to extend or re-factor parts of the system. Given that Makefiles aren't the easiest thing to parse, it is also harder to "mine" the FreeBSD ports collection for data to use for other purposes, such as generating documentation indexes or arbitrary front-ends for creating or managing ports.

Why did DarwinPorts start from scratch rather than adopting something like FreeBSD ports?

Even discounting some of the limitations of FreeBSD ports described above, the "science" of creating automated build systems is rather more complex than it looks at first glance and there's always room for fresh approaches to the problem, which is what we set out to do with DarwinPorts. There are certainly other systems, some of which have already been mentioned, which have made their own attempts at solving this problem and there will likely be many more such systems in the future since trying to find a single solution which pleases everyone is rather like trying to find a single programming language which pleases everyone - it's more or less impossible. We urge people to judge DarwinPorts' design on its own merits and consider it a parallel rather than a competing effort since there's more software out there than any one system can ever manage to encapsulate and automate.

What are the system requirements for DarwinPorts?

It currently requires Mac OS X 10.2 (Jaguar) with the developer tools installed since that's the reference code base most of us are using. DarwinPorts does make provisions for OS version or architecture specific "variants" of a port and we intend to leverage this mechanism to support multiple OS versions and architectures (for Darwin/x86) in a fairly clean way.

Does DarwinPorts run on any other operating systems?

There have already been patches submitted to make DarwinPorts run on everything from Solaris to FreeBSD, NetBSD and OpenBSD, though not all of this work has made it into the mainline tree yet. DarwinPorts itself was designed to be a highly portable framework in which individual ports can note which platforms they run on (via the platforms keyword) and have platform-specific rules which are automatically invoked only when the port is being built/installed on that particular platform. Work is currently underway to leverage that capability into a ports collection which supports multiple operating systems and CPU architectures.

Does DarwinPorts also do package management?

DarwinPorts works by first building software, installing it into a temporary directory (or "destroot") and then copying the contents of that into its final $prefix resting place (typically /opt/local). It also records the installation with a "receipt" so that you can ask DarwinPorts to uninstall it again if necessary.

Alternately, you can ask DarwinPorts to build a packaged version (pkg) of the software and install that with the standard installation tool (Installer.app) on Mac OS X. If the package has dependencies, you can also build a multi-part package (mpkg) which contains them as well, increasing convenience at the cost of disk space. Whichever type of Mac OS X package you install, you can also uninstall it with the Uninstaller.app provided at packages.opendarwin.org. For the future, there are plans to support the RPM Package Manager (RPM) format as well.

It will always be important to offer the capability of building things from source, of course, since something has to generate packaged versions of these individual ports, and developers who are modifying system libraries or playing with different ways of building a given piece of software may also find a canned binary package to be insufficient for their needs.

Why does DarwinPorts install everything into /opt/local by default?

First, this location can be set to anything you like by editing /etc/ports/ports.conf so nothing is fixed in place. Even the basic DarwinPorts infrastructure, which installs into /opt/local by default, can be installed elsewhere by overriding the value of PREFIX on the command line (see the README file for details). Second, we had to pick SOME location for things to install into so that they would not collide with system components or things already installed in /usr/local, so we elected to loosely follow Sun's convention and go with /opt/local.

OK, so how do I start playing with it then?

See the DarwinPorts web page for information on checking the project out of CVS. Once you get your hands on a copy, check out the top level README for installation and basic usage instructions

What's the command to see available ports?

port search ".*"

port search takes a regex as an argument so you can look for the particular port(s) you are interested in.

How do I build a Port?

There is an excellent portfile-HOWTO available, that explains this process.

Where should one send enhancements/fixes to a port?

Patches to existing ports should be submitted to Bugzilla as a bug within the dports component of the DarwinPorts product. Please assign the bug to the maintainer listed in the Portfile.

Known Issues and Incompatibilities

Unable to open port: can't find package Pextlib 1.0

DarwinPorts will not build properly against the TCL libraries shipped with earlier versions of the Fink TCL package. Either update your installed fink TCL package or ensure that you're using the system TCL library and rebuild DarwinPorts.

wrong tclsh

Some third party Tcl-Packages have the habit of overwriting the /usr/bin/tclsh link, resulting in an error during the DarwinPorts-Installation. Pointing the link back to tclsh8.3 fixes this:

sudo ln -s /usr/bin/tclsh8.3 /usr/bin/tclsh

Norton AntiVirus

The Fink project has recently discovered numerous problems including kernel panics and infinite hangs during patching when certain anti-virus software is installed. You may need to switch off any anti-virus software before using DarwinPorts or Fink.