Tools like apt-get and aptitude resolve dependencies and automatically remove programs that are no longer needed. They also clean up, update, and configure software on a Debian-based systems, such as Ubuntu, relying on mechanisms of package management for large-scale operations.

Both programs are easy to use for simple tasks (see the "Basics" box), but, with a little know-how, you can draw upon a very complete set of the tools and accomplish even complex tasks quickly and easily.

Default Settings

The apt and aptitude distribution maintainers usually provide default configurations. In the past, these were included in two files in the /etc/apt directory. The /etc/apt/apt.conf file handled the system-wide behavior [2] of apt and aptitude, whereas the /etc/apt/preferences file set the priorities for packages and package groups. Both of these files are optional on current systems.

Over time, the developers modularized the apt system configuration piece by piece. Since 2001, they have separated the configuration files into two separate directories – with the same filenames as before except ending with .d [3]. Following /etc/apt/apt.conf.d/, version 0.7.22 in 2009 (i.e., between 07.20.2 "Lenny" and 0.8.10.3 "Squeeze") came /etc/apt/preferences.d/ and, in 2010, /etc/apt/trusted.gpg.d/.

These directories further prioritized packages and included additional key ring files, such as the GPG key to verify backports, which are updated, bug-free, or functionally enhanced packages applied to older Debian releases to keep up the system up to date.

This directory structure allows software maintainers to ensure through their own configuration files that additional operations can run before or after installing programs with apt or aptitude.

All programs based on apt use the files in /etc/apt/ and use the identical file format, which recalls run-parts [4]. Files in these directories must follow certain naming conventions. Therefore, apt ignores files missing the .list extension in /etc/apt/sources.list.d/.

Additionally, some programs (aptitude in particular) put configuration files in other locations. Thus, aptitude saves its own system-wide defaults in /usr/share/aptitude/aptitude-defaults, which apt ignores [5].

If you change settings in the curses-based aptitude interface, parameters end up in the .aptitude/config file in your home directory and apply only to you.

To apply the change system-wide transfer the contents as root user from .aptitude/config to /etc/apt/apt.conf or into a new file in the /etc/apt/apt.conf.d/ directory.

After a standard CD or DVD installation, you can find four files in the /etc/apt/apt.conf.d/ directory whose names begin with a two-digit sequence (Table 1).

Apt works the files with these prefixes in ascending order of name [6]. The remaining files can be named as desired, but should normally correspond to the originating package name.

Apt ignores files with names ending in .disabled or a tilde (~), with the latter being an editor backup file. If dpkg modifies configuration files, it also creates copies without any effect on apt behavior.

You can tell which configuration apt and aptitude actually uses with the apt-config program from the apt package. If you invoke it with the dump option, you get a complete overview of all configured values (Figure 1). If you want to supplement the configuration, it's usually best to add a corresponding fragment from the /etc/apt/apt.conf.d/ directory.

Figure 1: The apt-config command displays the current settings at a glance.

Single-user systems can usually omit most apt configurations. The situation gets interesting if you want to maintain a current software state or exclude certain packages from installing despite the existence of a current package. The same goes for automatically installing recommended packages or if network access is done through a proxy server [7][8][9].

The subtle differences between apt and aptitude are made clear, among other things, by the differences in removing "orphaned" packages. These packages are created when the package manager doesn't remove all dependencies during an uninstall that were necessary only for the removed package but in no way affect any newly installed software.

Apt-get simply indicates that such orphaned packages exist, whereas aptitude automatically removes them. The related configuration command options and settings are shown in Table 2.

In One Step

Apt-get lets you reverse the operation of both the subcommands install and remove. For apt-get, you add a plus or minus sign to each package name. With a minus sign added to the package name for apt-get install, for example, you can remove it instead of installing it.

This functionality turns out to be useful when you set up a package that has alternative dependencies where you want to exclude certain ones. The stumpwm package uses a Lisp interpreter written in Stump Window Manager [10], but it doesn't settle on a particular one. Therefore, one of the three packages (clisp-module-clx, cl-clx-sbcl, or cmucl-source) should suffice. If you don't have any of them installed, apt-get usually selects the first package. If that's not what you want, you can use the following command to deselect it, in which case apt-get uses the second one instead:

# apt-get install stumpwm clisp-module-clx

Aptitude provides far more options in this respect. On one hand, it allows these corrections with other subcommands, such as full-upgrade, safe-upgrade, markauto or hold. On the other hand, it provides far more actions that you can add with tags to the name of the package (Table 3).

