the awkwardness of using core-image.bbclass

the awkwardness of using core-image.bbclass

[Robert P. J. Day]

  some observations/questions on core-image.bbclass, and whether it
can be used more understandably. this is being written from the
perspective of someone who has had the occasional student ask, "why
was it done *that* way?"

  so here's the important part of core-image.bbclass:

CORE_IMAGE_BASE_INSTALL = '\
    packagegroup-core-boot \
    packagegroup-base-extended \
    \
    ${CORE_IMAGE_EXTRA_INSTALL} \
    '

CORE_IMAGE_EXTRA_INSTALL ?= ""

IMAGE_INSTALL ?= "${CORE_IMAGE_BASE_INSTALL}"

inherit image

  whose job is obviously to define the final contents in IMAGE_INSTALL
to be handed off to image.bbclass. so far, so good. but notice first
that while IMAGE_INSTALL and CORE_IMAGE_EXTRA_INSTALL are weakly
assigned, CORE_IMAGE_BASE_INSTALL is *not*, which -- if one is
perusing that file -- strongly suggests that if you're inheriting
from this class file, you really should use that value. but it doesn't
work that way.

  first, here's (the relevant parts of) core-image-base.bb:

IMAGE_FEATURES += "splash"
inherit core-image

  that's perfect -- define an additional feature, then pull in
core-image to take care of the rest. perfectly understandable.

  core-image-minimal.bb is *not* so clean:

IMAGE_INSTALL = "packagegroup-core-boot ${ROOTFS_PKGMANAGE_BOOTSTRAP} ${CORE_IMAGE_EXTRA_INSTALL}"
inherit core-image

  i consider this recipe file potentially confusing since, although it
inherits core-image, it effectively stomps on the settings in there,
and just rams an overriding value into IMAGE_INSTALL. in short, rather
than "inheriting" cleanly from core-image and extending or enhancing
the recipe, core-image-mimimal simply kicks IMAGE_INSTALL out of the
way and sets its own final value.

  a final issue is, if you define a new core-image variation and
simply want to add some extra packages to it, what's the proper way to
do that? at first glance, i might have just created a new .bb file and
assigned some extra package names to CORE_IMAGE_EXTRA_INSTALL,
wouldn't that work? but the ref manual states quite clearly that you
are supposed to use that variable *only* in your local.conf file? any
reason for that?

  as i read it, the accepted way is to use:

IMAGE_INSTALL += "mtd-utils"

but is there some reason one can't use CORE_IMAGE_EXTRA_INSTALL from
within a recipe file? it seems like that would make recipe files
easier to read.

rday

-- 

========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                        http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================

Re: the awkwardness of using core-image.bbclass

[Rudolf Streif]

Hi Robert,



>   some observations/questions on core-image.bbclass, and whether it
> can be used more understandably. this is being written from the
> perspective of someone who has had the occasional student ask, "why
> was it done *that* way?"
>
>   so here's the important part of core-image.bbclass:
>
> CORE_IMAGE_BASE_INSTALL = '\
>     packagegroup-core-boot \
>     packagegroup-base-extended \
>     \
>     ${CORE_IMAGE_EXTRA_INSTALL} \
>     '
>
> CORE_IMAGE_EXTRA_INSTALL ?= ""
>
> IMAGE_INSTALL ?= "${CORE_IMAGE_BASE_INSTALL}"
>
> inherit image
>
>   whose job is obviously to define the final contents in IMAGE_INSTALL
> to be handed off to image.bbclass. so far, so good. but notice first
> that while IMAGE_INSTALL and CORE_IMAGE_EXTRA_INSTALL are weakly
> assigned, CORE_IMAGE_BASE_INSTALL is *not*, which -- if one is
> perusing that file -- strongly suggests that if you're inheriting
> from this class file, you really should use that value. but it doesn't
> work that way.
>
> Consider CORE_IMAGE_BASE_INSTALL as a default value for IMAGE_INSTALL.
It's internal to the core-image class only. Hence, it makes sense for it to
be directly assigned. It is not meant to be used by any other classes or
recipes. With the default value the most simple recipe you can write to use
the core-image class is:

myimage.bb:
   inherit core-image

which will produce an image that boots to the console and include hardware
support if so defined by machine and distro features.

IMAGE_INSTALL and CORE_IMAGE_EXTRA_INSTALL are meant to be overwritten by
image recipes and configuration files.



