Linux Kernel

The following sections discuss the Debian packaging programs in detail. For illustrative purposes, the Debian programs are compared with their equivalents from Red Hat Linux and Slackware Linux. This is purely for comparison, and is not intended to be a judgment as to which system is best. Debian's system is quite sophisticated, feature-rich, and correspondingly complex, so it helps to have a common terminology for the discussion.

Using the dpkg Program

The dpkg program is the where the rubber meets the road for Debian's packaging system. This program is responsible for physically unpacking and installing Debian package archive (.deb extension) files, and for managing the various databases related to package management.

You can use dpkg to install individual packages manually. For example, you may download a .deb file from a web site and install it with dpkg, or you may install a package off of a CD. Similarly, you can use dpkg to remove specific individual packages. You can also perform common query commands with dpkg, such as listing the files installed by a particular package or locating the package that owns a particular file.

You may have realized at this point that the dpkg program is essentially equivalent to the rpm program, in that you can install and remove packages and perform various queries on packages (both installed and uninstalled ). Slackware Linux spreads the same functionality across multiple programs (namely installpkg, upgradepkg, and removepkg).

In Chapter 5, you read that Slackware Linux uses simple text files in the /var/log/packages directory to store information about which packages own which files. In Chapter 4, on the other hand, you learned that Red Hat Linux goes to the other extreme and stores all this information in a binary database that you can't really get access to except through the rpm command. Debian's dpkg falls somewhere in between: The actual lists of files installed by packages are stored in a database, but information on the packages is stored in the file /var/lib/dpkg/available, and information on installed packages is located in the directory /var/lib/dpkg/ info . To some extent, you can consult these files for information without having to go through the dpkg tool (though you may find the dpkg tool to be more convenient ).

