From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id A274513827E for ; Wed, 11 Dec 2013 21:29:17 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 3E363E0CBA; Wed, 11 Dec 2013 21:28:53 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 36D63E0C56 for ; Wed, 11 Dec 2013 21:28:52 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id 702A433F547 for ; Wed, 11 Dec 2013 21:28:41 +0000 (UTC) X-Virus-Scanned: by amavisd-new using ClamAV at gentoo.org X-Spam-Flag: NO X-Spam-Score: -1.302 X-Spam-Level: X-Spam-Status: No, score=-1.302 tagged_above=-999 required=5.5 tests=[AWL=-1.139, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.161, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from smtp.gentoo.org ([IPv6:::ffff:127.0.0.1]) by localhost (smtp.gentoo.org [IPv6:::ffff:127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t0iGquedGeQr for ; Wed, 11 Dec 2013 21:28:35 +0000 (UTC) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.gentoo.org (Postfix) with ESMTPS id 08E7B33F557 for ; Wed, 11 Dec 2013 21:28:32 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1VqrKY-0005QA-8T for gentoo-dev@gentoo.org; Wed, 11 Dec 2013 22:28:30 +0100 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 ; Wed, 11 Dec 2013 22:28:30 +0100 Received: from 1i5t5.duncan by ip68-231-22-224.ph.ph.cox.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 11 Dec 2013 22:28:30 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-dev@lists.gentoo.org From: Duncan <1i5t5.duncan@cox.net> Subject: [gentoo-dev] Re: rfc: renaming "rc" binary in OpenRC Date: Wed, 11 Dec 2013 21:28:09 +0000 (UTC) Message-ID: References: <20131211204110.GA30092@linux1> <52A8CF7D.3090309@gentoo.org> <52A8D0B0.9010709@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 Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: ip68-231-22-224.ph.ph.cox.net User-Agent: Pan/0.140 (Chocolate Salty Balls; GIT 7161f50 /usr/src/portage/src/egit-src/pan2) X-Archives-Salt: 4a87d2d9-d5d0-4852-82fb-9fd572d50380 X-Archives-Hash: e441b163b98cbc040fd2105cf8b60374 Markos Chandras posted on Wed, 11 Dec 2013 20:53:04 +0000 as excerpted: > On 12/11/2013 08:47 PM, Chris Reffett wrote: >> On 12/11/2013 3:41 PM, William Hubbs wrote: >>> >>> My thought is to rename our "rc" to "openrc", since that would be >>> unique. >>> >>> I know at least one thing that will break is everyone's inittab, so >>> should I sed their inittab in our live ebuild or expect them to fix it >>> and give a warning? I know that once OpenRC with this change is >>> released, it will need to probably be p.masked until there is a new >>> release of sysvinit that updates the inittab. >> The idea of running a sed on inittab in an ebuild, no matter what the >> context, terrifies me. Perhaps we can ease this in slowly by renaming >> rc -> openrc and symlinking rc -> openrc and making a release with that >> change concurrent with a news item? Or even just do that in the ebuild >> rather than in the actual sources. I don't think Debian will keel over >> and die if it takes a little extra time for the change to go through, >> and it beats a ton of broken systems. > +1 > > The ebuild can grep the inittab and it if finds an "rc" there, just > print a huge warning telling the user to migrate || die. I think it's worth noting two small details of williamh's original mail that may have gone unnoticed: 1) He proposes seding the *LIVE* ebuild, which I take as meaning openrc-9999. 2) He then proposes p.masking an openrc release until a sysvinit release updating inittab, with the contrast between that and the LIVE ebuild proposal thus again emphasized. Question: How many people run the openrc-9999 LIVE ebuild, and given that it's masked and general gentoo policy is that people running live ebuilds should expect to keep the pieces of they can't handle occasionally unpredicted changes, how much should we actually worry about doing just that? *I ask the above as an openrc-9999 user myself! Of course, I also not only follow this list for heads-up notes such as this, but I also have a partially scripted update routine that checks openrc for changes every time I update, runs git log to check them out if there are any, and further runs git show on anything that I have questions about, *BEFORE* I actually do the update. There's certainly a small window between my checks and the actual run of the openrc emerge, during which a git commit or two might in theory slip in, but other than that, I'd see such a change BEFORE I ever actually installed that openrc live update in the first place. As a result, while I probably wouldn't have noted the linkage to inittab without this mail, I would have at least been aware of the name change when I did that live-build update, and would be prepared to boot with init=/bin/bash and find the problem, should it come to that, as I know it well might given the live-ebuild I choose to run. Meanwhile, given the openrc-9999 bug history, with me as about the only bug reporter, I don't think there's that many actually running it. Certainly nothing I'd qualify as "a ton of broken systems" even if there's no sed and every one of those running it fails to see the warning until they've rebooted and suffered the consequences. And the p.mask proposal for an actual release with the change, until a parallel sysvinit package update likely unmasked at the same time, does sound appropriately more responsible for ~arch as well, thus making both proposals at least not entirely insane. Tho I too am a bit uncomfortable about sedding inittab directly from the ebuild. Assuming it can work, the more gradual symlink and safer grep proposals sound much more reasonable, even at the live ebuild level. Tho that said, given that I /am/ running a live ebuild for something as critical as openrc, if sed screws up and replaces the current inittab with an empty file, I'd better be prepared to deal with it. That's part of the risk I took when unmasking that ebuild. Now I'd be rather more annoyed if the ebuild pulled a trick like I did in one of my own scripts a few years ago, such that I used the wrong variable name as the absolute prefix to a rm command run as root, and said mis-named variable ended up null... I was brown-bagging /that/ one for a few days! =:^\ But killing a single inittab file, meh! If I can't deal with that, I've no business running an openrc-9999 version! -- 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