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.

  • unknowing8343@discuss.tchncs.de
    11·
    2 months ago

    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.

    • atzanteol@sh.itjust.worksEnglish
      33·
      2 months ago

      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.

      What? That’s utter BS. Maybe the kernel devs aren’t wrong about the “rust religion”. Not every bug in C is a memory bug.

      We’re talking about a future version having regressions or different-than-expected behavior from what your application was built and tested on. I guarantee you that can happen with rust.

      • Dave.@aussie.zone
        1·
        2 months ago

        If library devs do versioning correctly, and you pin to major versions like “1.*” instead of just the “anything goes” of “*”, this should not happen.

        Your unit tests should catch regressions, if you have enough unit tests. And of course you do, because we’re all operating in the dream world of, “I am great and everyone else is shit”.