Sam Hartman, the Debian project leader, tried to resolve disagreements regarding the delivery of the elogind package as part of the distribution. In July, the team responsible for preparing the launches blocked the inclusion of elogind in the test branch, since this package conflicts with libsystemd.
As a crash reason there was a conflict with the systemd package and the danger of overriding libsystemd with an alternate version of libelogind, which is completely incompatible with the source library at the ABI level.On elogind it is important to know that it provides the necessary interfaces for Gnome to work without installing systemd. The project is based as a branch of systemd-logind, extracted in a separate package and saved from the link to the systemd components.
The inclusion of elogind provides its own version of the libelogind library, which takes over a number of functions offered by libsystemd and replaces this library during installation.
In the package, elogind is marked as conflicting with the systemd libraries, but it is inherently designed to work only without systemd and a conflict with systemd is even beneficial as it does not allow you to install elogind by mistake.
On the other hand, in the current form, attempts via APT to update systemd configuration to version with sysvinit and elogind result in corrupted system with an inoperative APT. But even with the removal of this flaw, the transition from systemd to elogind is still impossible without removing already installed user environments.
Whereupon Elogind developers were asked to adapt eulogyd to work on top of the regular libpam-systemd, without using its own libpam-elogind layer.
The transition from elogind to libpam-systemd is hampered by the lack of support for the concept of sectors, but the developers of elogind do not want to achieve full API compliance and exactly repeat all the features of systemd as elogind only provides minimal functionality to organize user logins and it is not intended to repeat all subsystems of systemd.
Resolving the technical issues outlined should be resolved at the level of interaction between the release team and the maintainers of elogind and systemd, but the project leader was forced to intervene because the teams could not agree, the joint work turned into a confrontation and the solution to the problem reached a dead end, in which each side of the law in its own way.
According to Sam Hartman, the situation is approaching a state that requires a general vote (GR, blanket resolution), in which the community will decide on alternative systems to initialize and support sysvinit with elogind.
If project participants vote to diversify initialization systems, all those in charge of maintenance will participate in a joint effort to solve this problem or special responsible developers will be appointed to work on this issue and those accompanying them will no longer be able to bypass the alternate initialization system, remain silent, or delay the process.
Currently, the repository has already accumulated 1033 packages that provide units of service for systemd, but do not include init.d scripts.
To solve this problem, it is proposed to supply service files by default, but to prepare a driver that automatically parses the commands in these files and generates init.d scripts based on them.
If the community decides that Debian has enough support for a single initialization system, they no longer have to worry about sysvinit and elogind, focusing only on unit and systemd files.
Such a solution will negatively affect ports that do not use the Linux kernel, but there are no such ports in the main file yet and they do not have an official support status.
Linking to systemd will also significantly complicate the change in the direction of distribution development in the future and will limit further experimentation in the field of service initialization and management.
Each solution has its advantages and disadvantages, so a thorough discussion of all the arguments for and against will be required prior to the vote.