On Thu, Dec 15, 2022 at 9:45 PM Alejandro Enedino Hernandez Samaniego <[email protected]> wrote: > > > > On Thu, Dec 15, 2022, 3:36 PM Alex Kiernan <[email protected]> wrote: >> >> On Thu, Dec 15, 2022 at 6:24 PM Alejandro Enedino Hernandez Samaniego >> <[email protected]> wrote: >> > >> > >> > >> > On Thu, 15 Dec 2022 at 11:11, Alejandro Enedino Hernandez Samaniego >> > <[email protected]> wrote: >> >> >> >> >> >> On Thu, 15 Dec 2022 at 11:03, Alexander Kanavin <[email protected]> >> >> wrote: >> >>> >> >>> On Thu, 15 Dec 2022 at 19:01, Alexander Kanavin via >> >>> lists.openembedded.org <[email protected]> >> >>> 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
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#174729): https://lists.openembedded.org/g/openembedded-core/message/174729 Mute This Topic: https://lists.openembedded.org/mt/95684480/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
