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

[Rob Owens]

----- Original Message -----
> From: "Zbigniew Jędrzejewski-Szmek" <zbyszek at in.waw.pl>
> On Mon, Oct 06, 2014 at 02:56:22PM -0400, Rob Owens wrote:

> > On Debian, I came across an unusual dependency.  Installing a cd burner
> > (brasero) required me to change my init system to systemd.  Sounds kind of
> > ridiculous, I think.  The dependency chain went like this:
> > 
> > brasero -> gvfs -> gvfs-daemons -> udisks2 -> libpam-systemd ->
> > systemd-sysv
> > 
> > I don't know enough about this stuff to comment very intelligently, which
> > is why I haven't said anything up until now.  But my research shows that
> > each of these dependencies is indeed valid in the sense that each
> > dependency represents some real requirement for functionality.  The issue,
> > I think, is that some of these packages provide very broad functionality.
> > As I put it in a Debian bug report:
> > 
> > Brasero needs X functionality, which can be found in package W.  Package W
> > also provides Y functionality, which depends on systemd-sysv.  So
> > therefore brasero depends on systemd-sysv, even though it doesn't *need*
> > it.
> > 
> > I gather that this has something to do with logind and/or cgroups.  I can
> > appreciate the benefits (on some systems) of giving only the local user
> > access to removable media.  But I don't understand why this functionality
> > requires the use of systemd-sysv (the init system), particularly if my
> > understanding is correct that this functionality used to be separate from
> > the init portion of systemd.
> 
> I'll assume that this is a serious question, despite being rather
> elementary...

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.

I am trying to demonstrate the drawbacks of the decision to combine logind with the init portion of systemd.  I'm giving you an outsider's point of view.  I realize that most of the folks on this list probably love all of systemd and couldn't imagine why anyone would want to have just bits and pieces of it.  But I think my previous email gave some good reasons.  If not, let me know and I'll try to be more clear about it.

> The second option requires someone to step up and provide an
> alternative implementation. So far, systemd-shim is one candidate, but
> it took months to appear and still has occasional problems. (I don't
> follow the situation quite closely, but Michael seems to find serious
> bugs with very light testing). At some point, systemd-shim might
> become a viable replacement. This work should be done by people who
> want the alternatives, not the maintainers of systemd, who happily use
> the existing stack. So if the alternatives are not in the shape you
> would like them to be, inquire with the maintainers of the said
> alternatives.
> 
> But even assuming that an alternative is functional, using it is not
> without costs for the maintainers of dependent packages. Let's say
> that we have some systems with systemd, some with systemd-shim. It is
> likely that a bug report for udisk2 might require the maintainer to
> ask which of the alternatives is used. For such basic functionality
> that influences the whole OS, if the maintainer uses a different
> init, it is like being on a different architecture. It makes things
> hard to debug, hard to test, and greatly distracts from the time
> the maintainer has available to really fix bugs. It is not free, and
> diminishes the appeal of the whole distribution. It might be that
> this alternative dependency has advantages which outweigh this cost.

I think everything you said in these two paragraphs could be used to support the argument of keeping logind separate from init.  Then everybody would be using your logind code, and there would be no need for systemd-shim.  There still would be the issue for package maintainers of supporting multiple init systems, but that's Debian's decision to do so.

> But seriously, is SysV init that great?

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).

> > Systemd-shim provides some functionality that systemd-sysv provides,
>   and allows admins to use init systems other than systemd while still
>   installing things like brasero.  I think this is a great thing,
>   except I wonder why the systemd project didn't separate this
>   functionality from the init system in the first place.  Systemd-shim
>   is a duplication of effort.  Not only that, but it must time its
>   releases with the releases of systemd-sysv.  That's no big deal for
>   Debian's stable release, but it can be problematic in Debian's
>   unstable and testing branches.
> 
> Because it's additional work and complications. Apparently providing
> systemd functionality without systemd running is not a trivial
> undertaking, as the lag between systemd and systemd-shim releases
> shows. I could spend my time for open source development on a
> (technically) pointless (from my vantage point) split, but I
> prefer to improve systemd instead.

I have to take your word for it, because I don't know enough to accurately judge the amount of work it would take.  Is the act of splitting up the functionality the part that creates the work?  Or is it in maintaining such a code base?  In other words, is the additional work a one-time thing or would it be additional work from now until eternity?

For the record, I am finding that systemd-shim is doing a pretty good job of providing timely updates.  In fact, recently in Debian Testing we had the situation where a newer version of systemd-shim was available before that version of systemd was available.  I don't expect that to happen often, but it did happen!  But I feel for the systemd-shim guys because they will constantly be under the gun to duplicate the systemd functionality in a timely manner.  And I can't help but wonder if this whole situation is avoidable.

-Rob