Sam Hartman, the leader of the Debian project, to clarify the disagreements surrounding the inclusion of the elogind package in the distribution. In July, the team responsible for preparing releases, the inclusion of elogind in the testing branch, as this package conflicts with libsystemd.
Recall that provides the necessary interfaces for running GNOME without installing systemd. The project is based as a fork of systemd-logind, moved to a separate package and freed from dependencies on systemd components. In particular, elogind offers its version of the libelogind library, which takes on several functions offered in libsystemd and replaces this library upon installation.
The reasons for the blocking included a conflict with the systemd package and the risk of replacing libsystemd with an alternative version of libelogind, which is completely incompatible with the original library at the ABI level.
The elogind package is marked as conflicting with systemd libraries, but it is essentially designed to work only without systemd, and the conflict with systemd actually serves a benefit, as it prevents the erroneous installation of elogind. On the other hand, attempts to update the configuration from systemd to the sysvinit and elogind option through APT lead to a with a non-functioning APT. However, even with this issue resolved, switching from systemd to elogind remains impossible without removing already installed user environments.
The developers of elogind were to adapt elogind to work on top of the standard libpam-systemd, without using their own libpam-elogind layer. The transition of elogind to libpam-systemd is hindered by the lack of support for the concept of slices, but the elogind developers do not wish to achieve full API compliance or to precisely replicate all of systemd's capabilities, as elogind only provides minimal functionality for user login management and does not aim to duplicate all of systemd's subsystems.
The resolution of the described technical issues should be handled at the level of interaction between the release team and the maintainers of elogind and systemd. However, the project leader had to intervene because the teams could not reach an agreement, and their collaboration turned into confrontation, leading to a deadlock where each side is right in its own way. According to Sam Hartman, the situation is approaching a state that requires a general resolution (GR), where the community will decide on alternative initialization systems and support for sysvinit with elogind.
If project participants vote for the diversification of initialization systems, all maintainers will be involved in collaborative work on this task or special responsible developers will be appointed to address this issue, and maintainers will no longer be able to ignore the alternative initialization system, remain silent, or delay the process.
Currently, there are already 1033 packages supplying service units for systemd but not including init.d scripts. To address this issue, service files should be supplied by default, but a handler should be prepared that automatically parses commands from these files and generates init.d scripts based on them.
If the community decides that Debian only needs support for one initialization system, they can stop worrying about sysvinit and elogind, focusing only on unit files and systemd. This decision would negatively impact ports that do not use the Linux kernel (, and ), but there are currently no such ports in the main archive, and they do not have the status of .
Tying to systemd will also significantly complicate the future direction of the distribution and limit further experiments in initialization and service management. Maintaining elogind in working condition is significantly easier than removing it and attempting to add it back later. Each solution option has its pros and cons, so comprehensive discussion of all arguments for and against will be necessary before voting.
Source: opennet.ru
