perhaps you should create a new branch for this layer which will be
compatible with gatesgarth, you can seed it with dunfell branch
and then make needed changes

On Tue, Feb 16, 2021 at 3:02 PM Jonas Vautherin
<jonas.vautherin@...> wrote:
>
> Good evening,
>
> I am using Yocto Gatesgarth, and I was just updating a layer that was written for Dunfell. In the `conf/layer.conf`, I can simply add "gatesgarth" to `LAYERSERIES_COMPAT_pocketbeagle`, like so:
>
> ```
> LAYERSERIES_COMPAT_pocketbeagle = "dunfell gatesgarth"
> ```
>
> However, this does not seem to work for a `.bbappend`. Let me use this particular layer as an example: it is a BSP that defines `linux-yocto_4.19.bbappend` for Dunfell. In my case, I want to define `linux-yocto_5.4.bbappend` for Gatesgarth. When building with Dunfell, I would like it to use the former, and when building with Gatesgarth, I would like it to use the latter.
>
> However, if I keep both `linux-yocto_4.19.bbappend` and `linux-yocto_5.4.bbappend` and try to build with Gatesgarth, it fails with:
>
> ```
> ERROR: No recipes in default available for:
>   /path/to/recipes-kernel/linux/linux-yocto_4.19.bbappend
> ```
>
> Which makes sense: Gatesgarth does not provide `linux-yocto_4.19`.
>
> Is there a way to keep both `*.bbappend` and have Yocto ignore the ones that do not correspond to its version? Or would that be bad practice anyway?
>
> Best Regards,
> Jonas
>
>
>

Hi,

On Wed, Feb 17, 2021 at 12:02:26AM +0100, Jonas Vautherin wrote:
> Good evening,
>
> I am using Yocto Gatesgarth, and I was just updating a layer that was
> written for Dunfell. In the `conf/layer.conf`, I can simply add
> "gatesgarth" to `LAYERSERIES_COMPAT_pocketbeagle`, like so:
>
> ```
> LAYERSERIES_COMPAT_pocketbeagle = "dunfell gatesgarth"
> ```
>
> However, this does not seem to work for a `.bbappend`. Let me use this
> particular layer as an example: it is a BSP that defines
> `linux-yocto_4.19.bbappend` for Dunfell. In my case, I want to define
> `linux-yocto_5.4.bbappend` for Gatesgarth. When building with Dunfell, I
> would like it to use the former, and when building with Gatesgarth, I would
> like it to use the latter.
>
> However, if I keep both `linux-yocto_4.19.bbappend`
> and `linux-yocto_5.4.bbappend` and try to build with Gatesgarth, it fails
> with:
>
> ```
> ERROR: No recipes in default available for:
>   /path/to/recipes-kernel/linux/linux-yocto_4.19.bbappend
> ```
>
> Which makes sense: Gatesgarth does not provide `linux-yocto_4.19`.
>
> Is there a way to keep both `*.bbappend` and have Yocto ignore the ones
> that do not correspond to its version? Or would that be bad practice anyway?

What I do in cases like this:

 * check and decide if BSP layer can be update to be fully compatible with new yocto
   version, by asking from maintainers of the BSP layer and HW vendors
   (usual answer is 'not this year, maybe next' or 'if you pay?', if you are lucky
    they will say 'just use the correct branch')

 * check if simple patches can update BSP layer to be compatible with new yocto
   version, if this involves Linux kernel, libdrm etc major version changes it
   might not work

Quite often, I keep using the BSP SW stack from old yocto release with only minimal
changes. For this to work, I make the minimal modifications needed to support building
with new yocto version like modify LAYERSERIES_COMPAT and adapt bbclasses, then copy
the needed old recipes from previous yocto version over the the BSP layer to be
maintained there by the BSP SW maintainers. What helps a lot, is that you have
reviewed what SW components you need to use from BSP SW meta layer and you have
BBMASK'ed away all recipes and bbappends which your product and its distro
configuration does not need.

Often BSP layers are full of examples, prototypes, or just plain weird changes
to high level SW components like gstreamer, systemd, openssl or openssh which your
product might not need (e.g. is prefectly fine with the poky version of the recipe).
These BSP side changes make yocto updates much more difficult and versioned dependencies
from BSP to poky are too complex and difficult to resolve easily. Thus look
for minimizing the impact of the BSP SW stack, keep it unchanged apart from minimal
bitbake and bbclass fixes, and update the rest.

For security and other updates, the BSP SW stack needs to be handled separately.

Hope this helps,

-Mikko