On Tue, Mar 7, 2023 at 9:58 AM Jose Quaresma <quaresma.j...@gmail.com> wrote: > > > > 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.
Right. You may still need some sort of mixin layer (for go, etc), I'm more saying that I would be willing to get whatever version of meta-virt tools available in the appropriate branches, since it doesn't mean a forced upgrade to all users if we just keep the multiple versions around. Bruce > > 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 -- - 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 (#178109): https://lists.openembedded.org/g/openembedded-core/message/178109 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] -=-=-=-=-=-=-=-=-=-=-=-
