Bug#896944: service: this wrapper script should pass additional options to systemctl(8) when using systemd

[Andreas Henriksson]

Hi,

Not that my opinion really counts, but still....

On Thu, Apr 26, 2018 at 11:12:33AM +0200, Michael Biebl wrote:
> On Thu, 26 Apr 2018 16:26:03 +0800 WHR <msl0000023508 at gmail.com> wrote:
[...]
> > The service(8) script should pass additional options, if any after '${ACTION}', to systemctl(8).
[...]
> I'm uncertain about this. If you want all features of systemd/systemctl,
> I think you should use systemctl directly.
> service is more of wrapper which hides the differences between
> alternative init systems (sysv, systemd, openrc) and is sort of the
> least common denominator.

I agree, but on the other hand this is the documented syntax (from
manpage):

	service SCRIPT COMMAND [OPTIONS]

Also...

	service passes COMMAND and OPTIONS to the init script unmodified.

So I think the patch is technically correct (and thanks submitter for
including a patch!).

This still leaves me torn. While the patch implements the documented
behaviour, but I personally see service as the "portable" command.
By allowing init dependent things to be passed that portability is
broken (and then it provides no value over init dependent equivalents).
I guess the bigger question is: Should the OPTIONS field be deprecated?
Thanks a much bigger task and breaking compatibility for things
that's not in the archive and has to be fixed up by users isn't nice.
I guess the minimum bar if maintainers decide deprecation is the best
is to simply document the deprecation and leave the sysvinit
implementain still functional.

(Maybe to be taken into consideration: How does other distributions
service commands work? We all use different implemations IIRC?!)

Regards,
Andreas Henriksson