View Single Post
Posts: 287 | Thanked: 862 times | Joined on Dec 2015
#54
Originally Posted by ruff View Post
Daemons are controlled by systemd or by user. Even when it is dbus unit it's still called and spawned via systemd. So either you start it in cli manually or via systemd.
Conflict statement allows isolation of the services to avoid "strange unpredictable" behaviour.
Pebbled app allows start/stopping the service and see its status. rockpoold is autostarted by app, moreover app locks down when daemon is not running (falls to waiting for service page).
This basically grants certain predictability, not providing ultimate solution. Bcz ultimate solution should be a user's choice, nor programmer's.

To be completely on the safe side we might implement checks for the stray pebbled processes (eg service is down but process is running) but that's too much overhead and unless reported with certain persistence by users - should be avoided.
I'd rather not have explicit references to other applications in the code, but we're not fixed to the RockWork design. A lot of that comes from workarounds for the Ubuntu platform. What would you think about having the same service control in Rockpool as Pebbled? I'd already partially migrated the ServiceControl over. It would be easy to add methods to enable or disable the service.

Tbh I'm coming round to the idea of declaring a conflict with pebbled in the RPM. I don't think smokku would mind really.

Btw I added a gitter chatroom. I thought it might be a good place to discuss finer implementation details in realer time.

https://gitter.im/abranson/rockpool
 

The Following 4 Users Say Thank You to abranson For This Useful Post: