4 ms·

What's all that about the bcachefs author's complaints with Rust and Debian? I'm far out of the loop on this stuff.

ajb 2y ago
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.
- kstrauser 2y ago
  Ah, I see. So "the Rust team" here means the team of Debian maintainers who package Rust for it, not the Rust developers? That makes sense.
  - ajb 2y ago
    Yeah I assume that's what "the Rust team" meant
- knowitnone 2y ago
  This makes perfect sense to me. Why would Debian-stable include something obviously not stable. They have an experimental branch for a reason
  - 6SixTy 2y ago
    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.
- bhelkey 2y ago
  > [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. [1] https://jonathancarter.org/2024/08/29/orphaning-bcachefs-tools-in-debian/ https://jonathancarter.org/2024/08/29/orphaning-bcachefs-too...
- dralley 2y ago
  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.
  - nialv7 2y ago
    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.
    - NewJazz 2y ago
      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.
      - nialv7 2y ago
        Lock files _are_ code. Same for meson.build or CMakeList.txt. We don't use to have the ability to precisely specify dependencies in code, now we do. Building with a patched codebase is effectively building a fork.
    - yjftsjthsd-h 2y ago
      > 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.
elitepleb 2y ago
Debian would compile dependencies with versions lower than specified in the project, reintroducing bugs that users would blame upstream for, https://www.phoronix.com/news/Debian-Orphans-Bcachefs-Tools https://www.phoronix.com/news/Debian-Orphans-Bcachefs-Tools
- kstrauser 2y ago
  Got it. I could see that being an issue.
- linsomniac 2y ago
  Why is Kent not providing his own deb packages that users can install to override the Debian provided ones to get updates?
  - tmtvl 2y ago
    Because he isn't a Debian packager. That isn't his job.
  - koverstreet 2y ago
    Perhaps down the road, after experimental is lifted. For now I've generally been telling distros to slow down. For anything this big staging the release is important, we don't need or want to be in every distro right away (the Fedora people were also _extremely_ gung ho in the past and I told them the same thing). Until every outstanding critical bug report is fixed (and there are still a few), I want power users testing it who know how to deal with things breaking, I don't want unsuspecting users getting bit.
    - nikp123 2y ago
      Already using it on a 3 drive gaming PC on NixOS and it's been great so far. The caching algo massively speeds up interactions and load times. Hope you continue the good work and best of luck.
    - linsomniac 2y ago
      Devil's advocate: You may find that it better achieves your goal to provide packages and say "For power users testing only". You might also be able to petition Debian to have it removed if it's leading to people foot-gunning. If I can help with deb/rpm packaging, let me know. I'm a power user here, excited about bcachefs, but haven't tried it because I don't have the time to give it a worthy test (remembering how much time I put into getting ZFS stable on Linux). Thanks for your hard work on it!

ajb 2y ago

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.

kstrauser 2y ago
Ah, I see. So "the Rust team" here means the team of Debian maintainers who package Rust for it, not the Rust developers? That makes sense.
- ajb 2y ago
  Yeah I assume that's what "the Rust team" meant
knowitnone 2y ago
This makes perfect sense to me. Why would Debian-stable include something obviously not stable. They have an experimental branch for a reason
- 6SixTy 2y ago
  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.
bhelkey 2y ago
> [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. [1] https://jonathancarter.org/2024/08/29/orphaning-bcachefs-tools-in-debian/ https://jonathancarter.org/2024/08/29/orphaning-bcachefs-too...
dralley 2y ago
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.
- nialv7 2y ago
  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.
  - NewJazz 2y ago
    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.
    - nialv7 2y ago
      Lock files _are_ code. Same for meson.build or CMakeList.txt. We don't use to have the ability to precisely specify dependencies in code, now we do. Building with a patched codebase is effectively building a fork.
  - yjftsjthsd-h 2y ago
    > 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.

elitepleb 2y ago

Debian would compile dependencies with versions lower than specified in the project, reintroducing bugs that users would blame upstream for, https://www.phoronix.com/news/Debian-Orphans-Bcachefs-Tools https://www.phoronix.com/news/Debian-Orphans-Bcachefs-Tools

kstrauser 2y ago
Got it. I could see that being an issue.
linsomniac 2y ago
Why is Kent not providing his own deb packages that users can install to override the Debian provided ones to get updates?
- tmtvl 2y ago
  Because he isn't a Debian packager. That isn't his job.
- koverstreet 2y ago
  Perhaps down the road, after experimental is lifted. For now I've generally been telling distros to slow down. For anything this big staging the release is important, we don't need or want to be in every distro right away (the Fedora people were also _extremely_ gung ho in the past and I told them the same thing). Until every outstanding critical bug report is fixed (and there are still a few), I want power users testing it who know how to deal with things breaking, I don't want unsuspecting users getting bit.
  - nikp123 2y ago
    Already using it on a 3 drive gaming PC on NixOS and it's been great so far. The caching algo massively speeds up interactions and load times. Hope you continue the good work and best of luck.
  - linsomniac 2y ago
    Devil's advocate: You may find that it better achieves your goal to provide packages and say "For power users testing only". You might also be able to petition Debian to have it removed if it's leading to people foot-gunning. If I can help with deb/rpm packaging, let me know. I'm a power user here, excited about bcachefs, but haven't tried it because I don't have the time to give it a worthy test (remembering how much time I put into getting ZFS stable on Linux). Thanks for your hard work on it!