some simple questions/observations about package groups

some simple questions/observations about package groups

[Robert P. J. Day]

  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:

# By default we install packagegroup-core-boot and packagegroup-base packages -

for that comment to read "packages" is a little ambiguous, yes?

  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.

  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?

  lots of pedantry ...

rday

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.

-- 

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

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

Re: some simple questions/observations about package groups

[Chris Larson]

[-- Attachment #1: Type: text/plain, Size: 2525 bytes --]

On Wed, Nov 28, 2012 at 4:45 AM, Robert P. J. Day <rpjday@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

[-- Attachment #2: Type: text/html, Size: 3716 bytes --]

Re: some simple questions/observations about package groups

[Chris Larson]

[-- Attachment #1: Type: text/plain, Size: 776 bytes --]

On Wed, Nov 28, 2012 at 3:26 PM, Chris Larson <clarson@kergoth.com> wrote:

> 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_


Erm, wrong button. To continue: or..

bitbake -s | grep packagegroup-

Also, to comment on something tangentially related from a different thread,
technically the PACKAGE_GROUP_ variables were the first to use the term as
far as I'm aware. *tasks* were then renamed to use that name as well, which
is where a bunch of the confusion probably got introduced.
-- 
Christopher Larson

[-- Attachment #2: Type: text/html, Size: 1425 bytes --]

Re: some simple questions/observations about package groups

[Paul Eggleton]

On Wednesday 28 November 2012 15:27:58 Chris Larson wrote:
> Also, to comment on something tangentially related from a different thread,
> technically the PACKAGE_GROUP_ variables were the first to use the term as
> far as I'm aware. *tasks* were then renamed to use that name as well, which
> is where a bunch of the confusion probably got introduced.

I did mention that:

> PACKAGE_GROUP_* actually came first as a way to 
> define items for IMAGE_FEATURES that map to one or more packages, and I'm
> not  sure the name choice was a particularly good one - I wonder if it
> would be worth considering renaming it to something like
> IMAGE_FEATURE_PACKAGES in order to avoid confusion, although obviously
> every rename like this has a cost associated.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: some simple questions/observations about package groups

[Robert P. J. Day]

On Thu, 29 Nov 2012, Paul Eggleton wrote:

> On Wednesday 28 November 2012 15:27:58 Chris Larson wrote:
> > Also, to comment on something tangentially related from a different thread,
> > technically the PACKAGE_GROUP_ variables were the first to use the term as
> > far as I'm aware. *tasks* were then renamed to use that name as well, which
> > is where a bunch of the confusion probably got introduced.
>
> I did mention that:
>
> > PACKAGE_GROUP_* actually came first as a way to
> > define items for IMAGE_FEATURES that map to one or more packages, and I'm
> > not  sure the name choice was a particularly good one - I wonder if it
> > would be worth considering renaming it to something like
> > IMAGE_FEATURE_PACKAGES in order to avoid confusion, although obviously
> > every rename like this has a cost associated.

  before i forgot all of this, i lashed together this wiki page for my
own benefit so i'd have some examples to show students:

http://www.crashcourse.ca/wiki/index.php/OE_package_groups

it's admittedly in rough form and could use some polishing but it will
do for now.  feedback?  errors?  on to the next topic  ...

rday

-- 

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

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

Re: some simple questions/observations about package groups

[Paul Eggleton]

On Thursday 29 November 2012 06:58:02 Robert P. J. Day wrote:
> On Thu, 29 Nov 2012, Paul Eggleton wrote:
> > On Wednesday 28 November 2012 15:27:58 Chris Larson wrote:
> > > Also, to comment on something tangentially related from a different
> > > thread,
> > > technically the PACKAGE_GROUP_ variables were the first to use the term
> > > as
> > > far as I'm aware. *tasks* were then renamed to use that name as well,
> > > which
> > > is where a bunch of the confusion probably got introduced.
> > 
> > I did mention that:
> > > PACKAGE_GROUP_* actually came first as a way to
> > > define items for IMAGE_FEATURES that map to one or more packages, and
> > > I'm
> > > not  sure the name choice was a particularly good one - I wonder if it
> > > would be worth considering renaming it to something like
> > > IMAGE_FEATURE_PACKAGES in order to avoid confusion, although obviously
> > > every rename like this has a cost associated.
> 
>   before i forgot all of this, i lashed together this wiki page for my
> own benefit so i'd have some examples to show students:
> 
> http://www.crashcourse.ca/wiki/index.php/OE_package_groups
> 
> it's admittedly in rough form and could use some polishing but it will
> do for now.  feedback?  errors?

You're describing those things defined by PACKAGE_GROUP_* as package groups, 
which I would strongly advise against. I know the naming of PACKAGE_GROUP_* 
suggests that the two are part of the same thing but they really aren't. Most 
of this page apart from section 5 is actually talking about IMAGE_FEATURES and 
should be reworded as such if you want to reduce confusion rather than 
increasing it.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: some simple questions/observations about package groups

[Robert P. J. Day]

On Thu, 29 Nov 2012, Paul Eggleton wrote:

> On Thursday 29 November 2012 06:58:02 Robert P. J. Day wrote:
> > On Thu, 29 Nov 2012, Paul Eggleton wrote:
> > > On Wednesday 28 November 2012 15:27:58 Chris Larson wrote:
> > > > Also, to comment on something tangentially related from a different
> > > > thread,
> > > > technically the PACKAGE_GROUP_ variables were the first to use the term
> > > > as
> > > > far as I'm aware. *tasks* were then renamed to use that name as well,
> > > > which
> > > > is where a bunch of the confusion probably got introduced.
> > >
> > > I did mention that:
> > > > PACKAGE_GROUP_* actually came first as a way to
> > > > define items for IMAGE_FEATURES that map to one or more packages, and
> > > > I'm
> > > > not  sure the name choice was a particularly good one - I wonder if it
> > > > would be worth considering renaming it to something like
> > > > IMAGE_FEATURE_PACKAGES in order to avoid confusion, although obviously
> > > > every rename like this has a cost associated.
> >
> >   before i forgot all of this, i lashed together this wiki page for my
> > own benefit so i'd have some examples to show students:
> >
> > http://www.crashcourse.ca/wiki/index.php/OE_package_groups
> >
> > it's admittedly in rough form and could use some polishing but it will
> > do for now.  feedback?  errors?
>
> You're describing those things defined by PACKAGE_GROUP_* as package
> groups, which I would strongly advise against. I know the naming of
> PACKAGE_GROUP_* suggests that the two are part of the same thing but
> they really aren't. Most of this page apart from section 5 is
> actually talking about IMAGE_FEATURES and should be reworded as such
> if you want to reduce confusion rather than increasing it.

  ok, i will work on that later today.  i do remember your earlier
email warning about a bad choice of names, so i'll review that.

rday

-- 

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

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