| 1 |
>>>>> On Thu, 11 Sep 2008, Zac Medico wrote: |
| 2 |
|
| 3 |
> I think it's worthwhile to have consistent phase ordering across all |
| 4 |
> EAPIs. Consider an upgrade from EAPI 0 to EAPI 2. If the phase order |
| 5 |
> is consistent across all EAPIs, as implemented in |
| 6 |
> >=sys-apps/portage-2.1.5, then the order of phase execution order is |
| 7 |
> uniform and unambiguous: |
| 8 |
|
| 9 |
> Upgrade from EAPI 0 to EAPI 2 |
| 10 |
|
| 11 |
> pkg_preinst (EAPI 2) |
| 12 |
> pkg_prerm (EAPI 0) |
| 13 |
> pkg_postinst (EAPI 0) |
| 14 |
|
| 15 |
This should read "pkg_postrm" I think? |
| 16 |
|
| 17 |
> pkg_postinst (EAPI 2) |
| 18 |
|
| 19 |
> [...] |
| 20 |
|
| 21 |
> Given that the phase order used in <sys-apps/portage-2.1.5 varies |
| 22 |
> depending on whether or not the new and old version are identical |
| 23 |
> [1], I consider the uniformity introduced by the new phase order to |
| 24 |
> be a change that is well worth keeping. Given the small number of |
| 25 |
> problems that have been discovered in practice, tracked by bug |
| 26 |
> 226505 [3], I believe that the potential problems have proven to be |
| 27 |
> negligible. |
| 28 |
|
| 29 |
+1 |
| 30 |
|
| 31 |
In some situations involving eclasses, the new phase order avoids some |
| 32 |
problems. pkg_postrm may call a function of an eclass saved with the |
| 33 |
old package in the VDB, and it may have advantages if you can clean up |
| 34 |
things in pkg_postinst of the new version. |
| 35 |
|
| 36 |
For example, the Emacs team had quite some headache due to pkg_postrm |
| 37 |
running after pkg_postinst, leading to complicated code in the present |
| 38 |
version of elisp-common.eclass. This wouldn't have been necessary if |
| 39 |
the new phase order already was in effect at that time. See ref. [4] |
| 40 |
for further details. |
| 41 |
|
| 42 |
Ulrich |
| 43 |
|
| 44 |
[4] http://bugs.gentoo.org/show_bug.cgi?id=210764#c3 |
Archives