public inbox for isar-users@googlegroups.com
 help / color / mirror / Atom feed
From: Srinuvasan Arjunan <srinuvasanasv@gmail.com>
To: isar-users <isar-users@googlegroups.com>
Subject: Re: [RFC][PATCH] Add sbuildchroot class
Date: Mon, 11 Dec 2023 21:18:12 -0800 (PST)	[thread overview]
Message-ID: <33f90a6e-1bc5-4a5b-ba2d-daa645220854n@googlegroups.com> (raw)
In-Reply-To: <ba605a3e-b029-4d4e-80fc-591a9e39898e@siemens.com>


[-- Attachment #1.1: Type: text/plain, Size: 2033 bytes --]



On Tuesday, December 12, 2023 at 10:38:08 AM UTC+5:30 Jan Kiszka wrote:

On 12.12.23 05:55, Srinuvasan Arjunan wrote: 
> 
> 
> On Friday, December 8, 2023 at 7:45:06 PM UTC+5:30 Jan Kiszka wrote: 
> 
> On 28.11.23 08:14, Srinuvasan Arjunan wrote: 
> > From: Srinuvasan A <srinuv...@siemens.com> 
> > 
> > In present implementation we are using sbuild/schroot to build the 
> > packages, this schroot created via sessions during package build, and 
> > immediatley vanish once build the packages. 
> > 
> > Some of the downstream projects uses this chroot at many 
> > places for doing some postprocessing the meta data based on the 
> chroot 
> > path, but unfortunately we cannot refer this path due to creating the 
> > chroot via session. 
> 
> Can you be more specific in the use cases? 
> 
> 
>    In our case we need to install the custom packages in buildchroot, 
>    once we installed the isar-apt packages, later we refer those and do 
some 
>    postprocessing before image creation. 
> 
> 
>    ISAR provides the provision to pre-install the  upstream packages 
>    not custom packages and this chroot will be used as a base chroot to 
>     build the packages or imager_run, hence SBUILD_FLAVOR would not be 
>    helpful atleast for my scenario. 
> 
> 
>    SBUILD_CHROOT_PREINSTALL_EXTRA variable directly install the upstream  
>    packages in rootfs not custom packages. 
> 

Understood the use case now - but then why not fixing/enhancing the 
existing mechanism? We likely need some SBUILD_CHROOT_INSTALL_EXTRA that 
establishes the recipe dependency, and then a custom sbuild should also 
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 
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 
patch ASAP.



Jan 

-- 
Siemens AG, Technology 
Linux Expert Center 


[-- Attachment #1.2: Type: text/html, Size: 2840 bytes --]

      reply	other threads:[~2023-12-12  5:18 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-11-28  7:14 Srinuvasan Arjunan
2023-12-08 14:13 ` Srinuvasan Arjunan
2023-12-08 14:15 ` Jan Kiszka
2023-12-12  4:55   ` Srinuvasan Arjunan
2023-12-12  5:08     ` Jan Kiszka
2023-12-12  5:18       ` Srinuvasan Arjunan [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=33f90a6e-1bc5-4a5b-ba2d-daa645220854n@googlegroups.com \
    --to=srinuvasanasv@gmail.com \
    --cc=isar-users@googlegroups.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox