1 |
Nirbheek Chauhan posted on Mon, 05 Jul 2010 09:02:19 +0530 as excerpted: |
2 |
|
3 |
> On Mon, Jul 5, 2010 at 7:53 AM, Richard Freeman <rich0@g.o> |
4 |
> wrote: |
5 |
>> On 07/04/2010 04:09 PM, Jory A. Pratt wrote: |
6 |
>>> |
7 |
>>> For those of you not on the #gentoo-dev channel, I just announced I am |
8 |
>>> gonna be looking at the openrc code and fixing the bugs and working to |
9 |
>>> continue the development. Anyone that is interested in helping please |
10 |
>>> feel free to contact me off list to discuss how we will handle getting |
11 |
>>> openrc back on track. |
12 |
|
13 |
Very cool. =:^) |
14 |
|
15 |
If you/we're moving OpenRC development back in-house, a couple of the |
16 |
problems with OpenRC as it was, pretty much cease to exist any more. |
17 |
|
18 |
The problems with OpenRC first trace back to, from what I can see, a |
19 |
disagreement some years ago, now -- which also played a non-minor role in |
20 |
Roy leaving Gentoo, as well. Roy's idea was to take Gentoo toward POSIX |
21 |
shell compatibility, both init-system-wise and package-system-wise. Over- |
22 |
all, that went over like a lead balloon, a number of devs (including |
23 |
several core toolchain, etc, devs, and council members) /liked/ the bash |
24 |
extensions Gentoo relies on, and our package system remains solidly bash |
25 |
dependent today, both by policy and in practice. |
26 |
|
27 |
But Roy was the baselayout (then including what's now openrc as well) |
28 |
maintainer, and he went ahead with his plans there, splitting baselayout |
29 |
into the Gentoo specific baselayout, and the init system itself, which was |
30 |
intended to be POSIX shell compliant and distribution and *nix system |
31 |
independent, as well as implementing core parts of it as native |
32 |
executables, thus speeding it up dramatically from the formerly almost |
33 |
entirely shell scripted implementation. |
34 |
|
35 |
In large part (at least from the view from here as a user of the new |
36 |
system) it was due to the goals of POSIX shell compatibility and |
37 |
distribution agnosticism that delayed and drew out OpenRC development and |
38 |
stabilization so much, the reason why every time it seemed about ready to |
39 |
go stable, along would come new versions with dramatic changes, dropping |
40 |
more bashisms/gentooisms, or fixing bugs in the implementation triggered |
41 |
by the last round of drops. Had the only or primary goal been simply the |
42 |
split and the switch to the native code core, many of the changes, for |
43 |
instance to the network subsystem, wouldn't have been necessary, and the |
44 |
more parallel reliable and faster native code system would have been able |
45 |
to stabilize far sooner. |
46 |
|
47 |
But it would seem that whatever other distributions or BSDs he had hoped |
48 |
to get using OpenRC went with something else, instead, and as Gentoo has |
49 |
continued down the GNU/bash based system route, his interests and those of |
50 |
Gentoo have continued to diverge as well, so the OpenRC project has |
51 |
apparently become a dead-end as far as his interest is concerned, and he's |
52 |
abandoning it. |
53 |
|
54 |
Too bad for what could have been for OpenRC, but bringing it back in-house |
55 |
does solve the two biggest problems Gentoo was having with it, all the |
56 |
unnecessary (from a Gentoo perspective) changes removing bashisms and |
57 |
gentooisms, and the fast rate of incompatible change, leaving Gentoo |
58 |
without a practical base for stabilizing anything. |
59 |
|
60 |
>> Well, openrc isn't any worse than baselayout-1 for upstream support. |
61 |
>> However, I do agree that we should strongly try to standardize on |
62 |
>> something that is more cross-platform if possible. |
63 |
>> |
64 |
>> I'd rather not push to make openrc stable (which means lots of |
65 |
>> migration for users), only to then move to something else anyway. Why |
66 |
>> have two migrations when you can just have one? |
67 |
>> |
68 |
> The reason why people want to do an openrc migration right now is |
69 |
> because we don't know when we'll find something else to move to; make it |
70 |
> work with gentoo, make it work for everyone, iron out all the bugs, and |
71 |
> push it to stable. In all probability, and looking at our past |
72 |
> experience with pushing openrc to stable, it *will* take years. It's too |
73 |
> much work to maintain both baselayout-1 *and* openrc *and* find |
74 |
> something else to move to. It's best to move to openrc (which has |
75 |
> numerous benefits over baselayout-1, and has a maintainer now), and then |
76 |
> see what we can do. |
77 |
|
78 |
Well, given the above and assuming Gentoo could settle on a reasonably |
79 |
mature replacement within a reasonably short period (say 4-6 months), it's |
80 |
possible adopting and stabilizing that replacement wouldn't take the years |
81 |
and years that OpenRC has. Presumably, whatever we were to settle on |
82 |
would already know where it was going, and wouldn't be doing the |
83 |
change-horses-in-mid-stream thing that OpenRC was pulling, killing the |
84 |
bashims, etc, at the same time. |
85 |
|
86 |
But those are some big assumptions. I've gotten the impression that the |
87 |
projects making the big waves aren't all that mature, and while they |
88 |
hopefully aren't changing horses in mid-stream like OpenRC was doing, so |
89 |
the development shouldn't be as painful in that regard, they still have |
90 |
some serious growing to do before they're to the point where OpenRC is, |
91 |
today. |
92 |
|
93 |
Really, even if Gentoo does ultimately switch to something else, we do |
94 |
need to get stable on something a bit more modern than the baselayout-1 |
95 |
we're stuck with ATM, and OpenRC is pretty close to there, particularly |
96 |
since we're bringing it back in-house now, and it'll take some time for |
97 |
our new maintainer to get up to speed on it, so the only right away |
98 |
changes are likely to be what's necessary to fix the remaining bugs and |
99 |
stabilize what we have -- we're not trying to hit a fast changing target, |
100 |
as we were before, and there's nothing to trigger any more of those |
101 |
incompatible changes simply for POSIX compatibility or the like, since |
102 |
Gentoo depending on bash is a settled question at this point. |
103 |
|
104 |
So really, openrc-for-stable it really needs to be, at this point. Once |
105 |
that's for sure a settled question, /then/ we can debate whether Gentoo |
106 |
should try to switch to something more standardized, and what that might |
107 |
be if so, longer term. But what's very likely to be another two years |
108 |
minimum, with no real upper bound at all at this point, on baselayout-1, |
109 |
for stable users, while Gentoo dumps an OpenRC that's very close to stable |
110 |
at this point, to chase after what could well be "the wind" for another |
111 |
two years or more, possibly to realize that's simply not going to work for |
112 |
Gentoo either, or if we force it, it'll be at the expense of serious |
113 |
feature regression, just isn't a good idea, and there's no way to /make/ |
114 |
it a good idea. |
115 |
|
116 |
So let's stabilize OpenRC and be done with it, and /then/ we can debate |
117 |
where we want to go from there. |
118 |
|
119 |
-- |
120 |
Duncan - List replies preferred. No HTML msgs. |
121 |
"Every nonfree program has a lord, a master -- |
122 |
and if you use the program, he is your master." Richard Stallman |