Actively blocking fixes
Actively blocking fixes
Posted Nov 12, 2019 10:37 UTC (Tue) by kilobyte (subscriber, #108024)Parent article: Debian reconsiders init-system diversity
The problem is not the lack of people willing to do the work, it's people actively refusing to merge ready, tested patches that don't fit within a maintainer's wishes. For example: a comprehensive set for patches for logind/policykit have been around since January 2018 (based on consolekit, later elogind), yet despite repeated requests there was no real response until just before Buster's freeze, when suddenly we received a demand for a thorough rework (so instead of co-installable libelogind it had to be made to reimplement full libsystemd ABI). Which then was rejected based on the change being too big and complex. In the result, Buster is mostly unusable in a GUI.
There are attempts to remove well-working pieces of software just because they're useful with modular inits rather than systemd (example: #930869 -- a RC bug with refusal to name any actionable problems), while "breaks the whole system, and requires a near-complete reinstall to switch inits" (#930105 instead got insta-downgraded+closed+WONTFIXed.
Within Debian's current model, it takes just a single hostile maintainer to block system-wide functionality.
Posted Nov 12, 2019 13:47 UTC (Tue)
by bigon (subscriber, #57617)
[Link] (9 responses)
IMVHO the problem lies in this comment elogind is developed by gentoo and in the gentoo world recompiling is not a problem. In binary distributions like debian it's a problem. And allowing to replace library packages is calling for troubles and will not make a distribution more robust. I'm still thinking that it's elogind daemon that should stub/mock the behavior of logind
Posted Nov 12, 2019 14:14 UTC (Tue)
by kilobyte (subscriber, #108024)
[Link] (6 responses)
Posted Nov 12, 2019 14:34 UTC (Tue)
by bigon (subscriber, #57617)
[Link] (4 responses)
Posted Nov 12, 2019 18:04 UTC (Tue)
by smurf (subscriber, #17840)
[Link] (3 responses)
elogind and systemd do their cgroups layout in a completely different way; teaching one library / daemon to interpret / layout these data in a way that the other can read it is not going to happen. Elogind isn't going to implement systemd's cgroups features, systemd cannot use elogind's layout even if it wanted to because it doesn't support its feature set, neither library reads the other's data, and AFAIK nobody is doing any work to implement any of that.
Simply put, these two implementations cannot co-exist. libelogind can be used as a libsystemd stub but this will only work on a system running elogind.
The only way to get this to work in some stable kind of way (that I can see, anyway) would be a stub init that checks which real init should run, re-links the libsystemd0 symlink to point to either libsystemd0.whatever-version.so or libelogind.some-other-version.so, and execs the real init. Good luck doing that if [/usr]/lib should happen to be readonly. Oh yes, you'd also need to prevent ldconfig to overwrite the link, prevent dpkg to remove the "wrong" library if the "wrong" init is running, and probably some other problems I haven't thought of.
Summary: it's time to throw in the towel. Just declare systemd to be *the* supported init and be done with this mess. Anybody who still wants to run current Debian on non-current-Linux kernels would need to do some sort of fork, their problem (unfortunately!).
The amount of effort to accommodate non-systemd Debian machines has been staggering, but IMHO we've learned that it's too much effort for too little gain to be sustainable.
Posted Nov 13, 2019 7:13 UTC (Wed)
by zuki (subscriber, #41808)
[Link]
My conclusion is similar to the debian release team: there is no sane way to try to substitute libsystemd that would not break programs linking to it. Trying to do it live on a running system is madness. That library implements dbus and device queries and logging and an event loop, and putting in stubs is never gonna fly.
On the other hand, the original design to keep libsystemd, but replace the part behind the dbus boundary, i.e. logind with elogind, will not work either, because various libsystemd functions look at the cgroup layout.
The only solution that would IMHO work would be to make elogind use compatible layout of cgroup paths. This sounds complicated, but the systemd cgroup layout is simple and almost stable. Then libsystemd0 and elogind packages could be installed in parallel at any time, and they would both work. Using an incompatible layout would be OK if this was a completely independent project, but for a purported drop-in replacement, that is a gratuitous and deal-breaking incompatibility.
(In the infrequent scenario that systemd introduces a cgroup layout change, elogind would need to be adjusted. But Debian doesn't need to allow any version of systemd to work with any version of elogind, so it could have elogind declare Conflicts:systemd>nnn, until it is known that nnn+1 is still compatible or elogind is adjusted.)
People keep bringing up that when systemd was being introduced it was parallel installable on existing systems and could be turned on and off by setting init= kernel command line. That design choice made the initial introduction vastly easier. Too bad that the elogind people didn't go for the same thing.
(systemd developer here)
Posted Nov 13, 2019 17:20 UTC (Wed)
by khim (subscriber, #9252)
[Link] (1 responses)
I think I miss something really important here: you have to call mount once to bind-mount either libsystemd0.whatever-version.so or libelogind.some-other-version.so on top of libsystemdo.so... and that kinda implies root privileges... but PID1 always have them so... what's the problem?
Posted Nov 13, 2019 21:13 UTC (Wed)
by NYKevin (subscriber, #129325)
[Link]
Posted Nov 16, 2019 10:48 UTC (Sat)
by intelfx (subscriber, #130118)
[Link]
Would you mind providing some nontrivial examples of such functionality?
Posted Nov 12, 2019 19:50 UTC (Tue)
by qyliss (subscriber, #131684)
[Link] (1 responses)
From the project’s README:
> Elogind has been developed for use in GuixSD, the OS distribution of GNU Guix.
Posted Nov 12, 2019 20:55 UTC (Tue)
by bandrami (guest, #94229)
[Link]
Posted Nov 12, 2019 16:14 UTC (Tue)
by ebiederm (subscriber, #35028)
[Link] (1 responses)
The only small regression I have is network-manager winds up depending upon
Posted Nov 12, 2019 17:43 UTC (Tue)
by zainryan (guest, #131584)
[Link]
Actively blocking fixes
Actively blocking fixes
Actively blocking fixes
Actively blocking fixes
Actively blocking fixes
Actively blocking fixes
The only way to get this to work in some stable kind of way (that I can see, anyway) would be a stub init that checks which real init should run, re-links the libsystemd0 symlink to point to either libsystemd0.whatever-version.so or libelogind.some-other-version.so, and execs the real init. Good luck doing that if [/usr]/lib should happen to be readonly.
Actively blocking fixes
Actively blocking fixes
Actively blocking fixes
Actively blocking fixes
XFCE works well without systemd
I was surprised to learn that XFCE for my uses actually works better.
something related to logind and so I have to edit my network configuration by hand.
XFCE works well without systemd