Hi Andreas and Robie, Thank you for thoroughly evaluating and investigating this ticket. We both accept that situations arise when a service cannot start after package install/upgrade. For kernel-space service I think the maintainer script should poll and abort in that case. For user-space daemons ideally the maintainer scripts are cognizant to the reality that a failed service, while not ideal, is an acceptable state for a user space daemon. I fully support the underlying philosophy that both you and Andreas have communicated - ideally the service gets started. There is at least one important exception to this philosophy where we want to migrate from provider A to provider B (i.e. apache to nginx) in a rolling fashion and the workflow maybe a stepped process of install B package while service A is still running (and locking resources needed for service B), migrate the configuration, stop service A, start service B, uninstall package A. This is a corner case which I encountered with legacy linux systems. I presume the policy-rc.d mechanism holds across Debian-derivative systems - we have a specific saltstack bug tracking this issue - so this is possible workaround. I need to check that this mechanism is well documented because I was unable to find this API when searching for a workaround to this behaviour. I never saw this issue with Samba-Winbind in Ubuntu 16.04. We both accept that this policy causes difficulties in at least the three cases you have listed. Thanks for the detailed summarization of these issues. On the basis that this is general issue I accept that technically marking this ticket (and a corresponding nginx ticket) as invalid works at maintainer and package level. However please understand this behaviour can be frustrating in the wider scheme of things when we want to design resilient systems where failures are expected. I have not looked at the implementation in detail with DEP packages but would prefer and encourage non-blocking checks by maintainer scripts so apt continues to work. I wanted to ask if there was a Technical Steering Committee (TSC) this matter could be raised with. I lack the bandwidth to pursue this matter at TSC right now - my FOSS work is voluntary - but for the future what is the best way to NOT forget this issue. It's frustrating from Engineer perspective. thanks Noel On Wed, Mar 20, 2019 at 6:50 AM Robie Basak