The Ubuntu Software Center is only one of many package management tools used on Debian-based Linux systems. Although users have the choice of many worthy GUI alternatives, experienced users often prefer to work from the command line.

Apt-get and aptitude are a pair of command-line package management tools for the Debian environment. Although these tools might seem very similar, they use different approaches for managing software packages. Whereas apt-get executes the input commands exactly, aptitude has a memory and autocompletes them. Aptitude also provides a powerful interactive interface in text mode. Apt-get, however, is usually the faster of the two.

Behind the Scenes

The fundamental tools for software packaging on Debian-based system are dpkg and apt. Dpkg, the lowest level of package management for Debian, is responsible for unpacking DEB packages and handling updated configuration files. It also prevents one package from unexpectedly overwriting a file of another package.

Apt takes care of everything dealing with package lists and their evaluation – for example, downloading package lists, automatically resolving package requirements, and downloading the package files themselves. Apt thus consists of several components, on one hand, the two program libraries libapt-pkg and libapt-inst , and on the other, various command-line tools, including apt-get and apt-cache. All other programs, such as aptsh , aptitude , and synaptic are based on the APT program libraries. (One exception is cupt [1], which is why it's left out here.)

The developers of apt and aptitude are running a kind of race to see which of the two projects has fewer open error reports [2]. The projects currently are pretty much tied.

Differences

The most obvious difference between the two tools is, first of all, their manner of display. Apt, aptitude, and aptsh accept commands on the command line, although aptsh follows a slightly different concept. Aptitude also uses an ncurses-based text-mode user interface (Figure 1). You control complex actions with aptitude by using the text-mode interface or through call parameters.

Figure 1: Aptitude's text-mode interface shows a series of packages destined for upgrading.

For a short while, aptitude also had a GUI version based on the GIMP toolkit, but it never achieved the quality and stability of aptitude's ncurses interface and is, therefore, no longer being maintained [3]. The aptitude-qt Qt counterpart is in the sources too, but a viable version hasn't yet surfaced.

Synaptic also provides a graphical interface and is quite popular, along with Ubuntu's Software Center.

Subcommands and Parameters

Table 1 shows some differences between apt-get and aptitude subcommands. You'll see some differences between subcommands of the same name in both tools. This is especially true of upgrade , safe-upgrade , dist-upgrade , and full-upgrade , so they are treated separately elsewhere (see the "Subtle Differences" box). Further information is in the aptitude manual [7] and the man pages for apt-get and aptitude.

Well Considered

Somewhat hidden is the possibility of not directly executing actions with aptitude but scheduling them for later execution. The software works on these scheduled actions as soon as it hits other actions at a later point, such as installing, removing, or updating packages.

The order in which aptitude executes the scheduled actions cannot always be predicted. It depends largely on the dependencies among the packages that need to be considered in single actions. Additionally, later actions can revise earlier ones. Aptitude stores the action status of packages in an internal database (see the box titled "Aptitude's Status Database"). Any packages that are earmarked to fulfill dependencies are marked as "automatically installed" with the letter A in the user interface.

Package: debtree
Unseen: no
State: 1
Dselect-State: 1
Remove-Reason: 0

Apt can also deal with these markers and sets them when installing packages. If apt-get discovers packages marked as automatically installed but no other package depends on them, it will inform you.

You execute package actions with aptitude on the command line or in the interactive text mode interface. In the text-mode interface, practically every package marking (+ for installation or – for removal) is a scheduled action. If you press g , you will see previews of held packages in the standard configuration.

Pressing g again executes the held action. Pressing q stops aptitude, but it remembers the previously planned package actions for the next call. Pressing Ctrl+C stops aptitude without storing the actions.

You can get the same result on the command line by including the --schedule-only option in an aptitude call. Performing a subsequent aptitude install , without further parameters, is enough to execute all the scheduled actions (see Listing 1).

# aptitude --schedule-only install htop
# aptitude --schedule-only remove tasksel
# aptitude install
The following NEW packages will be installed:
  htop
The following packages will be REMOVED:
  tasksel tasksel-data{a}
0 packages upgraded, 1 newly installed, 2 to remove and 0 not upgraded.

It's often helpful to find out before installing which held packages are affected. The easiest way is to simulate the action by activating the -s or --simulate option, as in aptitude install -s . In interactive mode, you would first select the package with + , and then press g for the preview (Figure 2).

Figure 2: Aptitude shows the selected package as libreoffice-common. Pressing g proceeds with the upgrade.

To cancel scheduled actions, aptitude provides the subcommand keep-all . If you simply want to undo a single package, you can use the subcommand keep , such as in aptitude --schedule-only keep tasksel . In interactive mode, you can press Shift+: (Shift+; for US-American keyboard layout) after selecting the package. To undo the last scheduled action, press Ctrl+U in interactive mode.

Colorful Mix

You will attract errors and add confusion if you alternately use apt-get and aptitude – for example, if you install Package A with aptitude, then use apt-get to remove Package A, and the install Package B, again with aptitude.

In the first step, aptitude sets up any actions and installs Package A. In the second step, apt-get deletes Package A without aptitude knowing anything about it, so aptitude assumes the package is still installed. In the last step, aptitude installs package B along with package A, again because package A is in the list of packages to be installed by aptitude. Package B is considered "lost" by aptitude and therefore needs to be set up again for installation.

Conversely, the same would not occur. Aptitude doesn't remove a package installed by apt-get behind its back because the software considers it "installed" in its list. This behavior belongs to the group of bugs centered around holds between aptitude and dpkg/dselect [8]. To avoid the trouble, it's best to decide on one of the package managers and stay with it.

This detail especially gains in importance when software in an APT repository indicates that it should be installed via aptitude install package_name . This call might potentially install the package, but it can also drag along all of aptitude's scheduled package actions  – which is not always the developer's intention. The same danger might not exist with apt-get install package_name .

Conclusion

Apt-get and aptitude are command-line package managers for Debian-based systems, including Ubuntu and its many variants. If you are growing weary of the Software Center and prefer to work from the command line, either apt-get or aptitude will do the job – but don't try to use them both. Whether you adopt apt-get or aptitude is entirely your decision and has nothing to do with the software you wish to install.