[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#801065: Section 6.4 - discourage failing install or upgrade when service fails to start



* Henrique de Moraes Holschuh <hmh@debian.org> [151007 09:42]:
> 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*.

Agreed.

> 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.

I enthusiastically agree!

> There is a damn good reason
> why policy does not use "must" to mandate service start/stop/restart
> behavior across package updates.

Again, agreed.  I was not proposing to use "must", and would not support
such a proposal.

> 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).

Right.  And the second case, which is at least perceived by me (and
apparently others) to be the vast majority of services, is what this
proposal is about.

> 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.

Actually, I was not aware that dh had a helper for this that defaulted
to "fail upgrade if service fails", and so was not intending to propose
an automatic change in behavior based on a change to dh.  This part of
it certainly requires more thought and a thorough risk assessment.

My proposal, and what I still think we should do regardless of any
change or lack of change to dh, is to document, in a place that package
maintainers will see, that the "best practice" is to not fail the
install just because the service fails to start.

> 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.

I don't see this as a contentious change; at least the part about
changing what is considered "best practice".  Changing dh hasn't, as far
as I can see, been discussed enough to know whether it is contentious or
not.  But, as you point out, a risk assessment followed by some
discussion on d-devel would be the first two steps.

I don't think a documentation change to "best practices" should be held
up by the dh issue.  Perhaps someone wants to clone this bug to the
debhelper package so the documentation change to developers-reference
and the potential implementation change to debhelper are tracked
independently.  If you would like me to do so, let me know.

...Marvin


Reply to: