From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6543174714398867456 X-Received: by 10.80.245.249 with SMTP id x54mr2365794edm.3.1523451580028; Wed, 11 Apr 2018 05:59:40 -0700 (PDT) X-BeenThere: isar-users@googlegroups.com Received: by 10.80.192.24 with SMTP id r24ls1113322edb.3.gmail; Wed, 11 Apr 2018 05:59:39 -0700 (PDT) X-Google-Smtp-Source: AIpwx4/8j5YTWbMJ8sG73l3Xm8kh0FnK+RJdWume9DO7JoN3Wm32lh2AykdxVr+ReIY7H7WK9iDm X-Received: by 10.80.165.8 with SMTP id y8mr2348932edb.11.1523451579596; Wed, 11 Apr 2018 05:59:39 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1523451579; cv=none; d=google.com; s=arc-20160816; b=SZrl7H03q4/jEm98CKSPeEoBzfbt1fTEn+AJyMlw/twqHksILXQ6EKz2nDUquyiAR1 MjRrxzDs+LZCCOWlPnZlFtr2hRxCHmLI+LwzTHMhwAwKt53oRkTH5C/XN5MKGckbt0WO 4C3Z8jSwMDyJgS5vhJk6mu69TnxFR4FC21RlR894MkCoB5RuPlv2URnkadFBHHN5PN5u ZcgoNr+08UBu9QueFlnNMbUcnSKRuQCHpvqjtXzGwFLJpFAT3Fz5aj6B7PgPzHT48USi eWmiBeWC9sxGuX9oE1EmhedRGtOLpU3ME7VvttDMYmWRtU6UR+5kPDDkQ833x8mj1sHo SKMA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:content-language:mime-version:user-agent :date:message-id:subject:from:to:arc-authentication-results; bh=qtMD/pOViekopwiV81Aps29naC2sOrDfU+Y7VemwoAo=; b=szW9GITeyx67kEvvPw1RehQepIsGNdzE/GZNpvRzd/J+CYdzGiNBbAx/ZMxmdLnjlG /wihzNE+OE4G4+LkK5Ctrdc2t8qx8kPmb9ims9EMDP/FVPwnyVk48gtPOUBWHxhNeSAf jtl4b8WZajGJydoao31YoYPGXY+6cBTQfLiVDZGdplQ+qadcKagaicxctfpdAxW4tA2K kntHPOSYWBEvU/09tX32ERK696tc7DGdBdem/JeTamPQsFcDxi8QpJF0ZvxpoCulDCqX ATEYTwmxs8xOevfVaSVrkoan8QDqBF9szP6XSO3tZCuLkzOgxDKCPL9BFsaMO/A568HD i6jg== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=pass (google.com: domain of claudius.heine.ext@siemens.com designates 192.35.17.2 as permitted sender) smtp.mailfrom=claudius.heine.ext@siemens.com Return-Path: Received: from thoth.sbs.de (thoth.sbs.de. [192.35.17.2]) by gmr-mx.google.com with ESMTPS id y22si81910edm.0.2018.04.11.05.59.39 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 11 Apr 2018 05:59:39 -0700 (PDT) Received-SPF: pass (google.com: domain of claudius.heine.ext@siemens.com designates 192.35.17.2 as permitted sender) client-ip=192.35.17.2; Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of claudius.heine.ext@siemens.com designates 192.35.17.2 as permitted sender) smtp.mailfrom=claudius.heine.ext@siemens.com Received: from mail2.sbs.de (mail2.sbs.de [192.129.41.66]) by thoth.sbs.de (8.15.2/8.15.2) with ESMTPS id w3BCxcKI002974 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Wed, 11 Apr 2018 14:59:39 +0200 Received: from [139.25.69.226] (linux-ses-ext02.ppmd.siemens.net [139.25.69.226]) by mail2.sbs.de (8.15.2/8.15.2) with ESMTP id w3BCxcfF032714 for ; Wed, 11 Apr 2018 14:59:38 +0200 To: isar-users From: Claudius Heine Subject: 'IMAGE_FEATURES' in Isar Message-ID: <8cc3abfe-de1b-fb63-b58d-7a73561c11ae@siemens.com> Date: Wed, 11 Apr 2018 14:59:38 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-TUID: +KJF2xlwvRBl Hi, 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. 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 - Removal of apt and other possible reduction tasks - ??? other ideas? 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. Of course most images created by Isar will have a kernel, so I also see that reason for including one. The other question might be if having a kernel should be implemented as a IMAGE_FEATURE or rather a setting in the machine.conf? In the simplest solution maybe something like: machine.conf: KERNEL='yes' while the multiconfig specifies which kernel to use and the distro what kernels are available, like it does today. What do you think? Thanks, 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