From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 7306407937029701632 Date: Mon, 11 Dec 2023 21:18:12 -0800 (PST) From: Srinuvasan Arjunan To: isar-users Message-Id: <33f90a6e-1bc5-4a5b-ba2d-daa645220854n@googlegroups.com> In-Reply-To: References: <20231128071401.1894962-1-srinuvasan_a@mentor.com> Subject: Re: [RFC][PATCH] Add sbuildchroot class MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_90845_1454962465.1702358292591" X-TUID: hxHBc68YSdlP ------=_Part_90845_1454962465.1702358292591 Content-Type: multipart/alternative; boundary="----=_Part_90846_704296951.1702358292591" ------=_Part_90846_704296951.1702358292591 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tuesday, December 12, 2023 at 10:38:08=E2=80=AFAM UTC+5:30 Jan Kiszka wr= ote: On 12.12.23 05:55, Srinuvasan Arjunan wrote:=20 >=20 >=20 > On Friday, December 8, 2023 at 7:45:06=E2=80=AFPM UTC+5:30 Jan Kiszka wro= te:=20 >=20 > On 28.11.23 08:14, Srinuvasan Arjunan wrote:=20 > > From: Srinuvasan A =20 > >=20 > > In present implementation we are using sbuild/schroot to build the=20 > > packages, this schroot created via sessions during package build, and= =20 > > immediatley vanish once build the packages.=20 > >=20 > > Some of the downstream projects uses this chroot at many=20 > > places for doing some postprocessing the meta data based on the=20 > chroot=20 > > path, but unfortunately we cannot refer this path due to creating the= =20 > > chroot via session.=20 >=20 > Can you be more specific in the use cases?=20 >=20 >=20 > In our case we need to install the custom packages in buildchroot,=20 > once we installed the isar-apt packages, later we refer those and do= =20 some=20 > postprocessing before image creation.=20 >=20 >=20 > ISAR provides the provision to pre-install the upstream packages=20 > not custom packages and this chroot will be used as a base chroot to= =20 > build the packages or imager_run, hence SBUILD_FLAVOR would not be=20 > helpful atleast for my scenario.=20 >=20 >=20 > SBUILD_CHROOT_PREINSTALL_EXTRA variable directly install the upstream = =20 > packages in rootfs not custom packages.=20 >=20 Understood the use case now - but then why not fixing/enhancing the=20 existing mechanism? We likely need some SBUILD_CHROOT_INSTALL_EXTRA that=20 establishes the recipe dependency, and then a custom sbuild should also=20 be able to pull packages from isar-apt. Did you consider this already? Hmm, Understood, but so far i didn't tried this method , i meant pull= =20 isar-apt packages in custom sbuild (SBUILD_FLAVOR), i hope this will work for my scenario, Let me try one use cases and update the=20 patch ASAP. Jan=20 --=20 Siemens AG, Technology=20 Linux Expert Center=20 ------=_Part_90846_704296951.1702358292591 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

On Tuesday, December 12, 2023 at 10:38:0= 8=E2=80=AFAM UTC+5:30 Jan Kiszka wrote:
On 12.12.23 05:55, Srinuvasan Arjunan wrote:
>=20
>=20
> On Friday, December 8, 2023 at 7:45:06=E2=80=AFPM UTC+5:30 Jan K= iszka wrote:
>=20
> On 28.11.23 08:14, Srinuvasan Arjunan wrote:
> > From: Srinuvasan A <sr= inuv...@siemens.com>
> >
> > In present implementation we are using sbuild/schroot t= o build the
> > packages, this schroot created via sessions during pack= age build, and
> > immediatley vanish once build the packages.
> >
> > Some of the downstream projects uses this chroot at man= y
> > places for doing some postprocessing the meta data base= d on the
> chroot
> > path, but unfortunately we cannot refer this path due t= o creating the
> > chroot via session.
>=20
> Can you be more specific in the use cases?
>=20
>=20
> =C2=A0 =C2=A0In our case we need to install the custom packages = in buildchroot,
> =C2=A0 =C2=A0once we installed the isar-apt packages, later we r= efer those and do some
> =C2=A0 =C2=A0postprocessing before image creation.
>=20
>=20
> =C2=A0 =C2=A0ISAR provides the provision to pre-install the=C2= =A0 upstream packages
> =C2=A0 =C2=A0not custom packages and this chroot will be used as= a base chroot to
> =C2=A0 =C2=A0=C2=A0build the packages or imager_run, hence SBUIL= D_FLAVOR would not be
> =C2=A0 =C2=A0helpful atleast for my scenario.
>=20
>=20
> =C2=A0 =C2=A0SBUILD_CHROOT_PREINSTALL_EXTRA variable directly in= stall the upstream=C2=A0
> =C2=A0 =C2=A0packages in rootfs not custom packages.
>=20

Understood the use case now - but then why not fixing/enhancing the
existing mechanism? We likely need some SBUILD_CHROOT_INSTALL_EXTRA t= hat
establishes the recipe dependency, and then a custom sbuild should al= so
be able to pull packages from isar-apt. Did you consider this already= ?

=C2=A0 =C2=A0 Hmm, Understood, but so f= ar i didn't tried this method , i meant pull isar-apt packages in custom sb= uild=C2=A0 (SBUILD_FLAVOR), i hope this
=C2=A0 =C2=A0will work fo= r my scenario,=C2=A0 Let me try one use cases and update the patch ASAP.


Jan

--=20
Siemens AG, Technology
Linux Expert Center

------=_Part_90846_704296951.1702358292591-- ------=_Part_90845_1454962465.1702358292591--