[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#911165: marked as done (debian-policy: drop requirement to ship sysvinit init script with same name)

Your message dated Tue, 20 Sep 2022 21:59:22 -0700
with message-id <87a66tfhlh.fsf@hope.eyrie.org>
and subject line Re: Bug#911165: debian-policy: drop requirement to ship sysvinit init script with same name
has caused the Debian Bug report #911165,
regarding debian-policy: drop requirement to ship sysvinit init script with same name
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
911165: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=911165
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message --- 
Package: debian-policy
Version: 4.2.1.2
Severity: normal

This requirement is currently included in Debian 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, 9.11 "Alternate init systems" ]

I propose to drop the requirement for the following reasons:

a. tor@.service has no init script with the same name. This should be
   fine. (Note: there is also both a "tor.service" and "tor" init
   script.)
b. ssh.socket for systemd has no equivalent in sysvinit at all.
   This should be fine.
c. It is better to ship integration with some init systems than
   no integration at all. (Including sysvinit scripts at all is not
   required, only when any other integrations are provided.)
d. Some sysvinit scripts might start multiple services at once,
   but this might be split into multiple units in other systems.
   This should be allowed.
e. It is unclear what "equivalent functionality" implies.  Does this
   include sandboxing features?  Socket activation (which might be
   important for startup order)?  Using the same file for configuration
   (some services can be configured in /etc/default/* for sysvinit,
   but use overrides for systemd)?

If one tries to accomodate all of this, only something along the lines
of "if there is a init-specific job and an (in some way) equivalent
SysV-style init script then both should have the same name" remains.

Ansgar

--- End Message ---
--- Begin Message --- 
Version: 4.5.0.0

Ansgar <ansgar@debian.org> writes:

> This requirement is currently included in Debian 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, 9.11 "Alternate init systems" ]

> I propose to drop the requirement for the following reasons:

[...]

This section was deleted as part of resolving #948115, so this was fixed
in the version with that change.  Closing this accordingly.

-- 
Russ Allbery (rra@debian.org)              <https://www.eyrie.org/~eagle/>

--- End Message ---
Reply to: