Gentoo Archives: gentoo-pms

From: Brian Harring <ferringb@×××××.com>
To: Ulrich Mueller <ulm@g.o>
Cc: gentoo-council@l.g.o, gentoo-pms@l.g.o
Subject: [gentoo-pms] Re: [gentoo-council] eapi3 riders
Date: Mon, 14 Dec 2009 22:27:24
Message-Id: 20091214215428.GH6344@hrair
In Reply to: [gentoo-pms] Re: [gentoo-council] eapi3 riders by Ulrich Mueller
On Mon, Dec 14, 2009 at 12:35:17PM +0100, Ulrich Mueller wrote:
> >>>>> On Mon, 14 Dec 2009, Brian Harring wrote: > > > Just nudging y'all to see if there is any complaints w/ slipping a > > few riders in w/ eapi3 (aka prefix). > > > 1) punting AA > > 2) punting KV and it's friends > > We voted in the last council meeting that we won't put any additional > features into EAPI 3. So I think that you need good arguments if you > want us to revise that decision.
It's not addition of a feature... it's removal, thus its exempt- the wording was "no additional features"... right? right? My shitty joke aside, it's zero cost, zero impact for any real world ebuilds (vapier already said he'd punt the involved ebuilds). The reason KV/friends needs to die is that they're basically misleading- majority of kernel aware bits involve /usr/src/linux, only ebuild that seems to need awareness of uname is glibc for nptl and I suspect there are other, better ways (as vapier already said, those ebuilds break down under cross compilation). That said, ignoring KV is viable imo. Punting AA, no cost- it's a worthless var. One less var for new devs to trip on, basically. It's not blatantly hurting anything right now so it could survive. Personally I'd rather not see it's existance continue because we're adhering to the words of the council rather then their intent. Specifically, I presume their intent was to knock this eapi out as quickly as possible- punting AA/KV won't affect that timeline (it's 5 minutes worth of implementation time, and 5 of spec time).
> 4) Support for unpacking .xz files > > It's an extension, therefore backwards compatible, and zmedico has > already included it in Portage (EAPI=3_pre2 has it). > > Should we have a vote per e-mail about the above (1, 2, and 4)? > I think we should finalise the EAPI 3 feature list now and don't > reiterate it at the next council meeting.
No argument from me on adding this. It's simple and quick, more importantly it's beneficial to devs. Consider that my +1 as someone who will actually have to implement the support... One additional thought is mtime vdb touching. I'd be tempted to try pushing that one in, specifically requiring implementations that support eapi3 to do this simple touch namely. It's a bit hackish, but is a nice way to nudge PMs to get off their ass and be compliant. Unfortunately that's probably not going to fly since council still hasn't commented. If y'all are open to it, I'd be willing to do the legwork to get it in- if preferred to defer, I understand. ~harring