Mastodawn

#gentoo question for all you beautiful intelligent #gentoo mains out there: is installing rust packages via portage pointless? I installed media-sound/wiremix thinking ooo no new dependencies and it installed a zillion "crates" out of band. or is that probably why the package is masked currently?

EDIT: winning answer: that is normal, but portage will update it at least (among other things)

@aeva if you install a rust package via portage it will download the whole rust dependency tree and compile it, just like if you had done `cargo install`. however, because it's a system package now you get automatic updates instead of forgetting about it forever, if you want that. also for some apps like app-editors/helix, the `cargo install` version leaves you with a somewhat broken setup out of the box until you take some extra manual steps to put its runtime files where it needs them. whereas if you install with portage it's actually set up correctly on your system

@aeva portage managing the rust package also confers some benefits that you probably don't care about, like the build is network isolated (some people care about this). And also cross-compilation will usually just work if you were say using gentoo to build a raspberry pi image from an x86 machine.

so basically there is a lot of nice things it can provide, but none of them are "saving you from compile times". this is true of golang packages as well, just the nature of those languages really

@artemis that makes sense. is there a way to mask these all by default so I don't install them on accident?

@aeva mask all rust applications you mean?

@artemis just so I know that there's some extra care to be taken if I want to inspect dependencies and such

@aeva In a short answer, not *directly* like you're asking.

In a longer answer, the masking system allows you to mask all things from an overlay, all things from a package *category* (which doesnt help since "is written in rust" isnt a category), or specific packages / versions of packages

What you *could* do is run `equery depends --all-packages -F '$cp' dev-lang/rust | sort -u` to generate a list of every package that depends on rust, and write it to a file in /etc/portage/package.mask/

I think you can then unmask one by one with /etc/portage/package.unmask/ without having to remove them from this auto-generated file (but I might be wrong about this).

equery comes from the "app-portage/gentoolkit" package

You would also need to make this run after syncing... They added a way to put a post-sync hook for a script to run after syncing I know, but I dont know how you do that I've never done it myself

@aeva note that any `depends --all-packages` query will take awhile to run since it has to partially process every package in the repository but it does not take so long as to be unusable. (without --all-packages it only checks packages you have installed)

@artemis probably not worth it. it seems like only rust applications actually use rust libraries though, so tbh it shouldn't be much of a problem because i'm not installing unfamiliar applications without a little advanced research

@artemis like i was surprised that i didn't pull in rust-bin sooner

@aeva this is partially true I would say. There are some libraries being written in rust that expose a C-ABI interface, so that other applications can link against them, this I know. The one off the top of my head I can think of that are a bit common is gstreamer (which I believe is seeing some components ported to rust?), and librsvg (which is a gnome project, and a lot of core libraries use for their svg support). These may in turn have dependencies on rust crates. I can't recall others off the top of my head.

@aeva Yeah, it's a hazard of compiling anything written in rust from source, I had to sit through the same process on slackware for an RSS reader. At least portage handling it for you makes maintaining the giant pile of crates rust drags along with it simple.

@miss_rodent i've been having so much fun seeing what each new thing I install wants, and it's really sucks the fun out when something is like trust me bro don't look

@miss_rodent i guess if my program's dependency tree was longer than an unspooled human intestinal tract i'd probably also feel a bit self conscious about people taking a look too lol

@aeva Yeah, though iirc most of the crates it ends up installing aren't even 'dependencies' for the program itself - it's just the base clusterfuck needed to have a functional rust build environment at all.

@aeva Yeah, honestly it's one of the things I really dislike about rust (and most languages that have their own special library package management nonsense), it makes it really hard to judge how long a build will take, and what sort of mess it's about to make in your filesystem if you run it and step away until it's done -.-;;;

@miss_rodent it also makes me wondering if the author is vetting anything either. it would be hilarious if this ended up being a horrific supply chain attack vector

@aeva presumably they just use cargo, which... pulls from community package repositories, the offical repository is https://crates.io/ but I think it can grab from github crates and such too... so, a supply chain attack is entirely plausible.

crates.io: Rust Package Registry

crates.io serves as a central registry for sharing crates, which are packages or libraries written in Rust that you can use to enhance your projects

@aeva but iirc you need to add unofficial registries to a config file, so, it probably only grabbed from crates.io.
Which.... maybe they're verified? No idea. How much do you trust the rust team, I guess.

@aeva Coming from a Slackware user of nearly two decades - I realllyyyy hate this aspect of rust.
I run a distro where *I* am the dependancy-resolution part of package management for a reason. If I want a package manager that does it for me, I can just use debian. I don't need (or want) an extra package manager to babysit.

@aeva At least the crates were being downloaded individually. Many rust ebuilds nowadays will pull a "-deps.tar.xz" tarball with all the crates inside, created by the ebuild author, on a "trust me bro" basis. This is because listing all the crates in each ebuild alongside their hash turned out to bloat the repo size and they want to keep it manageable...

Managing rust deps with portage at least lets it link with some system C libraries like openssl, instead of bundling their own.

@mid_kid please don't darvo the poor gentoo maintainers on this, rust created the problem.

Fabian Transchel 2d ago

@aeva @mid_kid 100%.

@aeva I agree, I'm not blaming anyone just complaining about the status quo... If it were just rust I'd point at them, but between rust, go, node, dotnet, etc there's now a lot of ecosystems with deep dependency trees that are annoying to package, and explode the size of repositories.

This is more of an ecosystem shift, and solutions to deal with it will be necessary. It's the sort of problem that keeps me up at night, as none of the solutions implemented by other distros seem usable in gentoo.

Tacitus 🇮🇪

> Read my lips: no new dependencies

*Installs a load of new dependencies*