Re: [PATCH] Factor out meta-examples

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

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