CasualTee , 5 hours ago

the common practice is to relax the dependencies

I found this a bit disturbing

I find that funny that, since this is rust, this is now an issue.

I have not dwelved in packaging in a long while, but I remember that this was already the case for C programs. You need to link against libfoo? It better work with the one the distribution ship with. What do you mean you have not tested all distributions? You better have some tests to catch those elusive ABI/API breakage. And then, you have to rely on user reported errors to figure out that there is an issue.

On one hand, the package maintainer tend to take full ownership and will investigate issues that look like integration issue themselves. On the other hand, your program is in a buggy or non-working state until that’s sorted.

And the usual solutions are frown upon. Vendoring the dependencies or static linking? Are you crazy? You’re not the one paying for bandwidth and storage. Which is a valid concern, but that just mean we reached a stalemate.

Which is now being broken by

• slower moving C/C++ projects (though the newer C++ standards did some waves a few years back) which means that even Debian is likely to have a “recent” enough version of your dependencies.
• flatpack and the likes, which are vendoring everything and the kitchen sink
• newer languages that static link by default (and some distributions being OK with it)

In other words, we never figured out a proper solution for C projects that will link with a different minor than the one the developer tested.

Well, /rant I guess. The point I’m raising does not seem to be the only one, and maybe far from the main one, for which bcachefs-tools is now orphaned. But I’ve seen very dubious arguments to try and push back against rust adoption. I feel like people have forgotten where we came from. And while there is no reason to go back per say, any new language that integrate this deep into the system will face similar challenges.