Re: [gentoo-dev] Re: EAPI Changes

[Tiziano Müller]

Am Sonntag, den 17.05.2009, 11:11 -0600 schrieb 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.
Which is mostly wrong as well since a change in dependency means that
the currently installed stuff may break if a package (the new dependency
for example) gets removed and since the package you changed does not
reference it, it gets broken (for example if you had a magic dep before
and add it now as an explicit dep). So, unless you're doing a pkgmove
it's a dangerous thing since the PM can't reliably track reverse deps
when doing uninstalls since it has to use the vdb entry for that,
doesn't it?

>   So I'd argue that an
> EAPI change does not require a revision bump in and of itself.
EAPI may imply a decent implicit change to the ebuild and therefore
needs a rev-bump as per the manual.

>   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.
And how much time a portage with a new EAPI got stabled?
(see for example early python eapi bumps)

>
> 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?
It would maybe suggest to update to an unstable version of portage, not
so good then?

-- 
Tiziano Müller
Gentoo Linux Developer, Council Member
Areas of responsibility:
  Samba, PostgreSQL, CPP, Python, sysadmin, GLEP Editor
E-Mail   : dev-zero@g.o
GnuPG FP : F327 283A E769 2E36 18D5  4DE2 1B05 6A63 AE9C 1E30