[PATCH] Factor out meta-examples

[PATCH] Factor out meta-examples

[Jan Kiszka]

From: Jan Kiszka <jan.kiszka@siemens.com>

Move recipes that have exemplary character (currently everything under
recipes-app) into a separate layer that can easily be dropped when
building real images. This also helps to ensure that no assumptions
about customizations and core recipes sharing the same layer sneak in
again.

The meta-isar layer is still not completely clean as we keep
bblayers.conf.sample and local.conf.sample prepared for building example
images.

Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
---
 meta-examples/conf/layer.conf                               | 13 +++++++++++++
 .../recipes-app/example-raw/example-raw_0.2.bb              |  0
 .../recipes-app/example-raw/files/README                    |  0
 .../recipes-app/example-raw/files/postinst                  |  0
 {meta-isar => meta-examples}/recipes-app/hello/hello.bb     |  0
 meta-isar/conf/bblayers.conf.sample                         |  1 +
 6 files changed, 14 insertions(+)
 create mode 100644 meta-examples/conf/layer.conf
 rename {meta-isar => meta-examples}/recipes-app/example-raw/example-raw_0.2.bb (100%)
 rename {meta-isar => meta-examples}/recipes-app/example-raw/files/README (100%)
 rename {meta-isar => meta-examples}/recipes-app/example-raw/files/postinst (100%)
 rename {meta-isar => meta-examples}/recipes-app/hello/hello.bb (100%)

diff --git a/meta-examples/conf/layer.conf b/meta-examples/conf/layer.conf
new file mode 100644
index 0000000..f244f26
--- /dev/null
+++ b/meta-examples/conf/layer.conf
@@ -0,0 +1,13 @@
+# This software is a part of ISAR.
+# Copyright (c) Siemens AG, 2018
+
+# We have a conf and classes directory, add to BBPATH
+BBPATH .= ":${LAYERDIR}"
+
+# We have recipes-* directories, add to BBFILES
+BBFILES += "${LAYERDIR}/recipes-*/*/*.bb \
+            ${LAYERDIR}/recipes-*/*/*.bbappend"
+
+BBFILE_COLLECTIONS += "examples"
+BBFILE_PATTERN_examples = "^${LAYERDIR}/"
+BBFILE_PRIORITY_examples = "6"
diff --git a/meta-isar/recipes-app/example-raw/example-raw_0.2.bb b/meta-examples/recipes-app/example-raw/example-raw_0.2.bb
similarity index 100%
rename from meta-isar/recipes-app/example-raw/example-raw_0.2.bb
rename to meta-examples/recipes-app/example-raw/example-raw_0.2.bb
diff --git a/meta-isar/recipes-app/example-raw/files/README b/meta-examples/recipes-app/example-raw/files/README
similarity index 100%
rename from meta-isar/recipes-app/example-raw/files/README
rename to meta-examples/recipes-app/example-raw/files/README
diff --git a/meta-isar/recipes-app/example-raw/files/postinst b/meta-examples/recipes-app/example-raw/files/postinst
similarity index 100%
rename from meta-isar/recipes-app/example-raw/files/postinst
rename to meta-examples/recipes-app/example-raw/files/postinst
diff --git a/meta-isar/recipes-app/hello/hello.bb b/meta-examples/recipes-app/hello/hello.bb
similarity index 100%
rename from meta-isar/recipes-app/hello/hello.bb
rename to meta-examples/recipes-app/hello/hello.bb
diff --git a/meta-isar/conf/bblayers.conf.sample b/meta-isar/conf/bblayers.conf.sample
index 80867e7..6d9b471 100644
--- a/meta-isar/conf/bblayers.conf.sample
+++ b/meta-isar/conf/bblayers.conf.sample
@@ -8,6 +8,7 @@ BBFILES ?= ""
 BBLAYERS ?= " \
   ##ISARROOT##/meta \
   ##ISARROOT##/meta-isar \
+  ##ISARROOT##/meta-examples \
   "
 BBLAYERS_NON_REMOVABLE ?= " \
   ##ISARROOT##/meta \
-- 
2.13.6

Re: [PATCH] Factor out meta-examples

[Alexander Smirnov]

Hi,