>   first, here's (the relevant parts of) core-image-base.bb:
>
> IMAGE_FEATURES += "splash"
> inherit core-image
>
>   that's perfect -- define an additional feature, then pull in
> core-image to take care of the rest. perfectly understandable.
>
>   core-image-minimal.bb is *not* so clean:
>
> IMAGE_INSTALL = "packagegroup-core-boot ${ROOTFS_PKGMANAGE_BOOTSTRAP}
> ${CORE_IMAGE_EXTRA_INSTALL}"
> inherit core-image
>
>   i consider this recipe file potentially confusing since, although it
> inherits core-image, it effectively stomps on the settings in there,
> and just rams an overriding value into IMAGE_INSTALL. in short, rather
> than "inheriting" cleanly from core-image and extending or enhancing
> the recipe, core-image-mimimal simply kicks IMAGE_INSTALL out of the
> way and sets its own final value.
>
> While it may add some confusing it actually illustrates that you can use
the core-image class in two different ways. You can rely on the default
values for IMAGE_INSTALL and add to it in your recipe:

myimage.bb
   IMAGE_INSTALL += "mtd-utils"
   IMAGE_FEATURES += "splash"

I would use IMAGE_FEATURES over IMAGE_INSTALL whenever an image feature
already provides what I am looking for.

The other way is that you can use core-image and not rely on the default
values but set IMAGE_INSTALL directly which is what core-image-minimal.bb
does. Could you write core-image-minimal.bb differently so that it uses the
default values from the core-image class? Sure.



>   a final issue is, if you define a new core-image variation and
> simply want to add some extra packages to it, what's the proper way to
> do that? at first glance, i might have just created a new .bb file and
> assigned some extra package names to CORE_IMAGE_EXTRA_INSTALL,
> wouldn't that work? but the ref manual states quite clearly that you
> are supposed to use that variable *only* in your local.conf file? any
> reason for that?
>

Yes, CORE_IMAGE_EXTRA_INSTALL fulfills a similar role in conf/local.conf as
EXTRA_IMAGE_FEATURES: you can safely assign to them in conf/local.conf
without worrying that you are overwriting preassigned values from an image
recipe.


>
>   as i read it, the accepted way is to use:
>
> IMAGE_INSTALL += "mtd-utils"
>
> but is there some reason one can't use CORE_IMAGE_EXTRA_INSTALL from
> within a recipe file? it seems like that would make recipe files
> easier to read.
>

I have the same recommendation as the manual has. If you want to have clean
image recipes use in your image recipes:

IMAGE_INSTALL += "...."
IMAGE_FEATURES += "...."

if you want to rely on the default values, or

IMAGE_INSTALL = "...."
IMAGE_FEATURES = "...."

if you do not want to be at the mercy of the default values.

And in conf/local.conf use

EXTRA_IMAGE_FEATURES = "...."
CORE_IMAGE_EXTRA_INSTALL = "...."

to add to it.

:rjs

Re: the awkwardness of using core-image.bbclass

[Robert P. J. Day]

On Fri, 11 Jul 2014, Rudolf Streif wrote:

> Hi Robert,
>
>
>
> >   some observations/questions on core-image.bbclass, and whether it
> > can be used more understandably. this is being written from the
> > perspective of someone who has had the occasional student ask, "why
> > was it done *that* way?"
> >
> >   so here's the important part of core-image.bbclass:
> >
> > CORE_IMAGE_BASE_INSTALL = '\
> >     packagegroup-core-boot \
> >     packagegroup-base-extended \
> >     \
> >     ${CORE_IMAGE_EXTRA_INSTALL} \
> >     '
> >
> > CORE_IMAGE_EXTRA_INSTALL ?= ""
> >
> > IMAGE_INSTALL ?= "${CORE_IMAGE_BASE_INSTALL}"
> >
> > inherit image
> >
> >   whose job is obviously to define the final contents in IMAGE_INSTALL
> > to be handed off to image.bbclass. so far, so good. but notice first
> > that while IMAGE_INSTALL and CORE_IMAGE_EXTRA_INSTALL are weakly
> > assigned, CORE_IMAGE_BASE_INSTALL is *not*, which -- if one is
> > perusing that file -- strongly suggests that if you're inheriting
> > from this class file, you really should use that value. but it doesn't
> > work that way.
> >
> > Consider CORE_IMAGE_BASE_INSTALL as a default value for IMAGE_INSTALL.
> It's internal to the core-image class only. Hence, it makes sense for it to
> be directly assigned. It is not meant to be used by any other classes or
> recipes. With the default value the most simple recipe you can write to use
> the core-image class is:
>
> myimage.bb:
>    inherit core-image
>
> which will produce an image that boots to the console and include
> hardware support if so defined by machine and distro features.
>
> IMAGE_INSTALL and CORE_IMAGE_EXTRA_INSTALL are meant to be
> overwritten by image recipes and configuration files.

  i know, which is exactly what is so counter-intuitive with the way
the above is done. you can override those two variables, but not
CORE_IMAGE_BASE_INSTALL directly, it just seems silly.

rday

-- 

========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                        http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================

Re: the awkwardness of using core-image.bbclass

[Khem Raj]

>   i know, which is exactly what is so counter-intuitive with the way
> the above is done. you can override those two variables, but not
> CORE_IMAGE_BASE_INSTALL directly, it just seems silly.

why do you want CORE_IMAGE_BASE_INSTALL to be overridable ? unless you
want to construct image of your own
completely from scratch but then why would you want to inherit
properties from core-image class.

Re: the awkwardness of using core-image.bbclass

[Robert P. J. Day]

On Fri, 11 Jul 2014, Khem Raj wrote:

> >   i know, which is exactly what is so counter-intuitive with the way
> > the above is done. you can override those two variables, but not
> > CORE_IMAGE_BASE_INSTALL directly, it just seems silly.
>
> why do you want CORE_IMAGE_BASE_INSTALL to be overridable ? unless
> you want to construct image of your own completely from scratch but
> then why would you want to inherit properties from core-image class.

  one last post on this, then i'll move on -- i didn't want this to
become so involved.

  quite simply, even if you inherit from core-image, the setting of
CORE_IMAGE_BASE_INSTALL *is* overridable -- it's simply overridable in
a disgusting, grotesque, non-intuitive and incomprehensible way.

  i'm happy to leave core-image.bbclass the way it is, and i'll admit
that it works just fine as long as you recognize the crippled way it's
implemented. any base class that requires horrid code like this in an
inheriting class:

IMAGE_INSTALL = "packagegroup-core-boot ${ROOTFS_PKGMANAGE_BOOTSTRAP} ${CORE_IMAGE_EXTRA_INSTALL}"
inherit core-image

to allegedly *inherit* from core-image but still mangle the allegedly
really, really important value of CORE_IMAGE_BASE_INSTALL is just ...
wrong.

  so, i'm happy to leave things the way they are, knowing that in my
future OE/yocto courses, i will continue to introduce the section on
core images with the lead-in, "you're not going to *believe* what they
did here", after which students will, as always, be wiping their eyes
from laughter.

  and as forrest gump once said, "and that's all i have to say about
that."  carry on.

rday

-- 

========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                        http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================

Re: the awkwardness of using core-image.bbclass

[Paul Eggleton]

Hi Robert,

On Friday 11 July 2014 12:51:54 Robert P. J. Day wrote:
>   some observations/questions on core-image.bbclass, and whether it
> can be used more understandably. this is being written from the
> perspective of someone who has had the occasional student ask, "why
> was it done *that* way?"
> 
>   so here's the important part of core-image.bbclass:
> 
> CORE_IMAGE_BASE_INSTALL = '\
>     packagegroup-core-boot \
>     packagegroup-base-extended \
>     \
>     ${CORE_IMAGE_EXTRA_INSTALL} \
>     '
> 
> CORE_IMAGE_EXTRA_INSTALL ?= ""
> 
> IMAGE_INSTALL ?= "${CORE_IMAGE_BASE_INSTALL}"
> 
> inherit image
> 
>   whose job is obviously to define the final contents in IMAGE_INSTALL
> to be handed off to image.bbclass. so far, so good. but notice first
> that while IMAGE_INSTALL and CORE_IMAGE_EXTRA_INSTALL are weakly
> assigned, CORE_IMAGE_BASE_INSTALL is *not*, which -- if one is
> perusing that file -- strongly suggests that if you're inheriting
> from this class file, you really should use that value. but it doesn't
> work that way.
> 
>   first, here's (the relevant parts of) core-image-base.bb:
> 
> IMAGE_FEATURES += "splash"
> inherit core-image
> 
>   that's perfect -- define an additional feature, then pull in
> core-image to take care of the rest. perfectly understandable.
> 
>   core-image-minimal.bb is *not* so clean:
> 
> IMAGE_INSTALL = "packagegroup-core-boot ${ROOTFS_PKGMANAGE_BOOTSTRAP}
> ${CORE_IMAGE_EXTRA_INSTALL}"
> inherit core-image
> 
>   i consider this recipe file potentially confusing since, although it
> inherits core-image, it effectively stomps on the settings in there,
> and just rams an overriding value into IMAGE_INSTALL. in short, rather
> than "inheriting" cleanly from core-image and extending or enhancing
> the recipe, core-image-mimimal simply kicks IMAGE_INSTALL out of the
> way and sets its own final value.

As core-image.bbclass currently works, it core-image-minimal must do this; 
otherwise you'll get packagegroup-base-extended in the image and the name 
"minimal" won't be true anymore. If on the other hand you inherit image 
instead of core-image then you won't be able to use the IMAGE_FEATURES 
definitions that core-image.bbclass defines.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre