Re: [bitbake-devel] [PATCH] cooker: Only warn on potentially incompatible layer

["Martin Jansa" <Martin.Jansa@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2980 bytes --]

You can modify LAYERSERIES_COMPAT_clang-layer to whatever you need after
you provide whatever is needed for layer (a) to be compatible with the rest
of your stack of layers.

See meta-qt5-compat as an example
https://github.com/webosose/meta-webosose/tree/2db6a1bc8e1a6f82db5b8f345d5aaa29e74fede5/meta-qt5-compat

Regards,

On Tue, Sep 7, 2021 at 3:50 PM Damian Wrobel <dwrobel@ertelnet.rybnik.pl>
wrote:

>
>
>
>  ---- On Tue, 07 Sep 2021 13:40:07 +0200 Richard Purdie <
> richard.purdie@linuxfoundation.org> wrote ----
>  > On Tue, 2021-09-07 at 01:54 -0700, Damian Wrobel wrote:
>  > > On Sat, Sep 4, 2021 at 09:54 AM, Richard Purdie wrote:
>  > > > Adding a single keyword every six months to show the layer is
> active and
>  > > > meant
>  > > > to work with a new release is not in my view a huge maintenance
> burden
>  > > > compared
>  > > > to showing that the layer is actively maintained and clearly
> showing which
>  > > > combinations are meant to work.
>  > >
>  > > It's not feasible because if the layer required some extra bbclasses
> cherry-
>  > > picked to be support it in the older yocto, then no one can simply
> add this
>  > > keyword to mark it's supported with older yocto.
>  >
>  > I don't understand your example here. If you can cherry-pick changes
> into a
>  > layer, you can also add a patch to mark the layer as supported using the
>  > standard variables?
>
> Let's consider the following example:
>
> a) meta-layer-which-we-want-to-consume (contains:
> LAYERSERIES_COMPAT_clang-layer = "gatesgarth hardknott")
> b) openembedded-core
> c) bitbake
> d) meta-our-layer
>
> By saying that layer (a) required some extra bbclasses to be cherry-picked
> I meant that
> in order to use layer (a) we had to cherry-pick some extra bbclasses or
> other changes
> into (d) to get (a) working with (b) and (c).
>
> This worked for us when (b), (c) and (d) were on yocto morty, but stopped
> to work when
> we switched to dunfell because dunfell started to utilize
> LAYERSERIES_COMPAT.
>
> This is very common situation that nothing needs to be modified in (a) to
> get it working with different versions
> of (b) and (c).
>
> So the question is why we have to modify also (a) to make (c) happy?
>
> --
> Regards,
> Damian
>
>  >
>  > > This in practise means that despite the layer itself didn't require
> any
>  > > changes to be supported in older yocto it will be unconditionally
> rejected by
>  > > bitbake.
>  >
>  > Your previous sentence says "the layer required some extra bbclasses"
> so it did
>  > need changes?
>  >
>  > > So, in reality it mean that such a layer has to be forked and
> modified to be
>  > > accepted by bitbake.
>  > >
>  > > I hope this clearly shows why this kind of checking in bitbake is
>  > > inappropriate.
>  >
>  > I'm afraid I don't understand your example.
>  >
>  > Cheers,
>  >
>  > Richard
>  >
>  >
>
> 
>
>

[-- Attachment #2: Type: text/html, Size: 3875 bytes --]