On Sat, 25 May 2013 11:54:48 +0200 Luca Barbato wrote: > Hi, since the whole discussion got somehow sidetracked on where and if > to install for everybody the rc system specific files for everybody > (that should be an implementation detail for the specific dohelper > IMHO), I'm back to the other part of it: switching the actual init > implementation. > > # WHY (not just edit your bootloader) > > Since efi at least some people started to put in the kernel the bootargs > and we have at least few new options brewing for init, some are > small impact (bootchar, bb-init-openrc and runit-openrc) some are more > invasive (runit and systemd). > > In those setup changing bootargs requires a kernel rebuild and some > effort, while the eselect approach stays completely transparent. > > For some switch we might not have just to change the init binary bit > also to do some other changes (e.g. use a different format for inittab) If you can't change options at boot time it's very simple to get unbootable system. Just curious, who does such systems and how root filesystem (+ it's mount options) is expected to be found there? I guess EFI allows you to set bootargs via EFI UI. I'd go for init=/sbin/gentoo-init and make all the messy stuff there. Otherwise by breaking /sbin/init it would be hard to find proper name of, say, SYSVs /sbin/init. How would you call it? > # KEYPOINTS > > - /sbin/init (or whatever linux currently calls by default with top > priority) should be either a symlink to the actual implementation or a > wrapper such as our gcc one. I like better the latter since it is > overall safer. The former might or might work since linux has some > fallback capabilities but hadn't been tested. > > - init gets effectively switched only at boot/reboot, eselect init must > keep track of the current active init and make sure the current init > configuration is used till the system reboots, if we use the wrapper > approach, it would pick up what's the new init at boot and that would be > enough for simple cases, hooks on reboot are still needed for more > complex ones. > > - we could try to not have the changes to the current init systems > ebuild or reduce them to the bare minimum (e.g. not overwrite /sbin/init) > > # FOCUS > > My interest is mostly if not all on bb-init-openrc and slightly on > runit-openrc. > > There are enough people involved in systemd and since I still consider > it a dangerously frail implementation of a bad idea is better if I do > not touch it at all. > > My system with stock openrc gets from linux start to graphical login in > less than 6s and I'm not using Gnome so I do not have any reason to use > it beside comparing. > > lu > > -- Sergei