From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6543174714398867456 X-Received: by 10.223.169.81 with SMTP id u75mr131039wrc.31.1523543177997; Thu, 12 Apr 2018 07:26:17 -0700 (PDT) X-BeenThere: isar-users@googlegroups.com Received: by 10.28.11.10 with SMTP id 10ls958048wml.12.canary-gmail; Thu, 12 Apr 2018 07:26:17 -0700 (PDT) X-Google-Smtp-Source: AIpwx4/Iwz6nPRB+G4Owe8dcjbsPyYOscNS0CwGFaaQ5VzIrkvuycy9jTFwiOCDK9a9JZf7a/hSf X-Received: by 10.28.53.65 with SMTP id c62mr113874wma.15.1523543177549; Thu, 12 Apr 2018 07:26:17 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1523543177; cv=none; d=google.com; s=arc-20160816; b=SW52XWu0pgesmUbW2+qgazlXsyO+ySuCWac7pxiMTTmmIiCpIyVV4hfgBjni1cZZlj ywvfzw/Y/p/aFeA0WLpCqd6nihUOMWdjVpmsrpTI9gfk/Ly2EkcAOdHuQzl9y27Y4KJI h16iXLQLFVsyDTIitUOcTB4IBYORxNcHoLdjwZsPmyzJiRDZNkhqHepojmkpJMB6HJeJ rL50NtxdmCCt0noRPhS5CEUW9MEd2XorBksZp6NfbrCLZd1iTcWc9Ks9PiDm9gQEnaSl dlbMb0xDowCw7MrFUeoIZazK1orYccvIwBCG3jRAvxdxnUhRYME8Ugx7/H/dWMR2Jml8 QP0A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=user-agent:in-reply-to:content-disposition:mime-version:references :mail-followup-to:message-id:subject:to:from:date :arc-authentication-results; bh=ZQtmz9n7tlucTXilRgHF7IVLJgahM/FIvwYPGan6Wjk=; b=Fc4oQugmlVfqpsauROlIkKLZKpgyUym0/bYKg5xgVUUN8XvwXf7oR81ytS2K0Yx1F1 zu50FkobAMrRSCyp6q/CQaROa5dc7ar9WRTaksgPGX99l2X1MsjiD9RvKxamNqIzDGWG BwIYh1jOSnzNQqqQdRYD5eA6SUy2q7kz3Ft1DTuakvSlvv+UNpabcDgIxQiE4pcrgc0Y AUYvQ0NR1Okho4aQ1ZR2peeHWWxrMr3YmzA+8yoRFFESSQziGWfGeesEFKr55rl6UXTf VnhbrXpB35HDr1drmMEQQJgsrrJfxr1qkRaUSglA0ycwJ+QMrbsrWfe9Y29eJntsKHbJ 0qjw== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=neutral (google.com: 85.214.62.211 is neither permitted nor denied by best guess record for domain of ibr@radix50.net) smtp.mailfrom=ibr@radix50.net Return-Path: Received: from aqmola.ilbers.de (aqmola.ilbers.de. [85.214.62.211]) by gmr-mx.google.com with ESMTPS id u1si119769wri.3.2018.04.12.07.26.17 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 12 Apr 2018 07:26:17 -0700 (PDT) Received-SPF: neutral (google.com: 85.214.62.211 is neither permitted nor denied by best guess record for domain of ibr@radix50.net) client-ip=85.214.62.211; Authentication-Results: gmr-mx.google.com; spf=neutral (google.com: 85.214.62.211 is neither permitted nor denied by best guess record for domain of ibr@radix50.net) smtp.mailfrom=ibr@radix50.net Received: from yssyq.radix50.net (host-80-81-17-52.static.customer.m-online.net [80.81.17.52]) (authenticated bits=0) by aqmola.ilbers.de (8.14.4/8.14.4/Debian-4+deb7u1) with ESMTP id w3CEQF4o004564 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Thu, 12 Apr 2018 16:26:16 +0200 Received: from yssyq.radix50.net (localhost [127.0.0.1]) by yssyq.radix50.net (8.14.4/8.14.4/Debian-8) with ESMTP id w3CEQEoB016269 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Thu, 12 Apr 2018 16:26:14 +0200 Received: (from ibr@localhost) by yssyq.radix50.net (8.14.4/8.14.4/Submit) id w3CEQEpi016268 for isar-users@googlegroups.com; Thu, 12 Apr 2018 16:26:14 +0200 Date: Thu, 12 Apr 2018 16:26:14 +0200 From: Baurzhan Ismagulov To: isar-users Subject: Re: 'IMAGE_FEATURES' in Isar Message-ID: <20180412142614.GE6864@yssyq.radix50.net> Mail-Followup-To: isar-users References: <8cc3abfe-de1b-fb63-b58d-7a73561c11ae@siemens.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8cc3abfe-de1b-fb63-b58d-7a73561c11ae@siemens.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-TUID: o6B3OQ0WLtRk 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. > 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? > - Removal of apt and other possible reduction tasks Additional recipe some images depend on? > 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? With kind regards, Baurzhan.