Re: [PATCH] Factor out meta-examples

[Jan Kiszka <jan.kiszka@siemens.com>]

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