[Pkg-sysvinit-devel] Bug #826214: Bug #826215: init-d-script and systemd: solution

[Andreas Henriksson]

Hi Christian,

Thanks for considering my negative feedback in a constructive way.

On Thu, Dec 29, 2016 at 05:24:26PM +0100, Christian Seiler wrote:
> Hi Andreas,
[....]
> 
> After reading the other emails, maybe we can converge on the
> following consensus / compromise?
> 
> For stretch:
> 
>  - I'll provide a patch for #826214 against init-d-script
>    that will restore the original arguments while sourcing
>    /lib/lsb/init-functions. This will make systemctl
>    redirection work again for Stretch when using
>    init-d-script.

Looking forward to it.

> 
>  - We'll ignore #826215 for Stretch and scripts shipping an
>    init-d-script based init script will hard-depend on
>    sysvinit-utils regardless of systemd service
>    availability. (As they do now.)

Yes, but note:
sysvinit-utils is still Essential: yes and I think it's too late
to change that now for Stretch.
According to policy nothing should declare a dependency against
an essential package...

> 
>  - Add a warning to the output in systemd's
>    /lib/lsb/init-functions.d/40-systemd and mention that
>    calling init scripts directly on systemd systems is
>    deprecated. (I can provide a patch.)

(Not sure this is needed, but no objection from me.)

> 
> For Buster:

step 0 would be to have someone work out how we can drop
Essential: yes from sysvinit-utils.
(Should be easily doable, but as always with these things
someone needs to make up a plan and consider all cases carefully.)

> 
>  - We revisit #826215 and say that packages that provide a
>    init-d-script that has the same name as a systemd service
>    need not depend on sysvinit-utils, and that if people
>    want init-d-scripts called directly in /etc/init.d
>    (when a corresponding systemd service also exists) to
>    work on systemd systems, they also have to install
>    sysvinit-utils, otherwise this just breaks.
> 
>    People using service / invoke-rc.d will not have any
>    trouble, and people who really want to call the script
>    directly via /etc/init.d have to install an additional
>    package. (Or use sysvinit as the init system.)

Installing sysvinit-utils manually will be the least of your
problem with invoking the init script directly unless the
LSB hook is there to redirect you to systemctl.

I think your explanation above is just too complicated for most
maintainers to spend enough time/thought about it to get it right.
Lets just say "if you use init-d-script provide a matching/masking
native systemd service unit" (and even if you don't use init-d-script
still provide a matching/masking systemd service unit anyway).
Much less complicated IMHO.

> 
> For either Buster or Buster + 1:
> 
>  - Revisit init.d script redirection entirely and perhaps
>    get rid of it. (Or not, we'll have to see.)
> 
> Would at least the Stretch part of that be agreeable for
> everyone involved here?

I think we can aim for this (and more!) for Buster.

HTH.

Thanks for your interest in building a good long-term
plan for these issues.

Regards,
Andreas Henriksson