Section 9.5. Installation Tools

9.5. Installation Tools

The previous section described the various file formats that can be used to release a collection of files (i.e., a package). This section describes installation tools, which are the tools that create installers, which are the programs (and their datafiles) that actually run on the customers' machines. Installers not only unpack and decompress the files from whatever package file format was used; they also perform all the other steps necessary to make the product work on each machine. Table 9-1 shows some of the different ways to install software, along with examples.

Table 9-1. Different ways to install software
Package contents	Installation tool	Installer
Source code	Packaging tool such as tar or WinZip	Run a build tool such as make (e.g. , many open source projects).
Source code		Run a custom build script (e.g. , some Perl applications).
Compiled files		Unpack the executables (e.g., .exe files in a self-extracting zip archive).
	Packaging tool such as rpm	Unpack the files and execute other commands, using an already installed application (e.g., rpm).
	Specialized installation tool such as InstallShield	Run the programs that were shipped with the compiled files (e.g., most commercial software).
Platform-independent compiled files	Packaging tool such as jar	Unpack the files and execute other commands, using an already installed application (e.g., JVM).

Installation tools can be thought of as specialized build tools: both kinds of tools take a description of what needs to be built, including where to find the files for the build, and both can produce executable programs. Both kinds of tools need to show you what they did, and you need to be able to debug both the tool and whatever is finally produced by the tool.

In the same way that each different kind of machine requires a different set of actions to install software on it, so too do different installation tools exist for building installers for each platform. One installation tool builds Windows executables, while another builds rpm packages for a GNU/Linux distribution. The Java-based tool InstallAnywhere generates multiplatform installers from a single specification, but this tool seems to be used mostly for creating installers for products written in Java.

9.5.1. Requirements

When evaluating an installation tool, be careful to distinguish between what the installation tool should do and what the installers that it produces should be able to do. For instance, you may want to produce installers that have Japanese text, but do you also need the installation tool to be localized for Japanese?

Just as some projects choose to write their own build tool, some projects create their own installation tools. This does have the advantage that the source code for the tool can be reviewed and tested as exhaustively as the rest of the product. However, this approach is a substantial amount of overhead for most projects, so carefully consider the existing tools first.

9.5.1.1. Tools

Some desirable characteristics of installation tools are:

Small, fast, repeatable: Just like a compiler, an installation tool should not produce overly large installers; it should run as fast as possible; and the resulting files should be the same each time the tool is used.
Portable: The configuration files for the installation tool should be portable to other machines, and ideally to other platforms. Absolute pathnames should not be part of the description of an installer. If the description of the installers are in a text-based format, this makes comparison easier.
Debuggable: Debugging how an installation tool creates an installer and debugging what an installer did when it ran are both tasks to consider when deciding how easy it is to work with each installation tool. The ability to simulate running an installer can also ease its development effort. Installer debugging logfiles should contain line numbers, timing information, and other descriptions of each part of the installation tool as it was executed.
Automated: Integrating the installation tool with an automated build process should be possible, by using a command-line version of the tool, for example. This includes signing packages.
Multilingual: An installation tool should be able to produce installers that are localized for different languages while running on a nonlocalized machine. In other words, you could use a machine with an English operating system to produce Japanese and German installers, as well as producing English installers.
Produces installers for updates: The installation tool should be able to produce installers to update products that have already been installed. Making customers uninstall a previous version of your product is ugly, and once they've uninstalled your product, they might install someone else's product instead. Some installation tools can produce installers that can be used to check periodically for updates over the Internet.
Supports different media: You should be able to create an installer suitable for download from a web site, as well as an installer for releasing on CDs or DVDs. The installation tool should be able to put the different files onto multiple CDs or DVDs in such an order that the most common installation sequences never require the customer to reinsert a disk.
Flexible: A good installation tool can be extended to do things during an install that no one imagined when the tool was designed. Sometimes this is done with a scripting language.
Stable: Beware of the ability to automatically update the installation tool; such updates can make it hard to be sure which version was used for each product. You should update only when you have chosen to, not just because the tool prompts you to update. This feels like an installation tool just demonstrating that it can create an installer for itself that checks for updates.

9.5.1.2. Installers

Some characteristics to look for in installers and uninstallers, no matter which platform or packaging format is used, are:

Simple: The main purpose of an installer is to make a product work correctly on a customer's machine and to do this as simply as possible. This means that wherever possible, the installer should run tests (rather than asking the user questions) and then copy the product's files to the right places on the machine. Anything other than major product configuration can be done by the user after the install has finished, including entering license keys.
Atomic: A failed installation should remove all traces that it was ever there. Leftover files can make subsequent installations fail in obscure and hard-to-debug ways.
Provides an installation summary: Before making any changes to the machine, the installer should show at least the product's name and version, where it will be installed, how much space it will take up, and any other useful configuration details.
Supports unattended installs: System administrators installing your product on numerous machines will want two things: the ability to install it with no input, and the ability to customize the installer (for instance, by adding other, unrelated packages). The first can be supported by reading responses from a text file or even by using Expect (http://expect.nist.gov). For silent installs, the user should also be able to redirect all output from the installer to a file. Many installation tools are able to create installers for this kind of unattended install, but customization is less commonly supported.

Some smaller, but helpful ideas for graphical installers are:

A map of where you are in the install, and some indication of how much longer the installation should take
Go Back buttons, to let you return to previous screens and change the choices that you made there
An option to restore the default choices on a screen

9.5.2. Unix

Installer programs for Unix have become more common since the 1990s, with the rise of GNU/Linux and CPAN for Perl modules. The lack of standard locations for key files on a Unix machine means that you always have to be aware of how each machine is configured, and so installation using source code is more common in Unix than on Windows machines. I'd like to report that Unix configurations have become more standard and that there was an obvious installation manager to choose, but I can't. I recommend using the default installation tools that already exist on your machine and then trying others if and when they fail. Using packages from a single source may help your installations to succeed more often.

9.5.2.1. Source code and binaries

The source code to your product can be distributed using one of the packaged formats discussed in Section 9.4, earlier in this chapter. They're easy to create and, if the customer has the right tool, easy to unpack. The packaged files may contain ready-built binaries for each platform or, more commonly in the case of open source products, the actual source code itself.

There are de facto standards for files to help customers complete the installation of the product after unpacking it. There are files such as README (start here first), LICENSE or COPYING (legal stuff), HACKING (how to change the source code), and the vital INSTALL file, which usually tells you how to actually use the product. Build tools such as GNU Autotools (see Section 5.5.3) provide help with creating such files. Another, much more formal standard is the Linux Standard Base (LSB; see http://www.linuxbase.org), which describes what to expect from a standard GNU/Linux machine.

Installing products from their source files is probably the most portable way to install software onto a wide variety of Unix platforms. When the more convenient rpm or deb packages fail to work, or when you want to know why the product isn't supported on your platform, it's time to "use the source, Luke."

9.5.2.2. RPM package manager

The Red Hat distribution of GNU/Linux is responsible for creating the rpm format and its companion installation tool (also named rpm), which now ships with each copy of Red Hat Linux. Various products were repackaged in the rpm format for Red Hat, and web sites such as rpmfind (http://rpmfind.net) grew up to help find RPMs for each package. rpm maintains a database on the local machine to track every package that has been installed, and it's relatively easy to use. However, if an installation fails because other packages have to be installed first, rpm simply leaves you with the name of the missing packages, and it's back to rpmfind you gothere is no automatic downloading of other required packages.

In an attempt to make the whole process of installing and upgrading packages a little easier, Red Hat created up2date, an application with both command-line and graphical interfaces, to download and install not only packages you specify, but also those required by your specified packages. However, up2date requires that you sign up on the Red Hat Network and register your machine and its current configuration.

Other choices for rpm-based installation managers are Yum (http://linux.duke.edu/projects/yum), which is becoming the de facto standard for RedHat, and apt4rpm (http://apt4rpm.sourceforge.net), which is a version of apt for rpms by Conectiva, the Brazilian GNU/Linux distribution (now part of Mandrakesoft). Both of these installers can create their own package databases from the local rpm one, use signatures, and download any other necessary packages. One installation manager that claims to handle conflicts better than all others is the Python-based Smart Project Manager (http://smartpm.org), developed by Gustavo Niemeyer, who was part of the team that created apt4rpm.

To unpack the contents of the rpm file myproject-1.0.0-i586.rpm into a fresh directory, simply type:

rpm2cpio project-1.0.0-i586.rpm | cpio -i --make-directories

9.5.2.3. apt

Debian Linux's deb packaging format also has its companion installation tool named dpkg, but the installer tool that is more frequently used is apt (Advanced Packaging Tool), which has always supported downloading the dependent packages needed to make an install succeed. apt's other advantage over rpm is that it uses benchmark systems to determine which versions of software should work best on your system. One GUI for apt is synaptic, but there are a number of others available.

apt has also been made to work with rpms in a few different ways. The tool apt4rpm (http://apt4rpm.sourceforge.net) is a version of apt for rpms. There is also alien (http://www.kitenet.net/programs/alien), which is a package converter that can convert between rpm, deb, and several other package formats, allowing you to use deb packages like rpm packages, and rpm packages like deb packages.

9.5.2.4. CPAN

CPAN (Comprehensive Perl Archive Network) is a good example of a successful installer, though only for products in one language: Perl. The command-line interface for using CPAN is straightforward, and there are plenty of graphical interfaces available too. The modules are downloaded as gzip'd tarballs of source code and built locally using make. Any other missing modules can also be automatically downloaded. CPAN uses a worldwide collection of mirror sites, all containing the same packages.

The strengths of CPAN are that the range of modules is enormous and that it is a focal point for the Perl community. It has scaled well with a large number of users and is one reason for the popularity of Perl. The main weakness is that all of the modules are developed independently, so you may end up with long installation chains (see Section 9.6 later in this chapter) or with two different modules needing different versions of another module.

9.5.3. Windows

Some good resources for lists of mainly Windows-related installation tools are the Open Directory category at http://dmoz.org/Computers/Software/System_Management/Installers and InstallSite (http://www.installsite.org/pages/en/msi/authoring.htm), which is a web site dedicated to Windows installers and to InstallShield in particular.

9.5.3.1. Windows Installer

Windows Installer is the name of the installation toolset that has been released with all Windows releases since Windows ME. Now at Version 3.0, Windows Installer produces MSI files that can be executed to behave as an installer. The benefits of Windows Installer include atomic installs, add/remove program integration, checking for files in use, and full support for automatic reboots. If you want your product to be compliant with the Microsoft Windows Logo program (http://www.microsoft.com/winlogo), then it has to be released as an MSI installer. This is one good reason why all the commercial installation tools now support MSI.

The main drawbacks of Windows Installer are its complexity and the size of the generated installers. Many of the restrictions imposed by earlier versions of the MSI SDK seem to have been fixed in the latest version.

One interesting installation tool is WiX (http://sourceforge.net/projects/wix), which is used by Microsoft internally to create MSI files. WiX uses XML for its configuration files. There is an overview available at http://www.ondotnet.com/pub/a/dotnet/2004/04/19/wix.html.

9.5.3.2. InstallShield

InstallShield from Macrovision (http://www.installshield.com) is probably the most commonly used commercial installation tool. InstallShield is also one of the oldest such tools. It costs $2,499 for the top-level edition. Earlier configurations were not stored in XML, but they were mostly in text files. You can build installers for a number of different platforms, but most InstallShield installers appear to be for Windows. Available in English, German, and Japanese, InstallShield can produce installers in over 30 different languages. It has integrated support for Visual SourceSafe and a huge range of other features, which explains the large number of choices on every screen of the UI.

Simple projects are easy enough to create using the wizards that come with the tool, but larger ones can require some time to get right. The installer debugger and the binary install logs in C:\Program Files\InstallShield Installation Information can help you greatly with this. There is a list of rather overpriced InstallShield books at InstallSite (http://www.installsite.org/pages/en/books.htm), along with a good community of users.

9.5.3.3. InstallAnywhere

InstallAnywhere from ZeroG (http://www.zerog.com), now also owned by Macrovision, is a good example of a newer type of installation tool, one that uses the platform-independent nature of Java for its installers. The cost for the top-level edition is $2,999. InstallAnywhere installers are specified using XML configuration files created by a nicely uncluttered UI. Almost any platform that has a JRE (Java Runtime Environment) is supported, both for the installation tool and for the installers that it creates, so creating installers for many platforms is faster than usual. InstallAnywhere is focused on releasing Java applications; it has a documented API so you can call it from other Java applications and it even has an Ant task for creating installers. The tool is available in English, German, French, and Japanese.

When you run an InstallAnywhere installer, it communicates very clearly what it is doing. There is a list of steps to show you what stage the install is in, and there are thoughtful buttons to restore choices on a page after you have messed around with them and forgotten what their original values were. The summary page that is shown after the installer has gathered all the information it needs, but before the install begins, is quite thorough.

To enable extensive logging in debug mode when you run an installer, press and hold Ctrl on Windows or set the environmental variable LAX_DEBUG to TRue.

The disadvantage of all this portability is that the customer has to have a JRE on his machine to use the installers that are generated by InstallAnywhere. This is hardly unlikely if the final application is a Java application, but it can be a hindrance to installation. InstallAnywhere does let you bundle a JRE together with the installer, but of course this makes the installer much larger.

9.5.3.4. Wise for Windows

Wise for Windows from Altiris (http://www.wise.com) is the other commercial installation tool that seems to be most commonly used. The top-level edition retails for $1,999. There is a comparison of Wise for Windows and InstallShield at http://www.installsite.org/pages/en/msi/comparison.htm, and there are some more technical tips at http://www.ewall.org/ContentExpress-display-ceid-8.html. Most reviews comparing InstallShield and Wise for Windows seem to feel that the two tools are roughly comparable in what you get (both good and bad) for your money.

9.5.3.5. InnoSetup

InnoSetup (http://www.jrsoftware.org/isinfo.php) is an open source installation tool by Jordan Russell. It has an active community and some enthusiastic users. However, InnoSetup runs only on Windows, produces installers only for Windows, and does not use the MSI installer format provided by Windows. There is good support for installers in languages other than English, and indeed a single installer can be run using many different languages. Since the tool is written in Delphi, Pascal is used to write any scripts that are executed by installers, but the UI is clear and a script debugger is nicely integrated into it. The documentation is concise, and there are a number of third-party tools built on top of InnoSetup. One well-known project that uses InnoSetup for its Windows releases is Subversion (see Section 4.6.2).

9.5.3.6. NSIS

NSIS (Nullsoft Scriptable Install System) from http://nsis.sourceforge.net is another open source installation tool that runs only on Windows and produces installers only for Windows. Originally developed by Joost Verburg for the WinAmp music player, its claim to fame is that it adds only 34KB of overhead, so its installers are almost as small as possible. Like InnoSetup, it doesn't use MSI, so you can't create installers that are Windows Logo-compliant. NSIS is used by a number of low-cost products, including Google's Gmail Notifier (http://toolbar.google.com/gmail-helper).