In a very broad sense, GNU/Linux applications are distributed in two formats: source code and distribution-specific packages.
The concept of distributing an application as source code seems foreign to many computer users, but it is extremely logical.
It is usually preferable to find a distribution specific package of the application for your distribution first. Only hunt for source code if you have a reason to such as there is no package for your distro, or the source code version is more up to date than the package version.
Distribution Specific Packages
Possibly the two most common packages out there are Debian and Red Hat style packages. There are others such as Slackware, but Debian and Red Hat are probably the most common.
Debian style packages end in the extension .deb and Red Hat style packages end in the extension .rpm. In general, if you are running a Debian-based system (like Ubuntu, Kanotix, or Debian itself) you should look for a *.deb package for the application; if you’re running a Red Hat-style system (like Fedora, SUSE, or Red Hat itself), then you should look for a *.rpm package for the application.
The words ‘In general’ are emphasized above because some distributions have gone so far off the mainstream track of their flavour that this rule does no apply. For example, Ubuntu is a Debian-based distribution and therefore you should be able to use a *.deb package to install an application. However, Ubuntu has strayed so far from the core Debian stream that there are some *.deb packages that won’t work on Ubuntu. Therefore not only do you want to look for a *.deb package for your Ubuntu but you also want to look specifically for an Ubuntu *.deb package. Attempting to install a standard *.deb package may or may not work.
I am not picking on Ubuntu – this same situation exists for many distros.
You may also have some luck grabbing the proper *.deb or *.rpm from your package manager.
In the terminal window of a Debian-based system (as root), type:
apt-get install application_name
In the terminal window of a Red Hat-based system (as root), type:
yum install application_name
If you’re successful, the application will download and install itself and you’re done.
Source code is generally distributed as a tar archive which is usually referred to as a ‘tarball’. The advantage of compiling source code over installing a package is that the application will be built to your specific system. The disadvantage is that your system may not have all of the dependent packages that it requires in order to actually install or run the application. The activity of trying to install any required dependencies for an application is sometimes referred to as ‘dependency hell’ because it can be quite labourious.
Tarballs are generally archived in one of two ways: BZipped (usually has an extension of tar.bz or .tbz) or GZipped (usually has an extension of either .tar.gz or .tgz)
In general, the following steps are used to install a tarball:
- For a GZipped tarball: tar –zxvf filename.tar.gz (or filename.tgz)
- For a BZipped tarball: tar jzvf filename.tar.bz (or filename.tbz)
- (as root) make install
The configure stage is where your system is queried to see if it has all the dependent files. The make stage is where the executable is actually compiled, and the make install stage is when the completed application is installed onto your system. Generally if you make it past the configure then you’re probably going to be OK.