One major difference between dpkg and rpm is that dpkg maintains an actual list of available packages that aren't yet installed—that is, the /var/lib/dpkg/available file. (Actually, Red Hat does provide a package known as rpmdb that includes some of these capabilities, but it is rather arcane to use, and isn't nearly as accessible.) This list is typically constructed from the contents of a CD or other media, and is consulted for various queries requested by the user. (For example, the user might ask for documentary information on a package that hasn't been installed yet.) This is convenient because it means that you don't necessarily have to have the .deb package itself lying around in order to fetch information about it; with rpm you have to have the actual package present in order to query it with the rpm -qp commands. You'll be hearing much more about this list of available packages as you read further, so keep it in mind.

Another difference between Debian's system and Red Hat's RPM is in their handling of dependencies. You read in Chapter 4 that RPM can track dependency information—that is, which other packages a particular package depends on. For example, the OpenSSH package depends on the OpenSSL package. With RPM, a dependency is a "yes or no" proposition. The dpkg tool, however, supports several types of dependencies, such as "required", "recommend", and "suggested". This added flexibility can make it easier to communicate dependency information to end users. When you install a Debian package, be sure to check its dependencies carefully , since there may be recommended or suggested features you might otherwise miss .

Using the apt-get Program

The apt-get program builds on dpkg and manages package sources, providing most of the network transparency mentioned earlier. You can think of this program as keeping dpkg well fed. All those packages that dpkg installs have to come from somewhere, after all, and apt-get is that place. The other major responsibility of apt-get is to keep track of dependencies between packages (such as which packages are required by another).

Managing the Source Media

Typically, users install Debian from installation CDs or from an installation repository (such as an FTP site) on a network. These installation media really just consist of a collection of Debian packages; apt-get monitors these media and keeps track of the list of packages that is available from each source. When the user wishes to install a new package, she simply instructs apt-get to locate the package and hand it off to dpkg for installation. Locating the package might mean going back to that FTP site, or prompting the user to insert one of the installation CDs, or even something else.

This ability to keep track of available packages is a major convenience. Systems like RPM are really fairly myopic: rpm can't see any files that aren't sitting directly in front of it. Debian's apt-get, in contrast, has a much better view of the "terrain" of available packages, and can go fetch packages without the user having to bother with hunting it down. Red Hat does have a similar system known as up2date, but up2date typically only has knowledge of the package repository maintained by Red Hat, Inc., which it sells access to as a profit-making service. Debian's apt-get has a much more flexible package source list. You might think of up2date as a cousin of apt-get that can only handle one package source.

The list of source media that apt-get uses is itself maintained by several helper programs. The file that stores the source list is /etc/apt/sources.list; this file can contain a variety of sources, such as CDs, FTP or HTTP (web) sites, and so on. The contents of this file can be conveniently managed by the helper programs, such as apt- cdrom , which scans Debian package CDs and creates appropriate entries in /etc/apt/sources.list.

Debian GNU/Linux contains the apt-get tool that, among other things, provides network-transparent access to software packages. Various other packaging systems include similar functionality, and there's a lot of work ongoing to "cross-pollinate" such tools. For example, there's at least one open-source implementation of Red Hat's server for its up2date program that would allow the use of up2date with providers other than Red Hat. Meanwhile, efforts are under way to configure apt-get for use with the RPM system so that users of Red Hat Linux systems can use apt-get to fetch and manage RPM packages the same way Debian users manage .deb packages. A number of other interesting efforts are also in the works, so the book is by no means closed on the future of package management.

Working with apt-get

When managing packages on a Debian system, many users work with apt-get most of the time. It's best suited for quickly and easily adding those packages that you forgot to include when you installed the system, or for upgrading current packages to a newer version when fixes or enhancements are released. However, apt-get is actually sophisticated enough that it can handle upgrading the entire distribution to a new version. These features of apt-get are discussed in more detail later.

Using the dselect Program

The dselect program is a menu-based interface for selecting packages to install. This is actually the same program that is invoked during the Debian installation process that allows users to tweak the list of packages to suit their needs. The program is also available to be run at any time after the installation to adjust the selected list.

This program is really just a view into the list of available packages maintained by apt-get and dpkg. That is, apt-get maintains a list of package sources, and dpkg maintains a list of available packages (which is compiled from the contents of the sources). The dselect program simply displays a list of all available packages, indicating which ones are already installed and allowing the user to flag available packages to be installed, or flag installed packages to be deleted. The menu of available packages also includes information on dependencies that each package has, and helps the user select packages to resolve any dependencies.

When the user makes his selections and exits dselect, apt-get (and in turn , dpkg) is then run to physically install and remove packages according to the user's selections. Red Hat Linux and Slackware Linux really have no tools equivalent to dselect.

Using the tasksel Program

The tasksel program is similar to dselect, but rather than allowing the user to select packages to install, it lets her select tasks. A task, in Debian's nomenclature , is essentially a collection of packages. For example, the XFree86 implementation of the X Window System actually consists of a number of different packages, including the core software, drivers for various video card models, and fonts (among other things). Debian has a notion of a task to permit the distribution designers to group collections of packages such as XFree86 into a single "virtual" package. When a user selects a task, he is actually selecting a set of multiple Debian .deb packages.

The tasksel program is pretty straightforward, and itself uses apt-get and in turn dpkg to handle the installation of the packages that make up tasks. As with dselect, Red Hat Linux and Slackware Linux don't really provide any similar functionality. (Red Hat Linux does allow users to select groups of software packages similar to Debian tasks during the installation process, but these collections are not accessible once installation has been completed.)

Getting Into the Details

The past few sections gave an overview of the capabilities provided by the various programs that make up the Debian package system. The next few sections go into a bit more detail and demonstrate some of the more common uses of the Debian packaging system. Each program, though, is pretty complicated, so for full details you should definitely check out the manual pages and other documentation on these tools provided with Debian GNU/Linux.

The following sections focus on illustrating the most common ways in which you'll use Debian's packaging system as a whole, rather than on the mechanics of the individual programs. By now, you probably have a pretty good grasp of exactly what tools like dpkg and rpm are doing (unpacking a bunch of files, recording where they went into a database so they can be removed later, and perhaps running a script). Rather than rehashing the same material you could get from reading a manual page, I'll focus on the distribution, not just the tools.

Managing Packages with Debian's System

Even though you can read the manual pages to figure out how to use them, the Debian packaging tools provide more power and flexibility than may be immediately obvious from the manual pages. Each of the next few sections focuses on a specific common task and outlines the general procedure for that task, in order to help you make the jump from knowing how to run the programs to knowing when to run them. It's important to bear in mind that with Debian's packaging system, there's more than one way to do almost anything, so much of this material boils down to a matter of preference.

It's generally possible to manage Debian packages on two levels: at the dpkg level, and at the apt-get and dselect level. This section will discuss each case, briefly demonstrating the mechanics of package management, and indicating when and why you'd want to use each level.

Working with dpkg

Debian's dpkg tool is the lowest-level tool in the packaging system. It operates at the individual package level, and can perform the typical packaging commands such as install, remove, and various queries. Table 6-2 summarizes some of the most common operations provided by dpkg; for full details, you should consult the manual page for dpkg, or other documentation.

As you can see, using dpkg to manage individual packages is quite straight-forward. If you've read Chapters 4 and 5, it's probably even familiar by now, since it's so similar to the equivalent mechanisms on Red Hat Linux and Slackware Linux. On Debian systems, you'll probably only use dpkg directly to install single packages that you obtain from somewhere other than the original installation or upgrade media, such as a specific piece of software you download from a web site. Most of the time, you'll probably use dselect or apt-get, which are discussed later in this section.

The term "globbing" refers to the expansion of wildcards like the "star" (*) character (or asterisk) to match specific patterns. Debian's dpkg program, like most of the packaging tools, supports globbing in the arguments you pass to it. For example, to list all installed packages with "libc" in the name, you can use this command:

$ dpkg -l "*libc*"

The asterisks will be "globbed" similar to the way filenames would be in a shell, and you'll get quite a list of packages with "libc" in their names . This is quite a convenient trick, so be sure to use it!

Managing Package Sources with apt-get

The only problem with using dpkg (or rpm for that matter) to manage the packages on your Debian system is that it's very laborious. After all, if you want to install a particular package, you first must find the package! This may involve inserting and mounting a CD—perhaps several times, if the package is not on the first disk you check—or downloading a file from a web or FTP site. Even if all you're doing is installing a package that you forgot to select during installation, you still have to shuffle CDs or URLs to locate it. Additionally, you also have to contend with any dependencies that the desired package might have.

For these cases, Debian GNU/Linux includes apt-get, which manages installation media for you. Since apt-get maintains a list of source media containing packages, and a list of the actual packages that are available, all you need to do is request that apt-get locate and install the desired package for you. Table 6-3 summarizes the common uses of apt-get. Again, you should consult the manual page for specific information.

The first two capabilities of apt-get—installing and removing packages—is pretty straightforward. Just type apt-get install foo and apt-get will check its list of sources and available packages in quest of a Debian archive named "foo". If it finds one, it will install the archive, resolving any dependencies along the way. Conversely, apt-get remove foo will uninstall the package. The remaining capabilities aren't quite so clear-cut , however.

Upgrading Installed Packages

One notable property of apt-get shown in Table 6-3 is that the upgrade function is not used on specific packages. Instead, it's a global command that upgrades all packages for which upgrades are available. This might seem like an odd restriction at first, since it makes upgrading to individual packages difficult. However, if you think about it, once you have a system that automatically updates itself you seldom need to worry about individual packages, so this turns out to be a nonissue in practice.

Refreshing the List of Available Packages

Another entry in Table 6-3 that may not be immediately obvious is the update command. This command differs from the upgrade command just described. The update command refreshes the list of available packages , but doesn't actually upgrade any packages. Typically, you'll run apt-get update after updating the /etc/apt/sources.list file, or when an FTP or web site updates its list of available packages. Once apt-get is aware that upgrades to installed packages actually exist, the upgrade command can be used to do the work.

Comparing apt-get to up2date

If you've read Chapter 4, you'll probably notice similarities between apt-get and Red Hat's up2date system. In fact, they are quite similar, but apt-get is rather more flexible, simply because up2date is currently only practical to use with Red Hat's own site, whereas apt-get lets you use any number of sources. (Ongoing work may always change this in the future, of course.)

In the end, apt-get is really just a convenience. However, it's a big convenience; after you spend a while maintaining the packages on a few Linux systems by hand, you'll be quite grateful for any conveniences you can get. Once you get used to apt-get, you probably won't care to use dpkg directly anymore. You'll quickly grow accustomed to running commands like apt-get install package and letting the system locate the package, download it or prompt you to insert the appropriate CD, and manage any dependencies for you.

Managing Packages with dselect and tasksel

Occasionally, you might need to install a number of packages at once, or you aren't quite sure of what the specific name of a package is. Sometimes you don't even know whether software even exists to fill a particular need, let alone what its name is. The dselect and tasksel tools address this issue.

Using dselect

The dselect program is first encountered early on in the life of a Debian GNU/Linux system, since it's the tool used to select individual packages during the installation. The dselect program is really just a menu-based front end that pulls together all the functionality discussed so far in this chapter.

Administrators can use dselect to browse the list of all available packages, and see instantly which are installed and which are not. By changing the list of selections, many packages can be installed or removed in one fell swoop. For such cases, working with dselect may be more convenient than using apt-get to manage each package individually.

Using tasksel

The tasksel program provides the coarsest level of granularity. A task is just a list of packages (or other tasks). For example, the XFree86 task includes a number of individual packages, such as the libraries, video card drivers, and fonts. The tasksel program can be used to install additional tasks after the installation is completed.

For example, a system may have originally been configured as some sort of server, and so XFree86 was not installed at all. If that system is then repurposed to be a desktop system, the XFree86 packages will have to be installed. This can, of course, be done manually with apt-get, but a lot of packages are involved. It might therefore be easier to use dselect to select all the XFree86 packages for installation, but even then you have to hunt them all down in the list. With tasksel, however, the entire suite of XFree86 packages—that is, the XFree86 task—can be installed quickly and easily.

Configuring Debian Packages

Packaging systems are very good at installing files, and upgrading and uninstalling them as necessary. Most are also capable of managing configuration files, though the degree of support varies. Red Hat's RPM system, for example, allows package creators to designate some files as configuration files. When later managing these files, RPM is careful to preserve them and never overwrite an administrator's custom files. Debian's system, however, includes more extensive configuration support.

Debian comes with the debconf package. This package is a set of libraries and utilities that implements a protocol that package designers can use to handle configuration of their packages. A protocol is a standardized contract controlling communication between programs; the debconf protocol essentially allows package creators to ask questions from the users in a standardized way. The debconf utilities and user interface front ends then gather the required information on behalf of the package, and pass the information to the installation scripts included with the package. The scripts can then do whatever is necessary, such as generating configuration files.

An example of a package that uses debconf is the x window-system package (which installs XFree86.) XFree86 requires a fairly large amount of information to configure the X server to work with the user's hardware. Red Hat wrote a program called Xconfigurator for its distribution, but Debian uses the debconf tools. The similarities between the two are fairly significant, at least inasmuch as both use a text menu–based user interface; they also ask similar questions and generate similar files (which makes sense, since they're different tools for configuring the same package).

