[Openembedded-architecture] Incorporating deploy artefacts from one multiconfig in another multiconfig

[Rich Persaud]

On Feb 21, 2019, at 13:28, Mark Hatle <mark.hatle at windriver.com> wrote:
> 
>> On 2/21/19 9:44 AM, Burton, Ross wrote:
>> So I'd like to use multiconfig for a fairly typical host/container use
>> case.  I've a class which can be used to build packages from images in
>> a fairly simple manner, essential just taking files from DEPLOY_DIR
>> when creating a package:
>> 
>> core-image-minimal-package.bb:
>> do_install[depends] += "core-image-minimal:do_image_complete
>> virtual/kernel:do_deploy"
>> do_install () {
>>    install -d ${D}/var/lib/machines/
>>    install ${DEPLOY_DIR_IMAGE}/core-image-minimal-${MACHINE}.ext4
>> ${D}/var/lib/machines/core-image-minimal.ext4
>>    install ${DEPLOY_DIR_IMAGE}/${KERNEL_IMAGETYPE}
>> ${D}/var/lib/machines/${IMAGE_NAME}.${KERNEL_IMAGETYPE}
>> }
>> 
>> This part works fine, but the problem is straddling multiconfig boundaries...
>> 
>> I can't just add "core-image-minimal-package" to IMAGE_INSTALL because
>> it will build that for the current configuration.  I can't just add
>> "multiconfig:uos:core-image-minimal-package" because that will look
>> for a recipe with that name.  I've a rather ugly hack to call opkg
>> directly in a post-rootfs hook which sort of works.  Linking in bits
>> of the other configuration's deploy directory in a pre-rootfs hook and
>> extending IMAGE_INSTALL there almost works, apart from the rootfs code
>> then looks at the task dependencies to generate a pruned deploy dir,
>> which is missing the pieces I linked in.
>> 
>> I suspect this is now breaking new ground: the multiconfiguration
>> support lets you do builds but so far the artefact sharing hasn't
>> really been explored.  Has anyone dug further into this?
> 
> I don't think anyone has.  But as we continue moving toward containers/micro
> services environments -- this exactly type of thing is going to be more and more
> needed.
> 
> One 'build', with various configurations that end up constructing a single
> device image with a container runtime (booting OS), and a number of container
> micro services should be able to be created with a single call to bitbake and (a
> potentially complex) config.

That would be an elegant, dependency-aware alternative to this packaging script for OpenXT, with more than a dozen invocations of bitbake, to build virtual machines and package them for installer ISO, network bootable images and OTA update.

  https://github.com/OpenXT/openxt/blob/master/do_build.sh
  https://github.com/OpenXT/xenclient-oe

Rich
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openembedded.org/pipermail/openembedded-architecture/attachments/20190221/1f0d5cd7/attachment.html>