I understand the reasoning behind RPROVIDES. I've grep'ed the sources and none of the packages that depend on dbus-x11 have build time dependencies on it, so the question arises "what's the point of PROVIDES?". I understand the compatibility argument, but it seems to me more like an argument when dependencies are not clear, but in this case they are clear. The following packages depend on dbus-x11, at run-time:

radu@dell-desktop>grep . -re dbus-x11
./recipes-bsp/qemu-config/qemu-config.bb:RDEPENDS_${PN} = "distcc ${@base_contains('DISTRO_FEATURES', 'x11', 'dbus-x11', '', d)} task-core-nfs-server oprofileui-server rsync bash"
./recipes-gnome/gnome/gconf_3.2.3.bb:RDEPENDS_${PN} += "${@base_contains('DISTRO_FEATURES', 'x11', 'dbus-x11', '', d)}"
./recipes-graphics/x11-common/x11-common_0.1.bb:RDEPENDS_${PN} = "dbus-x11 xmodmap xdpyinfo xtscal xinit formfactor"

Rephrasing my question, what would happen (potentially bad) if I don't have PROVIDES="dbus-x11" line in my recipe?

Also, I've done a clean build without PROVIDES="dbus-x11" line in dbus.inc and the build finished successfully, as if it were there (tried that as well).

Radu

On 07/26/2012 03:00 PM, Burton, Ross wrote:

On 26 July 2012 12:55, Koen Kooi <koen@dominion.thruhere.net> wrote:

It would be nice if other layers that have RDEPENDS_foo = "dbus-x11" keep working till their maintainers get around fixing them. Note that you might need to do a -c cleansstate on dbus first to trigger any errors.

Yes, and isn't that what the RPROVIDES is for?