Bug 31515

dbus-glib should create a new repository / tarball then.

This is probably too tiny to be reasonable in its own tarball ... each tarball is some extra work for all the release managers and packagers in the world.

one way to go is to just say glib apps need to use gdbus instead of libdbus. (they can keep using dbus-glib until they port, of course)
But this is a fairly harsh rewrite for apps.

another approach could be to drop this code into libegg for cut-and-paste

or it could go in some other repo, maybe even glib itself, I don't know.


I wouldn't object to adding it to libdbus but it's up to Thiago and others who are making releases.

(In reply to comment #2)
> I wouldn't object to adding it to libdbus but it's up to Thiago and others who
> are making releases.

My inclination would be to add a new top-level directory to dbus, move the dbus-glib main loop glue there, and make it compile into a tiny second shared library if GLib is available at compile-time. GLib should remain an optional dependency; you just won't get the main-loop glue if you don't have GLib.

I'd expect distributions to make their dbus source package build-depend on Glib, and produce a new binary package (libdbus-gmain-1-0 or something) containing the main-loop-glue shared library.

Won't this cause a circular dependency due to gdbus?

My opinion is that dbus shouldn't build any installable targets that depend on glib. Tests are ok.

(In reply to comment #4)
> Won't this cause a circular dependency due to gdbus?

Looks like glib has an optional dependency on libdbus; it's used by one of the gdbus tests.  The gdbus code itself is a complete reimplementation and doesn't use libdbus.

(In reply to comment #2)
> one way to go is to just say glib apps need to use gdbus instead of libdbus.
> (they can keep using dbus-glib until they port, of course)
> But this is a fairly harsh rewrite for apps.

I think it's worth it: GDBus is so much better for GLib apps than libdbus that it should be what we recommend.

Most GLib apps have already moved; it's mostly only the difficult cases (NetworkManager, Telepathy) that are still using dbus-glib.

Sorry for commenting on a bug so long closed. But in any case:

(In reply to Simon McVittie from comment #6)
> (In reply to comment #2)
> > one way to go is to just say glib apps need to use gdbus instead of libdbus.
> > (they can keep using dbus-glib until they port, of course)
> > But this is a fairly harsh rewrite for apps.
> 
> I think it's worth it: GDBus is so much better for GLib apps than libdbus
> that it should be what we recommend.
> 
> Most GLib apps have already moved; it's mostly only the difficult cases
> (NetworkManager, Telepathy) that are still using dbus-glib.

And what happen with at-spi2-core, the original need that lead to this bug open? 

While this discussion was settling up, in order to fix bug 28778 (that asked to remove the dbus-glib dependency), Mike Gorse just made a C&P of those two functions. I bringing this back because last year a bug was opened to avoid that C&P, and bringing back dbus-glib:

https://bugzilla.gnome.org/show_bug.cgi?id=710630#c3

FWIW, I also think that removing the C&P makes sense, but from the comments (and resolutio) of this bug, I understand that those methods will not be placed anywhere else. So is good enough to just bring back the dbus-glib dependency or there is a better alternative?