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