The dbus recipe packages the dbus-launch into a dbus-x11 package, which is only created if the distro feature 'x11' is selected. I think this is left over from some older version of dbus, AFAICT, in 1.4 dbus-launch does not require x11, only its autolaunch feature does, which is not enabled when building without x11 (and can be explicitly disabled with --disable-x11-autolaunch ).
Saul, can you have another guy to help to look at this? Many many thanks.
We did have a commit 8dc48993f33a3f656a8f980f5c0c048b47bce9cf that splits dbus-launch from the main dbus package. In current dbus configuration, we don't add the parameter "--disable-x11-autolaunch", therefore dbus-launch should still depends on X, right? If this is correct, we couldn't make the dbus package RDEPENDS on libx11 package, otherwise, dbus will be un-usable in Non-X environment.
(In reply to comment #2) > In current dbus configuration, we don't add the parameter > "--disable-x11-autolaunch", therefore dbus-launch should still depends on X, > right? I do not think this is necessary; AFAIK, the x11-autolaunch feature of dbus-launch is configured automatically (by the configure script) based on whether X is available or not. > If this is correct, we couldn't make the dbus package RDEPENDS on libx11 > package, otherwise, dbus will be un-usable in Non-X environment. With dbus-launch in dbux-x11, dbus is not very usable on non-X image either, because you can't start a dbus session without dbus-launch. If it is not feasible to include dbus-launch in the main package, then perhaps there needs to be dbus-nox package that includes dbus-launch built without the X dependency?
Here's my suggestion: 1) remove the --with-x/--without-x configure arguments. If you want to force no-discovery for native builds the correct argument is --disable-x11-autolaunch. This ensures that DBus looks at the build environment to determine whether to enable X11 bus discovery or not. 2) make the virtual/libx11 DEPENDS conditional based on the x11 distro feature. This makes the build dependencies reflect the feature list. 3) remove dbus-x11, meaning that dbus-launch with its potential X11 dependency is now back in dbus where is belongs. 4) Potentially make dbus provide dbus-x11, for compatibility.
What about moving this bug to 1.3 cycle? I think it doesn't impact current functionality severely.
submitted patch, waiting for review.
merged into master.
Bitbaked a core-image-base on latest master commit (e1c1ee19e04eca1ffd09b49104a7b49e89c74d12); dbus-launch is present and seems to work, showing DBUS_SESSION_BUS_ADDRESS and DBUS_SESSION_BUS_PID when executed from shell with no argument. As described, this is a non-x11 build. Does this test suffice in order to set this ti Verified?
The test case for this is that the binary "dbus-launch" is in the dbus package, and not the dbus-x11 package. (the huge debate around when and how to enable/disable x11 was a side-issue)
I see the required changes made to the dbus recipe: OLDPKGNAME = "dbus-x11" RPROVIDES_${PN} = "${OLDPKGNAME}" RREPLACES_${PN} += "${OLDPKGNAME}" FILES_${PN} = "${bindir}/dbus-daemon* \ ${bindir}/dbus-uuidgen \ ${bindir}/dbus-cleanup-sockets \ ${bindir}/dbus-send \ ${bindir}/dbus-monitor \ ${bindir}/dbus-launch \ ${libexecdir}/dbus* \ ${sysconfdir} \ ${localstatedir} \ ${datadir}/dbus-1/services \ ${datadir}/dbus-1/system-services" FILES_${PN}-lib = "${libdir}/lib*.so.*" EXTRA_OECONF_X = "${@base_contains('DISTRO_FEATURES', 'x11', '--with-x', '--without-x', d)}" EXTRA_OECONF_X_virtclass-native = "--disable-x11-autolaunch" I also built a core-image-base and dbus-launch is present and working. I am setting this to verified on: commit e1c1ee19e04eca1ffd09b49104a7b49e89c74d12 Date: Mon Sep 24 08:37:09 2012 +0000