PMS claims in section "Call Order": "The call order for upgrading or downgrading a package is: * pkg_preinst * pkg_postinst * pkg_prerm for the package being replaced * pkg_postrm for the package being replaced" whereas in reality the call order in portage is the same as for reinstalling a package, namely preinst, prerm, postrm, postinst.
Created attachment 248342 [details, diff] proposed patch
Basically, this change reverts this commit: http://git.overlays.gentoo.org/gitweb/?p=proj/pms.git;a=commit;h=2d3de7abf5484c616e9bc3fe398669d9935dd62c
It's not as simple as you think. Different post-EAPI-time versions of Portage have different call orders. Paludis uses the original call order for old EAPIs, and the newer, changed-without-discussion-or-council-approval call order for newer EAPIs. PMS needs to reflect that both behaviours are possible.
*shrug* Portage and PMS disagreed, then *both* were changed, and now of course they still disagree, but the other way around. Maybe people should talk to each other before making such changes? ;-) "Note: When up- or downgrading a package in EAPI 0 or 1, the last four phase functions can alternatively be called in the order pkg_preinst, pkg_postinst, pkg_prerm, pkg_postrm. This behaviour is deprecated."
(In reply to comment #4) > > "Note: When up- or downgrading a package in EAPI 0 or 1, the last four phase > functions can alternatively be called in the order pkg_preinst, pkg_postinst, > pkg_prerm, pkg_postrm. This behaviour is deprecated." > Or just call the order undefined and everyone who relies on the order should use a newer EAPI.
(In reply to comment #5) > Or just call the order undefined and everyone who relies on the order should > use a newer EAPI. Why not have the specification as tight as possible, if that needs only one sentence? The main question is if a note with rather informal wording (as in comment #4) would be sufficient. Or do we need another EAPI dependent table for this?
Created attachment 250193 [details, diff] Updated patch No answer. So unless there are objections, I'll commit attached patch in a week from now.
(In reply to comment #7) > Created an attachment (id=250193) [details] > So unless there are objections, I'll commit attached patch in a week from now. Pushed to master.
