defining FEATURE_PACKAGES_* in core-image.bbclass vs image.bbclass

defining FEATURE_PACKAGES_* in core-image.bbclass vs image.bbclass

[Robert P. J. Day]

  i was perusing core-image.bbclass and noticed that the alleged list
of "Available IMAGE_FEATURES" didn't mention "splash" so i was going
to submit a simple patch to add a line for it, before i noticed
something that puzzled me.

  i know there are some features that don't correspond to packagegroup
names, and here's one from core-image.bbclass:

FEATURE_PACKAGES_hwcodecs = "${MACHINE_HWCODECS}"

so that feature is clearly a "core image" feature. (i know the
meta-intel layer uses this feature.)

  then i noticed that the "splash" feature is defined, not in
core-image.bbclass, but in the more basic image.bbclass, as is
package-management:

FEATURE_PACKAGES_package-management = "${ROOTFS_PKGMANAGE}"
SPLASH ?= "psplash"
FEATURE_PACKAGES_splash = "${SPLASH}"

  so is there some rationale for deciding which FEATURE_PACKAGES
settings are defined in core-image, while others are defined in
image?

  i'll still add a line for splash to core-image.bbclass.

rday

-- 

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

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

Re: defining FEATURE_PACKAGES_* in core-image.bbclass vs image.bbclass

[Rudolf Streif]

>
>
>   then i noticed that the "splash" feature is defined, not in
> core-image.bbclass, but in the more basic image.bbclass, as is
> package-management:
>
> FEATURE_PACKAGES_package-management = "${ROOTFS_PKGMANAGE}"
> SPLASH ?= "psplash"
> FEATURE_PACKAGES_splash = "${SPLASH}"
>
> And then there is debug-tweaks for which the hooks are defined in
image.bbclass including the function zap_empty_root_password but the
post-processing is added to the variable by core-image.bbclass:

core-image.bbclass: ROOTFS_POSTPROCESS_COMMAND +=
'${@bb.utils.contains("IMAGE_FEATURES", "debug-tweaks", "",
"zap_empty_root_password ; ",d)}'

Since image.bbclass also adds the debug-tweaks to the valid image feature
list

image.bbclass:IMAGE_FEATURES[validitems] += "debug-tweaks read-only-rootfs"

my inclination would be to move the addition to ROOTFS_POSTPROCESS_COMMAND
from core-image.bbclass to image.bbclass.

The image feature readonly-rootfs is also added to the valid list by
image.bbclass.

Consequently this makes the image features splash, debug-tweaks,
package-management, splash and readonly-rootfs available to image recipes
that inherit image.bbclass while h/w codecs and others are added by
core-image.bbclass and are only available when an image recipe inherits
core-image.

Then there are the image features dbg-pkgs, dev-pkgs, doc-pkgs,
staticdev-pkgs and ptest-pkgs which are added to the image feature list by
populate_sdk_base.bbclass which image.bbclass inherits and hence they are
available to all images.


>   so is there some rationale for deciding which FEATURE_PACKAGES
> settings are defined in core-image, while others are defined in
> image?
>

That I do not really know. However, to some extend the choices as to what
class adds what image features make sense, alth

   - The minimal set of features splash, debug-tweaks, package-management,
   splash and readonly-rootfs to be added by the basic image.bbclass.
   - Extended image features added by core-image.bbclass.
   - SDK related image features by the populate_sdk_base.bbclass.

My $0.02

Cheers,
:rjs

Re: defining FEATURE_PACKAGES_* in core-image.bbclass vs image.bbclass

[Robert P. J. Day]

On Mon, 14 Jul 2014, Rudolf Streif wrote:

> >   then i noticed that the "splash" feature is defined, not in
> > core-image.bbclass, but in the more basic image.bbclass, as is
> > package-management:
> >
> > FEATURE_PACKAGES_package-management = "${ROOTFS_PKGMANAGE}"
> > SPLASH ?= "psplash"
> > FEATURE_PACKAGES_splash = "${SPLASH}"
> >
> > And then there is debug-tweaks for which the hooks are defined in
> image.bbclass including the function zap_empty_root_password but the
> post-processing is added to the variable by core-image.bbclass:
>
> core-image.bbclass: ROOTFS_POSTPROCESS_COMMAND +=
> '${@bb.utils.contains("IMAGE_FEATURES", "debug-tweaks", "",
> "zap_empty_root_password ; ",d)}'
>
> Since image.bbclass also adds the debug-tweaks to the valid image
> feature list
>
> image.bbclass:IMAGE_FEATURES[validitems] += "debug-tweaks read-only-rootfs"
>
> my inclination would be to move the addition to ROOTFS_POSTPROCESS_COMMAND
> from core-image.bbclass to image.bbclass.
>
> The image feature readonly-rootfs is also added to the valid list by
> image.bbclass.

  i didn't notice the rest of these as i stopped looking after the
splash example and thought i'd ask about it.

> Consequently this makes the image features splash, debug-tweaks,
> package-management, splash and readonly-rootfs available to image
> recipes that inherit image.bbclass while h/w codecs and others are
> added by core-image.bbclass and are only available when an image
> recipe inherits core-image.

  is there something special about hwcodecs that suggests it should
