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