rds :: graphikos

[ home | photos | gallery | scheme | notes | blog | facebook | twitter | youtube | last.fm | myspace | del.icio.us | EverythingHerePlus ]

OSX Needs an Unified Command Line Package Management System

Draft Status: Incomplete

While OS X aficionados laud the simplicity of the Mac OS X Installer, it is lacking in several regards. As this essay's concern is with command line installations of Unix software, it will not explore all of Installer.app's shortcomings. However a brief mention of the legendary Classic installer's to handle fine grained installation (ie. install single items) and remove items deserves mention considering such functionality is missing from its OSX counterpart. Furthermore, Installer.app isn't the optimal solution for traditional Unix software installation for several reasons examined within.

Defining the Problem

One of OSX's highly touted 'features' is that one can install and run a wide range of traditional Unix software via the BSD subsystem. Indeed, this is one of OSX's great strengths. The status of how this is handled is in total disarray. While examining every installation system available in the Unix-like universe is outside the scope of this essay, several systems are currently employed and explored within.

Another issue of serious concern is OSX is unique in that it really exists in two forms. There is the standard Mac OS X installation that one would find on the vast majority of capable Macintosh systems. This form includes all of the proprietary Apple software including its window manager, iApps, QuickTime, etc. This form or domain is where Installer.app is most appropriate for installing OSX style binaries. The second domain of Mac OS X is the open source 'Darwin' operating system which underlies the standard OSX installation. 'Darwin' exists both on capable Macintosh and X86 systems. Moreover, these forms are not exclusive, and one cannot assume that a system a with standard OSX installation will not at times be run in a 'Darwin mode.' A simple login as >console presents the 'Darwin mode' which operates as a standard BSD console and also accommodates running XFree86 (at least before 10.3).

Before continuing it is important to define what is meant by traditional Unix software in the context of this essay. This is software that is typically (but not always) installed at the command line. They are packages that nearly always run at the command line. They are packages with established methods of installation that don't lend themselves to installation via Installer.app. A handful of good example are packages like texinfo, lynx, kawa, or bigloo.

Existing Methods

Apple's Installation Tools

Many methods exist for installing traditional Unix software on Mac OS X. The most vehement OSX proponents seem to have adopted an attitude that Installer.app is the only correct way to handle installations. This notion is flawed in several regards. First Installer.app still provides no way to 'uninstall.' Secondly, this places a great deal of work on the developer or porter of a package in terms complexity and divergence from installation methods on other platforms (see UNIX Porting Guide). While some may argue that this should be the case in order to provide the 'best user experience,' it would certainly slow the porting of packages to OSX. Further, at the risk of sounding somewhat elitist, are end users that can't manage anything more than button click installs really likely to use packages that require the command line and an intimate knowledge of things like runtime flags? Lastly, this in no way addresses 'Darwin' installations, which neither have nor can use Installer.app. Ironically, this audience is the most likely to need and use traditional Unix software.

This is not to say that using Apple's porting guidelines and Installer.app are always inappropriate. Several highly complex projects like XDarwin utilize Installer.app making it widely available to even the most novice users. However, XFree86 is also available traditionally for 'Darwin' installations. Furthermore, there is a large group of individuals supporting XonX to help deal with the porting issues, which isn't always the case for small projects and ports.

Porting from Source

An acceptable and traditional way to install traditional Unix software is to download, build, and install from the source distribution. Typically this involves downloading the source either packaged (usually gziped tar files) or via a CVS or other source management system. Once downloaded, the usual steps are:

./configure # (with appropriate flags)
make # (or bsdmake in instances)
make check # (or make test if appropriate)
make install # (usually as sudo or root)

To all intents and purposes, this works fine with many existing software packages. There are drawbacks to this methodology, starting with the inability to remove a package in a simple and reliable way once it is installed except in the rare case that the makefile has make uninstall routines. This issue also arises when updates may not install the same files, leaving orphans files throughout the file system. Further, it assumes that the end user has installed Apple's developer tools and has some understanding of the command line. Rather than go into all the issues revolving around source ports, suffice it to say that the subsequent package management methods discussed below wouldn't exist if there was a consensus that source ports were the best way to distribute and install traditional Unix software.

GNU/Linux Style

There are quite a few package management tools employed in the Linux world. SuSE, Red Hat and some others use RPM. Debian uses Dpkg (apt-get), which is of interest because this is the method that the Fink Project uses. There are a few others in existence as well. The Fink project has done an admirable job in making a great deal of GNU software easy to install, and even has an available GUI front end. However, Fink has some issues which depending upon one's perspective, are problematic. Fink installs a 'ports tree' in a root level directory named /sw which it uses for both code and binaries. While the developers' rational for this is explained (to their satisfaction) and the end user can override this behavior, it is not where experienced Unix user expect to find tools like texi2html. There is also some question as to whether Fink works with straight 'Darwin' installations -- particularly X86 that is not answered in their FAQ. Maybe a reader on their mailing list can address this question. Fink has many merits, and one would hope the project continues at least to help novice users. Fink does not handle things the 'BSD Way,' which may or may not be a good thing depending on the background of the end user. There are other projects that have similar issues.

BSD Style

Considering Mac OS X receives much praise as being based on BSD, it follows that the BSD way of handling package management should be adopted. Among the 'free' BSD distributions (OpenBSD, NetBSD, FreeBSD), there is a de facto standard for command line package management. The ports and packages system, specifically the pkg_* suite of utilities provides a comprehensive system to manage installs, uninstalls, installation queries and more. This system is tried and true and provides for all of the shortcomings discussed with the other methods above. In addition to

References

UNIX Porting Guide, Apple Computer, Inc. 2002