eapi3 riders

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

eapi3 riders

Brian Harring-2
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

attachment0 (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: eapi3 riders

Ulrich Mueller-2
>>>>> 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

Reply | Threaded
Open this post in threaded view
|

Re: eapi3 riders

Mike Frysinger
In reply to this post by Brian Harring-2
On Monday 14 December 2009 06:09:23 Brian Harring wrote:
> 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.

as i'm sure you've seen, these are crap for cross-compiling.  i can simply
punt the glibc ebuilds in question.
-mike

signature.asc (853 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: eapi3 riders

Brian Harring-2
In reply to this post by Ulrich Mueller-2
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

attachment0 (205 bytes) Download Attachment