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?