From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: Alejandro Enedino Hernandez Samaniego <alejandro@enedino.org>
Cc: OE-core <openembedded-core@lists.openembedded.org>
Subject: Re: [OE-core] [PATCH] baremetal-image.bbclass: avoid inheriting incompatible IMAGE_CLASSES
Date: Fri, 02 Sep 2022 16:02:05 +0100 [thread overview]
Message-ID: <3da5db97fad9def2316542749953f960f2fcdb23.camel@linuxfoundation.org> (raw)
In-Reply-To: <CAHMutrbiWa0ezWeuH8mV9ZhGLqvAPVxpuEh1-JhCWEkks5OFxw@mail.gmail.com>
On Fri, 2022-09-02 at 09:53 -0500, Alejandro Enedino Hernandez
Samaniego wrote:
>
>
> On Fri, Sep 2, 2022, 9:47 AM Richard Purdie
> <richard.purdie@linuxfoundation.org> wrote:
> > On Thu, 2022-09-01 at 17:42 -0600, Alejandro Hernandez Samaniego
> > wrote:
> > > There could be IMAGE_CLASSES designed to work on images which
> > > arent
> > > necessarily compatible with baremetal-images, one example is the
> > > license_image class which relies on the package managers
> > > functionality
> > > during do_rootfs, for baremetal images no rootfs is created hence
> > > the
> > > package manager shouldnt be invoked, we need to avoid inheriting
> > > such
> > > class to fix this behavior.
> > >
> > > inherit BAREMETAL_IMAGE_CLASSES for baremetal images but set the
> > > default
> > > to IMAGE_CLASSES, whilst removing undesired classes in an
> > > intermediate
> > > step to avoid incompatibilities.
> > >
> > > Signed-off-by: Alejandro Enedino Hernandez Samaniego
> > > <alejandro@enedino.org>
> > > ---
> > > meta/classes-recipe/baremetal-image.bbclass | 9 ++++++++-
> > > 1 file changed, 8 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/meta/classes-recipe/baremetal-image.bbclass
> > > b/meta/classes-recipe/baremetal-image.bbclass
> > > index d3377a92fa..2f07dec4ac 100644
> > > --- a/meta/classes-recipe/baremetal-image.bbclass
> > > +++ b/meta/classes-recipe/baremetal-image.bbclass
> > > @@ -18,8 +18,15 @@
> > > ## Emulate image.bbclass
> > > # Handle inherits of any of the image classes we need
> > > IMAGE_CLASSES ??= ""
> > > -IMGCLASSES = " ${IMAGE_CLASSES}"
> > > +BAREMETAL_IMAGE_CLASSES ?= " ${IMAGE_CLASSES}"
> > > +
> > > +# The license_image class relies on package managers used on
> > > do_rootfs
> > > +# these dont exist for baremetal images since no rootfs is
> > > created.
> > > +BAREMETAL_IMAGE_CLASSES:remove = "license_image"
> > > +
> > > +IMGCLASSES = " ${BAREMETAL_IMAGE_CLASSES}"
> > > inherit ${IMGCLASSES}
> > > +
> > > # Set defaults to satisfy IMAGE_FEATURES check
> > > IMAGE_FEATURES ?= ""
> > > IMAGE_FEATURES[type] = "list"
> >
> > This is going to become a usability nightmare. Can we patch
> > license_image to just silently do nothing for baremetal?
>
> I think we can, but we'd have to do that on every class that is
> incompatible (I don't expect many to be, but I tried to generate a
> more generic solution and use BAREMETAL_, IMAGE_CLASSES as a gate),
> with that in mind, Is that still better than this?
I think we do need to fixes the classes which don't work. The
alternative is users having two lists of image classes which defeats
much of what the variable was trying to do. We may as well just give up
on IMAGE_CLASSES for baremetal and require it's own list which will be
a pain for users.
Cheers,
Richard
prev parent reply other threads:[~2022-09-02 15:02 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-01 23:42 [PATCH] baremetal-image.bbclass: avoid inheriting incompatible IMAGE_CLASSES Alejandro Enedino Hernandez Samaniego
2022-09-02 14:47 ` [OE-core] " Richard Purdie
2022-09-02 14:53 ` Alejandro Enedino Hernandez Samaniego
2022-09-02 15:02 ` Richard Purdie [this message]
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=3da5db97fad9def2316542749953f960f2fcdb23.camel@linuxfoundation.org \
--to=richard.purdie@linuxfoundation.org \
--cc=alejandro@enedino.org \
--cc=openembedded-core@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox