Re: Gentoo+Gnome requires systemd, but Gnome itself does not? Why? - WAS: Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

["Canek Peláez Valdés" <caneko@gmail.com>]

On Tue, Feb 25, 2014 at 6:58 AM, Alan McKinnon <alan.mckinnon@gmail.com> wrote:
> On 25/02/2014 14:40, Tanstaafl wrote:
>> On 2014-02-24 4:48 PM, Canek Peláez Valdés <caneko@gmail.com> wrote:
>>> In Gentoo you need systemd, but that's a decision from the Gentoo
>>> maintainers. They do the job, they make the choices.
>>
>> Interesting. Now I have to spin off a new thread as to why this decision
>> was made if it isn't forced by GNOME itself...
>
> Gnome uses logind, Canek has consistently stated that for months now.

That is true; but no one have to trust me on anything. The code is out
there ([1], [2]); anyone can go and check what dependencies GNOME
exactly require.

> logind is part of systemd (AIUI it's more "bundled" than "a chunk of a
> monolothic lump") and replaces consolekit.

I'm not so sure about this anymore. It seems that logind actually uses
many of systemd features, and therefore is really difficult to
implement independently of it. For a high overview discussion of this,
you can check [3], where Ryan Lortie says:

"""
Some interfaces provided by systemd are less awesome. Even at the
D-Bus level, the interface for PID 1 or logind are so complicated and
implementation-specific that they could never be reasonably
independently implemented. These interfaces often mix multiple
functionality sets into one: for the logind case, for example, only a
small subset of this is ever required by a desktop environment running
as a normal user. Many other calls on the same interface are only
called by other operating system components.
"""

Ubuntu has been (and supposedly, still is) interested in having a
non-systemd replacement; but AFAIK, they don't have it yet. For
systemd <= 204 the code of logind was more independent of systemd
features, so they just cut it from there; after 205 (when the new
slices thingies were added to deal with the future cgroups API from
the kernel), this is no longer possible, so they need to actually
write an API compatible replacement. This hasn't come to fruition (and
because of the above quote, this doesn't look easy).

Perhaps a compromise could be reached where the desktop-necessary
parts of logind are isolated in their own dbus API.

As with everything, however, somebody should do that job.

> The feature set of logind can be implemented in something else. Or, that
> functionality in previous Gnome versions forward-ported to 3.10 to be
> able to drop logind as a dep.

In this case, the "something else" is ConsoleKit, which (AFAIK) works
in the *BSD.

> OpenBSD would have had little choice in this as systemd doesn't run on
> OpenBSD - systemd uses many features unique to the Linux kernel. So they
> would have had to do *something* about logind. Whatever they did, it
> would have been a non-trivial amount of work.

I don't think so; the source code I linked says (literally):

if test x$enable_systemd = xyes; then
       [ snip ]
        session_tracking="systemd (with fallback to ConsoleKit)"
else
        session_tracking=ConsoleKit
fi

So, it could be that is actually "trivial".

The real problem is that most GNOME developers don't use the
ConsoleKit code paths anymore, so the burden of works goes to the
people that don't have systemd (*BSD).

> I suspect the Gentoo Gnome maintainers were not prepared to, or don't
> have the manpower, to do the same on Gentoo so took the easier route of
> depending on systemd.

Most of them don't use OpenRC anymore, so they could perhaps see that
the code emerges without errors, but they would not be able to
actually test it. They rather decided to support what they could test,
than to give the appearance of "choice" when no one is really
supporting the CK code paths.

(Also, it seems undeniable that logind works so much better than CK ever did).

Regards.

[1] https://git.gnome.org/browse/gdm/tree/configure.ac#n882
[2] https://git.gnome.org/browse/gnome-session/tree/configure.ac#n123
[3] http://blogs.gnome.org/desrt/2014/02/19/on-portability/
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México