Recipes which should always be upgraded on stable branches

Recipes which should always be upgraded on stable branches

[Paul Barker]

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

Hi all,

I've been briefly discussing stable branch update policy with Yoann.
There's a few recipes in openembedded-core which I would like to propose
that we always update to the latest version on LTS and stable branches.
These are recipes typically providing data that is expected to change
over time, with little or no code.

You could say ca-certificates is already covered by the fact that
security fixes are acceptable for example, but a clearer policy would be
better.

Any policy change will go to the TSC for approval, the goal here is to
get some review and input so that a concrete proposal can be put
forward.

The recipes that come to my mind are:

- ca-certificates: To allow access to HTTPS resources we need to keep
  these up-to-date.

    - Keeping this up-to-date is common practice in other distros.

- tzdata: To stay up to date with timezone or daylight savings changes.

    - Debian takes upgrades to this on stable branches
      (see https://tracker.debian.org/pkg/tzdata).

- mobile-broadband-provider-info: To stay up to date with provider
  changes.

    - The README file for this project says "The Package contains only
      informational files so it's safe for distributions to grab updates
      even during feature freeze and maintenance stages."

What opinions do other folks have?

Are there any other recipes we should include in this list?

Best regards,

-- 
Paul Barker


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

Re: [OE-core] Recipes which should always be upgraded on stable branches

[Ankur Tyagi]

On Thu, Feb 26, 2026 at 6:44 AM Paul Barker via lists.openembedded.org
<paul=pbarker.dev@lists.openembedded.org> wrote:
>
> Hi all,
>
> I've been briefly discussing stable branch update policy with Yoann.
> There's a few recipes in openembedded-core which I would like to propose
> that we always update to the latest version on LTS and stable branches.
> These are recipes typically providing data that is expected to change
> over time, with little or no code.
>
> You could say ca-certificates is already covered by the fact that
> security fixes are acceptable for example, but a clearer policy would be
> better.
>
> Any policy change will go to the TSC for approval, the goal here is to
> get some review and input so that a concrete proposal can be put
> forward.
>
> The recipes that come to my mind are:
>
> - ca-certificates: To allow access to HTTPS resources we need to keep
>   these up-to-date.
>
>     - Keeping this up-to-date is common practice in other distros.
>
> - tzdata: To stay up to date with timezone or daylight savings changes.
>
>     - Debian takes upgrades to this on stable branches
>       (see https://tracker.debian.org/pkg/tzdata).
>
> - mobile-broadband-provider-info: To stay up to date with provider
>   changes.
>
>     - The README file for this project says "The Package contains only
>       informational files so it's safe for distributions to grab updates
>       even during feature freeze and maintenance stages."
>
> What opinions do other folks have?

In favor of this.

> Are there any other recipes we should include in this list?

Also suggest to include wireless-regdb in the list.

> Best regards,
>
> --
> Paul Barker
>
>
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#231972): https://lists.openembedded.org/g/openembedded-core/message/231972
> Mute This Topic: https://lists.openembedded.org/mt/117998482/3619737
> Group Owner: openembedded-core+owner@lists.openembedded.org
> Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [ankur.tyagi85@gmail.com]
> -=-=-=-=-=-=-=-=-=-=-=-
>

Re: [Openembedded-architecture] Recipes which should always be upgraded on stable branches

[Mark Hatle]

On 2/25/26 11:44 AM, Paul Barker wrote:
> Hi all,
> 
> I've been briefly discussing stable branch update policy with Yoann.
> There's a few recipes in openembedded-core which I would like to propose
> that we always update to the latest version on LTS and stable branches.
> These are recipes typically providing data that is expected to change
> over time, with little or no code.
> 
> You could say ca-certificates is already covered by the fact that
> security fixes are acceptable for example, but a clearer policy would be
> better.
> 
> Any policy change will go to the TSC for approval, the goal here is to
> get some review and input so that a concrete proposal can be put
> forward.
> 
> The recipes that come to my mind are:
> 
> - ca-certificates: To allow access to HTTPS resources we need to keep
>    these up-to-date.
> 
>      - Keeping this up-to-date is common practice in other distros.
> 
> - tzdata: To stay up to date with timezone or daylight savings changes.
> 
>      - Debian takes upgrades to this on stable branches
>        (see https://tracker.debian.org/pkg/tzdata).

I agree completely for the above two items.  Keeping these current is really 
important and history has shown that updating them doesn't cause issues.


The one below I don't have any experience with, so no opinion.

> - mobile-broadband-provider-info: To stay up to date with provider
>    changes.
> 
>      - The README file for this project says "The Package contains only
>        informational files so it's safe for distributions to grab updates
>        even during feature freeze and maintenance stages."
> 
> What opinions do other folks have?
> 
> Are there any other recipes we should include in this list?
> 
> Best regards,
> 
> 
> 
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#2275): https://lists.openembedded.org/g/openembedded-architecture/message/2275
> Mute This Topic: https://lists.openembedded.org/mt/117998481/3616948
> Group Owner: openembedded-architecture+owner@lists.openembedded.org
> Unsubscribe: https://lists.openembedded.org/g/openembedded-architecture/unsub [mark.hatle@kernel.crashing.org]
> -=-=-=-=-=-=-=-=-=-=-=-
> 

Re: [Openembedded-architecture] Recipes which should always be upgraded on stable branches

[Yoann Congal]

On Thu Feb 26, 2026 at 12:50 AM CET, Mark Hatle via lists.openembedded.org wrote:
> On 2/25/26 11:44 AM, Paul Barker wrote:
>> Hi all,
>> 
>> I've been briefly discussing stable branch update policy with Yoann.
>> There's a few recipes in openembedded-core which I would like to propose
>> that we always update to the latest version on LTS and stable branches.
>> These are recipes typically providing data that is expected to change
>> over time, with little or no code.
>> 
>> You could say ca-certificates is already covered by the fact that
>> security fixes are acceptable for example, but a clearer policy would be
>> better.
>> 
>> Any policy change will go to the TSC for approval, the goal here is to
>> get some review and input so that a concrete proposal can be put
>> forward.
>> 
>> The recipes that come to my mind are:
>> 
>> - ca-certificates: To allow access to HTTPS resources we need to keep
>>    these up-to-date.
>> 
>>      - Keeping this up-to-date is common practice in other distros.

Agreed but since CAs can be removed from the list, there is a
probability for breakage. We should acknowledge that. By spelling out
the CA addition/removal in the release notes maybe?

>> - tzdata: To stay up to date with timezone or daylight savings changes.
>> 
>>      - Debian takes upgrades to this on stable branches
>>        (see https://tracker.debian.org/pkg/tzdata).
>
> I agree completely for the above two items.  Keeping these current is really 
> important and history has shown that updating them doesn't cause issues.
>
>
> The one below I don't have any experience with, so no opinion.
>
>> - mobile-broadband-provider-info: To stay up to date with provider
>>    changes.
>> 
>>      - The README file for this project says "The Package contains only
>>        informational files so it's safe for distributions to grab updates
>>        even during feature freeze and maintenance stages."
>> 
>> What opinions do other folks have?

I also agree with updating those. I've looked at
mobile-broadband-provider-info for a recent stable upgrade and merged
it.

>> Are there any other recipes we should include in this list?

In addition of the wireless-regdb suggestion from Ankur, maybe we should
consider hwdata:
> hwdata contains various hardware identification and configuration data,
> such as the pci.ids and usb.ids databases.
I have no direct experience with it but it does seem to match this list.

>> Best regards,

Regards,
-- 
Yoann Congal
Smile ECS

Re: [Openembedded-architecture] Recipes which should always be upgraded on stable branches

[Nicolas Dechesne]

On Wed, Feb 25, 2026 at 6:44 PM Paul Barker <paul@pbarker.dev> wrote:
>
> Hi all,
>
> I've been briefly discussing stable branch update policy with Yoann.
> There's a few recipes in openembedded-core which I would like to propose
> that we always update to the latest version on LTS and stable branches.
> These are recipes typically providing data that is expected to change
> over time, with little or no code.
>
> You could say ca-certificates is already covered by the fact that
> security fixes are acceptable for example, but a clearer policy would be
> better.
>
> Any policy change will go to the TSC for approval, the goal here is to
> get some review and input so that a concrete proposal can be put
> forward.
>
> The recipes that come to my mind are:
>
> - ca-certificates: To allow access to HTTPS resources we need to keep
>   these up-to-date.
>
>     - Keeping this up-to-date is common practice in other distros.
>
> - tzdata: To stay up to date with timezone or daylight savings changes.
>
>     - Debian takes upgrades to this on stable branches
>       (see https://tracker.debian.org/pkg/tzdata).
>
> - mobile-broadband-provider-info: To stay up to date with provider
>   changes.
>
>     - The README file for this project says "The Package contains only
>       informational files so it's safe for distributions to grab updates
>       even during feature freeze and maintenance stages."
>
> What opinions do other folks have?
>
> Are there any other recipes we should include in this list?

I know this is going to be controversial.. what can we do to keep
linux-firmware a bit more up-to-date? the recipe in scarthgap has not
been updated since it was released. Other distros deal with
linux-firmware in various ways..

>
> Best regards,
>
> --
> Paul Barker
>
>
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#2275): https://lists.openembedded.org/g/openembedded-architecture/message/2275
> Mute This Topic: https://lists.openembedded.org/mt/117998481/9005974
> Group Owner: openembedded-architecture+owner@lists.openembedded.org
> Unsubscribe: https://lists.openembedded.org/g/openembedded-architecture/unsub [nicolas.dechesne@oss.qualcomm.com]
> -=-=-=-=-=-=-=-=-=-=-=-
>

Re: [Openembedded-architecture] Recipes which should always be upgraded on stable branches

[Richard Purdie]

On Thu, 2026-02-26 at 12:37 +0100, Nicolas Dechesne via lists.openembedded.org wrote:
> On Wed, Feb 25, 2026 at 6:44 PM Paul Barker <paul@pbarker.dev> wrote:
> > I've been briefly discussing stable branch update policy with Yoann.
> > There's a few recipes in openembedded-core which I would like to propose
> > that we always update to the latest version on LTS and stable branches.
> > These are recipes typically providing data that is expected to change
> > over time, with little or no code.
> > 
> > You could say ca-certificates is already covered by the fact that
> > security fixes are acceptable for example, but a clearer policy would be
> > better.
> > 
> > Any policy change will go to the TSC for approval, the goal here is to
> > get some review and input so that a concrete proposal can be put
> > forward.
> > 
> > The recipes that come to my mind are:
> > 
> > - ca-certificates: To allow access to HTTPS resources we need to keep
> >   these up-to-date.
> > 
> >     - Keeping this up-to-date is common practice in other distros.
> > 
> > - tzdata: To stay up to date with timezone or daylight savings changes.
> > 
> >     - Debian takes upgrades to this on stable branches
> >       (see https://tracker.debian.org/pkg/tzdata).
> > 
> > - mobile-broadband-provider-info: To stay up to date with provider
> >   changes.
> > 
> >     - The README file for this project says "The Package contains only
> >       informational files so it's safe for distributions to grab updates
> >       even during feature freeze and maintenance stages."
> > 
> > What opinions do other folks have?
> > 
> > Are there any other recipes we should include in this list?
> 
> I know this is going to be controversial.. what can we do to keep
> linux-firmware a bit more up-to-date? the recipe in scarthgap has not
> been updated since it was released. Other distros deal with
> linux-firmware in various ways..

The challenge is that linux-firmware is a totally different thing.

a) We have little idea what the internal changes in the firmware actually mean

b) The liunx-firmware recipe is complex and changes a lot

c) The firmware in the codebase has very different properties and
change controls, there is a lot lumped together and QCOM has different
policies and timelines for their changes compared to other vendors who
have firmware there (for exmaple)

d) The linux-firmware recipe itself has caused all kinds of regressions in the past

Yes, we have done a lot to address d) recently but it is far from clear
we would be safe due to the other issues.

Cheers,

Richard

Re: [Openembedded-architecture] Recipes which should always be upgraded on stable branches

[Nicolas Dechesne]

On Thu, Feb 26, 2026 at 12:49 PM Richard Purdie
<richard.purdie@linuxfoundation.org> wrote:
>
> On Thu, 2026-02-26 at 12:37 +0100, Nicolas Dechesne via lists.openembedded.org wrote:
> > On Wed, Feb 25, 2026 at 6:44 PM Paul Barker <paul@pbarker.dev> wrote:
> > > I've been briefly discussing stable branch update policy with Yoann.
> > > There's a few recipes in openembedded-core which I would like to propose
> > > that we always update to the latest version on LTS and stable branches.
> > > These are recipes typically providing data that is expected to change
> > > over time, with little or no code.
> > >
> > > You could say ca-certificates is already covered by the fact that
> > > security fixes are acceptable for example, but a clearer policy would be
> > > better.
> > >
> > > Any policy change will go to the TSC for approval, the goal here is to
> > > get some review and input so that a concrete proposal can be put
> > > forward.
> > >
> > > The recipes that come to my mind are:
> > >
> > > - ca-certificates: To allow access to HTTPS resources we need to keep
> > >   these up-to-date.
> > >
> > >     - Keeping this up-to-date is common practice in other distros.
> > >
> > > - tzdata: To stay up to date with timezone or daylight savings changes.
> > >
> > >     - Debian takes upgrades to this on stable branches
> > >       (see https://tracker.debian.org/pkg/tzdata).
> > >
> > > - mobile-broadband-provider-info: To stay up to date with provider
> > >   changes.
> > >
> > >     - The README file for this project says "The Package contains only
> > >       informational files so it's safe for distributions to grab updates
> > >       even during feature freeze and maintenance stages."
> > >
> > > What opinions do other folks have?
> > >
> > > Are there any other recipes we should include in this list?
> >
> > I know this is going to be controversial.. what can we do to keep
> > linux-firmware a bit more up-to-date? the recipe in scarthgap has not
> > been updated since it was released. Other distros deal with
> > linux-firmware in various ways..
>
> The challenge is that linux-firmware is a totally different thing.

Correct. And we already discussed that. I am hoping to get more
feedback about the overall idea. Or feedback about how others
typically use linux-firmware in LTS branches, since not updating it at
all seems problematic to me.

Other distros manage linux-firmware in different ways. Debian seems to
either take full upgrade, or cherry picks specific firmware files
upgrade. Ubuntu is stricter and only updates firmware files (or add
new files) on-demand, as needed.

>
> a) We have little idea what the internal changes in the firmware actually mean
>
> b) The liunx-firmware recipe is complex and changes a lot
>
> c) The firmware in the codebase has very different properties and
> change controls, there is a lot lumped together and QCOM has different
> policies and timelines for their changes compared to other vendors who
> have firmware there (for exmaple)
>
> d) The linux-firmware recipe itself has caused all kinds of regressions in the past
>
> Yes, we have done a lot to address d) recently but it is far from clear
> we would be safe due to the other issues.
>
> Cheers,
>
> Richard
>
>
>
>
>

Re: [Openembedded-architecture] Recipes which should always be upgraded on stable branches

[Richard Purdie]

On Thu, 2026-02-26 at 14:10 +0100, Nicolas Dechesne wrote:
> On Thu, Feb 26, 2026 at 12:49 PM Richard Purdie
> <richard.purdie@linuxfoundation.org> wrote:
> > 
> > On Thu, 2026-02-26 at 12:37 +0100, Nicolas Dechesne via lists.openembedded.org wrote:
> > > On Wed, Feb 25, 2026 at 6:44 PM Paul Barker <paul@pbarker.dev> wrote:
> > > > I've been briefly discussing stable branch update policy with Yoann.
> > > > There's a few recipes in openembedded-core which I would like to propose
> > > > that we always update to the latest version on LTS and stable branches.
> > > > These are recipes typically providing data that is expected to change
> > > > over time, with little or no code.
> > > > 
> > > > You could say ca-certificates is already covered by the fact that
> > > > security fixes are acceptable for example, but a clearer policy would be
> > > > better.
> > > > 
> > > > Any policy change will go to the TSC for approval, the goal here is to
> > > > get some review and input so that a concrete proposal can be put
> > > > forward.
> > > > 
> > > > The recipes that come to my mind are:
> > > > 
> > > > - ca-certificates: To allow access to HTTPS resources we need to keep
> > > >   these up-to-date.
> > > > 
> > > >     - Keeping this up-to-date is common practice in other distros.
> > > > 
> > > > - tzdata: To stay up to date with timezone or daylight savings changes.
> > > > 
> > > >     - Debian takes upgrades to this on stable branches
> > > >       (see https://tracker.debian.org/pkg/tzdata).
> > > > 
> > > > - mobile-broadband-provider-info: To stay up to date with provider
> > > >   changes.
> > > > 
> > > >     - The README file for this project says "The Package contains only
> > > >       informational files so it's safe for distributions to grab updates
> > > >       even during feature freeze and maintenance stages."
> > > > 
> > > > What opinions do other folks have?
> > > > 
> > > > Are there any other recipes we should include in this list?
> > > 
> > > I know this is going to be controversial.. what can we do to keep
> > > linux-firmware a bit more up-to-date? the recipe in scarthgap has not
> > > been updated since it was released. Other distros deal with
> > > linux-firmware in various ways..
> > 
> > The challenge is that linux-firmware is a totally different thing.
> 
> Correct. And we already discussed that.

We did, and you're asking the question again, clearly not happy with
the answer. You could have at least pointed at the previous discussion
and made it clear you were looking for alternatives to updating
wholesale. I can't see updating it wholesale as being realistically
possible.

> I am hoping to get more feedback about the overall idea.

We already discussed that! ;-)

