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

[Zbigniew Jędrzejewski-Szmek]

On Mon, Oct 06, 2014 at 02:56:22PM -0400, Rob Owens wrote:
> ----- Original Message -----
> > From: "Martin Steigerwald" <Martin at lichtvoll.de>
> 
> > Heck, I started a thread here and then didn´t manage to take time to
> > carefully
> > read it and reply here and there as I see fit. But I challenged people on
> > debian-user mailing list to constructively voice their concerns upstream, and
> > even pointed them to this mailing list. As far as I saw *no one* of the
> > posters in debian-user took up on that challenge. Which I view as a pity.
> > Cause now actually you invited constructive feedback. I wonder whether I may
> > forward your answer to debian-user so they see your statement of inviting
> > constructive feedback.
>  
> I am here from debian-user, due to Martin's suggestion.  So now that he's calling me out, I guess I'll post my questions :)
> 
> For the record, I'm a sysadmin and not a developer.  I imagine my questions and opinions will reflect that.
> 
> > Here the feedback I read over and over again is that you and RedHat basically
> > forced the systemd decision onto other distributions. While I do not see how
> > you actually can be powerful enough to do that, as we live in a free will
> > zone. I do see tendencies that more and more stuff *depends* on systemd cause
> > it needs features only available there.
> > 
> > On of the most talked on things on debian-user is the logind thing. GNOME
> > actually depends on it, as far as I know. While KDE in Debian still uses
> > ConsoleKit, as it seems to me when looking at the process list and finding:
> 
> 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...

You describe a dependency chain. First of all, it is important to note
that it does not matter if brasero actually uses the part of gvfs that
uses the part of udisk2 that uses the part of libpam-systemd that
requires systemd to be running. Possibly not, and maybe brasero would
still function correctly w/o systemd. But dependencies are expressed
on package level, so if systemd is required for some functionality of
libpam-systemd, which is used by any package depending on
libpam-systemd, then libpam-systemd must depend on systemd-sysv, and
transitively so must brasero.

To break this chain at some point, it is necessary replace the strict
dependency with "recommends/suggests" or provide a different different
package which satisfies the dependency. The first option is only
possible if the functionality provided by the dependent package
is not essential. In some cases it is really clear, e.g. a binary
requires a library to be installed to be able to run, but in
other cases it's a judgment call by the maintainers, whether some
part of functionality is important enough to add a dependency.
In this case brasero, gvfs, udisks2, and systemd maintainers decided
that yes, it is.

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.
But seriously, is SysV init that great?

> > Dependencies like this actually create some force to adopt systemd.
> 
> Based on Lennart's and others' comments in this thread, forced adoption does not seem to be a goal.  But forced adoption is a reality due to dependencies like the one above.  I think there would be a lot less skepticism about systemd if the perception of forced adoption weren't so strong, and I'd love to see something done about this situation.
> 
> > Now I know ConsoleKit isn´t developed anymore, but also I never got why a
> > logind implementation needs to depend on systemd base package in such a way
> > that at least in Debian systemd package has to be installed if someone wants
> > to use GNOME.
> 
> Is this what Debian's systemd-shim is for?  If not, well I'm going to talk about that anyway...
> 

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

Debian as a project already paid significant to support systemd as an
alternative, when systemd version was held back for a year waiting
for systemd-shim to catch up. This is certainly not the last time.

[snip]

Zbyszek