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

["Damian Wrobel" <dwrobel@ertelnet.rybnik.pl>]

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