8 ms·

Orphaning bcachefs-tools in Debian

177 points by pabs3 2y ago

psibi 2y ago
Related discussion in the bcachefs subreddit: https://www.reddit.com/r/bcachefs/comments/1f4erbg/debianstable_drops_bcachefstools/ https://www.reddit.com/r/bcachefs/comments/1f4erbg/debiansta... Kent's reply in that thread has more details.
JonChesterfield 2y ago
This would be a good one for Rust enthusiasts to weigh in on. The issue raised is that some program written in rust insists on a very specific version of various dependencies. If other people change the metadata, it builds and seems to run ok with different versions. (Developer on reddit clarifies that it builds and does the wrong thing, and recommends dropping Debian as a solution). Linux likes to pack a finite set of versions of libraries (ideally just one version at a time) and use that dependency for multiple programs, totally at odds with the vendoring specific versions strategy. I'm not clear what a solution is to this one. In the specific case, sure, drop it from Debian. But this isn't the only program choosing to vendor dependencies instead of use them from the environment.
- viraptor 2y ago
  This isn't Rust specific. The same issue exists in all languages where the versions can be restricted at project level. It's an issue in Debian because they can't handle multiple concurrent versions (beyond renaming the package) and want every package built without internet access. But that same issue affects Ruby, Python, etc. if the project specifies strict versions. And if you deal with filesystems, you really want strict versions - I understand why the author wants to keep it that way. It's more of a self-inflicted Debian policy pain rather than anything to do with Rust. The author could be nice and vendor, but also he's completely right to refuse. The request is basically "we put handcuffs on ourselves, so please you do the work instead".
  - agwa 2y ago
    The author would be fine with vendoring. The problem is that Debian doesn't allow it.
    - AshamedCaptain 2y ago
      And that's because the users of Debian are not fine with vendoring.
    - cesarb 2y ago
      > The problem is that Debian doesn't allow it. Vendoring used to be more common, even in Debian. But then there was an important zlib vulnerability (which IIRC could be exploited through manipulated compressed data), and they had to chase and fix all the many copies of zlib embedded all over the place. To make things worse, some of them were not only old versions of zlib, but also had modified that zlib code, so each had to be reviewed before applying the fix. Debian (and other traditional distributions) learned from that incident, and started a strong push to not only remove vendored copies of libraries, but also when possible use a single version of these libraries. Which means that, whenever an important security issue is once again found in a widely used library, only a single copy has to be fixed and updated.
      - chandlerswift 2y ago
        I'm interested in hearing more about the history behind Debian and zlib! I did some searching and the closest thing I could find was a nod to the same incident in the Upstream Guide[0]. Do you know of a place where I could read more about it? [0]: https://wiki.debian.org/UpstreamGuide#No_inclusion_of_third_party_code https://wiki.debian.org/UpstreamGuide#No_inclusion_of_third_...
        cesarb 2y ago
        It's been so long ago, that it's hard to find all the discussions I had seen back then. I recall that it was after a long time without any zlib release, so looking at the zlib history, I think it was this one fixed in zlib 1.1.4 from 11 March 2002: http://www.zlib.org/advisory-2002-03-11.txt http://www.zlib.org/advisory-2002-03-11.txt Looking at the debian-devel archives around that date, I found a Debian developer complaining about the vendored zlib copies (https://lists.debian.org/debian-devel/2002/03/msg00716.html https://lists.debian.org/debian-devel/2002/03/msg00716.html), but not the full discussion about getting rid of vendored libraries, so it must have happened elsewhere.
- haileys 2y ago
  I think this is the same shape of issue that I’ve experienced with Debian for as long as I’ve used it - close to 15 years now. Debian is a great OS, but it targets stability and long term support for its releases. That just isn’t compatible with newer, faster moving software that’s still working towards stability. I remember it being an issue when I was playing around with Mono around 2010 ish, and it’s an issue now with bcachefs - a very new and fast moving technology. For motivated users, the solution is to install bcachefs-tools direct from upstream, or from a third party packager (if one exists). When bcachefs stabilises, I’m sure it’ll find its way back into Debian official.
  - aragilar 2y ago
    What I think is somewhat interesting in this case (if I've read the post correctly) half the changes were for newer versions of dependencies. If that's the case, then I'm inclined to start wondering what's going on with bcachefs upstream (and the whole dependency tree), if they're not keeping up with versions.
    - arzig 2y ago
      My read is that whatever subset of the ecosystem bcachefs-tools just hasn’t stabilized. Presumably it will, but once everything is functionally at 1.x even if they don’t reach it officially this will be become a non-issue. That said, having dabled in rust there’s a temptation to name breaking changes to improve ergonomics because the type system is so expressive. I almost wonder if this is an argument for simpler type systems to reduce churn.
    - SkiFire13 2y ago
      Imagine that an update of bcache-fs is released and 3 dependencies (could even be transitive) were updated and the newer versions were not packaged in Debian. The maintainer now has one package to update but another 3 to package for the first time. That's additional work. AFAIK Fedora has a tool to automatize this work, but maybe Debian has additional requirements that make this harder.
      - 2y ago
- rlpb 2y ago
  Maintenance is much more practical if everything in your dependency tree uses the same version of every dependency. Achieving this in practice is much of the work distribution maintainers have to do. Doing this has a couple of key advantages: 1. when a security vulnerability needs patching in a stable distribution release, the security team only have to patch one version instead of a dozen or more different versions bundled all over the place 2. a library that depends on dependencies A and B, both of which depend on X, can actually work properly if it needs to pass API objects created by X across between A and B, since X is of the same version In an ecosystem where it's considered acceptable to "pin" versions of dependencies and also call any system that doesn't use the pinned versions "unsupported", both of the above two cases become impractical. Whether you use shared libraries or static libraries, the above matters still exist.
  - orra 2y ago
    > 2. a library that depends on dependencies A and B, both of which depend on X, can actually work properly if it needs to pass API objects created by X across between A and B, since X is of the same version That feels like an advantage for the developer, not the distro maintainer. I find that amusing, because you're saying it's easy if they can use one version of the library. Well, that's also true if they're writing an application, hence pinning.
    - rlpb 2y ago
      > That feels like an advantage for the developer, not the distro maintainer. It's an advantage for the ecosystem, yes. Not the developer of the library (X in my example), but a different developer. Someone who is trying to write an app to do something interesting with A and B. > ...because you're saying it's easy if they can use one version of the library. Well, that's also true if they're writing an application I don't think that's true. Perhaps library A has pinned dependencies for X such that it is in conflict with unrelated library B that also uses pinned dependencies for X. Both libraries are now less useful to the ecosystem, because they are now inadvertently incompatible with each other (if their APIs expose X's objects). My example demonstrates why this doesn't work in the general case, and therefore why it's wrong to expect that everyone does it this way.
