Claudio Fontana

UNIX source installations made easier with GNU Source Installer

GNU/Linux distributions and other UNIX and UNIX-like operating systems already offer a phletora of tools for installing software. These tools all rely on different package formats that enable users and administrators to quickly obtain additional functionality from their system.

The different GNU/Linux distributions put a lot of their effort into maintaining an updated and comprehensive list of ports/packages.

Sometimes, however, this great and respectable effort does not suffice, and our user remains with the only option to install from the source packages provided by the developers.
Some optional and less frequently used feature might be needed, and must be compiled-in. A package might be unavailable yet from vendor or distributor, and maybe it never will. Whatever the reason is, sometimes fetching a source package and building it is the best way to proceed.

On the developers' side, the GNU autotools (autoconf, automake, libtool, ...) have done much to ensure portability of UNIX (and even non-UNIX) code, and on the users' side, the familiar procedure (./configure && make && make install), that can be run from the command line, is becoming a de-facto standard.

 (main window screenshot)

In order to further encourage developers to prepare their source packages in a standardized way, and in order to initiate new users into the mysteries (?) of source installation, a new GNU project has been launched: GNU Source Installer.

The goal of the project is not to hide all the details of source installation. Instead, they are presented in a way that can be more easily understood by new users, adding some features that might even be handy for the more experienced.

For example, what about a configuration window, where all package features and options (those that appear in ./configure --help) can be examined and tweaked, with tips containing the option comments? What about per package file consistency checks, package tracking and enhanced uninstallation? All this can be obtained without losing full control, and without having to design a new package format. The tarball released by the original developers sufficies, provided it honours some de-facto standards about UNIX package installations.

GNU Source Installer shows all commands it executes in the background, and comments them, so a new user should be able to slowly notice the patterns which develop during installation, and eventually gain more knowledge and confidence in UNIX commands in general.

 (Screenshot of action Add)

Let us now follow the process of a new user, who tried to run a program, only to discover he needs the latest SDL_image library (this is just an arbitrary example, there is no particular reason that led me to mention this piece of software, other than the fact that it's a well-built source package).

He downloads the source package SDL_image-1.2.4.tar.gz and runs the GNU Source Installer.

At this point from the main window he chooses the Add button, and browses for his SDL_image-1.2.4.tar.gz package. Once selected, he then confirms with Ok.

The commands to uncompress and extract the source begin to appear in the information frame. As soon as the program detects a configure script generated with version 2.59 of Autoconf, it reports back to the user and presents a configuration window where all options, features and influential environment variables are shown and explained.

 (Screenshot of a complete configuration window)

The user indulges for a moment with the pointer on --enable-maintainer-mode, and after a second the available information about the option pops up. The user sensibly decides he does not need that option, and tweaks some environment variables instead. His installation prefix of choice is /usr/local.

Finally he clicks Ok, and waits until the compilation phase completes. At this point, the program makes a test installation and discovers that it needs root privileges to install in /usr/local. So a login window appears, asking the user to perform a privileged login.

The installation then runs and completes; the installer re-compresses the resulting configured sources, and stores the archive for any eventual future use.

 (Screenshot of newly built package info)

Satisfied, our user gets a message about the success of the operation, and selects the new package that just appeared in the list to inspect the installed files and statistics.

This example only describes the behaviour of the default options. There are a few other options that can be tweaked: the default installation prefix, whether to store the source or not, whether to strip the binaries, in which format the source code should be stored and so on. With the new user in mind these options have all been initially set to safe defaults.  (Screenshot of the program options dialog)


There are other less evident features in GNU Source Installer; among these a lot of crosschecks that should ensure that the packages are and remain properly installed. However, for most details a fine manual exists.

Do all source package work equally well with this tool? No. For example, only packages where an autoconf-generated configure script is present get the nice configuration window. However there was an effort to provide nice 'fallbacks', which means that even a package containing just a simple Makefile, or a custom configure script could work (if they work as they are and do not require manual editing).

Some packages do not work at all because they use different installation conventions. Though if GNU Source Installer becomes widespread enough it may become another incentive for developers to build good standardized packages, and so further encourage the adoption of GNU autotools.

This project is still very new, so although most features are already fully functional, there has probably not been enough testing yet to suggest heavy use in a critical system. A good way to help the project become more stable is to use it for user-installations (for example, specifying /home/claudio/usr as a default prefix in the preferences), reporting eventual problems or bugs encountered.

The original author also welcomes additional developers, expecially people with a good background on at least one of Unix administration, m4, autoconf, Tcl, Tk, Expect, C, xlib. The project currently aims primarily at testing and fixing the existing code-base where needed. The future should see better handling of non-conforming packages, more intuitive and coherent behaviour for the administrative processes, an even better interface with autoconf-generated scripts, and could possibly also see an alternative implementation based on C and xlib.

For all links, contacts, and additional information, the resource is always the project home page, where the address of the maintainer is also available.


This article is Copyright (c) 2005 Claudio Fontana.
It is available for everyone to copy and redistribute it, with or without modifying it, either commercially or noncommercially, under the terms of the GNU Free Documentation License.