From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6617812835611181056 X-Received: by 2002:a2e:a287:: with SMTP id k7-v6mr1115005lja.12.1540903299905; Tue, 30 Oct 2018 05:41:39 -0700 (PDT) X-BeenThere: isar-users@googlegroups.com Received: by 2002:a2e:350e:: with SMTP id z14-v6ls50410ljz.25.gmail; Tue, 30 Oct 2018 05:41:37 -0700 (PDT) X-Google-Smtp-Source: AJdET5fxU5bBQMqbUYKcqjzS7iTXwGvEnzXiSsmMzBh9sMXDqyxjv5BNyCNun4iJDKHetgjsH6Dh X-Received: by 2002:a2e:5c43:: with SMTP id q64-v6mr1730148ljb.2.1540903297173; Tue, 30 Oct 2018 05:41:37 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1540903297; cv=none; d=google.com; s=arc-20160816; b=P0XSD6O2MNHVFq2HI6lKLRqmoS/78ETu+D2tqt3ThPDzX8qdWBsKK/YaP02cnzwuRF FPafEZ/OKWHJfi7wZUieH3JiZX/UAy/pImcbaWgC/yEAuhlk0unKa6cwzxUAFaghvte9 mLCzL96uCCUa+woUhzRth3x2CDGBoPmoYBaPF0dX+PUy4X+XjXpV8IVIpeB/pqYJe2Gw 27BUgyzir4tVZCeUmpuiktf3wFrw2zh752qCQt3P6w8ikgeP6jEBqh3kB85PEY9i/A/K bQj4SM9CxKOuQv4XwmcGBlt48WhWKjLTTpK5jZWxH/IMl37B60gQbJSGEfUJlnzs1M5F bkdw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date; bh=FP5Wfpc8Wv1Wy0DhwerCLohFOHZCp6WgZxURCwDYO10=; b=Rmia55tKQO0yQbx1yzgRlNOiKdigH0G0poyijV+ERmlDIKmQ67swgnz8CR3M8pLykG 8yp8l9ea791VEHtw4i0/2BrmycRdQKwupbA+du6apMZEEjS2pI/fYQIwLPb3ckXqCqm2 pEbkBljAl2kKTV7XNCJw8/X1cRnyCZ0nLo8LTzxoMm2L4m+5aJJCUsh0DetgT+jNiajr FQk0o3BtbrjBpFKdt63XvGOu8jxoYE2wsqBMo1oMgr1HjZWMAGXaWrr8OAYA8Kl505n+ 0i+udaTZWCSsJcJ1SIVMMBiW5wzE25YIAf8vauMZ3sI0RMWCCFuDGOxBsVPDBIg9J1Dv s6fg== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=pass (google.com: domain of henning.schild@siemens.com designates 192.35.17.28 as permitted sender) smtp.mailfrom=henning.schild@siemens.com Return-Path: Received: from goliath.siemens.de (goliath.siemens.de. [192.35.17.28]) by gmr-mx.google.com with ESMTPS id z13-v6si658854ljb.4.2018.10.30.05.41.36 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 30 Oct 2018 05:41:37 -0700 (PDT) Received-SPF: pass (google.com: domain of henning.schild@siemens.com designates 192.35.17.28 as permitted sender) client-ip=192.35.17.28; Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of henning.schild@siemens.com designates 192.35.17.28 as permitted sender) smtp.mailfrom=henning.schild@siemens.com Received: from mail1.sbs.de (mail1.sbs.de [192.129.41.35]) by goliath.siemens.de (8.15.2/8.15.2) with ESMTPS id w9UCfabZ016287 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 30 Oct 2018 13:41:36 +0100 Received: from md1pvb1c.ad001.siemens.net (md1pvb1c.ad001.siemens.net [139.25.68.40]) by mail1.sbs.de (8.15.2/8.15.2) with ESMTPS id w9UCfZJS031380 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 30 Oct 2018 13:41:36 +0100 Date: Tue, 30 Oct 2018 13:41:54 +0100 From: Henning Schild To: "Hombourger, Cedric" Cc: "isar-users@googlegroups.com" Subject: Re: [PATCH 0/4] add support for OE's ROOTFS_*_COMMAND Message-ID: <20181030134154.7adc8bf9@md1pvb1c.ad001.siemens.net> In-Reply-To: References: <20181029161303.7410-1-Cedric_Hombourger@mentor.com> <20181029174520.1fd028fe@md1pvb1c.ad001.siemens.net> <20181030102546.6f84f930@md1pvb1c.ad001.siemens.net> X-Mailer: Claws Mail 3.15.0-dirty (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-TUID: aGrcw5sXPywW Am Tue, 30 Oct 2018 11:02:49 +0000 schrieb "Hombourger, Cedric" : > prelink or ima would not be considered hacks or kludges but > definitely things you apply on the complete file-system. I am failing > to understand your resistance... Yocto is no different, have you > looked at their uses of the pre/post rootfs commands? They also have > packages and apply package level optimizations in their recipes (and > we also should) but the aforementioned examples do not fit this > category at all The resistance comes from a mechanism without a user, a mechanism that can (and will) be abused. First hit on google ... https://stackoverflow.com/questions/36863682/yoctos-rootfs-postprocess-command-not-working Once we have the use-case we can find the right mechanism or add a new one. Have a look at IMAGE_TRANSIENT_PACKAGES. I think prelink could be done with an apt hook as well, so you have a raw pkg depending on prelink and shipping the apt config. Henning > Looking forward to your response > > Sent from a mobile > > > On 30 Oct 2018, at 10:26, Henning Schild > > wrote: > > > > Am Mon, 29 Oct 2018 16:55:10 +0000 > > schrieb "Hombourger, Cedric" : > > > >> Sure thing. This will allow us to generate license/package > >> manifests like Yocto does amongst other things (eg rootfs > >> optimization functions). In other words system wide tweaks. The > >> former is the subject of an upcoming patch series. > > > > rootfs optimization functions sounds very much like hacking your way > > around the golden rule i mentioned earlier. And since people will > > abuse such a mechanism it is best to not introduce it. > > > > For the license manifests ... that sounds interesting indeed but > > will likely not require such a generic mechanism. > > > > I guess concrete examples would be useful. But looking just at the > > mechanism without such examples, i am strongly against merging that > > code. > > > > Henning > > > >> Sent from a mobile > >> > >>> On 29 Oct 2018, at 17:45, Henning Schild > >>> wrote: > >>> > >>> Hey, > >>> > >>> could you please elaborate on why this is needed and what you want > >>> to do with it? I suspect there are already other ways of doing > >>> what you might want to do. > >>> > >>> One golden rule is that _everything_ inside the rootfs comes from > >>> a .deb package. If you need to execute scripts, go for post/pre > >>> inst etc. > >>> > >>> Henning > >>> > >>> Am Mon, 29 Oct 2018 17:12:59 +0100 > >>> schrieb Cedric Hombourger : > >>> > >>>> OpenEmbedded allows custom functions to be called at various > >>>> stages of the root file-system generation process. Add similar > >>>> capabilities to Isar. > >>>> > >>>> Cedric Hombourger (4): > >>>> isar-image-base: introduce and use isar-image class > >>>> isar-image: refactor do_rootfs() > >>>> base: add 'lib' folder of each layer to python's module search > >>>> path isar-image: add support for OE's ROOTFS_*_COMMAND > >>>> > >>>> doc/user_manual.md | 43 > >>>> +++++++++++ meta-isar/classes/isar-image.bbclass | > >>>> 89 ++++++++++++++++++++++ .../files => > >>>> conf/distro}/debian-configscript.sh | 0 .../files => > >>>> conf/distro}/raspbian-configscript.sh | 0 > >>>> meta-isar/recipes-core/images/isar-image-base.bb | 57 > >>>> +------------- > >>>> meta/classes/base.bbclass | 4 + > >>>> meta/lib/oe/utils.py | 11 +++ 7 > >>>> files changed, 150 insertions(+), 54 deletions(-) create mode > >>>> 100644 meta-isar/classes/isar-image.bbclass rename > >>>> meta-isar/{recipes-core/images/files => > >>>> conf/distro}/debian-configscript.sh (100%) rename > >>>> meta-isar/{recipes-core/images/files => > >>>> conf/distro}/raspbian-configscript.sh (100%) create mode 100644 > >>>> meta/lib/oe/utils.py > >>> > >