Similarly to how we don't install shells to /bin/sh, I believe it would be beneficial to install the sysvinit executable as /sbin/sysvinit and a /sbin/init symlink pointing to it. This will allow our users to easily switch the target of /sbin/init without requesting them to fork sysvinit package or do modifications of PM-owned files.
I am strongly against this. I see no benefit to our users. The only thing I see this doing is paving the way for eselect-sysvinit, which is a step backward, because it adds another layer of things that have to be set right and thus another way things can go wrong. @vapier: As a member of base-system myself, if you agree, I would like to close this wontfix.
I suppose a compromise here would be to ask upstream to rename "init" to "sysvinit", but I do not believe we should do something like this at the distro level. (In reply to comment #0) > Similarly to how we don't install shells to /bin/sh, I believe it would be > beneficial to install the sysvinit executable as /sbin/sysvinit and a > /sbin/init symlink pointing to it. > > This will allow our users to easily switch the target of /sbin/init without > requesting them to fork sysvinit package or do modifications of PM-owned > files. We already don't ask them to do either of these things, so this argument is irrelevant. We ask them to add extra entries to their boot loader configuration file, which is not pm-owned.
I got asked to point out that some EFI setups use directly efi-stub with no bootloader. In that situation you rely on the hard-coded kernel command line and would be useful having the whole eselect-init and related machinery set in place.
(In reply to comment #1) > I am strongly against this. I see no benefit to our users. The only > thing I see this doing is paving the way for eselect-sysvinit, which is > a step backward, because it adds another layer of things that have to be > set right and thus another way things can go wrong. > > @vapier: > As a member of base-system myself, if you agree, I would like to close > this wontfix. users will notice no difference. using eselect-sysvinit is not mandatory either. I am not saying i am in favor of having it but this is orthogonal to this bug. i believe that what Michal is requesting makes sense.
(In reply to comment #3) > I got asked to point out that some EFI setups use directly efi-stub with no > bootloader. > > In that situation you rely on the hard-coded kernel command line and would > be useful having the whole eselect-init and related machinery set in place. How about not requiring it for everyone, but only using it where it is needed unless upstream sysvinit is willing to rename the init binary?
not really interested for all the reasons already outlined in bug 465236
