Re: RDEPENDS_${PN} and virtclass-native

[Richard Purdie <richard.purdie@linuxfoundation.org>]

On Wed, 2011-05-25 at 18:01 +0100, Phil Blundell wrote:
> By way of displacement activity to avoid actually fixing my perl
> compilation problem, it occurred to me to investigate why perl was
> getting dragged into a micro-base-image build in the first place.  The
> culprit turns out to be imake, which does:
> 
> RDEPENDS_${PN} = "perl xproto"
> 
> and is then BBCLASSEXTENDed to imake-native (which in turn is pulled in
> by way of prelink-native and transfig-native).
> 
> Now, leaving aside the question of whether it is reasonable for prelink
> to be depending on transfig, it is clearly wrong for the -native version
> of imake to be depending on perl.  It seems that native.bbclass makes
> some effort to rewrite plain RDEPENDS to the -native version, but it
> doesn't apply the same tactics to RDEPENDS_${PN} or any such.  (And, in
> fact, rewriting plain RDEPENDS is probably futile since few if any
> recipes are going to be setting it.)
> 
> Obviously I can fix this by just setting RDEPENDS_virtclass-native in
> the recipe, and that's what I've done in my local tree.  But I wonder if
> a better solution would be for native.bbclass to be slightly more
> adventurous about rewriting these things for itself.

I think we need to fix native.bbclass. I dread to think what this is
doing to the dependency tree at present. We did remove most references
to RDEPENDS directly so I think that makes this a high priority to fix.

I'd note that the rewriting code is fraught with ordering/expansion
issues which is why that code plays games with the variables like it
does.

DEPENDS is horrible and it looks like we needed to do something similar
for RDEPENDS. Better solutions to the ordering problems would be very
welcome. It problem was the use of DEPENDS_prepend in places iirc.

Cheers,

Richard