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

[Andreas Henriksson]

Hello Alexandre!

On Fri, Oct 31, 2014 at 08:38:05AM +0100, Alexandre Detiste wrote:
> 
> Hi,
> 
> If you services includes:
> >[Unit]
> >RefuseManualStart=yes
> >RefuseManualStop=yes
> but no [Install] insection, they can't be enabled nor started; 
> they are only pulled in by the matching timer when they elapse.
> 
> Does this solve your problem ?
[...]

First, the services doesn't contain these (which could
ofcourse be changed)....

The second problem is that I'm skeptical that's actually gives
the desired behaviour. I don't want to disallow manual startup.
I want the *package* to not manually start the service (ever).

Take for example the fstrim service/timer which runs once a week.

Say for example you do lots of package builds, run yocto or whatever
that really trashes your disk. The performance on your SSD becomes
crappy and you don't want to wait another week before this is fixed
up by the fstrim.timer. I'd think it would be nice if you could
then just "systemctl start fstrim" .... ofcourse you could also
run /sbin/fstrim directly, but then you'd probably have to go
look at the manpage to find the proper commandline arguments,
think twice if there are any gotchas involved to not mess up your
system, etc. All things you don't really have to bother with if
you could just start the service manually.... it does what you want
to get done after all.

As you probably figured, I'm not completely sold on your suggestion.

Do you know any case where a matching service+timer actually wants
both started on package install/upgrade?
Same question for matching socket+service?


Regards,
Andreas Henriksson