Re: [gentoo-portage-dev] Atom matching behavior

[Brian Harring]

On Mon, Jul 31, 2006 at 10:11:06PM -0400, Mike Frysinger wrote:
> On Monday 31 July 2006 21:30, Brian Harring wrote:
> > On Mon, Jul 31, 2006 at 09:11:35PM -0400, Mike Frysinger wrote:
> > > On Monday 31 July 2006 18:48, Brian Harring wrote:
> > > > Should be discussed on -dev, not here imo;
> > >
> > > why ?  short term we're gaining functionality:
> > > simply add .*
> >
> > 1) portage isn't the only package manager
>
> invalid reason

> until a spec exists. portage's behavior is the spec
>
> > 2) it's not a backwards compatible change
>
> so ?  same way any new feature gets merged: support it now, dont use it till
> later

And EAPI exists to version those changes so they can be rolled out 
_now_, not cross your finger for six months and hope nobody uses it 
before then inadvertantly triggering some massive mess like bug 114798  
(the infamous "sync ate itself due to virtual/*").

Brutal truth here is that once it's available, people *will* use it 
sooner then when they're supposed to.  Further, the realistic estimate 
of deploying it, and sitting on it for 6 months *still* will lead to 
people hitting it- this isn't some minor idiot cache change, this 
is a change in dependency parsing- rooting out why a users portage 
installation is selecting some later dep in a ||() block might be easy 
for devs once they've seen it, but it ain't going to make sense to 
users (gurantee even if a dev knows of the change, it's going to take 
a bit for it to click also).

So... two potentials here.

1) Deploy it, and pretend that it'll be unused for 6 months.  Users 
hit weirdness that is fun to track down.

2) EAPI bump it.  Portage tells you it can't play with that node, and 
that you need to upgrade.  Can use it _immediately_.

EAPI was added to specifically stop the practice of "eh... just shove 
it in, we'll let it cook for a bit and hope people have upgraded by 
when it gets used"- benefit is you get immediate access to the new 
functionality, only con is that you have to flip one var in the 
ebuild.
~harring