Dealing with errors in packages

At times, packages may fail to install due to unsatisfied dependencies or existing conflicts, files that would be overwritten, or erroneous control scripts. Problems like this should never occur in thestablerelease (and will be treated asgravebugs).

However, on a system runningunstable, this kind of problem can happen.

Depending on the source of the problem, different techniques must be employed to restore proper operations. In all cases, it is important to remember thatdpkg notes any problems and remains robust in the face of inconsistencies. Moreover, dpkgremembers the desired action and attempts to enact it over and over again, until it finally succeeds. At the same time, actions unrelated to the problematic packages are not affected.

Correcting dependency problems

In the following example, the administrator attempts the installation ofpostfix, but the dependent packagenetbaseis not installed. dpkgregisters the desire to installpostfixbut cannot fulfill it untilnetbaseis installed.

˜# dpkg --install /var/cache/apt/archives/postfix_2.1.5-1_i386.deb dpkg: dependency problems prevent configuration of postfix:

postfix depends on netbase; however:

Package netbase is not installed.

˜# dpkg --info postfix

iU postfix 2.1.5-1 A high-performance mail transport agent

While thenetbaseis in a broken state,dpkglets the administrator work on other packages. For instance,apache2can be installed and purged without problems:

˜# dpkg --install /var/cache/apt/archives/apache2_2.0.52-3_i386.deb [...]

Unpacking apache2 (from .../apache2_2.0.52-3_i386.deb) ...

Setting up apache2 (2.0.52-3) ...

˜# dpkg --purge apache2 Removing apache2 ...

The dependency problem relating topostfixcan be resolved at any point in time, either by installing the dependentnetbasepackage and askingdpkgto configure postfix, or by removingpostfix.

Sincedpkgremembers the administrator’s request to installpostfix, it will retry and automatically complete the installation as soon as the dependencies are fulfilled:

˜# dpkg --install /var/cache/apt/archives/netbase_4.19_all.deb [...]

˜# dpkg --configure postfix [...]

At times, you may want to use software installede.g.below/usr/localto satisfy dependencies in existing software. For instance, you may need a special version of libsasl2for use withpostfix. Rather than forcingdpkgto ignore the dependen-cies, it is better to employ special tools that are designed to convince the package management system to regard a specific dependency as fulfilled (e.g.using the equivsorcheckinstallpackages, introduced in chapter 5.10.3 and chapter 5.10.2 respectively).

Dealing with file conflicts

dpkg will not let a package overwrite files that belong to another package. As we saw in chapter 5.3.6, it is possible to forcedpkgto overwrite files in another package, but the use of this feature is highly discouraged. If the problem seems to be of a temporary nature (as is frequently the case withunstable), overwriting may be fine. Please consider filing a bug against both packages to make sure that the maintainers know about the problem (see chapter 10.6).

However, if the problem is persistent because you need to install DEB files from external sources, or DEB files build withalien(see chapter 5.10.1), then a bug report will not help. Of course, the packager of the external DEB file should be informed, but a fixed version may take forever to appear. In such a case, it is possible to tell dpkgto use a different name for the file in one package in favour of the file in another. For instance, iffootries to install/usr/bin/foobar, which is also inbar, and you want to usefoo’s version of the file, you can telldpkgto divert all other versions to a different filename:

˜# dpkg-divert --package foo --rename \ --divert /usr/bin/foobar.bar /usr/bin/foobar

Adding ’diversion of /usr/bin/foobar to /usr/bin/foobar.bar by foo’

Now,fooandbarcan coexist, but/usr/bin/foobarisfoo’s version. Ifbaris updated, dpkgautomatically installs the new/usr/bin/foobarfile to/usr/bin/foobar.bar in-stead. The--renameoption causesdpkgnot only to register the diversion, but also to immediately rename the file on the filesystem.

For more information on diversions, please refer to chapter 6.1.3.

Dealing with broken control scripts during installation

Broken maintainer scripts are another cause of problems. Ife.g.a package’spostinst control file contains an error, the package cannot be configured completely by dpkg. For instance, in the following (simulated) case, thenetbase postinstscript fails and prevents the installation of the package:

˜# dpkg --install /var/cache/apt/archives/netbase_4.19_all.deb [...]

Setting up netbase (4.19) ...

[...]

dpkg: error processing netbase (--configure):

subprocess post-installation script returned error exit status 1 Errors were encountered while processing:

netbase

E: Sub-process /usr/bin/dpkg returned an error code (1) ...]

Such an error should definitely be reported to the bug tracking system with agrave severity (see chapter 10.6). To help diagnose the problem, it may be useful to trace the execution of the offending script. In the case of a shell script, you can simply insertset -xright after the first line (1atellssedto append a line to the first line of the file):

˜# sed -i -e ’1aset -x’ /var/lib/dpkg/info/netbase.postinst

postinstscripts may also be written inPerl. Unfortunately,Perldoes not provide a similar means to trace the execution of the script. Instead, you can use the in-teractive debugger by appending the-doption to the first line of the script (in which thePerlinterpreter is identified). This will invoke thePerldebugger when thepostinstscript is run the next time. The debugger is documented in the perlde-bug (1)manpage. Inperldebtut (1), a beginner’s tutorial is available.

You are free to modify thepostinstscript in an attempt to correct any errors, but please exercise care when doing so; the script is executed asroot! If you do find the

problem and possibly even fix it, please provide all necessary information (or even a patch) in the bug report. Alternatively, you may opt to force the script to exit successfully by letting it executeexit 0in the right place, and then try to configure the package manually. The same holds for the preinstallation script.

Unless you need the package, maybe the best idea is to purge or remove the pack-age and wait for an updated version to be provided in response to your bug report.

You can remove packages with broken installation scripts as you would remove any other package.

Dealing with broken control scripts during deinstallation

The option to deinstall a package with broken control scripts does not really exist when a package’s removal scripts are the ones causing problems. Even though you could force the removal by causing the offending control script to exit cleanly, this would preventdpkgfrom cleaning up your system properly, potentially leaving or-phaned files behind. Short of fixing the problem (and submitting a patch to the bug tracking system), it is probably best to report the problem (see chapter 10.6) and wait for an updated, fixed version to percolate into the archive. Then, the package may be removed as it should. This only holds for thepostrmscript, however. If the prermscript is broken, you will have to simulate its successful completion to make the upgrade to the next package version work.