Installing Software on Linux
One of the most difficult things to get used to in the Linux world is installing new software packages. In the world of Windows, every program comes with a Setup.exe program that asks you some very easy questions and takes care of the job for you. While Linux software can be almost that easy to install, you will sometimes find software that seems to fight every step of the way. I can’t cover all the problems you might run into, but I’ll try to give you the basics and a few pointers to help get you over the rough spots.
Software tends to come in “packages”. In the Windows world a package is a Setup.exe or a program.zip file. On a Mac a package is a program.dmg or a program.sit file. In the Linux world, there are several kinds of packages, and each distribution has its own preferred package format.
The standard Linux package format (according to the Linux Standard Base) is RPM. RPM is a packaging system originally developed by Red Hat and widely used in the Linux community. Distributions using it include Fedora, Mandriva, Red Hat (naturally), and SUSE. An RPM package file normally will be named something like program-version-other.rpm
Another popular package format is DEB, the Debian software package. Debian packages and the Advanced Packaging Tool (APT) were the first to introduce several advanced features that are now common, such as automatic dependency resolution and signed packages. Debian packages are used by Debian GNU/Linux (naturally), and distributions based on it, including Ubuntu, Knoppix, and Mepis. A Debian package file normally will be named something like program-version-other.deb
Remember, you will need to become SuperUser to install software.
Debian, Ubuntu: APT
There is a broad array of tools for working with DEB packages, but the one you will commonly use is apt-get, arguably the easiest of Linux package management tools. apt-get is so easy because it not only keeps track of what packages are installed, but also what other packages are available. It will even download them from the Internet for you (if properly configured).
apt-get install ${packagename}
To remove software is just as easy.
apt-get remove ${packagename}
Although the repositories that contain installable packages might live on the Internet or on a disc somewhere, APT keeps a local database on your hard drive with a list of all available packages and where to find them. This database needs to be explicitly updated. To update the APT database:
apt-get update
A common idiom is to update your package database, and then upgrade all the packages that have patches or security updates to install. The following command will do this all at once.
apt-get update; apt-get upgrade
For a more indepth apt-get tutorial and other resources, see Managing Software with APT and dpkg.
Fedora, Red Hat: yum
yum does for RPM packages roughly what apt-get does for Debian packages. Like apt-get, yum can download and install packages from a configured repository.
yum install ${packagename}
To remove software is just as easy.
yum remove ${packagename}
yum does not keep a local copy of your package database by default, so normally there is no need to update it. To install all available security patches and bug fixes, use this command:
yum update
You can also explicitly update a single package with:
yum update ${packagename}
For a more indepth yum tutorial and other resources, see Managing Software with yum and rpm.
Mandriva: urpm
Mandriva Linux (formerly Mandrake and Connectiva) has a toolset similar to APT called urpmi. To install software:
urpmi ${packagename}
To remove software:
urpme ${packagename}
To update the local package database:
urpmi.update -a
To install security updates and bug fixes:
urpmi --auto-select
For a more indepth yum tutorial and other resources, see Managing Software with urpm.
Tar Balls
No, this is not a naughty term! A tar ball is a (usually compressed) archive of files, similar to a Zip file on Windows or a Sit on the Mac. Tar balls come in files that end in .tar, .tar.gz, .tgz, or something along these lines. To unpack a tar ball, use this command.
tar -xzvf ${filename}.tar.gz
The parameters are x to extract files, z to filter through gzip for decompression (leave this off if the file does not have a gz extension), v for verbose mode so you can tell what’s going on, f indicating there will be a filename to follow. You may want to create an alias called “untar” that feeds in these options if you have a hard time remembering command line options as I do.
This command will not install the software, it will only extract the archived files. It is your job then to find the README file or INSTALL file and read its instructions for installation. If the archive contains binaries there will usually be a setup script (often called install.sh) that you must execute as SuperUser.
Very often, software delivered in tar balls is not in executable form, but in source code, which must first be compiled before it can be installed.
--------------------------------------------------
Compiling Linux Software from Source Code
A computer program is a list of instructions given to a computer to make it perform a specific task or series of tasks. Computers do not understand English (we all wish that they did!), so programmers must communicate these instructions to the computer in a language the computer understands. Computers, however, can only operate on numbers, which makes a computer’s language very difficult for humans to understand.
The solution to this problem is to create an intermediate language that both humans and computers can understand. These are called programming languages. Programmers create a list of instructions for the computer in a programming language such as C, Pascal, or Fortran. This list of instructions is known as source code. It is textual in nature, and readable to humans (who speak the language). Programmers do all their work in this source code, changing the instructions to fix bugs, add features, or alter the appearance of a program.
When the programmer believes he has perfected the instructions for his program, he uses a special program called a compiler to translate his human readable text instructions into computer readable numbers that correspond to the same instructions. The resulting file is usable by computers but incomprehensible to humans. This is called object code. The resulting executable file is often called binary, after the number system used by the computer. This translation from source code into binary object code is a one-way process. It is impossible to translate a binary executable back into the original source code.
The binary executable is what you need if you want to run and use a program. This is commonly what you will receive when you purchase shrink-wrapped software from a retail store. The source code is what you need if you want to understand how a program works internally, or if you want to change, add to, or improve a program. If you have the source code and an appropriate compiler, you can produce the binary executable, but the reverse is not true.
If you’ve downloaded a source code archive, you’ll have to compile it before you can install it. In the top level directory of your extracted source, there is usually a README or INSTALL file that gives you instructions on how to compile and install the package. Some instructions are better than others, and rarely will they tell you everything you need to know. Hopefully this guide will help fill in some of the blanks.
A Quick Example
A typical incantation to install a source package looks something like this.
[root]# tar -xzvf ${name}.tar.gz
Unpacking ...
[root]# cd ${name}
[root]# more README
[root]# more INSTALL
[root]# ./configure
[root]# make
[root]# make install
Unpacking the Archive
[user]$ tar -xzvf ${filename}.tar.gz
[user]$ tar -xjvf ${filename}.tar.bz2
[user]$ tar -xvf ${filename}.tar
[user]$ unzip ${filename}.zip
[user]$ unzip ${filename}.exe
Depending on the type of archive you have received, the command for unpacking it may differ slightly. Shown above are some popular examples. tar is a Unix utility (Tape ARchiver) for working with bundled file archives. Typical command switches are x to extract files, v for verbose mode so you can tell what’s going on, f indicating there will be a filename to follow. If the file name ends in .tar that is all you need, but usually the tar file has been compressed with another utility. Files ending in .gz were compressed with gzip. For those, add the z flag to the list of parameters. Files ending with .bz2 were compressed with the bzip2 utility. For those, add the j flag, or failing that, --bzip2.
Occasionally you will run into an archive delivered in a .zip file. Use the unzip utility to unpack these. (Note that you may have to install the unzip package first.)
Some files you download may be built into self-extracting zip archives that end in .exe extension. Usually unzip can unpack those files as well, but be warned that anything packaged this way is almost certainly meant for a Windows machine and not your Linux box. Programs packaged this way probably will not run on Linux. But you might have an archive that contains only fonts or documentation, and those should be okay.
Configuring
The typical steps to configure and install software are these.
[root]# ./configure --help
[root]# ./configure
[root]# ./configure --prefix=/home/vince
Why do you type “dot slash configure” instead of just “configure”? Because the configure script is in the current directory, represented by the dot. By default, Linux does not search the current directory for executables; you must explicitly tell it where to look. (This is a security feature.) If you don’t type the dot slash, you’ll get an error like <samp>bash: configure: command not found</samp>, and may spend hours pulling your hair out trying to figure out why.
The primary job of the configure script is to detect information about your system and “configure” the source code to work with it. Usually it will do a fine job at this. The secondary job of the configure script is to allow you, the system administrator, to customize the software a bit. Running ./configure --help should give you a list of command line arguments you can pass to the configure script. Usually these extra arguments are for enabling or disabling optional features of the software, and it is often safe to ignore them and just type ./configure to take the default configuration.
There is one common argument to configure that you should be aware of. The --prefix argument defines where you want the software installed. In most source packages this will default to /usr/local/ and that is usually what you want. But sometimes you may not have root access to the system, and you would like to install the software into your home directory. You can do this with the last command in the example, ./configure --prefix=/home/${vince} (where ${vince} is your user name).
Compiling, Installing and Uninstalling
[root]# make
[root]# make install
[root]# make uninstall
The next step is to invoke the GNU Make utility to read the Makefile and compile the program for you. Unlike the Linux shell, make does look in the current directory for its Makefile, so you needn’t specify anything else. You should be aware that compiling software can take a long time. Compiling a simple program may take only a minute or two, but if you are planning to compile all of KDE from source, you may have to wait hours or even days depending on the speed of your computer. Also, it is not at all unusual to see hundreds of compiler warnings scroll by while software is compiling. If you are lucky, the software will compile anyway.
Assuming the compile phase completes without error, the next step is to actually install the software using make install. This invokes the make utility again, this time using it to copy the newly compiled files where they need to be in order to run your program. (See Where did the files go?) With some programs, you can remove the installed files using make uninstall as well, but this is not universal.
Most errors you will bump into while compiling have to do with missing libraries that the software depends on. Every case is unique, but watch for “not found” or “unable to locate” phrases. Typically you just need to install the “development” versions of the libraries it needs. These are usually available from your operating system vendor packages. Search for packages with names ending in “-devel”.
0 Comments
Post a Comment