From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6543174714398867456 X-Received: by 10.223.226.15 with SMTP id j15mr167478wri.10.1523547318745; Thu, 12 Apr 2018 08:35:18 -0700 (PDT) X-BeenThere: isar-users@googlegroups.com Received: by 10.28.148.129 with SMTP id w123ls960020wmd.4.gmail; Thu, 12 Apr 2018 08:35:18 -0700 (PDT) X-Google-Smtp-Source: AIpwx48z5IXZmk7LsPKyChg9C2jXBtaIu9XrxIeiLwFuk2jXa0FhVI8HUUsOM5LRxL7OEx1JiYyf X-Received: by 10.28.118.4 with SMTP id r4mr139367wmc.16.1523547318308; Thu, 12 Apr 2018 08:35:18 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1523547318; cv=none; d=google.com; s=arc-20160816; b=T4XCxCnHV/mwF74HcWcIMur3xEKpJUO2NlMjLpWgfFmNIBORBuTarFDaznnIEnMz7t bzNrofIhuEu5Nc8Z17Oj/TIdVQgmXiCk1nbjAWFhuZuDOfhQmi6iLHVa0DmgDh5nHpya OhEJzmumVTNeXGYx6VabLyZef2kSs1OxkLMv8bAIMcvuetcBCYA/Q3lj/YYRYDugJBMl /knjPrZ9niH+yo7NHNiiYuJvGcsgKFr5gxN5oItSayaQWJHa+UwS9dfxKHcJkPn38io9 yRk6T5eMt9O/PxWjNLXozuzeAPJRJSxqXzQxK/+m8pPg7uN1RexI6fpq87b6Wx80uUko jL5w== 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 :arc-authentication-results; bh=rew1CmJdL7p15J0yhskIi9LpbnSWsuCR4pHAShx+wLU=; b=oNv9L4pu9M1UTyMhdcxEkC6nGwMdO2OZbL8hUVrWhQlSPG+zpBABMOoW4VZMHcGBok mSIoUAEPrJrqdM8LrTlox6XR/omUoxno2s76WNsUxs21T8QQIBnMnZmiiEexVTuZzWwY oajNL0fV40tHVKiEhWlj0ZhbG03My2ZJNGSY7A1oSkBf1hnq6rsiHrQ/etzaNIZtNDIp X4Xvl5HPtjAOtJWmG42DZogle8nNcmaGWNnlQ9WQeVVip5PubVC+/rjOniPP6wxRz5eC PEbuKIYqdUi9nz0PWEFiGsNPS3S4QLJrpJiPcQwTJpDBhDIiCPzQQQXKTbqEGG8DdHNQ uKkA== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=pass (google.com: domain of claudius.heine.ext@siemens.com designates 192.35.17.14 as permitted sender) smtp.mailfrom=claudius.heine.ext@siemens.com Return-Path: Received: from david.siemens.de (david.siemens.de. [192.35.17.14]) by gmr-mx.google.com with ESMTPS id u27si167523wrf.1.2018.04.12.08.35.18 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 12 Apr 2018 08:35:18 -0700 (PDT) Received-SPF: pass (google.com: domain of claudius.heine.ext@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 claudius.heine.ext@siemens.com designates 192.35.17.14 as permitted sender) smtp.mailfrom=claudius.heine.ext@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 w3CFZHoN005355 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Thu, 12 Apr 2018 17:35:17 +0200 Received: from [139.25.69.226] (linux-ses-ext02.ppmd.siemens.net [139.25.69.226]) by mail1.sbs.de (8.15.2/8.15.2) with ESMTP id w3CFZHpt026790 for ; Thu, 12 Apr 2018 17:35:17 +0200 Subject: Re: 'IMAGE_FEATURES' in Isar To: isar-users References: <8cc3abfe-de1b-fb63-b58d-7a73561c11ae@siemens.com> <20180412142614.GE6864@yssyq.radix50.net> From: Claudius Heine Message-ID: <9e911992-c9ff-647d-ff04-2a400677d6e9@siemens.com> Date: Thu, 12 Apr 2018 17:35:17 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <20180412142614.GE6864@yssyq.radix50.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-TUID: 4+DQ3EeBnmSd Hi Baurzhan, On 2018-04-12 16:26, Baurzhan Ismagulov wrote: > On Wed, Apr 11, 2018 at 02:59:38PM +0200, Claudius Heine wrote: >> since we discussed that we might want to implement 'IMAGE_FEATURES' in Isar >> in order to support images without kernel, I wanted to start some >> brainstorming about what this should be used in other cases. > > Why not just generate without the kernel by default, adding one (possibly via a > virtualized name) to specific images as a dependency / IMAGE_INSTALL? IMHO, > the logic of adding instead of removing is more in the spirit of bitbake. I just posted an idea to solve this in a simple way, that shows how I would have done it. Alex brought up the IMAGE_FEATURES idea and this thread just discuss it and to answer the questions: What else could IMAGE_FEATURES be used for? And does it make sense to use it to specify if the kernel should be part of the image or not? >> While discussing that with Jan we came some ideas that would be nice to be >> implemented as features: >> >> - Cleanup steps like localepurge, and apt-get clean > > Just do it always, as in your patches? You meant the '*-configscripts.sh'? AFAIK the purpose is to try to move most of this stuff out of there and into a 'system-setup-package' of sorts. At lease for all of those things, that don't require doing it at the end of everything. The rest of those steps (like those cleanup commands) should be split up into smaller scripts each with just one task and then trigger them via IMAGE_FEATURES after all packages were installed. Then the difference between raspbian and debian might just be some different entries in the IMAGE_FEATURES (or DISTRO_FEATURES) variable. At least thats my current idea here. >> - Removal of apt and other possible reduction tasks > > Additional recipe some images depend on? Removal of apt and other reduction steps should be done after all packages are installed using apt. Doing that in some other recipe/debian package just doesn't work. >> About installing the kernel: It could be possible to have some 'nokernel' >> feature, but I am currently not sure if that is right. >> Debians 'debootstrap' does not install a kernel per default, so if we now >> have a kernel per opt-out we are a bit in a conflict with the >> 'Debian-Way-Of-Life' IMO. Because there even the kernel is a opt-in package. > > I agree. Specify explicitly where needed, not remove some enforced default. > There are systems where the kernel is installed in a separate partition and > isn't contained in the rootfs. > > >> Of course most images created by Isar will have a kernel, so I also see that >> reason for including one. > > Not a problem with explicit addition. > > >> The other question might be if having a kernel should be implemented as a >> IMAGE_FEATURE or rather a setting in the machine.conf? > > We already have it in IMAGE_INSTALL for isar-image-base. Doesn't it work if the > kernel is removed from there? This is how I do it in the current "Optional kernel" patchset. regards, Claudius -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-54 Fax: (+49)-8142-66989-80 Email: ch@denx.de