Am 25.01.2011 12:20, schrieb Tomáš Chvátal: > Hi, > I would like to upgrade tree-wide policy for EAPI usage in main tree. > Currently we say that developers can use any named version they wish or > find sufficient. > I would on other hand like to have all ebuilds to use Latest EAPI > version possible (given the eclasses support it [hint hint maintainers > of eclasses should always try to support latest :P]) with expection for > base-system or more specialy depgraph for portage that needs to be > EAPI0. [[ And here we need to find out some upgrade proccess that would > work for everyone so we could somehow migrate them too :)]] > > With this usually new developers should be aware only of latest EAPI and > wont need to memorize what which EAPI support. Heck even I sometimes > forget what i can do with some version and whatnot.
Do you have some more arguments for your request? Most new developers will have to know about all EAPi versions anyway since they join an existing team with existing ebuilds, which will mostly not use the newest EAPI. As an argument againt this: Noone forces you to keep older EAPI versions of the ebuilds you maintain, you can always bump them to the latest EAPI. But why do you want to force this on all developers? If i have an EAPI-0 ebuild and am fine with it, why should i convert it to the latest EAPI? > > Winner for being PITA in this race is python.eclass that HAS completely > different behavior based on EAPI version used... The python eclass issues are not just EAPI related, the complete eclass is very complex and hard to read/understand. And just because the eclass has additional EAPI-specific behaviour, this is specific to this eclass and should not be an argument for the general EAPI discussion. > > Cheers > > Tomas -- Thomas Sachau Gentoo Linux Developer
signature.asc
Description: OpenPGP digital signature
