[yocto] sstate black hole?

Paul Eggleton paul.eggleton at linux.intel.com
Tue Jun 16 01:37:50 PDT 2015


On Monday 15 June 2015 18:19:21 Gary Thomas wrote:
> I followed this down to an i.MX6 specific package which is
> in DEPENDS:
>    Variable PROVIDES value changed from
>    '${PN}  virtual/wayland-egl virtual/libgal-x11 virtual/egl
> virtual/libopenvg virtual/libg2d virtual/libgl virtual/libgles1
> virtual/libgles2' to
>    '${PN}  virtual/wayland-egl virtual/libgal-x11 virtual/egl
> virtual/libopenvg virtual/libg2d virtual/libgl virtual/libgles1
> virtual/libgles2 virtual/libgl virtual/libgles1 virtual/libgles2'
> 
> Why aren't these considered the same (duplicate elements and/or order)
> should not matter for PROVIDES.  Is there some way we could get bitbake
> to collapse this and remove the duplicates?
> 
> I found that this happens in
> meta-fsl-arm:recipes-graphics/imx-gpu-viv/imx-gpu-viv.inc which contains
> these lines:
>    PROVIDES += "virtual/wayland-egl virtual/libgal-x11 virtual/egl
> virtual/libopenvg virtual/libg2d" 
> PROVIDES_append_mx6q  = " virtual/libgl virtual/libgles1 virtual/libgles2"
> PROVIDES_append_mx6dl  = " virtual/libgl virtual/libgles1 virtual/libgles2"
> PROVIDES_append_mx6sx  = " virtual/libgl virtual/libgles1 virtual/libgles2"
> 
> Some i.MX6 targets, nitrogen6x in particular, has overrides for both mx6q
> and mx6dl, hence the duplication.
> 
> Note: I removed the extra override (for testing) and found that
> now the packages built by target A can be shared via sstate with
> target B (at least the few I tested)

I agree this would be nice, but for this to work we'd probably need to 
introduce a typing system within bitbake so that it can understand that this 
variable is a space-separated list. That is something we will probably do at 
some point for a variety of reasons, but I don't know that it's something we 
will get to soon.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre



More information about the yocto mailing list