Replace unknown oip-cpi-mandatory.target in systemd service file

[martin-ejdestig]

With a well known systemd target. oip-cpi-mandatory.target is Continental specific?

Do not know for sure that multi-user.target is the best one. Perhaps the administrator service should be changed to be D-Bus activated in the future since it is not required to be running all the time (if I have understood things correctly).

[gunnarx]

I think this is a reasonable change but it opens up a slightly larger discussion about where to put systemd unit files in components. Your question about which target to use, and on-demand activation, reflects that the unit file is often a distro-specific configuration file - it has to do with how the component gets integrated into the distro, or product.

In my opinion this is a reasonable approach:

1. Provide the best possible example unit file with the component source code.
2. Do not install it by default, but include a configuration flag to install it.
3. Let the distro build install the unit file (either provide its own file, or install the component-provided one).

(N.B. meta-ivi would be a distro of sorts, in this case)

[martin-ejdestig]

Having systemd unit files in components themselves is common practice in the rest of the FOSS world. If there is something that needs to be configurable there is usually a .service.in file used as a template for the .service file so it can be tweaked with build options. (Every distro doing their own init stuff is a remnant from the old (and bad) SysV days, I think. ;)

[gunnarx]

Having systemd unit files in components themselves is common practice in the rest of the FOSS world

OK, I accept that. Actually I suggested that it ought to be. So... I assume your diff is that it should be installed by default.

(Every distro doing their own init stuff is a remnant from the old (and bad) SysV days, I think. ;)

I'm not sure I fully agree with this 100% :) Software is still being packaged by distros. And if it's not packaged... then it is run in self-contained...uh, containers. The desired start/restart behavior could definitely differ, and more so when we talk about dedicated products such as these automotive/embedded systems. Creating that would be helped by the template and build-configuration steps you propose (which the distro builds will dis/enable differently).