[gentoo-dev] Re: The future of sys-apps/openrc in Gentoo

[Duncan <1i5t5.duncan@cox.net>]

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 <rich0@gentoo.org>
> wrote:
>> 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 
abandoning it.

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, 
today.

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