Re: [OE-core][PATCH] populate_sdk_ext: record METADATA_REVISION

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

On Wed, 2021-03-10 at 17:11 +0800, ChenQi wrote:
>  I think I've found the problem.
>  
>  """
>  commit 3ecf5d9692fec97b37af6a4e6c747a4e2c2ca292
>  Author: Richard Purdie <richard.purdie@linuxfoundation.org>
>  Date:   Sat Nov 21 16:16:40 2020 +0000
>  
>      uninative: Don't use single sstate for pseudo-native
>      
>      pseudo-native is a bit special. It conditionally compiles in support for
>      xattr, statx and statvfs amongst other options. If a pseudo-native binary is
>      used on a system where these functions are present but it wasn't compiled in
>      we see hard to debug permissions problems.
>  [snip]    
>  """
>  
>  This commit effectively says that the pseudo-native's sstate cache should not be shared among hosts with
> different distros, as it's appending ${ORIGLSBSTRING} to SSTATE_PKGARCH for pseudo-native.
>  
>  I'm not familiar with the pseudo's codes. But I'm wondering if it's possible for pseudo to always build in
> attr support and behave differently on different hosts/filesystems.
>  
>   
>  
>  Just checked the pseudo recipe. It seems that attr is always enabled.
>  DEPENDS = "sqlite3 attr"
>  PSEUDO_EXTRA_OPTS ?= "--enable-force-async --without-passwd-fallback --enable-epoll --enable-xattr"
>  
>  I think there should be no circumstances where the xattr support is not compiled in, yet the pseudo-native
> sstate cache is still reused. I'll send out a patch to revert the commit.

I was very reluctant to add that commit in the first place and from what 
I remember, it is a lot more tricky that just adding the right 
dependencies/configuration. I'd need to look at the code to remember
but there was code only being enabled on some distros and we'd have to
have it enabled in all cases even when headers and library functions
were not present.

Cheers,

Richard