Bug#727708: init system discussion status

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

Russ Allbery writes ("Bug#727708: init system discussion status"):
> The thrust of this seems right, but I dislike telling people what to do.
> Can we recast this in a way that avoids that problem?  Maybe something
> like:

Sure.  I borrowed your text and edited it slightly for clarity.  I
also changed "upstart/systemd" to "upstart", for two reasons: one is
that at this stage I'd prefer to try to maintain only one version of
this text.

And the other is that IMO the proposed prescription for non-Linux
ports doesn't make sense for systemd.  There is little prospect of
systemd being "ported" to those systems.

> Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
> > | 3. At least in jessie, unless a satisfactory compatibility approach is
> > |    developed and deployed (see paragraph 10), packages must continue
> > |    to provide sysvinit scripts.  Lack of a sysvinit script (for a
> > |    daemon which contains integration with at least one other init
> > |    system) is an RC bug in jessie.
> 
> This needs the same exception as is currently in Policy 9.11, namely:
> 
>     An exception to this rule is scripts or jobs provided by the init
>     implementation itself; such jobs may be required for an
>     implementation-specific equivalent of the /etc/rcS.d/ scripts and may
>     not have a one-to-one correspondence with the init scripts.

I've written a version of Niklaus's rule about dependencies:

   Likewise, packages must not Depend on or Recommend (directly or
   indirectly) a specific init(1).  Violations of this are also an RC
   bug in jessie.

And:

   Theses rules do not apply to machinery which itself forms part of
   the implementation of one or more init systems.

That seems to be the clearest way to put the matter.

> "Should delay" is a bit strong given that we have many packages in the
> archive that already provide native support for upstart, and several
> (including ones maintained by both Colin and myself) that have native
> support for systemd.  Maybe something more like:
> 
>     Contributors who have not already added native support for upstart,
>     systemd, or OpenRC may wish to wait until the relevant Debian Policy
>     is declared, by the Policy editors, to be ready.  Early adopters
>     should be aware that the requirements may change and their packages
>     may require updates.

I like this and have included it.

> > |    (b) Use facilities documented in the reference manuals for the init
> > |        system in question (as found in sid).  [ This requirement
> > |        cannot be met until the init system has a suitable reference
> > |        manual. ]
> > | 
> > |    (c) Require that environment variables and fds involved in the
> > |        daemon startup protocol should not in general be inherited by
> > |        the daemon's descendants.
> > | 
> > |    (d) Forbid the introduction of embedded copies of library code
> > |        (or the use of any embedded copies included by upstream).
> 
> I'm not sure what the point of (b) is.  I think (d) is too strong.  Policy
> 4.13 currently says:

(b) is probably irrelevant given the rest of the resolution.  I have
deleted it but not (for now) renumbered the rest.

If (d) is removed from here then I think it needs to be included in 6C.

> I think Policy 4.13 already covers this adequately and we don't need to
> say anything further in the decision.

I would like to be clear that maintainers don't need to take patches
that introduce embedded copies of sd_notify.

Thanks,
Ian.