[systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance

[Lennart Poettering]

On Tue, 07.10.14 23:40, Uoti Urpala (uoti.urpala at pp1.inet.fi) wrote:

> On Tue, 2014-10-07 at 14:15 -0400, Rob Owens wrote:
> > My question really isn't "why are the Debian dependencies the way they are".  I understand that.  I was trying to highlight the strange situation of a desktop application requiring a particular init system.  I *think* this is a result of the init portion of systemd being bundled together with the logind portion of systemd.  To me (unfamiliar with the systemd code) those two functions seem distinct enough to merit being separate.  Debian can't easily separate what the systemd devs have developed as a single binary, so we end up with these strange dependency chains.
> 
> "Single binary" is false of course. Logind is developed as a separate
> program, which is why systemd-shim is possible at all.
> 
> AFAIK the actual relevant dependencies go as follows: First, there's a
> good reason why logind requires cgroup functionality. And there's a good
> reason why cgroup functionality is best implemented together with init
> (see
> http://www.freedesktop.org/wiki/Software/systemd/ControlGroupInterface/
> for more info). So it's not quite directly "logind has to depend on
> systemd as init", but "logind has to depend on the system having cgroup
> support, and there's no equally good cgroup support available for inits
> other than systemd". It is possible to provide the relevant cgroup
> interfaces in or on top of another init, as the systemd-sysv + cgmanager
> combination attempts to do. But it is not trivial to do, as bugs and
> implementation delays with that combo have shown, and it's quite likely
> that there will be more problems in the future. It's not a particularly
> good idea to use the less-tested and less-reliable systemd-shim instead
> of the more reliable systemd. Thus the overall result is that yes, it
> does make sense to switch machines to systemd when you add certain
> functionality, even if that functionality does not appear to be directly
> tied to the init system at first glance.

Also note that the systemd concepts logind makes use of are also
exported in its own API. The "scopes" and "slices" that logind uses
are exposed on its bus objects, and they are used by tools like
"loginctl" to do their work.

The "scopes" and "slices" concept does not exist elsewhere, and
there's nothing comparable around, so even if we wanted we couldn't
make logind work on anything else.

Lennart

-- 
Lennart Poettering, Red Hat