Gentoo Logo
Gentoo Spaceship




Note: Due to technical difficulties, the Archives are currently not up to date. GMANE provides an alternative service for most mailing lists.
c.f. bug 424647
List Archive: gentoo-council
Navigation:
Lists: gentoo-council: < Prev By Thread Next > < Prev By Date Next >
Headers:
To: Ulrich Mueller <ulm@g.o>
From: Brian Harring <ferringb@...>
Subject: Re: eapi3 riders
Date: Mon, 14 Dec 2009 13:54:28 -0800
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
Attachment:
pgpS2CHNRiRJH.pgp (PGP signature)
References:
eapi3 riders
-- Brian Harring
Re: eapi3 riders
-- Ulrich Mueller
Navigation:
Lists: gentoo-council: < Prev By Thread Next > < Prev By Date Next >
Previous by thread:
Re: eapi3 riders
Next by thread:
Re: eapi3 riders
Previous by date:
Re: Re: [gentoo-pms] kdebuild-1 conditionales
Next by date:
January 2010 meeting date


Updated Nov 13, 2011

Summary: Archive of the gentoo-council mailing list.

Donate to support our development efforts.

Copyright 2001-2013 Gentoo Foundation, Inc. Questions, Comments? Contact us.