From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6543174714398867456 X-Received: by 10.46.128.21 with SMTP id j21mr307495ljg.25.1523618854686; Fri, 13 Apr 2018 04:27:34 -0700 (PDT) X-BeenThere: isar-users@googlegroups.com Received: by 2002:a19:fc2:: with SMTP id 63-v6ls829107lfp.16.gmail; Fri, 13 Apr 2018 04:27:34 -0700 (PDT) X-Google-Smtp-Source: AIpwx48UdUpyZwV73OxT0YxVuBFCu/Bt+452fJqlt8v9n2YNggrRtda9LzxkMRT/W+9tnzZok27n X-Received: by 2002:a19:ef0e:: with SMTP id n14-v6mr913211lfh.30.1523618854166; Fri, 13 Apr 2018 04:27:34 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1523618854; cv=none; d=google.com; s=arc-20160816; b=dyIZwHMdhdkcn/3rnQxHrScYd3X8YFL1SaGktcAycUTzhra2fzFU49++SSnaq46OhA vb6S3iExvmiLEhAKaeTBGgqneZBeIf20iW6MOw2oHEWuTGWZY43MZHJ+Skg26YdVYKPh dQzbiTPecAFg85l24DpQCWB1oaWnqvzp6ZTu34xIOWk+TyQv/3Y6XWz+pGhXHBqEIGHO DKWBEZEQ6R9V7pRN/znZc4anlV50h7xykZH9jIRaLDHU05p+dVBRzJeLlZZ/4Dohqhab ElhjwH2rHcf9nV8Y/A/VlpGRsbEIOv73SyxSyPkZ84HCOKHE0wVJ0+Lw5T+U5uVGvj2Z y8AQ== 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=WrD/ce672/VsQWjBEZy3ZhWh3v6a0T5x1/p3pix7lrA=; b=URGrOmzlJqnCmkGChZhgGyUzluWhqriMvLA01YzyL8+5613YBnC4uDstBUaroUYuRP a4Gz80Q8fMtVqqkiusbzVeigBY0FYm1MlgKDRyWVtVtcSXQkjPnHMV0MagL5VjYX714w l23lNFU1MTUtIDihISKChRs1cDwlc3fQ0iGr4f/t2Np+MDCenpXnAJGyXL+Hxr1ecMdF TNUzXfnT8DtulfEE3XnT3Icfo2bNmXoE+p2or6gndO6xfGTQq7R+jYiuiuSFDs073wCP QGdne5+sBjjGuFrgKUmnYPeM25p3bgoJVab1w55mje1fpscKZWO7T8AsZD8O/EyVtCtl md6w== 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 a19-v6si94455lfi.1.2018.04.13.04.27.33 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 13 Apr 2018 04:27:34 -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 w3DBRVUk007362 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Fri, 13 Apr 2018 13:27:33 +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 w3DBRVgU012918 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Fri, 13 Apr 2018 13:27:31 +0200 Received: (from ibr@localhost) by yssyq.radix50.net (8.14.4/8.14.4/Submit) id w3DBRVYL012917 for isar-users@googlegroups.com; Fri, 13 Apr 2018 13:27:31 +0200 Date: Fri, 13 Apr 2018 13:27:31 +0200 From: Baurzhan Ismagulov To: isar-users Subject: Re: 'IMAGE_FEATURES' in Isar Message-ID: <20180413112731.GF6488@yssyq.radix50.net> Mail-Followup-To: isar-users References: <8cc3abfe-de1b-fb63-b58d-7a73561c11ae@siemens.com> <20180412142614.GE6864@yssyq.radix50.net> <9e911992-c9ff-647d-ff04-2a400677d6e9@siemens.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9e911992-c9ff-647d-ff04-2a400677d6e9@siemens.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-TUID: kCNuHotLHzrn On Thu, Apr 12, 2018 at 05:35:17PM +0200, Claudius Heine wrote: > 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? Ah, now I see your point. As I understand it, Alex's point is to introduce an additional, breve, binary porcelain for the user. Adding or removing hairy IMAGE_INSTALL lines should be hidden in the plumbing. E.g., poky/meta/recipes-sato/images/core-image-sato.bb: IMAGE_FEATURES += "splash package-management x11-base x11-sato \ ssh-server-dropbear hwcodecs" When we have that many optional things, copy-pasting them in multiple recipes would be an error-prone process and a maintenance problem due to duplication of IMAGE_INSTALL += lines that have all to be updated if anything changes. In our case, local.conf would have IMAGE_FEATURES = "kernel" by default. Of course, we can only go in that direction if something like IMAGE_FEATURES_isar-image-base = "" would work (maybe it does [1]). It isn't very Isar-like, since Yocto is focused on one config at a time, and we explicitly aim at multiple, diverse deliverables from the beginning. Ideally, I'd like to see such binary porcelain in a recipe (not touching machine and distro configs being the goal). > >> - 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. Agree with the latter (e.g., root password, hostname). Do I understand correctly that localepurge and apt-get clean have to be done at the end? If yes, then they aren't suitable for system-setup-package. Then, where should those go? Regarding whether that should be done in IMAGE_FEATURES, my opinion is still that specifically localepurge, apt-get clean should always be performed. IOW, I don't think they belong to IMAGE_FEATURES. > 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. We can discuss those when we have a specific example. > >> - 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. Ok, so it has to be a task. Yocto does it by default and provides IMAGE_FEATURES += "package-management". I think mimicking that would be an advantage here. > >>The other question might be if having a kernel should be implemented as a > >>IMAGE_FEATURE or rather a setting in the machine.conf? I'd like to provide a binary way to customize it for every image without touching machine or distro confs. > >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. After I see the implementation, I think stacking complex lines in multiple images has disadvantages compared to binary options. References: 1. https://www.yoctoproject.org/docs/1.6/bitbake-user-manual/bitbake-user-manual.html#conditional-syntax-overrides With kind regards, Baurzhan.