Created attachment 129661 [details] [review]
Get rid of legacy dbus-1.0 include dir location.

Comment on attachment 129661 [details] [review]
Get rid of legacy dbus-1.0 include dir location.

Review of attachment 129661 [details] [review]:
-----------------------------------------------------------------

This is just a cosmetic change, right? Not fixing some functional problem?

If so, I'm not sure this is a good idea. Although the pkg-config files (and hopefully soon DBus1Config.cmake) are the only recommended/supported way to locate libdbus, I suspect that other projects have probably hard-coded dbus-1.0 all over the place anyway.

If you don't like the use of "1.0" in a version considerably newer than 1.0, you could think of "dbus-1.0" as shorthand for "a version of dbus that is API-compatible with 1.0", which is true?

(In reply to Simon McVittie from comment #2)
> Comment on attachment 129661 [details] [review] [review]
> Get rid of legacy dbus-1.0 include dir location.
> 
> Review of attachment 129661 [details] [review] [review]:
> -----------------------------------------------------------------
> 
> This is just a cosmetic change, right? Not fixing some functional problem?
You cannot have installed a dbus stable development package e.g. version 1.8 along with an unstable development package say 1.11. 

Stable an unstable development packages are incompatible in some areas e.g. they may have different headers, different shared library names and so one.

To identify them on UNIX different pkgconfig files are required e.g dbus-1.8.pc and dbus-1.11.pc in which the related library names and header locations need to be specified. In dbus-1 README there is already mentioned a link for this case http://ometer.com/parallel.html.

Having unstable development packages installable for dbus along with stable version may increase the number of users able to test unstable versions.

(In reply to Ralf Habacker from comment #3)
> You cannot have installed a dbus stable development package e.g. version 1.8
> along with an unstable development package say 1.11. 

That is correct, you can't. This is the price we pay for our development branch being API-compatible with (i.e. a drop-in replacement for) our stable branch.

I'm fairly sure we don't have the necessary development resources to maintain two library APIs like Gtk 2 and 3, Qt 3/4/5, Python 2 and 3, or GStreamer 0.10 and 1.0 (all of which unfortunately still seem to have major consumers using the "old" branch). I've been burned by this before - Telepathy 1.0 was a deliberate compatibility break from Telepathy 0.x, it never fully happened, and it has no users.

We also don't have much need to break API or ABI - parts of our current API are unfortunate, but there's nothing that really justifies a break. The only things I can immediately think of that I'd be tempted to break ABI for would be removing the global shared bus connection (along with the idea that the same DBusConnection can be used from two different threads), or removing thread-safety altogether. But I don't think either of those is worth the pain. If we break API/ABI, there is a significant risk that major users of dbus would mostly stick to the old API/ABI, at which point we would have gained nothing, but would still have to maintain the last branch with the old API/ABI essentially forever (potentially a major time sink).

In many ways the most interesting "APIs" exported by dbus are things like the dbus-daemon and dbus-send, which can't easily be parallel-installed anyway.

Also, breaking ABI and offering parallel installation can be quite problematic for nearly-ubiquitous software like libdbus, because if you directly or indirectly link both libdbus-1 and libdbus-2 into the same program's address space, it is undefined which version of dbus_bus_get() will "win".

This is less of a problem in Windows, because Windows symbol resolution is a tree of DLLs rooted at the executable (each user of a symbol knows which DLL it expects the symbol to come from); but ELF (Linux/*BSD/etc.) symbol resolution normally happens in a flat global namespace, and symbols are unfortunately not associated with the libraries they will come from. Symbol versioning partially solves this, but is specific to certain platforms (as far as I know it works for GNU/Linux and Solaris, but not for Android Linux or *BSD).

> Stable an unstable development packages are incompatible in some areas e.g.
> they may have different headers, different shared library names and so one.

Ours aren't. The patterns for header inclusion and library linking that were correct in dbus 1.0.0 are still considered correct in 1.11.x.

> In dbus-1 README there is already mentioned
> a link for this case http://ometer.com/parallel.html.

That would apply if we ever published a deliberately incompatible dbus-2, but we haven't, and I don't intend to for a long time (perhaps never). If we ever do, we can change from -I/usr/include/dbus-1.0 -I/usr/include/dbus-2 at that point.