Bug#767429: dh-systemd: Please improve timer unit handling

[Alexandre Detiste]

>I've looked at how to make a package where upstream installs systemd
>service and timer units to not start the service during package postinst.
"systemctl mask unit_name --runtime" ?
The masked unit in /run will go away on reboot.

>If I have to manually list each and every unit explicitly that will likely
>lead to me missing to update it when a new one gets added upstream.
If the upstream package really ships a *lot* of timers/services,
it could define a *single* target on build and pull everything from there.

>> RefuseManualStart=yes
> I'm skeptical that's actually gives the desired behaviour.
> As you probably figured, I'm not completely sold on your suggestion.
Indeed, this is only a good practice that solves the most simple cases.

> I don't want to disallow manual startup.
> I want the *package* to not manually start the service (ever).
That gets complicated, AFAIK  systemctl doesn't care by who it is called.
Maybe you'd the need to patch the package or duplicate the unit;
neither seems nice solutions.
 
> look at the manpage to find the proper commandline arguments,
Why not "systemctl cat fstrim.service | grep ExecStart" ?

> Do you know any case where a matching service+timer actually wants
> both started on package install/upgrade?
No, I think your patch make sense, and enable sane defaults that can be overiden if needed;
...but I'm not in pkg-systemd-maintainers and I'm not the right person to apply/review it.

The only native timer I've found in Debian packages is systemd-tmpfiles-clean.timer;
and a lot left to be decided for native timers "early adopters". 

At some point, the Policy should state what to do for upstreams that
ships both crontabs in /etc/cron.d/ and a matching native timer.
( the crontab remains needed by sysvinit + cron users)

Alexandre Detiste