The Old Joel on Software Forum: Part 3 (of 5)

Installing software on Unix

There is a few installation kit generators around that will generate different kits from a common source. I've seen a few, but as of exactly now my brain is completely empty and I can't remember the name of a single one.

Tarjei T. Jensen
Tuesday, December 23, 2003

In general, Unix software is installed by a system administrator who actually has a clue, so installers need not be as complex. In addition, you don't have the registry to get all screwed up.

The typical Unix app install (e.g. EDA tool for semiconductor design) goes like this:

cd /some/where
gzip -d <package.tar.gz|tar xvf -

setenv PACKAGE_ROOT /some/where
setenv PATH ${PATH}:${PACKAGE_ROOT}/bin

A well-written GUI app will install just like that. Your binaries find everything they need off $PACKAGE_ROOT.

To remove?

cd /some/where
rm -rf *

This is so simple and second-nature to Unix admins that you don't need a script. Just give the instructions to do it by hand, and make the app simple enough that this is sufficient. If this is not sufficient, then your design and infrastructire is TOO COMPLICATED (got that, OpenOffice?)

Unix apps may also have license daemons. The de-facto standard is FlexLM from Macrovision, and if your target market is one that typically uses license managers, then your target sysadmin will know what to do. To Windows users, it may seem like a lot of futzing, but the Unix admins have futzed this way many times before and each site has its own policies for dealing with it.

Web apps are a different kettle of fish, as they may typically require Apache, MySQL and PHP to be installed. Locating these items is not trivial, and you may actually need an install script in this case, at least so you can ask the admin where PHP is located. Avoid the tendency to automate; Unix admins by necessity set local policy and you will likely get it wrong.

Finally: don't put anything in the root directory. An Apache/MySQL/PHP application that I am evaluating (Hi, Epiware!) does this and nearly blew up due to lack of space. Root filesystems are typically lean, mean, quick-fscking machines.

David Jones
Tuesday, December 23, 2003

David is right, but some people like all installations to be documented in a central location, and have nice tools to manage this documentation - this is what package managers like rpm, dpkg, apt, yum and others are all about.

I highly recommend EPM - The ESP package manager, at <http://www.easysw.com/epm/>. It does all common package formats on all Unixes, as well as as a portable .tar.gz installer that is no tied to any.

Anything that Mike Sweet is involved with is worth using - I've had the pleasure of using EPM, CUPS, FLTK and HTMLDOC in the past, and all are very robust, well documented and generally a joy to use.

Ori Berger
Tuesday, December 23, 2003

The best of both is to have an installation script or gui, but have the README or INSTALL file clearly state what installation parameters are configurable (and how). I.e. if your target is a linux machine, make the default installation location be somewhere under /usr/local, but allow it to be overridable in case you've got an admin who prefers (often coming from a Sun culture) to put new software in /opt. The locations of apache, php, etc, can be configured as well (for instance on a linux machine you might assume apache is installed in /usr/apache, but of course let it be overridable -- maybe a newer version is installed in /usr/local/apache).

Also, some file (like INSTALL, MANIFEST or something) should list where every file that is installed goes (most of the time that might just be "All program files are installed in $PREFIX/fooprog where $PREFIX is /usr/local by default").

Basically, I wouldn't say unix admins (in general) don't like scripts, they just don't like scripts that it takes them time to figure out how to configure things like install directory (or not being able to configure at all and having to hand copy everything and not being sure where to put it so it will work).

-Rachael

R343L
Tuesday, December 23, 2003

The most important thing to remember dealing with installs on Unix is that there is no standard installer for all Unix or Unix-like systems. As a result, each Unix vendor has their own packaging system. Solaris, Debian, Red Hat, Mac OSX all have different packaging policies. Some vendors prefer non-OS packages go in /opt, while others prefer /usr/share, etc. The "lowest common denominator" is the typical configure; make; make install technique, but this lacks any sort of configuration management. In particular, it is generally difficult to remove or update the package. This is why things like BSD "ports", Debian packages, Red Hat RPMs and the like exist. (My personal favorite is the Gentoo "portage" system, because it is very easy to create ebuilds (install/uninstall scripts) on your own).

joev
Tuesday, December 23, 2003

To add to the above, it's about time *nix came up with tool to ensure compatibility of dependencies, ie. make it possible and safe for different versions of a given dependency to coexist, something which took MS a long time (DLL Hell -> side-by-side sharing and DLL/COM redirection introduced in W2K).

Then, applications can be shipped with all their dependencies, instead of requiring the user to spend sometimes days resolving those (need .so release 2.x, which itself requires .so release 4.x... which RPM will refuse to upgrade because it breaks such and such application, etc.)

Like it rightly says on NSIS' site (http://nsis.sourceforge.net), a good installer is a must, as it is the first impression users get of your application.

Frederic Faure
Tuesday, December 23, 2003