| 1 |
-----BEGIN PGP SIGNED MESSAGE----- |
| 2 |
Hash: SHA1 |
| 3 |
|
| 4 |
Ciaran McCreesh wrote: |
| 5 |
> On Wed, 10 Sep 2008 23:43:54 -0700 |
| 6 |
> Zac Medico <zmedico@g.o> wrote: |
| 7 |
>> [2] http://dev.gentoo.org/~zmedico/portage/eapi/eapi-2-draft.html |
| 8 |
> |
| 9 |
> By table 6.11, are you implying that you consider the new pkg_ phase |
| 10 |
> order to be part of EAPI 2? |
| 11 |
|
| 12 |
No, I consider the phase order change [1] to be outside the scope of |
| 13 |
EAPI. |
| 14 |
|
| 15 |
> Really, Portage needs to revert the order and go back to the way it |
| 16 |
> used to be for all EAPIs. The change breaks lots of existing ebuilds |
| 17 |
> (you claim you've probably fixed everything in ::gentoo, but you don't |
| 18 |
> know that and you've definitely not fixed overlays), including ebuilds |
| 19 |
> using a common documented technique recommended by the devmanual. |
| 20 |
|
| 21 |
The breakage to ebuilds, if they are broken in any way, seems to be |
| 22 |
non-critical in the vast majority of cases since the new phase order |
| 23 |
is identical to the phase order that portage has always used when |
| 24 |
replacing a given ebuild with another ebuild of the same version [1]. |
| 25 |
|
| 26 |
I consider the use of has_version calls in pkg_postinst to detect |
| 27 |
the previous installed version of a package, as suggested in |
| 28 |
devmanual [2], to be an illogical or counter-intuitive approach. The |
| 29 |
counter-intuitive nature of the approach explains why it was only |
| 30 |
used in a small fraction of the ebuilds in the tree. Ebuilds that |
| 31 |
used this approach were easily fixed by moving the has_version calls |
| 32 |
to pkg_preinst and storing the results in environment variables. |
| 33 |
|
| 34 |
When moving has_version calls from pkg_postinst to pkg_preinst for |
| 35 |
all ebuilds in the tree, I noticed that the calls were typically |
| 36 |
used to trigger einfo or ewarn messages. So, the majority of such |
| 37 |
breakage simply resulted in failure to generate einfo or ewarn |
| 38 |
messages in some upgrade or downgrade scenarious. |
| 39 |
|
| 40 |
> If you want the new pkg_* ordering to go through at all, it really |
| 41 |
> needs a lengthy discussion on its own and it mustn't apply to any |
| 42 |
> action that involves any existing EAPI. |
| 43 |
|
| 44 |
I think it's worthwhile to have consistent phase ordering across all |
| 45 |
EAPIs. Consider an upgrade from EAPI 0 to EAPI 2. If the phase order |
| 46 |
is consistent across all EAPIs, as implemented in |
| 47 |
>=sys-apps/portage-2.1.5, then the order of phase execution order is |
| 48 |
uniform and unambiguous: |
| 49 |
|
| 50 |
Upgrade from EAPI 0 to EAPI 2 |
| 51 |
|
| 52 |
pkg_preinst (EAPI 2) |
| 53 |
pkg_prerm (EAPI 0) |
| 54 |
pkg_postinst (EAPI 0) |
| 55 |
pkg_postinst (EAPI 2) |
| 56 |
|
| 57 |
If the phase order varies from one EAPI to another, as you suggest, |
| 58 |
then it seems like the phase order will not be uniform and the |
| 59 |
logical order will be ambiguous in some cases since it will depend |
| 60 |
upon both the EAPI of the original ebuild and the EAPI of the ebuild |
| 61 |
that will replace it: |
| 62 |
|
| 63 |
Upgrade from EAPI 0 to EAPI 2 (maybe ambiguous): |
| 64 |
|
| 65 |
pkg_preinst (EAPI 2) |
| 66 |
pkg_postinst (EAPI 2) |
| 67 |
pkg_prerm (EAPI 0) |
| 68 |
pkg_postrm (EAPI 0) |
| 69 |
|
| 70 |
Downgrade from EAPI 0 to EAPI 2 (certainly ambiguous): |
| 71 |
|
| 72 |
One conceivable order: |
| 73 |
|
| 74 |
pkg_preinst (EAPI 0) |
| 75 |
pkg_postinst (EAPI 0) |
| 76 |
pkg_prerm (EAPI 2) |
| 77 |
pkg_postrm (EAPI 2) |
| 78 |
|
| 79 |
Another conceivable order: |
| 80 |
|
| 81 |
pkg_preinst (EAPI 0) |
| 82 |
pkg_prerm (EAPI 2) |
| 83 |
pkg_postrm (EAPI 2) |
| 84 |
pkg_postinst (EAPI 0) |
| 85 |
|
| 86 |
Upgrade from EAPI 2 to EAPI 2 (unambiguous): |
| 87 |
|
| 88 |
pkg_preinst (EAPI 2) |
| 89 |
pkg_prerm (EAPI 2) |
| 90 |
pkg_postinst (EAPI 2) |
| 91 |
pkg_postinst (EAPI 2) |
| 92 |
|
| 93 |
> I'd like the Council to say that for anything involving EAPIs 0, 1 or 2 |
| 94 |
> we stick to the pkg_* phase ordering we've used years. |
| 95 |
|
| 96 |
Given that the phase order used in <sys-apps/portage-2.1.5 varies |
| 97 |
depending on whether or not the new and old version are identical |
| 98 |
[1], I consider the uniformity introduced by the new phase order to |
| 99 |
be a change that is well worth keeping. Given the small number of |
| 100 |
problems that have been discovered in practice, tracked by bug |
| 101 |
226505 [3], I believe that the potential problems have proven to be |
| 102 |
negligible. |
| 103 |
|
| 104 |
[1] |
| 105 |
http://dev.gentoo.org/~zmedico/portage/doc/portage.html#package-ebuild-phases-previous-installed |
| 106 |
[2] http://bugs.gentoo.org/show_bug.cgi?id=226419 |
| 107 |
[3] http://bugs.gentoo.org/show_bug.cgi?id=226505 |
| 108 |
- -- |
| 109 |
Thanks, |
| 110 |
Zac |
| 111 |
-----BEGIN PGP SIGNATURE----- |
| 112 |
Version: GnuPG v2.0.9 (GNU/Linux) |
| 113 |
|
| 114 |
iEYEARECAAYFAkjJPGAACgkQ/ejvha5XGaP4HQCfQvElOLBiFevxpFGIvXTHXwRv |
| 115 |
rrsAoI8uHLdEpztPViR6q9WYWLp3suJk |
| 116 |
=NQRa |
| 117 |
-----END PGP SIGNATURE----- |
Archives