From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gentoo-dev+bounces-63862-garchives=archives.gentoo.org@lists.gentoo.org>
Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80])
	by finch.gentoo.org (Postfix) with ESMTP id E8A1713827E
	for <garchives@archives.gentoo.org>; Wed, 11 Dec 2013 22:46:38 +0000 (UTC)
Received: from pigeon.gentoo.org (localhost [127.0.0.1])
	by pigeon.gentoo.org (Postfix) with SMTP id 67428E0A5C;
	Wed, 11 Dec 2013 22:46:33 +0000 (UTC)
Received: from mail-vb0-f52.google.com (mail-vb0-f52.google.com [209.85.212.52])
	(using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits))
	(No client certificate requested)
	by pigeon.gentoo.org (Postfix) with ESMTPS id 6F1B5E09E5
	for <gentoo-dev@lists.gentoo.org>; Wed, 11 Dec 2013 22:46:32 +0000 (UTC)
Received: by mail-vb0-f52.google.com with SMTP id p5so2107283vbn.39
        for <gentoo-dev@lists.gentoo.org>; Wed, 11 Dec 2013 14:46:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20120113;
        h=sender:date:from:to:subject:message-id:mail-followup-to:references
         :mime-version:content-type:content-disposition:in-reply-to
         :user-agent;
        bh=7YbxLEbt7UZDUsdAePmui3HvamF3WsqSnGiA2teZCYA=;
        b=k8GTTaiSg2GfJwkp8A/sEmVCml49RA3GEEHiSRuftTcE15M/feyB2jdecWd1o29S26
         MuNVe0vuDupvI0g6TXAojgy9QF41N6/zp5hQIidzMlHj21aAV51txhl0x7DTPSd+jW+b
         Ie+7wNN8mLeY/q2q98ghE2FzOCIF8nvBw6zI/2OvoxoYX6aFSn5goRL87eTxlA0xD/NY
         Eg3TKOF6Ljq83w/SB1S7r7brxy8VPaCdIhgBszo+5wRGOI06NZmoxuRkm6svwgSttzDY
         CXzwuIZFdGSENg4gCk69Ky3TKyly+Ztrr5fZjcOK5NuECfEsgYbRe6u+GFmxdjiKMSGg
         31rA==
X-Received: by 10.52.163.165 with SMTP id yj5mr1391178vdb.42.1386801991786;
        Wed, 11 Dec 2013 14:46:31 -0800 (PST)
Received: from linux1 (cpe-76-187-91-128.tx.res.rr.com. [76.187.91.128])
        by mx.google.com with ESMTPSA id dw6sm25031157ved.2.2013.12.11.14.46.29
        for <gentoo-dev@lists.gentoo.org>
        (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
        Wed, 11 Dec 2013 14:46:31 -0800 (PST)
Sender: William Hubbs <w.d.hubbs@gmail.com>
Received: by linux1 (sSMTP sendmail emulation); Wed, 11 Dec 2013 16:46:28 -0600
Date: Wed, 11 Dec 2013 16:46:28 -0600
From: William Hubbs <williamh@gentoo.org>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] Re: rfc: renaming "rc" binary in OpenRC
Message-ID: <20131211224628.GA30501@linux1>
Mail-Followup-To: gentoo-dev@lists.gentoo.org
References: <20131211204110.GA30092@linux1>
 <52A8CF7D.3090309@gentoo.org>
 <52A8D0B0.9010709@gentoo.org>
 <pan$d940e$5a1ff5d7$6bba616c$3cf9b956@cox.net>
Precedence: bulk
List-Post: <mailto:gentoo-dev@lists.gentoo.org>
List-Help: <mailto:gentoo-dev+help@lists.gentoo.org>
List-Unsubscribe: <mailto:gentoo-dev+unsubscribe@lists.gentoo.org>
List-Subscribe: <mailto:gentoo-dev+subscribe@lists.gentoo.org>
List-Id: Gentoo Linux mail <gentoo-dev.gentoo.org>
X-BeenThere: gentoo-dev@lists.gentoo.org
Reply-to: gentoo-dev@lists.gentoo.org
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="+QahgC5+KEYLbs62"
Content-Disposition: inline
In-Reply-To: <pan$d940e$5a1ff5d7$6bba616c$3cf9b956@cox.net>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Archives-Salt: 9254bb6f-0131-42e5-bb91-09cafe547595
X-Archives-Hash: 788fbba974066d0a4c327bc82ec4a881


--+QahgC5+KEYLbs62
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Wed, Dec 11, 2013 at 09:28:09PM +0000, Duncan wrote:
> Markos Chandras posted on Wed, 11 Dec 2013 20:53:04 +0000 as excerpted:
>=20
> > 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.
>=20
> >> 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.
>=20
> > +1
> >=20
> > The ebuild can grep the inittab and it if finds an "rc" there, just
> > print a huge warning telling the user to migrate || die.
>=20
> I think it's worth noting two small details of williamh's original mail=
=20
> that may have gone unnoticed:
>=20
> 1) He proposes seding the *LIVE* ebuild, which I take as meaning=20
> openrc-9999.
>=20
> 2) He then proposes p.masking an openrc release until a sysvinit release=
=20
> updating inittab, with the contrast between that and the LIVE ebuild=20
> proposal thus again emphasized.
>=20
> Question: How many people run the openrc-9999 LIVE ebuild, and given that=
=20
> it's masked and general gentoo policy is that people running live ebuilds=
=20
> should expect to keep the pieces of they can't handle occasionally=20
> unpredicted changes, how much should we actually worry about doing just=
=20
> that?

We don't have to worry about the live ebuild per se, I was more
concerned about what to do when the next release comes out.

Duncan, it sounds like you would know how to recover with the live
ebuild.

But, with the proposal of creating a symlink from /sbin/rc->openrc,
there would no longer be a reason to p.mask the next release, because
people would be able to upgrade. A news item would definitely be
appropriate though.

William


--+QahgC5+KEYLbs62
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iEYEARECAAYFAlKo60QACgkQblQW9DDEZTjbwgCeMyeUGWGwwodHuAyv+6y+z8lD
pG0AoKBnJzX8EqA0uw2DYtXzU7rwopUA
=Q/qQ
-----END PGP SIGNATURE-----

--+QahgC5+KEYLbs62--