- foobarqux 2y ago
  As others have said this isn't just Rust, distro "release" packaging is untenable now for non-base-system packages: there are an ever increasing number of packages, they release with updates users need/want at a rate far faster than the distro release schedule and have too many conflicting dependencies. To deal with this today you install a stable base system with an overlaid "user" package system so Debian/Fedora + nixpkgs/guix/brew/snap/flatpak/mpr/pip/cargo/etc. Unfortunately because because although you can get most packages on nixpkgs you can't get all and you'll need to install multiple so it becomes a nightmare to maintain (how do you remember all the package managers you have to update during the xz vulnerability?) and extremely bloated due to duplicated dependencies (especially for GUI packages that require gnome or kde). You do get pretty far for CLI-only packages by just adding nixpkgs though. Too bad it's so terrible to use. MPR is also pretty interesting: You basically leverage the AUR for Debian and with a few changes you could probably make the dependency names translation automatic and transparent. It solves the bloat problem (since you'll mostly use system packages) but doesn't help with library versions.
  - ploxiln 2y ago
    Shouldn't the filesystem utilities be base-system packages, though? Like e2fsprogs, xfsprogs ... I guess rust just isn't appropriate for base-system packages, because the dependencies move too fast, and so rust components need to depend on different specific versions of all dependencies, and are "horrifically out-of-date" in just a few months ... and rust developers wouldn't stoop so low as to recognize that e.g. bindgen is a particularly hairy and touchy dependency so they should just vendor the bindings output by bindgen, rather than the entire bindgen tool plus all other dependencies in full ...
    - foobarqux 2y ago
      I'm not that familiar with bcachefs-tools and was speaking more generally but I thought bcachefs-tools wasn't critical for normal booting (On Ubuntu 24.04 nothing seems to depend on that package and it seems optional. The same for btrfs-tools). Some other comments suggested you need it to mount a degraded file system but it seems to me that is a case where either 1. your system can't boot and you need external recovery boot tools anyway or 2. you can boot and can run whatever tools you want (you can install the latest version of bcachefs-tools via nixpkgs for example). The real problem there seems to be that the program was silently broken due to the changes made to get it to build on Debian. Though I agree that it is closer to a system-critical package than most packages.
- BoingBoomTschak 2y ago
  Gentoo has SLOTs and they work well. But for Go and Rust, I think they chose the vendoring path because it's just too damn Don Quixotesque to try to mirror their NPM tier package repositories.
- lambda 2y ago
  > Developer on reddit clarifies that it builds and does the wrong thing, and recommends dropping Debian as a solutio Can you link to the post on Reddit you are referring to?
  - dfc 2y ago
    I think this is the comment: https://www.reddit.com/r/bcachefs/comments/1f4erbg/comment/lkped4c/ https://www.reddit.com/r/bcachefs/comments/1f4erbg/comment/l...
- pornel 2y ago
  > rust insists on a very specific version of various dependencies It only insists on semver-compatible versions (if a Rust/Cargo package specifies libfoo=5.1, it will work with libfoo=5.9). It's one per major version, not that different from Debian packaging "libfoo5" and "libfoo7" when both are needed. The difference is that Cargo unifies versions by updating them to the newest compatible, and Debian unifies them by downgrading them to old unsupported versions, ignores compatibility, and reintroduces bugs, and disables required functionality.
londons_explore 2y ago
So I guess the gauntlet is now down for any other maintainer to come and decide they do want to package it for debian/ubuntu...
- Sesse__ 2y ago
  Not really. Debian has a Rust policy, which among others prohibits this kind of extreme vendoring. Upstream insists on exact versioning (thus requiring vendoring), including hacked-up versions of some upstream crates, and also insists that Debian maintainers go on a war to change Debian's Rust policy to his liking (this is why I left #bcache; I don't set these policies, I'm not interested in fighting against them, and I'm not interested in an infinite rant about how I should spend my energy on such a fight). A couple of other people and myself made some attempts to get the Rust parts of bcachefs-tools buildable and working (and yes, it was really working, and no, the version changes led to no real breakage that I know of), but you can't reasonably package software from an upstream who is so hostile to everything about your distribution. If it's “my way or the highway” about everything, I guess it's the highway, then? Maybe someone who cares deeply about bcachefs and cares deeply about Debian will pick it up, but that person would better have a really thick skin.
oguz-ismail 2y ago
[flagged]
- Ygg2 2y ago
  It's not a Rust specific issue. See C#/Mono, npm, Java, etc.
  - cozzyd 2y ago
    Yes but thankfully nobody writes base OS tooling in those languages
    - Ygg2 2y ago
      Yeah, they just write OS in those.
mananaysiempre 2y ago
See also on the same general topic: “The modern packager’s security nightmare” (2021) [1] by Gentoo maintainer Michał Górny, and Drew DeVault’s posts on why FOSS developers should not distribute software directly or try to impose their will on distros[2,3]. [1] https://blogs.gentoo.org/mgorny/2021/02/19/the-modern-packagers-security-nightmare/ https://blogs.gentoo.org/mgorny/2021/02/19/the-modern-packag..., discussed at https://news.ycombinator.com/item?id=26203853 https://news.ycombinator.com/item?id=26203853 (320 points, 278 comments) [2] https://drewdevault.com/2019/12/09/Developers-shouldnt-distribute.html https://drewdevault.com/2019/12/09/Developers-shouldnt-distr..., no notable HN discussions [3] https://drewdevault.com/2021/09/27/Let-distros-do-their-job.html https://drewdevault.com/2021/09/27/Let-distros-do-their-job...., no notable HN discussions
- 1oooqooq 2y ago
  exactly. the sad part is that this is being coopted into an aegument for flatpack! it's insane the discussions on some distros. they cannot see that by giving in to static libs you make every little application maintainer into a full-time distro maintainer responsible for it forever. ... good luck with that.
  - mananaysiempre 2y ago
    I actually don’t entirely agree with Górny’s argument that we should use the technical tool of shared libraries to solve the social problem of not organizing the package archive in a way that allows an automatic bump of every dependency on a static library change. But I do agree with a weakened version where “static libraries” is replaced with “vendored code”, and that’s the (part of) problem TFA describes. (The rest of the problem is that the goals of Debian are incompatible with upstream refusing to support versions of their own code more than a couple of months old. Which they transparently are, so there isn’t much to argue about here.)
    - 1oooqooq 2y ago
      I'm also on (several) the fence on the solution. but the description of the problem is spot on
