Installing stuff on Linux
This blog is a little different in that it isn't from multiply, but really provided specifically for my ham friends. This is an oversimplified view of installing software on Linux, and my Fedora friends would feel compelled to "correct" it, making it more complete, but less understandable!
I am often asked about installing software on Linux. Sometimes someone has tripped across one of the old ways, and can't believe that we put up with anything so difficult. Sometimes they are just confused by all the choices. This is an attempt to provide a place to send them.
Overview
Once upon a time installing software on Linux was hard ... really hard. As a result, Linux got rapped as being hard to use. Well, that day is long past and today installing software, and even upgrading operating systems, is many times easier than on Windows. The problem is that things don't go away in Linux, so there are multiple ways of doing things. All the old bad ways are still available to those that like nostalgia. This array of possibilities can be a bit confusing.
This note is an overview of the history of installing software on Linux. Although it is written from a Fedora point of view, pretty much the same can be said about Debian (Ubuntu) or any other distribution, it's just that the names of some of the tools are different.
Tarballs
In the beginning there was tar. tar is a program for archiving files to tape. In fact, tar comes from Tape ARchive. It is incredibly simple-minded in how it works, incredibly difficult to use. But it is very flexible, so when people want to put a bunch of files together they use tar, even though the magnetic tapes tar assumes have long since disappeared.
An application is nothing more than a bunch of files that need to be put in specific places on the computer. OK, on Windows there is a little more to it, but Linux, unlike Windows, avoids unnecessary complication. So basically it is a bunch of files. Unfortunately, because Linux is open source, different people with different priorities have gathered around different Linux distributions or "distros". These distros have differences in where they put things and what bits of software they include, although at the core, they are all basically the same.
Because Linux is open source, it is desireable to distribute the source with the application. This allows you to examine the source so you can tell it is doing what you expect, and to modify it should you feel it needs to work in a slightly different way. It also helps get around some distro-to-distro differences if you actually compile the program during the installation.
A standard (well, sort of standard) has developed for installing software from a tar. Basically, there are four steps; 1) unpack the tar, 2) configure the files for your distribution, 3) compile the program, and 4) move the files to where they belong. Only the last of these steps requires that you have privileges, and Linux users don't like to operate from a privileged environment except when it is absolutely necessary.
While most of these steps can be done with graphical tools, in theory, installing a tarball from the command line is pretty simple:
tar -xzf (name of the tarball) cd (name of the directory that was created) ./configure make sudo make install
Of course, the real world is never as well behaved as the theoretical. What really happens is that you do ./configure and get a bunch of fairly cryptic messages. You eventually figure out that you need three or four development tools in order to compile the program, so you hunt those down and go through the same process. Discovering of course, that each of those needs three or four others. After a few days you reach the bottom of the dependency tree and you can proceed to the make.
make is where your trouble really begins. Naturally, ./configure didn't find all the dependencies. In make you are typically greeted with several screenfulls of messages, most of which really don't matter. Of course, unless you are an expert, you don't know which matter and which don't. But you eventually figure out that there are a half dozen more things to install, each of which has it's own dependencies, and on and on. Only after you have installed those things and try again do you discover that make didn't tell you all the things that were missing the first time.
If you haven't gotten frustrated and given up, you might eventually try the sudo make install, by now being surprised that there are no nasty messages! Until, of course, you try to run the application, and discover another dozen things you are missing.
Installing an application from a tarball can turn into a career.
Enter the RPM
In the typical, recursive way Linux has of naming things, RPM stands for RPM Package Manager. Helpful, huh? RPM tries to solve three problems. First, since an RPM is built for a particular distro, it already knows where things are, so much of the ./configure step can be eliminated. Secondly, since again we know the distro, we can distribute already compiled binaries. Finally, we can identify the dependencies up front, so the missing pieces can be identified without jumping through all sorts of hoops.
Distributing things as source is still part of the culture, so there are two kinds of RPM, the source RPM and the binary RPM. The source RPM has not only the source, but also the instructions for installing the source on your system and making the binary RPM. The binary RPM contains the actual application, the instructions for installing it, and the list of dependencies. There will typically be multiple binary RPMs for different platforms. Depending on the application, there may be separate RPMs for 32 and 64 bit Intel platforms, or for Power PC, even for S/390.
RPM solves many of the problems of tarballs. You grab the RPM you want, and install it. Couldn't be simpler. In fact, on most distros, if you find the RPM on a web site somewhere and click on it, you will be asked whether you want to install it. No pain.
Yeah, right! We still haven't really addressed the dependency issue. If you have all the dependents already installed the RPM is a piece of cake. But chances are, you don't. And each of those has it's own dependents, which in turn ... Well, you get the picture
The good news is that there are no cryptic messages to decode, and since you don't really have to do the compile unless you want to, there are fewer other packages to hunt down. But still, it's a bit of a game of chance. It might go well, or you might be weeks hunting down dependencies.
And then along came yum
yum is actually the latest in a series of package management programs. It has evolved over the years to become a very fast and very friendly program.
What happened is that the various distributions began to build repositories containing RPMs of popular packages built for their distribution. This provided a simple way to locate the RPM for any particular application. Once these large repositories got established, it became a simple step to use them to resolve the dependency issue.
What yum does is quite simple in concept. You tell it what you want to install:
yum install fldigiand yum goes out and downloads the RPM for fldigi. It then looks at that RPM and determines what it needs. it looks at your system to see what you already have, and then goes and downloads the needed packages. It keeps doing this until it has all the dependencies identified, and then goes ahead and installs everything in the right order.
(It doesn't quite work that way, it keeps a database so it can be a lot faster, but in principle that is how it works).
yum and rpm can also update packages. If you do an yum update it identifies anything in the repository that is newer than what you have, downloads the new version, removes the old version and replaces it with the new. You can update your entire system or an individual package. You can also remove packages, search for packages, etc.
The latest version of yum can actualy download just the differences, so an update consists of applying the differences to your system instead of taking the time to download the entire package again. Even on fast connections this can be a noticeable improvement, but to people with slower Internet connections, it is a godsend.
PackageKit
Personally, I like yum. You open a terminal window, type sudo yum install whatever, and "whatever" is installed, no muss, no fuss. But there are those that are scared to death of typing commands. For those people, there is PackageKit.
PackageKit is basically a GUI wrapper around yum. You select "Add/Remove Software" from the menu, tick the program you want, click on "Apply", and the package is installed.
PackageKit was developed to wrap the installer for any of the major distributions. The hope is that some time in the future it will become the standard way to install software, no matter whether you choose Knoppix, or SuSE, or Ubuntu or Fedora. On any distro, installing a program will be as simple as clicking on it.
Here's the problem. Fedora contains over 11,000 packages. I don't think any of the other major distributions have numbers a lot different. No matter how you organize it, finding the package you want amongst such a large collection can be a problem. On the other hand, when you select a package, PackageKit gives you a short description so you can get some confidence that it is the one you want. You can get that same description from yum, but it isn't nearly as convenient.
Summary
You can go back to the bad old days if you wish, and install software from a tarball. But be prepared for some pain. This may be necessary if a package is not available for your distribution of choice, but set aside plenty of time for the exercise.
Modern Linux distributions have very easy ways to install software. Personally, I prefer the command line; yum on Fedora, apt on Ubuntu. Simple, quick, painless. There are GUI applications available, and although easy to use, they can get a little tedious.