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
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.