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 1MDPxn-0003ta-6g for garchives@archives.gentoo.org; Sun, 07 Jun 2009 21:31:35 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 6A159E0466; Sun, 7 Jun 2009 21:31:33 +0000 (UTC) Received: from mail.marples.name (rsm.demon.co.uk [80.177.111.50]) by pigeon.gentoo.org (Postfix) with ESMTP id ED65EE0466 for ; Sun, 7 Jun 2009 21:31:32 +0000 (UTC) Received: from [10.73.1.31] (uberlaptop.marples.name [10.73.1.31]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.marples.name (Postfix) with ESMTPSA id 10DAE27B14 for ; Sun, 7 Jun 2009 22:31:32 +0100 (BST) Message-ID: <4A2C31B1.9060908@marples.name> Date: Sun, 07 Jun 2009 22:31:29 +0100 From: Roy Marples User-Agent: Thunderbird 2.0.0.21 (X11/20090521) 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 To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Detecting Baselayout2/OpenRC from init.d scripts (summary of debate and plans from bug 270646) References: <20090607195950.GI22927@orbis-terrarum.net> <4A2C1EA1.8050709@gentoo.org> <4A2C26DB.3040402@gentoo.org> In-Reply-To: <4A2C26DB.3040402@gentoo.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Archives-Salt: d411e249-ac69-4489-a491-f5de2fb422b2 X-Archives-Hash: f0068749944b95333e72bff30ac7e5f8 Josh Saddler wrote: > Also, if OpenRC/baselayout is dropping support for things like PPP or > ADSL[1], and will not guarantee a "stable" configuration (i.e. as > "final" as baselayout-1 has been, not needing constant user-side > updates)[2] . . . then we need to find some other solution for our users. Just to clarify - net.lo and friends, along with bash specific configs are NOT going away. They're just not actively being developed with new features, nor will they get priority for any fixes. However, net.lo nor the modules are installed by default (MKOLDNET=yes is required). So existing documentation works just fine. Also, writing documentation to support things like ADSL and PPP now entirely depends on upstream working with new stuff. For example, wpa_supplicant does not react by itself to hotplugged interfaces and the new OpenRC network script no longer supports per interface start/stops. This is a problem, and I've spent some time working on patches to wpa_supplicant for this, but upstream is not sure about the whole idea. > If upstream doesn't ever want to slow down, wants to constantly stick in > new features, try out new things, that's all well and good. More power > to 'em. But I think that is ultimately not such a good thing for our > users. Especially if it means constantly dropping support for features, > sacrificing compatibility, etc. We're already having enough trouble > trying to ensure future Portage compatibility via EAPIs, we should not > add in a potential baselayout/OpenRC mess atop that. Development on OpenRC has slowed down a lot of late, mainly as most of my goals of where it should go have now been met. And with moving networking to a very simple script, future changes will only be on a per init script basis. As OpenRC just supplies enough init scripts to boot a basic system any future changes will be in the init scripts themselves and thus removed from OpenRC specific documentation. Of course that doesn't stop various upstreams that Gentoo uses from totally changing their user interface. > Oh, yes . . . and there's the workload it would put on the GDP folks. We > already have a helluva time running around chasing devs down and prying > out straight answers about what to update in the existing documentation. > We'd probably all quit if we had to do the same thing for every new > openrc/baselayout release. You could always try writing the code instead ;) Thanks Roy