On 01/24/2018 10:34 AM, Jan Kiszka wrote:
> From: Jan Kiszka <jan.kiszka@siemens.com>
> 
> Move recipes that have exemplary character (currently everything under
> recipes-app) into a separate layer that can easily be dropped when
> building real images. This also helps to ensure that no assumptions
> about customizations and core recipes sharing the same layer sneak in
> again.
> 
> The meta-isar layer is still not completely clean as we keep
> bblayers.conf.sample and local.conf.sample prepared for building example
> images.
> 

Isar core is in 'meta' layer. Current 'meta-isar' is the example itself, 
it's not intended to be used in real projects, it's a kind of template 
for your 'meta-product'.

Alex

> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
> ---
>   meta-examples/conf/layer.conf                               | 13 +++++++++++++
>   .../recipes-app/example-raw/example-raw_0.2.bb              |  0
>   .../recipes-app/example-raw/files/README                    |  0
>   .../recipes-app/example-raw/files/postinst                  |  0
>   {meta-isar => meta-examples}/recipes-app/hello/hello.bb     |  0
>   meta-isar/conf/bblayers.conf.sample                         |  1 +
>   6 files changed, 14 insertions(+)
>   create mode 100644 meta-examples/conf/layer.conf
>   rename {meta-isar => meta-examples}/recipes-app/example-raw/example-raw_0.2.bb (100%)
>   rename {meta-isar => meta-examples}/recipes-app/example-raw/files/README (100%)
>   rename {meta-isar => meta-examples}/recipes-app/example-raw/files/postinst (100%)
>   rename {meta-isar => meta-examples}/recipes-app/hello/hello.bb (100%)
> 
> diff --git a/meta-examples/conf/layer.conf b/meta-examples/conf/layer.conf
> new file mode 100644
> index 0000000..f244f26
> --- /dev/null
> +++ b/meta-examples/conf/layer.conf
> @@ -0,0 +1,13 @@
> +# This software is a part of ISAR.
> +# Copyright (c) Siemens AG, 2018
> +
> +# We have a conf and classes directory, add to BBPATH
> +BBPATH .= ":${LAYERDIR}"
> +
> +# We have recipes-* directories, add to BBFILES
> +BBFILES += "${LAYERDIR}/recipes-*/*/*.bb \
> +            ${LAYERDIR}/recipes-*/*/*.bbappend"
> +
> +BBFILE_COLLECTIONS += "examples"
> +BBFILE_PATTERN_examples = "^${LAYERDIR}/"
> +BBFILE_PRIORITY_examples = "6"
> diff --git a/meta-isar/recipes-app/example-raw/example-raw_0.2.bb b/meta-examples/recipes-app/example-raw/example-raw_0.2.bb
> similarity index 100%
> rename from meta-isar/recipes-app/example-raw/example-raw_0.2.bb
> rename to meta-examples/recipes-app/example-raw/example-raw_0.2.bb
> diff --git a/meta-isar/recipes-app/example-raw/files/README b/meta-examples/recipes-app/example-raw/files/README
> similarity index 100%
> rename from meta-isar/recipes-app/example-raw/files/README
> rename to meta-examples/recipes-app/example-raw/files/README
> diff --git a/meta-isar/recipes-app/example-raw/files/postinst b/meta-examples/recipes-app/example-raw/files/postinst
> similarity index 100%
> rename from meta-isar/recipes-app/example-raw/files/postinst
> rename to meta-examples/recipes-app/example-raw/files/postinst
> diff --git a/meta-isar/recipes-app/hello/hello.bb b/meta-examples/recipes-app/hello/hello.bb
> similarity index 100%
> rename from meta-isar/recipes-app/hello/hello.bb
> rename to meta-examples/recipes-app/hello/hello.bb
> diff --git a/meta-isar/conf/bblayers.conf.sample b/meta-isar/conf/bblayers.conf.sample
> index 80867e7..6d9b471 100644
> --- a/meta-isar/conf/bblayers.conf.sample
> +++ b/meta-isar/conf/bblayers.conf.sample
> @@ -8,6 +8,7 @@ BBFILES ?= ""
>   BBLAYERS ?= " \
>     ##ISARROOT##/meta \
>     ##ISARROOT##/meta-isar \
> +  ##ISARROOT##/meta-examples \
>     "
>   BBLAYERS_NON_REMOVABLE ?= " \
>     ##ISARROOT##/meta \
> 