h2odragon 2y ago
this is "static vs shared libraries" fight again. no one remembers the first iterations, and there's more layers of "stuff" in the way now, so now one sees the actual issue for what it is. "shared libs" was the product of storage constraints; a bobble in the smooth pace of progress that shouldn't be needed now. Our faith in "the way things are done now is the right way" and our (justified) fear of messing with the foundations of running systems will make excising the notion take longer.
- mananaysiempre 2y ago
  It’s rather the “vendoring is hostile to distros” fight. It’s adjacent to the shared vs static one but not the same: it’s absolutely possible to have statically linked binaries tracking distro-wide dependency versions, provided the distro’s build system is robust and automated enough. Not all are.
  - crote 2y ago
    "Vendoring is hostile to distros" in turn directly leads to "loose dependencies are hostile to upstream developers". Distros want to be able to mix & match upstream code with whatever version of the dependency they happen to have lying around in a drawer somewhere. Understandable, as the alternative is having to support dozens of versions of the same library. Upstream developers want to use a single fixed version of their dependencies for each release. Understandable, as the alternative is having to support support a massive test matrix for every possible version of every dependency, just on the odd chance that some obscure distro wants to mix a brand-new libfoo with a 5-year-old libbar. And all of this boils down to "versioning is actually really hard", because even with SemVer one's bug is another's feature[0] so there's still no unambiguous way to choose a version number, which in turn means upstream can't choose a version range for their dependencies and be reasonably sure that simply testing with the latest version won't result in breakage with other versions in that range. If dependency management was easy, we would've solved it decades ago. [0]: https://xkcd.com/1172/ https://xkcd.com/1172/
- viraptor 2y ago
  This is unrelated to shared libraries. Those strict versions are for compile-time dependencies.
frankjr 2y ago
The list of dependencies doesn't really seem crazy. Logging, parsing command line arguments, band-aiding error traits, working with uuids, reading binary data, "memset_s". All of those should be a part of the standard library as in any other programming language. The fact that you simply cannot build anything but trivial examples without taking a dependency on a third party library is just plain ridiculous and hinders Rust's adoption (as seen in this case). It's especially ridiculous considering Rust positions itself to be used in mission critical systems and yet essentially requires you to implicitly trust hundreds of maintainers for any non trivial project to not be malicious. https://github.com/koverstreet/bcachefs-tools/blob/b422b19f636329e1a082bcacd3ac6b485d7a5b3e/Cargo.toml https://github.com/koverstreet/bcachefs-tools/blob/b422b19f6...
- CJefferson 2y ago
  Where are those things in the standard library of C or C++, which most software is written in? Most C Debian packages have a few dependencies in my experience, they are just “standard”, because they are old and stable.
  - jmb99 2y ago
    Parsing command line arguments, reading/manipulating binary data, memset_s are of course all available in the C standard library. I’m not familiar with rust, but if it’s true that dependencies are required for those types of basic operations... yikes, to say the least. If you include boost (which, admittedly, is a heavy dependency, but still a single one), everything mentioned is possible.
    - steveklabnik 2y ago
      Just to be clear about it, Rust has the same level of this stuff in the standard library as C does. Like, the equivalent of argc/argv is in the rust standard library. The library being included is more like getopt conceptually; a package built on top of that that makes things nicer.
    - nequo 2y ago
peppermint_gum 2y ago
>not even considering some hostile emails that I recently received from the upstream developer or his public rants on lkml and reddit It feels like whenever the author of bcachefs comes up, it's always because of some drama. Just the other day he clashed with Linus Torvalds: https://lore.kernel.org/lkml/CAHk-=wj1Oo9-g-yuwWuHQZU8v=VAsBceWCRLhWxy7_-QnSa1Ng@mail.gmail.com/ https://lore.kernel.org/lkml/CAHk-=wj1Oo9-g-yuwWuHQZU8v=VAsB... My reading is that he's very passionate, so he wants to "move fast and break things" and doesn't get why the others aren't necessarily very happy about it.
- sp1rit 2y ago
  [flagged]
