From: Paul Barker <paul@pbarker.dev>
To: Yoann Congal <yoann.congal@smile.fr>,
"openembedded-core@lists.openembedded.org"
<openembedded-core@lists.openembedded.org>,
"openembedded-architecture@lists.openembedded.org"
<openembedded-architecture@lists.openembedded.org>
Subject: Recipes which should always be upgraded on stable branches
Date: Wed, 25 Feb 2026 17:44:23 +0000 [thread overview]
Message-ID: <1e6175f982bbd141fcc156113aa6e798a3120bdc.camel@pbarker.dev> (raw)
[-- 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 --]
next reply other threads:[~2026-02-25 17:44 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-25 17:44 Paul Barker [this message]
2026-02-25 19:04 ` [OE-core] Recipes which should always be upgraded on stable branches Ankur Tyagi
2026-02-25 23:50 ` [Openembedded-architecture] " Mark Hatle
2026-02-26 9:24 ` Yoann Congal
2026-02-26 11:37 ` Nicolas Dechesne
2026-02-26 11:49 ` Richard Purdie
2026-02-26 13:10 ` Nicolas Dechesne
2026-02-26 13:58 ` Richard Purdie
2026-04-30 21:37 ` Ricardo Salveti
2026-03-06 10:29 ` Yoann Congal
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1e6175f982bbd141fcc156113aa6e798a3120bdc.camel@pbarker.dev \
--to=paul@pbarker.dev \
--cc=openembedded-architecture@lists.openembedded.org \
--cc=openembedded-core@lists.openembedded.org \
--cc=yoann.congal@smile.fr \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox