Re: RFC: OE-Core task rework

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

On 8/15/12 2:12 PM, Chris Larson wrote:
> On Wed, Aug 15, 2012 at 11:05 AM, Mark Hatle <mark.hatle@windriver.com> wrote:
>>>    * 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 seems like you're arguing in favor of the ability to add groups of
> packages to an image, which no one disagrees with, and isn't really
> relevant to the bit you're quoting. The bit that tasks add that
> package groups / image features don't is the ability to add them after
> the fact at runtime, not image creation time.
>

It's both.. cross image creation, and on-target image creation (and updates). 
During runtime, some folks will want to add "features" to the system...  these 
are not what I would consider "image" features, but what we call task recipes today.

I.e. I have a base system, and a vendor says I need LSB compatibility -- 
assuming I have the right distro features set, I should be able to select one or 
more LSB "tasks" and suddenly I'm LSB compliant, without having to know all of 
the individual packages required.

--Mark