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
