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 A2A9B1381F3 for ; Sun, 26 May 2013 12:00:31 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 1A6ACE0CE3; Sun, 26 May 2013 12:00:24 +0000 (UTC) Received: from gerard.telenet-ops.be (gerard.telenet-ops.be [195.130.132.48]) by pigeon.gentoo.org (Postfix) with ESMTP id BE731E0B67 for ; Sun, 26 May 2013 12:00:22 +0000 (UTC) Received: from TOMWIJ-GENTOO ([94.226.55.127]) by gerard.telenet-ops.be with bizsmtp id gc0M1l00W2khLEN0Hc0Mzu; Sun, 26 May 2013 14:00:21 +0200 Date: Sun, 26 May 2013 13:58:20 +0200 From: Tom Wijsman To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] eselect init Message-ID: <20130526135820.17e12159@TOMWIJ-GENTOO> In-Reply-To: <20130526125742.4584d094@gentoo.org> References: <51A08A68.3020900@gentoo.org> <20130526084332.1a8afa69@gentoo.org> <51A1DC0C.2070706@gentoo.org> <20130526125742.4584d094@gentoo.org> X-Mailer: Claws Mail 3.9.0 (GTK+ 2.24.18; x86_64-pc-linux-gnu) 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: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/C+v5nXfrxXSj3W7IPaA0ACJ"; protocol="application/pgp-signature" X-Archives-Salt: e89a551f-8c2c-4680-afe5-92ffc383c75e X-Archives-Hash: 87571bfa1d03b68661ef443725425c62 --Sig_/C+v5nXfrxXSj3W7IPaA0ACJ Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sun, 26 May 2013 12:57:42 +0200 Micha=C5=82 G=C3=B3rny wrote: > Switch inittab? Now you added really dangerous behavior to the wrapper > code. I can hardly even express this in words. It doesn't need to be in the wrapper, inittab is something read at boot only as far as I am aware and therefore eselect can do it. > You are telling me that a wrapper, a thing that gets executed *every* > boot needs to do some random magic to know which init system was in > use and which one is supposed to be in use, and then conditionally > move around configuration files necessary for it to run. This is just > *INSANE*. > > Did anyone notice already that moving stuff around actually requires > rootfs mounted R/W? Which means the wrapper needs to repeat a fair bit > of init/RC work. The wrapper only needs to read stuff, I see no reason for it to write stuff. It needs to read which init it needs to kick off, nothing more than that; if more is needed, please elaborate in full detail. =20 > And what will happen if moving the files fail? Which files? Since eselect would move them, we would be aware that it failed and could possibly rollback. > What if half of configuration belongs to old init, and half to new? Given a rollback, I don't see this happen; unless the rollback fails... > And it all happens automagically on boot, on an incomplete system > without any console started, without Internet connection established > and without any serious mean of help. Barely anything needs to happen on boot, stop adding complexity; the wrapper is meant to be simple, not another init system on its own. People are having way to different ideas about the wrapper, this is not good; I think people should start to express their ideas in documents, same with the symlink solutions. These "everything in the wrapper, everything on reboot" assumptions are running out of hand. > > > I use systemd for a few months now, and last time I checked openrc > > > boots somehow. But considering the general complexity of it, I > > > wouldn't be much surprised if it failed in funny ways (like not > > > being able to handle automounts properly), caused cruft on the > > > filesystem or even caused *damage*. > >=20 > > openrc is *simpler* much *simpler* than systemd, stop with that. >=20 > [SNIP] >=20 > To make this point cleaner to you: what if the fallback ran systemd > instead?=20 >=20 > [SNIP] Why should the fallback be different from what stage3 provides? --=20 With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : TomWij@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D --Sig_/C+v5nXfrxXSj3W7IPaA0ACJ Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (GNU/Linux) iQEcBAEBAgAGBQJRofjcAAoJEJWyH81tNOV9rTwH/1wZEUkEK7JeLdXq27iZ8hEz nkmFGRJbCmSm1I5Y9dyt6J93cE2cCrgHhiKFnTRGgR0lrk7kMSNH9X4az5niBOzJ D6QcsHAIFkx3zts65w50IoeKzc0fOkMaRs1zgfGfxD3Jp1DTQIDmt4QYPmataIhe jhvy2sGErWwLIwLXdGlQsT0NloF6v8MwVGT+4P43a8ZIgAPrcCSr83V+uyt63YvS lS4BSBE+xo5uSLy9WEDh0e8nRCcc1Ur0CtRiUHgvr8tNIrvakqsHea61HzIx+cd/ 3Z383ZetXfd8w14jkXcuh5gggiZbWx8Xd1Anh0cKCvw5V9RUoosMmylcs6IdHn0= =Bsk0 -----END PGP SIGNATURE----- --Sig_/C+v5nXfrxXSj3W7IPaA0ACJ--