Translation(s): English - español - Français - Italiano - 한국어(Korean)
Background information about managing packages on a Debian system. For more information, see Package Management.
Contents
Debian packaging is like an app store that's desigend to make it easy for you to put other providers' apps in the store:
- App store
To install an officially-verified app, go to your store (e.g. Google Play or Apple's App Store) and tell it to install the app. The store will then download and install a file from its backend. The store will install new versions of the app whenever it thinks is convenient.
To install apps your store hasn't guaranteed, download the .apk or .ipa file manually from a website and sideload it. If you want new versions of sideloaded apps, set a reminder to manually check each page every so often. Or if you want to install a lot of apps, install an alternate store like F-Droid, and put up with looking for apps in two places.
- Debian
To install an officially-verified package, go to your package manager (e.g. synaptic or apt), and tell it to install the package. The package manager will then download and install a set of files from the Debian archive. By default, the package manager only installs new versions when you tell it to, or you can configure a schedule of your choosing.
To install packages Debian hasn't guaranteed, configure an extra repository (store backend), which your package manager will then treat exactly the same as the Debian archive. Or if you'd rather do it the hard way, you can download a .deb file, install it with dpkg, and keep manually checking for updates.
What are packages, anyway?
A package is like a zip file containing some software, a description for people to read, and instructions to (un)install it. Anyone can make a Debian-compatible package, but packages distributed by the Debian project are guaranteed to satisfy an extensive quality-assurance policy.
Packages are stored in repositories, which contain information about which versions of which packages are available. Anyone can make a Debian-compatible repository, but only Debian Developers can upload packages to Debian's official repository (the "Debian archive").
dpkg manages individual packages, e.g. unzipping them and running their installation instructions. Tools like apt and synaptic get packages from repositories and tell dpkg to do the low-level work.
Some Debian packages are created by Debian developers themselves - for example, dpkg is a Debian project. But most packages are maintained by some other group - for example, Firefox is developed by Mozilla, so Debian's Mozilla team just takes their work and makes it easy to use in a Debian environment. The people who make the software are often referred to as "upstream" of Debian, because work starts with them and flows down to the distribution.
Dependencies between packages
People who package software for Debian spend a lot of time thinking about the relationships between packages. This section covers some of the most common relationships, but see Declaring relationships between packages for the full list.
- depends
If package A depends on package B, that means A won't work unless B is installed. For example, a program written in Python needs Python to be installed before it can run.
- recommends
If package A recommends package B, that means most users of A will be happier if B is also installed, but you can uninstall it if you want to. For example, most players of The Battle for Wesnoth also want the Wesnoth music, but uninstalling it won't break the game.
- suggests
If package A suggests package B, that means some users of A might like to install B, but it shouldn't be included by default. For example, most people use bzip2 without reading the manual, but it's nice to know it's there.
- conflicts
If package A conflicts with package B, that means you can only install one or the other. For example, when Oracle bought MySQL, its original developers forked MariaDB but kept looking for plugins in /usr/lib/mysql. For this and other reasons, it's not safe to install both MySQL and MariaDB on the same machine.
There are many other types of dependency, like dependencies that only apply to speciific versions of a package, or only apply when building the package from source. For details, see Declaring relationships between packages.
Finding packages to install
Usually, you would find packages with a command like apt search <string> or apt-file search <filename>. If you need to do a more complicated search, package information is available from:
/var/lib/apt/lists/* - packages that can be downloaded from repositories
/var/lib/dpkg/available - packages currently available to dpkg
/var/lib/dpkg/status - status of installed and available packages
- whether a package is marked for removal or not, whether it is installed or not, etc.
a package marked reinst-required is broken and requires re-installation
/var/log/dpkg.log
- recent packaging activity
/var/log/apt/term.log
messages printed during recent runs of apt tools
You can also search online:
search for developer information about source packages
source packages usually have the same name as normal packages, but e.g. a pair of packages called foo-bin and foo-data might share a source package foo
Upgrading your system
Opinions differ about how often to upgrade a system, but most people recommend updating a stable system somewhere between once a week and once a month, or a testing/unstable system somewhere between once a day and once a week.
For information about upgrading to the next Debian release, see DebianUpgrade.
Safe- vs. full-upgrade
Upgrading packages is normally fairly simple - you have version 1.2, but version 1.3 just came out, so now you want the new version. But Debian's dependency system creates an important edge case:
- Imagine you installed a package a couple of years ago, which happened to depend on some little utility package. You didn't notice the utility at the time, then you found it last year and gradually came to use it every day. The new version of the original package no longer needs the utility package, so your package manager thinks your utility is redundant and can be safely removed.
Package managers provide two types of upgrade - a normal (or "safe") upgrade that never uninstalls packages, and a full upgrade that asks you to confirm the packages it's about to remove. If you don't want a package to be removed, you have a few choices:
use apt-mark to toggle packages between automatically installed (removable) and manually installed (required):
sudo apt-mark auto <package>
sudo apt-mark manual <package>
use pinning to always use a specific version of a package
- investigate why the dependency changed (maybe something better is available now)
if the packages actually conflict with each other, uninstall one package and make a note to see how the problem is resolved in future
Some people have reported a problem with updates that affect their login manager - the login manager restarts, which closes their session, which closes their terminal, which closes their package manager, which aborts the upgrade halfway through. Consider doing major updates using a command-line package manager in a screen or tmux session, which will continue running while you log back in. You can reconnect to the session when everything's back to normal.
Full upgrades are most useful when upgrading from one distribution to the next. Some package managers still refer to them as "dist" upgrades. For more information about upgrading distributions, see see the release notes.
Forcing removal of a package
Sometimes, you might find a situation where a package can't be fully installed, or can't be removed due to dependency issues. This is most likely to happen when upgrading to a new distribution, because some detail about your system turns out not to work with the new version.
To forcibly remove a package:
dpkg --force-all --remove <package>
See also
- this page used to be much longer, but most information has been moved to separate pages and linked from there