Die dbus-glib, die!


dbus-glib debuted in 2002 and was the first usable D-Bus client library for GLib-based applications.  NetworkManager used it since the earliest commits in mid-2004.

Why do you care?

Apps and services built on it and enabled the modern desktop.  If you’ve ever tried to code directly to libdbus to add a D-Bus service or talk to one you know what a pain that is.  dbus-glib made that process infinitely easier but had a ton of quirks that didn’t fit well with an evolving GLib. But in the past 5 years the GLib authors recognized that D-Bus needed first-class support and they wrote GDBus with much better GLib integration and a modern asynchronous API.  dbus-glib has been on life-support for years.  It was time to move on.

The upcoming NetworkManager 1.2 release will finally remove use of dbus-glib for the daemon, command-line/TUI utilities, nm-applet/editor, and VPN plugins if you build with legacy components disabled.  Almost nobody noticed this in-flight rebuild of the airplane and that’s exactly how we like it.  I cannot understate how much work this was and how much careful planning we (well, mostly Dan Winship) did to ensure we didn’t break backwards compatibility of either the utility libraries or the D-Bus interface.

To be fair, this is a slight lie; we can’t maintain C API/ABI compatibility in the legacy client libraries by removing dbus-glib and we cannot drop them yet either.  But we did write the new libnm which much more closely matches GLib coding practices and API, including GCancellables and asynchronous functions.  Its API is close enough to the old libnm-util and libnm-glib that porting to libnm is not a huge task, and porting will actually remove code from your application too.  Seriously: the libnm port for nm-connection-editor was +772/-1203 lines of code and nm-applet was +697/-990.  Killing code feels great.

We’ve already ported over all the NetworkManager tools like nmcli, nmtui, nm-applet, nm-connection-editor, and all the VPN plugins.  In the process, we cleaned up a ton of code, created better client APIs, wrote more testcases, reduced the dependency chain, and paid down most of our technical debt.  When kdbus (or bus1 or whatever it’s called) eventually hits, NetworkManager will be ready.

The future is dbus-glib-free.

One thought on “Die dbus-glib, die!”

Comments are closed.