Comment 40 for bug 44194

> I disagree to an extent, the problem doesn't sound specific to
> wpa_supplicant's shell glue at all,

If wpasupplicant tells ifupdown that it's done configuring the
interface, and that everything went fine, but it that's not actually the
case... That's wrong. No matter how you look at it.

> but rather, the inflexibility of the statically maintained ifupdown
> software on an ever evolving Debian/Ubuntu software ecosystem.

What exactly do you mean by "statically maintained"?

> A "cheap" fix could be included in an individual ifupdown hook script,
> but it strikes me that the central network dispatcher/configurator
> framework should be striving to handle situations such as that
> described, as future hooks may also fall prey to this pitfall.

"situations such as that described"? You mean a particular application
having specific needs? It's not ifupdown's responsibility to know about
all these things. If wpasupplicant doesn't know when it can expect to be
succesful, how on earth should ifupdown know?

Leaving this decision to each of the modular network configuration
things is the right thing to do. I don't see any reason at all why you'd
want to put something like that into ifupdown.