On 8/15/12 8:08 AM, Paul Eggleton wrote:

On Wednesday 15 August 2012 12:25:23 Phil Blundell wrote:

quoted

On Wed, 2012-08-15 at 10:46 +0100, Paul Eggleton wrote:

quoted

1) Do we rename "task" to something a little more understandable to the
uninitiated, such as "package group"? The word "task" is already used in a
much more natural sense within bitbake as a unit of work. Historically I
believe we picked up this term from Debian but I'm not aware of
significant use by other mainstream distributions.

Yeah, I think OE inherited it from Familiar, which in turn got it from
Debian.  But the meaning of the term has drifted slightly through the
generations and, as you say, it is no longer a very accurate reflection
of what the packages in question are doing.

It's never been totally obvious to me that there is much need for
tasks/package group recipes as such in oe-core itself; they're rather
more of a DISTRO policy thing and their presence in the metadata does
obviously have a cost in terms of parse time and memory usage.  It might
perhaps be worth exploring what they're actually being used for in
oe-core and whether those things could be better done in a different way
that doesn't involve having a .bb file for them.

I would say without checking that these days that cost is negligible. Off the
top of my head, the benefits we get from using recipes for tasks as opposed to
variables or some similar construct:

  * The tasks can be used and referred to on the target if desired, not just
when you compose the image (i.e. task packages are produced and thus the
package manager knows about them).

I think this is a key advantage.  Again, if we think of these tasks as logical 
groups of functionality, it gives an image developer (or installer) the ability 
to say "I need booting, discrete commands, python, perl, and LSB compliance." 
and get a system in the end that -should- work.

The image/installer should always be able to specify individual recipes as well, 
but often inexperienced users won't know that they need two or three recipes 
(that don't have actual dependencies on each other) to get a functionally 
complete answer.

  * It should be slightly easier to find where tasks are defined within the
metadata. In practice that's not always the case with the way we have named
some of the tasks, hopefully that can be improved.

  * Related to the above, they can be customised in a visible manner using
bbappends in your own layer.

  * If you inherit from task.bbclass you automatically get -dev and -dbg
complements for the tasks defined by the recipe, which can sometimes be useful.

Cheers,
Paul