Comment # 9 on bug 900505 from pgnd _

> The systemd is configured with --disable-networkd and that is fully legal

My (last) point is that even though that's apparently the case, it's not
relevant to the issue.

As you've just pointed out, one openSUSE systemd in configure with

    --disable-networkd 

Nonetheless, both network.target & network-online.target are loaded/active, and
network-online.target functions as it should.  Or so it seems on openSUSE
testing/examining startup ordering behavior in detail with respect to status of
multiple interfaces, as mentioned/reference above.

That implies, at least, that systemd-networkd is uninvolved in, and unncessary
to, proper function and use of the network. & network-online. services/targets.
 Hence, why would it be necessary in the case of network-pre. ?

> essential to use wicked and its services which, beside NetworkManager, are the tools used to to networking.

"are" the tools? or "will be"?

( Which raises a nagging suspicion for me that 'this' may have to do with
desktop vs server network-stack management implementation ... )

Atm, I currently use neither NetworkManager nor wicked; in fact, neither's
installed

    systemctl list-unit-files | grep -i "network|wicked"
        (empty)
    rpm -qa | grep -i "network|wicked"
        (empty)

I use, simply & preferably, ifup/down mgmt.

> The network-online.target and network.target ...
(snip)

I personally see more harm than value in using "non-systemd-standard"
mechanisms for ordering.  Not for the least of reasons that systemd's well &
throughly documented, and is likely the 1st reference typically used in
administration.

That said, it's admittedly unclear to me why the decision has been taken @
openSUSE to implement the services'/targets' ordering in the mentioned fashion.
 I assume there's some valid reason.

In any case, fine(r)-grained, network-related unit ordering as provided by
upstream systemd is needed, and is arguably a security issue.  The 3-stage
network*.target approach provided by systemd seems well thought out, and
provides that capability.

If current/future implementation of networking stack at openSUSE precludes that
ordering granularity, or provide it in some different, though functionally
equivalent fashion, it should be clarified and documented.

To my read here, it appears that, atm, there are more questions about what &
why than answers.