1 |
On 04:22 Sun 18 Sep , Brian Harring wrote: |
2 |
> On Sat, Sep 17, 2011 at 10:59:08PM -0500, Donnie Berkholz wrote: |
3 |
> > On 13:43 Fri 16 Sep , Brian Harring wrote: |
4 |
> > > What I said from the getgo and you're missing is that pushing EAPI |
5 |
> > > implementation into the tree and ignoring EAPI, or having this notion |
6 |
> > > that every repository must automatically use gentoo-x86 (pushing the |
7 |
> > > format into the tree) is /wrong/; |
8 |
> > |
9 |
> > I'm not necessarily requiring that every repository must automatically |
10 |
> > use gentoo-x86 ??? just the ones that want to use features in an eclass |
11 |
> > distributed with gentoo-x86. It sounds to me like the logical |
12 |
> > consequence of what you're saying is that every useful function that's |
13 |
> > now or could eventually be in an eclass must instead be incorporated |
14 |
> > into EAPI. I guess I just don't see where you're drawing the line. |
15 |
> |
16 |
> Drawing it back to what spawned it; usex. This isn't git.eclass, this |
17 |
> isn't svn.eclass, nor is it any of the other complex eclass |
18 |
> functionality. It's a core function that benefits the rest and should |
19 |
> be in EAPI. |
20 |
|
21 |
OK, so the implication of what you're saying is that everything in |
22 |
eutils.eclass, base.eclass, toolchain-funcs.eclass, flag-o-matic.eclass, |
23 |
versionator.eclass, multilib.eclass, prefix.eclass, savedconfig.eclass, |
24 |
and maybe even linux-info.eclass and autotools{,-utils}.eclass should go |
25 |
into EAPI. All that stuff is pretty generally useful features. |
26 |
|
27 |
> > What I'm suggesting is that we should add useful stuff to eclasses |
28 |
> > by default. If people want to use that stuff, they can stack on the |
29 |
> > gentoo-x86 repo and inherit the eclass. I don't know why EAPI needs |
30 |
> > to come into it at all. |
31 |
> |
32 |
> Stacking on gentoo-x86 means you get *everything* for that repository. |
33 |
> If all you want is a random function out of eutils, that's a *lot* of |
34 |
> uncontrolled change to have intermixed with your overlays eclasses |
35 |
> (even worse, if the eclasses truly overlay into gentoo-x86, that |
36 |
> introduces compatibility issues there too). |
37 |
|
38 |
Yeah, it seems like the ability to do partial stacking would be nice. |
39 |
Perhaps to do so, one wouldn't stack by default but would have a way to |
40 |
specify cross-repo dependencies (including eclasses) or file-specific |
41 |
UUIDs of some sort. |
42 |
|
43 |
> > > aside from meaning that the format definition can now *vary*, |
44 |
> > > which is great for wasting dev time and screwing up compatibility, |
45 |
> > > it opens up tweaking/customizing that functionality- aka, |
46 |
> > > fragmentation/divergence. |
47 |
> > |
48 |
> > People doing that outside gentoo-x86 should do it the same way as |
49 |
> > ones within it, by bumping the eclass to a new unique name. Ideally |
50 |
> > one that's not just a numeric value so it won't conflict with ours, |
51 |
> > in the same way as EAPI naming. |
52 |
> |
53 |
> They should, but api compatibility of an eclass *can* be fluid- in the |
54 |
> past it was a locked API purely because of portage environment saving |
55 |
> issues. That's been resolved, there isn't any strict requirement that |
56 |
> the eclass maintain API compat now. You're trying to rely on people |
57 |
> doing best practices- for format building blocks |
58 |
> (use_with/usex/unpack/etc), that's not sane. |
59 |
|
60 |
Which still pisses me off. It's like a shared library changing its API |
61 |
without bumping SONAME. That makes me wonder whether there's some way we |
62 |
could "enforce" it, at least on the level of repoman or test suites to |
63 |
examine whether the public interface changed, perhaps by generating a |
64 |
cache of the interfaces and comparing to them. |
65 |
|
66 |
> I suspect an easier way to wrap this thread up is if you just state |
67 |
> what you want for backwards compatibility- in a seperate thread you |
68 |
> already proposed basically locking out systems older than 6 months, |
69 |
> and this discussion (moreso the "eapi slows our development" subtext) |
70 |
> is along the same lines. |
71 |
|
72 |
Actually Zac said that, and I was trying to clarify if that's really |
73 |
what he was saying. 9-12 months is more my feeling, as it gets extremely |
74 |
difficult to maintain Gentoo systems without guru-level knowledge around |
75 |
there. (Spoken as someone who still gets support emails from a couple of |
76 |
previous positions.) |
77 |
|
78 |
While I would like there to be a "proper" way to express repo-level |
79 |
dependencies, properly announce deprecation and updates (e.g. to bash 4) |
80 |
in advance as a feature integrated with the PM, and so on, I don't think |
81 |
we should block our ability to move forward on these things. The |
82 |
situation is essentially the same as it's always been, but our old |
83 |
solution is no longer considered good enough and we don't have a new one |
84 |
in place, so we're just sitting here. |
85 |
|
86 |
> Layout what you think it should be, |
87 |
|
88 |
Layout of what, exactly? |
89 |
|
90 |
> how you think EAPI should be managed (what goes in, what doesn't, |
91 |
> etc), |
92 |
|
93 |
If it can go in an eclass without strange contortions, put it there. |
94 |
|
95 |
> how derivatives should be handled, |
96 |
|
97 |
With white gloves. More seriously, people making derivatives should have |
98 |
maximal freedom to experiment, and I'm guessing most of them don't want |
99 |
to deal with modifying 3 different PMs written at least partially in 3 |
100 |
different languages. They'd rather instantaneously support things in the |
101 |
same language they use for everything else. |
102 |
|
103 |
> how we'll deal w/ installations/derivative distros that grab |
104 |
> snapshots of the tree and run from that (chromeos is a public example, |
105 |
> I've seen multiple private deployments using the same approach), |
106 |
|
107 |
Being explicit about our level of support is what we need to do, no |
108 |
matter what that level is, so external groups can figure out how to deal |
109 |
with that timeline. Our current council-mandated standard is a year, as |
110 |
Ulm mentioned in another post, but I'm not aware of any of our |
111 |
documentation that actually says this. |
112 |
|
113 |
It would obviously be good to flood our users with communication |
114 |
(website, -announce, news items, etc) before anything that broke even |
115 |
just the oldest installations. |
116 |
|
117 |
-- |
118 |
Thanks, |
119 |
Donnie |
120 |
|
121 |
Donnie Berkholz |
122 |
Council Member / Sr. Developer |
123 |
Gentoo Linux |
124 |
Blog: http://dberkholz.com |