mirror of
https://gitlab.freedesktop.org/NetworkManager/NetworkManager.git
synced 2026-01-05 15:00:25 +01:00
2e2e2f92df
"active_slave" is by now deprecated and became an alias for "primary". If a profile specifies both properties, only "primary" is honored, without failing validation (to not break existing behavior). Maybe we should introduce a normalization for such cases. But normalize might not do the right thing, if a profile currently has "primary" set, and the user modifies it to set "active_slave" to a different value, normalize would not know which setting was set first and remove "active_slave" again. In the past, nm_setting_bond_add_option() performed some simple normalization, but this was dropped, because (such incompatible) settings can also be created via the GObject property. Our C accessor function should not be less flexible than other ways of creating a profile. In the end, whenever a user (or a tool) creates a profile, the tool must be aware of the semantics. E.g. setting an IP route without a suitable IP address is unlike to make sense, the tool must understand what it's doing. The same is true for the bond options. When a tool (or user) sets the "active_slave" property, then it must clear out the redundant information from the "primary" setting. There is no alternative to this problem than having tools smart enough to understand what they are doing. |
||
|---|---|---|
| .. | ||
| cli | ||
| cloud-setup | ||
| common | ||
| tests | ||
| tui | ||
| meson.build | ||
| nm-online.c | ||