Using debconf to Reconfigure Packages

Users and administrators frequently need to reconfigure packages after installation has finished. For example, a workstation may be upgraded with a new video card, requiring a reconfiguration of XFree86. To support this, debconf provides two tools: dpkg-preconfigure and dpkg-reconfigure. There is also a third tool, debconf-show, that displays the current configuration information for a package.

The two configuration commands—dpkg-preconfigure and dpkg-reconfigure—are fairly similar. Essentially, dpkg-preconfigure is used to gather information on a package before it is installed, and is most useful during the installation process; in fact, most users will seldom invoke it directly. The dpkg-reconfigure program, however, does basically the same tasks but can reconfigure already installed programs. For example, the command dpkg-reconfigure xserver-common can be used to reconfigure that workstation after the video card upgrade. Similarly, debconf-show xserver-common will display the configuration variables used by XFree86 and their current values.

Configuring debconf

The debconf program itself has a few configuration items. The primary components are the /etc/apt/apt.conf.d directory and the /etc/debconf.conf file. Each is described in the text that follows ; however, most users will not have to deal with these very often, if at all. You should simply be aware of their existence, should you someday need them.

The /etc/apt/apt.conf.d directory is used by the apt packaging system (which includes apt-get, dpkg, and so on) as a hook for running programs when the apt tools are invoked. This directory contains files whose contents are used by the packaging tools during their operation.

