Bug#727708: init system discussion status
Sjoerd Simons <sjoerd@debian.org> writes:
> Essentially this boils down to whether the logind interfaces will be
> available when using sysvinit. Most of the other interfaces (at least
> for current gnome as in experimental) would cause some functionality to
> either be missing or not work, but wouldn't yield a completely unusable
> system.
Thanks for that. That's one of the key pieces of information that I was
wondering about, and I was just told I should probably talk to you since
you'd know. :)
> 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.
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.
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.
Do you think there's a way that we could make option 3 work that the GNOME
maintainers would be comfortable with?
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?
If we go with upstart as the default, obviously the situation is much
different, possibly including multiple different maintenance teams, and
would require packaging a broken-up version of systemd and building a
maintenance team around that. It's basically option 2 with a bunch of
added disruption. There are enough variables involved in that situation
that I hesitate to guess what it would look like.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: