From: vijai kumar <vijaikumar.kanagarajan@gmail.com>
To: isar-users <isar-users@googlegroups.com>
Subject: Re: [PATCH] rootfs: Make rootfs_postprocess_finalize the last step
Date: Thu, 6 Feb 2020 10:28:35 -0800 (PST) [thread overview]
Message-ID: <f134a38d-ded5-451a-9e37-0c7754ed0749@googlegroups.com> (raw)
In-Reply-To: <201722b6-2a98-ca90-30f4-287205d4cedc@siemens.com>
[-- Attachment #1.1: Type: text/plain, Size: 2184 bytes --]
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
>
[-- Attachment #1.2: Type: text/html, Size: 3391 bytes --]
next prev parent reply other threads:[~2020-02-06 18:28 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-06 14:06 Vijai Kumar K
2020-02-06 17:21 ` Jan Kiszka
2020-02-06 17:47 ` vijai kumar
2020-02-06 18:09 ` Jan Kiszka
2020-02-06 18:28 ` vijai kumar [this message]
2020-02-10 5:37 ` [PATCH v2] rootfs: Make rootfs finalize a separate task Vijai Kumar K
2020-02-11 11:38 ` Henning Schild
2020-02-11 14:14 ` vijai kumar
2020-02-11 15:20 ` Henning Schild
2020-02-11 18:07 ` Jan Kiszka
2020-02-13 10:08 ` [PATCH v2 1/2] " Vijai Kumar K
2020-02-13 10:08 ` [PATCH v2 2/2] meta: cache deb srcs as part of postprocessing Vijai Kumar K
2020-02-14 5:48 ` [PATCH v3 1/2] rootfs: Make rootfs finalize a separate task Vijai Kumar K
2020-02-14 5:48 ` [PATCH v3 2/2] meta: cache deb srcs as part of postprocessing Vijai Kumar K
2020-02-14 8:19 ` Jan Kiszka
2020-02-14 8:41 ` vijai kumar
2020-02-14 8:45 ` vijai kumar
2020-03-11 7:16 ` [PATCH v3 1/2] rootfs: Make rootfs finalize a separate task vijai kumar
2020-04-01 7:25 ` vijai kumar
2020-04-01 8:19 ` Henning Schild
2020-04-01 10:29 ` vijai kumar
2020-04-03 6:50 ` vijai kumar
2020-04-03 8:30 ` Baurzhan Ismagulov
2020-04-03 8:50 ` vijai kumar
2020-04-03 13:05 ` [PATCH v4 " Vijai Kumar K
2020-04-03 13:05 ` [PATCH v4 2/2] meta: cache deb srcs as part of postprocessing Vijai Kumar K
2020-04-07 6:44 ` Jan Kiszka
2020-04-07 6:58 ` vijai kumar
2020-04-07 7:04 ` Jan Kiszka
2020-04-07 7:59 ` vijai kumar
2020-04-07 8:38 ` Jan Kiszka
2020-04-07 9:08 ` vijai kumar
2020-04-07 9:40 ` vijai kumar
2020-04-08 8:13 ` Baurzhan Ismagulov
2020-04-08 10:04 ` vijai kumar
2020-04-08 13:32 ` vijai kumar
2020-04-15 6:44 ` vijai kumar
2020-04-15 7:28 ` Jan Kiszka
2020-04-15 13:20 ` vijai kumar
2020-04-15 13:44 ` Jan Kiszka
2020-04-08 10:04 ` Henning Schild
2020-04-08 10:37 ` vijai kumar
2020-04-08 12:30 ` Henning Schild
2020-04-15 12:29 ` vijai kumar
2020-04-15 18:19 ` Henning Schild
2020-04-16 15:57 ` vijai kumar
2020-04-16 17:29 ` Henning Schild
2020-04-07 6:19 ` [PATCH v3 1/2] rootfs: Make rootfs finalize a separate task vijai kumar
2020-04-07 6:45 ` Jan Kiszka
2020-04-07 6:53 ` vijai kumar
2020-04-07 7:12 ` Baurzhan Ismagulov
2020-04-07 8:04 ` vijai kumar
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=f134a38d-ded5-451a-9e37-0c7754ed0749@googlegroups.com \
--to=vijaikumar.kanagarajan@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