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

[Pacho Ramos]

El jue, 18-10-2012 a las 09:36 -0400, Rich Freeman escribió:
> On Thu, Oct 18, 2012 at 12:07 AM, Ryan Hill <dirtyepic@g.o> wrote:
> > On Wed, 17 Oct 2012 15:00:12 -0400
> > Rich Freeman <rich0@g.o> wrote:
> >> I think the whole developers-can't-handle-47-EAPIs thing is a red
> >> herring.  The fact that there are packages written in Erlang in the
> >> tree doesn't cause me any issues even though I haven't had to do any
> >> work in Erlang.  If I ever wanted to maintain such a package then I'd
> >> take the time to learn it as needed.  Likewise, if I wanted to
> >> maintain a package that used EAPI joe and I really prefer to work in
> >> EAPI fred, then I'd revise it at my next convenience.
> >
> > Well, it's not just about ebuilds you maintain.  Think about something
> > like the gcc-porting trackers where you have to touch a lot of ebuilds
> > across the tree.  You really do have to have a working knowledge of the
> > differences between EAPIs to do so.  My browser bookmark to the EAPI
> > cheatsheet is one of the more frequently used as it is.
>
> Can't you just ask the maintainers to fix their ebuilds?  And if they
> don't respond or at least cooperate, well, then treeclean them.  I
> don't think that library maintainers should have to bend over
> backwards to fix reverse dependencies, within reason.  If out of the
> whole tree two packages are blocking an upgrade, give a deadline or
> treeclean them.  If we have 47 bazillion packages that don't work on
> the newer lib, then slot it and bug upstream.
>
> I do agree that trying to auto-mangle ebuilds from 47 different EAPIs
> doesn't make sense.  Just assign a bug to the maintainer saying "do
> this to your ebuild, or get it on EAPI foo so that I can fix it, by
> <date> or it is gone."  The deadline is important - I've seen a
> pattern on -dev where bugs linger without deadlines for months, and
> then a deadline of two days is imposed, and then a big flame war
> breaks out.  Just set a deadline up-front and make it reasonable.
>
> Rich
>
>

I didn't think eapi4 features were still "unfamiliar" to so many
people... let's say, what about deprecating eapi1, 2 and 0 for newer
ebuilds? Is eapi2 so unfamiliar also to not force it as older eapi for
newer ebuilds (eapi3 changes look to be minor when compared with
eapi2) ?