Bug#727708: init system discussion status
On Sat, 2014-01-04 at 09:56 -0800, Russ Allbery wrote:
> Sjoerd Simons <sjoerd@debian.org> writes:
> > Not having the logind interface is a lot harder to cope with and
> > something that will not only impact Gnome. So essentially the most
> > likely impact of using sysvinit _without_ a provider of the logind
> > interface would be a non-usable Gnome desktop (and potentially even GDM
> > to be unusable) on Jessie systems.
>
> If we go with systemd, I think we have three options:
>
> 1. Allow packages that require logind to depend on systemd and require
> that it be used as the init system. This is certainly the simplest for
> packaging applications that want to depend on logind, as well as for
> the systemd maintainers. However, it means we lose the ability for
> users of at least those packages to be able to fall back on sysvinit if
> something goes wrong with systemd on their systems. In the past, we've
> tried pretty hard to provide that capability when making a disruptive
> change of this kind.
This one feels like a bit of a cost/benefit analysis to me. Is it worth
it to force all packages to work properly (for some definition of
properly) on a sysvinit system even in cases where this is a non-trivial
amount of work? For e.g. daemon packages where this typically is a
matter of keeping/writing an init script the cost is obviously very
low, so probably worth it.
For something like Gnome, it's a lot less obvious in my opinion.
> 2. Package logind separately from systemd, get it working with sysvinit.
> The problems with doing this, as I understand it, is that we'd not be
> able to upgrade such a separately-packaged logind beyond 204 for
> jessie. I'm not sure how much impact that would have. Also, it
> sounded to me like we would need to figure out who was going to do that
> work and maintain that package, including in the stable release. If
> the current systemd maintainers are not interested in doing this, we
> absolutely shouldn't try to force them to do so. Someone else would
> need to step forward to do this and figure out the right package
> relationships. (Also, it would be good to maintain this separately so
> that the systemd maintainers could move forward with newer versions of
> systemd, including the logind built from its source.)
> 3. Get GNOME working at some level without logind. I think it would be
> entirely acceptable for there to be some loss of functionality when
> GNOME is started in this way, such as no user switching and some
> configuration and control panels that rely on logind functionality not
> working. But it would need to at least start and be basically
> functional for this to be a meaningful option.
The problem with this option is how to define "some level" and
"basically functional".. If it's enough to be able to login, launch some
applications and have some basic window manager functionality that's
probably possible.
However some functionality which I would find pretty basic, e.g.
configuring the network, suspending the machine, locking the screen
might not be available.
Also, would "basic functionality" mean that if things fail they fail
gracefully? Given modern Gnome essentially doesn't get tested in a
non-systemd environment anymore I'm sure there a lots of rough edges
around.
> None of these options are very appealing, but I think we have to pick one
> of them. I'm not seeing other options at the moment.
>
> I think option 3 would be the most appealing for the project as a whole,
> but I realize that's also the option that puts the most burden on GNOME
> maintainers. The only upside I can offer for that is that this would be
> in the context of moving forward with systemd and would be a one-release
> issue. Post jessie, you'd be able to move forward with a standard
> integration.
> It's worth noting that option 3 is also what would be required if we
> wanted to support GNOME on kFreeBSD. I'm not sure if anyone is working on
> that port or sufficiently interested in it to try to make it work, but
> there may be some additional resources there.
Actually for the project as a whole and for porting to KFreeBSD i would
find option 2 more appealing as a starting point. logind is not just
used by GNOME, so doing so is more generally useful. Especially for
KFreeBSD as it lowers the barrier for entry for all logind users.
> Do you think there's a way that we could make option 3 work that the GNOME
> maintainers would be comfortable with?
Do you think there is a way you can find someone willing to do the
work? :)..
The problem with both 2 and 3 is that it's work that needs to be done
and maintained at least until Jessie is released. Which is work that as
far as I'm aware nobody in the current Gnome team is motivated to do.
So unless someone volunteers to take up the challenge to do the required
work (and succeeds in doing so!), to me the options of what to do for
Gnome in Jessie are:
0) Provide the user with a massively degraded Gnome 3 desktop
experience with no/bare minimal support from the gnome
maintainers when using sysvrc
1) Indicate to the user that Gnome 3 is only supported when using
the default init system as PID 1.
From those I personally think option 1 is actually the better option and
much more honest to our users then pretending Gnome 3 works with
sysvinit.
> The systemd maintainers should definitely feel free to tell me if I'm
> misunderstanding their feelings on option 2.
>
> Do you think I should ask more generally on debian-devel if there are any
> other maintainers in Debian that anticipate any problem with either
> requiring sysvinit be supported as PID 1 for jessie, or with logind being
> an optional component for jessie?
It's probably worth asking the maintainer of the other desktop
environments what the impact on their desktops environments is if any.
I'm aware that some other desktops started using logind, not sure about
the other systemd interfaces.
--
Sjoerd Simons <sjoerd@debian.org>
Reply to: