[2018-10-17 16:42] Ian Jackson
> 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
Hi,
I have recently been made aware that this policy is still around when
someone filed a bug asking for a package to be made compliant. I had
assumed that the requirement would have been dropped by now, so let me
echo/add a few thoughts.
When I have previously voiced discontent about the work
Hello,
On Wed 17 Oct 2018 at 10:28AM +0100, Simon McVittie wrote:
> One part of this section that seems valuable to rescue is:
>
> If you have an LSB (or "sysvinit") init script /etc/init.d/foo, and
> systemd unit(s) that are intended to be used instead of the LSB init
> script on systemd-booted
Steve Langasek writes:
> On Wed, Oct 17, 2018 at 10:07:44AM +0200, Ansgar Burchardt wrote:
>> That exception does not exist in Policy; there is only an exception for
>> packages provided by the init implementation itself. Policy currently
>> requires the "Loose coupling of init systems" option of
On Wed, Oct 17, 2018 at 10:07:44AM +0200, Ansgar Burchardt wrote:
> Russ Allbery writes:
> > Until such time as we make a project-wide
> > decision to drop support for sysvinit, providing an init script for
> > straightforward daemons is part of packaging a daemon. If people are
> > unwilling to
Russ Allbery writes:
> Ansgar Burchardt writes:
>> So shipping a daemon without init scripts is better than shipping one
>> with only a systemd unit?
>
> I don't believe such a daemon package (with no init script) should be
> included in Debian at *all*, as a matter of not meeting the quality
>
Ansgar Burchardt writes:
> So shipping a daemon without init scripts is better than shipping one
> with only a systemd unit?
I don't believe such a daemon package (with no init script) should be
included in Debian at *all*, as a matter of not meeting the quality bar.
> Shipping a sysvinit
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 giv
On Tue, 16 Oct 2018 at 20:31:54 +0200, Andreas Henriksson wrote:
> I'm still leaning towards thinking just dropping this section is
> better than doing a direct translation of it to the current systemd
> reality which might just end up being confusing and help noone.
One part of this section that
Russ Allbery writes:
> Ansgar Burchardt writes:
>
>> 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.)
>
> Presumably this is fine for the same reason as b.
>
>> b. ssh.socket for systemd has
Ansgar Burchardt writes:
> 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.)
Presumably this is fine for the same reason as b.
> b. ssh.socket for systemd has no equivalent in sysvinit at all.
Ansgar Burchardt writes:
> 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.)
As a special example:
DBus can start services on-demand. On systems
Andreas Henriksson wrote:
> It seems obvious to me that the above policy snippet was written in a
> time when the universe revolved around sysvinit. In current day and age
> sysvinit itself would be an "Alternate init system". We could update the
> snippet to say that any package providing
Hi,
On Tue, Oct 16, 2018 at 06:49:56PM +0200, Ansgar Burchardt wrote:
[...]
> +---
> | 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
>
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
15 matches
Mail list logo
