On 10/14/2011 09:11 PM, "Paweł Hajdan, Jr." wrote: > On 10/14/11 5:38 PM, Alec Warner wrote: >> I believe op's point is that there is no one to escalate the problem >> to; certainly the council members are not going to do the work >> themselves and we already have our best people on it. > > I'm aware of that. My point is that I think there are many scenarios in > which EAPI-4 + python.eclass can work, especially if it's used only for > few things in cases like www-client/chromium > > Because the python team takes _ages_ to do the transition that is > holding back many other packages, because they've made python.eclass > overly complex and now try to make it perfect, > > I'd just like to get an "OK" to enable EAPI-4 for that eclass. > > Please note that it's still up to dependent packages which EAPI they > use. If they break python.eclass with EAPI-4 they shouldn't update to > that EAPI. However, if there are packages using python.eclass that could > work fine with EAPI-4, it shouldn't be blocking them for *ages* >
That would be an ok approach from my perspective: We could just change line 14 of python.eclass and let package maintainers report breakage as they increment EAPI. I am confident that nothing EAPI <= 3 would break. Is anyone (especially djc and the python herd members) opposed to this?
signature.asc
Description: OpenPGP digital signature
