dh_installsystemd command line arguments handling

[Daniele Nicolodi]

On 6/11/18 3:07 PM, Niels Thykier wrote:
> To answer these we need to answer the following question: As a user of
> dh_installsystemd, when would I want to spell out a service to
> dh_installsystemd as an explicit argument?  What would I be trying to
> solve in this case?
>   By default dh_installsystemd will install all unit files and setup
> maintscript snippets for all of them (which is the common case).
> 
> 
> Options include (but probably not limited too):
> 
>  A: Have dh_installsystemd install a unit file provided in a non-default
>     location.  E.g. assuming upstream provides it but the build system
>     do not install it into the tmpdir.
> 
>  B: To be able to select a subset of the units and choose a non-default
>     maintscript for them.  E.g.  --no-start --no-enable foo.service
>     followed by "--no-restart-after-upgrade bar.service" (in a separate
>     dh_installsystemd invocation).
> 
>  C: Your suggestion/interpretation here...
> 
> AFAICT/AFAIR, the code wants to solve B (but let me know if you have a
> different interpretation/suggestion).

This is my interpretation as well.

> In the interpretation, a call to "dh_installsystemd [--option]
> foo.service" could make sense[1] even if the helper acted on multiple
> binaries (as a "generate only maintscripts for foo.service subject to
> --option").
>   Though at the same time, in that interpretation "foo.service" is
> definitely sufficient to reference the unit file as we must always
> reference an "installed" unit file (as you mentioned yourself).

I fixed the confusion in dh_installsystemd about unit names ans unit
paths and now it works consistently, see merge request on salsa. I'm
however not convinced that guessing which binary package to operate on
based on the unit name is a good idea or worth the extra complication.
Thus that is not implemented. It is not impossible to do if someone
insists that it is a good idea.

Cheers,
Dan