The /etc/debconf.conf file configures the debconf system itself. This file really just specifies paths to database files that are used to store configuration information. The debconf system "remembers" previously entered answers to questions asked by packages via debconf by storing them in a database independent of the packages' contents. If a package is removed and then reinstalled (or simply upgraded), debconf fetches the configuration data from its database and uses those values to rerun the configuration scripts. To override this behavior, use the dpkg-reconfigure program.

Upgrading the System

So far I've covered a number of tools that provide a variety of ways to work with the Debian package management system. As you've probably noticed, generally this is similar to other systems, though Debian's may be a richer, more sophisticated system. However, there's one aspect I haven't touched on yet, and that is Debian's ability to be upgraded easily via the package management system.

For most distributions, an upgrade is a pretty intensive process. You typically have to boot from a floppy disk or CD that runs a special-purpose program that upgrades your system from the installation media. Debian systems, however, handle this rather differently.

The key is the list of available packages. Most of the time, you'll configure your system to use a set of sources that is largely static, but occasionally contains bug fixes, security fixes, and so on. On these occasions, you'll typically upgrade your installation with the new packages by a process similar to this:

1. If necessary, update the /etc/apt/sources.list file to reflect any new media. For example, you might have obtained a CD that contains updated packages and need to add the new CD through the apt-cdrom command.

