[prev in list] [next in list] [prev in thread] [next in thread] 

List:       debian-hurd
Subject:    Re: Debian Buster release to partially drop non-systemd support
From:       Ansgar Burchardt <ansgar () debian ! org>
Date:       2018-10-16 16:26:32
Message-ID: e0f51d677a1d72ccc1f0400cde91f1b2a6ffb32f.camel () 43-1 ! org
[Download RAW message or body]

On Tue, 2018-10-16 at 14:48 +0200, Philipp Kern wrote:
> The question is: Is 
> the package buggy if it does not contain an init script but a systemd 
> unit and it seems to be the case. Note that there are a *lot* of useful 
> options in a systemd unit that would need emulation to make properly 
> work with sysvinit.

Shipping a systemd unit without a corresponding init script with the
same name is forbidden by policy:

| However, any package integrating with other init systems must also
| be backwards-compatible with sysvinit by providing a SysV-style init
| script with the same name as and equivalent functionality to any
| init-specific job
+---[ Debian Policy, section 9.11 ]

In practice this is ignored.

Note that this also forbids, for example, ssh.socket/ssh@.service or
tor@.service which all don't have a corresponding init script of the
same name.  Also cases where the init script starts multiple services,
but there are individual units for each service in systemd is
forbidden.

I think this requirement isn't a good idea these days for various
reasons and will file a bug asking to drop it.

Ansgar

[prev in list] [next in list] [prev in thread] [next in thread]