On Tue, Mar 7, 2023 at 7:15 AM Mikko Rapeli <mikko.rap...@linaro.org> wrote: > > Hi, > > On Tue, Mar 07, 2023 at 11:43:32AM +0000, Jose Quaresma wrote: > > Hi, > > > > At Foundries.io we intend to update the docker version on the kirkstone > > branch to the latest available upstream, currently v23. > > Looks like the better approach can be doing that in the mixin layer, > > for that a new kirstone lts branch will be required. > > FWIW, meta-virtualization master branch works well with kirkstone and > docker can be updated that way.
And I'm also happy to maintain multiple versions in the released meta-virt branches, that way we can keep compatibility, but also offer a newer version that can be selected by preferred version. I'd rather have the main/supported recipes in the layers where most of the effort is placed, versus spraying them around in mixin layers. But as Mikko said, also consider just trying master against the release, as chances are it is fine, and the branching is just to put a stake in the ground for when the release happened. Bruce > > Many layers remove layer compatibility with older LTS releases even when > technically recipes still work, at least with very few exceptions. > > > This requires a golang update as well but the golang on master is broken > > for some cases when -linkshared is in use and we are still debugging this > > issue. > > I pretend to start this backport when I can stabilize first the golang 1.20 > > on master. > > Cherry-picking go patches from poky master to kirkstone also works once > the kirkstone specific security updates have been reverted. > > Even if Alex disagrees, CVE patch backporting is needed when SW > components break APIs and ABIs between releases. For mature and API/ABI > compatible SW components the updates are trivial, but even with them > there are exceptions and surprises. > > I think yocto maintainers can make sensible decisions and compromises for SW > components and features which get updates vs which get CVE security patches. I > think many "development only" tools can also be updated quite freely > also in LTS branches. For example CVE and SPDX tooling, maybe even > bitbake itself, git, subversion etc. gcc and libc do break things on major > updates, same for > clang. go, rust, perl, python have possibly more stable updates so those > could be aligned with all maintained branches. If no-one is posting CVE > patches for complex SW components to LTS branches then I'd update them > to latest release or even master branch rather than keep the affected > CVEs open for ever. If there are not enough maintainers/resources, then even > breaking the API compatibility is ok. nodejs, rust, go, webkit, tiff etc are > really pain to maintain and thus updating them to latest release should be > considered even if APIs change. > > Cheers, > > -Mikko > > > -- - Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end - "Use the force Harry" - Gandalf, Star Trek II
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#178106): https://lists.openembedded.org/g/openembedded-core/message/178106 Mute This Topic: https://lists.openembedded.org/mt/97444547/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
