Bug#911165: debian-policy: drop requirement to ship sysvinit init script with same name

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

Russ Allbery writes ("Bug#911165: debian-policy: drop requirement to ship sysvinit init script with same name"):
> This is not the sort of thing that we should be dropping on an ad hoc
> basis given the project decision to support multiple init systems, since
> if we give up this principle it will be *extremely* hard to re-establish
> it.
> 
> That doesn't mean that we can't decide to drop formal sysvinit support.
> It does mean that we should do this properly, as a project-wide decision,
> which is way, WAY beyond the scope of Policy and is *absolutely not*
> something that we're going to be able to decide here on this mailing list
> or in this bug report.

Needless to say I agree with all of this.

Obviously when there are situations where providing an init script is
actually wrong (because under sysvinit or other systems the daemon is
started some other way), the init script should not be provided.

In the existing text, this could be done as follows:

  | However, any package integrating with other init systems must also
  | be backwards-compatible with sysvinit

+ |                                      , usually

  |                                       by providing a SysV-style init
  | script with the same name as and equivalent functionality to any
  | init-specific job

As for the Russ's point about exact equivalence, that would be dealt
with by something like this:

  | script with the same name as and

+ |                                  roughly

  |                                  equivalent functionality to any
  | init-specific job

Ian.