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 <ans...@43-1.org> 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 (r...@debian.org) <https://www.eyrie.org/~eagle/>
