1 |
On Sat, Sep 17, 2011 at 10:59:08PM -0500, Donnie Berkholz wrote: |
2 |
> On 13:43 Fri 16 Sep , Brian Harring wrote: |
3 |
> > What I said from the getgo and you're missing is that pushing EAPI |
4 |
> > implementation into the tree and ignoring EAPI, or having this notion |
5 |
> > that every repository must automatically use gentoo-x86 (pushing the |
6 |
> > format into the tree) is /wrong/; |
7 |
> |
8 |
> I'm not necessarily requiring that every repository must automatically |
9 |
> use gentoo-x86 ??? just the ones that want to use features in an eclass |
10 |
> distributed with gentoo-x86. It sounds to me like the logical |
11 |
> consequence of what you're saying is that every useful function that's |
12 |
> now or could eventually be in an eclass must instead be incorporated |
13 |
> into EAPI. I guess I just don't see where you're drawing the line. |
14 |
|
15 |
Drawing it back to what spawned it; usex. This isn't git.eclass, this |
16 |
isn't svn.eclass, nor is it any of the other complex eclass |
17 |
functionality. It's a core function that benefits the rest and |
18 |
should be in EAPI. |
19 |
|
20 |
That function is pretty clearly destined for EAPI, hence this long |
21 |
thread where you're bitching "avoid EAPI, do eclass only" and I'm |
22 |
bitching back "that's stupid for xyz reasons, do a compat eclass and |
23 |
push it into the next EAPI". |
24 |
|
25 |
|
26 |
> What I'm suggesting is that we should add useful stuff to eclasses by |
27 |
> default. If people want to use that stuff, they can stack on the |
28 |
> gentoo-x86 repo and inherit the eclass. I don't know why EAPI needs to |
29 |
> come into it at all. |
30 |
|
31 |
Stacking on gentoo-x86 means you get *everything* for that repository. |
32 |
If all you want is a random function out of eutils, that's a *lot* of |
33 |
uncontrolled change to have intermixed with your overlays eclasses |
34 |
(even worse, if the eclasses truly overlay into gentoo-x86, that |
35 |
introduces compatibility issues there too). |
36 |
|
37 |
It's a matter of change control; using the unpack example again, if |
38 |
I'm maintaining a 6 month old snapshot for production deployment, |
39 |
which is preferable for getting an updated unpack function: |
40 |
|
41 |
1) unpack is in eclasses; do I sync gentoo-x86 eclasses into my |
42 |
snapshot? Do I just cherry pick the updated function out, into my own |
43 |
trees? |
44 |
|
45 |
2) if it's part of a new EAPI, do I cherry-pick the update for my $PM, |
46 |
and then use that EAPI in my ebuilds that needs that new |
47 |
functionality? |
48 |
|
49 |
#1 is exactly the sort of scenario where you'll start getting |
50 |
copy/pasting; you can state "well they should just update", but that's |
51 |
completely unrealistic. Every production deployment of gentoo (or |
52 |
derived from) that I've seen has snapshot'd periodically for |
53 |
stabilization reasons. |
54 |
|
55 |
|
56 |
> > aside from meaning that the format definition can now *vary*, which is |
57 |
> > great for wasting dev time and screwing up compatibility, it opens up |
58 |
> > tweaking/customizing that functionality- aka, |
59 |
> > fragmentation/divergence. |
60 |
> |
61 |
> People doing that outside gentoo-x86 should do it the same way as ones |
62 |
> within it, by bumping the eclass to a new unique name. Ideally one |
63 |
> that's not just a numeric value so it won't conflict with ours, in the |
64 |
> same way as EAPI naming. |
65 |
|
66 |
They should, but api compatibility of an eclass *can* be fluid- in the |
67 |
past it was a locked API purely because of portage environment saving |
68 |
issues. That's been resolved, there isn't any strict requirement that |
69 |
the eclass maintain API compat now. You're trying to rely on people |
70 |
doing best practices- for format building blocks |
71 |
(use_with/usex/unpack/etc), that's not sane. |
72 |
|
73 |
|
74 |
> > If we did the sort of thing you're basically pushing for, how long do |
75 |
> > you think it would be till funtoo added support for a new archive |
76 |
> > format to unpack? That's a *simple*, and *likely* example of how this |
77 |
> > can diverge. |
78 |
> |
79 |
> So, what I'm getting out of this is that we should make it harder for |
80 |
> derivative distributions to innovate? Why should I care if they want to |
81 |
> do stuff with new archive formats? |
82 |
|
83 |
If funtoo wants their own unpack, awesome. Shove it into an eclass |
84 |
under a different name. If they want to modify unpack /directly/, |
85 |
they better damn well change the EAPI the ebuild uses. |
86 |
|
87 |
prefix, kde, hell even a crazy python attempt have all had custom |
88 |
EAPI's built out for exactly scenarios like this. |
89 |
|
90 |
The point of EAPI is that it's an agreed to format. Embrace/extending |
91 |
it hasn't intentionally occured yet since the versioning is |
92 |
*designed* to allow for people to cut their own formats as needs be |
93 |
for experimentation. |
94 |
|
95 |
|
96 |
> > Further, doing as you propose means we're flat out, shit out of luck |
97 |
> > /ever/ distributing a usable cache for standalone repositories. If |
98 |
> > they're bound to the changes of another repository, distributing a |
99 |
> > cache in parallel is pointless (and not doable in current form since |
100 |
> > metadata/cache lacks necessary eclass validation data for overlay |
101 |
> > inheritance). |
102 |
> |
103 |
> Not much different from other cross-repository dependencies; you have to |
104 |
> keep everything in lockstep because who knows what other people will do |
105 |
> with their repos. Maybe people would want to distribute their own copies |
106 |
> of forked dependent repositories too, I haven't thought much about it. |
107 |
|
108 |
Think that through; you're suggesting "shove it all in gentoo-x86"; |
109 |
that increases the lockstep requirements. |
110 |
|
111 |
|
112 |
I suspect an easier way to wrap this thread up is if you just state |
113 |
what you want for backwards compatibility- in a seperate thread you |
114 |
already proposed basically locking out systems older than 6 months, |
115 |
and this discussion (moreso the "eapi slows our development" subtext) |
116 |
is along the same lines. |
117 |
|
118 |
Layout what you think it should be, how you think EAPI should be |
119 |
managed (what goes in, what doesn't, etc), how derivatives should be |
120 |
handled, how we'll deal w/ installations/derivative distros that grab |
121 |
snapshots of the tree and run from that (chromeos is a public |
122 |
example, I've seen multiple private deployments using the same |
123 |
approach), and what /you/ think it should be rather than sniping at |
124 |
the examples I've been giving why things are the way they are. |
125 |
|
126 |
As is, this thread isn't really going anywhere- better to just skip |
127 |
ahead to what you think it should be rather than random arguments |
128 |
about what it is now. |
129 |
|
130 |
~harring |