Debian TC vote on init system coupling

Posted Feb 24, 2014 17:44 UTC (Mon) by raven667 (subscriber, #5198)
In reply to: Debian TC vote on init system coupling by anselm
Parent article: Debian TC vote on init system coupling

> Finally, GNOME would not be allowed to depend on systemd in order to avail itself of logind, but it would be OK to depend on some (virtual) package that provided the logind DBUS interface as long as there'd be an alternative implementation ...

That's the kind of discouragement I was talking about, the penalty for trying to use logind is that you are now committed to create a re-implementation of logind for people who don't want to use systemd. What kind of software engineer would accept those conditions?

Debian TC vote on init system coupling

Posted Feb 24, 2014 18:00 UTC (Mon) by anselm (subscriber, #2796) [Link] (2 responses)

This is admittedly one of the hairier cases. However, in this case it is worth noting that you don't have to reimplement all of logind, you only need to reimplement those bits that GNOME actually uses, and not even all of those actually need to do anything (although it would sure be nice if they did). For example, you could probably get away with not supporting the nifty multiseat capability that systemd offers.

This approach may in the end still be preferable to supporting non-systemd systems in the actual GNOME code base until who-knows-when. I don't know whether upstream GNOME is planning to go Linux-only (which they would probably have to if they want to rely on systemd exclusively), but if they aren't they'll need something like this anyway.

Debian TC vote on init system coupling

Posted Feb 24, 2014 20:00 UTC (Mon) by fandingo (guest, #67019) [Link] (1 responses)

I agree, but here's some additional specificity:

http://www.freedesktop.org/software/systemd/man/systemd-l...

> systemd-logind is a system service that manages user logins. It is responsible for:

> 1. Keeping track of users and sessions, their processes and their idle state

> 2. Providing PolicyKit-based access for users to operations such as system shutdown or sleep

> 3. Implementing a shutdown/sleep inhibition logic for applications

> 4. Handling of power/sleep hardware keys

> 5. Multi-seat management

> 6. Session switch management

> 7. Device access management for users

> 8. Automatic spawning of text logins (gettys) on virtual console activation and user runtime directory management

It seems quite easy to make basically a "no-op" DBus interface to fake logind. #1 is only minimally necessary, although I can't say how much is actually needed and the complexity. #2 is simple enough to invoke a SUID binary for the underlying scripts, although security leaves something to be desired. #3 is completely optional. #4 could be handled through Gnome by configuring custom keyboard shortcut commands (sprinkle in SUID as necessary). #5 and #6 can be ignored. #7 should be simple. Since there's no multi-seat, it's easy to run a udev script for changing owner/group of the devices and sending a DBus signal to Gnome of the hotplug event. #8 can be ignored in favor of fixed gettys. Runtime directories should be kept and could likely be managed by a Gnome startup script (or if necessary something inserted earlier in the login sequence).

There's no doubt that it will be messy and half-baked (especially as I've described it), but I think it could mostly work. Whether anyone would want to run or enjoying running it is another matter.

Debian TC vote on init system coupling

Posted Feb 24, 2014 20:16 UTC (Mon) by anselm (subscriber, #2796) [Link]

Whether anyone would want to run or enjoying running it is another matter.

Yes, but that isn't the point. The point would be to achieve Debian policy compliance and make Ian Jackson happy. With proper documentation of the limitations of the gnome-compatibility-logind package it will probably be possible to avoid having any of those limitations look like RC bugs.

It is fairly safe to say that given a choice of a smooth GNOME user experience based on systemd and a clunky GNOME user experience based on »System V init or OpenRC plus essential-compatibility extras«, most GNOME users will be more interested in the former. If anyone doesn't like this, let them come up with a better non-systemd logind for GNOME; it is not the Debian GNOME maintainers' (or upstream GNOME's) job to ensure that the Debian non-systemd GNOME experience is 100% identical to the Debian GNOME experience based on systemd.