Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 226505 - [TRACKER] interactions with postinst phase order change in portage-2.1.5
Summary: [TRACKER] interactions with postinst phase order change in portage-2.1.5
Status: RESOLVED FIXED
Alias: None
Product: Portage Development
Classification: Unclassified
Component: Conceptual/Abstract Ideas (show other bugs)
Hardware: All All
: High normal (vote)
Assignee: Portage team
URL: http://archives.gentoo.org/gentoo-dev...
Whiteboard:
Keywords: Tracker
Depends on: 226419
Blocks: 216231 222721 231039 235020
  Show dependency tree
 
Reported: 2008-06-14 10:23 UTC by Zac Medico
Modified: 2010-07-01 14:43 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Zac Medico gentoo-dev 2008-06-14 10:23:49 UTC
Mark bugs as blockers of this bug if they are caused by the changes to ebuild phase execution order in >=portage-2.1.5. The the order for upgrade and downgrade operations has changed, but the order for reinstall operations has not. The new order for upgrades and downgrades is identical to the order used for reinstall operations:

pkg_preinst
pkg_prerm
pkg_postrm
pkg_postinst

Old versions of portage (less than 2.1.5) used a different order for upgrades and downgrades:

pkg_preinst
pkg_postinst
pkg_prerm
pkg_postrm

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.