>>>>> "Michael" == Michael Biebl <bi...@debian.org> writes:
Michael> On Wed, 30 Oct 2019 13:22:14 +0000 Ian Jackson
Michael> <ijack...@chiark.greenend.org.uk> wrote:
>> The bulk of the bug is a discussion about the general approach to
>> allowing Debian users to choose between systemd and elogind (and,
>> therefore, allowing them to run desktoppy kind of software
>> without systemd). As discussed it seems that this C/R/P is
>> needed to implement the approach which was agreed between the
>> elogind and systemd maintainers.
Michael> I very much disagree with this summary.
Michael> In [1] I clearly expressed that I did not like this
Michael> approach of having a libelogind0 which replaces
Michael> libsystemd0.
That's actually not how I read that discussion.
I read you as grumblingly accepting the necessity of libelogind0 after
Mark explained that it was necessary because of the upstream design.
I suspect I'm not the only one who honestly read what you said as
accepting elogind0 even though it was not your preference.
Michael> I think the best option is still the one I outlined in [1],
Michael> i.e. getting rid of libelogind0 completely in Debian and
Michael> simply ensure that elogind works in combination with
Michael> libsystemd0.
That's inconsistent with the design of elogind.
Mark explored doing that in this bug and outlined why that doesn't work.
Summarizing for those less familiar with libsystemd0 than Michael:
libsystemd0 splits its interface to systemd across a number of things.
A lot of it is in a dbus API.
However, it also assumes a certain structure of how cgroups are layed
out.
Elogind does implement the dbus APIs in question.
However elogind lays out cgroups differently.
So key functionality does not actually work if you use libsystemd0 iwth
elogind.
Asking the Debian elogind maintainer to redesign elogind seems like kind
of a tall ask.
I agree that using libsystemd0 only would be a great option *if it
worked*
