From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6790334981638979584 Date: Thu, 6 Feb 2020 10:28:35 -0800 (PST) From: vijai kumar To: isar-users Message-Id: In-Reply-To: <201722b6-2a98-ca90-30f4-287205d4cedc@siemens.com> References: <20200206140631.7928-1-Vijaikumar_Kanagarajan@mentor.com> <48d46a27-295c-a4d4-ea72-0ea2a1791809@siemens.com> <27f93d3b-c883-43fb-9532-24dd1750226a@googlegroups.com> <201722b6-2a98-ca90-30f4-287205d4cedc@siemens.com> Subject: Re: [PATCH] rootfs: Make rootfs_postprocess_finalize the last step MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_1724_1353772513.1581013716020" X-Google-Token: ENO18fEFZB8z89qm1Oo0 X-Google-IP: 192.94.34.34 X-TUID: rrPYnpIAWHsK ------=_Part_1724_1353772513.1581013716020 Content-Type: multipart/alternative; boundary="----=_Part_1725_1894028166.1581013716021" ------=_Part_1725_1894028166.1581013716021 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On Thursday, February 6, 2020 at 11:39:20 PM UTC+5:30, Jan Kiszka wrote: > > On 06.02.20 18:47, vijai kumar wrote: > > > > > > On Thursday, February 6, 2020 at 10:51:22 PM UTC+5:30, Jan Kiszka wrote: > > > > On 06.02.20 15:06, Vijai Kumar K wrote: > > > Sometimes the additional postprocessing functions we add as > > > part our custom image needs a proper chroot environment. > > > > When exactly? > > > > > > > > Though not finalized, the base-apt source gathering which I proposed to > > do via rootfs postprocess. > > That is the only one right now. But I believe more similar might come. > > We already > > have some post-process in our QA layer to pull out the dpkg status file > > for processing. > > But that doesn't need chroot. > > > > Absolutely fine, just make sure to describe use cases when arguing about > the "why" of a commit (which is what the commit log is about). > Sure. I agree that the 'Sometimes' is pretty vague. Sorry, Will take care of that. > > > > > > > > > > > Implicitly make rootfs_postprocess_finalize as the last step > > > to be executed in rootfs_postprocess task. > > > > > > > Well, that relies on no one else using _append to add things. > > Otherwise, > > the race is open again... > > > > > > Yes. Also to note, there was this proposal from Baurzhan[1] to remove > > finalize from rootfs features. > > We could do something similar if no one actually uses that feature > > explicitly. But, though not tested, > > I believe that might break buildchroot, and we might need to take care > > of it in buildchroot's post-process. > > If everyone agrees then we could take that path. That should be cleaner > > and should avoid these kinds of > > easy to make errs. > > > > [1] https://groups.google.com/d/msg/isar-users/_RLBzyvvZvM/WuYpLPVBAQAJ > > > > Second voice. Seems like we should do it then, model the finalization > without ROOTFS_POSTPROCESS_COMMAND. > > Sure. I will start working on that. Thanks, Vijai Kumar K > Jan > > -- > Siemens AG, Corporate Technology, CT RDA IOT SES-DE > Corporate Competence Center Embedded Linux > ------=_Part_1725_1894028166.1581013716021 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable


On Thursday, February 6, 2020 at 11:39:20 PM UTC+5= :30, Jan Kiszka wrote:
On 06.02= .20 18:47, vijai kumar wrote:
>=20
>=20
> On Thursday, February 6, 2020 at 10:51:22 PM UTC+5:30, Jan Kiszka = wrote:
>=20
> =C2=A0 =C2=A0 On 06.02.20 15:06, Vijai Kumar K wrote:
> =C2=A0 =C2=A0 > Sometimes the additional postprocessing functio= ns we add as
> =C2=A0 =C2=A0 > part our custom image needs a proper chroot env= ironment.
>=20
> =C2=A0 =C2=A0 When exactly?
>=20
>=20
>=20
> Though not finalized, the base-apt source gathering which I propos= ed to
> do via rootfs postprocess.
> That is the only one right now. But I believe more similar might c= ome.
> We already
> have some post-process in our QA layer to pull out the dpkg status= file
> for processing.
> But that doesn't need chroot.
>=20

Absolutely fine, just make sure to describe use cases when arguing abou= t
the "why" of a commit (which is what the commit log is about)= .

Sure. I agree that the 'Sometimes&= #39; is pretty vague.=C2=A0 Sorry, Will take care of that.

> =C2=A0
>=20
>=20
> =C2=A0 =C2=A0 >
> =C2=A0 =C2=A0 > Implicitly make rootfs_postprocess_finalize as = the last step
> =C2=A0 =C2=A0 > to be executed in rootfs_postprocess task.
> =C2=A0 =C2=A0 >
>=20
> =C2=A0 =C2=A0 Well, that relies on no one else using _append to ad= d things.
> =C2=A0 =C2=A0 Otherwise,
> =C2=A0 =C2=A0 the race is open again...
>=20
>=20
> Yes. Also to note, there was this proposal from Baurzhan[1] to rem= ove
> finalize from rootfs features.
> We could do something similar if no one actually uses that feature
> explicitly. But, though not tested,
> I believe that might break buildchroot, and we might need to take = care
> of it in buildchroot's post-process.
> If everyone agrees then we could take that path. That should be cl= eaner
> and should avoid these kinds of
> easy to make errs.=C2=A0
>=20
> [1]=C2=A0https://= groups.google.com/d/msg/isar-users/_RLBzyvvZvM/WuYpLPVBAQAJ
>=20

Second voice. Seems like we should do it then, model the finalization
without ROOTFS_POSTPROCESS_COMMAND.


Sure. I will start working on that.

Thanks,
Vijai Kumar K
=C2=A0
Jan

--=20
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux
------=_Part_1725_1894028166.1581013716021-- ------=_Part_1724_1353772513.1581013716020--