Bug 226505

Summary:	[TRACKER] interactions with postinst phase order change in portage-2.1.5
Product:	Portage Development	Reporter:	Zac Medico <zmedico>
Component:	Conceptual/Abstract Ideas	Assignee:	Portage team <dev-portage>
Status:	RESOLVED FIXED
Severity:	normal	CC:	pacho
Priority:	High	Keywords:	Tracker
Version:	2.1
Hardware:	All
OS:	All
URL:	http://archives.gentoo.org/gentoo-dev/msg_27feec8fc563e406b174386d24c39fdc.xml
Whiteboard:
Package list:		Runtime testing required:	---
Bug Depends on:	226419
Bug Blocks:	216231, 222721, 231039, 235020

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.