From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6514517411576676352 X-Received: by 10.28.193.201 with SMTP id r192mr604964wmf.18.1516799320034; Wed, 24 Jan 2018 05:08:40 -0800 (PST) X-BeenThere: isar-users@googlegroups.com Received: by 10.223.151.118 with SMTP id r109ls3737304wrb.14.gmail; Wed, 24 Jan 2018 05:08:39 -0800 (PST) X-Google-Smtp-Source: AH8x227qLhlUJu8Sqi76WXaFJCZrLSBRNel+nQAMWmg3ZruP0FDZTMlWD4ik33Z2innznk75yy7S X-Received: by 10.223.153.178 with SMTP id y47mr800903wrb.2.1516799319544; Wed, 24 Jan 2018 05:08:39 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1516799319; cv=none; d=google.com; s=arc-20160816; b=UqUBX0YEARRRve51UJEk3q0m1McteSyyKSO9G9HtfeYTLvWalUGXEDnkjRj8BI7bs5 +d431pO+bxAxP03Ox9JgQ6e2vr+sSXRj+fEOK88y73cI3nw32NwPNzgbU2FGl3TUJCEP loE4lNXQHGJxAZmok06Hl1dTlyGHxTCI2t3eC2fdlsTdlHDJ+oyXDJbCSJtb4YFVFBgG hFzZsJxeihu4iCnhX3sx3MkGkQhDNJuYJD3wELkfmyeuevSzq/Dx+hkyiyQrfiBmgJru 3ftctFBWpVWgLXvd3wWk3Wg7NlTrBUnlHnus8Cd6GA4tkBxSjenNbl+/+8IYSSu8xxiT 4YDQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=user-agent:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:mail-followup-to :message-id:subject:to:from:date:arc-authentication-results; bh=3iYmx9G8iwhTydzREgsqm+VU3Pjs3vDFDLfMjfEhPCQ=; b=1AXX1DgSRpSnJMTUQR4suHWgXBqSsxzU3+i6wdcLdhpLyPAWZQhBchcYEPYiUuQfQh VCccNHfCv4rAwoiVFMEa/A0mfDhHGqQTbD97C3go4ds46MxovIv6gxW6K8qvqjYMsU4d NX/7d7tp+Ijhl6zQdd+4kcM7Dajk1YWTPR/kLf78jzbf1JPzmb70vsckrOg6IdtaX352 K+VAo/ZHcTM8YVLCPhJMfmMEwZvzpvEuXOz5GftEhzfnvMcggh1OMUIZ2iSKnE3JBYcl CkNx7QY1bBGTvjD8bVmeH4E6bzOOHfa3PvDdo1OhWgToxUkJ3REfDPibYqU3UcjGuBuO VQag== 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 b10si22602wmc.0.2018.01.24.05.08.39 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 24 Jan 2018 05:08:39 -0800 (PST) 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 (p2E51B0DF.dip0.t-ipconnect.de [46.81.176.223]) (authenticated bits=0) by aqmola.ilbers.de (8.14.4/8.14.4/Debian-4+deb7u1) with ESMTP id w0OD8bYg017171 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Wed, 24 Jan 2018 14:08:38 +0100 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 w0OD8a2G007571 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Wed, 24 Jan 2018 14:08:36 +0100 Received: (from ibr@localhost) by yssyq.radix50.net (8.14.4/8.14.4/Submit) id w0OD8a4L007570 for isar-users@googlegroups.com; Wed, 24 Jan 2018 14:08:36 +0100 Date: Wed, 24 Jan 2018 14:08:36 +0100 From: Baurzhan Ismagulov To: isar-users Subject: Re: [PATCH] Factor out meta-examples Message-ID: <20180124130836.GA6434@yssyq.radix50.net> Mail-Followup-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> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-9 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <3e2ad3a4-9631-80bd-7c75-315d628b8d5c@siemens.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-TUID: sUY8+NFHj2IQ 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 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"? > > 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? With kind regards, Baurzhan.