[kijin]

> There's also the issue that having multiple versions means maintaining multiple versions (applying security fixes and so on).

This is the most important part. Debian LTS maintains packages for 5 years. Canonical takes Debian sources, and offers to maintain their LTS for 10 years. Red Hat also promises 10 years of support. They don't want anything in the core part of their stable branches that they can't promise to maintain for the next 5-10 years, when they have no assurance that upstream will even exist that long.

If you want to move fast and break things, that's also fine. Just build and distribute your own .deb or .rpm. No need to bother distro maintainers who are already doing so much thankless work.

[zamadatix]

I didn't get the impression anyone bothered the maintainers to do this, the article implies they chose to package it on their own accord.

[kijin]

Yes, and they chose to stop packaging it, again on their own accord.

Except this time, they seem to have made the decision because upstream was bothering them too much.

[zamadatix]

No arguments there, I'm more talking what that means for the "build and distribute your own dev/rpm" part that follows. Why are the only options "do work for maintainers" or "provide a prebuilt package for the distro", what happened to "nobody said this needed to be done yet"?

[kijin]

No problem, if upstream doesn't want their software packaged for Distro X, nobody needs to do anything.

The thing about Linux filesystems, though, is that they consist of two parts: the kernel patch and the userspace tooling. Bcachefs is already in the kernel, so it's a bit awkward to leave out bcachefs-tools. Which is probably why it got packaged in the first place. Stable distros generally don't want loose ends flailing about in such a critical part of their system. If nobody wants to maintain bcachefs-tools for Debian, Debian will probably remove bcachefs entirely from their kernel as well.