On Wed, 25.01.12 16:34, Olav Vitters ([email protected]) 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. _______________________________________________ [email protected] http://mail.gnome.org/mailman/listinfo/release-team Release-team lurker? Do NOT participate in discussions.
