His side is that basically it doesn't make sense to package the tools for an experimental FS in an OS that's going to get very far behind, as debian stable will do, since the tools have to iterate rapidly to fix problems with releases of the FS. Debian-stable had an old set of some rust libraries and the packager relaxed the dependency constraints in order to package it, which doesn't make a lot of sense on something you are hoping to fix your filesystem.
Basically it shouldn't be packaged for LTS-class OS releases until it's not experimental.
Kent's issue IIRC was that they loosened the dependencies, full-stop. Debian presumably isn't replicating his entire testing regime when they change all the dependencies being compiled in. The potential exists for a bug to be introduced that is genuinely consequential to the user, moreso than for, say, a broken calendar app. Combine that with a rapidly changing FS and the fact that any issues would likely be blamed on his FS and I can see why he might feel that way.
If a distro chose to build some program with a different set of dependencies than what is specified by its author, then arguably it is not the same piece of software anymore. If Debian wants to do that - which I think they 100% have the rights to do, this is free software after all - they should make it clear that they will also take over the maintenance responsibility for it as well.
Distros generally do try to do this, but it doesn't matter much in practice, not enough users go to the distro by default (in part because the distro maintainers, quite understandably, can't actually solve most of the problems, even the ones they caused). So a distro that releases a broken package inevitably causes a support burden for upstream.
(I personally agree that debian's "let's just relax version dependencies on rust projects and hope that it works" policy is insane: a recipe for all kinds of subtle breakage that no-one working upstream is even trying to avoid. And this kind of fiddling is not unique to rust, either, nor is bcachefs the first project to say "don't use debian's packages")
> they should make it clear that they will also take over the maintenance responsibility for it as well.
Don't they already? I was always told that if you hit a bug in a distro package, you report it to the maintainer, and then if applicable they can pass it upstream. The whole point of a distro (at least the kind Debian is) is to be its own thing.
A large part of the issue here was the snafu resulted in Debian users not getting updates for months for a critical fix, and then not being able to mount in degraded mode, and I was the one fielding those bug reports.
Okay, so ask if they're using your packages or the distro packages, and if it's the latter tell them to talk to the person who maintains those packages. If it was me I would have that be part of the bug report form up front, but I don't know what your process is.
That's just passing the buck, it doesn't do anything for the users who were affected by the very real screw up
It also doesn't work in practice because I have to do most of the diagnosis before I find it if it's my bug or Debian's.
The only real solution is for Debian to be better at working with upstream, and not do things they've been told are going to cause problems, and not drop the ball when they do.
> It also doesn't work in practice because I have to do most of the diagnosis before I find it if it's my bug or Debian's.
No, you ask that first and if it's a downstream package you stop working on it. If the downstream maintainer determines that it is on your end and not theirs, then you can pick it back up.
> The only real solution is for Debian to be better at working with upstream, and not do things they've been told are going to cause problems, and not drop the ball when they do.
Assuming that "working with upstream" means "adopting upstream code in direct contravention of their own policies": If your solution depends on Debian not being Debian, then it's unlikely to work.
> No, you ask that first and if it's a downstream package you stop working on it. If the downstream maintainer determines that it is on your end and not theirs, then you can pick it back up.
They're not going to devote that kind of time. That just means bugs not getting looked at or fixed.
> Assuming that "working with upstream" means "adopting upstream code in direct contravention of their own policies": If your solution depends on Debian not being Debian, then it's unlikely to work.
I'm not sure why you think that policies that are causing problems shouldn't change.
Again: they volunteered to package it, they did it badly and users were affected. Until they can get their act together, bcachefs-tools won't be in Debian.
That's ok. There are other distros, and there's no rush.
Distros do this all the time with C libraries. Until newer languages added support for lock files and stuff, it was pretty normal to use slightly different dependencies.
> [bcachefs auhor's] side is that basically it doesn't make sense to package the tools for an experimental FS in an OS that's going to get very far behind
If the bcachefs author's believe the tool is too unstable for Debian stable and Debian developer's believe bcachefs is too unstable for Debian stable [1], it sounds as if they agree.
To my knowledge, Debian changed deps in bcachefs-tools to synchronize with Debian's Rust repo, breaking it. It's one part that it's a green fs, and the other with clashing expectations of how to treat dependencies between Rust and Debian.
Basically it shouldn't be packaged for LTS-class OS releases until it's not experimental.