Package Rust applications, is it really worth it?

I’ve been investigating packaging a mpris scrobbler named rescrobbled. It’s very simple to install using cargo, but I thought it would be nice to have it in the Fedora repository. However, I seem to be missing something because it seems to be inordinately difficult and unwieldy to implement, mainly due to the seemingly endless wack-a-mole dependency issues. First of all, of the rust dependencies that are currently in the repository, many are not at the current required level. As I understand it, the requirements in the cargo file may or may not be actually required, and if they actually are required, then you run into the issue that the upgrade may break other rust applications so then that creates another rabbit hole to explore and resolve. It’s seemingly endless. I started out wanting to package rescrobbled and I’m now on 23 packages and counting that need to be either created or touched. Am I missing something or is this just the way it is?

1 Like

I’m super curious about this topic because I haven’t made up my mind whether cRustaceans are committed to continuous improvement (like Ruby and Python) or anarchy and chaos (like Javascript).
I suspect you may have to address a hardcore Rust forum.

1 Like

I am not a Rust packager,
but since there have not been any responses from experts,
here is the view I have formed by following the devel mailing list:
Yes, you have got it basically right.
You need to introduce all missing dependency crates as new packages,
and yes, it often is a painful experience due to large amount of them.

This problem is not unique to Rust,
it affects all programming languages and package ecosystems.
Impact varies depending how many dependencies a package usually requires.

Rust is somewhat special because the dependencies apply at buildtime.
This creates extra work when a library is updated.
The update only trickles down to reverse dependencies when they are rebuilt,
which means that they all need to be rebuilt when a library is updated.
(C++ has similar characteristics too,
because many libraries put implementation into header files,
either to avoid forming runtime dependencies or to leverage templates.)

In general, the dependency explosion is driving distributions away from packaging every possible piece of software,
towards choosing what they really need and want to support on distribution level.
Access to the rest is then left to solutions like ecosystem specific installers like Cargo, containers, and Flatpak.

Back to your original question,
for conflicting dependency version requirements,
adding a “compatibility package” is a option.

Did you already get familiar with Rust Packaging Guidelines?
They do cover the questions you ask.
And yes, the Packaging Guidelines are the specification how Fedora packages are made.

2 Likes

Thanks for the reply. Yes, I have read the rust packaging guidelines. They cover the “how to” very well - but I didn’t expect to run into what has turned out to be a whack-a-mole dependency issue. What I’ve noticed that seems to be somewhat unique (at least as far as I have observed) about rust is that the dependencies listed in the Cargo.toml may or may not be accurate. And regarding adding “compatibility packages”, yes I know that is an option… but packaging and/or touching what now would be most like 50+ packages for one package to me seems untenable for many reasons.