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.

    • Leaflet@lemmy.worldEnglish
      20·
      2 months ago

      On the kernel side, there are disagreements between long term C maintainers (who may not know Rust or may actively dislike it) and the new Rust community trying to build in Rust support. To make the Rust parts work, there needs to be good communication and cooperation between them to ensure that the Rust stuff doesn’t break.

      On the Debian side, they have strict policies that conflict with how Rust development works. Rust has a dependency system called Cargo which hosts dependencies for Rust projects. This is different from C, C++ where there really isn’t a centralized build system or dependency hoster, you actually install a lot of dependencies for these languages from your distro’s repos. So if your Rust app is built against up to date libraries in Cargo, it’s going to be difficult to package those apps in Debian when they ship stable, out of date libraries since Debian’s policies don’t like the idea of using outside dependencies from Cargo.

      • P03 Locke@lemmy.dbzer0.comEnglish
        24·
        2 months ago

        So if your Rust app is built against up to date libraries in Cargo, it’s going to be difficult to package those apps in Debian when they ship stable, out of date libraries since Debian’s policies don’t like the idea of using outside dependencies from Cargo.

        As they should. You don’t just auto-update every package to bleeding edge in a stable OS, and security goes out the window when you’re trusting a third-party’s third-party to monitor for dependency chain attacks (which they aren’t). This is how we get Crowdstrike global outages and Node.JS bitcoin miner injections.

        If some Rust tool is a critical part of the toolchain, they better be testing this shit against a wide array of dependency versions, and plan for a much older baseline. If not, then they don’t get to play ball with the big Linux distros.

        Debian is 100% in the right here, and I hope they continue hammering their standards into people.

    • qqq@lemmy.world
      12·
      2 months ago

      This doesn’t seem to be a Rust problem, but a modern development trend appearing in a Rust tool shipped with Cargo. The issue appears to be the way things are versioned and (reading between the lines maybe?) vendoring and/or lockfiles. Lockfiles exist in a lot of modern languages and package managers: Go has go.sum, Rust has Cargo which has Cargo.lock, Python has pip which gives a few different ways to pin versions, JavaScript has npm and yarn with lock files. I’m sure there are tons of others. I’m actually surprised this doesn’t happen all the time with newer projects. Maybe it does actually and this instance just gains traction because people get to say “look Rust bad Debian doesn’t like it”.

      This seems like a big issue if you want your code to be packaged by Debian, and it doesn’t seem easy to resolve if you also want to use the modern packaging tools. I’m not actually sure how they resolve this? There are real benefits to pinning versions, but there are also real benefits to Debian’s model (of controlling all the dependencies themselves, to some extent Debian is a lockfile implemented on the OS level). Seems like a tough problem and seems like it’ll end up with a lot of newer tools just not being available in Debian (by that I mean just not packaged by Debian, they’ll likely all run fine on Debian).