Bug#727708: Processed: block 726763 with 727708
Cameron Norman <camerontnorman@gmail.com> 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 (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: