Author: Claudio Fontana
It could be because they need some optional and less frequently used feature that must be compiled in. A binary package might be unavailable yet from the vendor or distributor, and maybe it never will be. Whatever the reason, sometimes fetching a source package and building it is the only way to go.
The GNU autotools (autoconf, automake, libtool, and so on) have done much to ensure portability of Unix (and even non-Unix) code, and offer a familiar procedure (./configure && make && make install
) that users can run from the command line.
In order to give developers further incentive to prepare their source packages in a standardized way, and in order to initiate new users into the mysteries of source installation, I’ve launched a new GNU project: GNU Source Installer. The goal of the project is not to hide all the details of source installation. Instead, with GNU Source Installer, users can see the details in a way they can more easily understand. It also adds some features that could even be handy for the more experienced.
For example, what about a configuration window, where users can examine and adjust all package features and options (those that appear in./configure --help
), with tips containing the option comments? What about per-package file consistency checks, package tracking, and enhanced uninstallation? With the new software, developers will be able to let users do all this without losing full control, and without having to design a new package format. A normal tarball suffices, 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 can begin to notice patterns during installation, and eventually gain more knowledge of and confidence in the Unix commands in general.
Let us now follow the process of a new user who tries to run a program, only to discover he needs the latest SDL_image library. (This is just an arbitrary example.) He downloads the source package SDL_image-1.2.4.tar.gz and runs the GNU Source Installer. From the main window he chooses the Add button and browses for his SDL_image-1.2.4.tar.gz package, then confirms it with an OK.
The commands to uncompress and extract the source begin to appear in the information frame, and as soon as the program detects a configure script generated with version 2.59 of Autoconf, it reports that and presents a configuration window in which it displays and explains all options, features, and influential environment variables.
The user pauses for a moment with the pointer on --enable-maintainer-mode
, and after a second information about the option pops up. He decides he does not need that, but he tweaks some environment variables, and in addition sets his installation prefix to
He clicks OK, then waits until compilation phase completes. At this point, the program makes a test installation and discovers that it needs root privileges to install in
The installation completes, and now the installer compresses the resulting configured source again and stores it for an eventual future use. Our user gets a message about the success of the operation, and selects the new package that just appeared in the list to see installed files and statistics.
The behaviour described in this example is just the default one; there are a few options developers can tweak, such as the default installation prefix, whether to store the source, whether to strip the binaries, and so on.
Among the less evident features in GNU Source Installer are a lot of crosschecks designed to ensure that the packages are and remain properly installed. However, for most details, a fine manual exists.
Not all source package work equally well with this tool. For example, only packages where an autoconf-generated configure script is present get the nice configuration window. However, we’ve made an effort to provide 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. If our tool becomes widely used, though, it would be another incentive for developers to build good and standardized packages, and would further encourage the adoption of the autotools.
This project is very new, so although most features are already fully functional, it has not yet been tested enough for us to recommend using it on a critical system. A good way to help the project become more stable is to use it for user installations (for example, specifying
We also welcome additional developers, especially people with a good background in Unix administration, Tcl, Tk, Expect, C, xlib, or Autoconf. Our current priority is testing and fixing the existing codebase. Future plans call for better handling of non-conforming packages, more intuitive and coherent behaviour for the administrative processes, an even better interface with autoconf-generated scripts, and possibly an alternative implementation based on C and xlib.
For all links, contacts, and additional information, turn to the project home page, where the address of the maintainer is also available.