[yocto] [Yocto] RFC: Image Creator and Config Creator, design thoughts

[Tom Zanussi]

On Thu, 2011-04-21 at 09:05 -0700, 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. 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.
> 
> 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.
> 
> 
> 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).
> 

Input we got from the ELC talk suggested that people did think it would
be intuitive and useful to expand the kernel menuconfig 'UI' down to all
the other packages in the image.

I've used UIs designed like that in other build systems and it was very
useful, so I'd add my +1 to the ELC requests...

Tom

> 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
> 
> 
> 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?
> 
>