From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6514517411576676352 X-Received: by 10.46.62.15 with SMTP id l15mr464057lja.0.1516801155559; Wed, 24 Jan 2018 05:39:15 -0800 (PST) X-BeenThere: isar-users@googlegroups.com Received: by 10.46.117.2 with SMTP id q2ls1196970ljc.3.gmail; Wed, 24 Jan 2018 05:39:14 -0800 (PST) X-Google-Smtp-Source: AH8x225cutzfkcy1C5gM+cPw6dxhhilv4/ierbnP+1Iy8xkxLabKDlZwmXtjczA1RdV+UrirCntX X-Received: by 10.46.9.71 with SMTP id 68mr467822ljj.12.1516801154793; Wed, 24 Jan 2018 05:39:14 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1516801154; cv=none; d=google.com; s=arc-20160816; b=lsYeDYownTCN7qPrmpFZ2uIT6WoQmVryOGNCiahLgpNg3CGNxm6YLYmkOGE+Dilxnc wVQdOhBFkS0JEZM/aq+qF51QJCsIOe9e5/Y/22riHb/3zBCRkNnZWRmGEiYZv9Eyc8sL sy1/hhULiEx1Ks7JXaEMj6B4vJAa5H+16b6YWzigX9YbOjd17wItq+tkSyt/64VjgfkG aCnpFb4p7EWRDmbO5kZDkvPhYCzWwNkyt/3IFqDBRIJHyCCp9+crSQ9GDhl8OTWAiNWW joDknvHQ5qZgb0NjaNBBMuYnRn31RvJnnyMo8+S0ya93SvJnLdF6dsEnIlrwMMtJrkcd sUDQ== 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=d6TB9oN+r/lcAnd9Q03y4XzOysappt/5rOJ4RKKkVKw=; b=C+tj59z4KybpA8l4ybtliZKuPF9AA2ySgkzbieJPwuvX8K0N8x8Qk2mUtWrAvosuhV 9Mnbk3U+3V4ORgdLhig5e5ON0SWz2UlYmmLUpHt7bwP1ZntPlukJ1ois5fLO/cutnWGb 414W8DVAiMFpEWnvfqelIoZpzsf1XsiTmmvAlO53kvdYkl7ix3VplGK+o3HMO/f5zJ/+ oc6ao/9IB45HCn4M2xEu7noUee1dRSlgYpz/vU1cPWceoS6uHf7elJAs3dJljQt2Pi54 pLfL1DYhE1ysqwXkqlIzmXe0r3XESZZFzzqYLvezYbIpgvxatQs1vihgBlvQHl4zxwon K/Tw== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=pass (google.com: domain of jan.kiszka@siemens.com designates 192.35.17.2 as permitted sender) smtp.mailfrom=jan.kiszka@siemens.com Return-Path: Received: from thoth.sbs.de (thoth.sbs.de. [192.35.17.2]) by gmr-mx.google.com with ESMTPS id h92si338047lfi.3.2018.01.24.05.39.14 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 24 Jan 2018 05:39:14 -0800 (PST) Received-SPF: pass (google.com: domain of jan.kiszka@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 jan.kiszka@siemens.com designates 192.35.17.2 as permitted sender) smtp.mailfrom=jan.kiszka@siemens.com Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by thoth.sbs.de (8.15.2/8.15.2) with ESMTPS id w0ODdEot025635 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Wed, 24 Jan 2018 14:39:14 +0100 Received: from md1f2u6c.ww002.siemens.net (md1q0hnc.ad001.siemens.net [139.25.68.37] (may be forged)) by mail1.siemens.de (8.15.2/8.15.2) with ESMTP id w0ODdE6C002113 for ; Wed, 24 Jan 2018 14:39:14 +0100 Subject: Re: [PATCH] Factor out meta-examples To: isar-users References: <23ca38c7-3718-f70f-532f-697b7023d69c@siemens.com> <6780b230-1481-8767-89a4-129be64d4319@siemens.com> <9fa572d2-8a59-b3b3-ab96-451975c72235@ilbers.de> <3e2ad3a4-9631-80bd-7c75-315d628b8d5c@siemens.com> <20180124130836.GA6434@yssyq.radix50.net> From: Jan Kiszka Message-ID: Date: Wed, 24 Jan 2018 14:39:13 +0100 User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.8.1.12) Gecko/20080226 SUSE/2.0.0.12-1.1 Thunderbird/2.0.0.12 Mnenhy/0.7.5.666 MIME-Version: 1.0 In-Reply-To: <20180124130836.GA6434@yssyq.radix50.net> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-TUID: JBRc/g0776Vm On 2018-01-24 14:08, Baurzhan Ismagulov wrote: > On Wed, Jan 24, 2018 at 01:15:07PM +0100, Jan Kiszka wrote: >>> As I see this patch is just a small step to new direction, but I have no >>> idea what this direction is itself, it wasn't discussed here. >>> >>> Could you please describe the vision you assume to see finally? What is >>> Isar core, what is example? >> >> The direction is not really new: do not tough isar for own images, >> create "product" layers - simply the OE model. That's the key point of >> using bitbake and layers. > > I've heard about this only offline. I support the idea of not having to delete Surely not. First, it's what I was proposing (and patching towards) for ELC-NA 17. After that, all Siemens' major patches go in this direction, all our products are built this way. No one should be surprised by now. > meta-isar and adding meta-product to create a new product. The latter was > indeed the way we recommended at various conferences. The advantage of the > former would be easier upgradability of Isar core for a given meta-product. > > For the record, after some offline brainstorming with Alex, I see that one > doesn't have to delete meta-isar and can just copy the necessary parts to > meta-product. In that way, Isar core would be easily pullable. The disadvantage > is -- elaborating Alex's example as it wasn't immediately clear for me -- e.g. > copied image recipe: If Isar core e.g. moves away from multistrap, the > meta-product image copy would not automatically move to the new Isar core. > Moving image recipes to the core and using .bbappend at least for trivial > products would solve that problem. > > Back in time, when I first heard about the core upgradability requirement, I > stumbled over the question, what is core and what isn't. Because the initial > idea was that e.g. meta-isar/conf/multiconfig/qemuarm-wheezy.conf is just an > example. Where do we do the cut? I'd like to see some simple and intuitive > principle here. Then, we could provide the complete series and see the whole > picture. > > Alex suggests declaring Debian as the main distro and move it to the core, the > rest to the examples. If a product is based on that core, uses wheezy, and we > drop wheezy support, the product that hadn't copied it would be broken. Should > we accept this? I don't think that would be a good choice. Should we support > all older versions? Should we keep older versions not supported by the core? > One answer could be that upon such upgrade, qemuarm-wheezy.conf has to be > copied to meta-product. Would that solve the problem? > > The same for machines. Could we define anything more specific than "arbitrary, > reasonable minimum"? Only if we also test that. QEMU machines are both good test candidates and good examples. I think they could stay with the core for the sake of testability. But we may also extract their architectural bits so that you could reuse that definitions for own machines and have QEMU instances in the example/testing layer. > > >>> 1. 'meta' contains: >>>  - Isar classes >>>  - buildchroot >>>  - caching/reproducibility core; >>> >>> 2. meta-isar contains: >>>  - distro: debian-wheezy, debian-jessie, debian-stretch >>>  - machine: qemuarm, qemuamd64, qemui386 >>>  - images: isar-image-base (minimal multirstap image) >>>  - No local.conf, bblayers.conf etc... >>> >>> 3. meta-isar-example: >>>  - distro: raspbian-jessie >>>  - machine: rpi >>>  - images: isar-image-example >>>  - apps: hello, example-raw >>>  - local.conf, bblayers.conf etc... >> >> I specifically like the structure or meta[-isar]-example. Still, I have >> problems with the separation of meta and meta-isar. > > I'd suggest two-directory structure: > > * meta is core, contains 1 and 2 above, and is renamed to meta-isar to clearly > show that it is Isar core, to avoid questions whether meta is inherited from > OE, and to avoid name clashes for possible integration with other projects. > > * meta-isar is renamed to meta[-isar]-example, as I agree that this name is > much clearer for new users than meta-isar. > > This is simple, stupid. Even if there are use cases for meta alone: If we > declare machines and Debian suite configs as the core, is there value in > maintaining the separation of meta and meta-isar? Exactly. I can rework my patch in this direction, split it up, whatever. Besides that this general question of meta vs. metat-isar was nagging me for a while, the current motivation to do something is to have the reusable custom kernel recipes and an exemplary recipe that use them in separate layers. Jan -- Siemens AG, Corporate Technology, CT RDA IOT SES-DE Corporate Competence Center Embedded Linux