Cameron Norman <[email protected]> writes: > I think there is a huge problem with recommending that systemd be > installed by the user changing the init line in grub: a package can not > depend on an init system being PID 1. Can a package be made that changes > the init line to systemd? I think that is preferable, because it folows > the upstream convention of installing systemd by changing the init > value, while also allowing packages to depend on systemd being PID 1.
I'm not sure that it's ever going to be sane for simple installation of a package with no further admin interaction to change your init system. If we're going to support multiple init systems going forward, I think we're going to need to figure out some approach to changing the init system that requires *something* besides a package installation. If packages aren't allowed to depend on the functionality of any specific init system, there are various straightforward approaches to this, of which systemd is one that seems reasonable to me. If we do introduce package dependencies on specific functionality, we need to think about how to do this properly. I *like* systemd, and I would still be very unhappy if a routine aptitude upgrade (or even a dist-upgrade) of a system currently running sysvinit suddenly resulted in running systemd without some sort of critical debconf question or the like. Maybe we can handle this by having a package that changes the default init system but have it throw a critical debconf prompt and fail to install if installed noninteractively. -- Russ Allbery ([email protected]) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
