Overriding dpkg’s sanity and policy checks

Purging configuration files for postfix ...

˜$ dpkg --list postfix [...]

pn postfix <none> (no description available)

Note the state of the package: pn, which indicates that the package is actually purged, but also that the package database has an entry for the package. Therefore, pn specifies thatpostfixwas previously installed and the package management database has seen it and

1. All remaining files are unlinked (removed from the system).

2. If it exists, thepostrmscript is run.

3. The two remaining files,postfix.postrmandpostfix.filesare unlinked from /var/lib/dpkg/info.

4. dpkgmarks the packages as non-installed in the package management data-base (see chapter 5.3.4).

For mass removals, an administrator may also resort to the selection interface of dpkgand register deinstallation and purge requests before tellingdpkgto enact them:

˜# echo postfix deinstall | dpkg --set-selections

˜# dpkg --remove --pending [...]

Removing postfix ...

˜# echo postfix purge | dpkg --set-selections

˜# dpkg --purge --pending [...]

Removing postfix ...

Purging configuration files for postfix ...

5.3.6 Overriding dpkg’s sanity and policy checks

dpkgenforces the Debian policy (see chapter 5.7) wherever and whenever it can.

It refuses to overwrite files belonging to other packages, it preserves configuration files, it prevents the removal of essential packages which are needed to provide core functionality of the system, it refuses to install packages when the dependency relations are not satisfied, . . . The list goes on and on, anddpkg would not be a versatile tool if these checks could not be individually overridden. Overriding dpkg’s rules is called “forcing” in Debian speak.

It goes without saying that forcing is to be used with care. Lowrey’s Law (a subsec-tion of Murphy’s Law¹⁰) states “if it jams, force it; if it breaks, it needed replacement anyway.” Fortunately, the Debian package management tools do not abide by this law. The Debian package database is designed to be robust, and the tools have been carefully crafted to leave the database in a consistent state no matter how they are called, or do whatever they do, or fail. When a user employs forcing, that user is explicitly telling the package management tools to put the system into an inconsistent state. dpkg’s forcing method is an acknowledgement that at times, the system must be rendered (temporarily) inconsistent. For instance, third party software may be uninstallable otherwise, or the current state of Debian unsta-blemay be inconsistent internally, and thus unusable in the wake ofdpkg’s strict rules. Nevertheless, the best recipe to destroy a Debian system is to employ forcing without care. Use forcing only when you have no alternative, and try to keep an overview (or better yet, a written account) of what you have forced.

Thedpkg (8)manpage lists all the available forcing methods. The following are the most commonly used ones:

--force-depends

This switch causesdpkgto ignorealldependency declarations during the execution of the requested action. The removal or the installation of a pack-age with this option has grave implications for future interactions with the package database. For instance, forcing the removal ofvim-common (de-spite the dependency of thevimpackage) prevents further installations of unrelated packages, in this casemc:

˜# dpkg --remove --force-depends vim-common

dpkg: vim-common: dependency problems, but removing anyway as you request:

vim depends on vim-common (>> 1:6.2).

[...]

Removing vim-common ...

˜# apt-get install mc [...]

You might want to run "apt-get --fix-broken install# to correct these:

The following packages have unmet dependencies:

vim: Depends: vim-common (> 1:6.2) but it is not going to be installed

E: Unmet dependencies. Try "apt-get --fix-broken install# with no packages (or specify a solution).

The package database is now in an inconsistent state and even though it knows about the source of the problem,dpkgcannot continue to service the user’s request until the problem is fixed. In chapter 5.3.7, I will be introducing methods to handle situations like this more gracefully.

10http://www.murphys-laws.com

It may be better to ignore the dependencies only for a single package. For this purpose, dpkg provides the --ignore-depends=<package> option (which may be given multiple times). With the option, it is possible to forcecfully override the dependencies of the specified package. However, dependency relationships of other packages continue to be protected by dpkgduring the same operation. Thus, the following allowsdpkg to re-movenetkit-inetdbut prevents the removal ofadduser(do not try this at home):

˜# dpkg --purge --ignore-depends=netkit-inetd netkit-inetd adduser [...]

Purging configuration files for netkit-inetd ...

dpkg: dependency problems prevent removal of adduser:

ssh depends on adduser (>= 3.9).

[...]

Furthermore, if only the version of a versioned dependency must be overrid-den,--force-depends-versionis a better choice.

--force-overwrite

With this switch,dpkgis allowed to overwrite files belonging to another package. This may be necessary with incompatible packages that have no conflict declared between them. This can easily happen when the DEB files are obtained from unofficial sources. In addition, fluctuations inunstable may sometimes call for this switch:

˜# dpkg --install coreutils_5.0.91-2_i386.deb [...]

Unpacking replacement coreutils ...

dpkg: error processing coreutils_5.0.91-2_i386.deb (--install):

trying to overwrite ‘/bin/chgrp’, which is also in package fileutils

dpkg-deb: subprocess paste killed by signal (Broken pipe) Errors were encountered while processing:

coreutils_5.0.91-2_i386.deb

˜# dpkg --install --force-overwrite coreutils_5.0.91-2_i386.deb [...]

Unpacking replacement coreutils ...

dpkg - warning, overriding problem because --force enabled:

trying to overwrite ‘/bin/chgrp’, which is also in package fileutils

Setting up coreutils (5.0.91-2) ...

From the viewpoint of the package management tools,/bin/chgrpis now owned bycoreutils, nor byfileutils. Thus ownership has changed. In cer-tain situations, this can have severe consequences.coreutilsis an essential package and therefore its removal is highly unlikely. But assuming we were talking about another package and removedcoreutils,dpkgwould unlink

/bin/chgrp. fileutilsis still installed, but its footprint is now incomplete — and the package management tools have no way to know that. If the func-tionality offileutils depended on/bin/chgrp, the package would be ren-dered unusable by removing a different package. Obviously, such situations are extremely rare, but it is important to understand the implications of the --force-overwriteswitch.

Please refer to chapter 5.3.7 for information on how to handle this kind of scenario.

--force-hold

If this option is given,dpkgwill override the request to hold a package and process it anyhow.

--force-conflicts

This option allows dpkgto ignore Conflictsdeclarations and install con-flicting packages anyhow. This usually requires --force-overwrite and is generally a good way to shoot yourself in the foot.