- jt2190 2y ago
  Is bcachefs-tools going into the mainline distros or into something that’s meant to be less stable and experimental? Linus makes it sound like there’s a more appropriate place for this work. Edit: Reading through the thread, it seems like there is a claim of rigorous but effectively private testing. Without the ability to audit those results easily it’s causing a lot of worry.
  - ralferoo 2y ago
    I don't think Linus is particularly concerned about bcachefs-tools, and whether a particular distributions ships with it or not isn't a concern for the kernel. Presumably though, distributions that don't ship the tools may also want to disable it in the kernel, although I'd imagine they'd leave it alone if it was previously supported. Linus' complaint was about adding feature work into a supposed minor bug fix, especially because (going from Linus' comments) they were essentially refactors of major systems that impacted other areas of the kernel.
- ralferoo 2y ago
  It's very clear from that thread that he doesn't understand the purpose of the stable branch. It doesn't mean "stable" as in "the best possible experience", it means it as in "this code has been tested for a long period of time with no serious defects found" so that when the stable branch is promoted to release, everything has undergone a long testing period by a broad user base. If there is a defect found, the change to a stable branch should literally be the minimal code change to fix the reported issue. Ideally, if it's a newly introduced issue (i.e. since being on the stable branch), the problematic code reverted and a different fix to the original defect applied instead (or left if it's deemed less of an issue than taking another speculative fix). Anything that requires a re-organisation of code, by definition, isn't a minimal fix. Maybe it's the correct long-term solution, but that can be done on the unstable branch, but for the stable branch, the best fix is the simplest work around. If there isn't a simple work around, the best fix is to revert everything back to the previous stable version and keep iterating on the unstable branch. The guy even admits it as well with his repeated "please don't actually use this in production" style messages - it's hard to give a greater indication than this that the code isn't yet ready for stable. I can understand why from his perspective he wants his changes in the hands of users as soon as possible - it's something he's poured his heart and soul and he strongly believes it will improve his users' experience. It's also the case that he is happy running the very latest and probably has more confidence in it that an older version. The rational choice from his perspective is to always use the latest code. But, discounting the extremely unlikely situation that his code is entirely bug free, that just means he hasn't yet found the next serious bug. If a big code change is rushed out into the stable branch, it just increases the likelihood that any serious bug won't have the time it needs in testing to have the confidence that's the branch is suitable for promotion to release.
rgname 2y ago
[flagged]
yshui 2y ago
This is pretty dumb on Debian's part. First of all I don't understand why they insist crate dependencies must be pulled from their repository. They are just source code, not built binary. AFAIK there is no other distro that does this, what they do is that they would download crates from crates.io (`cargo vendor` is a command that does this automatically) and build against that. Arch does this, Gentoo does this, NixOS does this, why does Debian has to be different? Secondly, even if they have to use crates from their repository, I don't understand what's so hard to just have multiple versions of the same crate? That will solve the problem too. This is just all-around weird what Debian is doing. (Full disclosure, I am the one who introduced the first piece of Rust code into bcachefs-tools)
- wojciii 2y ago
  Perhaps they want to have builds they can reproduce years later? When libraries are removed you have to update your build. This will not be the case if you use your own infrastructure (crates.io mirror).
- acka 2y ago
  Debian has a Social Contract[1] as well as guidelines {the DFSG}[2] regarding the commitment to only distribute free and open source software that all package maintainers must adhere to. This means that package maintainers must check the licenses of source code and documentation files, clear up any ambiguities by talking to upstream, and (as a last resort) even excise code and/or documentation from Debian's copy of the codebase if it doesn't meet the requirements of the DFSG. In practise, this means that Debian has to make its own copy of the source code available from a Debian-controlled repository, to ensure that no (accidental or otherwise) change to an upstream source archive can cause non-DFSG compliant Debian source or binary packages to be distributed. [1] https://www.debian.org/social_contract https://www.debian.org/social_contract [2] https://wiki.debian.org/DebianFreeSoftwareGuidelines https://wiki.debian.org/DebianFreeSoftwareGuidelines
  - koverstreet 2y ago
    That justification doesn't work here - I provide vendored tarballs, so the source code availability argument is moot.
koverstreet 2y ago
I would rather something not be packaged at all than packaged badly; this whole experience reads like a lesson in what not to do. What the author left out in his blog post is that I specifically explained why this was going to be an issue and what was going to happen when he and I first talked about Debian packaging; and why for a package that needs to work correctly for the system to boot (fsck, mount helper, encryption unlock), playing these kinds of games with swapping dependencies out was not a good idea. But with Debian and Fedora people alike it's been like talking to a brick wall. "No, your concerns don't matter, this is our policy and we're going to do what we want with your code". They've made it very clear that I have no voice or say in how they package it. So then he breaks the build by switching to the packaged version of bindgen, an old unsupported version. And he makes no attempt to debug, doesn't even send me the build error until months later. As a result, Debian users were stuck on a broken version of -tools that wasn't passing mount options correctly, which meant that when a drive died and they needed to mount in degraded mode, they weren't able to. This happened to multiple people - that bothered to report it. This was quickly fixed upstream, but as far as I know it's still broken in Debian; and Jonathan Carter wasn't fielding any of those bug reports, I was. I'm tired, frustrated and demoralized by this drama and tired of constantly having to respond to it. This has taken up an enormous amount of my time. I really wish this guy hadn't packaged -tools for Debian in the first place. I never asked for it. I have enough on my plate to do without a bunch of distro drama to deal with as well.
- haileys 2y ago
  Thanks for taking the time to comment here! > So then he breaks the build by switching to the packaged version of bindgen, an old unsupported version. Could bcachefs-tools solve this problem upstream of distros by releasing a source tarball with the bindings already generated, so that you can use whatever version of bindgen you want, and bindgen is not needed at all when building from this release tarball? This would be similar in nature to traditional autotools approach where some amount of pre-compilation is done to produce a release tarball from what actually lives in the source repository. It's also what I do for some of my ffi crates. I have a script in the root of the repo which regenerates the bindings, but when published to crates.io, the bindings are already generated and bindgen is not part of the build downstream of my crate.
Brian_K_White 2y ago
The same bcachefs that Linus just ripped apart for inconsiderate and irresponsible PRs? Sensing a pattern and it's not both Debian and the kernel. I mean can you even point at 2 more proven solid large and long term projects that have proven how to do it right?
Brian_K_White 2y ago
Sure buddy. Not only Debian but the kernel itself too. Those immature unproven little projects and their silly "best practices". What do Debian or the kernel know about building and maintaining bedrock software? https://www.phoronix.com/news/Linus-Torvalds-Bcachefs-Regrets https://www.phoronix.com/news/Linus-Torvalds-Bcachefs-Regret...
- rc00 2y ago
  These are some of the sentiments I'm seeing where people are tired of Rust and the related crowd. Very young and/or very inexperienced Rust evangelists are showing up to experienced, long-term, and stable projects and effectively dictating that they know better because "the future" is on their side. And then when they are rebuffed, they turn to the mentally unhealthy echo chamber that is social media for reinforcement. It is a cycle of unhealthy and even toxic behavior. I'm fortunate that I haven't seen this with my mentees but it does appear that there are non-mainstream social media platforms allowing these problems to fester rather than addressing them head-on.
- Brian_K_White 2y ago
  Apologies I got this kinda backwards. The Debian article was written from Debians perspective not bcachefs. "sure buddy" and the rest of the sarcasm was directed at bcachefs.
suncore 2y ago
Splitting a piece of software into multiple pieces and shipping the pieces (dependencies) independently is sometimes a good idea, but it has its limits. Maybe the limit should be for dependencies which are very stable and used by many packages (libc, etc.). The hard line policy enforced by Debian here obviously is not working. Happy to see other distros solve this better. This might become really problematic for Debian in the future.
rubiquity 2y ago
Debian is going to look as ridiculous for doing this as Alma Linux is for insisting btrfs isn’t an “enterprise file system” due to it lacking RAID 5/6.
- chungy 2y ago
  btrfs lacking RAID 5/6 is exactly the sort of thing that makes it get written off as a toy. ZFS has had working raidz[12] since 2005, raidz3 since 2007, and draid since 2021. Completely stable and enterprise-ready.
- jonathanspw 2y ago
  AlmaLinux has made no such statement, for what it's worth.
  - chungy 2y ago
    Red Hat Enterprise Linux excludes btrfs support in its distribution because Red Hat does not believe btrfs to be stable enough to be worth considering. That decision trickles down to recompilation projects that pretty much amount to "RHEL, but without having to pay for it".
    - cozzyd 2y ago
      And rightfully so, imo. btrfs is the only filesystem I've used where it's gotten so corrupted due to faulty memory on a computer that I had to recover the files and reinstall from scratch after replacing the memory (obviously not using btrfs the second time ..).
  - rubiquity 2y ago
    Thanks for that correction. I misunderstood a forum post that was probably someone being snarky/cynical.

177 points by pabs3 2y ago

Related discussion in the bcachefs subreddit: https://www.reddit.com/r/bcachefs/comments/1f4erbg/debianstable_drops_bcachefstools/ https://www.reddit.com/r/bcachefs/comments/1f4erbg/debiansta... Kent's reply in that thread has more details.

JonChesterfield 2y ago

This would be a good one for Rust enthusiasts to weigh in on. The issue raised is that some program written in rust insists on a very specific version of various dependencies. If other people change the metadata, it builds and seems to run ok with different versions. (Developer on reddit clarifies that it builds and does the wrong thing, and recommends dropping Debian as a solution). Linux likes to pack a finite set of versions of libraries (ideally just one version at a time) and use that dependency for multiple programs, totally at odds with the vendoring specific versions strategy. I'm not clear what a solution is to this one. In the specific case, sure, drop it from Debian. But this isn't the only program choosing to vendor dependencies instead of use them from the environment.

viraptor 2y ago
This isn't Rust specific. The same issue exists in all languages where the versions can be restricted at project level. It's an issue in Debian because they can't handle multiple concurrent versions (beyond renaming the package) and want every package built without internet access. But that same issue affects Ruby, Python, etc. if the project specifies strict versions. And if you deal with filesystems, you really want strict versions - I understand why the author wants to keep it that way. It's more of a self-inflicted Debian policy pain rather than anything to do with Rust. The author could be nice and vendor, but also he's completely right to refuse. The request is basically "we put handcuffs on ourselves, so please you do the work instead".
- agwa 2y ago
  The author would be fine with vendoring. The problem is that Debian doesn't allow it.
  - AshamedCaptain 2y ago
    And that's because the users of Debian are not fine with vendoring.
  - cesarb 2y ago
    > The problem is that Debian doesn't allow it. Vendoring used to be more common, even in Debian. But then there was an important zlib vulnerability (which IIRC could be exploited through manipulated compressed data), and they had to chase and fix all the many copies of zlib embedded all over the place. To make things worse, some of them were not only old versions of zlib, but also had modified that zlib code, so each had to be reviewed before applying the fix. Debian (and other traditional distributions) learned from that incident, and started a strong push to not only remove vendored copies of libraries, but also when possible use a single version of these libraries. Which means that, whenever an important security issue is once again found in a widely used library, only a single copy has to be fixed and updated.
    - chandlerswift 2y ago
      I'm interested in hearing more about the history behind Debian and zlib! I did some searching and the closest thing I could find was a nod to the same incident in the Upstream Guide[0]. Do you know of a place where I could read more about it? [0]: https://wiki.debian.org/UpstreamGuide#No_inclusion_of_third_party_code https://wiki.debian.org/UpstreamGuide#No_inclusion_of_third_...
      - cesarb 2y ago
        It's been so long ago, that it's hard to find all the discussions I had seen back then. I recall that it was after a long time without any zlib release, so looking at the zlib history, I think it was this one fixed in zlib 1.1.4 from 11 March 2002: http://www.zlib.org/advisory-2002-03-11.txt http://www.zlib.org/advisory-2002-03-11.txt Looking at the debian-devel archives around that date, I found a Debian developer complaining about the vendored zlib copies (https://lists.debian.org/debian-devel/2002/03/msg00716.html https://lists.debian.org/debian-devel/2002/03/msg00716.html), but not the full discussion about getting rid of vendored libraries, so it must have happened elsewhere.
haileys 2y ago
I think this is the same shape of issue that I’ve experienced with Debian for as long as I’ve used it - close to 15 years now. Debian is a great OS, but it targets stability and long term support for its releases. That just isn’t compatible with newer, faster moving software that’s still working towards stability. I remember it being an issue when I was playing around with Mono around 2010 ish, and it’s an issue now with bcachefs - a very new and fast moving technology. For motivated users, the solution is to install bcachefs-tools direct from upstream, or from a third party packager (if one exists). When bcachefs stabilises, I’m sure it’ll find its way back into Debian official.
- aragilar 2y ago
  What I think is somewhat interesting in this case (if I've read the post correctly) half the changes were for newer versions of dependencies. If that's the case, then I'm inclined to start wondering what's going on with bcachefs upstream (and the whole dependency tree), if they're not keeping up with versions.
  - arzig 2y ago
    My read is that whatever subset of the ecosystem bcachefs-tools just hasn’t stabilized. Presumably it will, but once everything is functionally at 1.x even if they don’t reach it officially this will be become a non-issue. That said, having dabled in rust there’s a temptation to name breaking changes to improve ergonomics because the type system is so expressive. I almost wonder if this is an argument for simpler type systems to reduce churn.
  - SkiFire13 2y ago
    Imagine that an update of bcache-fs is released and 3 dependencies (could even be transitive) were updated and the newer versions were not packaged in Debian. The maintainer now has one package to update but another 3 to package for the first time. That's additional work. AFAIK Fedora has a tool to automatize this work, but maybe Debian has additional requirements that make this harder.
    - 2y ago
rlpb 2y ago
Maintenance is much more practical if everything in your dependency tree uses the same version of every dependency. Achieving this in practice is much of the work distribution maintainers have to do. Doing this has a couple of key advantages: 1. when a security vulnerability needs patching in a stable distribution release, the security team only have to patch one version instead of a dozen or more different versions bundled all over the place 2. a library that depends on dependencies A and B, both of which depend on X, can actually work properly if it needs to pass API objects created by X across between A and B, since X is of the same version In an ecosystem where it's considered acceptable to "pin" versions of dependencies and also call any system that doesn't use the pinned versions "unsupported", both of the above two cases become impractical. Whether you use shared libraries or static libraries, the above matters still exist.
- orra 2y ago
  > 2. a library that depends on dependencies A and B, both of which depend on X, can actually work properly if it needs to pass API objects created by X across between A and B, since X is of the same version That feels like an advantage for the developer, not the distro maintainer. I find that amusing, because you're saying it's easy if they can use one version of the library. Well, that's also true if they're writing an application, hence pinning.
  - rlpb 2y ago
    > That feels like an advantage for the developer, not the distro maintainer. It's an advantage for the ecosystem, yes. Not the developer of the library (X in my example), but a different developer. Someone who is trying to write an app to do something interesting with A and B. > ...because you're saying it's easy if they can use one version of the library. Well, that's also true if they're writing an application I don't think that's true. Perhaps library A has pinned dependencies for X such that it is in conflict with unrelated library B that also uses pinned dependencies for X. Both libraries are now less useful to the ecosystem, because they are now inadvertently incompatible with each other (if their APIs expose X's objects). My example demonstrates why this doesn't work in the general case, and therefore why it's wrong to expect that everyone does it this way.
foobarqux 2y ago
As others have said this isn't just Rust, distro "release" packaging is untenable now for non-base-system packages: there are an ever increasing number of packages, they release with updates users need/want at a rate far faster than the distro release schedule and have too many conflicting dependencies. To deal with this today you install a stable base system with an overlaid "user" package system so Debian/Fedora + nixpkgs/guix/brew/snap/flatpak/mpr/pip/cargo/etc. Unfortunately because because although you can get most packages on nixpkgs you can't get all and you'll need to install multiple so it becomes a nightmare to maintain (how do you remember all the package managers you have to update during the xz vulnerability?) and extremely bloated due to duplicated dependencies (especially for GUI packages that require gnome or kde). You do get pretty far for CLI-only packages by just adding nixpkgs though. Too bad it's so terrible to use. MPR is also pretty interesting: You basically leverage the AUR for Debian and with a few changes you could probably make the dependency names translation automatic and transparent. It solves the bloat problem (since you'll mostly use system packages) but doesn't help with library versions.
- ploxiln 2y ago
  Shouldn't the filesystem utilities be base-system packages, though? Like e2fsprogs, xfsprogs ... I guess rust just isn't appropriate for base-system packages, because the dependencies move too fast, and so rust components need to depend on different specific versions of all dependencies, and are "horrifically out-of-date" in just a few months ... and rust developers wouldn't stoop so low as to recognize that e.g. bindgen is a particularly hairy and touchy dependency so they should just vendor the bindings output by bindgen, rather than the entire bindgen tool plus all other dependencies in full ...
  - foobarqux 2y ago
    I'm not that familiar with bcachefs-tools and was speaking more generally but I thought bcachefs-tools wasn't critical for normal booting (On Ubuntu 24.04 nothing seems to depend on that package and it seems optional. The same for btrfs-tools). Some other comments suggested you need it to mount a degraded file system but it seems to me that is a case where either 1. your system can't boot and you need external recovery boot tools anyway or 2. you can boot and can run whatever tools you want (you can install the latest version of bcachefs-tools via nixpkgs for example). The real problem there seems to be that the program was silently broken due to the changes made to get it to build on Debian. Though I agree that it is closer to a system-critical package than most packages.
BoingBoomTschak 2y ago
Gentoo has SLOTs and they work well. But for Go and Rust, I think they chose the vendoring path because it's just too damn Don Quixotesque to try to mirror their NPM tier package repositories.
lambda 2y ago
> Developer on reddit clarifies that it builds and does the wrong thing, and recommends dropping Debian as a solutio Can you link to the post on Reddit you are referring to?
- dfc 2y ago
  I think this is the comment: https://www.reddit.com/r/bcachefs/comments/1f4erbg/comment/lkped4c/ https://www.reddit.com/r/bcachefs/comments/1f4erbg/comment/l...
pornel 2y ago
> rust insists on a very specific version of various dependencies It only insists on semver-compatible versions (if a Rust/Cargo package specifies libfoo=5.1, it will work with libfoo=5.9). It's one per major version, not that different from Debian packaging "libfoo5" and "libfoo7" when both are needed. The difference is that Cargo unifies versions by updating them to the newest compatible, and Debian unifies them by downgrading them to old unsupported versions, ignores compatibility, and reintroduces bugs, and disables required functionality.

londons_explore 2y ago

So I guess the gauntlet is now down for any other maintainer to come and decide they do want to package it for debian/ubuntu...

Sesse__ 2y ago
Not really. Debian has a Rust policy, which among others prohibits this kind of extreme vendoring. Upstream insists on exact versioning (thus requiring vendoring), including hacked-up versions of some upstream crates, and also insists that Debian maintainers go on a war to change Debian's Rust policy to his liking (this is why I left #bcache; I don't set these policies, I'm not interested in fighting against them, and I'm not interested in an infinite rant about how I should spend my energy on such a fight). A couple of other people and myself made some attempts to get the Rust parts of bcachefs-tools buildable and working (and yes, it was really working, and no, the version changes led to no real breakage that I know of), but you can't reasonably package software from an upstream who is so hostile to everything about your distribution. If it's “my way or the highway” about everything, I guess it's the highway, then? Maybe someone who cares deeply about bcachefs and cares deeply about Debian will pick it up, but that person would better have a really thick skin.

oguz-ismail 2y ago

[flagged]

Ygg2 2y ago
It's not a Rust specific issue. See C#/Mono, npm, Java, etc.
- cozzyd 2y ago
  Yes but thankfully nobody writes base OS tooling in those languages
  - Ygg2 2y ago
    Yeah, they just write OS in those.

mananaysiempre 2y ago

See also on the same general topic: “The modern packager’s security nightmare” (2021) [1] by Gentoo maintainer Michał Górny, and Drew DeVault’s posts on why FOSS developers should not distribute software directly or try to impose their will on distros[2,3]. [1] https://blogs.gentoo.org/mgorny/2021/02/19/the-modern-packagers-security-nightmare/ https://blogs.gentoo.org/mgorny/2021/02/19/the-modern-packag..., discussed at https://news.ycombinator.com/item?id=26203853 https://news.ycombinator.com/item?id=26203853 (320 points, 278 comments) [2] https://drewdevault.com/2019/12/09/Developers-shouldnt-distribute.html https://drewdevault.com/2019/12/09/Developers-shouldnt-distr..., no notable HN discussions [3] https://drewdevault.com/2021/09/27/Let-distros-do-their-job.html https://drewdevault.com/2021/09/27/Let-distros-do-their-job...., no notable HN discussions

1oooqooq 2y ago
exactly. the sad part is that this is being coopted into an aegument for flatpack! it's insane the discussions on some distros. they cannot see that by giving in to static libs you make every little application maintainer into a full-time distro maintainer responsible for it forever. ... good luck with that.
- mananaysiempre 2y ago
  I actually don’t entirely agree with Górny’s argument that we should use the technical tool of shared libraries to solve the social problem of not organizing the package archive in a way that allows an automatic bump of every dependency on a static library change. But I do agree with a weakened version where “static libraries” is replaced with “vendored code”, and that’s the (part of) problem TFA describes. (The rest of the problem is that the goals of Debian are incompatible with upstream refusing to support versions of their own code more than a couple of months old. Which they transparently are, so there isn’t much to argue about here.)
  - 1oooqooq 2y ago
    I'm also on (several) the fence on the solution. but the description of the problem is spot on

h2odragon 2y ago

this is "static vs shared libraries" fight again. no one remembers the first iterations, and there's more layers of "stuff" in the way now, so now one sees the actual issue for what it is. "shared libs" was the product of storage constraints; a bobble in the smooth pace of progress that shouldn't be needed now. Our faith in "the way things are done now is the right way" and our (justified) fear of messing with the foundations of running systems will make excising the notion take longer.

mananaysiempre 2y ago
It’s rather the “vendoring is hostile to distros” fight. It’s adjacent to the shared vs static one but not the same: it’s absolutely possible to have statically linked binaries tracking distro-wide dependency versions, provided the distro’s build system is robust and automated enough. Not all are.
- crote 2y ago
  "Vendoring is hostile to distros" in turn directly leads to "loose dependencies are hostile to upstream developers". Distros want to be able to mix & match upstream code with whatever version of the dependency they happen to have lying around in a drawer somewhere. Understandable, as the alternative is having to support dozens of versions of the same library. Upstream developers want to use a single fixed version of their dependencies for each release. Understandable, as the alternative is having to support support a massive test matrix for every possible version of every dependency, just on the odd chance that some obscure distro wants to mix a brand-new libfoo with a 5-year-old libbar. And all of this boils down to "versioning is actually really hard", because even with SemVer one's bug is another's feature[0] so there's still no unambiguous way to choose a version number, which in turn means upstream can't choose a version range for their dependencies and be reasonably sure that simply testing with the latest version won't result in breakage with other versions in that range. If dependency management was easy, we would've solved it decades ago. [0]: https://xkcd.com/1172/ https://xkcd.com/1172/
viraptor 2y ago
This is unrelated to shared libraries. Those strict versions are for compile-time dependencies.

frankjr 2y ago

The list of dependencies doesn't really seem crazy. Logging, parsing command line arguments, band-aiding error traits, working with uuids, reading binary data, "memset_s". All of those should be a part of the standard library as in any other programming language. The fact that you simply cannot build anything but trivial examples without taking a dependency on a third party library is just plain ridiculous and hinders Rust's adoption (as seen in this case). It's especially ridiculous considering Rust positions itself to be used in mission critical systems and yet essentially requires you to implicitly trust hundreds of maintainers for any non trivial project to not be malicious. https://github.com/koverstreet/bcachefs-tools/blob/b422b19f636329e1a082bcacd3ac6b485d7a5b3e/Cargo.toml https://github.com/koverstreet/bcachefs-tools/blob/b422b19f6...

CJefferson 2y ago
Where are those things in the standard library of C or C++, which most software is written in? Most C Debian packages have a few dependencies in my experience, they are just “standard”, because they are old and stable.
- jmb99 2y ago
  Parsing command line arguments, reading/manipulating binary data, memset_s are of course all available in the C standard library. I’m not familiar with rust, but if it’s true that dependencies are required for those types of basic operations... yikes, to say the least. If you include boost (which, admittedly, is a heavy dependency, but still a single one), everything mentioned is possible.
  - steveklabnik 2y ago
    Just to be clear about it, Rust has the same level of this stuff in the standard library as C does. Like, the equivalent of argc/argv is in the rust standard library. The library being included is more like getopt conceptually; a package built on top of that that makes things nicer.
  - nequo 2y ago

peppermint_gum 2y ago

>not even considering some hostile emails that I recently received from the upstream developer or his public rants on lkml and reddit It feels like whenever the author of bcachefs comes up, it's always because of some drama. Just the other day he clashed with Linus Torvalds: https://lore.kernel.org/lkml/CAHk-=wj1Oo9-g-yuwWuHQZU8v=VAsBceWCRLhWxy7_-QnSa1Ng@mail.gmail.com/ https://lore.kernel.org/lkml/CAHk-=wj1Oo9-g-yuwWuHQZU8v=VAsB... My reading is that he's very passionate, so he wants to "move fast and break things" and doesn't get why the others aren't necessarily very happy about it.

sp1rit 2y ago
[flagged]
jt2190 2y ago
Is bcachefs-tools going into the mainline distros or into something that’s meant to be less stable and experimental? Linus makes it sound like there’s a more appropriate place for this work. Edit: Reading through the thread, it seems like there is a claim of rigorous but effectively private testing. Without the ability to audit those results easily it’s causing a lot of worry.
- ralferoo 2y ago
  I don't think Linus is particularly concerned about bcachefs-tools, and whether a particular distributions ships with it or not isn't a concern for the kernel. Presumably though, distributions that don't ship the tools may also want to disable it in the kernel, although I'd imagine they'd leave it alone if it was previously supported. Linus' complaint was about adding feature work into a supposed minor bug fix, especially because (going from Linus' comments) they were essentially refactors of major systems that impacted other areas of the kernel.
ralferoo 2y ago
It's very clear from that thread that he doesn't understand the purpose of the stable branch. It doesn't mean "stable" as in "the best possible experience", it means it as in "this code has been tested for a long period of time with no serious defects found" so that when the stable branch is promoted to release, everything has undergone a long testing period by a broad user base. If there is a defect found, the change to a stable branch should literally be the minimal code change to fix the reported issue. Ideally, if it's a newly introduced issue (i.e. since being on the stable branch), the problematic code reverted and a different fix to the original defect applied instead (or left if it's deemed less of an issue than taking another speculative fix). Anything that requires a re-organisation of code, by definition, isn't a minimal fix. Maybe it's the correct long-term solution, but that can be done on the unstable branch, but for the stable branch, the best fix is the simplest work around. If there isn't a simple work around, the best fix is to revert everything back to the previous stable version and keep iterating on the unstable branch. The guy even admits it as well with his repeated "please don't actually use this in production" style messages - it's hard to give a greater indication than this that the code isn't yet ready for stable. I can understand why from his perspective he wants his changes in the hands of users as soon as possible - it's something he's poured his heart and soul and he strongly believes it will improve his users' experience. It's also the case that he is happy running the very latest and probably has more confidence in it that an older version. The rational choice from his perspective is to always use the latest code. But, discounting the extremely unlikely situation that his code is entirely bug free, that just means he hasn't yet found the next serious bug. If a big code change is rushed out into the stable branch, it just increases the likelihood that any serious bug won't have the time it needs in testing to have the confidence that's the branch is suitable for promotion to release.

rgname 2y ago

[flagged]

yshui 2y ago

This is pretty dumb on Debian's part. First of all I don't understand why they insist crate dependencies must be pulled from their repository. They are just source code, not built binary. AFAIK there is no other distro that does this, what they do is that they would download crates from crates.io (`cargo vendor` is a command that does this automatically) and build against that. Arch does this, Gentoo does this, NixOS does this, why does Debian has to be different? Secondly, even if they have to use crates from their repository, I don't understand what's so hard to just have multiple versions of the same crate? That will solve the problem too. This is just all-around weird what Debian is doing. (Full disclosure, I am the one who introduced the first piece of Rust code into bcachefs-tools)

wojciii 2y ago
Perhaps they want to have builds they can reproduce years later? When libraries are removed you have to update your build. This will not be the case if you use your own infrastructure (crates.io mirror).
acka 2y ago
Debian has a Social Contract[1] as well as guidelines {the DFSG}[2] regarding the commitment to only distribute free and open source software that all package maintainers must adhere to. This means that package maintainers must check the licenses of source code and documentation files, clear up any ambiguities by talking to upstream, and (as a last resort) even excise code and/or documentation from Debian's copy of the codebase if it doesn't meet the requirements of the DFSG. In practise, this means that Debian has to make its own copy of the source code available from a Debian-controlled repository, to ensure that no (accidental or otherwise) change to an upstream source archive can cause non-DFSG compliant Debian source or binary packages to be distributed. [1] https://www.debian.org/social_contract https://www.debian.org/social_contract [2] https://wiki.debian.org/DebianFreeSoftwareGuidelines https://wiki.debian.org/DebianFreeSoftwareGuidelines
- koverstreet 2y ago
  That justification doesn't work here - I provide vendored tarballs, so the source code availability argument is moot.

koverstreet 2y ago

I would rather something not be packaged at all than packaged badly; this whole experience reads like a lesson in what not to do. What the author left out in his blog post is that I specifically explained why this was going to be an issue and what was going to happen when he and I first talked about Debian packaging; and why for a package that needs to work correctly for the system to boot (fsck, mount helper, encryption unlock), playing these kinds of games with swapping dependencies out was not a good idea. But with Debian and Fedora people alike it's been like talking to a brick wall. "No, your concerns don't matter, this is our policy and we're going to do what we want with your code". They've made it very clear that I have no voice or say in how they package it. So then he breaks the build by switching to the packaged version of bindgen, an old unsupported version. And he makes no attempt to debug, doesn't even send me the build error until months later. As a result, Debian users were stuck on a broken version of -tools that wasn't passing mount options correctly, which meant that when a drive died and they needed to mount in degraded mode, they weren't able to. This happened to multiple people - that bothered to report it. This was quickly fixed upstream, but as far as I know it's still broken in Debian; and Jonathan Carter wasn't fielding any of those bug reports, I was. I'm tired, frustrated and demoralized by this drama and tired of constantly having to respond to it. This has taken up an enormous amount of my time. I really wish this guy hadn't packaged -tools for Debian in the first place. I never asked for it. I have enough on my plate to do without a bunch of distro drama to deal with as well.

haileys 2y ago
Thanks for taking the time to comment here! > So then he breaks the build by switching to the packaged version of bindgen, an old unsupported version. Could bcachefs-tools solve this problem upstream of distros by releasing a source tarball with the bindings already generated, so that you can use whatever version of bindgen you want, and bindgen is not needed at all when building from this release tarball? This would be similar in nature to traditional autotools approach where some amount of pre-compilation is done to produce a release tarball from what actually lives in the source repository. It's also what I do for some of my ffi crates. I have a script in the root of the repo which regenerates the bindings, but when published to crates.io, the bindings are already generated and bindgen is not part of the build downstream of my crate.

Brian_K_White 2y ago

The same bcachefs that Linus just ripped apart for inconsiderate and irresponsible PRs? Sensing a pattern and it's not both Debian and the kernel. I mean can you even point at 2 more proven solid large and long term projects that have proven how to do it right?

Brian_K_White 2y ago

Sure buddy. Not only Debian but the kernel itself too. Those immature unproven little projects and their silly "best practices". What do Debian or the kernel know about building and maintaining bedrock software? https://www.phoronix.com/news/Linus-Torvalds-Bcachefs-Regrets https://www.phoronix.com/news/Linus-Torvalds-Bcachefs-Regret...

rc00 2y ago
These are some of the sentiments I'm seeing where people are tired of Rust and the related crowd. Very young and/or very inexperienced Rust evangelists are showing up to experienced, long-term, and stable projects and effectively dictating that they know better because "the future" is on their side. And then when they are rebuffed, they turn to the mentally unhealthy echo chamber that is social media for reinforcement. It is a cycle of unhealthy and even toxic behavior. I'm fortunate that I haven't seen this with my mentees but it does appear that there are non-mainstream social media platforms allowing these problems to fester rather than addressing them head-on.
Brian_K_White 2y ago
Apologies I got this kinda backwards. The Debian article was written from Debians perspective not bcachefs. "sure buddy" and the rest of the sarcasm was directed at bcachefs.

suncore 2y ago

Splitting a piece of software into multiple pieces and shipping the pieces (dependencies) independently is sometimes a good idea, but it has its limits. Maybe the limit should be for dependencies which are very stable and used by many packages (libc, etc.). The hard line policy enforced by Debian here obviously is not working. Happy to see other distros solve this better. This might become really problematic for Debian in the future.

rubiquity 2y ago

Debian is going to look as ridiculous for doing this as Alma Linux is for insisting btrfs isn’t an “enterprise file system” due to it lacking RAID 5/6.

chungy 2y ago
btrfs lacking RAID 5/6 is exactly the sort of thing that makes it get written off as a toy. ZFS has had working raidz[12] since 2005, raidz3 since 2007, and draid since 2021. Completely stable and enterprise-ready.
jonathanspw 2y ago
AlmaLinux has made no such statement, for what it's worth.
- chungy 2y ago
  Red Hat Enterprise Linux excludes btrfs support in its distribution because Red Hat does not believe btrfs to be stable enough to be worth considering. That decision trickles down to recompilation projects that pretty much amount to "RHEL, but without having to pay for it".
  - cozzyd 2y ago
    And rightfully so, imo. btrfs is the only filesystem I've used where it's gotten so corrupted due to faulty memory on a computer that I had to recover the files and reinstall from scratch after replacing the memory (obviously not using btrfs the second time ..).
- rubiquity 2y ago
  Thanks for that correction. I misunderstood a forum post that was probably someone being snarky/cynical.