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