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