> Or feedback about how others typically use linux-firmware in LTS branches, 

The question needs to be clear.

> since not updating it at all seems problematic to me.

I do agree, however the question did appear to be whether that was more
or less problematic than a complete upgrade.

> Other distros manage linux-firmware in different ways. Debian seems to
> either take full upgrade, or cherry picks specific firmware files
> upgrade. Ubuntu is stricter and only updates firmware files (or add
> new files) on-demand, as needed.

Would/could someone take on "stable" updates to linux-firmware?

This could be stable branch releases of firmware where the contributors
are attesting it is fixes only? I can see plenty of potential problems
but if someone did try and make a go of that it might be easier for us
and the other distros to get behind?

Alternatively, a mix in layer? That is one of our other options.

Cheers,

Richard

Re: [Openembedded-architecture] Recipes which should always be upgraded on stable branches

[Ricardo Salveti]

On Thu, Feb 26, 2026 at 10:58 AM Richard Purdie via
lists.openembedded.org
<richard.purdie=linuxfoundation.org@lists.openembedded.org> wrote:
> On Thu, 2026-02-26 at 14:10 +0100, Nicolas Dechesne wrote:
> > Other distros manage linux-firmware in different ways. Debian seems to
> > either take full upgrade, or cherry picks specific firmware files
> > upgrade. Ubuntu is stricter and only updates firmware files (or add
> > new files) on-demand, as needed.
>
> Would/could someone take on "stable" updates to linux-firmware?
>
> This could be stable branch releases of firmware where the contributors
> are attesting it is fixes only? I can see plenty of potential problems
> but if someone did try and make a go of that it might be easier for us
> and the other distros to get behind?
>
> Alternatively, a mix in layer? That is one of our other options.

As we are getting closer to wrynose release, this came back again due
our own specific need to keep updating linux-firmware, and I believe
the mixin layer will probably be easier to manage for everyone (we can
be initial layer maintainers).

I believe we don't expect another linux-firmware bump for wrynose, so
any release post 20260410 could go to this mixin layer, would that be
fine with you all?

Thanks,
-- 
Ricardo Salveti

Re: Recipes which should always be upgraded on stable branches

[Yoann Congal]

On Wed Feb 25, 2026 at 6:44 PM CET, Paul Barker wrote:
> Hi all,
>
> I've been briefly discussing stable branch update policy with Yoann.
> There's a few recipes in openembedded-core which I would like to propose
> that we always update to the latest version on LTS and stable branches.
> These are recipes typically providing data that is expected to change
> over time, with little or no code.
>
> You could say ca-certificates is already covered by the fact that
> security fixes are acceptable for example, but a clearer policy would be
> better.
>
> Any policy change will go to the TSC for approval, the goal here is to
> get some review and input so that a concrete proposal can be put
> forward.
>
> The recipes that come to my mind are:
>
> - ca-certificates: To allow access to HTTPS resources we need to keep
>   these up-to-date.
>
>     - Keeping this up-to-date is common practice in other distros.
>
> - tzdata: To stay up to date with timezone or daylight savings changes.
>
>     - Debian takes upgrades to this on stable branches
>       (see https://tracker.debian.org/pkg/tzdata).
>
> - mobile-broadband-provider-info: To stay up to date with provider
>   changes.
>
>     - The README file for this project says "The Package contains only
>       informational files so it's safe for distributions to grab updates
>       even during feature freeze and maintenance stages."
>
> What opinions do other folks have?
>
> Are there any other recipes we should include in this list?
>
> Best regards,

Hello all,

A quick update on this:
The YP TSC discussed and agreed that:
* ca-certificates,
* tzdata,
* wireless-regdb and 
* mobile-broadband-provider-info
can be regularly upgraded on stable branches.

So I'll gladly accept those upgrades.

Note that (as Paul noticed) the tzdata 2026a release announcement says
"It also has significant changes to code and to the build procedure.".
So some care will have to taken there...

Regards,
-- 
Yoann Congal
Smile ECS