Re: [PATCH] sstate: Ensure PACKAGE_EXTRA_ARCHS are part of SSTATE_ARCHS

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

On Wed, 2017-04-19 at 15:17 -0700, Saul Wold wrote:
> Since BSPs also define package archs that are included in
> PACKAGE_EXTRA_ARCHS
> we should also enure they are accounted for in SSTATE_ARCH.
> 
> This helps with the license manifest issue in some cases.
> 
> Signed-off-by: Saul Wold <sgw@linux.intel.com>
> ---
>  meta/classes/sstate.bbclass | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/meta/classes/sstate.bbclass
> b/meta/classes/sstate.bbclass
> index e50a385..614c3a0 100644
> --- a/meta/classes/sstate.bbclass
> +++ b/meta/classes/sstate.bbclass
> @@ -45,6 +45,7 @@ SSTATE_ARCHS = " \
>      ${SDK_ARCH}_${PACKAGE_ARCH} \
>      allarch \
>      ${PACKAGE_ARCH} \
> +    ${PACKAGE_EXTRA_ARCHS} \
>      ${MACHINE}"
>  
>  SSTATE_MANMACH ?= "${SSTATE_PKGARCH}"

You really need to explain more about the problem this is solving. I'm
nervous of this change as it has the potential to complicate
multimachine builds and hide real issues.

For example, currently if you build an armv5 and an armv7 machine, the
files will be left alone for both. After this change, building the
armv7 machine will cause the armv5 files to be removed as they are not
"reachable" from the v7 build but are listed as an extra package arch.
At that point we may as well go though all index files and remove
anything which isn't reachable by the current configured machine.

It actually gets worse with multiconfig as with this change building an
armv7 and armv5 machine would fail.

If you're solving a package feed issue, the answer might be to limit
the package feeds only to currently builable package architectures. I'm
not sure what license issue you're addressing here though so I can't
really help give pointers on what to do here...

Cheers,

Richard