Package dependency problems may occur when upgrading in
unstable/testing . Most of the time, this is because a package
that will be upgraded has a new dependency that isn't met. These
problems are fixed by using

# apt-get dist-upgrade

If this does not work, then repeat one of the following until
the problem resolves itself:

# apt-get upgrade -f # continue upgrade even after
error

... or

# apt-get dist-upgrade -f # continue dist-upgrade even
after error

Some really broken upgrade scripts may cause persistent trouble.
It is usually better to resolve this type of situation by
inspecting the /var/lib/dpkg/info/packagename.{post,pre}{inst,rm}
scripts of the offending package and then running:

# dpkg --configure -a # configures all partially
installed packages

If a script complains about a missing configuration file, look
in /etc/ for the corresponding configuration file. If one exists
with an extension of .new (or something similar), change (mv) it
to remove the suffix.

Package dependency problems may occur when installing in
unstable/testing. There are ways to circumvent dependency.

# apt-get install -f package # override broken dependencies

An alternative method to fix these situations is to use the
equivs package. See /usr/share/doc/equivs/README.Debian and
The equivs package,

Rescue using dpkg

Ad hoc recovery of a crashed dselect (APT) can be done on a
really broken system by just using dpkg without APT:

If /var/lib/dpkg/status becomes broken for any reason, the
Debian system loses package selection data and suffers severely.
Look for the old /var/lib/dpkg/status file at /var/lib/dpkg/status-old
or /var/backups/dpkg.status.*.

Keeping /var/backups/ in a separate partition may be a good idea
since this directory contains lots of important system data.

If the old /var/lib/dpkg/status file is not available, you can
still recover information from directories in /usr/share/doc/.

Since the /var directory contains regularly updated data such as
mail, it is prone to be corrupted. Separating it in an
independent partition limits risks. If disaster happens, you may
have to rebuild the /var directory to rescue your Debian system.

Obtain the skeleton content of the /var directory from a minimum
working Debian system based on the same or older Debian version,
for example var.tar.gz, and place it in the root directory of
the broken system. Then

Boot into Linux using a Debian rescue floppy/CD or an
alternative partition in a multiboot Linux system. . Mount the
unbootable system on /target and use the chroot install mode of
dpkg.

# dpkg --root /target -i packagefile.deb

Then configure and fix problems.

By the way, if a broken lilo is all that prevents booting, you
can boot using a standard Debian rescue disk. At boot prompt,
assuming the root partition of your Linux installation is in
/dev/hda12 and you want runlevel 3, enter:

boot: rescue root=/dev/hda12 3

Then you are booted into an almost fully functional system with
the kernel on floppy disk. (There may be minor glitches due to
lack of kernel features or modules.)

What to do if the dpkg command is
broken

A broken dpkg may make it impossible to install any .deb files.
A procedure like the following will help you recover from this
situation. (In the first line, you can replace "links" with your
favorite browser command.)