The example in Listing 1 shows these options in practice. With one command, aptitude updates the lintian package, installs the htop package and any missing build dependencies (libncurses5-dev in this case), removes the tasksel package along with its dependencies, and sets the ccal package as "automatically installed." Package manager then removes Ccal because no other package depends on it. All other packages not named remain in their current state, even if a newer version is available: aptitude full-upgrade processes only the specified packages.

# aptitude full-upgrade lintian htop+ 'htop&BD' tasksel- 'ccal&M'
The following NEW packages will be installed:
  htop libncurses5-dev
The following packages will be UPGRADED:
  lintian
The following packages will be KEPT BACK:
  iceweasel libmozjs10d xulrunner-10.0
The followihhhhng packages will be REMOVED:
  ccal{a} tasksel tasksel-data{a}
1 packages upgraded, 2 newly installed, 3 to remove and 3 not upgraded.
[...]

Filtering and Search Patterns

Aptitude provides extensive options for searching for packages. Both the interactive interface and the command line include powerful filters and search patterning. The curses interface provides the search input with the Shift+/. In the CLI, the command is search followed by the search string.

In both cases, aptitude lets you input not only parts of the package name and regular expressions, but also special search patterns. These include ~i for all installed packages, ~M for all those automatically installed through dependencies, and ?description(<description>) in searching for package descriptions (Figure 2).

Figure 2: Aptitude helps effectively sift through the huge inventory of packages with search patterns and filters.

Most of the search patterns have both long and short forms. The long forms start with the question mark, and the short forms begin with the tilde character. A selection of search patterns is shown in Table 4; a full list is available online [11] and in the aptitude-doc-en package.

These patterns also help filter the lists in the text interface and commands in the CLI. Use L to filter the text lists, where you get a search input box for entering a pattern, as in a search. The program displays only those software packages that match the pattern (in Figure 3, o[kc]ular). You can accurately find each package, even if the spelling isn't exactly right.

Figure 3: A search using a regular expression for the Okular PDF viewer.

Patterns also prove useful at the command line. The following command marks all packages that begin with the name lib as automatically installed:

# aptitude markauto '~n^lib'

You should normally only install software libraries that you actually use. Our example can have an undesirable side effect: It targets LibreOffice but picks up packages with header files (whose names typically are lib<name>-dev) and removes them, which was not what we wanted.

A more precise filtering is using the section name instead of the package name as the pattern. The following command marks all packages in the libs and oldlibs sections as "automatically installed":

# aptitude markauto '~slibs'

An explicit ~soldlibs option is not necessary because aptitude recognizes the pattern as part of a section name. Specific exceptions (e.g., libraries that end up in a system because of a dependency) can be dealt with through corrections to actions (see Table 3). After the previous command, aptitude would remove all libraries upon which no other packages depend – with the exception of the libtclcl1 package, marked as "not automatically installed," which remains installed.

aptitude markauto '~slibs' 'libtclcl1&m'

Another typical example is purging previously removed configuration and application data from already configured packages:

# aptitude purge '~c'

The same warning as for --purge-unused applies, however. When not used correctly, the action can lead to losing possibly required data. Thus, a setting for packages for the Debian MySQL server can determine whether the system should delete databases during a purge. In any case, a second look before executing the command is advised.

Aptitude proves to be much more complex and provides quite a few more options for managing packages. Of course, this also has its downside. The program uses considerably more time to start and end than apt-get. At startup, it reads its additional database to determine status and, when it closes, it saves it back to the hard disk. This happens even in cases when you would not think it necessary [13], making it a slower than apt-get.

Conclusion

If you want fine-grained yet efficient control of the packages you use, the mighty aptitude provides far and away more options than apt-get. However, it requires a bit more knowledge and a steeping learning curve, whereas apt-get gets a start right out of the gate. Apt-get might thus provide a better choice if you want to avoid "side effects" in prepared actions, such as accidentally deleting packages.

Once you have learned to appreciate aptitude's text mode interface with all its options for previewing and filtering, must always remember to call aptitude keep-all before each run, to remove all reservations.

If you're writing installation instructions for an Ubuntu package or article, you should make sure you always use apt-get in all your examples. Apt-get provides the basic functionalities and it's best to let the users decide whether to use apt-get or aptitude. As an author, you can't possibly anticipate what side effects could occur with aptitude.