ハクソク

世界を動かす技術を、日本語で。

Bcachefsが「外部管理」に移行

2025年8月30日原文(lwn.net)

概要

Debianにおけるbcachefs-toolsのパッケージング問題と、その周辺で発生したRust依存関係やバージョン管理の課題を整理。 Debianの安定版モデルとbcachefs-toolsの開発サイクルとのミスマッチが議論の中心。 複数の関係者がパッケージの改善や調整に尽力し、上流・Debian双方で協力が進んだ経緯。 Rust依存の扱いや、異なるディストリビューション間での一貫性確保の難しさが浮き彫りに。 最終的に、Debianとbcachefs-toolsの双方にとって前向きな成果も生まれた事例。

Debianにおけるbcachefs-toolsパッケージング問題の整理

  • Debian での bcachefs-tools パッケージングを巡る議論

    • バージョン依存性 の問題（古すぎる/新しすぎるRustパッケージ）
    • 将来的な安定版での保守性 への懸念
    • 例外取得プロセス （carve-outs/exceptions）の存在

  • 依存パッケージのバージョン問題

    • bindgen 0.69.4が必要だが、Debian unstableは0.66.1を提供
    • rust-errno 0.2.xが必要だが、Debian unstableは0.3.8を提供
    • 他にもspurious/cruftな依存が存在

  • Debianの安定版モデルとのミスマッチ

    • bcachefs-toolsの開発サイクルは 2年間のハードフリーズ に適合しない可能性
    • ユーザーが新しいカーネルを外部から導入するケースが多い
    • カーネルとユーザーランドの同期性 が重要

  • パッケージメンテナンスの経緯

    • 元々C実装でJonathan CarterがDebianで保守
    • Rust依存が増え、メンテナンスが困難に
    • paravoid氏らがDebian BTSやupstreamと連携し、Rust依存解消やパッチ適用を推進
    • bindgenのfork問題も、Debianとupstreamで協力しRust本家に受け入れられる形に修正

  • 異なるディストリビューション間の一貫性問題

    • Fedoraはバンドル解除を行わない方針
    • Debianが独自にRust依存を外すと、他ディストリとバージョン不整合が発生
    • bindgenのようなFFIツールは、バージョン違いで深刻なバグ（heisenbug）を生むリスク

  • ディストリビューション独自変更のリスク

    • ArchのLTO有効化で不具合発生（QA不足が原因）
    • こうした変更は upstreamへ還元 し、広範なテスト・QAを受けるべき

  • 協力的な開発の成果

    • Debian・upstream双方でコミュニケーションを重ね、パッケージ品質向上
    • bcachefs-toolsだけでなく、Debian全体のRustパッケージエコシステムも改善
    • 結果として、Debian Trixieで最新状態かつ安定したパッケージ提供が可能に

bcachefs-toolsとDebian安定版の今後

  • bcachefs-tools の現状

    • まだ安定版に含めるには早い段階
    • 今後のbackport方針や安定性検証が必要
    • 実験的段階ではアップグレード・ダウングレードの互換性重視

  • Debianユーザーへの影響

    • 安定版にbcachefs-toolsを導入するには、カーネル・ユーザーランド両方の管理が必要
    • 現状は、外部リポジトリや独自ビルドでの運用が現実的

  • 今後の課題

    • Rust依存のパッケージを安定的に管理する体制構築
    • 複数ディストリビューション間での依存性整合性維持
    • upstreamとの更なる協力による品質・互換性向上

まとめ

  • bcachefs-tools のDebianパッケージ化は、多くの技術的・運用的課題をはらむ
  • Rust依存管理 や ディストリビューション間の調整 が重要課題
  • Debianコミュニティ と upstream が連携し、問題解決とエコシステム全体の改善を実現
  • 今後も安定性・互換性確保に向けた継続的な協力と議論が必要

Hackerたちの意見

うわ、ZFSやDKMSの面倒から解放されて楽しんでたのに、今度はbcachefsも同じ状況になりそうだね。DKMSのトラブルや時々の不具合に対処するか、どんどん古くなるカーネルバージョンに留まるかって感じ。

└

うわ、ZFSやDKMSの面倒から解放されて楽しんでたのに、今度はbcachefsも同じ状況になりそうだね。DKMSのトラブルや時々の不具合に対処するか、どんどん古くなるカーネルバージョンに留まるかって感じ。 君のディストロは、希望があればbcachefsを簡単に含められるんじゃない？ZFSとLinuxの状況はほとんどLinuxの宗教的なこだわりが暴走してると思うけど、その特有の問題はbcachefsにはないんじゃない？bcachefsの問題はbtrfsの問題でもある。結局、bcachefsはZFSがすでに解決している問題を解決するためにはほとんど機能していないんだよね。

└

参考までに、DKMSだけがアウトオブツリーのモジュールを配布する方法じゃないよ。https://github.com/chimera-linux/ckms

└

記事によると、bcachefsはメインラインカーネルから削除されないみたい。これは主に、Linusや他のカーネル開発者がKentと直接やり取りしなくて済むようにするための対策っぽいね。

こんなに時間がかかるとは驚きだね。

Debianでも孤立してるけど、btrfsに対してどんな大きな利点があるのかはよくわからないな。最近のbtrfsはかなり安定してるし。

└

btrfsは6.1以前のカーネルではマルチディスク環境では使えなかった。そこからは試してないけど、今のbtrfsはそういう環境で安定してるの？あと、https://www.phoronix.com/news/Josef-Bacik-Leaves-Metaも見てみて。

関連: Linux CoCがKent Overstreet（Bcachefs）に関する決定を発表 (kernel.org) https://news.ycombinator.com/item?id=42221564 - 2024-11-23, コメント103件

└

最近、いろんな関係者の間で摩擦があったから、この最新のニュースはその決定の直接的な結果じゃないと思うよ。例えば、これを見てみて：https://news.ycombinator.com/item?id=44464396

俺だけかな？Kentが自分の考えるカーネル開発のやり方に自爆的に固執してるように見えるんだけど。どの側もミスはあったと思うけど、外から見るとKentはルールを守りたくないだけに見えるな（何年も我慢してもらってるのに）。

└

カーネル開発だけじゃないよね。lwnのスレッドでも、Debianの開発者たちとのやり取りが難しいって言ってたし。俺の意見だけど、彼のコミュニケーションからは、他のプロジェクトが彼の仕事を含んでいても、焦点や優先事項、方針が彼のプロジェクトとは違うって認めたくない感じがする。さらに、他のケースでは例外が認められてるから、自分のケースでも例外を期待してるみたい。俺は、彼が発表用のメーリングリストで別に開発した方がいいと思う。緊急の変更があったら、そのリストに送信して、他の関係者がその変更をカーネルやディストリビューションに取り込むプロセスを整理すればいい。もし他の人が配布した古いバージョンからバグレポートを持ってきたら、最新のバージョンを彼のリポジトリからどうやって入手するか教えてあげて、ディストリビューターにも優しく促してあげればいい。そうなると、ユーザーは古いバージョンを使うことになって、修正がすぐには来ないけど、今のやり方だってユーザーにすぐ修正を届けることはできてないからね。

└

ケントは間違ってると思うけど、リーナス以下のカーネルの人たちが問題を説明できないのは本当に助けにならないよね。代わりに遊び場の罵倒に走っちゃってるし。プロフェッショナルじゃないし、敵対的な作業環境を作るだけで、ケントの行動がなぜ問題なのかを伝えられてないから、彼がそれを信じられないのも少し同情する。

Hacker Newsで議論の続きを見る