Re: [oe] [meta-oe][PATCH v2] image_types_sparse: switch ext* conversion to ext2simg_android

[Gyorgy Sarvari <skandigraun@gmail.com>]

Sorry for the spam... Looked a bit further, and want to share a few more
thoughts.

On 3/23/26 19:03, Gyorgy Sarvari via lists.openembedded.org wrote:
> On 3/23/26 10:15, Ashish Kumar Mishra via lists.openembedded.org wrote:
> 
> ...SNIP...
> 
>> diff --git a/meta-oe/conf/layer.conf b/meta-oe/conf/layer.conf
>> index 186ff9a488..b7ab46f12b 100644
>> --- a/meta-oe/conf/layer.conf
>> +++ b/meta-oe/conf/layer.conf
>> @@ -12,8 +12,16 @@
>>  BBPATH .= ":${LAYERDIR}"
>>  
>>  # We have a recipes directory, add to BBFILES
>> -BBFILES += "${LAYERDIR}/recipes-*/*/*.bb ${LAYERDIR}/recipes-*/*/*.bbappend"
>> +# Adding dynamic layers recipes
>> +BBFILES += "\
>> +    ${LAYERDIR}/recipes-*/*/*.bb \
>> +    ${LAYERDIR}/recipes-*/*/*.bbappend \
>> +    ${LAYERDIR}/dynamic-layers/selinux/recipes-*/*/*.bb \
>> +    ${LAYERDIR}/dynamic-layers/selinux/recipes-*/*/*.bbappend \
>> +"
>>  
> 
> Sorry for not asking earlier... but why is this done actually? Only to
> make it available without meta-selinux aswell? If so, then I think
> instead the recipes (or a part of them maybe?) should be moved to the
> main meta-oe folder. Changing BBFILES like this kind of defeats the
> purpose of dynamic-layers.
> 
> Thinking a bit loudly, assuming that the above guess is correct about
> the reason:
> Question is, why do these recipes depend on meta-selinux? Do they really
> depend? This is a question, not a challenge, I'm not that familiar with
> these particular recipe. If they really do depend, then making this
> BBFILES extension will cause broken recipes in the layer, possibly it
> will fail.


Since I'm sending this message anyway, I might even finish this sentence
that I left here half baked: "...possibly it will fail yocto
compatibility check."


> If they don't depend, then there is no need for them to be in the
> dynamic layer folder, they can become standard ones.
> 


FWIW I just ran two tests. First I dropped the old android-tools recipe
from meta-oe, and just copied the android-tools folder from
dynamic-layers to the main layer.

1. I removed the libselinux dependency of android-tools recipe, and
built it without meta-selinux present
2. I left the recipe with the original libselinux dependency, and added
meta-selinux to my build (along with the DISTRO_FEATURES that are
described in the readme).

Both builds produced bit-identical artifacts, for both class-native and
class-target. When I ran a "grep -ri selinux" in all produced artifacts,
the only thing came up was some includes in the -src package, guarded by
"#ifdef __ANDROID__".
Makes me really wonder if the android-tools recipe still depends on
meta-selinux, or it is just a remnant from an old version of the recipe.

If there is still some partial runtime-dependency on the meta-selinux
layer that remains hidden from me, possibly that could be solved with a
PACKAGECONFIG and/or bbappend in the dynamic-layers folder?


> 
>> +# Prefer android-tools from selinux dynamic layer (29.0.6) over the older version (5.1.1)
>> +PREFERRED_VERSION:pn-android-tools = "29.0.6.r14%"
> 
> PREFERRED_VERSION should use weak assignment (?= or ??=), otherwise it
> may shadow other user-preference. Alternatively, maybe you could check
> the version/avalability of ext2simg_android in image_type_sparse
> bbclass, and complain hard if it's wrong? That would put the version
> selection on the user's shoulder. (Just an idea, no need to like it)
> 
> 
>>  BBFILE_COLLECTIONS += "openembedded-layer"
>>  BBFILE_PATTERN_openembedded-layer := "^${LAYERDIR}/"
>>  
>> diff --git a/meta-oe/dynamic-layers/selinux/recipes-devtool/android-tools/android-tools_29.0.6.r14.bb b/meta-oe/dynamic-layers/selinux/recipes-devtool/android-tools/android-tools_29.0.6.r14.bb
>> index 74928ed171..39b8ef5fe8 100644
>> --- a/meta-oe/dynamic-layers/selinux/recipes-devtool/android-tools/android-tools_29.0.6.r14.bb
>> +++ b/meta-oe/dynamic-layers/selinux/recipes-devtool/android-tools/android-tools_29.0.6.r14.bb
>> @@ -166,6 +166,37 @@ do_install() {
>>          install -d ${D}${bindir}
>>          install -m0755 ${B}/mkbootimg/mkbootimg ${D}${bindir}
>>      fi
>> +
>> +    # e2fsprogs expecting headers in sparse/ subdirectory
>> +    # to resolve the "Multiple shlib providers" conflict.
>> +    rm -f ${D}${libdir}/android/libsparse.so*
>> +    rm -f ${D}${libdir}/android/libbase.so*
>> +    rm -f ${D}${libdir}/android/liblog.so*
>> +
>> +    if [ -d "${S}/system/core/libsparse/include/sparse" ]; then
>> +        install -d ${D}${includedir}/sparse
>> +        cp -r ${S}/system/core/libsparse/include/sparse/* ${D}${includedir}/sparse/
>> +    else
>> +        bberror "Sparse headers not found in ${S}/system/core/libsparse/include/sparse"
>> +    fi
>> +
>> +    install -d ${D}${libdir}
>> +    for lib in libsparse libbase liblog; do
>> +        if [ -f "${S}/debian/out/system/core/${lib}.so" ]; then
>> +            bbwarn "Installing ${lib} to sysroot"
> 
> 
> One bbwarn escaped here.
> 
> 
>> +            install -m 0755 ${S}/debian/out/system/core/${lib}.so ${D}${libdir}/${lib}.so.0
>> +            ln -sf ${lib}.so.0 ${D}${libdir}/${lib}.so
>> +        fi
>> +    done
>> +
>> +    install -d ${D}${libdir}/android
>> +    for lib in libsparse libbase liblog; do
>> +        if [ -f "${D}${libdir}/${lib}.so.0" ]; then
>> +            ln -sf ../${lib}.so.0 ${D}${libdir}/android/${lib}.so.0
>> +            ln -sf ../${lib}.so ${D}${libdir}/android/${lib}.so
>> +        fi
>> +    done
>> +
>>  }
>>  
>>  PACKAGES =+ "${PN}-fstools ${PN}-adbd"
> 
> 
> 
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#125524): https://lists.openembedded.org/g/openembedded-devel/message/125524
> Mute This Topic: https://lists.openembedded.org/mt/118461929/6084445
> Group Owner: openembedded-devel+owner@lists.openembedded.org
> Unsubscribe: https://lists.openembedded.org/g/openembedded-devel/unsub [skandigraun@gmail.com]
> -=-=-=-=-=-=-=-=-=-=-=-
>