| Summary: | [TRACKER] sys-apps/portage EAPI 3 implementation | ||
|---|---|---|---|
| Product: | Portage Development | Reporter: | Zac Medico <zmedico> |
| Component: | Conceptual/Abstract Ideas | Assignee: | Portage team <dev-portage> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | binki, pms |
| Priority: | High | Keywords: | Tracker |
| Version: | 2.1 | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | 273638, 296701 | ||
| Bug Blocks: | 302803 | ||
|
Description
Zac Medico
2009-12-13 06:40:11 UTC
Where are you getting your list of what's in EAPI 3 from? The prefix stuff came from a council decision. I threw in xz unpack myself because I just assumed everybody would want it. Are you planning to throw anything else in there? We're trying to get PMS straightened out after the most recent round of Counciling. No, I'm not planning to throw in anything else. Hopefully the current state is final. Simple stuff (cleanup, final removal of vars that were deprecated), etc, should be considered. Keep in mind to get eapi3 official anyways, it'll have to go back to the council. A few simple riders that are beneficial shouldn't be cause to get butt hurt. Ok, who's coming up with the full list and running it past the Council then? If anybody wants to make a list, the ones that block bug 273620 and are marked "fixed" are good choices since there are already patches in portage for those. Ahem. We voted in the December meeting that we don't want any additional features in EAPI 3. My personal opinion (not speaking for the council): EAPI 3 is intended as the Prefix EAPI, so it should be as easy as possible to convert existing ebuilds to it (basically, after replacing 2 by 3 the ebuild should just work). OTOH, .xz support sounds safe enough since it's just an extension. So if you absolutely want to prepare such a list, I would recommend that you don't include any incompatible changes (like removal of variables or functions, or change of default phase functions). And probably .xz support is the feature (of the already implemented ones) that is most urgently awaited. (In reply to comment #8) > Ahem. We voted in the December meeting that we don't want any additional > features in EAPI 3. > > My personal opinion (not speaking for the council): > EAPI 3 is intended as the Prefix EAPI, so it should be as easy as possible to > convert existing ebuilds to it (basically, after replacing 2 by 3 the ebuild > should just work). I was more thinking of locking down things ebuilds either expect already, or formally punting stuff they've stopped using. Forbidding AA in EAPI3 is pretty much a zero hit on ebuild devs- it's already dead. Punting KV w/in EAPI3 (get_KV and friends in addition) is potential, although someone would have to talk to the kernel herd since frankly I don't want to dig through their eclass. The one potentially contentious one is pushing mtime preservation into eapi3- reasoning for doing this is that there are a decent # of ebuilds/eclasses that expect mtime preservation (hence that bug existing). Formalizing it shouldn't be disruptive to ebuilds (portage/pkgcore already do it after all)- more importantly, it enables said ebuild devs to cleanup some nasty orphan scenarios that exist where they're protecting against the lack of mtime preservation. Either way, the stuff that is dead or is already expected by ebuilds/eclasses in the tree is what I'm suggesting be slipped in as riders on eapi3. Personally I would like to see EAPI 3 used as fast as possible, so keep as much out as you can. Maybe some people don't agree on the zero-cost argument and we have discussions on-end again. (In reply to comment #10) > Personally I would like to see EAPI 3 used as fast as possible, so keep as much > out as you can. Maybe some people don't agree on the zero-cost argument and we > have discussions on-end again. If the discussion goes cyclical, then lay down the law... if it's got valid technical arguements that are real world breakages/issues, then punt it to eapi4 imo. Just to contrast ferringb's remark about having to rerun eapi3 against the council: my interpretation of the last council's meeting was that it approved how eapi3 should look like and that it wanted to see it being available ASAP. Since that last thing is pretty much important to me, I prefer to delay all the discussions on (even though seemingly trivial) other issues, and to stay with the council's decision that eapi3 is just eapi2 + prefix. I tend to agree with grobian. But if you really want any additional feature (like .xz support), then please send an e-mail message to the gentoo-council ML *now* and don't wait until the next council meeting. We really should see that we'll have the final spec for EAPI 3 as soon as possible. (In reply to comment #13) > I tend to agree with grobian. > > But if you really want any additional feature (like .xz support), then please > send an e-mail message to the gentoo-council ML *now* and don't wait until the > next council meeting. We really should see that we'll have the final spec for > EAPI 3 as soon as possible. Emailed, although go figure, I forgot to mention .xz support. Someone might want to add that to the ml posting... As I expressed on the -pms mailing list, EAPI 3 should restrict to mtime preservation and prefix support. All other items should be postponed. EAPI 3 is supported in >=sys-apps/portage-2.1.7.17. |