On Tue, Sep 03, 2024 at 11:37:32PM GMT, Martin Steigerwald wrote: > Kent Overstreet - 07.08.24, 21:55:09 CEST: > > On Wed, Aug 07, 2024 at 08:58:23PM GMT, Martin Steigerwald wrote: > > > I amended the subject line a bit. I am not sure whether Debian Testing > > > or Debian Unstable should also be avoided. > > > > Unstable as well - unstable is stuck at 1.9.1 and tools is up to 1.9.4, > > and it's their policy of switching rust dependencies to distro packages > > that broke the build. > > Experimental meanwhile has 1.9.4. > > But I do find this quite sad and concerning: > > https://jonathancarter.org/2024/08/29/orphaning-bcachefs-tools-in-debian/ > > I do not completely agree with removing it from Debian Unstable aka Sid at > this time, but if upstream development continues like this until too short > before Debian 13 aka Trixie release I can somewhat understand. However it > would still be good to have it there for people who use Debian Sid to > test.
Upstream development continues how...? I would like Debian people to really consider if they might be overreaching with their policies too much. For now, we really need to be able to update bcachefs-tools in a timely manner, because - bugs happen: when updates stopped and debian users were stuck on 1.9.1, that left users with filesystems they weren't able to mount - their machines were down - because of the bug with passing mount options, they weren't able to mount degraded. And I must repeat, I was the one fielding those bug reports, not the Debian package maintainer. I don't want Debian creating a mess and leaving me to deal with the aftermath. - because -tools needs to stay up-to-date with on disk format features in the kernel > I more and more come to the conclusion myself that BCacheFS might be just > a tad bit too much of a moving target for me at the moment. > > BTRFS can be used just fine in Debian Stable meanwhile. But it took quite a > while to get there. Version of btrfs-progs in Unstable is available as a > backport for Debian stable. As far as I understand this cannot be done > with BCacheFS tools without putting all the dependencies as is into the > package and violating the principle to package a library dependency in one > place and be able to update it for security updates in one place for all > the applications and tools depending on it to benefit from them in one go. I still have not yet heard a single good reason for this policy. The rust dependencies are statically linked, and that's not going to change because dynamic linking that works with the full Rust typesystem is, simply, a _really_ hard problem that's going to take a massive enginering effort to solve. Swift was able to do it - but I'm quite familiar with what it took to do that, and they were only able to because Apple invested significantly into it. So, given that they're statically linked, why? It can't be for security updates, because to update a dependency we _still_ have to update and spin a new release of bcachefs-tools. And that's not such a big deal, because nodays there's bots that notify me if I need to do that. So it seems to me that Debian people just aren't thinking things through.
