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
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
~harring, cranky at revisiting the same arguments over and over