Consolekit support

Question

Consolekit support

elinorbgr opened this issue 6 years ago · comments

Elinor B. commented 6 years ago

As an alternative session backend to logind, we need to implement Consolekit support.

Apparently, the consolekit API is fully on dbus: https://consolekit2.github.io/ConsoleKit2/

There are apparently a lot of similarities with the logind backend.

Victoria Brekenfeld · Answer 1 · Tue May 19 2020 15:59:52 GMT+0800 (China Standard Time)

Is this superseded by #127 or a separate protocol, that we still want to support?
Otherwise we could close this issue in favor of #127.

Elinor B. · Answer 2 · Tue May 19 2020 20:24:39 GMT+0800 (China Standard Time)

Consolekit is a still a different protocol than (e)logind as far as I can tell, so this is not superseded by #127.

Now do we actually want to support ConsoleKit, that is the main question.

Pros: ConsoleKit is available on at least some of the *BSD, while (e)logind is not
Cons: ConsoleKit seems to be unmaintained for years now

Kirill Chibisov · Answer 3 · Tue May 19 2020 20:58:21 GMT+0800 (China Standard Time)

Well, consolekit is being dropped even by gentoo https://www.gentoo.org/support/news-items/2020-04-14-elogind-default.html . Also, I'd say that the primary BSD we should look at is FreeBSD, since a lot of Wayland libs assume linux and this is likely the only BSD that patch a lot of things in it and try to make it work IIRC.

I'm not familiar with what FreeBSD is using though.

Szymon Scholz · Answer 4 · Tue May 11 2021 19:18:13 GMT+0800 (China Standard Time)

https://freedesktop.org/wiki/Software/ConsoleKit/ - unmaintained
https://github.com/ConsoleKit2/ConsoleKit2 - depends on x11, seems rarely maintained (code frequency) and uses a lot deprecated dependencies
https://github.com/elogind/elogind - well maintained

just my 2 cents

Victoria Brekenfeld · Answer 5 · Tue May 11 2021 20:06:15 GMT+0800 (China Standard Time)

Not really our problem anymore anyway, if we decide to fully migrate to seatd. (see #262)
Not sure, if seatd is planning to support ConsoleKit2 at some point, but that would move this problem upstream.

Which imo is a good thing, because like demonstrated by the age of issue, we do lack the manpower to maintain this feature and the systems / dedication to actually test it as well.

I am in favor of closing this.