[yocto] Need for offline binary configuration

[Venkata ramana gollamudi]

Reply inline

> -----Original Message-----
> From: Bruce Ashfield [mailto:bruce.ashfield at windriver.com]
> Sent: Tuesday, November 20, 2012 8:53 PM
> To: Venkata ramana gollamudi
> Cc: yocto at yoctoproject.org; Sanil kumar; Hatle, Mark
> Subject: Re: [yocto] Need for offline binary configuration
> 
> On 12-11-20 10:09 AM, Venkata ramana gollamudi wrote:
> > Poky allows to build custom Linux for you, but we have cases where
> the post build customization is required, like user-addition, network
> configuration, service control. Even selecting the required packages
> can be a post build activity.
> >
> > The current model requires the image to be rebuilt to support these
> configuration.
> > Offline Configuration tool (OCT), which allows a binary image
> customization before making a final target image. This case will be
> more evident in larger companies, where platform teams, product teams ,
> application teams are distributed and Linux build from source will be
> owned and lab tested by a single team, like platform team. Other teams
> just configure to use it for product variants from same platform build.
> >
> > Detailed use cases can be found in enhancement bug:3252
> >
> > OCT should work on the binary pool of compiled packages generated
> from poky.
> >
> > The basic operations that can be supported includes
> > a) Select/deselect required packages from pool of binary packages
> into final target image.
> > b) Provision to select external binary packages like ADT compiled
> applications as input and add them to final target image.
> > c) Binary level Offline configuration can includes
> >        Configure the users/passwords
> >        Configure the network
> >        Configure the host name
> >        Select the services to be started by default
> >        Security related configuration
> >        Generate initrd in ramfs/ext3/... format
> >        etc..
> >
> > Considering the methods to support these in our current yocto model,
> following changes can be done.
> > 1) HOB can be the tool which can be extended to support these
> >      Poky can generate a binary package pool as one if its output and
> Hob can work on this package pool to select packages, configure and
> generate image.
> > So HOB can support opening HOB in Binary(or OCT) mode i.e., without
> build options but only with binary package selection. Configuration GUI
> needs to be added to HOB.
> > Note:HOB+OCT is together or separate, needs a bit more thought and
> overall organization as they will be intended for different users.
> 
> Is there some overlap between this point and the other ongoing
> discussions
> about image construction, deployment and package management ?
> 
> i.e. this thread:
> 
>    [OE-core] RFC: OE-Core image creation and deployment
> 
> http://lists.linuxtogo.org/pipermail/openembedded-core/2012-
> July/026938.html
> 
> These may already be coordinated, but I do see some common threads and
> it would be nice to make sure everything will work together and that we
> aren't duplicating effort!
> 
> Cheers,
> 
> Bruce
> 

Bruce, Thanks for the information. After your reply, I have gone through the discussions and agree that binary pool is in similar lines. Great to see that the realization happening in yocto1.4.
Understood that package-feed can be used to generate the target image.

Is there any RFC/mail/wiki available explaining how the configuration(like fstype) during image generation will be realized?

I am looking for post build configuration tool, which allows the product team users also to configure users, network, services etc .
Image type, file system and Partition configuration can be one of them.
I expect the product team users who configures image and generates target image, will have a little or no knowledge of bitbake, also needs easy installation and less dependencies.

Can look in this context, how HOB will fit into this scenario or needs a new tool.

> 
> > 2) Binary package pool can be a minimal/partial sstate-cache, as
> complete sstate-cache is quite big and not required for product teams
> as they are not expected to build but just need to select and
> configure.
> >      I think it is sufficient to keep the minimal binaries from
> sstate-cache which are required to execute image.bbclass, do_rootfs
> task to generate image.

Point 2, No longer applicable as package-feed is a binary pool.

> > 3) Along with specific configuration UI implementation, a generic
> configuration model similar to kernel kconfig and menuconfig can be
> considered, in cases where more detailed offline configurations is
> required like detailed security configuration.

Point 3, still can be thought about.

> >
> > Regards,
> > Ramana
> > _______________________________________________
> > yocto mailing list
> > yocto at yoctoproject.org
> > https://lists.yoctoproject.org/listinfo/yocto
> >