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

[Darren Hart]

On 04/26/2011 11:40 AM, Bruce Ashfield wrote:
> On 11-04-22 11:10 AM, Tom Zanussi wrote:
>> 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...
> 
> And I'd add another +1 to that.
> 

So the kernel guys agree that menuconfig should used everywhere.
Surprise, Surprise. ;-)

--
Darren

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

-- 
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel