[OE-core] RDEPENDS of packages created by PACKAGES_DYNAMIC not built before image rootfs

Richard Purdie richard.purdie at linuxfoundation.org
Wed Nov 28 05:35:20 UTC 2012


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





More information about the Openembedded-core mailing list