on the edge

computers & technology, books & writing, civilisation & society, cars & stuff


Greg Black

gjb at gbch dot net
Home page
Blog front page


If you’re not living life on the edge, you’re taking up too much space.


FQE30 at speed



Syndication / Categories

  All
   Announce
   Arts
   Books
   Cars
   Family
   House
   Meta
   People
   Places
   Random
   Society
   Software
   Technology
   Writing



Worthy organisations

Amnesty International Australia — global defenders of human rights

global defenders of human rights


Médecins Sans Frontières — help us save lives around the world

Médecins Sans Frontières - help us save lives around the world


Electronic Frontiers Australia — protecting and promoting on-line civil liberties in Australia

Electronic Frontiers Australia



Blogroll

(Coming soon…)



Software resources


GNU Emacs


blosxom


The FreeBSD Project

Fri, 12 Nov 2004

Software packaging

In general, I like the FreeBSD ports system (which has equivalents in the other BSDs). If you have the CDs for a release, it’s as simple as typing “pkg_add emacs-21*” and it’s there. If you don’t have the package, it’s still simple (albeit slower). You just “cd /usr/ports/category/program; make all install”. The system fetches the distribution archive, adds any FreeBSD-specific patches, configures, builds and installs the software. This is all nice to use.

There are, however, circumstances where it doesn’t work so well. If you use databases such as PostgreSQL or MySQL, you can’t just build and install a new version—first you have to “dump” your current data using the old version of the software; then you build and install the new version; finally you “load” your data and test for breakage. And, if your own code was written in a language like Python and used your own C extension to talk to the SQL database, then you’ll have to rebuild that so that it links against the new database code.

This becomes critical if you decide to use the marvellous portupgrade program to update all your ports by magic because it will cause you real grief if you took a short cut and used a port for one of these critical and fragile components of your system. So the ports system is good, but it’s not perfect and probably never will be as there are just too many possibilities out there for the ports maintainers to cover them all.

There are other problems that are harder to understand. Lately, I’ve been evaluating FreeBSD-5.x, as it has a number of features that I really want to use. The recent 5.3 release seemed to be the first that might be ready for production use, so I was hoping to manage a simple install for testing. One thing I want to deploy is a web server that can do more than static pages without requiring me to become an expert in apache which I regard as unsuitable software to expose to the outside world. My intention was to try yaws. For that, I needed first to install Erlang.

There’s no erlang package on my CD, so I go to /usr/ports/lang/erlang and type “make”, only to be rewarded with: “erlang-r9c2_1,1 is marked as broken: Does not compile on FreeBSD >= 5.x”. It seems strange, but I decide to try it by hand. Some time later, I have the source (for a later version or Erlang, but I might as well have the latest), it’s configured and built and passes my tests. So then I build and install yaws and it handles my existing web site fine, as well as doing SSL and running yaws code (in a similar way that mod_php does with PHP code in apache). Today I will test it with CGI and PHP code and then I’ll make a decision. But if I’d relied on the ports person, I’d have rejected FreeBSD-5.3 for a task that it will probably handle with ease.