Re: Proposal for ConsoleKit distributor-list announcement

[Lennart Poettering <lennart poettering net>]

On Wed, 25.01.12 16:34, Olav Vitters (ovitters gmail com) wrote:

> Dear release team dudes and Mr.Lennart,
> 
> Due to the d-d-l thread and because we should, I plan to announce two
> things to distributor-list.
> 
> 1. ConsoleKit deprecated and the impact
> 2. relying on the API of those systemd daemons

Please be aware of the following:

I am currently also the maintainer of CK. I discussed with Martin Pitt
(Canonical) and Jon McCann (Red Hat, original author) that as soon as we
don't need CK anymore in Fedora I will hand off upstream maintainership
duty to Martin. Jon requested that at that time the project changes its
name (but can continue to use the old name in the bus names, classes and
so on), and Martin agreed to that.

Given that we are almost through in patching all packages for CK removal
the day of hand-over will probably be very soon, maybe two or three
weeks away.

Now, I guess the result of this is that CK itself is deprecated, but I
figure Canonical will say that the project under its new name is not, as
they require it.

>  - Fedora will switch to relying fully on systemd:
>    https://fedoraproject.org/wiki/Features/ckremoval
>  - Mageia and openSUSE will continue rely on the deprecated ConsoleKit; due
> to current support of sysvinit fallback. From what we understood, they
> likely will rely on systemd alone.

Note you cannot really mix tools that use CK and those using systemd for
login management, since the session identifiers are vastly different,
and various parts might stop understanding each other.

Also, you don't want to mix this anyway, since you lose all the new
stuff that systemd provides you with, most prominently automatic
multi-seat. 

Also note that while org.freedesktop.login1.Manager and friends
(i.e. the D-Bus API of systemd-logind, i.e. the replacement for CK) is
fairly generic it's one of the few APIs we currently haven't documented
in systemd, as we still want to keep a bit of liberty to chnage a few
things. Also, it exposes a couple of things that make no sense on
cgroup-less and non-Linux systems, i.e. cgroups and stuff. That said,
the code in GNOME that uses these interfaces doesn't need those bits.

In contrast to CK we also provide a low-level C API (which is much
easier to use because synchronous) for a subset of the features
available on the bus:

http://cgit.freedesktop.org/systemd/systemd/tree/src/systemd/sd-login.h

This API is fully documented (including with man pages for all library
calls), but it also exposes stuff that is a bit Linux or systemd
specific. For example, there's sd_pid_get_unit() which basically tells
you to which systemd service a process belongs.

Summary: for the hostname, timedate, locale stuff it makes a lot of
sense to ask the bsd/solaris folks to reimplement the interfaces, as
they are designed to be portable, and it's easy there.

However, for the login stuff this is not really doable, as a lot of the
concepts we introduce (i.e. proper low-level definition of a "seat" and
"session") make little sense on systems which don't support definining
these concepts this low level.

I figure that means that we probably have to keep code for CK compat in
GNOME, if CK matters. My own patches for GNOME stuff and otherwise are
actually written in a way that systemd and CK are detected at runtime,
thus allowing distros like Debian to ship a single version of the
software that's compatible with CK and systemd at the same time. But
others have not been as careful as I was and have this as a compile time
switch only.

And running partly CK software and partly systemd software side-by-side
is as mentioned a bad idea. This breaks at many places, for example with
PK authorizations (and you totally lost with genuine systemd features
anyway, such as true automatic multi-seat).

Sorry if this is disappointing,

Lennart

-- 
Lennart Poettering - Red Hat, Inc.