Bug#727708: init system discussion status

[Ian Jackson <ijackson@chiark.greenend.org.uk>]

Russ Allbery writes ("Bug#727708: init system discussion status"):
> Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
> > It seems daft to go around making two (or perhaps three or more) patches
> > to every daemon when one patch to each daemon, and a couple of
> > compatibility modes in the init systems, would suffice.
> 
> Okay, it's possible that we just disagree here.  Having actually done it,
> I don't see any reason not to implement both the upstart and systemd
> readiness protocols in a typical daemon.  It's not at all hard, and in
> most cases one is going to want to implement socket activation on the
> systemd side anyway, which makes the readiness protocol mostly irrelevant.

The question isn't what you would prefer.  The question is this:

Are you going to vote to overrule a maintainer who says 

  I have already implemented non-forking readiness protocol X and I
  think support for all init systems in my daemon should be done via
  one protocol.  Please do send me a patch for your init system Y task
  file (and correponding packaging support) when init system Y has
  support for protocol X.

?

ISTM that if this situation arises it is due to a failure by the init
system to be sufficiently accomodating.  I would vote to not overrule
a maintainer in such a situation.

> Whether systemd upstream should support the SIGSTOP protocol is certainly
> debatable, but I'm very reluctant to support an option that tries to force
> the systemd maintainers to support the protocol indefinitely as a
> Debian-specific fork.

We have endless Debian-specific patches which are precisely there to
support additional protools which make packaging and integration
easier.  OK, nowadays there is less need of this because our technical
choices have been more widely recognised as good, but it is not
something we should be afraid of.

Support for raise(SIGSTOP) would be a small patch which Debian could
easily carry indefinitely if need be.

Consider for example the support for searching "whatever.d"
directories for configuration of one kind or another, which has been
added by many Debian maintainers first in their patches (and I bet
there are packages where that's still not upstream).

>  This protocol is not widely used in Debian at the
> moment, nor is it widely used upstream, and I think it would be a far
> better use of our time to add support for the systemd protocol to upstart.

I think we need to add both protocols to both daemons.  This is
because I want integration to be as easy and uncontroversial as
possible.

Ian.