(debian-policy.info)Summary of ways maintainer scripts are called
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. (1)
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 Note: 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. (2) 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. (3)
‘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.
---------- Footnotes ----------
(1) This can happen if the new version of the package no longer
pre-depends on a package that had been partially upgraded.
(2) 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”.
(3) This is often done by checking whether the command or facility
the ‘postrm’ intends to call is available before calling it. For
example:
if [ "$1" = purge ] && [ -e /usr/share/debconf/confmodule ]; then
. /usr/share/debconf/confmodule db_purge
fi
in ‘postrm’ purges the ‘debconf’ configuration for the package if
debconf is installed.
automatically generated by info2www version 1.2.2.9