2. Run apt-get update to cause apt-get to become aware of any updated packages.

3. Run apt-get upgrade to cause apt-get to fetch and install any updated packages that have been made available.

This procedure works well when all you need to do is upgrade a few packages. However, eventually you'll probably want to upgrade a Debian system to a new major release. This case, when you think about it, really isn't that different from the previous case; you just need to replace the currently installed packages with newer versions. The difference is just the scope of the upgrade: In a major version upgrade, a lot (perhaps all!) of the packages change simultaneously , most likely with significant changes made to the contents of each package.

Managing a full-blown upgrade like that isn't easy, so most distributions just produce new CDs, and you reboot the system to perform the upgrade. With Debian, however, you can use a procedure like this one:

1. Update /etc/apt/sources.list, removing all references to the current distribution's media, and adding the appropriate entries for the new major version. (For example, update the URLs for a web installation or add the new CDs for a local installation.)

2. Run apt-get update to refresh the list of available packages and versions.

3. Run apt-get dist-upgrade to actually upgrade the distribution. This command causes apt-get to enter an alternate upgrade mode suitable for handling the potentially complicated dependency issues that arise during a full system upgrade.

4. When the upgrade completes, reboot the system to complete the installation if necessary.

It's immediately obvious that this procedure for a full distribution upgrade is very similar to the procedure for handling minor updates to a particular distribution version. The system still has to be rebooted (if the kernel was upgraded, for example) of course, but it's a pretty elegant process nonetheless.

Manipulating Debian Package Archives

All these packages that you've been reading about have to come from somewhere , so it's logical to ask how they are created. Also, someday you may want or need to view the contents of a Debian package, or extract a specific file from it, or otherwise deal with it at a very basic level. To support all of these tasks, Debian includes a program known as dpkg-deb that manages individual Debian packages. Table 6-4 summarizes the usage of dpkg-deb. As always, consult the manual page for full details.

As Table 6-4 shows, dpkg-deb is more or less functionally equivalent to RPM. However, it differs rather substantially in what happens when an archive is actually created. Recall from Chapter 4 that RPM packages are essentially built from special scripts contained in .spec (specification) files; these files contain all the information needed to re-create a binary RPM from pristine source code.

