Move network_ready to globals

[albertvaka]

This function is used in ip which might be sourced from auto.action instead of network, so this makes it available from every code path.

Solves #191

[joukewitteveen]

Oof, interesting catch. network_ready is also used in network and it makes sense to keep related functions together. An alternative solution is to source network from auto.action, but I don't like that either since it would be a very hidden dependency. Sourcing it from ip is a possibility too, but I don't want libraries sourcing each other. I'll have to take a closer look when I find some time again to do some much needed developments.

[albertvaka]

FWIW, this is the cleanest change I could find, since network_ready is called from a bunch of places.

[joukewitteveen]

Thinking a bit more, I came to agree with your suggestion of moving it to globals, but thinking even more, I realize that it would actually be incorrect. The service type for netctl-auto is forking rather than notify, as it is for the netctl service. This means no "read" notification should be sent at all.

Still, this is a bug and I agree #194 is worth pursuing. There are several fixes imaginable

• Add a 'fallback' definition in auto.action.
• Add a default definition in globals.
• Add a wrapper in globals that checks whether the function is defined before calling it.
• Add that check in the wireless connection type (the only one affected).

I need some time to think about which option I like best. Arguments are very welcome!

[albertvaka]

My understanding is that calling systemd-notify --ready from a forking unit has no harmful effect (or rather, no effect whatsoever), so I went with this option because it's simpler. I don't know enough the different code paths to evaluate your proposed solutions, though.