Ian, if you have a moment, could you also weigh in here to confirm that I've understood the intent of your proposal correctly?
Ansgar <[email protected]> writes: > So three hypothetical examples: > - a hypothetical GNOME version that requires a build-time choice > between `systemd --user` and the traditional session implementation; > (GNOME can use `systemd --user` already[1], but it's not a build-time > choice.) I guess elogind could in theory start a `systemd --user` > instance even when pid-1 is not systemd, but it's probably not > realistic to expect that to be implemented. The criteria here under Ian's proposal is stated in point 8, "But such contributions should not impose nontrivial risks on users of the default configuration (systemd with Recommends installed)." So it would be a determination of the GNOME maintainers, appealable to the Technical Committee, whether using the traditional session implementation would impose a nontrivial risk to the users of the default configuration. If the traditional session implementation has RC bugs, point 7 would also apply and would be a strong argument in favor of switching to systemd --user. > - a hypothetical network management program that requires a build-time > choice between using systemd-networkd or isc-dhcp-{server,client} to > manage network connections. (Had NM used networkd would likely have > saved me some fiddling with settings recently and some things would > just have worked out-of-the-box.) > In case of build-time choices someone could submit a patch to switch the > program to use another option even when this provides a less good > experience for people using systemd (though still usable). I think this is the same. (In this case, I'll also add the editorial comment that I think making this sort of choice a build-time switch is poor engineering.) > - a hypothetical GNOME version requires (and does not really work > without) a new or updated logind interface that elogind doesn't > provide yet, but that could be implemented. Say for some device > access or so. > Would updating the software be blocked? I don't see how it would be under Ian's proposal. It's a regression in sysvinit support, but I don't see anything in Ian's proposal that calls out upstream removal of sysvinit support as distinct from any other upstream that only supports systemd. This introduces a bug under point 4, but that bug is not RC. I suppose you could argue that a patch reverting the upstream version of the software could be considered "available support" under point 7, but I don't think this holds up to scrutiny. Among other things, pinning to an old version of upstream is pretty obviously an RC bug as soon as upstream stops supporting that version, due to security support considerations. It *is* the case under Ian's proposal that if someone forward-ports the elogind support from an older version of GNOME and provides that as a patch that can be applied without a non-trivial risk to systemd users, the maintainer is in effect obligated to apply that patch. Obviously this is not a great situation to be in and would mean a ton of ongoing work by the sysvinit patch maintainer, so I don't think it's likely we would end up in that sort of situation for all that long. There would be a strong motivation for sysvinit users to find some other approach, such as an improved elogind. (In reality, my personal guess is that we'll drop sysvinit support for GNOME. I'm not sure the cross-section of GNOME users and sysvinit users is large enough to maintain that combination. My subjective impression is that most of the people who want to stick with sysvinit are also not big fans of GNOME's design decisions and are more likely to use some other desktop environment or window manager. But I don't want to assume that my guess is correct, or get in the way of anyone who does want to find a way to make this work.) -- Russ Allbery ([email protected]) <https://www.eyrie.org/~eagle/>
