Comment 9 for bug 1488453

summary: by adding a systemd openhpid.service file we have parity with previous upstart behavior

== details ==
I've found that installing a systemd service file fixes the problem, and have uploaded the fix to wily.
The designed behavior of openhpi is to exit 8 unless the user edits /etc/openhpi/openhpi.conf to remove:
  OPENHPI_UNCONFIGURED = "YES"

(sudo sed -i 's,^OPENHPI_UNCONFIGURED,#OPENHPI_UNCONFIGURED,' etc/openhpi/openhpi.conf).

The '/etc/init.d/openhpid start' would exit 0 in this case. Upstart would happily go on, and not cause package installation failure.

When init changed to systemd, systemd-sysv-generator started handling the start of the service during installation. That would correctly identify that the forked service started via '/etc/init.d/openhpid start' exited non-zero and pass the failure up to the install script. The install script would then exit non-zero, causing the bug.

So, we ended up with a possibly more correct behavior that caused installation failure.

The interesting thing is that adding the openhpid.service file actually changes the behavior so that the install now succeeds although the service exits non-zero.

The result is that we now act as we did before:
  * fresh installation of openhpid succeeds
  * 'service openhpid status' immediately after clean install will show the service failed to start.