1 |
On 13:43 Fri 16 Sep , Brian Harring wrote: |
2 |
> What I said from the getgo and you're missing is that pushing EAPI |
3 |
> implementation into the tree and ignoring EAPI, or having this notion |
4 |
> that every repository must automatically use gentoo-x86 (pushing the |
5 |
> format into the tree) is /wrong/; |
6 |
|
7 |
I'm not necessarily requiring that every repository must automatically |
8 |
use gentoo-x86 — just the ones that want to use features in an eclass |
9 |
distributed with gentoo-x86. It sounds to me like the logical |
10 |
consequence of what you're saying is that every useful function that's |
11 |
now or could eventually be in an eclass must instead be incorporated |
12 |
into EAPI. I guess I just don't see where you're drawing the line. |
13 |
|
14 |
What I'm suggesting is that we should add useful stuff to eclasses by |
15 |
default. If people want to use that stuff, they can stack on the |
16 |
gentoo-x86 repo and inherit the eclass. I don't know why EAPI needs to |
17 |
come into it at all. |
18 |
|
19 |
> aside from meaning that the format definition can now *vary*, which is |
20 |
> great for wasting dev time and screwing up compatibility, it opens up |
21 |
> tweaking/customizing that functionality- aka, |
22 |
> fragmentation/divergence. |
23 |
|
24 |
People doing that outside gentoo-x86 should do it the same way as ones |
25 |
within it, by bumping the eclass to a new unique name. Ideally one |
26 |
that's not just a numeric value so it won't conflict with ours, in the |
27 |
same way as EAPI naming. |
28 |
|
29 |
> If we did the sort of thing you're basically pushing for, how long do |
30 |
> you think it would be till funtoo added support for a new archive |
31 |
> format to unpack? That's a *simple*, and *likely* example of how this |
32 |
> can diverge. |
33 |
|
34 |
So, what I'm getting out of this is that we should make it harder for |
35 |
derivative distributions to innovate? Why should I care if they want to |
36 |
do stuff with new archive formats? |
37 |
|
38 |
> Further, doing as you propose means we're flat out, shit out of luck |
39 |
> /ever/ distributing a usable cache for standalone repositories. If |
40 |
> they're bound to the changes of another repository, distributing a |
41 |
> cache in parallel is pointless (and not doable in current form since |
42 |
> metadata/cache lacks necessary eclass validation data for overlay |
43 |
> inheritance). |
44 |
|
45 |
Not much different from other cross-repository dependencies; you have to |
46 |
keep everything in lockstep because who knows what other people will do |
47 |
with their repos. Maybe people would want to distribute their own copies |
48 |
of forked dependent repositories too, I haven't thought much about it. |
49 |
|
50 |
-- |
51 |
Thanks, |
52 |
Donnie |
53 |
|
54 |
Donnie Berkholz |
55 |
Council Member / Sr. Developer |
56 |
Gentoo Linux |
57 |
Blog: http://dberkholz.com |