Debian 14 の展望を予想する

by

Debian 14 “forky” は、2027 年頃に登場する予定の次期安定版だ。すでに testing ブランチとして開発が始まっており、trixie を土台にした進化系として、いくつかの方針が明確になりつつある。ここでは、現在の sid・開発者メーリングリスト・フォーラムの動向から見える変化を整理しておく。

1. 確度が高い変更（公式文書に明示 or 強く示唆）

Debian 13 “trixie” のリリースノートには、「forky で削除・移行する」旨の宣言が多数ある。すなわち、これらはすでに確定している将来の仕様変更だ。

  • sudo-ldap 削除 認証連携は libsss-sudo に一本化される。
  • OpenSSH の分離 GSSAPI 機能が本体から除外され、openssh-*-gssapi に分割される。
  • fcitx4 系の削除 入力メソッドは fcitx5 または ibus に統一される。
  • LXD から Incus への移行 Canonical とのライセンス問題を受け、Debian 側は Incus に移行する方針を取る。
  • ISC DHCP の撤退 DHCP サーバおよびクライアントとして非推奨となり、Kea や systemd-networkd などが後継となる。
  • KDE Frameworks 6 への移行 Qt5/KF5 系は廃止され、Plasma 6 が標準になる見込み。
  • 新アーキテクチャ loong64 の正式化 LoongArch64 系 CPU の公式サポートが進行中であり、forky での本格対応が見込まれる。

これらは trixie 期から明示的に「forky で適用」と示されているものであり、“予想”というより“時間の問題”として扱ってよい領域である。

2. 確度「高め」の予想（sid / upstream のロードマップからほぼ読めるもの）

ここからは、現在の sid および upstream の動きから合理的に導ける変化である。

  • カーネルは 6.12 以降の LTS 世代 io_uring、eBPF、cgroupv2 などが前提機能として定着する。
  • Python 3.13 以降の採用 古い 3.x 系は段階的に削除され、サポート対象が整理される。
  • Qt6 / GTK4 時代への移行 デスクトップ全体がモダンツールキット前提に寄り、Qt5 や古い GTK 依存は縮小する。
  • Wayland 優先の固定化 GNOME や KDE に続き、他デスクトップも X11 依存度を下げる方向に進む。
  • セキュリティ方針の簡素化 弱い暗号や古いプロトコルを排除し、暗号設定を整理する方向に進む。
  • コンテナ／仮想化基盤の整理 Podman、containerd、Incus などの OSS 基盤を軸に据え、Docker は明確にサードパーティ扱いとして位置付けられていく可能性が高い。

これらは「いずれそうなる」と多くの開発者が見ている流れであり、forky 世代では事実上の標準として扱われる可能性が高い。

3. 妥当な範囲の予想（運用目線で備えておくと筋が良いもの）

次に、まだ公式な確約はないものの、現状の開発状況から見て十分に起こり得ると考えられる項目を挙げておく。

  • RISC-V・LoongArch の位置付け強化 ARM64 と並ぶ選択肢として、次期世代 CPU アーキテクチャの扱いがより実用レベルで整理される。
  • Reproducible Builds の標準化推進 パッケージの再現可能ビルドが一層重視され、署名やハッシュ検証と合わせて信頼性が高まる。
  • テスト自動化の要件強化 autopkgtest や CI 整備が事実上の必須要件に近づき、テスト未整備パッケージへの圧力が強まる。
  • PipeWire への完全移行 オーディオ層は PipeWire ベースを前提とし、PulseAudio 単体構成は縮小していく可能性が高い。
  • X11 周辺機能の縮退 古い X11 専用ツールやドライバは段階的に整理され、XWayland を含む互換レイヤに役割が集約される。

これらは「妥当な範囲の予想」として、運用設計や環境更新計画を考える際に意識しておくと、後から慌てずに済む領域である。

4. 運用者としての注目点

  • 認証連携を見直し、sudo-ldap や古い NSS への依存を排除しておく。
  • SSH 設定を GSSAPI 機能分離後の構成に対応させる。
  • fcitx4 や Qt5 ベースの GUI ツールを、fcitx5 や Qt6 ベース環境へ早めに置き換える。
  • DHCP や LXD を利用している場合、Kea や Incus など後継技術への移行パスを用意する。
  • KDE/Qt 系アプリや独自ツールの依存関係を整理し、次期スタックでのビルドと動作を検証しておく。
  • アーキテクチャ依存のビルド環境を trixie/testing のうちに試し、forky 世代を見据えた構成に寄せておく。

Debian 14 は「劇的な刷新」というより、ここ十数年積み重ねてきた整理と標準化を完成させるリリースになる可能性が高い。既存環境を順当に整えておけば、移行コストは比較的素直に収まるはずだ。