El jue, 18-10-2012 a las 15:35 -0400, Rich Freeman escribió: > On Thu, Oct 18, 2012 at 3:05 PM, Pacho Ramos <[email protected]> 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.
signature.asc
Description: This is a digitally signed message part
