On 8/15/12 2:12 PM, Chris Larson wrote:
On Wed, Aug 15, 2012 at 11:05 AM, Mark Hatle <mark.ha...@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
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
