Sam Hartman, Debian Project Leader, sort out the controversy associated with the delivery of the elogind package as part of the distribution. In July, the release team inclusion of elogind in the testing branch, as this package conflicts with libsystemd.
Recall that provides the interfaces needed to run GNOME without installing systemd. The project is based as a branch of systemd-logind, taken out in a separate package and freed from binding to systemd components. Including elogind provides its own version of the libelogind library, which takes on a number of functions offered in libsystemd and replaces this library during installation.
A conflict with the systemd package and the danger of replacing libsystemd with an alternative version of libelogind, which is completely incompatible with the original library at the ABI level, were noted as reasons for blocking.
The package flags elogind as conflicting with systemd libraries, but it is inherently designed to only work without systemd, and conflicting with systemd is even beneficial as it prevents you from installing elogind by mistake. On the other hand, in the current form, attempts to update the configuration via APT from systemd to the variant with sysvinit and elogind result in with broken APT. But even with this flaw fixed, the transition from systemd to elogind remains impossible without removing already installed user environments.
elogind developers had to adapt elogind to work on top of the regular libpam-systemd, without using its own libpam-elogind layer. The transition of elogind to libpam-systemd is hampered by the lack of support for the concept of slices, but the developers of elogind do not want to achieve full API compliance and exactly repeat all the features of systemd, since elogind only provides minimal functionality for organizing user login and does not aim to repeat all systemd subsystems.
The resolution of the described technical problems should be resolved at the level of interaction between the release team and the elogind and systemd maintainers, but the project leader was forced to intervene as 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 is right in its own way . According to Sam Hartman, the situation is approaching a state requiring a general vote (GR, general resolution), in which the community will decide on alternative systems to initialize and support sysvinit with elogind.
If project participants vote to diversify init systems, all maintainers will be involved in working together to solve this problem or special responsible developers will be assigned to work on this problem and maintainers will no longer be able to ignore an alternative init system, remain silent or drag out the process.
Currently in the repository already 1033 packages supplying service units for systemd but not including init.d scripts. To solve this problem supply service files by default, but prepare a handler that would automatically parse commands from these files and generate init.d scripts based on them.
If the community decides that Debian's support for a single init system is enough, they can stop worrying about sysvinit and elogind and focus only on unit files and systemd. This decision will negatively affect ports that do not use the Linux kernel (, ΠΈ ), but there are no such ports in the main archive yet and they do not have the status .
Linking to systemd will also make it much harder for the distribution to change direction in the future and limit further experimentation in provisioning and service management. Keeping elogind running is much easier than removing it and then trying to add it back. Each decision option has pros and cons, so before voting, a comprehensive discussion of all the arguments for and against will be required.
Source: opennet.ru