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 [cjwat...@debian.org] -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140202110625.ga17...@riva.ucam.org