dbus: fix emitting D-Bus NetworkManager's old-style PropertiesChange signal

Before switching to gdbus (before 1.2.0), NetworkManager used dbus-glib.
Most objects in the D-Bus API with properties had a signal
NetworkManager-specific "PropertiesChanged" signal. Nowadays, this way of
handling of property changes is deprecated for the common "PropertiesChanged"
signal on the "org.freedesktop.DBus.Properties" interface.

There were a few pecularities in 1.0.0 and earlier:

  (1) Due to the implementation with dbus-glib, a property-changed
    signal was emitted on *all* interfaces. For example:
      - a change on a NMDeviceVeth of "NMDeviceEthernet.HwAddress" would be
        emitted both for the interfaces "fdo.NM.Device.Ethernet" and
        "fdo.NM.Device.Veth". Note that NMDeviceVeth is derived from
        NMDeviceEthernet and there is no "HwAddress" on veth device.
      - a change of "NMVpnConnection.VpnState" was emitted on both
        interfaces "fdo.NM.VPN.Connection" and "fdo.NM.Connecion.Active".
        Note that NMActiveConnection is the parent type of NMVpnConnection and
        only the latter has a property "VpnState".
  (2) NMDevice's "fdo.NM.Device" interface  doesn't have a "PropertiesChanged"
    signal. From (1) follows that all property-changes for this type were instead
    invoked with an interface like "fdo.NM.Device.Ethernet" (or multiple
    interfaces in case of NMDeviceVeth).

1.2.0 introduced gdbus, which gives us the standard "fdo.DBus.Properties"
signal. However, it made the mistake of not realizing (1), thus instead
of emitting the signal once for each interface, it would pick the first
one in the inheritance tree.

With 1.4.0, a bug from merge commit 844345e caused signals for devices
to be only emitted for the interface "fdo.NM.Device.Statistics", instead
of "fdo.NM.Device.Ethernet" or "fdo.NM.Device.Veth" (or both).

The latter is what bgo#770629 is about and what commit 82e9439 tried to fix.
However, the fix was wrong because it tried to do the theoretically correct
thing of emitting the property-changed signal exactly once for the
interface that actually ontains the property. In addition, it missed that
NMDevice doesn't have a PropertiesChanged signal, which caused signals for
"fdo.NM.Device" to get lost *sigh*.

Now, restore the (broken) behavior of 1.0.0. These old-style property changed
signals are anyway considered deprecated and exist solely to satisfy old clients
and preserve the old API.

Fixes: 63fbfad3705db5901e6a2a6a2fc332da0f0ae4be

https://bugzilla.gnome.org/show_bug.cgi?id=770629
https://bugzilla.redhat.com/show_bug.cgi?id=1371920

0 files changed, 0 insertions, 0 deletions