On Wed, Aug 15, 2012 at 11:05 AM, Mark Hatle [off-list ref] wrote:

quoted

  * 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.
-- 
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics