Competing software installers

With an increasing number of software installation methods, testing cutting-edge applications may require learning about the installer first.

A well-known xkcd cartoon starts with 14 competing standards [1]. Someone resolves to simplify the situation by developing one standard that covers all the others. The result? Fifteen competing standards. The cartoon reflects a wry truth that has recently been illustrated in a proliferation of software installers that complicates matters for those who install cutting-edge applications. Increasingly, would-be users have to learn a new installer and install more software before they can get to the software they want to try.

When Linux first became popular in the late 1990s, software installation often ended in what was known as “dependency hell,” in which users had to track down the correct version of each dependency and risked leaving a package half-installed. One way around this problem was to use static tarballs – archives that included the required dependencies. These were used in the first forays into commercial Linux software, like Loki Entertainment, and they were easy to create with the tar command. However, static tarballs were not always used, probably because they often meant that one hard drive might contain several versions of the same software, which was wasteful at a time when storage was limited.

Another early solution was to install software written in C or C++ from source, creating the necessary binaries. If you were lucky, the install scripts would even list and install dependencies, although less conscientious developers might still strand users in dependency hell. Installing from source typically begins by switching into the directory that contains the source code and running ./configure to check that all the required dependencies are already installed (Figure 1). For instance, one of the first checks that ./configure usually does is to check whether the system has the GCC compiler installed and running correctly. In addition, ./compile creates the files needed to compile, such as the makefile that contains the basic instructions for compiling. If all dependencies are present, you can then compile the binary using the make command. If the build is successful, the command make install installs the application. This system at least provides some minimal guidance in dealing with problems and is still used today, as well as variants like KDE’s CMake.


Use Express-Checkout link below to read the full article (PDF).

Posted by Contributor