[poky] Problems adding native support packages

[Tian, Kevin]

> From: Gary Thomas [mailto:gary at mlbassoc.com]
> Sent: Friday, March 11, 2011 8:14 PM
> 
> On 03/11/2011 04:19 AM, Gary Thomas wrote:
> > On 03/10/2011 09:57 PM, Tian, Kevin wrote:
> >>> From: Gary Thomas
> >>> Sent: Friday, March 11, 2011 11:29 AM
> >>>
> >>> I'm trying to import a native package from OE for which the
> >>> main package depends on libiconv. This seems to imply that
> >>> when I extend to the native package using BBCLASSEXTEND, the
> >>> native package depends on virtual/libiconv-native
> >>>
> >>> I can't figure out how to provide this. Any clues?
> >>
> >> I'm not sure about the problem here. do you want virtual/libiconv-native
> dependency
> >> or not? If target recipe already has a DEPENDS = "libiconv", then with
> BBCLASSEXTEND
> >> you have libiconv-native automatically.
> >>
> >> Or if you only want to add libiconv-native for native recipe exclusively, then:
> >>
> >> DEPENDS_virtclass-native = "virtual/libiconv-native"
> >
> > Actually, the problem is that such a dependency was added automatically by
> BBCLASSEXTEND.
> > virtual/libiconv is provided by eglibc package, but it's not clear if it can provide
> > virtual/libiconv-native
> 
> It comes from this dependency which seems very hard to satisfy:
>    meta/recipes-graphics/pango/pango.inc:DEPENDS = "glib-2.0 fontconfig
> freetype zlib virtual/libiconv virtual/libx11 libxft gtk-doc-native cairo"
> 
> It looks like I can side-step this by adding
>    ASSUME_PROVIDED += " virtual/libiconv-native "
> 

the other alternative is to use DEPENDS_virtclass-native to list all dependencies 
you think the native recipe requires instead of implicitly sharing same DEPENDS
from target recipe.

Thanks
Kevin