Survival Guide to DPKG and APT

I often work with the Debain package management tools at the command line for a variety of reasons. There is quite a large assortment of them. In this article I've laid out the commands that I use on a regular basis to manage the software on my Debian, Devuan, Ubuntu, ... systems.

*.deb files are a two level archive file format that Debian packages software in to. See "man 5 deb". This package format contains binaries, docs, data, ... and some meta data like: name, description, where the source came from, conflicts, dependencies and other packages that can enhance its capabilities. Any software you install via the tools like "apt-get" or "Synaptic" use these files under the hood.

Commands (NOTE: commands that actually alter the system require "root" to run, ie "sudo", "su" or login as root):

• dpkg -i {file name}
  (requires root) Install the specified .deb file into the system or replace the existing version, if its already installed. This process could complain about maintainer script issues or missing dependencies (see next command). It will also prevent the install if the package will break something already installed.
   
• apt-get install -f
  (requires root) This will attempt to find a solution to fix a broken package install. It will present a solution and give you the option to proceed or not. Example: the "psbasic" package uses (needs) the "curses" library to know how to manipulate the terminal. If the curses libraries or correct versions aren't installed the "dpkg -i" command above will complain and leave the package only partly installed (what it calls "unconfigured"). This command will reach out to the OS' package servers and/or your install media and install the missing dependencies. Or, if it can't find a match for the dependencies, it will recommend uninstalling "psbasic".
   
• apt-get install {package name} [[{package name}] ...]
  (requires root) This will search the OS install media and/or the network repositories for the package(s) named on the CLI and any packages that they require. When found they will all be installed as requested. IF the listed packages need anything not specifically listed on the CLI then it will prompt you to OK the action
   
• apt-get clean
  (requires root) "apt-get" has an odd habit of keeping all of the .deb files (packages) it downloads after the package has been installed. These are kept in the "/var/cache/apt/archives" directory. This can be a lot of wasted disk space. This command deletes those files.
   
• dpkg -P {package name} [[{package name}] ...]
  dpkg -r {package name} [[{package name}] ...]
  (requires root) This removes / uninstalls package(s) from your system. The "-P" is a "purge" operation that will remove "configuration" files, typically those in "/etc". The "-r" "removes" the package(s) leaving the config files behind. This is helpful if you plan on re-installing the package later like for an upgrade/downgrade. I use the "purge" (-P) operation 99.99% of the time.
  
  NOTE: If the removing the packages would break something dpkg will refuse to proceed. You can "--force" it, but 99.99999% of the time this will likely cause critical damage. Trust the system! Example: you installed "psbasic". It required the "libtinfo" (curses) package to run. You attempt to uninstall "libtinfo". "dpkg" complains its needed. You "--force" it and later attempt to run "psb". It dies complaining of a missing library.
   
• apt-get remove {package name} [[{package name}] ...]
  (requires root) This will remove package(s) and everything that depends on them. If more than the specified packages would need to be removed you are provided the option to "abort". This is like a recursive uninstall. I almost always avoid this command. Using the running example: you installed "psbasic", which installed "libtinfo". You can "apt-get remove libtinfo" and it will tell you it needs to remove "psbasic" also. You say "y" and both packages get removed.
   
• apt-get autoremove
  (requires root) This removes all installed packages that are no longer required. This should be run after you remove some package(s). You will be given the chance to OK the suggested list of removals. Example: you install "psbasic", it requires the curses packages (libncurses, libtinfo, ...). You decide to uninstall "psbasic" and nothing else on the system requires the curses packages. This will remove them. Since many programs require libraries this is a good way to free up disk space when you uninstall programs.
   
• dpkg -l [wild card pattern]
  This lists locally known packages. The "locally known" concept is a bit odd. It includes things like: packages that are currently installed, packages that are referenced by other packages whether or not they are installed and packages that had been installed but have been removed. The wild card pattern is the same kind used by most file system tools (ls, rm , cp, ...). Its not a regular expression. Leaving the pattern off will list everything. :-D
   
• dpkg -L {package name}
  This will list every installed file from a package. This is one of the many advantages of what I call "real software management". This is an incredibly helpful tool to know what a package has done. Example: you installed "psbasic" then type "psbasic" at the command line and get a "not found" error. What?!?! "dpkg -L psbasic | grep bin/" will show you all things installed by psbasic in the typical executable directories. In theory you might get a few extras but in reality I've not seen it happen. That "grep" part of the command will list everything that was installed to a directory who's name ends in "bin". That would include "/usr/bin", "/sbin", .... Example: "dpkg -L psbasic | grep bin/" will return two entries:" /usr/bin/psb" & " /usr/bin/renum2"
   
• dpkg -S {file name}
  This will list all packages that contain a file named {file name}. This is normally most useful when a full path name is specified since it will limit it to one specific file, returning one package name. Since this is "real software management" no two packages can install the exact same file (conflict). Example: You discover this weird executable "/usr/bin/psb" and have no idea where it came from. :-D "dpkg -S /usr/bin/psb" will show you its from the "psbasic" package and the next command will explain further.
   
• dpkg -s {package name}
  This shows the package meta data for {package name}. There is a lot more to the meta data then you might imagine. The most useful bits of information are: short description, long description, project home page, version and dependencies.
   
• apt-cache search [--names-only] {regex}
  This will search the cache of packages known by "apt-get". You specify what your searching for with a "regular expression" (regex). This will search not only package names but the short and long descriptions of the packages. The "--names-only" switch will limit the search to the actual package name and the short description. Example: You want to know what versions of BASIC are available to install? "apt-cache search --names-only basic" would return a list of potential packages. But it would also match "my very basic chat client". ;-)
   
• apt-cache show {package name}
  This is like "dpkg -s" for packages that may not be installed. It shows the meta data for any package that "apt-get" can find to install.
   
• apt-cache showpkg {package name}
  This is a more technical view of a package. This will list all of the versions of a package available to "apt-get install" and their source repository (in a round about way). The output can be a bit daunting and this should definitely be considered an advanced command. But there are times its very handy indeed.

NOTE "apt-get" vs. "apt": I wrote this list using the "apt-get" command. There is the shorter, new comer "apt" command, which seems to be a fancificated wrapper around "apt-get". It adds things like colors and progress indicators. As far as I know you can substitute "apt" for "apt-get" and visa-versa. I use "apt-get" because I know it works.

Other front ends for the package system are:

• aptitude: this is a terminal (curses based) front end for the dpkg* & apt-* suite of tools. I find it barely usable. If I'm confused by its output I can only imagine how a novice would feel.
   
• synaptic: This is the GUI front end for the package management tool suite.  I used to swear by it, now I swear at it. After Debian 5 (somewhere around Ubuntu 08.x) this tool slid into the toilet. Without ranting too much: I kept running into situations where it either refused to install packages or it wanted to remove large swaths of my installed software. In every case dropping to a terminal and typing "apt-get install ..." performed the requested action with zero issues. In short synaptic forced me to find and learn a great deal about the available CLI tools. This horrible eroding of a once great tool is one big reason I don't trust "apt" (not get).
   
• There are many other tools, with varying degrees of maturity and reliability, kicking around out there.

This list of commands and front ends is not exhaustive by any stretch of the imagination. It doesn't even scratch the surface of the options available for the commands shown. The list is essentially a recipe book for common package management tasks. If you want to learn more check the man pages and follow the "see also" commands listed in them.

That should help get you started working with Debian packages! :-D