On Thu, 2011-04-21 at 10:05 -0600, Darren Hart wrote:
I sat down with Josh earlier this week to discuss how I might use the
Image Creator in my development and to address any issues that might
pose as blockers to my finding such a tool useful. This led to various
feature discussions, scope setting, etc. I wanted to capture that here
and also ask for comments from other users and developers.
Image Recipe Generation
---
The image creator Josh is working on currently facilitates specifying
the policy (bitbake term distro, such as poky, poky-bleeding, or
poky-lsb), image, and any additional packages you may want to include.
It then provides a simple wrapper to bitbake and it's output.
Aside, wrapper is not the right term. This is a full fledged BitBake GUI
and uses the same libraries as the CLI (knotty) interface. :-)
This is
useful in and of itself as sorting out which variables to modify
(IMAGE_INSTALL, MACHINE(_ESSENTIAL?)_R?DEPENDS_append(_$MACHINE), etc)
and which tasks to rebuild (task_base, task_machine_base, poky-image-*,
etc.) can be a frustrating exercise (or at least it has been for me).
In order for this feature to be the most useful, it needs to be able to
save the result of the user's selection. This involves saving off the
distro selection (typically in local.conf) as well as an image recipe
defining which packages to include in the resulting image. This could be
done by writing to local.conf and saving a new *image*.bb file in a
suitable location.
Writing Layers
--
The suitable location is most likely a layer, which suggests the Image
Builder should probably know how to construct a basic layer skeleton and
prompt the user to fill in the descriptive bits required for layer.conf.
This sounds like a useful way to handle the customisations.
I could see this as having been useful for the recent Yocto Project 1.0
launch demo we worked on, which added rygel upnp video renderers to the
the 0.9 audio only demo. This implies the Image Builder should also be
able to work with an existing layer - perhaps only those that it created
- and save the changes back to that layer.
Layer support is definitely something I'd like to see in the Image
Creator. I'm thinking along the lines of a GUI for toggling available
layers enabled state.
Further to the suggestion above this GUI would likely also include a
Save my customisations to this layer entry.
Configuration Fragments
---
In order to properly build the demo images (poky-image-rygel
specifically) some specific license related variables need to be set,
typically in local.conf:
COMMERCIAL_LICENSE =
COMMERCIAL_AUDIO_PLUGINS ?= gst-plugins-ugly-mad
gst-plugins-ugly-mpegaudioparse
COMMERCIAL_VIDEO_PLUGINS ?= gst-plugins-ugly-mpeg2dec
gst-plugins-ugly-mpegstream gst-plugins-bad-mpegvideoparse
Without the above, the upnp demo is mostly non-functional. Having to
manually add these sorts of settings significantly reduces the value of
the Image Builder in my mind. This led to the discussion of providing a
graphical mechanism to set the variables that have some impact on how
the generated image recipe is built.
Something like a Linux kernel kconfig mechanism, which only shows the
user relevant options (albeit still WAY too many), might be really nice
here. Perhaps an interface that parsed the recipes included in the image
recipe and determined which variables would be relevant to the user and
present those in the UI with help derived from documentation.conf
doctags (or perhaps a new mechanism).
As this would be a considerable effort, and would surely delay the
progress of the image builder itself, perhaps a Configuration Editor
would be a good companion tool which the Image Builder could launch to
do the relevant configurations
I really like the idea of a configuration editor GUI, I'm pretty sure
Jeff Polk would like at least some of the infrastructure of this.
I haven't yet gotten around to investigating this but I think between
the doctags and the oetypes support Chris Larson implemented (which we
still need to pullit into oe-core iirc) we should have a solid
foundation on which to build this GUI.
Conclusions
---
The goal of any user interface should be to abstract away to
implementation details that are not particularly relevant to task at
hand, or to the user's perception of the task at hand. I feel these
tools as discussed above would help contain feature creep, while still
allowing for a more complete graphical interface to configuring and
building images.
Thoughts? Criticisms?
Unsurprisingly, since I was there, I'm in agreement.
Cheers,
Joshua
--
Joshua Lock
Yocto Build System Monkey
Intel Open Source Technology Center
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
