Bruce Ashfield <[email protected]> escreveu no dia terça, 7/03/2023 à(s) 15:15:
> On Tue, Mar 7, 2023 at 9:58 AM Jose Quaresma <[email protected]> > wrote: > > > > > > > > Bruce Ashfield <[email protected]> escreveu no dia terça, > 7/03/2023 à(s) 13:52: > >> > >> On Tue, Mar 7, 2023 at 7:15 AM Mikko Rapeli <[email protected]> > 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. 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
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#178112): https://lists.openembedded.org/g/openembedded-core/message/178112 Mute This Topic: https://lists.openembedded.org/mt/97444547/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
