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: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
