Comment 11 for bug 1794825

We have a manual section for override_dh_installinit
 64 override_dh_installinit:
 65 »···dh_installinit -pibacm --onlyscripts
 66 »···dh_installinit -prdma-core --onlyscripts --name=iwpmd
 67 »···dh_installinit --remaining-packages

And only the autosections for dh_installsystemd which would do right thing these days (for systemd only).

There is also /etc/init.d/ibacm for old style sysV, but due to the sysV->systemd wrapping this mis-starts the systemd unit.
This is our issue ^^

We can:
- remove the sysV file - that would avoid the dh helpers to pick it up and mis-start it through those wrappers.
- install the sysV scripts with --no-start (to keep them available but not messing up through the wrappers)

Both somewhat inhibit the sysV compat, with the second less so.
And since systemd is the de feacto default init - and in Ubuntu sysV also not being supported I think the latter is what we can try and upgrading to the former if not enough.

I have put a ppa with such a fix to [1].

Tests:
#1 - Upgrading from broken state to the fixed PPA: working
     This no more has the restart, so the upgrade works (otherwise it was failed postinst).
     The systemd services stay "as they are" which is socket up and service failed (ok).
#2 - fresh install from fixed PPA: not working
     The no-start of dh_installinit has carried over to dh_installsystemd which is not what we
     want.

A second approach (before droppign the sysV script) would be to not call the dh_installinit for it in the override section, the result will depend what it picks up automatically.

Tests:
#1 - Upgrading from broken state to the fixed PPA: working
     This no more has the restart, so the upgrade works (otherwise it was failed postinst).
     The systemd services stay "as they are" which is socket up and service failed (ok).
#2 - fresh install from fixed PPA: not working
     The service&socket are still dead.

Hrm, it only has the dh_installsystemd snippets to enable, but none to start it.
Need to continue next week on this ...

Once fixed IMHO combining this with the Condition I check would be best, I'll re-ping on the mail thread and extend the PR once I found a working approach to the sysV-vs-systemd mess in this case.

[1]: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/3477