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
_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
