and the main point is: there is no need to replace network.service
on
*any* static configured machine
(As a short-time initscripts comaintainer way-back-when:) There may not be a need for
anything smarter than init.d/network for machines with _trivial_ static configuration (a
few interfaces with static IP addresses), but it starts breaking down very quickly with
more complex setups.
Networking is inherently a DAG: IP alias ON TOP OF a bond ON TOP OF an Ethernet vlan ON
TOP OF a vlan trunk connected through a physical cabe¹, and frequently when something
changes in this DAG (change an IP alias, change bond composition, change vlan tag, change
a performance tuning parameter) it would be useful to also update/refresh configuration of
the other related components. And building the kind of data structure necessary to keep
track of these relationships is pretty much impossible in the shell language², so it
hasn’t been done. init.d/network more or less assumes that the complex cases don’t happen
instead of supporting them properly.
Mirek
¹ This may be a nonsensical example, it’s been about 8 years. But I am confident about
the gist of the issue.
² Well, after seeing ifup-aliases, my sense of what is “pretty much impossible in the
shell language” has been dulled; but maintaining such relationships is another order of
magnitude more complex than ifup-aliases, and given the speed of shell a shell daemon (☺)
would be needed anyway just to amortize the overhead of dealing with the DAG.