Installing software in GNU/Linux looks quite different to the way you’re probably used to from Microsoft Windows. This is due to philosophical reasons :). GNU/Linux is a free (as in freedom) operating system. Most of the software is free as well. Thus, the programs can better cooperate with each other and often depend on each other for getting a job done.

Installing from packages

Packages are the Linux equivalents of Windows EXE installers. There are different formats of packages though. The differences between these formats are not the subject of this article, but it’s good to know they exist. The most popular are the following three:

• RPM, first appeared in Red Hat Linux, now used by numerous distros like Suse, Mandriva, Fedora Core, Yoper or PLD Linux
• DEB, a Debian package format, now used in many Debian-derived distros, i.e. Ubuntu, MEPIS, Xandros and Knoppix
• TGZ, a traditional package format used in Slackware, as well as (in a modified version) in Arch Linux, Frugalware, KateOS and other distributions.

Installing software from packages is usually as easy as double-clicking on a downloaded DEB or RPM file. Single packages can be also installed manually. For RPM packages, the magic command is:

rpm -Uvh package_name.rpm

For DEB packages it’s as easy as:

dpkg -i package_name.deb

Installing packages manually get quite cumbersome when the downloaded package has some dependencies. Using a package manager (see next section) is a much smarter choice in such case.

Installing software from repositories

In order to make software installation easier, Linux distributions provide so called software repositories — central servers where the packages are stored (applications, libraries, drivers or pieces of documentation) and stay available for direct installation.
Thanks to the repositories, plenty of apps can be installed in a standard way by using a single program called package manager (or software manager). Each distribution uses its own package manager. The most popular are: APT (Debian systems), Yast (Suse) and Smart (Mandriva, Yoper, etc). The approach with repositories is actually quite revolutionary. The traditional way of installing (proprietary) software includes: searching the web, downloading the app, double clicking on it, hoping there is no malware inside, clicking the “Next” a hundred times, using it. In Linux, a single command is enough to trigger the automatic software download, installation and pre-configuration. Nice?

Pic 1. Installing new software in Ubuntu 6.06 using the
gnome-app-install applet

Most distros provide their own application for installing software from the repositories. The functionality provided by those package managers is usually searching, installing, removing and sometimes configuring the packages. Almost all package managers provide command-line and graphical user interfaces. Command line is good for quick software installation when we know what we want to do. For example, the following command will install Mozilla Firefox browser in Debian or Ubuntu:

apt-get install firefox

And the next command will search for the packages containing all sorts of codecs:

apt-cache search codecs

In Mandriva, there is urpmi or smart, in Fedora Core yum, in Arch Linux pacman, but all of them provide very similar functionality. The most popular graphical frontend for installing apps is Synaptic, available for both RPM and DEB distros.

Installing software from repositories is the recommended way for most distros, mainly because the package managers take care of the a href=”#dependencies”>dependencies automatically. Only if the package you are seeking is not available in either default or extra repositories (which can be added and searched easily), an alternative way of installing should be used. More about it in the following sections.

Binary installers

This is the way of installing software known from the Microsoft systems. Some applications, usually due to unfriendly licensing (i.e. NVIDIA and ATI drivers) are not available as standard Linux packages (although some distros make “fake” packages including binary drivers, but that’s not the point). When software producer doesn’t release the source code of their application, the only way is to install it in a “black-box” mode (you don’t know what’s inside, you just run the program and hope it works).

Note that binary installers can damage your system if you run them as root (which is usually required to have them do anything useful), since no one except the people who made it know what’s inside. Use them on your own risk. You have been warned.

Installing binary apps is usually as easy as double clicking on the downloaded binary installation file. In order to run the program in Unix-like systems it needs to have an “executable” permission, so it may be necessary to grant this permission to the downloaded file either from the file manager or from command line. The latter looks like:

chmod u+x the_file

When the file is already executable, we can then run it from the command line like this:

./the_file

Note that there is a ./ prefix is used in UNIX to run applications which are located in the current folder. If you wanted to run an application located in a different folder you should type . /path/to/folder/the_file (with a dot a the beginning).

Pic 2. Binary RealPlayer 10 installer in action

Compilation and manual installation

Manual compilation of programs is the traditional way of installing software in Linux. GPL-licenced apps are available with their source code which means we can manually compile it and install in our system.
This way of installing software is preferred by some distributions (like Gentoo) as well as most of the BSD systems. If we choose the compilation flags reasonably, we can achieve superior speed and efficiency of the installed app. On the other hand, manual compilation is far from being easy to use since it usually involves manual dependency handling (installing the applications which are required by the program we want to install) and is time-consuming (compiling of KDE or OpenOffice.org can take even a few days!)

In order to compile anything, we need a compiler. We can check if we have one installed in our system by executing in the command line:

gcc --version

If gcc compiler is absent, we need to install it (preferably using the software manager of choice). In some distros, all the applications usually required for building the package from sources are gathered in one meta-package, i.e. in Ubuntu the name of this package is build-essential.

A standard way of installing apps from source code is presented below. Note that the commands need to be invoked in the folder containing the unpacked source code of the application we want to install.

./configure
make
make install

Right now, the software should be installed in our system. If errors occurred, we need to read the messages carefully and probably install additional packages which are required to compile the desired program. The list of dependencies is usually located in README or INSTALL text file which is delivered together with the sources.

As mentioned before, there are distros like Gentoo where building from sources is the default way of installing new software. Portage system with a large repository of packages with source code available allows for a lot easier installation from sources. This looks much like installing packages via APT or urpmi. The command used is Gentoo is emerge. So, for example, issuing the following command:

emerge mozilla-firefox

triggers automatic download of Firefox source code, automatic compilation and installation of Firefox in our system. All the dependencies are downloaded ane d compiled as well, so the only downside is time (compiling can be sometimes really time-consuming).

Compiling from sources has another benefit we haven’t mentioned yet. When building your own package, you can customize the program to your needs. You may remove unwanted features or even get new ones (those that are not activated by default and not used in standard packages). So, sometimes it’s the only option if you need some special, usually experimental feature that is not included in your distribution’s default package.

What are these dependencies?

So, what are these dependencies, anyway? In short a dependency means that one package needs another package for proper functioning. And why is it so? Well, it lays down deeply in the history of Linux and free software. GNU/Linux as a system is all build from modules. There are numbers of programs designed to do one specific task and do it well. Those programs are interconnected with each other and can use the functionality of each other through an open programmers’ API. This way, lots of programs use the same code for typical operations (like cd-burning), but provide a different user interface or other complex functionalities which are independent of the backend. Thus, no redundant code needs to be written, saving the time of both programmers and the users.

There is an alternative to the dependencies which is called static packaging. In short, it means that a single application contains all the required dependencies build in. This is easier to install (no need for installing dependencies) but it takes much more disk space and of course it’s not the optimal way of handling software (it may be that one single app is installed in our systems 10 times, in different software packages). That’s why, dynamic packaging is generally preferred by the Linux distributors, with all its drawbacks (including the so called “dependency hell”). When good package manager is used, the dependency hell is not a big issue though, because the system takes care for handling them nicely on its own. The only popular free OS that uses static packaging is PC-BSD with its PBI package format.

The program is installed. Now, how do I run it?

It’s easy! The programs after installation usually do not create desktop shortcuts unasked. You have to create them yourself if you want to (which is fairly easy in Gnome and KDE). If you installed the program from a package, it usually adds itself to the system menu under an intuitive category. If, for some reason, it wasn’t the case, you can always create the menu entry yourself or run the program directly from the command line.

By default, the executables of the installed apps land in one of the two system folders. The apps installed via package manager should be found in:

/usr/bin

Applications compiled manually and installed via make install go to:

/usr/local/bin

In order to run an application, you need to enter its name in the terminal. Of course you can also use desktop shortcuts or main menu for that as well.

More about software management in GNU/Linux

• Adding Repositories in Ubuntu
• Video: Installing Software on Ubuntu Linux by wu.acm.org
• Building and Installing Software Packages for Linux
• How to install ANYTHING in Ubuntu - a graphical guide for all new users with a Windows background using Ubuntu