On Sun, 26 May 2013 12:57:42 +0200 Michał Górny 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. > 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*. > > > > openrc is *simpler* much *simpler* than systemd, stop with that. > > [SNIP] > > To make this point cleaner to you: what if the fallback ran systemd > instead? > > [SNIP] Why should the fallback be different from what stage3 provides? -- 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