Hi, it has been requested many times and just makes sense currently rust is slotted as, for example stable/1.34 the intention is to slot it per version 1.32 1.34 etc so users can have 1.32 and 1.34 installed. we'll need something similar to LLVM_MAX_SLOT to pull exact slot in ebuilds that require it. thoughts, options, caveats? I haven't really looked at it yet, but there've been reports it should be painless enough. I know that non-virtual cargo has to go before we can do that.
I think it's not at all clear that this makes sense. First of all, rust has been very good about backwards compatibility, so I don't see an important use case for preserving old versions of the compiler. Second, upstream delivers no support at all for old stable releases, so (especially in terms of security and vulnerability handling) we should strive to keep our rust versions close to current upstream stable so they're actually supported. What use cases do you have for slotting Rust?
There are use cases like this: https://bugs.gentoo.org/679656#c2
Another usecase: Building rust itself. Since now I'm getting segfaults from the internally shipped version.
(In reply to Mark Gomersbach from comment #3) > Another usecase: Building rust itself. > Since now I'm getting segfaults from the internally shipped version. Disregard message and sorry for the noise. After strace it turned out to be my virus scanner.
I'm no longer going to pursue this due to way rust wants rustlib path always to be /usr/lib/rustlib. single slot version seems to be ok so far.
Are there bug reported somewhere? Versioned slotting still working for stable 1.40 and nightly 9999.
(In reply to Oleg from comment #6) > Are there bug reported somewhere? Versioned slotting still working for > stable 1.40 and nightly 9999. https://bugs.gentoo.org/703744 moving rust libs to /usr/lib/rustlib allows us do system-rust bootstrap, previously it was failing unable to find stblib during bootstrap, because it looks for <sysroot>/rustlib if rust stuff installed to /usr/lib/rust-<ver> like it was before, bootstrap and tools can no longer find rustlib. alternatively installing rust to isolated dir also allows to pass --sysroot (like it works with /opt/rust-<ver>) pretty sure with some modifications/patches to rust it's possible to modify rustlib search path, but some external tools (including cargo itself) always assume this path relative to sysroot.
I don't get issues with rustlib placement when building other rust code. I'll try to look if it is issue in the bootstrap itself.
Oh, I've missed when stable rust switched to plain libdir.
example falure here https://bugs.gentoo.org/706292 this is what happens when someone tries to bootstrap new rust with system-installed rust which is not in /usr/lib/rustlib this happens if bootstrap passes sysroot=/usr /usr path is result of $(rustc --print sysroot)
I've opened PR to fix it: https://github.com/rust-lang/rust/pull/69608 Could this issue be reopened, and rust ebuild started on 1.43 return to versioned libdir?
sure, let's track libdir issues in bug https://bugs.gentoo.org/703744
As libdir issue was fixed should this bug be reopened?
I see it's merged in https://github.com/rust-lang/rust/commit/8f1c0d0a10761b70d74bec7a537a25cb54f42b61 slotting it will require a bit more work in eclasses and ebuilds to pull it properly (sorta like llvm does) I'd avoid it for now. but we can leave it open and see how situation develops. I simply lack time and there's no REAL need for it now. it's sometimes convenient to have multiple versions installed, true. any other reasons? honest question, I'm not mocking or anything, just curious. I changed my mind a bit since I opened this bug.
I use it to have stable and nightly version together without rustup.
(In reply to Oleg from comment #15) > I use it to have stable and nightly version together without rustup. that should be possible again after changes, no worries. I was talking about having 1.44 1.45 installed together, for example. that's not happening for now.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=75a4d1ee6422c5e2d3984e1e7c51e65dcce66c96 commit 75a4d1ee6422c5e2d3984e1e7c51e65dcce66c96 Author: Georgy Yakovlev <gyakovlev@gentoo.org> AuthorDate: 2020-07-17 00:39:23 +0000 Commit: Georgy Yakovlev <gyakovlev@gentoo.org> CommitDate: 2020-07-17 06:35:02 +0000 dev-lang/rust: bump to 1.45.0 move a lot of deps to BDEPEND Bug: https://bugs.gentoo.org/703744 Bug: https://bugs.gentoo.org/683420 Bug: https://bugs.gentoo.org/731764 Package-Manager: Portage-2.3.103, Repoman-2.3.23 Signed-off-by: Georgy Yakovlev <gyakovlev@gentoo.org> dev-lang/rust/Manifest | 15 ++ dev-lang/rust/rust-1.45.0.ebuild | 503 +++++++++++++++++++++++++++++++++++++++ 2 files changed, 518 insertions(+)
rust itself bootstrapped fine but I still ran into different issues. so 1.45.0 still installs to /usr/lib/rustlib directly.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=d4e6ca7891bdea48a8214f8ca2a675ce00c65604 commit d4e6ca7891bdea48a8214f8ca2a675ce00c65604 Author: Georgy Yakovlev <gyakovlev@gentoo.org> AuthorDate: 2020-08-03 20:08:15 +0000 Commit: Georgy Yakovlev <gyakovlev@gentoo.org> CommitDate: 2020-08-03 20:11:39 +0000 dev-lang/rust: bump to 1.45.2 Install rustlib to versioned subdirectory in /usr/lib* again Bug: https://bugs.gentoo.org/703744 Bug: https://bugs.gentoo.org/683420 Package-Manager: Portage-3.0.1, Repoman-2.3.23 Signed-off-by: Georgy Yakovlev <gyakovlev@gentoo.org> dev-lang/rust/Manifest | 1 + dev-lang/rust/rust-1.45.2.ebuild | 521 +++++++++++++++++++++++++++++++++++++++ 2 files changed, 522 insertions(+)
1.45.2 installs to /usr/lib*/rust-{ver} again. I'm closing this bug.
