On Thu, 15 Dec 2022 at 22:33, Alex Kiernan <alex.kiernan@gmail.com> wrote:

> On Thu, Dec 15, 2022 at 9:45 PM Alejandro Enedino Hernandez Samaniego
> <alejandro@enedino.org> wrote:
> >
> >
> >
> > On Thu, Dec 15, 2022, 3:36 PM Alex Kiernan <alex.kiernan@gmail.com>
> wrote:
> >>
> >> On Thu, Dec 15, 2022 at 6:24 PM Alejandro Enedino Hernandez Samaniego
> >> <alejandro@enedino.org> wrote:
> >> >
> >> >
> >> >
> >> > On Thu, 15 Dec 2022 at 11:11, Alejandro Enedino Hernandez Samaniego <
> alejandro@enedino.org> wrote:
> >> >>
> >> >>
> >> >> On Thu, 15 Dec 2022 at 11:03, Alexander Kanavin <
> alex.kanavin@gmail.com> wrote:
> >> >>>
> >> >>> On Thu, 15 Dec 2022 at 19:01, Alexander Kanavin via
> >> >>> lists.openembedded.org <alex.kanavin=
> gmail.com@lists.openembedded.org>
> >> >>> wrote:
> >> >>> > Ok, I think what we should do first is to actually drop the
> version
> >> >>> > from all of the .bb file names, and set it once, inside some
> .inc, and
> >> >>> > probably next to SRC_URI and tarball checksum. Then this should
> allow
> >> >>> > a convenient scheme for including and overriding things.
> >> >>> >
> >> >>> > rust_1.65.0.bb - > rust.bb, and so on.
> >> >>>
> >> >>> Oh, and upstream version checks must be kept functional. It needs to
> >> >>> both correctly report a newer version, and match the recipe version
> >> >>> with upstream if it is already the latest.
> >> >>>
> >> >>> Alex
> >> >>
> >> >>
> >> >> How should I test that upstream checks are still functional?
> >> >>
> >> >>
> >> > Actually how would this make it any simpler?, if we remove PV from
> the filenames, the correct place to put the variable is in rust-source.inc
> since all others include it (rust-cross-canadian, rust, rust-llvm), if like
> I said, rust-source.inc gets included from somewhere else, wouldnt that
> override PV for the other recipe as well? beating the whole purpose of the
> change, this, or creating a new .inc file just for this seems too
> convoluted IMO.
> >> >
> >> > If changing RUST_VERSION is too problematic on every upgrade I think
> approach #2 its a lot simpler just specifying RUST_VERSION on other recipes
> since it would be very seldom used and it wont conflict with upgrades
> >> >
> >>
> >> Actually changing it is clearly straightforward, the problem is that
> >> upgrading the rust version is already tricky because of the need to
> >> regenerate the cargo checksums, so every extra step is something that
> >> you have to remember to do.
> >>
> >> Which leaves me wondering how introducing nightly/beta actually work
> >> with those patches?
> >
> >
> > I understand that , the checksums/patches shouldn't cause any problem
> since as its explained in the commit message beta/nightly builds from the
> exact same sources, hence patches should apply and checksums wouldn't
> change.
> >
>
> Sorry, now I'm properly confused, if the sources don't change, how is
> this beta/nightly?
>
> cargo-checksum.json is basically completely non-patch friendly, you
> have to fix it up every time as its based on the vendored sources in
> the tarball.
>
> --
> Alex Kiernan
>

Yes, I was confused at first myself, the channel actually works as a build
time flag, setting it to "beta" would enable the beta
features that already in the source code at the time of every release, same
with nightly hence why there are no extra conflicts
when doing upgrades..

I actually just did the upgrade from 1.65.0 to 1.66.0 to test this (I just
wasn't able to test target/native/nativesdk and all the arch
variants before yours went in) and using different channels worked like a
charm, no extra checksum changes other than the ones
we have in our patches already.

I'll be sending a v2 rebased on top of your 1.66.0 upgrade.

Alejandro