[systemd-devel] /usr vs /etc for default distro units enablement

[Michael Biebl]

2014-11-18 15:40 GMT+01:00 Colin Guthrie <gmane at colin.guthr.ie>:
> Longer term, I want to move this to filetriggers. We have been using
> filetriggers for a while via an RPM patch and it looks like some kind of
> similar functionality will be (at long last) making it to upstream RPM
> in the nearish future. I believe .deb supports something like this?
>
> If this is the case, I'd use a filetrigger to spot the
> /usr/lib/systemd/system/*.{service,socket,...} units and then call
> systemctl preset on them.
>
> I've not yet switched over to this logic yet myself (mainly due to lack
> of time to refactor stuff) so I can't really talk from practical
> experience yet or highlight any "gotchas" (one thing I do know is that
> any service start/reload/restart we may do in %post would have to be
> delayed and left to a filetrigger too because we'd have to do this
> *after* the call to preset. So I may have to make the current
> %_post_service macro just write out some kind of state somewhere to say
> "try to start/reload/restart this service" and then process that state
> in another filetrigger with the same matching regexp but which runs
> later in the %posttrans)
>
> Sorry if that's a bit RPM specific, but I think the same concepts hold
> true in .deb.

As a maybe interesting datapoint, we did use file-triggers in Debian
wheezy to enable unit files.

But this proved to be to inflexible, so we moved away from that model
and let this be done via maintainerscripts now, via dh-systemd helper
to autogenerate that code.

file triggers are great for simple cases, like rebuilding icon caches,
updating the initramfs etc, though.