El jue, 18-10-2012 a las 13:49 -0400, Rich Freeman escribió: > On Thu, Oct 18, 2012 at 11:49 AM, Pacho Ramos <[email protected]> wrote: > > 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) ? > > This still involves the issue that what would be simple ebuild bumps > turn into a need to make more substantial changes to an ebuild.
But that changes will save us from needing to move a lot of ebuilds to newer eapis if some years later we decide to deprecate some of them. For example, if every package using eapi1 is forced to be bumped to newer eapi, we won't need to manually do that work in the future if we decide to deprecate old eapis. Also, it's probably better to force new ebuilds to use things like splitted configure phase instead of keeping with old eapi0/1 src_compile one, also the same for deprecated things like dosed and dohard. If there were valid reasons to ban then on newer eapi, I think it's better to not allow people to still use old eapi to skip that banning (or were they banned only for cosmetic reasons?) > > And the concern still exists that a policy that says all new ebuilds > shall use EAPI foo might result in fewer new ebuilds. Sure, they'll > have new and shiny fooness, but arguably I'd rather have more packages > supported on older EAPIs then fewer packages supported on newer ones. > > If migrating to newer EAPIs is so simple, why aren't more doing it already? Personally I see no major difficult in moving to eapi4, what exact difficult are you (I mean people still sticking with eapi0/1) seeing? I have re-read http://devmanual.gentoo.org/ebuild-writing/eapi/index.html and I can't see anything specially hard :/ > > Rich > >
signature.asc
Description: This is a digitally signed message part
