On 2 May 2013 15:18, William Hubbs <[email protected]> wrote: > Like I've already said too, I don't see that we need to do this change. > > Systemd is called /usr/lib/systemd/systemd (it should be > /lib/systemd/systemd), and sysvinit is called /sbin/init,, so I don't > see the need for moving init around and creating all of these symlinks. > > I guess I'm not completely opposed to it, I just want you to convince me > that doing it has value. Where I am now is I feel like it adds > complexity for almost no gain. > > William > > The best arguments I have for the symlink approach, are:
- its a consistent approach that is bootloader agnostic - it doesn't require you to understand your bootloaders scripting system to add it to the init= line - its "no brains required, and hard to mess up" bootloader configuration under grub1 for instance, was quite straight-forward. Now with grub-2, its quite convoluted, for me at least. Its also sometimes a bit confusing if you need something other than /sbin/init as your "init", because sometimes you need some pre-init stuff ( like genkernel does ), and you need some /other/ parameter other than init= so that the pre-init still runs and then passes over to init Having a symlink that will just do the right thing is helpful for these cases. Against, the symlink may introduce parts that are breakable, like if user messes up and places the destination of the symlink on a different partition ( shouldn't be a problem, but might be ), or if you're doing an initird that has init baked into it, you'd have to regenerate that initrd after changing the symlink ( I think, maybe not, its probably not even a problem, its just something I'd have to check ) And also, if for whatever reason systemd becomes "unbootable" it might be slightly hard to boot with the "right" init if you can't change kernel parameters during boot time. But noted, those last 2 "against" reasons are "edge cases", where the arguments for it are "majority cases", so collectively I'm still in favour of the eselect + symlinks approach. -- Kent
