[OE-core] some simple questions/observations about package groups

[Chris Larson]

On Wed, Nov 28, 2012 at 4:45 AM, Robert P. J. Day <rpjday at crashcourse.ca>wrote:

>   perusing package groups, and a few simple questions and probably a
> couple things i can submit patches for.
>
>   first, is IMAGE_FEATURES *exclusively* for selecting package groups
> and not individual packages?  since core-image.bbclass reads:
>

IMAGE_INSTALL is for packages. IMAGE_FEATURES is for image features, of
which metadata defined package groups (PACKAGE_GROUP_*) are some.


> # By default we install packagegroup-core-boot and packagegroup-base
> packages -
>
> for that comment to read "packages" is a little ambiguous, yes?
>

Not really, no. 'packagegroup-core-boot' is a binary package emitted by the
packagegroup-core-boot recipe. They are packages.

  that same comment seems inaccurate as well, since it refers to
> "packagegroup-base" when, below, it's actually:
>
>
> CORE_IMAGE_BASE_INSTALL = '\
>     packagegroup-core-boot \
>     packagegroup-base-extended \     <-- see?
>
> so that's just a quick doc fix.
>
>   again, back at the top, we read:
>
> # IMAGE_FEATURES control content of the core reference images
>
> but it's not just the *core* reference images, is it?  in fact, the
> list of available IMAGE_FEATURES in that file doesn't include
> "splash", which is inherited from image.bbclass.  should that not be
> in the list?  that also means that PACKAGE_GROUP_splash is available
> to non-core images.
>

By core images in this context I expect it means any image that inherits
core-image.

   finally, meta/conf/local.conf.sample also allegedly lists the
> possibilities for EXTRA_IMAGE_FEATURES, but that list is noticeably
> incomplete.  why not just refer the reader to core-image.bbclass,
> rather than try to keep a current list in both places?
>

I'd imagine it's hard enough getting people to read local.conf.sample,
without also expecting them to read other files. It's no different than any
other case of documentation (in comment form, in this case) not matching
the content.

p.s. as with other things i've put on my wish list, it would be great
> if a variation of bitbake could list the available package groups.
>

Depending on whether you want the metadata package groups or the packages:

bitbake -e <some core-image inheriting recipe> | grep PACKAGE_GROUP_
-- 
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20121128/19e043ae/attachment-0002.html>