Bug #826214: Bug #826215: init-d-script and systemd: solution

[Christian Seiler]

Hi Andreas,


Sorry for not replying earlier, but I wanted to mull this over some
before answering.

On 12/27/2016 10:49 AM, Andreas Henriksson wrote:
> On Sun, Dec 25, 2016 at 01:34:41PM +0100, Christian Seiler wrote:
>> Hi there,
>> (Cc'd a lot of people, so that hopefully everybody relevant
>> is included.)
> [...]
> 
> The problem I pointed you to where only one out of many symptoms of the
> breakage introduced by using init-d-script. I think just attacking one
> specific symptom of one specific LSB hook is wrong.

So after reading your arguments I believe I agree with you.

> Following Martins advice and pushing this back into the original
> init-d-script is better, because that means this is confined in a single
> place.

Yes.

> I also have to point out that I completely disagree with you on
> minimal systems not being relevant to anyone.

I think you misunderstood me a bit, I'm not against making
the Debian base smaller (I use containers myself and them
requiring less stuff is definitely something I look forward
to) - but since that was in support of an argument for
something I'm now convinced it's not the right way, I'm
going to leave it at that.





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.

 - 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.)

 - 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.)

For Buster:

 - 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.)

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?

Regards,
Christian

PS: I've also gone through the bug list against init-d-script
and have been working on fixing a couple of other issues. I
haven't posted anything in that regard yet because I wanted to
wait what came out of this discussion here first, because this
is the most important issue at the moment.