On Thu, 28 Feb 2019 at 12:06:15 +0000, Dmitry Bogatov wrote: > currently, inclusion of new init system into Debian requires inclusion into > pre-dependency of bin:init package, which is unsatisfactory. > > As can be followed in #838480, current practice puts maintainer of any > new init system to be included into Debian at disadvantage, essentially > granting maintainer of bin:init (which happens to be `systemd' team now) > veto right. According to Constitution 3.1, individual developer poses > power of descision making only with regard their /own/ work. > > Hereby, I ask TCCE to provide requirements init system must satisfy that > /warrants/ inclusion into pre-dependency of essential bin:init. > Alternatively, I ask to consider introducion of virtual package > 'init-system'.
We discussed this at last month's technical committee meeting (sorry for the delay in replying - I've been busy IRL, and so was the person previously asked to reply). Committee consensus ------------------- Yes, we agree that the maintainers of the init-system-helpers package (which builds the init binary) have a gatekeeper role for making init systems as straightforward to install to /sbin/init as e.g. sysvinit is. We don't consider this to be a problem. They seem to be applying due scrutiny and care to this process, based in part on experience that they gained during systemd's time as an unsupported/non-default init system. We would recommend that the init-system-helpers maintainers should document their requirements for being an alternative pre-dependency of init, for instance in init's README.Debian. I'll mention some possible criteria further down this mail, but those are not part of the committee consensus (and detailed design work is, constitutionally, not a function of the technical committee, although some of us might be able to provide useful suggestions in our personal/non-TC roles, and I have tried to do so). It is entirely possible to include init systems in Debian without being pre-dependencies of init: for instance, at the time systemd was made available as a non-default init during the wheezy release cycle, the recommended mechanism to use it was to boot with init=/bin/systemd. People who are interested in trying new init systems that are not pre-dependencies of init can do the same, and we would recommend structuring runit packaging to make this possible if it isn't already. (For example, systemd was available and worked well in wheezy, but was most straightforward to test by using init=/bin/systemd; the systemd-sysv package, which makes systemd provide /sbin/init, couldn't be installed without applying force until part way through the jessie release cycle.) Another way to use an init system that is not a pre-dependency of init is to override the Important flag and remove init. I think we have a consensus that we consider this to be a feature, not a bug: it provides an indication that this particular non-default init system is unlikely to be suitable for people who do not know for sure that they want it. We do not consider an init-system virtual package to be a suitable solution here. My personal suggestions ----------------------- As a general operating principle, I think adding a new init system to the pre-dependencies of init should only be done when the init system is definitely entirely ready for general use, and has already been tested on a variety of systems by multiple people (by alternative mechanisms like booting with init=/sbin/my-init or overriding the Important flag to uninstall the init package); so modifying init should be the last step in enabling a new init system. I don't think there should be a presumption that Debian should consider every init system that has been packaged to be equally important or equally strongly supported, and if it isn't obvious that a new init system is ready for wide use, then it probably isn't. Some criteria that the init-system-helpers maintainers might like to consider, which I believe are all satisfied by systemd and sysv-rc, and were satisfied by upstart before it was removed from the archive: * If the init system is booted in the most obvious way on a simple TUI system (similar to a default Debian install with Priority: standard packages), it should start at least one console getty on a VT for interactive login, without the sysadmin needing to set this up manually. * It should be possible to configure the init system to provide a getty on a serial console, for testability on headless servers and VMs, and it should be documented how to do this. (systemd makes this very convenient, by starting a getty on the kernel console by default, and I would encourage this approach. sysvinit is less convenient here, but does at least have a relatively well-known way to enable a getty on a serial console.) * If the init system is booted in the most obvious way on a simple GUI system, it should be possible to start an X11 display manager and log in to a simple X11 GUI by merely installing packages, again without needing manual setup. I think it's fine to have non-default init systems that don't satisfy the dependencies of major desktop environments like GNOME and KDE (which need systemd-logind, which in turn needs systemd), but something like xdm + openbox should always be possible, and ideally any desktop environment whose dependencies are met should work without further sysadmin intervention. * If the init system is booted in the most obvious way on a server with popular/important server daemons (particularly OpenSSH since that's a common way to log in, but also things like Apache httpd, Exim, Postfix, PostgreSQL, dbus-daemon), then those server daemons should work correctly without further sysadmin intervention. * As a "lowest common denominator" to enable the majority of services to work, the init system should be able to run services that are defined by LSB init scripts, either directly (as sysv-rc does) or by translating them into its own representation of a service (as systemd does). * It should be straightforward for maintainers of unrelated packages to boot the init system on a virtual machine for testing. I see that on #838480, Martin Pitt suggested an autopkgtest that would codify how to do this and verify that it works, and I think that's an excellent idea. * The init system should have a CLI broadly compatible with the common interface of sysvinit and systemd: reboot, poweroff, telinit and so on. Unfortunately this is mostly defined by Unix folklore rather than a formal specification, but comparing the commands provided by sysvinit and systemd would be a good starting point, and so would comparing each of sysvinit and systemd with the list of executables mentioned in the FHS. I agree with your comment on #838480 that shutdown's time specification feature is perhaps more complicated than you would want to implement, but it might be reasonable to consider implementing it so all time specifications other than 'now' are errors? * The init-neutral commands in init-system-helpers (invoke-rc.d, service, update-rc.d) should have their expected functions with the new init system: as a minimum, they should be able to register and invoke LSB init scripts. Conveniently, init and init-system-helpers are built by the same source package. The init maintainers might also want to consider having weaker criteria for experimental than for unstable (or conversely, stricter criteria for unstable than for experimental), so that early adopters can use a version from experimental. I don't think that having a mechanism analogous to systemd's "shadowing" (where a native systemd unit foo.service is used in preference to a LSB init script /etc/init.d/foo, and is assumed to replace and supersede the LSB init script) should necessarily be a requirement, but I do think it's an excellent idea, and I would encourage its use. I don't think it's wise (or scalable) to expect the init maintainers to do the work of supporting and debugging non-default init systems. Their most important role in Debian is to make sure that the init systems of normal Debian installations work well: in terms of providing the most benefit to the most users, it is very likely that time they spend on supporting non-default init systems is less effective than spending the same amount of time on the default init system. If people want to maintain alternative init systems then that's great, but the onus should be on those people to prevent their init system from becoming a burden on the project - the same way the systemd maintainers spent a lot of time on system integration work before systemd became a supported init system, and continue to do so now that it is the default. smcv