-- 
With best regards,
Alexander Smirnov

ilbers GmbH
Baierbrunner Str. 28c
D-81379 Munich
+49 (89) 122 67 24-0
http://ilbers.de/
Commercial register Munich, HRB 214197
General manager: Baurzhan Ismagulov

Re: [PATCH] Factor out meta-examples

[Jan Kiszka]

On 2018-01-24 08:49, Alexander Smirnov wrote:
> Hi,
> 
> On 01/24/2018 10:34 AM, Jan Kiszka wrote:
>> From: Jan Kiszka <jan.kiszka@siemens.com>
>>
>> Move recipes that have exemplary character (currently everything under
>> recipes-app) into a separate layer that can easily be dropped when
>> building real images. This also helps to ensure that no assumptions
>> about customizations and core recipes sharing the same layer sneak in
>> again.
>>
>> The meta-isar layer is still not completely clean as we keep
>> bblayers.conf.sample and local.conf.sample prepared for building example
>> images.
>>
> 
> Isar core is in 'meta' layer. Current 'meta-isar' is the example itself,
> it's not intended to be used in real projects, it's a kind of template
> for your 'meta-product'.

This is the old view, it's no longer correct. meta-isar has become
already a core layer that products build upon. We need to fix this now.

Jan

-- 
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux

Re: [PATCH] Factor out meta-examples

[Jan Kiszka]

On 2018-01-24 08:52, Jan Kiszka wrote:
> On 2018-01-24 08:49, Alexander Smirnov wrote:
>> Hi,
>>
>> On 01/24/2018 10:34 AM, Jan Kiszka wrote:
>>> From: Jan Kiszka <jan.kiszka@siemens.com>
>>>
>>> Move recipes that have exemplary character (currently everything under
>>> recipes-app) into a separate layer that can easily be dropped when
>>> building real images. This also helps to ensure that no assumptions
>>> about customizations and core recipes sharing the same layer sneak in
>>> again.
>>>
>>> The meta-isar layer is still not completely clean as we keep
>>> bblayers.conf.sample and local.conf.sample prepared for building example
>>> images.
>>>
>>
>> Isar core is in 'meta' layer. Current 'meta-isar' is the example itself,
>> it's not intended to be used in real projects, it's a kind of template
>> for your 'meta-product'.
> 
> This is the old view, it's no longer correct. meta-isar has become
> already a core layer that products build upon. We need to fix this now.

BTW, we should eventually discuss the folding of meta and meta-isar or a
clarification what should go where. For now, I will be add the reusable
recipes for custom kernel builds into meta-isar, but it's not really
intuitive yet.

We definitely must stop proposing users to fork isar in order to build
own images. That is a completely obsolete and counterproductive pattern.

Jan

-- 
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux

Re: [PATCH] Factor out meta-examples

[Alexander Smirnov]

On 01/24/2018 10:56 AM, Jan Kiszka wrote:
> On 2018-01-24 08:52, Jan Kiszka wrote:
>> On 2018-01-24 08:49, Alexander Smirnov wrote:
>>> Hi,
>>>
>>> On 01/24/2018 10:34 AM, Jan Kiszka wrote:
>>>> From: Jan Kiszka <jan.kiszka@siemens.com>
>>>>
>>>> Move recipes that have exemplary character (currently everything under
>>>> recipes-app) into a separate layer that can easily be dropped when
>>>> building real images. This also helps to ensure that no assumptions
>>>> about customizations and core recipes sharing the same layer sneak in
>>>> again.
>>>>
>>>> The meta-isar layer is still not completely clean as we keep
>>>> bblayers.conf.sample and local.conf.sample prepared for building example
>>>> images.
>>>>
>>>
>>> Isar core is in 'meta' layer. Current 'meta-isar' is the example itself,
>>> it's not intended to be used in real projects, it's a kind of template
>>> for your 'meta-product'.
>>
>> This is the old view, it's no longer correct. meta-isar has become
>> already a core layer that products build upon. We need to fix this now.
> 
> BTW, we should eventually discuss the folding of meta and meta-isar or a
> clarification what should go where. For now, I will be add the reusable
> recipes for custom kernel builds into meta-isar, but it's not really
> intuitive yet.
> 
> We definitely must stop proposing users to fork isar in order to build
> own images. That is a completely obsolete and counterproductive pattern.
> 

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?

