From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6790334981638979584 X-Received: by 2002:a2e:b5cb:: with SMTP id g11mr2787604ljn.210.1581012560989; Thu, 06 Feb 2020 10:09:20 -0800 (PST) X-BeenThere: isar-users@googlegroups.com Received: by 2002:a05:6512:3b2:: with SMTP id v18ls1069805lfp.8.gmail; Thu, 06 Feb 2020 10:09:20 -0800 (PST) X-Google-Smtp-Source: APXvYqyMYclrx+18qE3IPGwpKxXaBIgpe1iWFLO03bYa4sn74pD7Pp4IWWrlORwROzHE5//yP8AN X-Received: by 2002:a19:cb95:: with SMTP id b143mr2472352lfg.158.1581012559774; Thu, 06 Feb 2020 10:09:19 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1581012559; cv=none; d=google.com; s=arc-20160816; b=TgNZkYTPURVNcqmDCZvHBXtxl/0r30zGpZiScTG1uz3ddPTOXPynzsqb2qnjEfJ94m tb4Iy9zqt5tisKhZVnnI6rpX8cxPeOtzCMuifyzswVIl3pKrQDlQ2//GFQtWdZ83hgE8 Kcbe2kcS2w1pxm7Zj7L/57t2Dwha6I/+CbEg2vhCDb7GE75C8YBduKc5G6HVuEpug3gz v2mR19FI3pYbTp0BE7nsyVFlGBrenEypWSZ1KYeybRX3J1VyVVUbcphzg3HfcNXUdzRF TtMzxI9I2hlUiubltZmrzU+ph1Rm4oGYWUYABH1AVFam5IYHmiB4XdxjQdrIJM3ThHmi iQOg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:content-language:in-reply-to:mime-version :user-agent:date:message-id:from:references:to:subject; bh=q7a/EhgRj4nolgPUF7mKRJVUsWW2PsNfXFKh6gsZRMI=; b=i298OIyIvcjfMuWiIwAqGm+VKebcVlm6l574Im1/ERkctKl0xcW8E2jskwC3PRZ/Nb Cj0GfuMmWf+Gvn9Ro33jr9zJ3NMHFZ+2PtP8nD96VfrvMzA797d6RM7pQfBUIFtIVKgy KHA0MIoX2Cfs7+Nw1kFuwRIFY+oqWNGETRdgvvyTXT/y5ERt+DGMkt+xk1ofr+3OhMzb SyP/P7nSyyWWMpLyJ8tpAAQB9VmvspYhXoW7leuUlI2FK2z3EjI8ix1bkLOkfMIX8rx4 QYZsW7jp0qC86b2/ezotwU+RQxpR8erat1yooe5uQ1aFG+qdlCtNrZQdTDINwFNfIgEk JPLA== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=pass (google.com: domain of jan.kiszka@siemens.com designates 192.35.17.14 as permitted sender) smtp.mailfrom=jan.kiszka@siemens.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=siemens.com Return-Path: Received: from david.siemens.de (david.siemens.de. [192.35.17.14]) by gmr-mx.google.com with ESMTPS id o24si8126lji.4.2020.02.06.10.09.19 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 06 Feb 2020 10:09:19 -0800 (PST) Received-SPF: pass (google.com: domain of jan.kiszka@siemens.com designates 192.35.17.14 as permitted sender) client-ip=192.35.17.14; Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of jan.kiszka@siemens.com designates 192.35.17.14 as permitted sender) smtp.mailfrom=jan.kiszka@siemens.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=siemens.com Received: from mail2.sbs.de (mail2.sbs.de [192.129.41.66]) by david.siemens.de (8.15.2/8.15.2) with ESMTPS id 016I9I8X015783 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 6 Feb 2020 19:09:18 +0100 Received: from [139.25.68.37] ([139.25.68.37]) by mail2.sbs.de (8.15.2/8.15.2) with ESMTP id 016I9H49009316; Thu, 6 Feb 2020 19:09:17 +0100 Subject: Re: [PATCH] rootfs: Make rootfs_postprocess_finalize the last step To: vijai kumar , isar-users References: <20200206140631.7928-1-Vijaikumar_Kanagarajan@mentor.com> <48d46a27-295c-a4d4-ea72-0ea2a1791809@siemens.com> <27f93d3b-c883-43fb-9532-24dd1750226a@googlegroups.com> From: Jan Kiszka Message-ID: <201722b6-2a98-ca90-30f4-287205d4cedc@siemens.com> Date: Thu, 6 Feb 2020 19:09:17 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: <27f93d3b-c883-43fb-9532-24dd1750226a@googlegroups.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-TUID: JCTCOWfzV69L 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