pulseaudio has RDEPENDS_pulseaudio-module-console-kit =+ "consolekit" and pulseaudio-module-console-kit is dynamic package PACKAGES_DYNAMIC += "^pulseaudio-lib.* ^pulseaudio-module.* ^libpulse-lib.* ^libpulse-module.* " If you have image where consolekit is pulled to image only by pulseaudio-module-console-kit (e.g. through pulseaudio-server). Then consolekit is not built before image do_rootfs is executed and do_rootfs fails. Easy way to reproduce this is to build e.g. core-image-minimal with pulseaudio-module-console-kit or pulseaudio-server added to IMAGE_INSTALL. Will fail with: * satisfy_dependencies_for: Cannot satisfy the following dependencies for pulseaudio-server: * consolekit * * opkg_install_cmd: Cannot install package pulseaudio-server. Not sure what's proper fix, bitbake probably just checks that right provider for pulseaudio-module-console-kit is pulseaudio because of PACKAGES_DYNAMIC, but does not check RDEPENDS_pulseaudio-module-console-kit after that. We can add consolekit to build time deps like it was before, but that's just work around and not correct fix.
(In reply to comment #0) > pulseaudio has > RDEPENDS_pulseaudio-module-console-kit =+ "consolekit" > > and pulseaudio-module-console-kit is dynamic package > PACKAGES_DYNAMIC += "^pulseaudio-lib.* ^pulseaudio-module.* ^libpulse-lib.* > ^libpulse-module.* " > > If you have image where consolekit is pulled to image only by > pulseaudio-module-console-kit (e.g. through pulseaudio-server). > Then consolekit is not built before image do_rootfs is executed and > do_rootfs fails. > > Easy way to reproduce this is to build e.g. core-image-minimal with > pulseaudio-module-console-kit or pulseaudio-server added to IMAGE_INSTALL. > Will fail with: > * satisfy_dependencies_for: Cannot satisfy the following dependencies for > pulseaudio-server: > * consolekit * > * opkg_install_cmd: Cannot install package pulseaudio-server. > > > Not sure what's proper fix, bitbake probably just checks that right provider > for > pulseaudio-module-console-kit is pulseaudio because of PACKAGES_DYNAMIC, but > does not check > RDEPENDS_pulseaudio-module-console-kit after that. > > We can add consolekit to build time deps like it was before, but that's just > work around and not correct fix. Updating with RP's reply on email http://lists.linuxtogo.org/pipermail/openembedded-core/2012-November/032223.html Bitbake sees "pulseaudio-module-console-kit" and is has to ask "Which recipe provides this". To answer that question, it looks first at PACKAGES and then at PACKAGES_DYNAMIC. In this case it will find a match for PACKAGES_DYNAMIC but bitbake considers this a fuzzy match. We only match dynamic packages right at the end of processing and they are "fuzzy". Basically, they are just a sanity check in bitbake to ensure there is some chance of the thing getting built. I can see in this case that a dependency exists that BitBake could use to enhance its knowledge, the trouble is that is would have to first decide which provider is providing PACKAGES_DYNAMIC, and then search that package for extra RDEPENDS. In this case its "easier" since its all the same package but with our generic providers mechanism, this could just as easily be split between two recipes which makes the problem at lot more complex and the code has to be written for the general case. I suspect we'll just have to add this. I agree it would be possible to try and figure out this corner case but whether its worth the complexity and extra parse time I'm not sure. The risk of adding further bugs trying to add this functionality would worry me, as would the extra complexity and the time taken to do it...
Fixing this is hard and could come at a high performance overhead (e.g. iterating the datastore to look at RDEPENDS:*). When originally written that was huge overhead by iterating the whole datastore. With the override syntax changes, it may be possible just to iterate the overrides of variable. I'm also wondering if we could detect this situation having happened during the package generation and warn the user, that may be something that would now trigger with the existing code changes? So still an issue but we may stand a better chance of dealing with it now...