6.8. Details of removal and/or configuration purging

    1. prerm remove

    If prerm fails during replacement due to conflict

    1. conflictor's-postinst abort-remove \
    2. in-favour package new-version

    Or else we call:

    1. postinst abort-remove

    If this fails, the package is in a “Half-Configured” state, or else it remains “Installed”.

  1. The package’s files are removed (except conffiles).

    1. postrm remove

    If it fails, there’s no error unwind, and the package is in an “Half-Installed” state.

  2. All the maintainer scripts except the postrm are removed.

    If we aren’t purging the package we stop here. Note that packages which have no postrm and no conffiles are automatically purged when removed, as there is no difference except for the dpkg status.

  3. The conffiles and any backup files (~-files, #*# files, %-files, .dpkg-{old,new,tmp}, etc.) are removed.

    1. postrm purge

    If this fails, the package remains in a “Config-Files” state.

  4. The package’s file list is removed.

1

This is so that if an error occurs, the user interrupts dpkg or some other unforeseen circumstance happens you don’t leave the user with a badly-broken package when dpkg attempts to repeat the action.

2

This can happen if the new version of the package no longer pre-depends on a package that had been partially upgraded.

3

For example, suppose packages foo and bar are “Installed” with foo depending on bar. If an upgrade of bar were started and then aborted, and then an attempt to remove foo failed because its prerm script failed, foo’s postinst abort-remove would be called with bar only “Half-Installed”.

4

This is often done by checking whether the command or facility the postrm intends to call is available before calling it. For example:

  1. if [ "$1" = purge ] && [ -e /usr/share/debconf/confmodule ]; then
  2. . /usr/share/debconf/confmodule db_purge
  3. fi

in postrm purges the debconf configuration for the package if debconf is installed.

5

See Maintainer script flowcharts for flowcharts illustrating the processes described here.

6

Part of the problem is due to what is arguably a bug in dpkg.

7

Historical note: Truly ancient (pre-1997) versions of dpkg passed <unknown> (including the angle brackets) in this case. Even older ones did not pass a second argument at all, under any circumstance. Note that upgrades using such an old dpkg version are unlikely to work for other reasons, even if this old argument behavior is handled by your postinst script.