Re: [gentoo-dev] Re: [RFC] Drop EAPI=0 requirement for system packages.

[Pacho Ramos]

El jue, 18-10-2012 a las 15:35 -0400, Rich Freeman escribió:
> On Thu, Oct 18, 2012 at 3:05 PM, Pacho Ramos <pacho@g.o> wrote:
> > Personally I see no major difficult in moving to eapi4, what exact
> > difficult are you (I mean people still sticking with eapi0/1) seeing?
>
> It is harder than cp.  :)
>
> If I write a new ebuild I would always target the most recent EAPI.
> However, if I'm just doing a revbump, why fix what ain't broken?
>
> That is rhetorical.  I do understand your logic.  However, if it takes
> me 15min to do something now, and it might take me 15min to do it
> later, I'll take later every time since who knows if the package will
> even be around later.
>
> Rich
>
>

It's not only about the difficulty problem (that I don't see so hard),
it also about keeping packages behaving inconsistently around the tree
due people keeping old eapis in their ebuilds:
- What will occur if people is not forced to use eapi5 when "slot
operator dependencies" are needed? Will people still need to already run
revdep-rebuild for ages to be safer?

- What about " --disable-silent-rules" eapi5 feature? Will we have part
of the tree passing that option while other packages are still showing
hidden output due old eapi usage?

- What about src_test behavior? If packages are broken they should force
-j1 for that packages... but if we don't push people to jump to last
eapi, they will be tempted to simply skip the eapi bump to hide the
problem.

- Look to different blockers handling introduced in eapi2, if people
keeps using older eapis, they will still make people to need to manually
unmerge old package even if not needed.

- Also look to packages still dying due unsatisfied USE dependencies
instead of bumping to eapi >=2 and setting that deps properly.

- And the different behavior of utilities dying, they will die on eapi4
but won't on older eapis and, then, that utils could still be not
running at all but that being hidden.

- Also the --disable-dependency-tracking parsing in eapi4, if it was
added to run configure faster, that is nice, but packages still wanting
to keep old eapi to not make the effort to bump it will still have a
slower configure run.

What I am trying to say is that, if we agree latest eapi is technically
better, we need to try to get it used when possible (I mean, when, for
example, eclasses are ported) for a "QA" reasoning.