From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6790334981638979584 X-Received: by 2002:adf:dd0b:: with SMTP id a11mr10276236wrm.150.1581444468655; Tue, 11 Feb 2020 10:07:48 -0800 (PST) X-BeenThere: isar-users@googlegroups.com Received: by 2002:a1c:6385:: with SMTP id x127ls4074728wmb.2.gmail; Tue, 11 Feb 2020 10:07:47 -0800 (PST) X-Google-Smtp-Source: APXvYqyhxaW8316uCiqo0g2RujB6xKQH8NPL0exZccx8Gdj6ujMKnYDrteLBcUEImlBQwl9zZkc4 X-Received: by 2002:a1c:7205:: with SMTP id n5mr7216052wmc.9.1581444467839; Tue, 11 Feb 2020 10:07:47 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1581444467; cv=none; d=google.com; s=arc-20160816; b=V3Y4vMiMPCYPek9qcZfSU19RP7Dxbp1eDj2gDwcCkAAQ74CAyscuSzmV2lb9AJVLrM ErMR00EBg4ODWuZIe6sEjx7bMLfe/J0XhhdnNLo4t+oNQFY3FrEto7DiogdzKPSg0Yt6 0oNrQsOoP5qfcIUon+QJO4Ri1RFaHWvZpIgP89V+q4Cs2JYt6Ajg1vmyHGMfrcK8D6xE 5m5vrrqVsuuiXIYCHUPr5QIBHK+/qH9bVwVd4Ux2WuUh3br1hYRFYzhUleoyKT6t8ujM GNwKAPfqfEM4z0HFSk4aPQ9zR3WEc/xvFIgXUF/jXSlxPWVxa/enLWx3u/4IF1acq0dd WxMQ== 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=tjNAda1AeXoPsal/6o/yX3//EuuOIQB4kqbYOzYexV0=; b=WUEIUUVcPh1KHp7R72KHM0iTJIQLYCdCo00+BDRJH/wl7EumT/cg736QvPmuWA2xbA 33RsxDvmXzwHIndEu5PQ9gH0qvGH4omPGcA7zDV1YSDBXoJq9rMJVqX2WScJb+wnwTdz xYO+CvB6EZqyL9NKEwlj5gqGg4wea83QGegmVZjAnxe6nkNCtiYu1jWmQ0WQZJO5U+Ld XMTrZyBJ0zUwP1tjST/td6M2RAOlRGPsw17F5mZohQjZZG+E+UzLMy59rSYL9r9Myu03 0erKKoP3RWKJM7Td+aEsO8xAFNjx0kVKW8486JBwqYdrg/Q++6vpsaVTtDhigqY/JPzX MOlg== 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 m2si192860wmi.3.2020.02.11.10.07.47 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 11 Feb 2020 10:07:47 -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 mail1.sbs.de (mail1.sbs.de [192.129.41.35]) by david.siemens.de (8.15.2/8.15.2) with ESMTPS id 01BI7knL013781 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 11 Feb 2020 19:07:46 +0100 Received: from [139.25.68.37] ([139.25.68.37]) by mail1.sbs.de (8.15.2/8.15.2) with ESMTP id 01BI7kug003379; Tue, 11 Feb 2020 19:07:46 +0100 Subject: Re: [PATCH v2] rootfs: Make rootfs finalize a separate task To: vijai kumar , isar-users References: <20200210053753.32341-1-Vijaikumar_Kanagarajan@mentor.com> <20200211123841.1a72daed@md1za8fc.ad001.siemens.net> From: Jan Kiszka Message-ID: <25b9cca0-3fb3-14c5-f7be-c25d20b74d3e@siemens.com> Date: Tue, 11 Feb 2020 19:07:45 +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: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-TUID: saX5OAdMwhNO On 11.02.20 15:14, vijai kumar wrote: > > > On Tuesday, February 11, 2020 at 5:08:43 PM UTC+5:30, Henning Schild wrote: > > This patch will allow you to keep your apt downloading feature > downstream for yourself. I would say - propose it again together with > the feature. > > > I can push that feature if it is needed upstream, which I doubt, since I > don't vision an upstream use-case where-in one would need to > download all the sources. Providing an "all sources for my target" target is surely an upstream topic. > > Also, It would need your base-apt series. > > > In fact if the feature was in Isar the whole problem would go away, > unless you have more postprocess functions. > > > Yes. We have one per se for our QA layer. To export dpkg status file to > deploy directory. This will be used by debsecan. > > > We discussed postprocessing a couple of times, it is really bad style > and enabling it as a feature that is easy to use we provoke downstream > layers making mistakes by implementing their stuff as such postprocess > functions. > > > I see the ability to add custom post-processing as a useful feature. > Not sure if anyone actually uses them in their downstream layers. It is > good to have if you know what you are doing. > > As long as this provision is there, people would use it. If we feel that > this > provision is unnecessary and would lead to issues, well, we could go > ahead and remove it. Even if that hooking mechanism is a two-sided sword, there is already inside Isar value in defining a clean environment for the hooks and ensuring that this contains all mounts until the last hook is done. So, this patch can only be seen as the messenger, not to be shot for downstream misuse of the overall feature. Jan -- Siemens AG, Corporate Technology, CT RDA IOT SES-DE Corporate Competence Center Embedded Linux