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

[Pacho Ramos]

El mar, 16-10-2012 a las 23:42 -0600, Ryan Hill escribió:
> On Sat, 13 Oct 2012 08:28:20 +0200
> Ralph Sennhauser <sera@g.o> wrote:
>
> > On Fri, 12 Oct 2012 21:10:23 -0600
> > Ryan Hill <dirtyepic@g.o> wrote:
> >
> > > I'd argue against deprecating EAPI 0 any time soon though.  Killing
> > > EAPI 1 would be a better idea.
> >
> > I'm not for forced EAPI bumps anytime soon, but I expect EAPI 0 to be
> > gone from tree in 3-5 years once the EAPI=0 requirement is lifted.
>
> How many packages in the tree don't define EAPI at all?  It's been a while
> since I looked, but I remember it was a pretty big number.  Maybe things have
> changed.
>
> > Currently we have only 6 official EAPIs which is still manageable to
> > remember the details of each. Though it might be confusing for new
> > developers. Once we are at 20 EAPIs it will be an issue also for
> > seasoned folks.
>
> Agreed.  We will definitely have to do some pruning at some point.

Would be easier to prune old versions if we "force" them to be less
using at least preventing new ebuilds to use them. For example, what is
the advantage for a new ebuild to still rely on old src_compile phase
instead of src_prepare/configure...?

>
> > Therefore deprecation is a given, how to go about it is certainly up to
> > discussion. What do you see as an acceptable path here?
>
> I think an EAPI becomes a candidate for removal when the number of packages
> using it becomes small enough that a sufficiently motivated/bored/gullible
> person could take on the task of porting them all to a newer EAPI. EAPI 0 is
> our baseline (all EAPIs are defined as "EAPI 0 plus/minus foo") and thus
> should never* be removed.  Anything else is fair game.
>
>
> *for varying lengths of never.  If it becomes completely irrelevant then
> yeah just boot it.
>