James Henstridge wrote: > On 14/02/07, Rob Taylor <[EMAIL PROTECTED]> 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 _______________________________________________ desktop-devel-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/desktop-devel-list
