On Thu, 2026-02-26 at 14:10 +0100, Nicolas Dechesne wrote: > On Thu, Feb 26, 2026 at 12:49 PM Richard Purdie > <[email protected]> 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 <[email protected]> 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
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#232027): https://lists.openembedded.org/g/openembedded-core/message/232027 Mute This Topic: https://lists.openembedded.org/mt/118010472/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
