6.5. Summary of ways maintainer scripts are called

What follows is a summary of all the ways in which maintainer scripts may be called along with what facilities those scripts may rely on being available at that time. Script names preceded by new- are the scripts from the new version of a package being installed, upgraded to, or downgraded to. Script names preceded by old- are the scripts from the old version of a package that is being upgraded from or downgraded from.

The preinst script may be called in the following ways:

new-preinst install

new-preinst install old-version

new-preinst upgrade old-version

The package will not yet be unpacked, so the preinst script cannot rely on any files included in its package. Only essential packages and pre-dependencies (Pre-Depends) may be assumed to be available. Pre-dependencies will have been configured at least once, but at the time the preinst is called they may only be in an “Unpacked” or “Half-Configured” state if a previous version of the pre-dependency was completely configured and has not been removed since then.

old-preinst abort-upgrade new-version

Called during error handling of an upgrade that failed after unpacking the new package because the postrm upgrade action failed. The unpacked files may be partly from the new version or partly missing, so the script cannot rely on files included in the package. Package dependencies may not be available. Pre-dependencies will be at least “Unpacked” following the same rules as above, except they may be only “Half-Installed” if an upgrade of the pre-dependency failed. 2

The postinst script may be called in the following ways:

postinst configure most-recently-configured-version

The files contained in the package will be unpacked. All package dependencies will at least be “Unpacked”. If there are no circular dependencies involved, all package dependencies will be configured. For behavior in the case of circular dependencies, see the discussion in Binary Dependencies - Depends, Recommends, Suggests, Enhances, Pre-Depends.

old-postinst abort-upgrade new-version

conflictor's-postinst abort-remove in-favour package new-version

postinst abort-remove

deconfigured's-postinst abort-deconfigure in-favour failed-install-package version [ removing conflicting-package version ]

The files contained in the package will be unpacked. All package dependencies will at least be “Half-Installed” and will have previously been configured and not removed. However, dependencies may not be configured or even fully unpacked in some error situations. 3 The postinst should still attempt any actions for which its dependencies are required, since they will normally be available, but consider the correct error handling approach if those actions fail. Aborting the postinst action if commands or facilities from the package dependencies are not available is often the best approach.

The prerm script may be called in the following ways:

prerm remove

old-prerm upgrade new-version

conflictor's-prerm remove in-favour package new-version

deconfigured's-prerm deconfigure in-favour package-being-installed version [removing conflicting-package version]

The package whose prerm is being called will be at least “Half-Installed”. All package dependencies will at least be “Half-Installed” and will have previously been configured and not removed. If there was no error, all dependencies will at least be “Unpacked”, but these actions may be called in various error states where dependencies are only “Half-Installed” due to a partial upgrade.

new-prerm failed-upgrade old-version

Called during error handling when prerm upgrade fails. The new package will not yet be unpacked, and all the same constraints as for preinst upgrade apply.

The postrm script may be called in the following ways:

postrm remove

postrm purge

old-postrm upgrade new-version

disappearer's-postrm disappear overwriter overwriter-version

The postrm script is called after the package’s files have been removed or replaced. The package whose postrm is being called may have previously been deconfigured and only be “Unpacked”, at which point subsequent package changes do not consider its dependencies. Therefore, all postrm actions may only rely on essential packages and must gracefully skip any actions that require the package’s dependencies if those dependencies are unavailable. 4

new-postrm failed-upgrade old-version

Called when the old postrm upgrade action fails. The new package will be unpacked, but only essential packages and pre-dependencies can be relied on. Pre-dependencies will either be configured or will be “Unpacked” or “Half-Configured” but previously had been configured and was never removed.

new-postrm abort-install

new-postrm abort-install old-version

new-postrm abort-upgrade old-version

Called before unpacking the new package as part of the error handling of preinst failures. May assume the same state as preinst can assume.