Grant has already started working on your prior review comments 1 & 2 to reduce some of the complexity and excessive nesting for next release to aid in maintainability of this section.
For the comment about "the other checks are either superfluous, or actively harmful."
I'm not certain how this section will be harmful here, if we are in chroots, we should be skipping this section in general because our initial `if [ -d /run/systemd/system ]` check. If this code happens to run in a chroot w/ run/systemd/system present we also avoid non-zero exit in the failure case if systemctl or deb-systremd-helper error.
I presumed this was also why debhelper snippets is automatically adding the similar check prior to invoking `systemctl ...`.
Are you suggesting we don't use systemctl or deb-systemd-helper tools directly and instead just attempt to unlink systemd timer/service link files to ensure we continue to disable ua-timer.timer if ua-messaging.timer is not represented as enabled?
Thanks for the review here Steve.
Grant has already started working on your prior review comments 1 & 2 to reduce some of the complexity and excessive nesting for next release to aid in maintainability of this section.
For the comment about "the other checks are either superfluous, or actively harmful."
I'm not certain how this section will be harmful here, if we are in chroots, we should be skipping this section in general because our initial `if [ -d /run/systemd/system ]` check. If this code happens to run in a chroot w/ run/systemd/system present we also avoid non-zero exit in the failure case if systemctl or deb-systremd-helper error.
I presumed this was also why debhelper snippets is automatically adding the similar check prior to invoking `systemctl ...`.
Are you suggesting we don't use systemctl or deb-systemd-helper tools directly and instead just attempt to unlink systemd timer/service link files to ensure we continue to disable ua-timer.timer if ua-messaging.timer is not represented as enabled?