Debian's package tools are famous for their reliability. However, their weakness is that they developed over decades with little centralized planning. As a result, the Debian archives now list 44 package utilities starting with "apt" alone [1], each with its own set of options. Add other packages, such as dpkg and alien, and the total is closer to 60. Wajig [2] reduces this complexity by uniting package management under a single command with self-explanatory sub-commands.

Wajig has been an open secret in the Debian world for two decades. Graham Williams of Togaware, wajig's original developer, explains that users had trouble remembering not only Debian's commands but also "the extra greps and awks and finds that would be commonly used in conjunction with them. I was also regularly coming across tips and tricks for managing the system from various newsgroups and blog posts. I used to write them down in documents and cheat sheets, but then started to bring them together into a single command."

Because package management is an administrative function, Williams wrote it as a command-line tool. "Whilst GUIs can deliver quite a bit of simplicity and yet still offer quite a bit of power," Williams says, they can't do everything that we do from the command line."

Wajig is a Python script that maps its sub-commands to standard commands such as dpkg, apt-cache, and wget. Most of these standard commands are installed by default in distributions; but, if they are not installed, wajig will tell you what you need to install when you run the sub-command. You can install it just as you would any other package.

Only a token man page accompanies wajig, but you can read a summary of its mappings by entering wajig help or a one-line explanation by entering wajig -commands. For full documentation, increase the verbosity level with wajig docs or wajig --verbose=2 help (Figure 1). The same documentation is available online [3].

Figure 1: Wajig installs with two levels of help: a summary and a brief manual.

The basic structure of the command resembles that of apt-get or dpkg:

wajig SUB-COMMAND OPTIONS [PACKAGES, FILES, or STRINGS]

Many of the sub-commands are identical to those used in apt-get or dpkg, which helps make wajig easy to learn. Many sub-commands can be run by ordinary users, but those that involve installing or removing packages invoke sudo first. If you do not have sudo set up on your system, you will have to run these sub-commands as root instead.

Wajig Options

Besides --verbose, wajig also includes a limited number of options. The opposite of --verbose is --quiet or -q, which runs the command without any feedback. By default, wajig assumes authenticated archives, but you can work with unauthorized archives by prefacing the sub-command with --noauth or -n.

Another useful option is --simulate or -s, which tells you what wajig will do when you enter a command without actually doing it (Figure 2). This option is useful if you are upgrading packages that are essential to your system or GUI and want to check if you are likely to encounter problems.

Figure 2: The simulate option shows what commands will be run but does not actually carry them out.

Another option, --teaching or -t, appears to have been superseded in the latest releases without being removed from the documentation. The teaching option seems to have been replaced by equivalent sub-commands, just as wajig help replaces --help. Instead of --teaching, use the showdistupgrade, showinstall, showremove, or showupgrade sub-commands – whichever is appropriate for what you are doing.

Basic Package Management

Using wajig is largely a case of knowing which sub-commands to use and following the occasional directions that wajig offers while you work. For example, before installing packages, you may want to run wajig with edit so you can edit the list of repositories at /etc/apt/sources.list. If you edit the repositories or have not updated them in some time (you can check by running last-update), then you probably need to run update to get a current list of available packages.

Before installing a package, you might also run wajig with bug, so you can read about the latest problems or report problems you have already found (Figure 3). Running changelog, too, might tell you how packages have changed between versions, which could occasionally be useful – perhaps when a package has been updated to use systemd instead of init, or Wayland rather than init.

Figure 3: Use bug either to report a bug or to check on a package before installing it.

If you are unable to find a package, you can search by entering a package name or a string after the sub-command list-names. If you have several repositories enabled, you can use apt-cache's madison to see a list of available versions (Figure 4).

Figure 4: The madison sub-command lists the versions of a package in your enabled repositories.

Installing or upgrading includes several convenient sub-commands, all based on apt-get. Besides the basic install, you can use installsuggested to install all suggested packages listed for a package – that is, packages that enhance but are not needed. You also have the option of pinning the install to a particular repository with install/dist REPOSITORY.

Additionally, installation can be automated by using auto-install so that wajig does not prompt you with questions about the installation, or you can simply run auto-download to update the repository lists and then install all updated packages. More simply still, upgrade installs the latest versions of the packages listed after it, or, if left unqualified, all packages already installed.

If you run into problems during installation, you have apt-get's full array of problem-solving tools: fix-install, fix-missing, and force (Figure 5). A problem package can be held back with hold or installed again with unhold. Yet another option is to use reinstall on a package – after, of course, updates have appeared in the repository or you have added another repository.

Figure 5: Wajig uses apt-get for basic package installation.

Removing packages is as versatile as installing them. The sub-command remove uninstalls a package, as with apt-get, whereas purge removes all the package's files, as with dpkg. You also have the option of using remove-depend to delete both packages and any dependents not required by other packages – a choice that removes the need to run remove-orphans to clean up after you are finished. However, you may want to run auto-clean to remove any packages that have been replaced with more up-to-date versions.

Getting Package Information

One of wajig's strengths is its sub-commands for learning more about packages. By specifying a package with the sub-command contents, you can view the files in a package; using list-scripts or list-sections, you can see the files in specific parts of the package. Similarly, dependents lists the packages that depend on, recommend, or suggest a package (Figure 6). If you know the command or file you need but are unable to find it, whichpkg can help you track down the package to install (Figure 7).

Figure 6: The dependents sub-command lists a package's relationship to other packages.

Figure 7: The whichpkg sub-command helps you locate the package that includes a command or file.

If you really want to know more about a package, the sub-commands starting with list are the place to start. The list command itself gives you the status of all installed packages. Using list-alts shows the alternatives, if any, for the package, and list-daemons shows the services that are stopped and restarted when the package is installed. More specifically, list-file gives the files that a package installs on your system. More generally, list-log shows which packages have been installed or removed.

Many of these information sub-commands are more useful to a network administrator than someone on a home system. All the same, a nodding familiarity with them can be handy if you run into serious problems and want some insight into what happened.