I think this is right. Cargo can still verify dependencies, similar to the way a
configure script would, and after that it just needs to act like
Patching sources for packaging is fine in some cases, but if we would end up repeating the same modification on every single one, that's probably something the tool should support directly. Overriding opt/debug flags with distro choices, for instance.
Packaging just Rust and Cargo is a great start, of course. And while Cargo itself uses many crates, I think we can get away with bundling those together for the moment, at least while this is the only place they are used in the distro.
Security is probably the most important, and generic bugfixing also follows.
Keep in mind also that a distro is tracking dependencies of the entire world; Cargo only knows Rust crates. In a world where Rust programs and libraries are integrated more deeply with the rest of the system, it would be bad if the distro package manager had only a Cargo blackbox for the Rust corner of the world.
We don't have to package everything on crates.io, just those that prove useful for a program we want in the distro. That still may be a lot of tiny crate packages, yes. But how many of those hundreds used by servo are frequently updated? My hunch is that most of these are probably for one-off functionality that won't update much.
Compare to a few other languages, with a quick glance at Fedora I see 176 golang, 669 ruby, 1482 python, and 2677 perl packages. And this is just searching at the level of source rpms; some may create multiple installable packages. (Searching this way also includes all historical packages, so some might be retired by now.)
Even though perl has the most, that's a drop in the bucket of the 154,917 modules on cpan. In the 3,013 crates on crates.io, I'm sure there are much fewer that will find their way into distros.
Anyway, yes, distros keep up with lots of packages.
Surely part of that idiomatic way is because these things just don't exist yet in the system package manager.
I think you're sort of getting at the disconnect between distro packaging and containers here. You may not be explicitly containerizing, but building all your own exact dependencies into a monolithic static binary is pretty close. I definitely don't think we should dig into that disconnect here, but let's allow that both methodologies should be made possible with Rust. If Rust is to be the new systems language, it needs to be able integrate into systems too.