1 |
On Fri, Sep 16, 2011 at 07:30:14AM -0500, Donnie Berkholz wrote: |
2 |
> On 02:06 Fri 16 Sep , Brian Harring wrote: |
3 |
> > Specious argument; the point of controllable stacking was to avoid the |
4 |
> > issue of overlay's forcing their eclasses upon gentoo-x86 ebuilds |
5 |
> > (which may not support those modified eclasses) via the old |
6 |
> > PORTDIR_OVERLAY behaviour. This is why multiple repositories have |
7 |
> > layout.conf master definitions- to explicitly mark that they |
8 |
> > require/consume a seperate repo. |
9 |
> |
10 |
> So let me get this straight — instead, you want overlay users to |
11 |
> maintain a copy of every eclass they use, which will almost |
12 |
> automatically become outdated and stale because it won't track the |
13 |
> gentoo-x86 version? |
14 |
|
15 |
Where did I say that? |
16 |
|
17 |
layout.conf exists to allow repo's to explicitly state what they need- |
18 |
this means we can have individual overlay stacks, instead of having |
19 |
gentoo-x86, overlay1, overlay2, overlay3, with that as a single stack |
20 |
(including eclass lookup), it can be broken out as individual stacks. |
21 |
|
22 |
This limits the eclass affect for a repo to just what is explicitly |
23 |
configured. This is a good thing. This is controllable in addition. |
24 |
|
25 |
What I said from the getgo and you're missing is that pushing EAPI |
26 |
implementation into the tree and ignoring EAPI, or having this notion |
27 |
that every repository must automatically use gentoo-x86 (pushing the |
28 |
format into the tree) is /wrong/; aside from meaning that the format |
29 |
definition can now *vary*, which is great for wasting dev time and |
30 |
screwing up compatibility, it opens up tweaking/customizing that |
31 |
functionality- aka, fragmentation/divergence. If we did the sort of |
32 |
thing you're basically pushing for, how long do you think it would be |
33 |
till funtoo added support for a new archive format to unpack? That's |
34 |
a *simple*, and *likely* example of how this can diverge. |
35 |
|
36 |
Further, doing as you propose means we're flat out, shit out of luck |
37 |
/ever/ distributing a usable cache for standalone repositories. If |
38 |
they're bound to the changes of another repository, distributing a |
39 |
cache in parallel is pointless (and not doable in current form since |
40 |
metadata/cache lacks necessary eclass validation data for overlay |
41 |
inheritance). |
42 |
|
43 |
Fact is, gentoo-x86 has a lot of usable eclass in it, but it's not |
44 |
required to be used. Anything trying to *force* that is very short |
45 |
sighted and forgetting history. |
46 |
|
47 |
You want new EAPI functionality that is bash only? Awesome, eclass |
48 |
compatibility, and EAPI; don't just jam it into an eclass and say |
49 |
"EAPI is slow/annoying and I don't want to do it". Do both, everyones |
50 |
happy. |
51 |
|
52 |
~harring, cranky at revisiting the same arguments over and over |