2014-06-03 14:11 GMT+02:00 Miloslav Trmač <mitr@volny.cz>:
> installPackages()        # install packages and groups
> #uninstallPackages()     # uninstall packages and groups, fails if
> deployed - not initially
>
> The caller managing the server doesn‘t need to know that; this is
> an implementation detail of the role.

Doesn't need to know what?

Anything about packages; the caller should just say “install postgres” and never hear about RPMs.  (Notably, this would allow us to transparently switch from RPMs to Docker images—and even back the other way if necessary.)

> startServices()          # start the services restartServices()
> # restart the services stopServices()           # stop the
> services
>
> The caller managing the server doesn‘t need to know that; this is
> an implementation detail of the role.

Same question.

Same answer: just say “start postgres” and never hear about systemd units.  Especially when there already is start() and stop(), exposing the subcomponents of that API is rather redundant.

To be more clear about the two comments above, I’m not saying that the D-Bus service shouldn’t know about packages or systemd services, or that roles should explicitly implement start() and stop() instead of providing static data like package and service names.  But these should only be visible in the Server role D-Bus service <-> individual role API (internal and free to be modified), not in the anybody <-> D-Bus service API (published and stable forever within that API version).
    Mirek