View previous topic :: View next topic |
Author |
Message |
Tony0945 Watchman
Joined: 25 Jul 2006 Posts: 5127 Location: Illinois, USA
|
|
Back to top |
|
|
asturm Developer
Joined: 05 Apr 2007 Posts: 8938
|
Posted: Tue Sep 01, 2020 6:48 pm Post subject: |
|
|
No.
Gentoo has already shielded you for about ~2 years from that dependency. |
|
Back to top |
|
|
belze n00b
Joined: 21 Jul 2007 Posts: 12
|
Posted: Tue Sep 01, 2020 7:00 pm Post subject: |
|
|
Thanks in advice for your work here at gentoo forums.
I did not have rust installed in my system, and got forced to pull it down. I tried to compile but my sandybridge machine is not powerful enough. I would like to use rust-bin, so i emerged it but after that virtual/rust pulls is rust sources again.
What am I missing? |
|
Back to top |
|
|
ebray187 Tux's lil' helper
Joined: 02 Mar 2005 Posts: 121 Location: Al otro lado de la pantalla
|
Posted: Tue Sep 01, 2020 7:32 pm Post subject: |
|
|
belze wrote: | Thanks in advice for your work here at gentoo forums.
I did not have rust installed in my system, and got forced to pull it down. I tried to compile but my sandybridge machine is not powerful enough. I would like to use rust-bin, so i emerged it but after that virtual/rust pulls is rust sources again.
What am I missing? |
Masking rust should not be the same as installing rust-bin. After masking it, portage should resolve all for you:
# echo "dev-lang/rust" >> /etc/package.mask
Also, if you manually install rust-bin, then maybe you want to remove it from your world file:
# emerge -a --deselect dev-lang/rust-bin _________________ # emerge -C world >> 9/8
A flower?!
Last edited by ebray187 on Tue Sep 01, 2020 7:39 pm; edited 1 time in total |
|
Back to top |
|
|
asturm Developer
Joined: 05 Apr 2007 Posts: 8938
|
Posted: Tue Sep 01, 2020 7:37 pm Post subject: |
|
|
Actually the masking shouldn't be necessary, and the described behaviour doesn't make much sense. If rust-bin is present (e.g. by having run `emerge -1 rust-bin`), then the dependency of the virtual is satisfied, and portage will not try to pull in rust anymore. |
|
Back to top |
|
|
ebray187 Tux's lil' helper
Joined: 02 Mar 2005 Posts: 121 Location: Al otro lado de la pantalla
|
Posted: Tue Sep 01, 2020 7:45 pm Post subject: |
|
|
asturm wrote: | Actually the masking shouldn't be necessary, and the described behaviour doesn't make much sense. |
Thanks for the clarification. Years ago something similar happened to me, so I assumed portage worked that way.
Everyday you learn something new.
Regards _________________ # emerge -C world >> 9/8
A flower?! |
|
Back to top |
|
|
figueroa Advocate
Joined: 14 Aug 2005 Posts: 2965 Location: Edge of marsh USA
|
Posted: Tue Sep 01, 2020 8:04 pm Post subject: |
|
|
asturm wrote: | Actually the masking shouldn't be necessary, and the described behaviour doesn't make much sense. If rust-bin is present (e.g. by having run `emerge -1 rust-bin`), then the dependency of the virtual is satisfied, and portage will not try to pull in rust anymore. |
Actually, before updating I didn't have any rust at all. By masking dev-lang/rust, dev-lang/rusts-bin was pulled in to meet the new dependency for gnome-base/librsvg. I had not previously installed dev-lang/rust-bin.
Therefore, keeping dev-lang/rust in my package mask makes sense to me. That way at any point in the future if a dependency needs the full rust, I'll get notified by portage when I run updates. _________________ Andy Figueroa
hp pavilion hpe h8-1260t/2AB5; spinning rust x3
i7-2600 @ 3.40GHz; 16 gb; Radeon HD 7570
amd64/23.0/split-usr/desktop (stable), OpenRC, -systemd -pulseaudio -uefi |
|
Back to top |
|
|
asturm Developer
Joined: 05 Apr 2007 Posts: 8938
|
Posted: Tue Sep 01, 2020 8:05 pm Post subject: |
|
|
rust-bin and rust are both the "full" rust. reverse-dependencies depend on the virtual for that reason.
If none is yet installed, yes, rust is preferred, this is Gentoo after all. |
|
Back to top |
|
|
Tony0945 Watchman
Joined: 25 Jul 2006 Posts: 5127 Location: Illinois, USA
|
Posted: Tue Sep 01, 2020 8:11 pm Post subject: |
|
|
asturm wrote: |
No.
Gentoo has already shielded you for about ~2 years from that dependency. |
Ebuild failed with "configure: error: cargo is required. Please install the Rust toolchain from https://www.rust-lang.org/"
From your comment I'm guessing everything in-between also requires rust. So, having masked higher than 2.40, the choices as I see them are:
1. Continued masking until a later version is required. When it s, pick one of the other options.
2. Uninstall everything requiring librsvg, pretty much covers Gnome. Mate, and KDE
3. Surrendering to the borg and either:
________a. spend the better part of a day compiling that monstrosity that violates every precept of UNIX or
________b. install periodically a humongous binary blob that violates the whole concept of Gentoo
Last edited by Tony0945 on Tue Sep 01, 2020 8:18 pm; edited 1 time in total |
|
Back to top |
|
|
figueroa Advocate
Joined: 14 Aug 2005 Posts: 2965 Location: Edge of marsh USA
|
Posted: Tue Sep 01, 2020 8:13 pm Post subject: |
|
|
asturm wrote: | rust-bin and rust are both the "full" rust. reverse-dependencies depend on the virtual for that reason.
If none is yet installed, yes, rust is preferred, this is Gentoo after all. |
Many thanks. That is a helpful description of why the virtual package exists and how it works. _________________ Andy Figueroa
hp pavilion hpe h8-1260t/2AB5; spinning rust x3
i7-2600 @ 3.40GHz; 16 gb; Radeon HD 7570
amd64/23.0/split-usr/desktop (stable), OpenRC, -systemd -pulseaudio -uefi |
|
Back to top |
|
|
asturm Developer
Joined: 05 Apr 2007 Posts: 8938
|
Posted: Tue Sep 01, 2020 8:14 pm Post subject: |
|
|
Tony0945 wrote: | 2. Uninstall everything requiring librsvg, [...] KDE |
KDE being a community aside, did you properly investigate that claim? I think not.
Tony0945 wrote: | a. spend the better part of a day com[piling that monstrosity that violates every precept of UNIX |
Does it? In what ways?
I mean, it very unfortunately is bundling LLVM because they modify it in ways that upstream is not (yet) there. Gentoo does provide USE=system-llvm though. |
|
Back to top |
|
|
Tony0945 Watchman
Joined: 25 Jul 2006 Posts: 5127 Location: Illinois, USA
|
Posted: Tue Sep 01, 2020 8:25 pm Post subject: |
|
|
asturm wrote: | Tony0945 wrote: | 2. Uninstall everything requiring librsvg, [...] KDE |
KDE being a community aside, did you properly investigate that claim? I think not. |
I thought I saw a kde component having librsvg in the dependency list. However, you are KDE expert.
I know that I saw lots and lots of gnome dependencies. Even putting -svg in make.conf didn't clear them.
Two days ago, I re-installed lumina. It does look like lumina 2.0 will start inching back to freedesktop.org & RedHat, however. Looks like the old community is gone.
Like so many other open source projects, it looks like personality conflicts destroyed the community. |
|
Back to top |
|
|
Hu Administrator
Joined: 06 Mar 2007 Posts: 21715
|
Posted: Tue Sep 01, 2020 9:58 pm Post subject: |
|
|
If you want to avoid Rust and the Rust-encumbered versions of librsvg, I suggest using package.mask on both. If you want to begin the process of migrating away from librsvg entirely, I suggest you mask it without a version qualifier, and unmerge it. That should force Portage to start identifying packages which require it. Based on discussion here, it won't surprise me if you have at least one package that you would prefer to keep, but which requires violating the mask. This approach will at least let you discover such packages, though. In theory, it should also let you see which ones can drop their dependency on librsvg versus which need to be removed entirely. |
|
Back to top |
|
|
Tony0945 Watchman
Joined: 25 Jul 2006 Posts: 5127 Location: Illinois, USA
|
Posted: Tue Sep 01, 2020 10:05 pm Post subject: |
|
|
Hu, are you saying that there are packages with dependencies that really aren't? |
|
Back to top |
|
|
Blind_Sniper Guru
Joined: 20 Apr 2018 Posts: 340
|
Posted: Tue Sep 01, 2020 10:51 pm Post subject: |
|
|
I unmerged x11-themes/adwaita-icon-theme, masked both rust and rust-bin and updated my system. And there is one message after emerge finished:
Code: | !!! The following update(s) have been skipped due to unsatisfied dependencies
!!! triggered by backtracking:
gnome-base/librsvg:2 |
_________________ GNU is Not Usable |
|
Back to top |
|
|
Hu Administrator
Joined: 06 Mar 2007 Posts: 21715
|
Posted: Wed Sep 02, 2020 1:12 am Post subject: |
|
|
Tony0945 wrote: | Hu, are you saying that there are packages with dependencies that really aren't? | I am not saying that. I meant that some packages may optionally use Rust (e.g. a C library that ships its own Rust bindings might optionally USE=rust, just as today many packages have USE=python when they ship optional Python bindings). Similarly, there may be packages that hard-depend on Rust, but are themselves behind a soft-dependency. For example, USE=-svg causes imagemagick not to depend on librsvg, thus avoiding the need to remove imagemagick just to avoid Rust.
There are some known limitations with equery depends that make it a bit harder to use for this purpose. In particular, it does not handle USE-flag conditional dependencies as well as I would like. If you start with the premise that you won't allow a package (in this case, Rust) onto the system at all, blocking it at the Portage level and using the Portage dependency resolver to find other things to mask seems easier to me than using equery depends. Also, again assuming you have no plans to allow it later, if you don't mask it, then every time Portage tries to install it, you will need to manually investigate why. If you mask it, then Portage will advise you if you try to install something that requires it, and will explain the dependency tree that led to it. |
|
Back to top |
|
|
ebray187 Tux's lil' helper
Joined: 02 Mar 2005 Posts: 121 Location: Al otro lado de la pantalla
|
Posted: Wed Sep 02, 2020 8:45 am Post subject: |
|
|
So, after installing the long-avoided Rust, 13 and a half hours later...
Quote: | # emerge -avDNu @world
These are the packages that would be merged, in order:
Calculating dependencies... done!
[ebuild U ] dev-lang/rust-bin-1.45.2:stable::gentoo [1.44.1:stable::gentoo]... |
https://www.youtube.com/watch?v=1-ykugiRKyM
Quote: | # genlop -et rust-bin
* dev-lang/rust-bin
Tue Sep 1 14:04:36 2020 >>> dev-lang/rust-bin-1.44.1
merge time: 4 minutes and 31 seconds.
Wed Sep 2 03:55:24 2020 >>> dev-lang/rust-bin-1.45.2
merge time: 2 minutes and 47 seconds. |
I have no problem with it, everyone should program in whatever they want, I just found it curious considering the conversation that has taken place on the thread.
Tony0945 wrote: | Like so many other open source projects, it looks like personality conflicts destroyed the community. |
Actually that's true in all fields even beyond open source and software development. _________________ # emerge -C world >> 9/8
A flower?! |
|
Back to top |
|
|
eccerr0r Watchman
Joined: 01 Jul 2004 Posts: 9691 Location: almost Mile High in the USA
|
Posted: Wed Sep 02, 2020 2:00 pm Post subject: |
|
|
The x86 machines without SSE2 are still SOL with rust-bin?
Sigh. Forced Obsolescence through New Languages... _________________ Intel Core i7 2700K/Radeon R7 250/24GB DDR3/256GB SSD
What am I supposed watching? |
|
Back to top |
|
|
Ionen Developer
Joined: 06 Dec 2018 Posts: 2727
|
Posted: Wed Sep 02, 2020 2:10 pm Post subject: |
|
|
eccerr0r wrote: | The x86 machines without SSE2 are still SOL with rust-bin?
Sigh. Forced Obsolescence through New Languages... | Do you have another machine you can use to build? You could either build a suitable rust and install a binpkg of it, or better yet make a binpkg for librsvg/others and install only that on the target machine (not like it need build deps with binpkgs).
Personally build everything in a lazy chroot/qemu copy and my weak machines never build anything at all, even depclean with --with-bdeps=n. Regardless of rust, building on some old x86 machine doesn't seem worth it with today's inflated sources. My weak server with 2GB ram does need a few rust-built things (not librsvg, no GUI stuff on it, but similar deal), and this been working out fine.
Edit: much like gcc, you can use stuff like RUSTFLAGS="-C target-cpu=haswell -C target-feature=-avx,-bmi,-bmi2" (adjust for your own hardware, and of course -sse2 "should" work). |
|
Back to top |
|
|
Hu Administrator
Joined: 06 Mar 2007 Posts: 21715
|
Posted: Wed Sep 02, 2020 4:21 pm Post subject: |
|
|
ebray187 wrote: | So, after installing the long-avoided Rust, 13 and a half hours later... | I think you just validated the complaints here. ebray187 wrote: | I have no problem with it, everyone should program in whatever they want, I just found it curious considering the conversation that has taken place on the thread. | The issue is that the Rust project has developed Rust in a way that is hostile to source-based distributions like Gentoo. According to what I have read, the Rust compiler is significantly less memory efficient, and possibly less CPU efficient, than commonly available C++ compilers, which are already not noted for their efficiency. The requirement to install Rust before you can build it is just obnoxious. The inability to run Rust targets on exotic platforms for which C compilers exist is frustrating for the people who use those platforms, and could have been avoided if Rust had a Rust->C translation utility, instead of requiring Rust to generate native code directly. The use of a bundled LLVM bloats the whole process significantly, and also could have been avoided with a good Rust->C translator. The complaint in this thread is that certain core functionality, which is hard to avoid without crippling the system, has switched from being available in standard C, which is widely supported, to requiring Rust. From what I can see, Rust is worse for downstream users in almost every way. It is available on fewer platforms. It is slower to build. It requires more memory. It is less compatible with existing hardware. Its only virtue is its alleged memory safety, which is nice, but there are other ways to get that, especially if you don't offer transparent bidirectional interoperability between C and the safe language (exporting a C compatible ABI, such that someone with C headers can write C code that calls into the safe language, and vice versa). |
|
Back to top |
|
|
figueroa Advocate
Joined: 14 Aug 2005 Posts: 2965 Location: Edge of marsh USA
|
Posted: Wed Sep 02, 2020 5:06 pm Post subject: |
|
|
In any case, bless their hearts for offering us rust-bin. _________________ Andy Figueroa
hp pavilion hpe h8-1260t/2AB5; spinning rust x3
i7-2600 @ 3.40GHz; 16 gb; Radeon HD 7570
amd64/23.0/split-usr/desktop (stable), OpenRC, -systemd -pulseaudio -uefi |
|
Back to top |
|
|
tld Veteran
Joined: 09 Dec 2003 Posts: 1816
|
Posted: Wed Sep 02, 2020 5:24 pm Post subject: |
|
|
Hu wrote: | From what I can see, Rust is worse for downstream users in almost every way. It is available on fewer platforms. It is slower to build. It requires more memory. It is less compatible with existing hardware. | I also have zero faith in the Rust developers caring much about backward compatibility either. I'd venture to guess that gcc can compile code written 40 years ago. That's one of the many reasons that talk of rust in the kernel brings tears to my eyes. I could see the says where drivers for old hardware staying in the kernel essentially forever come to an end because "nobody uses that anymore" as well as even something like 32-bit support in the name of "progress".
Then again, the decisions around Firefox and Thunderbird have been so good, why not trust Mozilla with your compiler right?
Tom |
|
Back to top |
|
|
belze n00b
Joined: 21 Jul 2007 Posts: 12
|
Posted: Wed Sep 02, 2020 6:45 pm Post subject: |
|
|
Thanks.
For the record, I masked rust and successfully installed virtual-rust which in turn picked up rust-bin. |
|
Back to top |
|
|
The Main Man Veteran
Joined: 27 Nov 2014 Posts: 1166 Location: /run/user/1000
|
Posted: Wed Sep 02, 2020 8:37 pm Post subject: |
|
|
figueroa wrote: | In any case, bless their hearts for offering us rust-bin. |
Yeah, llvm-bin would be nice as well, perhaps even clang-bin |
|
Back to top |
|
|
Etal Veteran
Joined: 15 Jul 2005 Posts: 1931
|
|
Back to top |
|
|
|