dbus-glib is a deprecated D-Bus library with some significant design
flaws, and is essentially unmaintained. I would like to minimize its
use, and eventually remove it from Debian. There will not be a
version that fixes its design flaws, because that would be a major
compatibility break, and any user of dbus-glib who is willing to port
their application to a newer, incompatible version should instead be
porting their application to a better D-Bus implementation such as
GDBus.

For most purposes, the recommended replacement for dbus-glib is the
GDBus family of APIs in GLib, found in <gio/gio.h>. This does not add
an additional dependency, because dbus-glib already depends on a
sufficiently new version of GLib. A porting guide is available in the
GLib documentation:
<https://developer.gnome.org/gio/stable/ch35.html>. Practical
examples of porting from dbus-glib to GDBus can be found in the git
history of most older GNOME applications.

Alternatives to GDBus, with different design emphasis and trade-offs,
include sd-bus (systemd's D-Bus implementation), QtDBus (Qt's D-Bus
API), and libdbus (the low-level reference D-Bus implementation).
Please contact the D-Bus mailing list <dbus at lists.freedesktop.org>
if you are unsure which D-Bus implementation is most suitable for a
particular package.

Some libraries expose dbus-glib as part of their API/ABI, in which
case removing the deprecated dependency requires breaking API/ABI
(telepathy-glib is a good example). For these libraries, maintainers
should talk to the dependent library's upstream developers about
whether the dependent library should break API/ABI and switch to
GDBus, or whether the dependent library should itself be deprecated.

In a few cases, the package uses the reference D-Bus library libdbus
for all D-Bus-related APIs, and only uses dbus-glib as a way to
connect libdbus to the GLib main loop: if the only functions
referenced from dbus-glib are dbus_connection_setup_with_g_main() and
dbus_server_setup_with_g_main(), then you are in this situation. The
recommended replacement in this case is to bundle the dbus-gmain
branch from the dbus-glib git repository, for example as a `git
subtree` or `git submodule`. For example, dbus-python's GLib
integration now works like this. See
<https://gitlab.freedesktop.org/dbus/dbus-glib/blob/dbus-gmain/README
.md> for more details.

Hi Simon,

I'm about to do an ITS upload of kbdd[1] and I would love to support
your attempt to minimize the dbus-glib usage.  However, if I simply drop
the libdbus-glib-1-dev Build-Depends this line[2] fails the configure
step.  Since I have no idea about dbus-glib I could need some help to
replace it by something more modern.  Otherwise I could upload the
package as is in Git with at least fixing the dbus-x11 related bugs for
the moment and providing the packaging in Git open for any patch / MR.

Kind regards
    Andreas.

[1] https://salsa.debian.org/salvage-team/kbdd
[2] https://salsa.debian.org/salvage-team/kbdd/-/blob/master/configure.ac?ref_type=heads#L45

Hi again,

after our conversation I dived deeper into this, deactivated
the test in configure.ac which lead to

  dbus-binding-tool: command not found

which makes me assume that

  libdbus-glib-1-dev-bin: /usr/bin/dbus-binding-tool

is needed.  So it seems this bug can't be fixed easily and I
leave it untouched.

Kind regards
    Andreas.

Control: severity -1 important

I'm raising the bug reports for remaining uses of dbus-glib to important
severity. It's now been 11 years since dbus-glib was documented as
deprecated in its own NEWS file, and it hasn't got any better-quality or
more-maintained since then.

It might be useful to note that since the initial MBF in 2018, the
migration guide from dbus-glib to GDBus has moved to
<https://docs.gtk.org/gio/migrating-gdbus.html>.

     smcv

If you want a message to reach the submitter of a bug report, please
remember to Cc them - I didn't see your replies to this bug report until
I happened to see them in the BTS web interface now, because I am not a
maintainer of the kbdd package.

([1] and [2] were broken links, but at the time of writing,
https://sources.debian.org/src/kbdd/0.7.1-1/configure.ac#L45 works as a
replacement reference for [2].)

Yes, if kbdd is written to use dbus-glib then it will require porting to
be able to avoid dbus-glib without dropping features.

If the feature "Enable providing D-BUS object" is not particularly
important, then this package could probably be configured with
--disable-dbus. I have no idea what this package is or what it does, so 
I can't judge whether its D-Bus-related features are essential,
unnecessary, or anything in between.

Otherwise, it will need changes to the C code and build system, which
would be something to be done upstream. Uusually the most appropriate
replacement for dbus-glib is GLib's GDBus, for which there is a porting
guide at <https://docs.gtk.org/gio/migrating-gdbus.html>. Practical
examples of porting from dbus-glib to GDBus can be found in the VCS
history of many older GNOME projects.

Note that kbdd appears to be dead upstream
(https://github.com/qnikst/kbdd/issues/52) so any porting would likely
have to be done by someone who is also willing to become the new
upstream maintainer.

     smcv