From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id C8C5C138334 for ; Thu, 11 Jul 2019 00:19:26 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 38FC9E0905; Thu, 11 Jul 2019 00:19:23 +0000 (UTC) Received: from smtp.gentoo.org (dev.gentoo.org [IPv6:2001:470:ea4a:1:5054:ff:fec7:86e4]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id E32ECE08EF for ; Thu, 11 Jul 2019 00:19:22 +0000 (UTC) Received: from whubbs1.gaikai.biz (unknown [100.42.103.5]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: williamh) by smtp.gentoo.org (Postfix) with ESMTPSA id D08FB3476E1 for ; Thu, 11 Jul 2019 00:19:21 +0000 (UTC) Received: (nullmailer pid 8820 invoked by uid 1000); Thu, 11 Jul 2019 00:19:18 -0000 Date: Wed, 10 Jul 2019 19:19:18 -0500 From: William Hubbs To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] rfc: making sysvinit optional Message-ID: <20190711001918.GA8354@whubbs1.dev.av1.gaikai.org> Mail-Followup-To: gentoo-dev@lists.gentoo.org References: <20190710202528.GA24935@whubbs1.dev.av1.gaikai.org> <20190710214846.GA31047@whubbs1.dev.av1.gaikai.org> <20190710231614.GA3597@whubbs1.dev.av1.gaikai.org> <45d06884-b97c-6bcc-f254-93a5e6eb5f57@gentoo.org> <20190711000332.GA6104@whubbs1.dev.av1.gaikai.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 X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="/04w6evG8XlLl3ft" Content-Disposition: inline In-Reply-To: <20190711000332.GA6104@whubbs1.dev.av1.gaikai.org> User-Agent: Mutt/1.10.1 (2018-07-13) X-Archives-Salt: 6367f4d7-0e14-40bc-8734-c328f89a3ec6 X-Archives-Hash: 9c081c3d4de01985037449382de479c7 --/04w6evG8XlLl3ft Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I'm replying, because there is one more thing I want to add before I head out. On Wed, Jul 10, 2019 at 07:03:32PM -0500, William Hubbs wrote: > On Wed, Jul 10, 2019 at 07:30:57PM -0400, Michael Orlitzky wrote: > > On 7/10/19 7:16 PM, William Hubbs wrote: > > > 3. add a sysvinit use flag to openrc, which will be off by default. W= hen > > > it is on, openrc will block sysvinit since it will provide /sbin/init > > > and /sbin/shutdown. > > >=20 > >=20 > > This logic, or maybe the name of the flag, sounds backwards to me. I > > only get sysvinit when USE=3Dsysvinit is NOT set? >=20 > If you don't set sys-apps/openrc[sysvinit], you would have /sbin/init > and /sbin/shutdown as they are now, from sys-apps/sysvinit. >=20 > If you do set sys-apps/openrc[sysvinit], /sbin/init and /sbin/shutdown > would become wrappers for /sbin/openrc-init and /sbin/openrc-shutdown. >=20 > Actually, I'm thinking that the use flag can't happen until the next > OpenRC release, because I need to set up openrc-shutdown so it can shut d= own > a system that is booted with sysvinit first. >=20 > >=20 > >=20 > >=20 > > > RDEPEND=3D" > > > kernel_linux? ( > > > || ( > > > sys-apps/sysvinit Since sysvinit is first in the rdepend it will be the first choice to be installed. In other words, no systems would be affected unless they forcibly unmerge sysvinit. The others below are alternatives. > > > sys-apps/systemd > > > sys-apps/openrc > > > sys-process/runit > > > virtual/daemontools This one I need to look at, because I'm not actually sure if it provides an init. > > > ) > >=20 > > Modulo my first comment, you'll want some USE flag (un)set for > > sys-apps/openrc to ensure that /sbin/init is provided. >=20 > I am willing to be convinced, but I'm not sure all providers of a virtual > are required to provide the same binaries. A couple of examples off the > top of my head are virtual/editor, virtual/logger and virtual/mta. William --/04w6evG8XlLl3ft Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQTVeuxEZo4uUHOkQAluVBb0MMRlOAUCXSaAfAAKCRBuVBb0MMRl OLhNAJ9Xz+Tk7n55ZQulf0V4b28DzEXYwACgkYBHRuL8bNLWpZK8SVwm9ogU3bI= =lp43 -----END PGP SIGNATURE----- --/04w6evG8XlLl3ft--