Thank you for taking the time to report this bug and helping to make Ubuntu better.

I accept that it is a problem that situations can arise when a service will fail to start (for example by system misconfiguration, or as a result of necessary changes to local customisations triggered by a release upgrade), and this causes apt to fail when maintainer scripts fail to start such a service.

The underlying principle that leads to this behaviour is the long standing philosophy that if a user installs a package, it is presumed that the user intends to use it, and so after installation is complete the service for which the user installed the package should be active with sensible defaults. This is why packages that provide services configure and start them by default.

As Andreas points out, you can control this behaviour using policy-rc.d, which is the mechanism provided to allow sysadmin override of service control behaviour.

In my view this policy causes difficulties in three cases:

1) On servers, a package's default behaviour often isn't useful, and it is expected that the user is a sysadmin who will configure the daemon. In this case, an automatic service start on package install just gets in the way. In my opinion, management tools (chef, puppet, ansible, etc) should therefore automatically use policy-rc.d on Debian and derivatives to provide more sensible default behaviour in their automation case, but they currently do not. You mention saltstack so that sounds like this problem applies here. This point however is a tangent to your assertions about service and package manager integration.

2) On server packages, it is fairly common for users to end up in a misconfigured state where a service cannot be started. This causes problems on package upgrades, since sometimes a user isn't impacted by the service start failure, but does get impacted by a subsequent service restart attempt on package upgrade unwinding through to an apt failure.

3) On release upgrades, intentional changes to how packages operate may invalidate previous local customisations, breaking services until the customisations are updated manually. This can be mitigated somewhat by smarter package upgrade paths, but fundamentally cannot be eliminated in the general case.

I therefore accept that "something needs to be done". However it is clearly a general problem and not one specific to winbind, and the right way to solve this is to find a general solution for individual packages to implement. The solution needs to come from the top, not from individual package maintenance changes on a piecemeal basis; otherwise we'll just end up with inconsistent behaviour and confuse users further.

In the meantime, nothing in particular has changed in the way Debian and Ubuntu work. Under the current design, it is still a local configuration problem that a service is enabled but fails to start. If this happens by default, then it is a bug in packaging. If it happens because of some local event, then it is something that is expected behaviour that needs to be addressed by the sysadmin. If your automation is not using policy-rc.d, then under the current distribution design your automation is buggy on Ubuntu, as well as on Debian and other Debian derivatives.

That we have a higher level concern suggesting a design change does not stop this being true.

To manage this most effectively, I think the only reasonable path forward is to treat individual reports of local misconfigurations as unactionable (bug status Invalid), but we can certainly have a higher level bug open, with Wishlist importance, proposing a change in distribution design in how we manage service restarts on package upgrades. Such a bug needs to be written up carefully to cover the generic case and accomodate multiple use cases.

Therefore I'm marking this bug Invalid to accurately reflect that there is no action that can currently be taken on your concern except for a separate general and extensive effort, but feel free to discuss further.