Bug#727708: Processed: block 726763 with 727708
On Sat, Feb 01, 2014 at 06:21:13PM -0800, Cameron Norman wrote:
> 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.
There are a few reasonable possibilities for that; see my comments in
#736678.
I don't particularly like the convention of passing init=, for much the
same kind of reason as I'm in favour of the injunction in
http://www.debian.org/doc/debian-policy/ch-opersys.html#s9.9 that a
program "must not depend on environment variables to get reasonable
defaults"; the set of boot parameters is user-visible configuration, and
I think that the preferred init on any given system, not to mention
Debian's default, should be the default value. I can understand the
pragmatic reasons for systemd being hooked in using init= while it's a
non-default system trying to gain acceptance and to be easy to
experiment with on an ad-hoc basis, but as a GRUB maintainer I would
prefer that GRUB not need to be involved in the establishment of a
default. Furthermore, not everyone uses GRUB and it's going to be
pretty tedious to go round all the boot loaders.
The de facto interface for making an init system the default is to
install it as /sbin/init. While I'm coming at this from a starting
point different from Cameron's above - I haven't yet decided whether I
think it would be good for packages to be able to depend on specific pid
1 implementations - nevertheless, if we select systemd as the default I
would argue that there should be some arrangement in packaging to put it
in place as /sbin/init, even if that isn't upstream's advertised method.
--
Colin Watson [cjwatson@debian.org]
Reply to: