dbus: Merge dbus-library, dbus-tools and dbus-daemon into a single package

[rickynils]

I ran into a problem where an application (network-manager-applet) tried to execute dbus-launch from /nix/store/...dbus-library.../bin/dbus-launch, which doesn't exist, since the dbus-launch binary is built by the dbus-tools package. It turns out, however, that it is the dbus-library itself that refers to the dbus-launch binary (in its own bin dir). Since dbus-tools depends on dbus-library, this can't be fixed without introducing a circular dependency.

What do you say about merging dbus-library, dbus-tools and dbus-daemon (which already is equal to dbus-library) into one package?

Doing that solves the problem, and doesn't seem to cause any other problems. The only trouble I can imagine, is that some X11 dependencies are introduced in dbus-library:

buildInputs = [ expat ] ++ stdenv.lib.optionals useX11 [ libX11 libICE libSM ];

[7c6f434c]

I think that merging dbus-* is a good idea

[edolstra]

They are split to prevent a dependency on X11 in applications that require the dbus libraries. So we shouldn't merge them.

In the future we can probably use a single dbus package with multiple outputs to handle this.

[vcunat]

Closed, well, but what about the circular dependency, or do we have another solution to the described problem?

[rickynils]

Yes, I also wonder what we should do in the meantime... I have
NetworkManager applet working nicely on my computer now with the dbus
merge, but I haven't found a way to solve the issue in another way.

Den 2012-08-01 20:52:10 skrev Vladimír Čunát
reply@reply.github.com:

Closed, well, but what about the circular dependency, or do we have
another solution to the described problem?

---

Reply to this email directly or view it on GitHub:
#81 (comment)