These scripts should be the files preinst
, postinst
,
prerm
and postrm
in the control area of the package. They
must be proper exectuable files; if they are scripts (which is
recommended) they must start with the usual #!
convention. They
should be readable and executable to anyone, and not world-writeable.
dpkg looks at the exit status from these scripts. It is
important that they exit with a non-zero status if there is an error,
so that dpkg can stop its processing. For shell scripts this
means that you almost always need to use set -e
(this is
usually true when writing shell scripts, in fact). It is also
important, of course, that they don't exit with a non-zero status if
everything went well.
It is necessary for the error recovery procedures that the scripts be idempotent: ie, invoking the same script several times in the same situation should do no harm. If the first call failed, or aborted half way through for some reason, the second call should merely do the things that were left undone the first time, if any, and exit with a success status.
When a package is upgraded a combination of the scripts from the old and new packages is called in amongst the other steps of the upgrade procedure. If your scripts are going to be at all complicated you need to be aware of this, and may need to check the arguments to your scripts.
Broadly speaking the preinst is called before (a particular version of) a package is installed, and the postinst afterwards; the prerm before (a version of) a package is removed and the postrm afterwards.
install
install
old-versionupgrade
old-versionabort-upgrade
new-version
configure
most-recently-configured-versionabort-upgrade
new versionabort-remove
in-favour
package new-versionabort-deconfigure
in-favour
failed-install-package version
removing
conflicting-package version
remove
upgrade
new-versionfailed-upgrade
old-versionremove
in-favour
package new-versiondeconfigure
in-favour
package-being-installed version
removing
conflicting-package version
remove
purge
upgrade
new-versionfailed-upgrade
old-versionabort-install
abort-install
old-versionabort-upgrade
old-versiondisappear
overwriter new-versiondpkg --unpack
, or the unpack stage of dpkg
--install
) is as follows. In each case if an error occurs the
actions in are general run backwards - this means that the maintainer
scripts are run with different arguments in reverse order. These are
the `error unwind' calls listed below.
old-prerm upgrade new-version
new-prerm failed-upgrade old-versionError unwind, for both the above cases:
old-postinst abort-upgrade new-version
--auto-deconfigure
is specified, call, for each such package:
deconfigured's-prerm deconfigure \ in-favour package-being-installed version \ removing conflicting-package versionError unwind:
deconfigured's-postinst abort-deconfigure \ in-favour package-being-installed-but-failed version \ removing conflicting-package versionThe deconfigured packages are marked as requiring configuration, so that if
--install
is used they will be configured again if
possible.
conflictor's-prerm remove in-favour package new-versionError unwind:
conflictor's-postinst abort-remove \ in-favour package new-version
new-preinst upgrade old-version
new-preinst install old-version
new-preinst installError unwind versions, respectively:
new-postrm abort-upgrade old-version new-postrm abort-install old-version new-postrm abort-install
It is an error for a package to contains files which are on the system
in another package, unless Replaces
is used (see
Replaces
- overwriting files and replacing packages, section 8.5). Currently the --force-overwrite
flag is
enabled, downgrading it to a warning, but this may not always be the
case.
Packages which overwrite each other's files produce behaviour which though deterministic is hard for the system administrator to understand. It can easily lead to `missing' programs if, for example, a package is installed which overwrites a file from another package, and is then removed again.[14]
old-postrm upgrade new-version
new-postrm failed-upgrade old-versionError unwind, for both cases:
old-preinst abort-upgrade new-version
disappearer's-postrm disappear \ overwriter overwriter-version
dpkg --install
, or
with --configure
), we first update the conffiles and then call:
postinst configure most-recently-configured-version
No attempt is made to unwind after errors during configuration.
If there is no most recently configured version dpkg will pass a
null argument; older versions of dpkg may pass
<unknown>
(including the angle brackets) in this case.
Even older ones do not pass a second argument at all, under any
circumstances.
prerm remove
postrm remove
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.
~
-files, #*#
files,
%
-files, .dpkg-{old,new,tmp}
, etc.) are removed.
postrm purge