On Sat, Dec 17, 2022 at 1:20 AM Alejandro Enedino Hernandez Samaniego <alejan...@enedino.org> wrote: > > > > > On Thu, 15 Dec 2022 at 22:33, Alex Kiernan <alex.kier...@gmail.com> wrote: >> >> On Thu, Dec 15, 2022 at 9:45 PM Alejandro Enedino Hernandez Samaniego >> <alejan...@enedino.org> wrote: >> > >> > >> > >> > On Thu, Dec 15, 2022, 3:36 PM Alex Kiernan <alex.kier...@gmail.com> wrote: >> >> >> >> On Thu, Dec 15, 2022 at 6:24 PM Alejandro Enedino Hernandez Samaniego >> >> <alejan...@enedino.org> wrote: >> >> > >> >> > >> >> > >> >> > On Thu, 15 Dec 2022 at 11:11, Alejandro Enedino Hernandez Samaniego >> >> > <alejan...@enedino.org> wrote: >> >> >> >> >> >> >> >> >> On Thu, 15 Dec 2022 at 11:03, Alexander Kanavin >> >> >> <alex.kana...@gmail.com> wrote: >> >> >>> >> >> >>> On Thu, 15 Dec 2022 at 19:01, Alexander Kanavin via >> >> >>> lists.openembedded.org <alex.kanavin=gmail....@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.. >
Oh I see... that makes sense now! -- Alex Kiernan
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#174780): https://lists.openembedded.org/g/openembedded-core/message/174780 Mute This Topic: https://lists.openembedded.org/mt/95684480/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
