All of lore.kernel.org
 help / color / mirror / Atom feed
From: Gyorgy Sarvari <skandigraun@gmail.com>
To: git-patches@bmwtechworks.in, openembedded-devel@lists.openembedded.org
Cc: AshishKumar Mishra <ashishkumar.mishra@bmwtechworks.in>
Subject: Re: [oe] [meta-oe][PATCH v2] image_types_sparse: switch ext* conversion to ext2simg_android
Date: Mon, 23 Mar 2026 19:03:42 +0100	[thread overview]
Message-ID: <63363b44-df2a-4826-a72a-bc83732ad15b@gmail.com> (raw)
In-Reply-To: <20260323091500.1196198-1-git-patches@bmwtechworks.in>

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.
If they don't depend, then there is no need for them to be in the
dynamic layer folder, they can become standard ones.


> +# 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"



  reply	other threads:[~2026-03-23 18:03 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-23  9:15 [meta-oe][PATCH v2] image_types_sparse: switch ext* conversion to ext2simg_android Ashish Kumar Mishra
2026-03-23 18:03 ` Gyorgy Sarvari [this message]
     [not found] ` <189F8A77E50C1281.1003@lists.openembedded.org>
2026-03-23 19:09   ` [oe] " Gyorgy Sarvari
2026-03-24  5:40 ` Gyorgy Sarvari
2026-03-24  6:10   ` Ashish Mishra
2026-03-24 10:20     ` Ashish Mishra
2026-03-26  9:15       ` Ashish Mishra
2026-03-27  8:19         ` Ashish Mishra

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=63363b44-df2a-4826-a72a-bc83732ad15b@gmail.com \
    --to=skandigraun@gmail.com \
    --cc=ashishkumar.mishra@bmwtechworks.in \
    --cc=git-patches@bmwtechworks.in \
    --cc=openembedded-devel@lists.openembedded.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.