On 12-11-21 11:29 AM, Venkata ramana gollamudi wrote:
-----Original Message-----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.
From: Bruce Ashfield [mailto:firstname.lastname@example.org]
Sent: Tuesday, November 20, 2012 8:53 PM
To: Venkata ramana gollamudi
Cc: email@example.com; 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 wherethe 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
Offline Configuration tool (OCT), which allows a binary imagecustomization 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
into final target image.
The basic operations that can be supported includes
a) Select/deselect required packages from pool of binary packages
b) Provision to select external binary packages like ADT compiledapplications as input and add them to final target image.
c) Binary level Offline configuration can includesfollowing changes can be done.
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
Considering the methods to support these in our current yocto model,
1) HOB can be the tool which can be extended to support theseHob can work on this package pool to select packages, configure and
Poky can generate a binary package pool as one if its output and
So HOB can support opening HOB in Binary(or OCT) mode i.e., withoutbuild 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 andoverall organization as they will be intended for different users.
Is there some overlap between this point and the other ongoing
about image construction, deployment and package management ?
i.e. this thread:
[OE-core] RFC: OE-Core image creation and deployment
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!
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?
Not that I know of. It is still under design last I heard, but MarkH is the
person to provide the details. He's out of the office at the moment, but
I'm sure that when he is back he can provide plenty of information.
I am looking for post build configuration tool, which allows the product team users also to configure users, network, services etc .
Agreed. I see this as something to start with, since it doesn't overlap
with the other efforts (that I know of), and when I first read your
email I thought it was the main focus. When you continued into image
creation and package selection, that's when I noted the overlap.
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.
Keeping the number of tools low is a good thing, so hopefully it can fit
within the existing options.
Point 2, No longer applicable as package-feed is a binary pool.
2) Binary package pool can be a minimal/partial sstate-cache, ascomplete sstate-cache is quite big and not required for product teams
as they are not expected to build but just need to select and
I think it is sufficient to keep the minimal binaries fromsstate-cache which are required to execute image.bbclass, do_rootfs
task to generate image.
Point 3, still can be thought about.
3) Along with specific configuration UI implementation, a genericconfiguration model similar to kernel kconfig and menuconfig can be
considered, in cases where more detailed offline configurations is
required like detailed security configuration.
There have been other menuconfig efforts in the past (that I've heard
about, but not had direct involvement), so doing some research in this
area would be appropriate as well.
yocto mailing list