DBus GLib API

[Rob Taylor]

James Henstridge wrote:
> On 14/02/07, Rob Taylor <rob.taylor at codethink.co.uk> wrote:
>> Rob Taylor wrote:
>> > (Changing subject appropriately, should have done this earlier..)
>> >
>> > Havoc Pennington wrote:
>> >> Parallel install will be of limited value most likely if any
>> *libraries*
>> >> in the typical GNOME/GTK stack use dbus-glib, because you'll probably
>> >> still use some of the same symbol names. That is, as soon as a lib in
>> >> the stack uses a dbus-glib ABI, that ABI is locked in.
>> >>
>> >> You might address this by strongly discouraging such a dependency in
>> >> several places online and in the docs, or something, if changing ABI
>> >> looks necessary.
>> >
>> > Hmm, there's a *lot* of libraries using dbus-glib-1 right now (13 on
>> > Ubuntu Edgy, according to apt-cache rdepends). The aim would be to
>> allow
>> > us to break ABI at will without disturbing these current users. I guess
>> > the right thing is to go to dbus-glib-2.
>>
>> To be clear - the solution I'm suggesting is to have the API version in
>> the library name, like gtk+ or gstreamer. We could just as well go to
>> dbus-glib-1.1 or dbus-glib-2. Personally I rather like the way Gstreamer
>> does it: major.minor, with minor being odd signifying that its an
>> unstable API.
> 
> The problem here isn't the naming of the library.  The problem is if
> something like the following occurs:
> * Some application links to both libfoo and libbar
> * libfoo adds a dependency on dbus-glib-X
> * libbar adds a dependency on dbus-glib-Y
> 
> Now the application is linked to both dbus-glib-X and dbus-glib-Y.  If
> the two versions of dbus-glib share any symbols, then you will get
> undefined results (since with ELF, libfoo and libbar will be linking
> to the dbus-glib symbols by name, rather than binding to the
> particular version they link with).  For platforms where the ELF
> linking is not a problem, you'd still get into trouble if the two
> versions of dbus-glib tried to register GTypes with the same name.
> 
> So while having parallel installable dbus-glib versions is okay for
> applications to use, it'll be a nightmare if libraries that are part
> of the Gnome platform depend on different versions.
>

Oh, damn, of course. Good point on GTypes as well, so even gnu symbol
versioning can't save me here (not that I'd really want to go there anyhow).

The problem is that dbus-glib's ABI sucks for forwards-compatibility
right now, especially with DBusGMethodInfo and DBusGObjectInfo, which
are tied into the code generated by dbus-binding-tool.

Can anyone with a bit more library maintenance experience give me some
advice on the best way forward? I don't want to just ignore the ABI
issue, given the rapidly growing number of components depending on
dbus-glib. Is the best thing to try and maintain ABI going forwards and
deprecating symbols as needed? I'll also take a look at the main library
users, if they're just using the mainloop integration perhaps
Alexander's suggestion of splitting off a static library with just the
mainloop integration would be a sensible option.

Thanks,
Rob Taylor