On Thu, May 02, 2013 at 04:26:06PM +1200, Kent Fredric wrote:
> - 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"

Why should we do something "boot loader agnostic" for the init
system when editing config files is something that all gentoo
users/sysadmins are expected to understand?

> bootloader configuration under grub1 for instance, was quite
> straight-forward. Now with grub-2, its quite convoluted, for me at least.

I haven't looked at grub2 yet, but I can't imagine it being convoluted
based on the documentation I have read.

> 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
 
Now you are talking about an initramfs, and no symlink is going to take
care of that.

You also still have to keep your boot loader configuration up to date
whenyou upgrade your kernel.

> Having a symlink that will just do the right thing is helpful for these
> cases.

I don't see how the symlink is going to help anything since it doesn't
preclude you editing your boot loader configuration.

> 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.
 
 If this does ever hit the tree, I think it should be defaulted to off
 and users should be able to turn it on if they want.

 William