Table of Contents
Ebuild execution is divided into a series of phases. In order to implement a phase, an ebuild defines a function to serve as an entry point for execution of that phase. This design is similar to the template method pattern that is commonly used in object oriented programming languages. An ebuild can inherit or override a template method from an eclass.
The function names for the ebuild phases, listed in order of execution:
pkg_pretend
pkg_setup
src_unpack
src_prepare
src_configure
src_compile
src_test
src_install
pkg_preinst
pkg_postinst
pkg_prerm
pkg_postrm
The order for upgrade and downgrade operations changed in version 2.1.5, but the order for reinstall operations remained unchanged.
pkg_preinst
pkg_postinst
pkg_prerm
pkg_postrm
The new order for upgrades and downgrades is identical to the order used for reinstall operations:
pkg_preinst
pkg_prerm
pkg_postrm
pkg_postinst
Now that pkg_postinst is called after all other phases, it's not possible to call has_version in pkg_postinst to detect whether the current install operation is an upgrade or downgrade. If this information is needed during the pkg_postinst phase, do the has_version call in an earlier phase (such as pkg_preinst) and store the result in a global variable to be accessed by pkg_postinst when it is called.