From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6617812835611181056 X-Received: by 2002:a67:8984:: with SMTP id l126mr17164953vsd.17.1540903563781; Tue, 30 Oct 2018 05:46:03 -0700 (PDT) X-BeenThere: isar-users@googlegroups.com Received: by 2002:ab0:7054:: with SMTP id v20ls1990097ual.0.gmail; Tue, 30 Oct 2018 05:46:03 -0700 (PDT) X-Google-Smtp-Source: AJdET5ffgqYYPo5QfdKSAZsea7zlHTs2ftGvWfKlo96Oc2r4lqApWLZV40+pWs3C0Ur7lSlIh+9/ X-Received: by 2002:ab0:59f0:: with SMTP id k45mr16526066uad.15.1540903563438; Tue, 30 Oct 2018 05:46:03 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1540903563; cv=none; d=google.com; s=arc-20160816; b=Di58paaP4aHNpcRVCDowzWK9W3zo5NUf7qoECNeTXEScookuL/Mkd2P6Mi3oncNggN 9/0bIH1mncuTHDY2KuHyqdrg8aeUfoKNqek8i9uQPfHaZD5teXVo9B8LBMxIjeoqISXG YWttCDsHelT9EPNPmPHxqb4J7Ge75UDiUCQpeVSVh5eDdtyJ/ki93ry4WNsf9RCY6if+ RpoQRlyhSQya9bxjpC7ul9N5Ze2IDKDSs6xlC5entHxHjRXSVCckw99strC1c0Krteay kdkBsljifxysGavfO83NiOlNyp41YxJFIIovtK9mq62JoIrsAHvPXD4of8j/Q9SP/gRX f58A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=mime-version:content-transfer-encoding:content-language :accept-language:in-reply-to:references:message-id:date:thread-index :thread-topic:subject:cc:to:from; bh=BmNNVAhvh9sqsCLa3CF7bFv9F6UXEqQE7kT5PouxRPI=; b=suE7nVoS+MaFLJZqJWjw1K0BTTeEDjfg94XGCTtqtHobTAnfyzH9ChV7yecFJVmLKn mEmzHHsLYqH5XEwAbuoiC05DuZveR371YBvuoKNMTJbD2VHlIZC3+kGdHBA63pOX4Ir0 DftUUnehG6c6JQa5tE34XZELYLBnrWkri+yFn4Sh0P0TcDVwpFWhAxg0TFFjd9cAnPaG HDlXm6rhSaW9NezQXxv+7E7bH5/i+urPSbwL8SwNPZMjCps6OhOv8Rp4BjOEF2J8prli 4IYM9m3Fww3RObGcBp+4hyyagG0ryhG2NDBSbkxXByzZ2yvCGzVTvk0ES3A5xdm2xt5j 2v0Q== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=pass (google.com: domain of cedric_hombourger@mentor.com designates 192.94.38.131 as permitted sender) smtp.mailfrom=Cedric_Hombourger@mentor.com Return-Path: Received: from relay1.mentorg.com (relay1.mentorg.com. [192.94.38.131]) by gmr-mx.google.com with ESMTPS id g126si1019110vke.0.2018.10.30.05.46.03 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 30 Oct 2018 05:46:03 -0700 (PDT) Received-SPF: pass (google.com: domain of cedric_hombourger@mentor.com designates 192.94.38.131 as permitted sender) client-ip=192.94.38.131; Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of cedric_hombourger@mentor.com designates 192.94.38.131 as permitted sender) smtp.mailfrom=Cedric_Hombourger@mentor.com Received: from nat-ies.mentorg.com ([192.94.31.2] helo=svr-ies-mbx-01.mgc.mentorg.com) by relay1.mentorg.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-SHA384:256) id 1gHTPF-0007CD-Bm from Cedric_Hombourger@mentor.com ; Tue, 30 Oct 2018 05:46:01 -0700 Received: from svr-ies-mbx-02.mgc.mentorg.com (139.181.222.2) by svr-ies-mbx-01.mgc.mentorg.com (139.181.222.1) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Tue, 30 Oct 2018 12:45:57 +0000 Received: from svr-ies-mbx-02.mgc.mentorg.com ([fe80::a01f:51c9:5b6c:e0c]) by svr-ies-mbx-02.mgc.mentorg.com ([fe80::a01f:51c9:5b6c:e0c%22]) with mapi id 15.00.1320.000; Tue, 30 Oct 2018 12:45:57 +0000 From: "Hombourger, Cedric" To: Henning Schild CC: "isar-users@googlegroups.com" Subject: Re: [PATCH 0/4] add support for OE's ROOTFS_*_COMMAND Thread-Topic: [PATCH 0/4] add support for OE's ROOTFS_*_COMMAND Thread-Index: AQHUb6JbX2Z3TUmJC0SCPK6pN1r0/qU2bkkAgAACwEiAARTFAIAAGx7BgAAbrwCAAAEimw== Date: Tue, 30 Oct 2018 12:45:57 +0000 Message-ID: <5D9B603F-D0E3-44CB-B5C4-F5B868C64E0B@mentor.com> References: <20181029161303.7410-1-Cedric_Hombourger@mentor.com> <20181029174520.1fd028fe@md1pvb1c.ad001.siemens.net> <20181030102546.6f84f930@md1pvb1c.ad001.siemens.net> ,<20181030134154.7adc8bf9@md1pvb1c.ad001.siemens.net> In-Reply-To: <20181030134154.7adc8bf9@md1pvb1c.ad001.siemens.net> Accept-Language: en-US, en-IE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TUID: 0AhHUDgYbTEU Ok i will submit a new patch series with one or several users. The Yocto fl= ow is IMO easier to control than postinst scripts (e.g. another postinst sc= ript could alter some of the files you have just hashed for IMA).=20 Sent from a mobile > On 30 Oct 2018, at 13:41, Henning Schild wro= te: >=20 > Am Tue, 30 Oct 2018 11:02:49 +0000 > schrieb "Hombourger, Cedric" : >=20 >> 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=20 >=20 > 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-co= mmand-not-working > Once we have the use-case we can find the right mechanism or add a new > one. >=20 > 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. >=20 > Henning >=20 >> Looking forward to your response >>=20 >> Sent from a mobile >>=20 >>> On 30 Oct 2018, at 10:26, Henning Schild >>> wrote: >>>=20 >>> Am Mon, 29 Oct 2018 16:55:10 +0000 >>> schrieb "Hombourger, Cedric" : >>>=20 >>>> 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. =20 >>>=20 >>> 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. >>>=20 >>> For the license manifests ... that sounds interesting indeed but >>> will likely not require such a generic mechanism. >>>=20 >>> I guess concrete examples would be useful. But looking just at the >>> mechanism without such examples, i am strongly against merging that >>> code. >>>=20 >>> Henning >>>=20 >>>> Sent from a mobile >>>>=20 >>>>> On 29 Oct 2018, at 17:45, Henning Schild >>>>> wrote: >>>>>=20 >>>>> Hey, >>>>>=20 >>>>> 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. >>>>>=20 >>>>> 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. >>>>>=20 >>>>> Henning >>>>>=20 >>>>> Am Mon, 29 Oct 2018 17:12:59 +0100 >>>>> schrieb Cedric Hombourger : >>>>>=20 >>>>>> OpenEmbedded allows custom functions to be called at various >>>>>> stages of the root file-system generation process. Add similar >>>>>> capabilities to Isar. >>>>>>=20 >>>>>> 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 >>>>>>=20 >>>>>> doc/user_manual.md | 43 >>>>>> +++++++++++ meta-isar/classes/isar-image.bbclass | >>>>>> 89 ++++++++++++++++++++++ .../files =3D> >>>>>> conf/distro}/debian-configscript.sh | 0 .../files =3D> >>>>>> 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 =3D> >>>>>> conf/distro}/debian-configscript.sh (100%) rename >>>>>> meta-isar/{recipes-core/images/files =3D> >>>>>> conf/distro}/raspbian-configscript.sh (100%) create mode 100644 >>>>>> meta/lib/oe/utils.py=20 >>>>>=20 >>>=20 >=20