Adrian Bunk <bunk@stusta.de> writes: > There are at least three tricky areas: > > 1. init systems will have to cope with packages supplying init scripts > in several formats they support. This doesn't seem that tricky to me. If a package provides init functionality in the preferred native format for a given init system, that would take precedence over functionality provided in a supported but not preferred format, right? > 2. How to ensure that both systemd systems and non-systemd systems > work equally well? This for me immediately gets hung up in how one defines "equally well", as expectations are clearly going to differ between init systems. > If dependencies like "installing GNOME enforces systemd as init system" > would be legal, then after a few more such dependencies it would turn > out that systemd will be the only option available for virtually all > users - and that all the hassle of supporting multiple init systems > was a waste of effort. Please be careful about stacking assumptions like this. Equating GNOME to "virtually all users" completely ignores the vast number of Debian instances on servers, virtual machines, and embedded systems. And even if you only think about client systems, in my own circle of friends there's a lot more XFCE4 than GNOME these days. > 3. Switching init systems after installation. > Assume I am currently using systemd. > What is supposed to happen when I do "apt-get install sysvinit-core"? That's a great question. I suspect most of the effort in thinking about init system transitions so far has gone in to figuring out how to replace sysvinit. But if we're truly going to support alternatives, ensuring we have a robust mechanism for deciding which of several init systems that may be simultaneously installed is "active" and will control the next boot is clearly a requirement. Bdale
Attachment:
pgpmHcw2DFssF.pgp
Description: PGP signature