2011-07-27 15:07:54 Rafael Goncalves Martins napisał(a): > On Wed, Jul 27, 2011 at 6:02 AM, Pacho Ramos <pa...@gentoo.org> wrote: > > El mié, 27-07-2011 a las 09:39 +0200, Michał Górny escribió: > >> Hello, > >> > >> As many of us already raged, the Python eclasses are delaying half > >> a year with support of EAPI=4. The reason for that is not actually > >> the lack of time or complexity of needed changes but willingness to use > >> the new EAPI as an excuse to turn the eclass API upside down. > >> > >> The question I'm raising here: should eclasses be actually allowed to > >> do *heavy* changes in their APIs in such cases? Or should the eclass > >> maintainers create a new eclass instead (python-r1.eclass or so)? > >> > >> The main advantage I see in that is that devs are somehow forced > >> to migrate their ebuilds as soon as they bump EAPI in them. Taking > >> a look at a number of ebuilds still using git.eclass (instead of git-2) > >> this is a serious advantage. > >> > >> On the other hand, I find this idea very unclear. Why should two > >> ebuilds use completely different eclass variables just because they're > >> using two different EAPIs? More importantly, why is a dev forced to do > >> the migration in a random point when he/she wants to bump the ebuild > >> EAPI? I'd like to remind you that python eclass is still hard to read > >> for many of us. > >> > >> And why do we have to wait so long to use a new EAPI? We already had to > >> fix a lot of ebuilds when old EAPIs were banned in Python eclasses. We > >> wanted to bump the ebuilds to EAPI 4 then but the eclasses didn't > >> support it. And now it still doesn't come with EAPI 4 support. > >> > >> And keeping two different EAPIs in a single eclass file means probably > >> that older EAPIs are going to be banned at a random point once again. > >> Devs will have to pro-actively migrate their ebuilds, overlays will > >> break and so on. The usual procedure related to eclass removal wouldn't > >> apply. > >> > >> So, don't you think it would be better to simply add EAPI=4 support to > >> python eclass with no changes and start developing the new API in > >> python-r1? Devs could migrate then at any point they want (and have > >> time to!), and when Python team wants to get rid of the old eclass, > >> the usual removal procedure will apply. > >> > > > > About the concrete case of python eclass, per Arfrever's comment in bug > > report related with its eapi4 support, that support is already available > > in overlay, but not yet merged to the tree (probably because of the > > possible upcoming retirement of Arfrever :-/). What is preventing python > > team to merge eclass from overlay? > > > > AFAIK, the EAPI4 support in the overlay is EAPI 4-python, that almost > certainly will never come to gx86, and some guys are trying to port > the functionality to raw EAPI4, IIRC.
python.eclass from python overlay supports EAPI="4". -- Arfrever Frehtes Taifersar Arahesis
signature.asc
Description: This is a digitally signed message part.
