On Mon, Oct 5, 2015, at 22:13, Marvin Renich wrote: > The discussion started on d-devel; should it be moved back there? The > overwhelming majority of opinion seems to be in favor of the change.
We have supported per-package behavior on this for a very long time, maybe since forever (this is no joke). We have had packages that restart after the upgrade instead of stopping before, or that ignore service start failures during upgrades for *years*. All it takes is that the package maintainer actually stop to think about it, consider which behavior is more appropriate to that specific package, and adjust things appropriately. There is a damn good reason why policy does not use "must" to mandate service start/stop/restart behavior across package updates. The reason for this thread, an "undesired" behavior of stopping a package upgrade if the service fails to start, which is the current default, is both employed by the (likely few) packages that absolutely depend on it to avoid worse damage down the service/package dependency chain, as well as by packages that the maintainer did not even think about the issue (and therefore might or might not need this behavior). IMO, we should not just "change this default" in the *implementation* (debhelper, etc), at least not without actually acessing the real risk of the change. It does not look like this kind of risk accessment was done by anyone yet in the d-devel thread. Just because we expect it to be low, doesn't mean it doesn't exist or that it won't have a high impact on the user if it happens. If the need for this kind of provision in a possible policy text update (possibly as a foot-note) is contentious, IMHO the matter needs to go back to d-devel for further discussion. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique de Moraes Holschuh <h...@debian.org>
