On Fri, 9 Jun 2023, Jose Quaresma wrote: > Hi Scott, > > Can this branch be renamed to just rust? > > -kirkstone/rust-1.68 > +kirkstone/rust > > rust is now on 1.70 in core and it would be useful in my opinion to > backport what is in the master and not just the 1.68 > https://git.yoctoproject.org/poky/commit/?id=5035a8588bb27e029661a500215dd4e83f023ac6
No. As I say in the README in the branch: - The intent is to just track any further 1.68.x upgrades that occur in the mickledore branch of oe-core. Supporting newer versions of Rust or trying to support more than one version of Rust should use a different mixin layer. I see two paths to do what you ask, both of which IMO have issues wrt my usecase of a hopefully stable mixin layer to use on top of kirkstone: 1. Keep sticking the latest Rust from master into a mixin branch in meta-lts-mixins. This likely will make some folks happy, but my issue with doing that in the branch I want to use against kirkstone is that while chances are slim that the Rust team go back and do a 1.68.x point release, I know 1.68.x works with the combination of kirkstone and the target software in Automotive Grade Linx (AGL), and just bumping the mixin layer to latest Rust as it comes into master would complicate later trying to pick up any fixes for 1.68.x from mickledore if they do happen. I may potentially need to worry about a version bump when mickledore goes out of maintenance, but at the moment my plan is to stick with 1.68.x until we upgrade AGL to Yocto Project 4.4 next spring. If you want to take the kirkstone/rust-1.68.x mixin as the starting point of a plain "rust" mixin layer that you will maintain against master's Rust version, please go ahead. 2. Supporting more than one version in a mixin layer. Since the rust .inc files are not versioned, this will require some (hopefully minor) manual tinkering. The first drawback is that cherry-picks of updates afterwards will then all need to be done in a more manual fashion. The second drawback is that since oe-core only carries a single version of Rust, extra testing against the two or more versions present will need to be done to make they sure they all work, and to be certain of compatibility, this likely will take adding the multiple versions of cargo, rigging up CARGO_VERSION, etc., and also testing that. I have no desire to expend the effort required for that, and if I were to need a newer version of Rust for AGL, I would probably once again just submit a mixin with a single version. It seemed to be the consensus on the YP technical calls that this was a reasonable approach. Best regards, Scott
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#60259): https://lists.yoctoproject.org/g/yocto/message/60259 Mute This Topic: https://lists.yoctoproject.org/mt/98827520/21656 Group Owner: [email protected] Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
