Keep .bbappend for older Yocto version


Jonas Vautherin
 

It does help, yes!
Thanks a lot!

On Thu, 18 Feb 2021, 12:24 , <Mikko.Rapeli@...> wrote:
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


Khem Raj
 



On Tue, Feb 16, 2021 at 3:54 PM Jonas Vautherin <jonas.vautherin@...> wrote:
Thank you for the answer :-). Yes, that works, and it seems like it is commonly used already. But because there is a way to define which versions are supported in the machine configuration, I thought there may be a way without branches, i.e. having a layer that actually is compatible with multiple versions.

Yes in some layers they do work across releases but 
That does have some restrictions and maintenance costs eg if you are patching a recipe via a bbappend then use more liberal bbappend names using % wild characters and make sure same patch can apply to different versions of the package etc 

Usually maintaining per Releaee branch turns out to be less costly over time 


Otherwise what's the point of LAYERSERIES_COMPAT, if the way to move to another version is to branch away? Is that a legacy option?

Best,


On Wed, 17 Feb 2021, 00:32 Khem Raj, <raj.khem@...> wrote:
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
>
>
>


Jonas Vautherin
 

Thank you for the answer :-). Yes, that works, and it seems like it is commonly used already. But because there is a way to define which versions are supported in the machine configuration, I thought there may be a way without branches, i.e. having a layer that actually is compatible with multiple versions.

Otherwise what's the point of LAYERSERIES_COMPAT, if the way to move to another version is to branch away? Is that a legacy option?

Best,


On Wed, 17 Feb 2021, 00:32 Khem Raj, <raj.khem@...> wrote:
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
>
>
>


Khem Raj
 

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@gmail.com> 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



Jonas Vautherin
 

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