stay in core-image rather than moving to image as well? i'm just
trying to understand the rationale.

rday

-- 

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

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

Re: defining FEATURE_PACKAGES_* in core-image.bbclass vs image.bbclass

[Rudolf Streif]

>
>
>   is there something special about hwcodecs that suggests it should
> stay in core-image rather than moving to image as well? i'm just
> trying to understand the rationale.
>
>
Not necessarily. But I would consider them extended features and they
belong into core-image in my opinion. Not all embedded systems need them.
Many don't have video or audio support. I would even suggest to move splash
to core-image. If a device does not have video there is not reason for a
splash screen.

I consider debug-tweaks, package-management, and readonly-rootfs the basic
image features to be in image.

:rjs

Re: defining FEATURE_PACKAGES_* in core-image.bbclass vs image.bbclass

[Robert P. J. Day]

On Mon, 14 Jul 2014, Rudolf Streif wrote:

> >   is there something special about hwcodecs that suggests it
> > should stay in core-image rather than moving to image as well? i'm
> > just trying to understand the rationale.
> >
> Not necessarily. But I would consider them extended features and
> they belong into core-image in my opinion. Not all embedded systems
> need them. Many don't have video or audio support. I would even
> suggest to move splash to core-image. If a device does not have
> video there is not reason for a splash screen.
>
> I consider debug-tweaks, package-management, and readonly-rootfs the
> basic image features to be in image.

  and i have no problem with that rationale. :-)

rday

-- 

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

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

Re: defining FEATURE_PACKAGES_* in core-image.bbclass vs image.bbclass

[Robert P. J. Day]

On Mon, 14 Jul 2014, Rudolf Streif wrote:

> >
> >
> >   then i noticed that the "splash" feature is defined, not in
> > core-image.bbclass, but in the more basic image.bbclass, as is
> > package-management:
> >
> > FEATURE_PACKAGES_package-management = "${ROOTFS_PKGMANAGE}"
> > SPLASH ?= "psplash"
> > FEATURE_PACKAGES_splash = "${SPLASH}"
> >
> > And then there is debug-tweaks for which the hooks are defined in
> image.bbclass including the function zap_empty_root_password but the
> post-processing is added to the variable by core-image.bbclass:
>
> core-image.bbclass: ROOTFS_POSTPROCESS_COMMAND +=
> '${@bb.utils.contains("IMAGE_FEATURES", "debug-tweaks", "",
> "zap_empty_root_password ; ",d)}'
>
> Since image.bbclass also adds the debug-tweaks to the valid image feature
> list
>
> image.bbclass:IMAGE_FEATURES[validitems] += "debug-tweaks read-only-rootfs"

  ... snip ...

  there's something i'll throw in here now that i'm thinking about it.
i've wondered about that very line above -- what is its purpose?

  as i read it, the primary purpose for the variable IMAGE_FEATURES is
to define packagegroups through the use of FEATURE_PACKAGES_* that you
see in core-image.bbclass. (so this is again a bit of weirdness where
code in image.bbclass refers up the "inheritance tree" to stuff found
in core-image.bbclass.)

  however, there are of course some IMAGE_FEATURES that don't
correspond directly to package groups; eg, package-management,
debug-tweaks, read-only-rootfs. so why is "package-management" not
listed in the line:

image.bbclass:IMAGE_FEATURES[validitems] += "debug-tweaks read-only-rootfs"

is that variable flag supposed to list all valid, non-packagegroup
IMAGE_FEATURES?

  i can see that debug-tweaks is processed explicitly in
image.bbclass:

ROOTFS_POSTPROCESS_COMMAND += '${@bb.utils.contains("IMAGE_FEATURES", "debug-tweaks", "ssh_allow_empty_password; ", "",d)}'
ROOTFS_POSTPROCESS_COMMAND += '${@bb.utils.contains("IMAGE_FEATURES", "debug-tweaks", "postinst_enable_logging; ", "",d)}'

  but, then again, so is package-management:

ROOTFS_BOOTSTRAP_INSTALL = "${@bb.utils.contains("IMAGE_FEATURES", "package-management", "", "${ROOTFS_PKGMANAGE_BOOTSTRAP}",d)}"

  so why is debug-tweaks assigned to IMAGE_FEATURES[validitems] but
not package-management? oh, wait, i just noticed that image.bbclass
explicitly does this:

FEATURE_PACKAGES_package-management = "${ROOTFS_PKGMANAGE}"

so that package-management *will* be recognized as a valid image
feature here in image.bbclass:

def check_image_features(d):
    valid_features = (d.getVarFlag('IMAGE_FEATURES', 'validitems', True) or "").split()
    valid_features += d.getVarFlags('COMPLEMENTARY_GLOB').keys()
    for var in d:
       if var.startswith("PACKAGE_GROUP_"):
           bb.warn("PACKAGE_GROUP is deprecated, please use FEATURE_PACKAGES instead")
           valid_features.append(var[14:])
       elif var.startswith("FEATURE_PACKAGES_"):
           valid_features.append(var[17:])
    valid_features.sort()

  gaaaaaaaaah! i need more coffee ...

rday

-- 

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

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