Re: [gentoo-pms] EAPI 5

[Brian Harring <ferringb@gmail.com>]

On Sun, Apr 29, 2012 at 08:47:27AM +0200, Micha?? G??rny wrote:
> On Sat, 28 Apr 2012 20:13:41 -0700
> Brian Harring <ferringb@gmail.com> wrote:
> 
> > On Sat, Apr 28, 2012 at 12:26:41PM +0200, Ulrich Mueller wrote:
> > > >>>>> On Sat, 28 Apr 2012, Ciaran McCreesh wrote:
> > > 
> > > > On Sat, 28 Apr 2012 12:11:38 +0200
> > > > Ulrich Mueller <ulm@gentoo.org> wrote:
> > > >> >>>>> On Sat, 28 Apr 2012, Ciaran McCreesh wrote:
> > > >> >> > * Get a versionator replacement into the PM
> > > >> >> 
> > > >> >> Given the long time it's been in limbo I doubt that this will
> > > >> >> be a quick feature. (But I'll be glad if you convince me of
> > > >> >> the opposite.)
> > > >> 
> > > >> > I thought we just didn't have that because we couldn't add new
> > > >> > global scope functions.
> > > >> 
> > > >> But can we already for EAPI 5? Wouldn't the following:
> > > >> 
> > > >> EAPI=5
> > > >> MY_PV=$(new_pm_version_mangler_function ${PV})
> > > >> 
> > > >> still fail for old package managers that don't implement EAPI
> > > >> parsing?
> > > 
> > > > Didn't the Council effectively vote to ignore that problem?
> > > 
> > > Yes, but after some reasonable transition period.
> > 
> > <insert my ongoing "Gee, lovely fucking approach to designing a 
> > compatibility mechanism"/>
> > 
> > For EAPI5, all global scope functionality/bash version/take your pick 
> > has to be taken off the table, and held back till EAPI6- w/ the 
> > timeline for EAPI6 being "a reasonable transition period" after EAPI5 
> > has been stabled in portage.
> 
> Usually, the transition period ends when we no longer bikeshed
> the topic.

Future suggestion: if you're going to try and be a smart ass, do it 
when you're right.  Not even sure how you could comment on transition 
periods since the last time this occured was in '06, but hey, have at 
it.


Continuing the point (w/ specific details so mgorny actually listens 
this time), referring to 
http://wiki.gentoo.org/wiki/Alternate_EAPI_mechanisms ,
the rules were to be "deploy the EAPI parsing, don't break existing 
mechanism for <reasonable transition period>, then go nuts".


So... if we abide by what was actually voted upon, our options are as 
follows:

1) No global scope crap in EAPI5.  Land it in EAPI6 since that's 
likely going to land past the compatibility window.  This is what I 
stated above; it sucks, but welcome to compatibility.

2) Stable a portage w/ the parsing now, delay EAPI5 till the 
compatibility window is over.  This sucks worse than #1 in my view.

3) Decide we don't actually care about compatibility (despite the 
proposal being about *compatibility*), and just deploy global crap in 
EAPI5 and ignore compatibility related breakage.  Smugly label anyone 
bringing these issues up as bikeshedding, eventually comparing them to 
ciaran.

So... bikeshed about the options, but we choose one of them.

~brian