Bug#932704: debian-policy: Don't force sysvinit compatibility if e.g. alternate init required
[2019-09-22 16:13] David Steele <steele@debian.org>
> 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?
Imho, it opens loophole. Sysvinit does not provide equivalent of
sd_notify("SD_READY=1"), so any service that links to libsystemd for
that exactly call can be argued as "requiring feature [...] which is not
available [...]".
As real life example I recall Avahi-related bug (can't find number right
now, sorry). Two inter-dependent services, where second fails to start
unless first is already ready to listen.
I'd argue this is bug in design, but if we consider design is written in
stone, this is a bug in init.d script that must be worked around
somehow.
With your change in place, avahi maintainers would be able to drop
sysvinit support instead of fixing init.d script.
Very strong -1.
--
Note, that I send and fetch email in batch, once in a few days.
Please, mention in body of your reply when you add or remove recepients.
Reply to: