From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1OVhVh-0004DT-Hb for garchives@archives.gentoo.org; Mon, 05 Jul 2010 08:58:41 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 768A8E0AFA; Mon, 5 Jul 2010 08:58:38 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id 34D3FE0A83 for ; Mon, 5 Jul 2010 08:58:19 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id D206B1B4034 for ; Mon, 5 Jul 2010 08:58:18 +0000 (UTC) X-Virus-Scanned: amavisd-new at gentoo.org X-Spam-Score: -1.227 X-Spam-Level: X-Spam-Status: No, score=-1.227 required=5.5 tests=[AWL=-1.228, BAYES_50=0.001] Received: from smtp.gentoo.org ([127.0.0.1]) by localhost (smtp.gentoo.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Ruy8i4wofnQ for ; Mon, 5 Jul 2010 08:58:12 +0000 (UTC) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by smtp.gentoo.org (Postfix) with ESMTP id E1C3A1B4015 for ; Mon, 5 Jul 2010 08:58:11 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1OVhV9-00013h-84 for gentoo-dev@gentoo.org; Mon, 05 Jul 2010 10:58:07 +0200 Received: from ip68-231-22-224.ph.ph.cox.net ([68.231.22.224]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 05 Jul 2010 10:58:07 +0200 Received: from 1i5t5.duncan by ip68-231-22-224.ph.ph.cox.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 05 Jul 2010 10:58:07 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-dev@lists.gentoo.org From: Duncan <1i5t5.duncan@cox.net> Subject: [gentoo-dev] Re: The future of sys-apps/openrc in Gentoo Date: Mon, 5 Jul 2010 08:57:55 +0000 (UTC) Message-ID: References: <201007041630.07537.polynomial-c@gentoo.org> <20100704133949.0cda055a@gentoo.org> <4C30EA89.4020806@gentoo.org> <4C314233.8030809@gentoo.org> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: ip68-231-22-224.ph.ph.cox.net User-Agent: Pan/0.133 (House of Butterflies; GIT a971f44 branch-testing) Content-Transfer-Encoding: quoted-printable X-Archives-Salt: 2c22d566-77ae-4450-8f25-589cd7a9835d X-Archives-Hash: e6572f8c1df008b7a71f22fa70b2684e 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 > 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 a= m >>> gonna be looking at the openrc code and fixing the bugs and working t= o >>> continue the development. Anyone that is interested in helping please >>> feel free to contact me off list to discuss how we will handle gettin= g >>> openrc back on track. Very cool. =3D:^) If you/we're moving OpenRC development back in-house, a couple of the=20 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=20 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=20 shell compatibility, both init-system-wise and package-system-wise. Over= - all, that went over like a lead balloon, a number of devs (including=20 several core toolchain, etc, devs, and council members) /liked/ the bash=20 extensions Gentoo relies on, and our package system remains solidly bash=20 dependent today, both by policy and in practice. But Roy was the baselayout (then including what's now openrc as well)=20 maintainer, and he went ahead with his plans there, splitting baselayout=20 into the Gentoo specific baselayout, and the init system itself, which wa= s=20 intended to be POSIX shell compliant and distribution and *nix system=20 independent, as well as implementing core parts of it as native=20 executables, thus speeding it up dramatically from the formerly almost=20 entirely shell scripted implementation. In large part (at least from the view from here as a user of the new=20 system) it was due to the goals of POSIX shell compatibility and=20 distribution agnosticism that delayed and drew out OpenRC development and= =20 stabilization so much, the reason why every time it seemed about ready to= =20 go stable, along would come new versions with dramatic changes, dropping=20 more bashisms/gentooisms, or fixing bugs in the implementation triggered=20 by the last round of drops. Had the only or primary goal been simply the= =20 split and the switch to the native code core, many of the changes, for=20 instance to the network subsystem, wouldn't have been necessary, and the=20 more parallel reliable and faster native code system would have been able= =20 to stabilize far sooner. But it would seem that whatever other distributions or BSDs he had hoped=20 to get using OpenRC went with something else, instead, and as Gentoo has=20 continued down the GNU/bash based system route, his interests and those o= f=20 Gentoo have continued to diverge as well, so the OpenRC project has=20 apparently become a dead-end as far as his interest is concerned, and he'= s=20 abandoning it. Too bad for what could have been for OpenRC, but bringing it back in-hous= e=20 does solve the two biggest problems Gentoo was having with it, all the=20 unnecessary (from a Gentoo perspective) changes removing bashisms and=20 gentooisms, and the fast rate of incompatible change, leaving Gentoo=20 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. =C2=A0= 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 i= t > 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 to= o > 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 the= n > see what we can do. Well, given the above and assuming Gentoo could settle on a reasonably=20 mature replacement within a reasonably short period (say 4-6 months), it'= s=20 possible adopting and stabilizing that replacement wouldn't take the year= s=20 and years that OpenRC has. Presumably, whatever we were to settle on=20 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=20 bashims, etc, at the same time. But those are some big assumptions. I've gotten the impression that the=20 projects making the big waves aren't all that mature, and while they=20 hopefully aren't changing horses in mid-stream like OpenRC was doing, so=20 the development shouldn't be as painful in that regard, they still have=20 some serious growing to do before they're to the point where OpenRC is,=20 today. Really, even if Gentoo does ultimately switch to something else, we do=20 need to get stable on something a bit more modern than the baselayout-1=20 we're stuck with ATM, and OpenRC is pretty close to there, particularly=20 since we're bringing it back in-house now, and it'll take some time for=20 our new maintainer to get up to speed on it, so the only right away=20 changes are likely to be what's necessary to fix the remaining bugs and=20 stabilize what we have -- we're not trying to hit a fast changing target,= =20 as we were before, and there's nothing to trigger any more of those=20 incompatible changes simply for POSIX compatibility or the like, since=20 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=20 that's for sure a settled question, /then/ we can debate whether Gentoo=20 should try to switch to something more standardized, and what that might=20 be if so, longer term. But what's very likely to be another two years=20 minimum, with no real upper bound at all at this point, on baselayout-1,=20 for stable users, while Gentoo dumps an OpenRC that's very close to stabl= e=20 at this point, to chase after what could well be "the wind" for another=20 two years or more, possibly to realize that's simply not going to work fo= r=20 Gentoo either, or if we force it, it'll be at the expense of serious=20 feature regression, just isn't a good idea, and there's no way to /make/=20 it a good idea. So let's stabilize OpenRC and be done with it, and /then/ we can debate=20 where we want to go from there. --=20 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