[yocto] [OE-core] RFC: OE-Core task rework

[Philip Balister]

On 08/21/2012 01:49 AM, Paul Eggleton wrote:
> On Monday 20 August 2012 15:45:07 Mark Hatle wrote:
...

>>
>> Yup, there is a logical grouping for the lsb specific tasks, as for others.
>> The naming needs to be made clear as to why it's there, and what it
>> represents. Same with the summary and descriptions -- they should list the
>> functionality provided by this group of components.
>
> The main concern with LSB is that we have something called task-basic, which
> seems to be intended for LSB but does not state as much, and I know at least
> one person has tried to use it and then been a little puzzled as to why rpm
> has been pulled in when ipk packaging has been selected. Just naming some of
> these tasks more appropriately would help avoid such situations. In the
> specific case of task-basic there may be a case for creating a similar but not
> LSB-focused task that pulls in real shell utilities in preference to the light
> versions provided by busybox.

I was seriously stumped by the presence of rpm in what I felt should 
have been a very basic image. If a task/group is targeted at lsb, it 
needs to have lsb plastered all over the name so the rest of us can 
avoid it :)

Philip

>
>>> 4) Consider the usefulness of the existing PACKAGE_GROUP_ structure which
>>> converts some IMAGE_FEATURES into the addition of tasks to be installed
>>> (see classes/core-image.bbclass). At the very least we should probably
>>> rename this if we rename tasks to package groups, and there's a question
>>> as to how IMAGE_FEATURES scales - should every task be represented in
>>> there or only a select list? Would we be better off not trying to bring
>>> any tasks in via IMAGE_FEATURES at all and mostly leave that to control
>>> post-processing (e.g. package-management, debug-tweaks, etc.)?
>>
>> I'd certainly prefer that images were limited to selecting software from
>> task (group) recipes only, and not providing their own.  An image should be
>> able to change the selection based on an "image feature" or similar
>> configuration, but the underlying tasks/groups, recipes, etc should all be
>> 'generic' to a given distribution configuration.
>
> The first part seems reasonable to me; but I'm still short of an answer as to
> what to do with the existing IMAGE_FEATURES code as mentioned above. At the
> moment aside from the special features such as debug-tweaks, these are just a
> thin layer on top of task recipes which doesn't add very much at all other
> than extra maintenance.
>
>> I think if you go through the images today, a lot of that stuff is either
>> old, or could be simplified by creating appropriate tasks/groups.
>
> OK, that's a good point. I have another task on my list to clean up our image
> recipes and that would be a good segue into that.
>
> Cheers,
> Paul
>