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. I'll be sending a v2 later today Alejandro > > > -- > Alex Kiernan >
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#174728): https://lists.openembedded.org/g/openembedded-core/message/174728 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] -=-=-=-=-=-=-=-=-=-=-=-
