Bug#932704: debian-policy: Don't force sysvinit compatibility if e.g. alternate init required
On Wed, Sep 25, 2019 at 12:18 PM Ansgar <ansgar@43-1.org> wrote:
>
> Hi,
>
> On Sun, 2019-09-22 at 16:13 -0400, David Steele wrote:
> > On Tue, Jul 23, 2019 at 2:10 PM Sean Whitton <spwhitton@spwhitton.name> wrote:
> > > The Policy Editors have decided that dropping the requirement to ship
> > > init scripts is not something that can be decided by means of the Policy
> > > Changes Process, at least for the time being.
> > >
> > > In proposing and reviewing wording to resolve this bug, then, we should
> > > be careful not to weaken the requirement to ship init scripts.
> > > Otherwise, in resolving this bug we would be changing the requirements
> > > to ship init scripts by means of the Policy Changes Process.
> > >
> > > I'm suggesting this be kept in mind. It need not result in a wordier
> > > change, and I certainly agree with you that we should assume good faith
> > > on the part of package maintainers.
> > >
> >
> > Candidate language attached. It adds "Also excepted are packages which require a
> > feature of an alternate init system which is not available in SysV-Style
> > init systems.". Thoughts?
>
> I don't think there is a way to get such changes through the policy
> process as Sean said (I tried to document what I see as current
> practice in #911165). Practically the project seems to have already
> decided that this is fine, even for packages that don't require
> systemd:
>
> +---
> | There are 1033 non-overridden instances of lintian detecting a
> | service unit without an init.d script [7].
> +---[ https://lists.debian.org/debian-devel-announce/2019/09/msg00001.html ]
>
> Ansgar
>
Regardless of the practicality, I'd like clarity on the policy.
After reading #911165, I'd say I prefer it to this proposal. But something
needs to be done about the current alternate init system support
language.
Reply to: