There have been multiple accounts created with the sole purpose of posting advertisement posts or replies containing unsolicited advertising.

Accounts which solely post advertisements, or persistently post them may be terminated.

Debian Orphans Bcachefs-Tools: "Impossible To Maintain In Debian Stable"

Even before the Bcachefs file-system driver was accepted into the mainline kernel, Debian for the past five years has offered a “bcachefs-tools” package to provide the user-space programs to this copy-on-write file-system. It was simple at first when it was simple C code but since the Bcachefs tools transitioned to Rust, it’s become an unmaintainable mess for stable-minded distribution vendors. As such the bcachefs-tools package has now been orphaned by Debian.

From John Carter’s blog, Orphaning bcachefs-tools in Debian:

“So, back in April the Rust dependencies for bcachefs-tools in Debian didn’t at all match the build requirements. I got some help from the Rust team who says that the common practice is to relax the dependencies of Rust software so that it builds in Debian. So errno, which needed the exact version 0.2, was relaxed so that it could build with version 0.4 in Debian, udev 0.7 was relaxed for 0.8 in Debian, memoffset from 0.8.5 to 0.6.5, paste from 1.0.11 to 1.08 and bindgen from 0.69.9 to 0.66.

I found this a bit disturbing, but it seems that some Rust people have lots of confidence that if something builds, it will run fine. And at least it did build, and the resulting binaries did work, although I’m personally still not very comfortable or confident about this approach (perhaps that might change as I learn more about Rust).

With that in mind, at this point you may wonder how any distribution could sanely package this. The problem is that they can’t. Fedora and other distributions with stable releases take a similar approach to what we’ve done in Debian, while distributions with much more relaxed policies (like Arch) include all the dependencies as they are vendored upstream.”

…

With this in mind (not even considering some hostile emails that I recently received from the upstream developer or his public rants on lkml and reddit), I decided to remove bcachefs-tools from Debian completely. Although after discussing this with another DD, I was convinced to orphan it instead, which I have now done.

solrize ,

Oh man, that isn’t a good luck for Rust. What do those tools do and how much code is there anyway? If they are userspace tools, what is the benefit of writing them in Rust?

kbal ,
@kbal@fedia.io avatar

Rust is a good language. There is no reason not to use it for userspace tools if you manage dependencies with sufficient care. As with most other currently fashionable languages they make it easy to not do that.

InverseParallax ,

It’s a great language, and I even like their deployment/packaging system.

But oh my god it assumes everything follows its rules, and does NOT play well with others.

We need a rust-based distribution, there can be only one.

unknowing8343 , (edited )

Everything is better in Rust. Faster, safer… And also the developer experience is amazing with cargo.

The problem here is not Rust, it’s the humans, it seems.

The dependencies are set manually, of course, and the dev was enforcing something too strict, it seems, and that is causing headaches.

But, as the debian dude has learned… Rust programs will 99.999 % work if they can be compiled.

atzanteol ,

Rust programs will 99.999 % work if they can be compiled.

It’s the same in C. Most programs don’t test against the exact versions of most C libraries either. I’m not sure why he’s so amazed at this.

MrPoopyButthole ,
@MrPoopyButthole@lemmy.world avatar

Debian is the most stable distro and downstream loads of distros rely on Debian being clean. This dev has to be strict if they want to maintain the status quo. Rather let the user DL this as a standalone package and still use it, instead of it being included by default with the possibility of breaking.

And another thing. Version pinning should be normalized. I just can’t bend my mind around code which has to be refactored every 12 - 24 months because dependencies were not version pinned and a new thing broke an old thing. Unless this code is your baby and you stare at every day, constantly moving forward, you should write code that lasts.

unknowing8343 ,

The thing is that, in C the API could be slightly different and you could get terrible crashes, for example because certain variables were freed at different times, etc.

In Rust that is literally impossible to happen unless you (very extremely rarely) need to do something unsafe, which is explicitly marked as such and will never surprise you with an unexpected crash.

Everything is so strongly typed that if it compiles… It will run without unexpected crashes. That’s the difference with C code, and that’s why Rust is said to be safe. Memory leaks, etc, are virtually impossible.

just_another_person ,

It’s a huge tire fire at this point. This issue isn’t Rust, per-se, but the dev is just being an asshole here. Submitting something that is generally problematic and yelling about how it will EVENTUALLY be good is a good way to get your shit tossed out.

He just lost a good amount of favor with the general community.

Laser ,

Submitting something that is generally problematic and yelling about how it will EVENTUALLY be good is a good way to get your shit tossed out.

What are you hinting at regarding this specific news?

Ghoelian ,

This entire thread:

lore.kernel.org/…/sctzes5z3s2zoadzldrpw3yfycauc4k…

tl;dr: bcachefs dev sent in a massive pull request, linus thinks it’s too big and touches too much other code for the current state of the release cycle, dev says his filesystem is the future and should just be merged

Laser ,

Which is a completely different issue than what the post is about, hence my question

just_another_person ,

Wha?

This is exactly what the entire thread is about. Did you not read it?

thingsiplay ,

First Linus, now Debian team. Rough times for bcachefs fans.

boredsquirrel ,
@boredsquirrel@slrpnk.net avatar

Fedora doesnt even have that package. Crazy!

superkret ,

ELI5: What the fuck is going on with Rust in Linux?

GolfNovemberUniform ,
@GolfNovemberUniform@lemmy.ml avatar

Hype.

CasualTee ,

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.

  • All
  • Subscribed
  • Moderated
  • Favorites
  • •
  • [email protected]
  • random
  • lifeLocal
  • goranko
  • All magazines
    •