- Introduction to Package Management
- Debian Packages
- Package Management in Ubuntu
- Making Your Own Packages
Package Management in Ubuntu
The administrator of every Ubuntu installation—servers and desktops—will need to learn the basic mechanics of package management. As administrators need to find new software to solve particular problems, metadata in the packaging system can be a great place to start. When administrators want to install new software, the packaging system provides the best way to do so. The Ubuntu package system will also allow users to install and remove software, check for updates—and for security updates in particular—and install these updates. Finally, when a new release of Ubuntu is made, the packaging system will allow administrators to update their systems.
Ubuntu provides a variety of different tools for package management. On a desktop Ubuntu system, users’ interaction with the package management system is primary through a little icon on the desktop that alerts them to new releases of software and through the graphical Add/Remove Programs application and a second graphical package management program called Synaptic that provides functionality to let users browse the package archives. Since these programs are covered in depth in The Official Ubuntu Book and because the focus of this book is servers, this section will focus on the command-line tools for package browsing and management.
Most server administrators primarily use tools in the APT family that handle high-level package management. The original tool developed for this purpose was apt-get. Aptitude is a frequently used alternative to apt-get that provides both an interactive front end and that takes most of the default apt-get commands. Many of the commands described in the rest of this chapter that call aptitude can also be used with apt-get with little or no difference in either output or behavior. The primary differences are in the ways that the systems resolve complicated dependency situations and certainly would not affect the reasonably simple operations described here.
Staying Up-to-Date
Each Ubuntu system stores a list of package repositories in /etc/apt/ sources.list. This describes the list of “places” where your package managers—originally just APT but now several other tools—will look for updated versions of software. These sources may include local repositories on your file system, a CD in your computer, or—as is common in the vast majority of situations—a network location. To update the system, you can run apt-get update or aptitude update.
This command will download the latest updated package lists for all repositories listed in your /etc/apt/sources.list files and will check any cryptographic signatures on these updates against the keys stored on your machine. On a new system, this will check only the Ubuntu package repositories that include the repositories you installed from and the security repositories.
Installing any new version of packages is as simple as running aptitude safe-upgrade, which is a replacement for the apt-get upgrade command that may be more familiar to more seasoned users. safe-upgrade simply tries to upgrade all installed packages to their most recent versions. Installed packages will not be removed unless they are unused, although additional packages may also be installed in order to resolve added dependencies.
APT can be configured to automatically download and upgrade packages with new versions. This is an attractive proposition to administrators who like the idea of not having to log in to their systems to keep them up-to-date. However, automatic package upgrades are subject to errors because of the particular status of software on the system or even particular configuration changes that have been made, so these automatic package upgrades can leave systems in unstable or unworkable states. As a result, automatic upgrades are neither covered in this book nor recommended by the authors.
Searching and Browsing
Historically, the primary way of searching for new packages was using the program dselect. Users of Ubuntu on the desktop will primary use the Add/Remove Programs application and the graphical program Synaptic. Users on the console have several other options.
First among these is the simple program apt-cache, which can provide statistics about and information on packages. If, for example, I decide I want a pager like less, I can search for one in the following way:
$ apt-cache search pager less less - Pager program similar to more wdiff - Compares two files word by word console-log - Puts a logfile pager on virtual consoles gdesklets-data - Applets for gdesklets jless - A file pager program, similar to more(1) supporting ISO2022 most - Pager program similar to more and less nagios-plugins-basic - Plugins for the nagios network monitoring and management system
As you can see from the previous list, the apt-cache search command returned eight “hits” for my search on the two keywords pager and less and returned a list of package names followed by short one-line descriptions. The keyword search looked through the full list of available packages and focused on the package names, short descriptions, and full descriptions that are not shown in the returned list. If I want to know more about a package, apt-cache can also show me more about the package with the show subcommand as in the example below:
$ apt-cache show most Package: most Priority: optional Section: universe/text Installed-Size: 172 Maintainer: Ubuntu MOTU Developers <ubuntu-motu@lists.ubuntu.com> Original-Maintainer: Benjamin Mako Hill <mako@debian.org> Architecture: i386 Version: 5.0.0a-1 Depends: libc6 (>= 2.7), libslang2 (>= 2.0.7-1) Filename: pool/universe/m/most/most_5.0.0a-1_i386.deb Size: 48092 MD5sum: e089c00005b536e1b8848b7087df2bae SHA1: 4f4ab395f340be4804732452aa112007916f90cb SHA256: ccf50fb49270e7ddf7735da23e699afcd11dcfc8e241973bb17ad03bf49e6f4a Description: Pager program similar to more and less Most is a paging program that displays, one windowful at a time, the contents of a file on a terminal. A status line at the bottom of the screen displays the file name, the current line number, and the percentage of the file so far displayed. . Unlike other paging programs, most is capable of displaying an arbitrary number of windows as long as they all fit on the screen, and different windows could be used to view the same file in different positions. . In addition to displaying ordinary text files, most can also display binary files as well as files with arbitrary ascii characters. Bugs: mailto:ubuntu-users@lists.ubuntu.com Origin: Ubuntu
You may recognize that quite a bit of this information looks like the source package information and the corresponding stanza referring to this binary package in the control file described previously. Sure enough, this is exactly where this metadata has been extracted.
Of course, the bulk of the output is made up of the long-form description that was omitted in the previous example. There are some other fields of potential interest, including the “Original-Maintainer” or the person who packaged the system in Debian, the “Maintainer” or the person or group to contact with questions about or issues with the package, and sizes and hashes (e.g., MD5Sum, SHA1, and SHA256), which describe ways to identify that a particular version of the package was downloaded correctly and has not been modified.
Called with no arguments, Aptitude also can provide users with a Curses-based text-based interface that allows for more interactive browsing of all the packages available. For users familiar with Synaptic, this can be thought of as a text-based version of the Synaptic interface. In this mode, many search results can be navigated through with the arrow keys and different applications can be “marked” for installation.
Before concluding this tour of the options for searching and browsing for packages, it is worth pointing to the Web site at http://packages.ubuntu.com. This interface lets users search in ways that are similar to some of the tools I have shown here but with several additional useful options. In particular, the Web site lets users search for particular files in any package in Ubuntu. Normally, users are able to find out only which package “owns” a file if they have the package on their system. If, for example, you need a particular header file or shared library and you know only the filename, you can search on the Web site for that filename throughout all packages available in the Ubuntu archive.
Installation and Removal
Installing and removing packages is another simple task that you will do frequently. To install a package, you can invoke apt-get or Aptitude in a similar way, although, unlike searching, a user must be running with root privileges to do so. The recommended way to do this would be to use the sudo command. Since prefixing each command in this section with sudo would be tedious, I have assumed the user is root, although having the user logged in as root would not be considered the best form. If I want to install most, I can simply run the following command as root:
# aptitude install most Reading package lists... Done Building dependency tree Reading state information... Done Reading extended state information Initializing package states... Done Writing extended state information... Done The following NEW packages will be installed: libslang2{a} most 0 packages upgraded, 2 newly installed, 0 to remove and 0 not upgraded. Need to get 0B/509kB of archives. After unpacking 1323kB will be used. Do you want to continue? [Y/n/?] y Writing extended state information... Done Selecting previously deselected package libslang2. (Reading database ... 362131 files and directories currently installed.) Unpacking libslang2 (from .../libslang2_2.1.3-3ubuntu1_i386.deb) ... Setting up libslang2 (2.1.3-3ubuntu1) ... Selecting previously deselected package most. (Reading database ... 362143 files and directories currently installed.) Unpacking most (from .../most_5.0.0a-1_i386.deb) ... Processing triggers for man-db ... Setting up most (5.0.0a-1) ... Reading package lists... Done Building dependency tree Reading state information... Done Reading extended state information Initializing package states... Done Writing extended state information... Done
You can see in the output of the command above that libslang2 was installed alongside most. In this case, Aptitude saw that most required the S-Lang library but that it was not installed. Aptitude prompted me for confirmation about the installation of the additional package (which I approved), downloaded both packages, and then installed and configured them on my system.
Removing a package is similar and similarly simple. If I decide to remove most, I can do so by running
# aptitude remove most
In this case, libslang2 will not be removed (since I have not asked for it to be removed). If I were instead to try to remove libslang2, Aptitude would prompt me and explain that removing libslang2 would also require removing all of the packages that depend on it—on this system, that would just be most, but for other packages or on other systems there could be quite a few packages. This type of dependency management means that, for example, users should not (and cannot easily) remove core or essential packages. Extra “unused” packages can be removed using the command apt-get autoremove.
Finally, while these examples both used Aptitude, the installation and removal of packages can also be done with the lower-level tool dpkg. In fact, in both cases Aptitude is simply calling dpkg on the downloaded package files behind the scenes. Aptitude—or apt-get—will always download packages and work out dependencies before turning to dpkg. If you have already installed existing dependencies, you can install a DEB directly with dpkg by using the -i command and passing the package filename as an argument. For example, if I were given a DEB file for most, I could install it with a command like this:
$ dpkg -i most_5.0.0a-1_i386.deb
dpkg will check dependencies and produce an error if there are missing dependencies but will not automatically download or install packages since it does not contain the functionality to do this. I could uninstall most with dpkg with the command dpkg -r most.
Manipulating Installed Packages
dpkg provides dozens of methods of querying, searching, and manipulating installed packages. It contains a database of information about packages installed on the system. To get a quick overview of what this might look like, you could run the following command:
$ dpkg -l most Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Cfg-files/Unpacked/Failed-cfg/Half-inst/ trig-aWait/Trig-pend |/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad) ||/ Name Version Description +++-===========-============-=============+======================= ii most 5.0.0a-1 Pager program similar to more and less
Run without any arguments, dpkg -l will show this basic information on the installation status, name, version, and description of every package on your system.
Another simple task is to get a list of files contained within the package. If you have a DEB file that you have not installed, you can get this information by running dpkg --contents as in the example below:
$ dpkg --contents /var/cache/apt/archives/most_5.0.0a-1_i386.deb drwxr-xr-x root/root 0 2008-05-06 12:06 ./ drwxr-xr-x root/root 0 2008-05-06 12:06 ./usr/ drwxr-xr-x root/root 0 2008-05-06 12:06 ./usr/bin/ -rwxr-xr-x root/root 59940 2008-05-06 12:06 ./usr/bin/most drwxr-xr-x root/root 0 2008-05-06 12:06 ./usr/share/ drwxr-xr-x root/root 0 2008-05-06 12:06 ./usr/share/man/ drwxr-xr-x root/root 0 2008-05-06 12:06 ./usr/share/man/man1/ -rw-r--r-- root/root 5912 2008-05-06 12:06 ./usr/share/man/ man1/most.1.gz drwxr-xr-x root/root 0 2008-05-06 12:06 ./usr/share/doc/ drwxr-xr-x root/root 0 2008-05-06 12:06 ./usr/share/doc/most/ -rw-r--r-- root/root 2989 2007-09-09 12:14 ./usr/share/doc/ most/changelog.gz -rw-r--r-- root/root 5544 2008-05-06 12:06 ./usr/share/doc/ most/copyright -rw-r--r-- root/root 3335 2007-09-06 10:15 ./usr/share/doc/ most/README -rw-r--r-- root/root 1386 2006-05-01 13:51 ./usr/share/doc/ most/lesskeys.rc -rw-r--r-- root/root 492 2006-05-01 13:51 ./usr/share/doc/ most/most-fun.txt -rw-r--r-- root/root 3086 2006-05-01 13:51 ./usr/share/doc/ most/most.rc -rw-r--r-- root/root 2028 2008-05-06 12:06 ./usr/share/doc/most/ changelog.Debian.gz drwxr-xr-x root/root 0 2008-05-06 12:06 ./usr/lib/ drwxr-xr-x root/root 0 2008-05-06 12:06 ./usr/lib/mime/ drwxr-xr-x root/root 0 2008-05-06 12:06 ./usr/lib/mime/ packages/ -rw-r--r-- root/root 94 2008-05-06 12:06 ./usr/lib/mime/ packages/most
Similar information for installed packages can be retrieved with dpkg -L. Working in the other direction, if you have a particular file and you want to know which package “owns” it, you can use dpkg -S to query the database for this information. For example:
dpkg -S /usr/bin/most most: /usr/bin/most
The binary file /usr/bin/most belongs to—no surprise here for anyone who’s gotten this far—the binary package called most. Since this command is searching through each of the file lists of every package on your system, it may take some time to complete.
Manipulating Repositories
The best way to install new software in the “Ubuntu way” is never to simply download new DEB packages and install them “by hand” with dpkg. But APT is only kept up-to-date with the packages that it already knows about. While dpkg works on packages, APT works on repositories of packages that contain information on different packages, their versions, and their dependencies. As a result, to manage a package through APT, one needs to add to the system not the package, but rather the repository that contains it. This is done by adding or editing the list of “sources.” While the Ubuntu desktop distribution includes a graphical tool for manipulating repositories, it can be done easily by hand, which will be the default on most systems.
The source.list file, already mentioned several times in this chapter, is located at /etc/apt/sources.list on every Ubuntu and Debian system and is made up of a series of lines like this:
deb http://archive.ubuntu.com/ubuntu intrepid main universe deb-src http://archive.ubuntu.com/ubuntu intrepid main universe
The first word will either be a # symbol marking the line as a comment or either deb or deb-src. This specifies whether the repository is a source package repository or a binary package repository. The second item is the location in the form of a URI. The third item is the name of the distribution or, as it might more accurately be described, the distribution version. In the example above, this distribution version is intrepid, which refers to the Ubuntu release of the Intrepid Ibex. The remaining arguments are the lists of the components. The components provided in the core Ubuntu repositories are detailed in the following section.
An example will help illustrate the process of adding a repository. If I want to install a version of Bazaar that is always the latest released version, I will need to do this from outside the default Ubuntu repositories, which will only be updated based on the Ubuntu release cycle. Luckily, the Bazaar developers provide their own “Personal Package Repository”—a subject I’ll come back to at the end of this chapter. On their Web site, they provide the deb and deb-src lines that I can simply drop into my sources.list:
deb http://ppa.launchpad.net/bzr/ubuntu intrepid main deb-src http://ppa.launchpad.net/bzr/ubuntu intrepid main
If I update, I am first greeted by an error that claims that I do not have the correct cryptographic key to verify that the packages in the repository are really coming from the Bazaar developers:
W: GPG error: http://ppa.launchpad.net intrepid Release: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY FE8956A73C5EE1C9
I can easily install that by downloading the key from a trusted source like the PPA providers’ Web site and saving it into a file (called /tmp/keyfile in the example below), verifying that is correct, and adding to the package manager’s key database with a command such as
apt-key add - < /tmp/key OK
The apt-key manual page gives more details on how keys for repositories can be managed with this useful command.
Ubuntu Default Repositories
The vast majority of packages that you will need have been packaged for Ubuntu. This is because, leveraging the work of Debian, Ubuntu provides access to a large majority of the most popular pieces of free software as packages in their own repositories.
These tens of thousands of packages are separated into a series of different sections or components. You can toggle these on and off by including them in the list of components in your sources.list. Because these have important consequences for the level of support you will receive for your software, it is worth understanding these different components so that you can decide from which areas you want to pull software. Available components on the Ubuntu server include main, restricted, universe, and multiverse. The following descriptions are adapted from the component descriptions on the Ubuntu Web site.
Main
The main distribution component contains applications that are free software, can freely be redistributed, and are fully supported by the Ubuntu team. These include the most popular and most reliable open source applications available, much of which is installed by default when you install Ubuntu. Software in main includes a hand-selected list of applications that the Ubuntu developers, community, and users feel are important and that the Ubuntu security and distribution teams are willing to support. When you install software from the main component, you are assured that the software will come with security updates and technical support.
Restricted
The restricted component is reserved for software that is very commonly used and that is supported by the Ubuntu team even though it is not available under a completely free license. Please note that it may not be possible for Ubuntu to provide complete support for this software since the Ubuntu team is unable to fix the software but can only forward problem reports to the actual authors.
Universe
In universe one can find almost every piece of open source software and software available under a variety of less-open licenses, all built automatically from a variety of public sources. All of this software is compiled against the libraries and using the tools that form part of main, so it should install and work well with the software in main, but it comes with no guarantee of security fixes and support.
Multiverse
The multiverse component contains software that is not free, which means the licensing requirements of this software do not meet the “main” component license policy. The onus is on you to verify your rights to use this software and comply with the licensing terms of the copyright holder. This software is not supported and usually cannot be fixed or updated. Use it at your own risk.
Using Other Repositories
As you saw when I added the Bazaar repository several sections ago, users will still sometimes want to make use of a variety of outside repositories beyond what is provided in Ubuntu. For example, users might want to install new versions of particular applications or libraries from the development release of Ubuntu but might not want to upgrade all of their packages to the latest version.
The quasi-official “backports” repository in Ubuntu is a useful resource. It contains versions of software from the development version of Ubuntu that have been “backported” to install cleanly on stable versions of Ubuntu. You can add the backports by installing a DEB package by hand in a one-by-one with dpkg or by adding an extra line to your sources.list. Information on doing both can be found on the Ubuntu Web site at https://help.ubuntu.com/community/UbuntuBackports.
One reason that many users choose to go the à la carte method—that is, the method of downloading packages by hand and installing them with dpkg—as opposed to just adding the repository is because of a limitation in the way that APT works: APT and other tools will always install the newest version of any package available by default. This means that if you add the backports repository, or the development repository for that matter, to your sources.list, the latest version of everything in that repository will be installed when you try to run an upgrade. For small repositories (like the Bazaar PPA described several sections ago that contained only Bazaar and several closely linked packages) this does not present a problem. However, in situations where you want to add a large repository of many packages like the backports repository or the development release of Ubuntu but only want a few packages, the effects will often not be what you want.
The general solution to this problem is called “pinning” or “apt pinning.” Pinning is extraordinarily powerful but, in its advanced forms, can also be very complicated. As a result, a full discussion is outside the scope of this chapter. That said, an example is shown below for the situation where I have Intrepid installed but want APT to prefer packages in Jaunty. To change this, I would need to edit the file /etc/apt/preferences so that it included something like the following section:
Package: * Pin: release a=intrepid Pin-Priority: 700 Package: * Pin: release a=jaunty Pin-Priority: 600
Each stanza describes one release and, as is represented by the wildcard in the first line, applies to all packages. In the final line of each stanza, the pin-priority describes both relative position (i.e., in the example above, Intrepid is preferred to Jaunty) and weight that will be given to each. Weights can be tweaked so that packages will be installed, or not, except in special circumstances. Much more information on pinning is available in the apt_preferences manual page and in several excellent pieces of documentation on the Ubuntu and Debian wikis.
Upgrading a Whole System
A final basic task that every system administrator will need to do is to upgrade a full system. On desktop Ubuntu systems, the default way of handling an upgrade is by using the update manager software. However, this software is designed specifically to upgrade graphical systems. Since the process can just as easily be done from the command line, that will probably be more appropriate on most servers.
In the past, upgrading most systems was a two-step process. First, the administrator would update the list of repositories (detailed in the previous section) so that references to the old release were replaced with the new release. For example, if I were upgrading from the Hardy Heron to the Gutsy Gibbon, I would replace every instance of hardy with gutsy in my source.list file. After doing this, I would run aptitude update exactly as I described in the section above on staying up-to-date. This would refresh my local package metadata cache with a list of all the packages in the new distribution.
Finally, I would run aptitude full-upgrade which, unlike safe-upgrade, described previously, would upgrade all installed packages to their most recent version and would remove or install additional packages as necessary. full-upgrade is less conservative than safe-upgrade and is much more likely to perform unwanted actions. However, it is capable of upgrading packages that safe-upgrade cannot. Because these sorts of situations are much more common between releases, using full-upgrade became the recommended course for upgrading between releases. However, neither method is supported anymore.
In current releases of Ubuntu, the correct way to upgrade systems is with the do-release-upgrade program. do-release-upgrade is a script that automates the process described above in addition to handling a number of corner cases and exceptions intelligently. It is the supported way to upgrade one’s Ubuntu server.
Mirroring a System
One common task many system administrators want to accomplish is to mirror the installed software from one machine to another. Because all software on a default Ubuntu system is installed in packages, the packaging system can make this easy. Using dpkg, one can get a list of all packages on the machine with the following command:
# dpkg --get-selections > package_list
This will output a simple list of packages and then redirect that output into a file called package_list. I can copy this file to another machine and then use it to set the list of installable packages with the following command:
# dpkg --set-selections < package_list
Finally, I can install those selections onto the target system using the following command:
# apt-get dselect-upgrade
dselect-upgrade is a reference to APT’s predecessor dselect but will simply work to upgrade packages on the system and install any new packages “marked” for upgrade by dpkg --set-selections in the process.