Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 683420 - dev-lang/rust versioned slotting
Summary: dev-lang/rust versioned slotting
Status: RESOLVED WONTFIX
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Gentoo Rust Project
URL:
Whiteboard:
Keywords:
Depends on: 675026 683392
Blocks:
  Show dependency tree
 
Reported: 2019-04-15 19:01 UTC by Georgy Yakovlev
Modified: 2020-08-03 20:15 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Georgy Yakovlev archtester gentoo-dev 2019-04-15 19:01:13 UTC
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.
Comment 1 Dirkjan Ochtman (RETIRED) gentoo-dev 2019-04-16 07:08:24 UTC
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?
Comment 2 Oleg 2019-04-16 17:35:05 UTC
There are use cases like this: https://bugs.gentoo.org/679656#c2
Comment 3 Mark Gomersbach 2019-07-18 08:55:15 UTC
Another usecase: Building rust itself.
Since now I'm getting segfaults from the internally shipped version.
Comment 4 Mark Gomersbach 2019-07-18 17:05:47 UTC
(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.
Comment 5 Georgy Yakovlev archtester gentoo-dev 2020-02-22 10:23:54 UTC
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.
Comment 6 Oleg 2020-03-01 04:08:52 UTC
Are there bug reported somewhere? Versioned slotting still working for stable 1.40 and nightly 9999.
Comment 7 Georgy Yakovlev archtester gentoo-dev 2020-03-01 08:36:03 UTC
(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.
Comment 8 Oleg 2020-03-01 08:41:24 UTC
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.
Comment 9 Oleg 2020-03-01 08:53:45 UTC
Oh, I've missed when stable rust switched to plain libdir.
Comment 10 Georgy Yakovlev archtester gentoo-dev 2020-03-01 09:53:27 UTC
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)
Comment 11 Oleg 2020-03-01 16:06:45 UTC
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?
Comment 12 Georgy Yakovlev archtester gentoo-dev 2020-03-30 20:22:01 UTC
sure, let's track libdir issues in bug https://bugs.gentoo.org/703744
Comment 13 Oleg 2020-07-01 06:08:23 UTC
As libdir issue was fixed should this bug be reopened?
Comment 14 Georgy Yakovlev archtester gentoo-dev 2020-07-01 07:07:42 UTC
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.
Comment 15 Oleg 2020-07-01 07:11:46 UTC
I use it to have stable and nightly version together without rustup.
Comment 16 Georgy Yakovlev archtester gentoo-dev 2020-07-01 17:22:42 UTC
(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.
Comment 17 Larry the Git Cow gentoo-dev 2020-07-17 06:36:16 UTC
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(+)
Comment 18 Georgy Yakovlev archtester gentoo-dev 2020-07-17 06:40:50 UTC
rust itself bootstrapped fine but I still ran into different issues. so 1.45.0 still installs to /usr/lib/rustlib directly.
Comment 19 Larry the Git Cow gentoo-dev 2020-08-03 20:14:44 UTC
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(+)
Comment 20 Georgy Yakovlev archtester gentoo-dev 2020-08-03 20:15:49 UTC
1.45.2 installs to /usr/lib*/rust-{ver} again.

I'm closing this bug.