this post was submitted on 29 Aug 2024
137 points (100.0% liked)

Linux

1259 readers
79 users here now

From Wikipedia, the free encyclopedia

Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).

Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word "Linux" in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.

Rules

Related Communities

Community icon by Alpár-Etele Méder, licensed under CC BY 3.0

founded 5 years ago
MODERATORS
 

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.

top 10 comments
sorted by: hot top controversial new old
[–] thingsiplay 49 points 2 months ago

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

[–] CasualTee 19 points 2 months ago* (last edited 2 months ago) (2 children)

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.

[–] 2xsaiko@discuss.tchncs.de 8 points 2 months ago* (last edited 2 months ago)

Well, it's now an issue with Rust since Cargo makes it a pain in the ass to do. It's one of the big things that makes me very reluctant to write any sort of system tools in Rust despite being a big fan of the language itself.

[–] merthyr1831@lemmy.ml 2 points 2 months ago

Because it's Rust it's now "rust bad" but Debian and other distros have been fucky with dependency management for YEARS. That's why we're moving to flatpak and other containerised apps!

Once again, the wider Linux dev community is trying to openly kneecap the first attempt in decades to bring Linux and its ecosystem up to a vaguely modern standard.

[–] superkret@feddit.org 12 points 2 months ago (1 children)

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

load more comments (1 replies)
[–] merthyr1831@lemmy.ml 2 points 2 months ago

TLDR Debian and the traditional Linux package management system is antiquated and insecure, but somehow this is the fault of one of the many programming languages that is designed around the sensible expectations of being able to manage your own dependencies.

[–] boredsquirrel@slrpnk.net 2 points 2 months ago* (last edited 2 months ago) (1 children)

Fedora has this package? I didnt find it, strange

[–] bsergay@discuss.online 3 points 2 months ago (1 children)
[–] boredsquirrel@slrpnk.net 2 points 2 months ago (1 children)

Strange, thanks that is nice! The development of bcachefs seems to not be that problematic on rolling or semi-rolling distros.

That guy might just have bad time managent, but filesystem based encryption is really cool.

[–] bsergay@discuss.online 2 points 2 months ago

filesystem based encryption is really cool.

Can't agree more.