Bruce Ashfield <bruce.ashfi...@gmail.com> escreveu no dia terça, 7/03/2023 à(s) 13:52:
> 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. > One of the problems with this approach of using the master branch of meta-virt is because some go recipes/projects require a recent version of the golang to build the latest version. At last the golang needs to be backported on the mixin layer to circumvent these problems. Anyway I will try to build oe-core kirkstone with meta-virt master branch to get a better overview of the build requirements. Jose > > 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 > -- Best regards, José Quaresma
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#178107): https://lists.openembedded.org/g/openembedded-core/message/178107 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] -=-=-=-=-=-=-=-=-=-=-=-
