12.2. General Upgrade Procedure
As discussed in the previous section, it's usually easier and best to upgrade only those applications you need to upgrade. For example, if you never use Emacs on your system, why bother keeping up-to-date with the most recent version of Emacs? For that matter, you may not need to stay completely current with oft-used applications. If something works for you, there's little need to upgrade.
Modern Linux systems provide various ways of upgrading software, some manual (which ultimately are the most flexible, but also the most difficult), others quite automated. In this section, we look at three different techniques: using the RPM package system, using the Debian package system, and doing things manually.
We'd like to stress here that using packages and package systems is convenient, and even if you are a power user, you might want to use these techniques because they save you time for other, more fun stuff. Here is a short summary of the advantages:
Of course, package systems also have a few disadvantages, some of which we discuss when we talk about RPM and the Debian package system. A generic problem is that once you start using a package system (which is a requirement if you use the distributions' automated installation interfaces) you ought to really install everything through packages. Otherwise, you can't keep track of the dependencies. For the same reason, mixing different package systems is a bad idea.
Every day some program you use is likely to be updatedall too often because of an important security flaw, unfortunately. Some grizzled system administrators insist on checking security reports regularly and upgrading every package manually, using the means shown in this section, so they can control every aspect of their systems and make sure no change breaks existing functionality. That's a noble cause to dedicate yourself to, and one that's feasible on systems with dedicated purposes (such as mail servers or routers) and a limited set of software.
For more general-purpose systems, though, keeping everything you use regularly up-to-date becomes a major part-time job. For this reason, all major distributions provide automated update services. We explore a few of them later in this chapter, but you'll want to understand general package management first. It shows what the update services are doing, and is important when you want to install new software or do something else that isn't offered by those services.
12.2.1. Using RPM
RPM, which originally expanded to Red Hat Package Manager but now just stands as a name on its own, is a tool that automates the installation of software binaries and remembers what files are needed so that you can be assured the software will run properly. Despite the name, RPM is not Red Hat-specific, but is used in many other distributions nowadays, including SUSE. Using RPM makes installing and uninstalling software a lot easier.
The basic idea of RPM is that you have a database of packages and the files that belong to a package. When you install a new package, the information about this package is recorded in the database. Then, when you want to uninstall the package for every file of the package, RPM checks whether other installed packages are using this file too. If this is the case, the file in question is not deleted.
In addition, RPM tracks dependencies. Each package can be dependent on one or more other packages. When you install a package, RPM checks whether the packages the new package is dependent on are already installed. If not, it informs you about the dependency and refuses to install the package.
The dependencies are also used for removing packages: when you want to uninstall a package that other packages are still dependent upon, RPM tells you about this, too, and refuses to execute the task.
The increased convenience of using RPM packages comes at a price, however: first, as a developer, it is significantly more difficult to make an RPM package than to simply pack everything in a tar archive. And second, it is not possible to retrieve just one file from an RPM package; you have to install everything or nothing.
If you already have an RPM system, installing RPM packages is very easy. Let's say that you have an RPM package called SuperFrob-4.i386.rpm (RPM packages always have the extension .rpm; the i386 indicates that this is a binary package compiled for Intel x86 machines). You could then install it with:
tigger # rpm -i SuperFrob-4.i386.rpm
Instead of -i, you can also use the long-named version of this option; choose whatever you like better:
tigger # rpm --install SuperFrob-4.i386.rpm
If everything goes well, there will be no output. If you want RPM to be more verbose, you can try:
tigger # rpm -ivh SuperFrob-4.i386.rpm
This prints the name of the package plus a number of hash marks so that you can see how the installation progresses.
If the package you want to install needs another package that is not yet installed, you will get something like the following:
tigger # rpm -i SuperFrob-4.i386.rpm failed dependencies: frobnik-2 is needed by SuperFrob-4
If you see this, you have to hunt for the package frobnik-2 and install this first. Of course, this package can itself be dependent on other packages.
If you want to update a package that is already installed, use the -U or --update option (which is just the -i option combined with a few more implied options):
tigger # rpm -U SuperFrob-5.i386.rpm
Uninstalling a package is done with the -e or --erase option. In this case, you do not specify the package file (you might not have that around any longer), but rather, the package name and version number:
tigger # rpm -e SuperFrob-5
Besides the options described so far that alter the state of your system, the -q option provides various kinds of information about everything that is recorded in the RPM database as well as package files. Here are some useful things you can do with -q:
What we've just finished showing are the basic modes of operation, which are supplemented by a large number of additional options. You can check those in the manual page for the rpm(8) command.
If you are faced with an RPM package that you want to install, but have a system such as Slackware or Debian that is not based on RPM, things get a little bit more difficult.
You can either use the fairly self-explanatory command alien that can convert between various package formats and comes with most distributions, or you can build the RPM database from scratch.
The first thing you have to do in this latter case is to get the rpm program itself. You can download it from http://www.rpm.org. Follow the installation instructions to build and install it; if you have the C compiler gcc installed on your system, there should be no problems with this. It should be mentioned that some newer versions of rpm have experienced stability problems, so if you do not use the rpm version that your distribution provides, you should be a bit careful and look out for unexpected results. Version 4.1.1 seems to be reasonably stable, though.
The next task is to initialize the RPM database. Distributions that come with RPM do the initialization automatically, but on other systems you will have to issue the following command:
tigger # rpm --initdb
This command creates several files in the directory /var/lib/rpm. The directory /var/lib should already exist; if it doesn't, create it with the mkdir command first.
Now you can install RPM packages the normal way, but because you have not installed the basic parts of the system, such as the C library with RPM, you will get errors like the following:
tigger # rpm -i SuperFrob-4.i386.rpm failed dependencies: libm.so.5 is needed by SuperFrob-4 libdl.so.1 is needed by SuperFrob-4 libc.so.5 is needed by SuperFrob-4
because those files are not recorded in the RPM database. Of course, you really do have those files on your system; otherwise most programs wouldn't run. For RPM to work, you must tell it not to care about any dependencies. You do this by specifying the command-line option --nodeps:
tigger # rpm -i --nodeps SuperFrob-4.i386.rpm
Now, RPM will install the package without complaining. Of course, it will run only if the libraries it needs are installed. The mere fact that you use --nodeps doesn't save you when the "dependent" library or software is not installed on your system.
With this information, you should be able to administer your RPM-based system. If you want to know more, read the manual page for the rpm command, or check out http://www.rpm.org.
Some commercial companies sell automated upgrade services based on RPM. As a subscriber to these services, you can have your system upgraded automatically; the service finds out which new packages are available and installs them for you. If you use the SUSE distribution, SUSE provides such a service (called "YOU") for free. Even the Debian distribution (whose package system is described in the next section) has an automated upgrade system (described there). However, some security experts consider these automated upgrades a security risk.
12.2.2. Using dpkg and apt
After rpm, the most popular package manager for Linux distributions is dpkg, which is used to manage .deb archives. As the name implies, the .deb format is tied to the Debian distribution, so it is also used by distributions based on Debian, such as Ubuntu and Kubuntu, Libranet, and Xandros. Like the RPM format, the .deb format keeps track of dependencies and files to help ensure your system is consistent.
The technical differences between the two formats are actually fairly small; although the RPM and .deb formats are incompatible (for example, you can't install a Debian package directly on Red Hat), you can use alien to translate .deb packages for other distributions (and vice versa). The main difference between the formats is that .deb packages are built using tools that help make sure they have a consistent layout and generally conform to policies (most notably, the Debian Policy Manual, provided in the debian-policy package) that help developers create high-quality packages.
While dpkg is the low-level interface to the Debian package manager, most functions are usually handled through either the apt suite of programs or frontends such as dselect, aptitude, gnome-apt, synaptic, or KPackage.
Installing .deb packages on a Debian system is quite easy. For example, if you have a package named superfrob_4-1_i386.deb, you can install it with:
tigger # dpkg -i superfrob_4-1_i386.deb Selecting previously deselected package superfrob. (Reading database ... 159540 files and directories currently installed.) Unpacking superfrob (from superfrob_4-1_i386.deb) ... Setting up superfrob (4-1) ...
If the superfrob package is missing a dependency, dpkg will issue a warning message:
tigger # dpkg -i superfrob_4-1_i386.deb Selecting previously deselected package superfrob. (Reading database ... 159540 files and directories currently installed.) Unpacking superfrob (from superfrob_4-1_i386.deb) ... dpkg: dependency problems prevent configuration of superfrob: superfrob depends on frobnik (>> 2); however: Package frobnik is not installed. dpkg: error processing superfrob (--install): dependency problems - leaving unconfigured Errors were encountered while processing: superfrob
The output indicates that you would need frobnik Version 2 or later for the package to install completely. (The files in the package are installed, but they may not work until frobnik is installed too.)
Unlike RPM, dpkg doesn't make a distinction between installing a new package and upgrading an existing one; the -i (or --install) option is used in both cases. For example, if we want to upgrade superfrob using a newly downloaded package superfrob_5-1_i386.deb, we'd simply type:
tigger # dpkg -i superfrob_5-1_i386.deb (Reading database ... 159546 files and directories currently installed.) Preparing to replace superfrob 4-1 (using superfrob_5-1_i386.deb) ... Unpacking replacement superfrob ... Setting up superfrob (5-1) ...
To uninstall a package, you can use either the -r (--remove) or -P (--purge) options. The --remove option will remove most of the package, but will retain any configuration files, while --purge will remove the system-wide configuration files as well. For example, to completely remove superfrob:
tigger # dpkg -P superfrob (Reading database ... 159547 files and directories currently installed.) Removing superfrob ...
dpkg can also be used to find out what packages are installed on a system, using the -l (--list) option:
tigger $ dpkg -l Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed |/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad) ||/ Name Version Description +++-= == == == == == == =-= == == == == == == =-= == == == == == == == == == == == == == == == == == == == == == = ii a2ps 4.13b-15 GNU a2ps 'Anything to PostScript' converter ii aalib1 1.4p5-10 ascii art library ii abcde 2.0.3-1 A Better CD Encoder ... ii zlib1g-dev 1.1.3-19 compression library - development
The first three lines of the output are designed to tell you what the first three columns before each package's name mean. Most of the time, they should read ii, which means the package is correctly installed. If they don't, you should type dpkg --audit for an explanation of what is wrong with your system and how to fix it.
You can also use the -l option with a package name or glob-style pattern; for example, you could find out what version of superfrob is installed using the following:
tigger $ dpkg -l superfrob Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed |/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad) ||/ Name Version Description +++-= == == == == == == =-= == == == == == == =-= == == == == == == == == == == == == == == == == == == == == == = ii superfrob 4-1 The superfrobulator
dpkg can also be used to find out the package to which a particular file belongs:
tigger $ dpkg --search /bin/false shellutils: /bin/false tigger $ dpkg --search /home/kalle/.xinitrc dpkg: /home/kalle/.xinitrc not found.
You can also display information about an installed package or .deb archive:
tigger $ dpkg --status dpkg Package: dpkg Essential: yes Status: install ok installed Priority: required Section: base Installed-Size: 3156 Origin: debian Maintainer: Dpkg Development <firstname.lastname@example.org> Bugs: debbugs://bugs.debian.org Version: 1.9.19 Replaces: dpkg-doc-ja Pre-Depends: libc6 (>= 2.2.4-4), libncurses5 (>= 5.2.20020112a-1), libstdc++2.10- glibc2.2 (>= 1:2.95.4-0.010810) Conflicts: sysvinit (<< 2.80) Conffiles: /etc/alternatives/README 69c4ba7f08363e998e0f2e244a04f881 /etc/dpkg/dpkg.cfg 1db461ac9a1d4f4c8b47f5061078f5ee /etc/dpkg/dselect.cfg 190f7cf843556324495ef12759b752e3 /etc/dpkg/origins/debian 24926c0576edec3e316fd9f6072b8118 Description: Package maintenance system for Debian This package contains the programs which handle the installation and removal of packages on your system. . The primary interface for the dpkg suite is the 'dselect' program; a more low-level and less user-friendly interface is available in the form of the 'dpkg' command. . In order to unpack and build Debian source packages you will need to install the developers' package 'dpkg-dev' as well as this one. tigger $ dpkg --info reportbug_1.43_all.deb new debian package, version 2.0. size 66008 bytes: control archive= 1893 bytes. 40 bytes, 2 lines conffiles 1000 bytes, 24 lines control 986 bytes, 15 lines md5sums 1014 bytes, 41 lines * postinst #!/bin/sh 147 bytes, 5 lines * postrm #!/bin/sh 416 bytes, 19 lines * prerm #!/bin/sh Package: reportbug Version: 1.43 Section: utils Priority: standard Architecture: all Depends: python Recommends: python-newt Suggests: postfix | mail-transport-agent, gnupg | pgp, python-ldap (>= 1.8-1) Conflicts: python (>> 2.3), python-newt (= 0.50.17-7.1) Installed-Size: 195 Maintainer: Chris Lawrence <email@example.com> Description: Reports bugs in the Debian distribution. reportbug is a tool designed to make the reporting of bugs in Debian and derived distributions relatively painless. Its features include: . * Integration with the mutt, af, and mh/nmh mail readers. * Access to outstanding bug reports to make it easier to identify whether problems have already been reported. * Support for following-up on outstanding reports. * Optional PGP/GnuPG integration. . reportbug is designed to be used on systems with an installed mail transport agent, like exim or sendmail; however, you can edit the configuration file and send reports using any available mail server.
dpkg can also list the files and directories included in a .deb archive:
tigger $ dpkg --contents superfrob_4-1_i386.deb -rwxr-xr-x root/root 44951 2002-02-10 12:16:48 ./usr/bin/dothefrob -rwxr-xr-x root/root 10262 2002-02-10 12:16:48 ./usr/bin/frobhelper ...
dpkg, like rpm, has numerous other options; for more details, refer to the manual pages for dpkg and dpkg-deb.
In addition to dpkg, Debian and other Debian-based distributions provide the apt suite of programs.[*] apt stands for "advanced package tool," and is designed as an archive-independent system that can handle multiple package formats. Perhaps the most important feature of apt is its ability to resolve dependencies automatically; if, for example, superfrob requires Version 2 or later of frobnik, apt will try to find frobnik from the sources that are available to it (including CD-ROMs, local mirrors, and the Internet).
The most useful interface to apt is the apt-get command. apt-get manages the list of available packages (the "package cache") and can be used to resolve dependencies and install packages. A typical session would start with an update of the apt cache:
tigger # apt-get update Get:1 http://http.us.debian.org stable/main Packages [808kB] Get:2 http://http.us.debian.org stable/main Release [88B] Hit http://non-us.debian.org stable/non-US/main Packages Hit http://non-us.debian.org stable/non-US/main Release Get:3 http://security.debian.org stable/updates/main Packages [62.1kB] Get:4 http://security.debian.org stable/updates/main Release [93B] Fetched 870kB in 23s (37kB/s) Reading Package Lists... Done Building Dependency Tree... Done
The output indicates that there have been updates to the stable distribution, so we may want to upgrade the packages already installed on the system. To do this automatically, we can use apt-get's upgrade option:
tigger # apt-get upgrade The following packages have been kept back: gnumeric 17 packages upgraded, 0 newly installed, 0 to remove and 1 not upgraded. Need to get 16.3MB of archives. After unpacking 5kB will be freed. Do you want to continue? [Y/n] y Get:1 http://http.us.debian.org stable/main base-passwd 3.4.6 [17.2kB] Get:2 http://security.debian.org stable/updates/main ssh 1:3.1.6p4-1 [600kB] ... (Reading database ... 159546 files and directories currently installed.) Preparing to replace ssh 1:3.0.3p2-6 (using .../ssh_1%3a3.1.6p4-1_i386.deb) ... Unpacking replacement ssh ... ...
One thing you will notice is that unlike most Linux commands, the actions taken by apt commands are specified without dashes. apt-get does allow some options, but they are used only to change the behavior of the main action specified.