The results of the vote on Debian init systems have been summed up

Published findings general voting (GR, general resolution) of the Debian project developers involved in package maintenance and infrastructure maintenance, carried out on the issue of supporting multiple init systems. The second item (“B”) in the list won - systemd remains preferred, but the possibility of maintaining alternative initialization systems remains. Voting was carried out using the method Condorcet, in which each voter ranks all options in order of preference, and when calculating the result, it is taken into account how many voters prefer one option to another.

The winning proposal acknowledges that systemd service units are the preferred way to configure daemons and services to run, but acknowledges that there are environments in which developers and users can create and use alternative init systems and functional alternatives to systemd's capabilities. Developers of alternative solutions require resources to carry out their work and format their packages. Alternative solutions like elogind for running applications bound to systemd-specific interfaces remain important to the project. Supporting such initiatives requires assistance in areas where developing alternative technologies intersect with the rest of the project, such as delaying patch review and discussion.

Packages can include both systemd unit files and init scripts for starting services. Packages may use any systemd features the package maintainer wishes, as long as the features comply with Debian rules and are not tied to experimental or unsupported Debian features in other packages. In addition to systemd, packages may also include support for alternative init systems and provide components to replace systemd-specific interfaces. Decisions regarding the inclusion of patches are made by maintainers as part of standard procedures. Debian is committed to working with derivative distributions that choose to use other init systems, but the interaction is built at the maintainer level, which makes decisions about which features prepared by third-party distributions are accepted into the main Debian composition and which ones are left in the derivative distribution.

Let us recall that in 2014 the technical committee approved transition default distribution on systemd, but not worked out decisions regarding support for multiple provisioning systems (the item indicating the committee's unwillingness to make a decision on this issue won the vote). The committee leader recommended that package maintainers maintain support for sysvinit as an alternative init system, but indicated that he could not impose his point of view and that the decision should be made independently in each case.

After this, some developers attempted attempt to carry out general vote, but preliminary voting showed that there was no need to make a decision on the issue of using multiple initialization systems. A few months ago, after problems with the inclusion of the elogind package (necessary for running GNOME without systemd) in the testing branch due to a conflict with libsystemd, the issue was again raised by the Debian project leader, since the developers could not agree, and their communication turned into a confrontation and reached a dead end.

Options considered:

The main focus is on systemd. Providing support for alternative init systems is not a priority, but maintainers may optionally include init scripts for such systems in packages.

systemd remains preferred, but the possibility of maintaining alternative initialization systems is left. Technologies such as elogind, which allow applications bound to systemd to run in alternative environments, are seen as important. Packages may include init files for alternative systems.

Support for a variety of init systems and the ability to boot Debian with init systems other than systemd.
To run services, packages must include init scripts; supplying only systemd unit files without sysv init scripts is unacceptable.

Support for systems that do not use systemd, but without making changes that would hinder development. The developers agree to support multiple init systems for the foreseeable future, but also believe it is necessary to work on improving systemd support. The development and maintenance of specific solutions should be left to the communities interested in those solutions, but other maintainers should actively help and contribute to problem solving when the need arises. Ideally, packages should function using any init system, which can be achieved by supplying traditional init scripts or using other mechanisms that allow them to work without systemd. The inability to work without systemd is considered a bug, but not a release-blocking bug, unless there is a ready-made solution for working without systemd, but it is refused to be saved (for example, when the problem is caused by the removal of a previously supplied init script).

Supports portability without introducing changes that hinder development. Debian continues to be seen as a bridge for integrating different software that provides equivalent or similar functionality. Portability between hardware platforms and software stacks is an important goal, and the integration of alternative technologies is encouraged, even if the worldview of their creators differs from the general consensus. The position regarding systemd and other initialization systems completely coincides with point 4.

Making support for multiple initialization systems mandatory. Providing the ability to run Debian with init systems other than systemd continues to be important to the project. Each package must work with pid1 handlers other than systemd, unless the software included in the package was originally intended to work only with systemd and does not support running without systemd (the absence of init scripts does not count as intended only for working with systemd).

Supports portability and multiple implementations. The general principles are exactly the same as point 5, but there are no specific requirements for systemd and init systems, and no obligations are imposed on developers. Developers are encouraged to take into account each other's interests, make compromises and find common solutions that are satisfactory for various parties.

Continued discussion. The item can be used to downgrade unacceptable options.

Source: opennet.ru