[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#727708: init system discussion status

On 4 January 2014 23:13, Sjoerd Simons <sjoerd@debian.org> wrote:
> 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.

Imho that's a gross overstatement. Over more than a year, an Ubuntu
GNOME team was established and became official ubuntu flavour with so
goal and purpose of shipping GNOME3 in it's full glory. If distro
watch is any indication they are fast growing ubuntu flavour,
outpacing the more established ones like e.g. Xubuntu. The demand for
such flavour is growing, with highly positive reviews from critics and
general public. There is a group of volunteers who contribute to
making it work. I've personally used it, and it's quite wonderful and
capable desktop environment. I think there is some degree of heresy to
claim that GNOME3 is only supported with systemd-init pid1. That was
the case intermittently, until majority of pid1 checks were replaced
by more correct ones.

Even if that was the case, why should one Desktop Environment dictate
for all Debian users what the pid1 should be? We are debating this
decision not only on behalf of Debian developers, maintainers of
GNOME, but ultimately on behalf of all our users. Which significantly
includes !gnome3 and/or headless deployments.

> 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.

logind does not require systemd-init as pid1, and that is the case at
least to the extent of how GNOME3 is using logind.



Reply to: