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.
