Re: RFC: OE-Core task rework

[Mark Hatle <mark.hatle@windriver.com>]

On 8/15/12 8:08 AM, Paul Eggleton wrote:
> On Wednesday 15 August 2012 12:25:23 Phil Blundell wrote:
>> On Wed, 2012-08-15 at 10:46 +0100, Paul Eggleton wrote:
>>> 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
>