Debian packages, in contrast, are constructed with the dpkg-deb —build command, which creates the package by gathering the contents of the current directory and processing some specially named control files in the DEBIAN subdirectory. In fact, Debian's approach to creating packages is more like Slackware's than Red Hat's.

Managing Source Code

Some readers may be wondering whether Debian supports source packages, similar to the way that Red Hat's RPM supports .src.rpm files. The answer is "sort of." Since Debian packages are created to simply archive the contents of a particular directory, it's trivial to build a Debian .deb file that contains source code. However, there is no formal concept of a Debian source package; source code of Debian packages is distributed as standard "tarballs" (that is, gzipped tar archive files) containing the source along with files containing any patches that were necessary to build the software for Debian GNU/Linux.

Installing Non-Debian Packages

As was mentioned in Chapter 4, you're probably more likely to find an RPM packaging of a particular application than you are a Debian package. Thus, Debian users frequently find themselves in the annoying situation of wanting to install a binary software package that's distributed in a different (non-Debian) format.

To address this issue, Debian GNU/Linux includes the alien program. This is a tool that converts between packaging formats. For example, it allows Debian users to convert an RPM file into a Debian .deb package. The user can then install the package on her Debian system (provided that it meets the software dependencies, of course). However, since each package format has its own peculiarities , there are bound to be some packages that alien doesn't quite handle correctly. It's not a perfect solution, but it definitely can help. Users who find themselves in this predicament may wish to check out alien.

Mechanism and User Interface

As you've probably noticed by now, Debian's package management system is rather substantially different from those of Red Hat Linux and Slackware Linux. Whereas Red Hat's and Slackware's systems more or less automate the process of physically installing (and otherwise managing) packages, Debian's system takes package management to another level.

The best way to illustrate this is to compare the installation processes of Debian GNU/Linux and Red Hat Linux. During the installation of Red Hat Linux, the user selects from one of a set of installation classes—for example, Server, Workstation, or Laptop. These options are templates that install a list of packages customized for the selected class. Users can tweak this list after the installation, but at that point it comes down to locating a required package on a CD or the Internet, and then installing it manually.

Debian GNU/Linux takes a similar approach, but with a twist. The Debian installer really only installs a very minimal set of packages—just enough to boot the system. The user is then prompted to use the dselect program to build a list of packages to be installed, selecting from a separate list of available packages. At any given time, only a subset of the available packages will be installed on the system. This approach also makes it easy to update the system with bug fixes, and even upgrade to a new major release; the process is almost fluid in nature.

Of course, all this flexibility comes at a price—namely, complexity. Some people swear by apt-get and the convenience it provides, and others swear just as loudly that RPM is a superior packaging format. Still others, of course, follow the KISS ("Keep It Simple, Stupid") philosophy and prefer Slackware's much more streamlined mechanism. There are vociferous advocates for each of these packaging systems, even though they have a great deal of overlapping functionality. In the end, users should use whatever they like best.

Which Tool Is Best?

So far, you've read about three different package management tools: Red Hat's RPM, Debian's .deb system, and Slackware's basic .tar.gz system. You've also read about a variety of tools that add a layer of functionality to these systems, providing features such as network transparency and various user interfaces.

If there's one thing you should remember, though, it's that there's more than one way to do something. Much of the "culture" of a given operating system is tied up in the way it handles updates; for example, Microsoft Corp.'s introduction of its Windows Update system was a major event for that community, despite the fact that Linux distributions had been providing such a mechanism for years . As another example, the FreeBSD Unix-like operating system has its own very powerful method that involves updating the source code for the entire operating system (and all applications!) via CVS, and then recompiling the whole thing. (This can take days for a full update!)

Working with a Linux distribution (or any other operating system) means that you're going to have to learn the way things are done on that system. So, try and avoid getting too attached to a particular distribution, because it's likely to be completely different on the system you use tomorrow.

---

< Free Open Study >