Section 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:

• You have everything that belongs to a software package in one downloadable file.

• You can remove a software package entirely, without endangering other packages.

• Package systems keep a dependency database and can thus automatically track dependencies. For example, they can tell you if you need to install a newer version of a library in order to run a certain application you are about to install (and will refuse to remove a library package as long as packages are installed that use the libraries this package provides).

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:

• Find out the version number of an installed package:

      tigger# rpm -q SuperFrob
      SuperFrob-5

  
  

• Get a list of all installed packages:

      tigger# rpm -qa
      SuperFrob-5
      OmniFrob-3
      ...
      glibc-2.3.4-23.4

  
  

• Find out to which package a file belongs:

      tigger# rpm -qf /usr/bin/dothefrob
      SuperFrob-5
      tigger# rpm -qf /home/kalle/.xinitrc
      file /home/kalle/.xinitrc is not owned by any package

  
  

• Display information about the specified package:

      tigger# rpm -qi rpm
      Name        : rpm                          Relocations: (not relocatable)
      Version     : 4.1.1                             Vendor: SUSE LINUX Products GmbH,
      Nuernberg, Germany
      Release     : 208.2                         Build Date: Sat 11 Jun 2005 01:53:04
      AM CEST
      Install date: Tue 28 Jun 2005 10:02:18 AM CEST      Build Host: purcell.suse.de
      Group       : System/Packages               Source RPM: rpm-4.1.1-208.2.src.rpm
      Size        : 5970541                          License: GPL
      Signature   : DSA/SHA1, Sat 11 Jun 2005 01:58:41 AM CEST, Key ID a84edae89c800aca
      Packager    : http://www.suse.de/feedback
      Summary     : The RPM Package Manager
      Description :
      RPM Package Manager is the main tool for managing the software packages
      of the SuSE Linux distribution.
      ...
      Distribution: SuSE Linux 9.3 (i586)

  
  

• Show the files that will be installed for the specified package file:

      tigger# rpm -qpl SuperFrob-5.i386.rpm
      /usr/bin/dothefrob
      /usr/bin/frobhelper
      /usr/doc/SuperFrob/Installation
      /usr/doc/SuperFrob/README
      /usr/man/man1/dothefrob.1

  
  

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 <debian-dpkg@lists.debian.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 <lawrencc@debian.org>
     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).

^[*] Some RPM-based distributions now include apt as well because apt was designed to work with any packaging format.

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.^[]

^[] Some other Linux commands, such as cvs, also act this way.

Note that gnumeric was not automatically upgraded, probably because it would have required additional packages to be installed. To upgrade it and resolve dependencies, we can use apt-get's install option, with the names of one or more packages: ^[*]

^[*] Note that apt-get does not install packages directly from .deb archives; dpkg's --install option should be used instead for an archive that you have in a .deb archive on disk or have downloaded directly from the Internet. When using dpkg, you will need to resolve the dependencies yourself.

    tigger # apt-get install gnumeric 
    The following extra packages will be installed:
      libgal36 libglade3
    The following NEW packages will be installed:
      libgal36
    2 packages upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
    Need to get 8.3MB of archives.  After unpacking 503kB will be used.
    Do you want to continue? [Y/n] y 
    ...

Another useful feature of apt is its ability to find information about packages in the repository. The apt-cache command is used to look up information about packages that are available for installation. One common use of apt-cache is to find packages based on keywords in the package's description, by using words, complete phrases (in quotes), or regular expressions. For example, if you want to find a package that allows you to play Ogg Vorbis-encoded music files, you can use the search option to find appropriate packages:

    tigger $ apt-cache search "ogg vorbis" 
    audacity - A fast, cross-platform audio editor
    bitcollider-plugins - bitcollider plugins
    cplay - A front-end for various audio players
    gqmpeg - a GTK+ front end to mpg321/mpg123 and ogg123
    libapache-mod-mp3 - turns Apache into a streaming audio server
    libvorbis0 - The Vorbis General Audio Compression Codec
    mp3blaster - Full-screen console mp3 and ogg vorbis player
    mp3burn - burn audio CDs directly from MP3s or Ogg Vorbis files
    oggtst - Read comments in ogg vorbis files
    python-pyvorbis - A Python interface to the Ogg Vorbis library
    vorbis-tools - Several Ogg Vorbis Tools
    xmms - Versatile X audio player that looks like Winamp
    xmms-dev - XMMS development static library and header files
    mq3 - a mp3/ogg audio player written in Qt.

Now, if we are interested in one of these packages, we can find out more about it using the show option of apt-cache:

    tigger $ apt-cache show xmms 
    Package: xmms
    Priority: optional
    Section: sound
    Installed-Size: 4035
    Maintainer: Josip Rodin <jrodin@jagor.srce.hr>
    ...
    Description: Versatile X audio player that looks like Winamp
     XMMS (formerly known as X11Amp) is an X/GTK+ based audio player
     for various audio formats.
     .
     It's able to read and play:
      * Audio MPEG layer 1, 2, and 3 (with mpg123 plug-in),
      * WAV, RAW, AU (with internal wav plug-in and MikMod plug-in),
      * MOD, XM, S3M, and other module formats (with MikMod plug-in),
      * CD Audio (with CDAudio plug-in), with CDDB support,
      * .cin files, id Software,
      * Ogg Vorbis files.
     It has eSound, OSS, and disk writer support for outputting sound.
     .
     It looks almost the same as famous Winamp, and includes those neat
     features like general purpose, visualization and effect plug-ins,
     several of which come bundled, then spectrum analyzer, oscilloscope,
     skins support, and of course, a playlist window.

Although a full exploration of apt's features is beyond the scope of this chapter, the apt manual page (and the manual pages it references) along with the APT HOWTO (available in the apt-howto-en package) should answer any questions you may have.

In addition to the command-line tools, a number of easy-to-use text-based and graphical frontends have been developed. One of the most mature frontends is KPackage , which is part of the KDE Desktop Environment, but can be used with other desktops, such as GNOME. KPackage can be run from the command line or found in the System menu of KDE. Figure 12-1 shows a sample screen from KPackage.

The main window of KPackage displays a list of all the packages available for your system on the left, with a box to the right; when you choose a package in the list, the box to the right includes information about the package you selected. You can install or uninstall packages by selecting them and choosing Install or Uninstall from the Packages menu, or by clicking the column labeled Mark to place a check mark next to them and then clicking the "Install marked" or "Uninstall marked" buttons. You can also install .deb packages directly by clicking the Open button on the toolbar to the left of the screen and selecting the file, or dragging .deb icons from KDE file manager windows into KPackage's window. KPackage also has tools for finding packages with particular names. Like all KDE applications, KPackage has help available by pressing F1 or using the Help menu.