From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6790334981638979584 Date: Thu, 6 Feb 2020 09:47:46 -0800 (PST) From: vijai kumar To: isar-users Message-Id: <27f93d3b-c883-43fb-9532-24dd1750226a@googlegroups.com> In-Reply-To: <48d46a27-295c-a4d4-ea72-0ea2a1791809@siemens.com> References: <20200206140631.7928-1-Vijaikumar_Kanagarajan@mentor.com> <48d46a27-295c-a4d4-ea72-0ea2a1791809@siemens.com> Subject: Re: [PATCH] rootfs: Make rootfs_postprocess_finalize the last step MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_1893_1755210757.1581011266170" X-Google-Token: EMKi8fEFhnwa5oXvmr40 X-Google-IP: 106.51.234.238 X-TUID: DCJCB59esE6Z ------=_Part_1893_1755210757.1581011266170 Content-Type: multipart/alternative; boundary="----=_Part_1894_736265729.1581011266171" ------=_Part_1894_736265729.1581011266171 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit 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. > > > > > 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 Thanks, Vijai Kumar K Jan > > > Signed-off-by: Vijai Kumar K > > > --- > > meta/classes/rootfs.bbclass | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/meta/classes/rootfs.bbclass b/meta/classes/rootfs.bbclass > > index 64eaef7..b0394d5 100644 > > --- a/meta/classes/rootfs.bbclass > > +++ b/meta/classes/rootfs.bbclass > > @@ -197,7 +197,7 @@ rootfs_generate_manifest () { > > ${ROOTFS_MANIFEST_DEPLOY_DIR}/"${PF}".manifest > > } > > > > -ROOTFS_POSTPROCESS_COMMAND += "${@bb.utils.contains('ROOTFS_FEATURES', > 'finalize-rootfs', 'rootfs_postprocess_finalize', '', d)}" > > +ROOTFS_POSTPROCESS_COMMAND_append = > "${@bb.utils.contains('ROOTFS_FEATURES', 'finalize-rootfs', ' > rootfs_postprocess_finalize', '', d)}" > > rootfs_postprocess_finalize() { > > sudo -s <<'EOSUDO' > > test -e "${ROOTFSDIR}/chroot-setup.sh" && \ > > > > -- > Siemens AG, Corporate Technology, CT RDA IOT SES-DE > Corporate Competence Center Embedded Linux > ------=_Part_1894_736265729.1581011266171 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable


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, t= he 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 nee= d chroot.

=C2=A0

>=20
> Implicitly make rootfs_postprocess_finalize as the last step
> to be executed in rootfs_postprocess task.
>=20

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 prop= osal from Baurzhan[1] to remove finalize from rootfs features.
We could do something similar if no one actually uses that feature explic= itly. But, though not tested,
I believe that might break buildchr= oot, 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.=C2=A0=

[1]=C2=A0https://groups.google.com/d/msg/isar= -users/_RLBzyvvZvM/WuYpLPVBAQAJ

Thanks,
= Vijai Kumar K

Jan

> Signed-off-by: Vijai Kumar K <Vijaikumar_...@mentor.com&g= t;
> ---
> =C2=A0meta/classes/rootfs.bbclass | 2 +-
> =C2=A01 file changed, 1 insertion(+), 1 deletion(-)
>=20
> diff --git a/meta/classes/rootfs.bbclass b/meta/classes/rootfs.bbc= lass
> index 64eaef7..b0394d5 100644
> --- a/meta/classes/rootfs.bbclass
> +++ b/meta/classes/rootfs.bbclass
> @@ -197,7 +197,7 @@ rootfs_generate_manifest () {
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0${ROOTFS_MANIFEST_DEPLOY_DIR}/"${PF}".manifest
> =C2=A0}
> =C2=A0
> -ROOTFS_POSTPROCESS_COMMAND +=3D "${@bb.utils.contains('R= OOTFS_FEATURES', 'finalize-rootfs', 'rootfs_postproces= s_finalize', '', d)}"
> +ROOTFS_POSTPROCESS_COMMAND_append =3D "${@bb.utils.cont= ains('ROOTFS_FEATURES', 'finalize-rootfs', ' rootf= s_postprocess_finalize', '', d)}"
> =C2=A0rootfs_postprocess_finalize() {
> =C2=A0 =C2=A0 =C2=A0sudo -s <<'EOSUDO'
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0test -e "${ROOTFSDIR}/chroo= t-setup.sh" && \
>=20

--=20
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux
------=_Part_1894_736265729.1581011266171-- ------=_Part_1893_1755210757.1581011266170--