Hi, On Do 07 Nov 2019 19:59:49 CET, Sam Hartman wrote:
No, the difference intended between choice 2 and 3 is about how we handle technologies like elogind, or a mythical technology that parsed sysusers files, rather than how we handle starting daemons.
I'd suggest leaving elogind entirely out of the discussion, here.The elogind fork of the systemd component systemd-logind only kicks in, just like systemd-logind, once a user logs into the session.
As I get it, the rest of the GR draft is about system services initialization, not user session services startups.
If systemd was mandatory, user session services would be handled by systemd-logind.
If systemd was replaceable by some other init system, than there would be (at least) two options:
- still use systemd-logind for user session service startups
(and have all the systemd entanglement package-wise) [1, 2]
- use elogind (drop-in replacement for systemd-logind, no entanglement
with systemd as a system service orchestrator)
Isn't as side-question that is on the table with this GR: what about
the future of non-Linux variants of Debian. If systemd becomes _the_
init system of focus in Debian (by vote, not only de facto), kFreeBSD
and Hurd will certainly have more of their difficulties, more than
they have now.
light+love, Mike [1] in Debian jessie this was possible[2] Ubuntu used to have a phase when upstart was handling system services and systemd-logind was handling user session services
-- DAS-NETZWERKTEAM c\o Technik- und Ökologiezentrum Eckernförde Mike Gabriel, Marienthaler str. 17, 24340 Eckernförde mobile: +49 (1520) 1976 148 landline: +49 (4351) 850 8940 GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22 0782 9AF4 6B30 2577 1B31 mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de
pgpFxlp1eGHIc.pgp
Description: Digitale PGP-Signatur
