Results of the voting on initialization systems in Debian have been summarized

Published results general voting (GR, general resolution) of Debian project developers involved in package maintenance and infrastructure support, held regarding the question of supporting multiple init systems. The second option (‘B’) in the list won — the preferred choice remains systemd, but the possibility of supporting alternative init systems is retained. The voting was conducted by the method of Condorcet, where each voter ranks all options in order of preference, and when calculating the result, the number of voters who prefer one option over another is taken into account.

The winning option acknowledges that systemd service units are the preferred way to configure the launch of daemons and services, but concedes that there are environments in which developers and users can create and apply alternative init systems and functional alternatives to systemd capabilities. Developers of alternative solutions require resources to conduct their work and format packages. Alternatives, such as elogind, used to organize the launch of applications tied to interfaces specific to systemd, remain important for the project. Supporting such initiatives requires cooperation in areas where developed alternative technologies intersect with the rest of the project, for example, delaying the review of patches and discussions is unacceptable.

Packages may include both systemd unit files and init scripts for starting services. They can utilize any capabilities of systemd at the discretion of the package maintainer, provided that these capabilities comply with Debian policy and are not tied to experimental or unsupported functionalities from 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 commits to working with derivative distributions that choose other init systems, but the interaction occurs at the level of maintainers, who make decisions about which features prepared by third-party distributions to incorporate into the main Debian system, and which to leave in the derivative distribution.

Let’s remember that in 2014, the technical committee approved the transition of the default distribution to systemd, but did not develop a decision regarding support for multiple init systems (the point indicating the committee's unpreparedness to make a decision on this issue won in the vote). The committee leader recommended that package maintainers retain support for sysvinit as an alternative init system but indicated that he could not impose his viewpoint and that decisions should be made independently in each case.

After that, some developers attempted to conduct a general vote, but the preliminary voting showed no need to make a decision on the issue of using multiple init systems. Several months ago, after including the elogind package (needed for GNOME to work without systemd) into the testing branch due to a conflict with libsystemd, the issue was raised again by the leader of the Debian project, as the developers could not reach an agreement, and their communication escalated into opposition and reached a deadlock. issues Options considered:

Considered options:

The primary 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 the packages.

Systemd remains the preferred choice, but there is an opportunity to support alternative init systems. Technologies like elogind, which allow applications tied to systemd to run in alternative environments, are considered important. Init files for alternative systems may be included in the packages.

Support for various init systems and the ability to boot Debian with init systems different from systemd.
To run services, packages must necessarily include init scripts; supplying only systemd unit files without sysv init scripts is unacceptable.

Support for systems that do not use systemd is allowed, but without making changes that hinder development. Developers agree to support multiple init systems in the foreseeable future, but they also find it necessary to work on improving support for systemd. Development and maintenance of specific solutions should be handled by communities interested in such solutions, while other maintainers should actively assist and facilitate problem-solving when necessary. Ideally, packages should function with any init system, for which traditional init scripts can be supplied or other mechanisms that allow operation without systemd can be used. Inability to operate without systemd is regarded as a bug, but not a release-blocking bug, except in cases where a ready solution exists for operation without systemd, but is refused to be maintained (e.g., when the issue is caused by the removal of a previously supplied init script).

Support for portability without introducing changes that hinder development. Debian continues to be viewed as a link for integrating various software that provides equivalent or similar functionality. Portability between hardware platforms and software stacks is one of the important tasks, and the integration of alternative technologies is welcomed, even if their creators' views diverge from the general consensus. The position regarding systemd and other initialization systems fully aligns with point 4.

The transition of support for multiple initialization systems to a requirement. Allowing Debian to run with initialization systems other than systemd remains significant for the project. Each package must work with pid1 handlers other than systemd, unless the software included in the package is originally intended to work only with systemd and lacks support for running without systemd (the absence of init scripts is not considered a design for working solely with systemd).

Support for portability and multiple implementations. The general principles fully coincide with point 5, but no specific requirements are imposed regarding systemd and initialization systems, nor are there any obligations placed on developers. Developers are encouraged to consider each other's interests, make compromises, and find common solutions that are satisfactory for various parties.

Continuation of the discussion. The item may be used to lower the ranking of unacceptable options.

Source: opennet.ru