1 |
On Mon, 2022-01-17 at 21:58 -0500, Ionen Wolkens wrote: |
2 |
> On Mon, Jan 17, 2022 at 03:24:23PM -0800, Georgy Yakovlev wrote: |
3 |
> > Hi, |
4 |
> > |
5 |
> > I've been approached multiple times with that request, and a lot of |
6 |
> > time I see new users completely destroyed by rust build time and |
7 |
> > disk |
8 |
> > space requirements. |
9 |
> |
10 |
> fwiw it may be a bit mitigated by the new desktop stages that come |
11 |
> with |
12 |
> rust, or at least it won't be the first thing they see when they try |
13 |
> to build their brand new desktop install until a rust update. |
14 |
> |
15 |
> It's nice if users can get a basic desktop before worrying about how |
16 |
> to |
17 |
> handle rust. Not that desktop stages are heavily visible/known so new |
18 |
> users may not always pick them. |
19 |
indeed it helps, but it takes time for users to discover/consider this. |
20 |
it mostly hits very new users or users of containers/vms, who don't |
21 |
have enough disk space or ram. |
22 |
> |
23 |
> > |
24 |
> > WDYT about switching order of rusts in a virtual? |
25 |
> > |
26 |
> > RDEPEND="|| ( |
27 |
> > ~dev-lang/rust-${PV} |
28 |
> > ~dev-lang/rust-bin-${PV} |
29 |
> > )" |
30 |
> > |
31 |
> > |
32 |
> > becomes |
33 |
> > |
34 |
> > RDEPEND="|| ( |
35 |
> > ~dev-lang/rust-bin-${PV} |
36 |
> > ~dev-lang/rust-${PV} |
37 |
> > )" |
38 |
> > |
39 |
> > |
40 |
> > Existing installs should be unaffected ofc. |
41 |
> > But portage may prefer to depclean rust and not rust-bin if both |
42 |
> > are |
43 |
> > present. |
44 |
> |
45 |
> Haven't tested how it reacts, but wouldn't that be an issue with |
46 |
> system-bootstrap in situations where it pulls rust-bin to build |
47 |
> itself? |
48 |
it can build itself with non-bin too. as long as it's same or ver- |
49 |
minus-1 and is installed, if not installed it will pull rust-bin of |
50 |
matching version. |
51 |
also system-bootstrap is stable-masked (for various reasons), so I'm |
52 |
not too worried about it. ~kw users know their way around. |
53 |
|
54 |
> |
55 |
> > Users who wish to use source version at all times can just add it |
56 |
> > to |
57 |
> > world file. |
58 |
> > |
59 |
> > I see both positives and negatives of doing that, but would like to |
60 |
> > reach out to community first. |
61 |
> |
62 |
> Unsure what I like best, I generally agree should default to sources |
63 |
> but I do see new users complaining about building rust every few |
64 |
> days. |
65 |
> Not that the step of telling them that rust-bin exists is that bad |
66 |
> (part of the issue is that they don't know it's an option). |
67 |
> |
68 |
|
69 |
If I had clear answer myself I would not be asking opinions here =) |
70 |
just trying to understand if I'm missing something or my view is too |
71 |
different. |
72 |
developer and user opinions all are helpful to build picture. |
73 |
I receive at least weekly complaint about how resource-intensive rust |
74 |
build is, that counts too. |
75 |
|
76 |
for now on stable systems, if user types, let's say, |
77 |
$ emerge ripgrep |
78 |
|
79 |
with USE=-system-bootsrap (the default): |
80 |
portage will pull virtual/rust, which will pull dev-lang/rust, which |
81 |
will bootstrap itself by downloading proper rust-bin tarball, but not |
82 |
as a package, just as a tarball behind the scenes. |
83 |
|
84 |
with USE=system-bootstrap: |
85 |
portage will pull virtual/rust, which will pull dev-lang/rust-bin, and |
86 |
build dev-lang/rust, to build ripgrep. |
87 |
|
88 |
USE=system-llvm (also stable-masked) complicates picture even more. |
89 |
|
90 |
We've had openjdk-bin and icedtea-bin as default provider for as long |
91 |
as I can remember, before I started to maintain it. works fine. |
92 |
|
93 |
PS: |
94 |
and just to be clear - I'm not pushing for it, just asking for input. |