-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ciaran McCreesh wrote:
> On Wed, 10 Sep 2008 23:43:54 -0700
> Zac Medico <zmedico@g.o> wrote:
>> [2] http://dev.gentoo.org/~zmedico/portage/eapi/eapi-2-draft.html
> 
> By table 6.11, are you implying that you consider the new pkg_ phase
> order to be part of EAPI 2?

No, I consider the phase order change [1] to be outside the scope of
EAPI.

> Really, Portage needs to revert the order and go back to the way it
> used to be for all EAPIs. The change breaks lots of existing ebuilds
> (you claim you've probably fixed everything in ::gentoo, but you don't
> know that and you've definitely not fixed overlays), including ebuilds
> using a common documented technique recommended by the devmanual.

The breakage to ebuilds, if they are broken in any way, seems to be
non-critical in the vast majority of cases since the new phase order
is identical to the phase order that portage has always used when
replacing a given ebuild with another ebuild of the same version [1].

I consider the use of has_version calls in pkg_postinst to detect
the previous installed version of a package, as suggested in
devmanual [2], to be an illogical or counter-intuitive approach. The
 counter-intuitive nature of the approach explains why it was only
used in a small fraction of the ebuilds in the tree. Ebuilds that
used this approach were easily fixed by moving the has_version calls
to pkg_preinst and storing the results in environment variables.

When moving has_version calls from pkg_postinst to pkg_preinst for
all ebuilds in the tree, I noticed that the calls were typically
used to trigger einfo or ewarn messages. So, the majority of such
breakage simply resulted in failure to generate einfo or ewarn
messages in some upgrade or downgrade scenarious.

> If you want the new pkg_* ordering to go through at all, it really
> needs a lengthy discussion on its own and it mustn't apply to any
> action that involves any existing EAPI.

I think it's worthwhile to have consistent phase ordering across all
EAPIs. Consider an upgrade from EAPI 0 to EAPI 2. If the phase order
is consistent across all EAPIs, as implemented in
>=sys-apps/portage-2.1.5, then the order of phase execution order is
uniform and unambiguous:

  Upgrade from EAPI 0 to EAPI 2

    pkg_preinst   (EAPI 2)
    pkg_prerm     (EAPI 0)
    pkg_postinst  (EAPI 0)
    pkg_postinst  (EAPI 2)

If the phase order varies from one EAPI to another, as you suggest,
then it seems like the phase order will not be uniform and the
logical order will be ambiguous in some cases since it will depend
upon both the EAPI of the original ebuild and the EAPI of the ebuild
that will replace it:

  Upgrade from EAPI 0 to EAPI 2 (maybe ambiguous):

    pkg_preinst  (EAPI 2)
    pkg_postinst (EAPI 2)
    pkg_prerm    (EAPI 0)
    pkg_postrm   (EAPI 0)

  Downgrade from EAPI 0 to EAPI 2 (certainly ambiguous):

    One conceivable order:

      pkg_preinst  (EAPI 0)
      pkg_postinst (EAPI 0)
      pkg_prerm    (EAPI 2)
      pkg_postrm   (EAPI 2)

    Another conceivable order:

      pkg_preinst  (EAPI 0)
      pkg_prerm    (EAPI 2)
      pkg_postrm   (EAPI 2)
      pkg_postinst (EAPI 0)

  Upgrade from EAPI 2 to EAPI 2 (unambiguous):

    pkg_preinst   (EAPI 2)
    pkg_prerm     (EAPI 2)
    pkg_postinst  (EAPI 2)
    pkg_postinst  (EAPI 2)

> I'd like the Council to say that for anything involving EAPIs 0, 1 or 2
> we stick to the pkg_* phase ordering we've used years.

Given that the phase order used in <sys-apps/portage-2.1.5 varies
depending on whether or not the new and old version are identical
[1], I consider the uniformity introduced by the new phase order to
be a change that is well worth keeping. Given the small number of
problems that have been discovered in practice, tracked by bug
226505 [3], I believe that the potential problems have proven to be
negligible.

[1]
http://dev.gentoo.org/~zmedico/portage/doc/portage.html#package-ebuild-phases-previous-installed
[2] http://bugs.gentoo.org/show_bug.cgi?id=226419
[3] http://bugs.gentoo.org/show_bug.cgi?id=226505
- --
Thanks,
Zac
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEARECAAYFAkjJPGAACgkQ/ejvha5XGaP4HQCfQvElOLBiFevxpFGIvXTHXwRv
rrsAoI8uHLdEpztPViR6q9WYWLp3suJk
=NQRa
-----END PGP SIGNATURE-----