Competing software installers

Command Line – Installersn

© Lead Image © Dean Dropbot, 123rf.com

© Lead Image © Dean Dropbot, 123rf.com

Article from Issue 247/2021
Author(s):

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).

Buy this article as PDF

Express-Checkout as PDF
Price $2.95
(incl. VAT)

Buy Linux Magazine

SINGLE ISSUES
 
SUBSCRIPTIONS
 
TABLET & SMARTPHONE APPS
Get it on Google Play

US / Canada

Get it on Google Play

UK / Australia

Related content

  • pip3 Primer

    As a replacement for pip, pip3 offers a complete solution for binary packages. Here's how to get started with this increasingly popular Python installer.

  • Smart Package Manager

    The package manager is one of the central components on any Linux system. If you have a system with unreliable package management – such as Suse Linux 10.1 – you may want to consider the Smart alternative.

  • Command Line: Apt-get

    Dependency tangles fall away with the Debian package system.

  • Command Line: Yum

    The RPM package manager Yum has its own advantages over other tools.

  • Topgrade

    Topgrade detects all the package managers installed on a system and executes them one by one at the command line.

comments powered by Disqus
Subscribe to our Linux Newsletters
Find Linux and Open Source Jobs
Subscribe to our ADMIN Newsletters

Support Our Work

Linux Magazine content is made possible with support from readers like you. Please consider contributing when you’ve found an article to be beneficial.

Learn More

News