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).

>  
>
>
>     >
>     > 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.

Jan

--
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux