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

[Richard Purdie <richard.purdie@linuxfoundation.org>]

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