BTW, below is my assumption what could be reasonable regarding Isar 
future layout:

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...

With this layout I assume that:

1. Debian is the reference Isar distro and it's included to Isar core by 
default.

2. Debian will be the most popular distro for customer projects.

3. To create new product, the user needs to create meta-prodcut with:
  - local.conf, bblayers.conf
  - isar-image-base.bbappend with custom packages set

This layout will help to hide back-end magic like multistrap from user. 
So if, for example, we will switch from multistrap to debootstrap, 
'meta-product' will work as it is.

Alex

Re: [PATCH] Factor out meta-examples

[Jan Kiszka]

On 2018-01-24 11:04, Alexander Smirnov wrote:
> On 01/24/2018 10:56 AM, Jan Kiszka wrote:
>> On 2018-01-24 08:52, Jan Kiszka wrote:
>>> On 2018-01-24 08:49, Alexander Smirnov wrote:
>>>> Hi,
>>>>
>>>> On 01/24/2018 10:34 AM, Jan Kiszka wrote:
>>>>> From: Jan Kiszka <jan.kiszka@siemens.com>
>>>>>
>>>>> Move recipes that have exemplary character (currently everything under
>>>>> recipes-app) into a separate layer that can easily be dropped when
>>>>> building real images. This also helps to ensure that no assumptions
>>>>> about customizations and core recipes sharing the same layer sneak in
>>>>> again.
>>>>>
>>>>> The meta-isar layer is still not completely clean as we keep
>>>>> bblayers.conf.sample and local.conf.sample prepared for building
>>>>> example
>>>>> images.
>>>>>
>>>>
>>>> Isar core is in 'meta' layer. Current 'meta-isar' is the example
>>>> itself,
>>>> it's not intended to be used in real projects, it's a kind of template
>>>> for your 'meta-product'.
>>>
>>> This is the old view, it's no longer correct. meta-isar has become
>>> already a core layer that products build upon. We need to fix this now.
>>
>> BTW, we should eventually discuss the folding of meta and meta-isar or a
>> clarification what should go where. For now, I will be add the reusable
>> recipes for custom kernel builds into meta-isar, but it's not really
>> intuitive yet.
>>
>> We definitely must stop proposing users to fork isar in order to build
>> own images. That is a completely obsolete and counterproductive pattern.
>>
> 
> 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.

> 
> BTW, below is my assumption what could be reasonable regarding Isar
> future layout:
> 
> 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.

Could you describe a use case where one would only pull meta? If there
is one, we will also have to think about how to ensure that no
dependencies from meta on meta-isar prevent this (test strategy).

> 
> With this layout I assume that:
> 
> 1. Debian is the reference Isar distro and it's included to Isar core by
> default.
> 
> 2. Debian will be the most popular distro for customer projects.
> 
> 3. To create new product, the user needs to create meta-prodcut with:
>  - local.conf, bblayers.conf
>  - isar-image-base.bbappend with custom packages set

Right.

> 
> This layout will help to hide back-end magic like multistrap from user.
> So if, for example, we will switch from multistrap to debootstrap,
> 'meta-product' will work as it is.

Exactly. And it avoid the trap of forking isar and then running into
update/rebase problems with local changes.

Jan

-- 
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux

Re: [PATCH] Factor out meta-examples

[Baurzhan Ismagulov]

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.

Re: [PATCH] Factor out meta-examples

[Jan Kiszka]

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

Re: [PATCH] Factor out meta-examples

[Baurzhan Ismagulov]

On Wed, Jan 24, 2018 at 02:39:13PM +0100, Jan Kiszka wrote:
> > 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.

It wasn't to say anyone was surprised. Alex's wish is to see the design
principles we elaborate below (what goes where) formulated on this list.


> > 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.

Ok, so for now, it's still "arbitrary, reasonable minimum".


> 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.

Hmm, in that case, wouldn't it be a pure rename action? meta -> meta-isar,
meta-isar -> meta-example? Or do you suggest to move Debian configs to meta?


> > 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.

My suggestion would be still "small steps": Review and merge reusable custom
kernel in meta-isar, then reach the consensus on what goes where and do the
complete move in a separate series.


With kind regards,
Baurzhan.