Re: [PATCH] Factor out meta-examples

[Baurzhan Ismagulov <ibr@radix50.net>]

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.