Software installation under Unix
This page covers software installation under the versions of Unix available in the Computer Lab - Ubuntu, Fedora, CentOS, and debian. They use a mixture of software packages called RPMs and .debs, referred to below as packages.
What is a package?
The software contained in a package may be a utility and all the extra files necessary to run that utility (libraries, configuration files etc), plus documentation. Often, however, a package will only contain one part of what you need, while other parts will be in other packages. For example, the utility xyz might make use of the shared library libwibble.so. The library libwibble.so might be used by a great many other utilities too, and if so it is likely to be in a package on its own rather than bundled into the same package as xyz. If this is the case, the xyz package is said to be dependent on the libwibble.so package, and you will need to install both (and possibly others as well, as the libwibble.so package itself may be dependent on other packages, and so on).
Package file names normally have the following format: packagename-version-release.type
For example, finger-0.17-220.127.116.11.i386.rpm, is an RPM containing the utility finger, version 0.17, release 18.104.22.168 of this RPM, intended to be installed on an i386 system (this last part is often missing if the RPM can be installed on many different systems), which is an RPM. Unfortunately package file names are not always consistent and alphanumeric characters, "." and "-" may be used in any part of a package name, so things are ambiguous - e.g. java-1.4.2-gcj-compat-22.214.171.124-40jpp.110.i386, the packagename is java-1.4.2-gcj-compat, version 126.96.36.199, release 40jpp.110, for an i386 architecture.
There are also packages which contain the files necessary to generate other packages — these are known as "Source packages". They will have an additional .src as part of their name.
Where can I find packages ? - "repositories"
A package repository is simply a collection of packages. Each distribution has its own standard repositories, and there are some well-known additional repositories (e.g. livna.org). The Lab also have several small local ones for home-grow packages (one for "all systems", one for each word length (i.e. 32-bit or 64-bit), and one for each distribution). The University Computing Service maintains a cache of the well-known package repositories.
Each machine holds a list of the repositories to be searched when a particular package is requested. There are various "higher level" tools which can be used to install packages, such as yum (for RPMs) and apt-get (for .debs), which will look through this list and which will then fetch the package from the appropriate repository. A few of the packages which users can install add extra repositories to the list which the commands search (they create a new file in /etc/yum.repos.d/ or /etc/apt/sources.list.d/), thereby allowing a user to "add" a repository to the set of those which are searched.
There can occasionally be problems using multiple repositories as they may contain incompatible packages. A well-known example is the mplayer utility. Both the freshrpms and livna repositories contain an "mplayer" package, but they are actually different packages, containing different things, and they have different dependencies. This means that in order to install a working version of mplayer, you need to specify that all of the packages it requires come from the same repository. (See Software installation using Yum for a fix for this specific problem.)
Non obvious package names
Many packages are named after the commands they provide. Unfortunately, some are less obvious, such as:
startkde / KDE: kdebase g++: gcc-c++ alisp / acl: CL-acl80.64 tethereal: wireshark