Re: RFC: OE-Core task rework

[Paul Eggleton <paul.eggleton@linux.intel.com>]

On Wednesday 15 August 2012 10:46:49 Paul Eggleton wrote:
> Hi all,
> 
> There have been a few requests to review the task recipes (i.e. package
> groups) provided by OE-Core, and indeed these have not really been looked at
> seriously since OE-Core was created. Ideally I think we want them to be
> useful to a wide audience and provide useful units of functionality that
> can be added to an image without the person doing the selection having to
> manually select too many individual packages. Imagine presenting the list
> of tasks to someone in a UI for assembling images (such as Hob or
> Narcissus) and you can start to see that we have some work to do in this
> area.
> 
> I know various distros and users of OE-Core have created their own tasks or
> resurrected tasks from OE-Classic, and this is an opportunity to perhaps
> look at bringing some of these (or at least, parts of them) into the core.
> It is true that tasks will often be an expression of distro policy, and we
> also can't have any tasks in OE-Core that refer to packages that don't
> exist in OE- Core; thus distros will always be extending the base tasks or
> adding their own - and that's fine. However, with some thought I believe we
> can come up with a set of tasks that are generally useful to most people
> using OE-Core.
> 
> For reference, I've compiled a list on the wiki of the current tasks in OE-
> Core with links to the recipes and some notes:
> 
>   http://www.openembedded.org/wiki/OE-Core_Task_Rework
> 
> Some of the things I think we ought to consider/address as part of this
> exercise:
> 
> 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.
> 
> 2) Look at the existing tasks and:
>  * evaluate their usefulness
>  * remove any that are obsolete
>  * adjust existing contents if needed
>  * look for useful groups of packages that might be added
> 
>  We need to pay particular attention to task-core-boot and task-base as
> these are pulled in by default in any image that inherits from
> core-image.bbclass - if these are not generally working for people that are
> creating their own images, we need to change them such that they are.
> 
> 3) Ensure all task recipes follow reasonable patterns:
>  *  Fix recipe DESCRIPTIONs to make sense (and not contain Poky references)
>  *  Ensure all individual packages have a decent SUMMARY/DESCRIPTION
>  *  Try to make each task have a reasonable name - there are some current
> uses of "core" and "base" that don't actually convey any meaning; LSB
> specific tasks should be named as such, etc.
>  *  Make all tasks inherit task.bbclass so that they get proper dbg/dev
> packages and any other common task functionality
> 
> 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.)?
> 
> Please reply with your thoughts. Once we've come to a consensus on the
> things we want to do (allowing plenty of time for discussion), I'll look at
> putting together a set of patches that makes the appropriate changes.

So, any further thoughts on this one?

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre