Nixstaller and the inconvenience of do-it-yourself

Nixstaller 0.2.2 is a command-line tool for creating graphical installers for archived files on Unix-like systems. If that sounds paradoxical, it is. Although Nixstaller is easy enough to learn that you can produce your first installer within half an hour of installing it, much of the process is sufficiently painstaking that it cries out for the automation usually associated with a graphical interface.

Using the Lua scripting language, Nixstaller produces installers that support both an ncurses and FLTK interface, depending what is available on the system. The default language for installers is English, but you can add multiple languages, although no UTF-8 support is available yet. Installers can be configured to have multiple screens of all the usual types, including screens for selecting a language, welcoming users, viewing the licensing, selecting install directories, viewing installation progress, and reporting on the installation’s success. The resulting installer runs from a shell script, and can run files compressed by gzip, bzip2, or lzma, installing them to multiple locations if necessary.

Creating an installer

The process for creating an installer is explained in a series of detailed HTML help files included with Nixstaller. The help includes both a quickstart and a series of three progressively more complicated tutorials, as well as appendices about scripting with Lua and a reference library of Nixstaller variables and functions. The files for the tutorials are included in the /examples directory when you install Nixstaller.

When you create your own installer, you can save time by copying and pasting files from the examples — since Nixstaller is released under the GNU General Public License — and making minor modifications. However, this is about the only timesaver that you get with Nixstaller.

The first step is to set up and populate the directory structure for the files used to create the installer. At a minimum, the project’s main directory usually contain the subfolder /.files_all for the files to be installed, the config.lua script to specify the installer’s setups, and a plain text file called welcome that contains the content displayed on the welcome screen. More complex installers may contain subfolders for the files for a specific architecture or Unix operating system, a run.lua script, and additional text files for the content displayed on other screens.

You also add a /lang directory that contains subfolders for each language other than English that the installer supports; each subfolder contains a text filed called strings that includes translations of the interface’s buttons, messages, window titles, and error messages. Currently, Nixstaller comes with only a Dutch strings file, but, with it as an example, creating another one should take only a few hours for someone fluent in the language it uses.

Another option is to include a graphic for the introduction screen. Unlike other elements, this graphic needs a specific name, since it is specified in the config.lua file. The graphic can be in PNG, JPEG, BMP, or GIF format.

Once you have organized the directory structure, the next step is to configure config.lua. At a minimum, config.lua must contain the name of the application to be installed. However, optionally, it can specify all the elements of the installer, including the graphic on the first page, the type of archive used for the files, the default and supported languages, and the architectures and operating systems.

By contrast to config.lua, run.lua is a more complex script. It defines the destination directory for installation, as well as any additional screens. These screens can include ones that let users choose a variety of options. For example, in the sample Vim installer, the run.lua file includes options for the scripting language used as a command interpreter, the toolkit for use as a front end, and the IDEs into which Vim will be integrated. Run.lua is not difficult to understand if you have at least basic scripting experience, but, even so, understanding and choosing the available options will probably take more time than any other step in the entire process.

When you have finished setting up all the installer’s files, use the geninstall.sh script in Nixstaller’s top directory to compile: for example, ~/geninstall.sh <topinstallerdirectory>. The result is a script called setup.sh in the present working directory.

Nixstaller and other third-party installers

Nixstaller is at an early stage of development, but the basic functionality is already present. And, if you are not using native package formats — which makes sense if you are thinking of cross-platform support — there is something refreshing about repurposing basic technologies like shell scripts and file compression rather than creating unique binaries, as InstallAnywhere, InstallBuilder, or InstallJammer do.

However, where Nixstaller lags behind other third-party installers is convenience. Although Nixstaller’s high degree of organization makes most of it easy to learn, too much of the procedure is sheer drudgery — either hand-editing in a separate text editor or at best creating directories and copying and pasting. All that would be tolerable if it held any advantage, but a thoughtfully organized wizard could provide the same functionality without the inconvenience. Nixstaller is usable now for anyone willing to invest half an hour in learning its basics, but, with any luck, future development will concentrate on making the program more convenient, preferably via a graphical interface.

Bruce Byfield is a computer journalist who writes regularly for NewsForge, Linux.com, and IT Manager’s Journal.