On Tue, Feb 28, 2012 at 09:09:22PM +0100, Andrew Shadura wrote: > On Tue, 28 Feb 2012 11:27:37 -0800 > Steve Langasek <vorlon@debian.org> wrote: > > > However, it's been reported that some scripts return wrong exit > > > codes sometimes, causing failure during network configuration. > > My doubt here is: what is the definition of a *right* exit code now, > > from ifupdown's POV? When is it appropriate for a hook which has > > failed to exit non-zero? > When failure to execute a hook leads to interface being non-operational. Yes, that's probably a reasonable threshold. What should packages like miredo and wide-dhcpv6-client do? Both of these hooks have to do with routing information; if an interface comes up but the hook fails, the interface may be operational but not actually routing traffic to the networks the user cares about reaching. Should these hooks exit non-zero on failure, or not? Could this guidance be included in the ifupdown documentation as a clue to maintainers? > > This is a pretty significant change in behavior from the perspective > > of the packages providing hooks, as it means that they now have to > > avoid giving meaningful exit codes in order to not cause ifupdown to > > fail to run subsequent hooks. OTOH, there might be cases where > > that's beneficial because it lets a critical hook declare that an > > interface bring-up hasn't succeeded and the interface bring-up should > > be rolled back so the admin can try again. But how do we define > > "critical" hooks? > This isn't a change in behaviour at all. Er, it most certainly is. You may argue that the previous behavior was *wrong*, but it's just plain false to say that the behavior isn't changing. And the change is incompatible with at least some existing hook scripts, which means it's incumbent on you as the ifupdown maintainer to coordinate this behavior change with the maintainers of those other packages. *Not* just filing a bug on "general", but actually following through on this transition to make sure things get fixed as needed. On Tue, Feb 28, 2012 at 10:54:38PM +0100, Andrew Shadura wrote: > > And if you really want/need/do this change which needs changes in 30 > > (or so) other packages, then please file 30 bugs against those > > package and then use these bugs as blockers against one bug for > > tracking. (And I'd prefer this bug to be one against ifupdown and not > > general, but YMMV.) But, definitly, filing a bug against general > > saying these and these package need to be fixed wont do it. > It does NOT involve all of those packages directly. Most of them do > things correctly, some don't. That's why I've asked all the maintainers > to do checks needed, just to make it easier, so people review their > packages only and don't go into deep of others' packages. A bug filed against "general" is not an appropriate means of notifying package maintainers of anything at all. "general" bugs are sent to debian-devel, which maintainers are not required to follow. I think Holger is right that this needs to be done as a mass bug filing or other coordinated effort to review all of the hooks. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer http://www.debian.org/ slangasek@ubuntu.com vorlon@debian.org
Attachment:
signature.asc
Description: Digital signature