From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6594287117104316416 Date: Mon, 27 Aug 2018 06:48:05 -0700 (PDT) From: chombourger@gmail.com To: isar-users Message-Id: In-Reply-To: References: <1db1ee65-3af9-8789-7c0f-169c452597b5@siemens.com> Subject: Re: Incremental target images MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_893_1148606782.1535377686045" X-Google-Token: EJWCkNwFySBr7mSJBQM0 X-Google-IP: 192.94.31.2 X-TUID: qf5NNbl/6DZi ------=_Part_893_1148606782.1535377686045 Content-Type: multipart/alternative; boundary="----=_Part_894_1807502691.1535377686046" ------=_Part_894_1807502691.1535377686046 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit This would have been my thinking as. Add something like IMAGE_CREATE_FROM = "production-image" in your development-image recipe would go a long way. +1 for Jan's suggestion. Cedric On Monday, August 27, 2018 at 10:29:35 AM UTC+2, Jan Kiszka wrote: > > On 2018-08-27 09:44, Claudius Heine wrote: > > On 2018-08-27 09:25, [ext] Claudius Heine wrote: > >> Hi Jan, > >> > >> On 2018-08-27 08:41, [ext] Jan Kiszka wrote: > >>> Hi all, > >>> > >>> I was wondering if / how we could model the increasingly common case > >>> of building very similar target images more efficiently. > >>> > >>> A devel image, e.g., likely consists of almost the same base package > >>> set as the release image. It may only add further packages and maybe > >>> replace very few (like customization packages). When building both, > >>> we could save time - specifically when doing cross - by bootstrapping > >>> the baseline only once. We already do that for the debootstrap step, > >>> but not yet for further packages. > >>> > >>> What do you think? And how could that be modeled from user > perspective? > >> > >> That is not very easy. > >> > >> A complex way this could be done by having a `common image` recipe > >> that depends on other image recipes to deploy their required package > >> list, > > > > What I meant by that is each image recipe writes its package list into > > its own text file in the 'deploy' directory. > > > >> then figure out the common dependencies of all of them and build the > >> custom image. > > > > s/custom/common/ > > > > Problem scenario here is: > > > > Image A: depends on A which depends on D > > Image B: depends on B which depends on D > > > > Since D is not named in any recipes, but should be installed in the > > `common image` as automatically selected package (not as manual). This > > scripting is a bit tricky. > > > >> Then those other image recipes depend of the `common image` recipe in > >> turn to create it, copy it and base their own customizations on top. > >> > >> From a user perspective they would have to add their image recipes > >> into a global variable or bbappend, so that is available in the > >> `common image` recipe. The rest could be done in the image classes. > >> > >> Cheers, > >> Claudius > > > > Hmm, I'm not seeing yet where the complication could come from. I would > have expected the following: > > - write a new image recipe include that takes a preexisting image in > form of a rootfs as input (rather than using setup_root_file_system) > > - create specialized images on top of that which depend on some base > image recipe as well as additional IMAGE_INSTALL recipes and may come > with own IMAGE_PREINSTALLs (always on top of base images) > > - push all common IMAGE_PREINSTALLs into base image recipes, same for > all IMAGE_INSTALLs > > And done. What am I missing? > > Jan > ------=_Part_894_1807502691.1535377686046 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
This would have been my thinking as. Add something like IM= AGE_CREATE_FROM =3D "production-image" in your development-image = recipe would go a long way.

+1 for Jan's suggestion.=

Cedric

On Monday, August 27, 2018 at 10:29= :35 AM UTC+2, Jan Kiszka wrote:
On 2018-08-27 09:44, Claudius Heine wrote:
> On 2018-08-27 09:25, [ext] Claudius Heine wrote:
>> Hi Jan,
>>
>> On 2018-08-27 08:41, [ext] Jan Kiszka wrote:
>>> Hi all,
>>>
>>> I was wondering if / how we could model the increasingly c= ommon case=20
>>> of building very similar target images more efficiently.
>>>
>>> A devel image, e.g., likely consists of almost the same ba= se package=20
>>> set as the release image. It may only add further packages= and maybe=20
>>> replace very few (like customization packages). When build= ing both,=20
>>> we could save time - specifically when doing cross - by bo= otstrapping=20
>>> the baseline only once. We already do that for the deboots= trap step,=20
>>> but not yet for further packages.
>>>
>>> What do you think? And how could that be modeled from user= perspective?
>>
>> That is not very easy.
>>
>> A complex way this could be done by having a `common image` re= cipe=20
>> that depends on other image recipes to deploy their required p= ackage=20
>> list,
>=20
> What I meant by that is each image recipe writes its package list = into=20
> its own text file in the 'deploy' directory.
>=20
>> then figure out the common dependencies of all of them and bui= ld the=20
>> custom image.
>=20
> s/custom/common/
>=20
> Problem scenario here is:
>=20
> =C2=A0=C2=A0Image A: depends on A which depends on D
> =C2=A0=C2=A0Image B: depends on B which depends on D
>=20
> Since D is not named in any recipes, but should be installed in th= e=20
> `common image` as automatically selected package (not as manual). = This=20
> scripting is a bit tricky.
>=20
>> Then those other image recipes depend of the `common image` re= cipe in=20
>> turn to create it, copy it and base their own customizations o= n top.
>>
>> =C2=A0From a user perspective they would have to add their ima= ge recipes=20
>> into a global variable or bbappend, so that is available in th= e=20
>> `common image` recipe. The rest could be done in the image cla= sses.
>>
>> Cheers,
>> Claudius
>=20

Hmm, I'm not seeing yet where the complication could come from. I w= ould=20
have expected the following:

- write a new image recipe include that takes a preexisting image in
=C2=A0 =C2=A0form of a rootfs as input (rather than using setup_root_fi= le_system)

- create specialized images on top of that which depend on some base
=C2=A0 =C2=A0image recipe as well as additional IMAGE_INSTALL recipes a= nd may come
=C2=A0 =C2=A0with own IMAGE_PREINSTALLs (always on top of base images)

- push all common IMAGE_PREINSTALLs into base image recipes, same for
=C2=A0 =C2=A0all IMAGE_INSTALLs

And done. What am I missing?

Jan
------=_Part_894_1807502691.1535377686046-- ------=_Part_893_1148606782.1535377686045--