On Tue, 2012-11-27 at 21:23 +0100, Martin Jansa wrote: > On Tue, Nov 27, 2012 at 08:11:42PM +0000, Richard Purdie wrote: > > On Tue, 2012-11-27 at 16:41 +0100, Martin Jansa wrote: > > So basically, you need to decide whether you want consolekit enabled or > > not and build accordingly, there is nothing you can do within bitbake to > > "mind read" what the image is going to want... > > No, you know that you will need pulseaudio-module-console-kit because > pulseaudio-server RDEPENDs on it (not on any pulseaudio-module-* but > pulseaudio-module-console-kit exactly). So it's not really mind reading.
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. > If it's not possible with current code-base then we should document it > and add some work around in pulseaudio (I'm fine with building > consolekit even when it's not used later). 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... As such I'd probably mark the bug report "LATER" and suggest working around this. If we were hitting this on many recipes, fine but we're not as far as I know. Cheers, Richard _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core