On Fri, Sep 16, 2011 at 07:30:14AM -0500, Donnie Berkholz wrote:
> On 02:06 Fri 16 Sep     , Brian Harring wrote:
> > Specious argument; the point of controllable stacking was to avoid the 
> > issue of overlay's forcing their eclasses upon gentoo-x86 ebuilds 
> > (which may not support those modified eclasses) via the old 
> > PORTDIR_OVERLAY behaviour.  This is why multiple repositories have 
> > layout.conf master definitions- to explicitly mark that they 
> > require/consume a seperate repo.
> 
> So let me get this straight — instead, you want overlay users to 
> maintain a copy of every eclass they use, which will almost 
> automatically become outdated and stale because it won't track the 
> gentoo-x86 version?

Where did I say that?

layout.conf exists to allow repo's to explicitly state what they need- 
this means we can have individual overlay stacks, instead of having 
gentoo-x86, overlay1, overlay2, overlay3, with that as a single stack 
(including eclass lookup), it can be broken out as individual stacks.  

This limits the eclass affect for a repo to just what is explicitly 
configured.  This is a good thing.  This is controllable in addition.

What I said from the getgo and you're missing is that pushing EAPI 
implementation into the tree and ignoring EAPI, or having this notion 
that every repository must automatically use gentoo-x86 (pushing the 
format into the tree) is /wrong/; aside from meaning that the format 
definition can now *vary*, which is great for wasting dev time and 
screwing up compatibility, it opens up tweaking/customizing that 
functionality- aka, fragmentation/divergence.  If we did the sort of 
thing you're basically pushing for, how long do you think it would be 
till funtoo added support for a new archive format to unpack?  That's 
a *simple*, and *likely* example of how this can diverge.

Further, doing as you propose means we're flat out, shit out of luck 
/ever/ distributing a usable cache for standalone repositories.  If 
they're bound to the changes of another repository, distributing a 
cache in parallel is pointless (and not doable in current form since 
metadata/cache lacks necessary eclass validation data for overlay 
inheritance).

Fact is, gentoo-x86 has a lot of usable eclass in it, but it's not 
required to be used.  Anything trying to *force* that is very short 
sighted and forgetting history.

You want new EAPI functionality that is bash only?  Awesome, eclass 
compatibility, and EAPI; don't just jam it into an eclass and say 
"EAPI is slow/annoying and I don't want to do it".  Do both, everyones 
happy.

~harring, cranky at revisiting the same arguments over and over