[gentoo-pms] eapi3 riders

[gentoo-pms] eapi3 riders

[Brian Harring]

[-- Attachment #1: Type: text/plain, Size: 1526 bytes --]

Just nudging y'all to see if there is any complaints w/ slipping a few 
riders in w/ eapi3 (aka prefix).

Specifically,

1) punting AA (no ebuild/eclass uses it, although 
suppression of it is required for a few ebuilds due to env conflicts 
w/ their build framework)

2) punting KV and it's friends- (check|get)_KV and 
KV_(major|micro|minor|to_int).  The only ebuilds/eclasses aware of 
these vars seem to be glibc <2.5-r3 for nptl checks.  This one is 
potentially arguable although shifting it into an eclass would 
definitely suffice if it were actually needed.

3) the fun one.  mtime preservation (bug 264130).  Exact wording is 
still being tweaked (mostly screwing w/ double 
negatives/contradictions), but it looks like the brewha on that one is 
finally quieted down.  I can reiterate the specifics of why it's 
needed if needs be, just ask.

The reason I'm suggesting these be slipped in is pretty 
straightforward- for the first two, it's just punting some vars/code 
that are dead from the ebuild spec.  For the last one, paludis has 
mtime preservation code (disabled, and I've not tested it to see if 
it's sane), pkgcore has a compliant implementation (does second level 
resolution for merges), and portage is en route (second level is 
doable, they're just trying to preserve NS where possible).

So... basically minimal work on the PM standpoint for mtime, and a 
pretty useful gain for pkgs.

Thoughts?  Additionally, anyother minor cleanups folks can think of?
~harring

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

[gentoo-pms] Re: [gentoo-council] eapi3 riders

[Ulrich Mueller]

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

> 3) the fun one.  mtime preservation (bug 264130).

This is already included, see again December council meeting.
<http://www.gentoo.org/proj/en/council/meeting-logs/20091207-summary.txt>

The only feature that I think is worth reconsidering:

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.

Ulrich

[gentoo-pms] Re: [gentoo-council] eapi3 riders

[Brian Harring]

[-- Attachment #1: Type: text/plain, Size: 2658 bytes --]

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 #2: Type: application/pgp-signature, Size: 198 bytes --]