On 05/06/2014 08:08 AM, Tollef Fog Heen wrote: > ]] Zack Weinberg > >> On Mon, May 5, 2014 at 5:40 PM, Tollef Fog Heen <tfh...@err.no> wrote: >>> ]] Zack Weinberg >>>> Fundamentally what I want is a bulletproof procedure for reverting to >>>> sysvinit in case something goes wrong. >>> >>> Sounds like you're arguing that sysvinit-core should no longer ship >>> /sbin/init, then, so systemd-sysv doesn't have to conflict with it. >> >> Wouldn't that make the sysvinit implementation of /sbin/init >> completely unavailable? This is an earnest question. I do not have >> access to package contents right now. > > No, to revert you'd boot with init=/sbin/sysvinit.
Ah, I understand now. Yes, this + systemd-sysv and upstart *also* stop shipping /sbin/init (it becomes a symlink under control of the administrator) + documentation would be a satisfactory conclusion as far as I'm concerned. If we were to also move 'reboot' and friends to a shared utilities package, that might make the systemd-sysv package unnecessary. Ideally, also, if systemd is installed on a system that is currently running sysvinit, that doesn't change what /sbin/init points to; the administrator has to do that as a separate operation. This provides an additional bit of defense against unforeseen problems with local customizations -- the admin can look into them in their own time rather than immediately. >> Note that coinstallability is not enough -- the bulletproof procedure >> (e.g. "update-init-system") must also be implemented, shipped, and >> documented. > > I have still not seen any reason whatsoever for this to be a command > rather than just changing a configuration file. I have no problem with that. I suggested a command because I thought the switch might be more complicated than just changing what /sbin/init is symlinked to, but right now it looks to me like that should be enough. zw
signature.asc
Description: OpenPGP digital signature
