On Tue, Mar 7, 2023 at 10:48 AM Jose Quaresma <quaresma.j...@gmail.com> wrote: > > > > Bruce Ashfield <bruce.ashfi...@gmail.com> escreveu no dia terça, 7/03/2023 > à(s) 15:15: >> >> 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. > > > Having on meta-virt more than one version available on the stable/lts branches > looks like a great improvement. The newest version can use > default_prefference -1 > so we can maintain some type of abi/api stabilization enabled by default. > > However it will always be difficult to decide which version of golang the > tool on meta-virt needs. > And of course, the adicional maintenance overhead can increase a lot.
Having battled the go applications in meta-virt for a long time now, it really isn't all that often we have issues with golang versions, in the sense of needing matched versions. It is normally new features that are required, versus a new golang dropping features. So a newer go has almost always worked for all the versions we need. The extra maintenance isn't significant, in particular when balanced around trying to keep a centre of gravity around the recipes. Bruce > > Jose > >> >> 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 > > > > -- > 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 (#178113): https://lists.openembedded.org/g/openembedded-core/message/178113 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] -=-=-=-=-=-=-=-=-=-=-=-
