[gentoo-dev] Re: EAPI Changes

[Ryan Hill]

On Fri, 15 May 2009 23:31:25 +0200
Tiziano Müller <dev-zero@g.o> wrote:

> Wrong. For example:
> - stuff like docompress may change the content being installed depending
> on the package manager
> - --disable-static (maybe in a later EAPI) changes content
> - slot-dep-operators change the rdepend of installed packages, so it
> changes how the package manager has to handle reverse packages on
> uninstall (in EAPI 3)

None of which are a problem when changing the EAPI from 0 to 1, which is the
situation here. The first two examples fall under the currently established
guideline of revbumping when content changes (and I emphasize guideline).  I
don't see how the third example is any different than adding or removing
dependencies, which also does not require a revbump.  So I'd argue that an
EAPI change does not require a revision bump in and of itself.  That's not to
say it shouldn't be done if the situation allows, or you have any doubts, or
just because you want to. But unconditionally putting an ebuild through full
~arch to stable cycle because you added a simple SLOT dependency or a + to a
USE flag is bureaucratic nonsense.

> And we also always said that a rev bump should be done on non trivial
> changes or non-build-fixes and changing the EAPI is technical seen
> mostly a non-trivial change.

As above, it depends on the situation.  0 -> 1 is a trivial change.

> Do we want to document the following? (do we have already?)
> - When is it allowed to use an EAPI in the tree (given as offset to the
> release of portage supporting that eapi)
> - When is it allowed to use an EAPI in the stable tree (given as offset
> of when a portage version supporting that EAPI got stable)

As soon as a version of portage supporting that EAPI is available.

This is the entire point of the EAPI, that we don't have to wait X amount of
time before using new features.  If the user hasn't updated portage yet, they
simply won't see ebuilds which use the new EAPI.

We may want to document a suggested waiting time before removing ebuilds
using older EAPI's.  For example, should we always keep an EAPI 0 ebuild in
stable as a fallback?  Or if the user tries to install or update a package
where all versions are masked by EAPI, should (does?) portage suggest updating
itself?  How long should we keep core system packages at earlier EAPI's?


-- 
gcc-porting,                                      by design, by neglect
treecleaner,                              for a fact or just for effect
wxwidgets @ gentoo     EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662