4 ms·

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

by 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.

by ajb 2y ago

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.