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. > I never thought much about my init system until recently. I never really had > any complaints with SysV init, although I do recognize that systemd provides > real improvements for some use cases. So for me as a sysadmin the wisest > thing to do is stick with what I already know, as long as it's working well > enough (and for me, it is). The issue with "I should be able to stay with sysvinit because it worked fine for me" is that keeping sysvinit working is COSTLY. The reason sysvinit used to mostly work was not that it would have been a reliable system - it mostly worked because people kept using a lot of effort to work around and paper over various issues that kept popping up. And there's no justification to keep up that effort for the minority who wants to stay with sysvinit. So, you can keep running your old systems unchanged if you want, but you shouldn't expect to be able to upgrade them or install new software without switching to systemd. _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel