Rustの必須依存関係、2026年5月からDebian APTに導入予定

 (lists.debian.org)
3 ポイント 投稿者 GN⁺ 2025-11-02 | 1件のコメント | WhatsAppで共有
  • DebianのAPTパッケージマネージャーに、2026年5月以降Rustベースのコードと依存関係が含まれる予定
  • 初期段階ではRustコンパイラ、標準ライブラリ、そしてSequoiaエコシステムが統合対象
  • .deb、.ar、.tarファイルのパーサーとHTTP署名検証コードが、メモリ安全性と単体テスト強化の観点で主な改善領域
  • Rustツールチェーンのないポートは、6か月以内にRust環境を構築するか、サポート終了(sunset) が必要
  • プロジェクト全体を現代的なツールと技術へ移行するための措置であり、旧式ハードウェア互換性に足を引っ張られないための方向性

APTへのRustコード導入計画

  • APTにRustコードとハード依存関係(hard dependency) を2026年5月以降に導入予定
    • 導入時期は2026年5月以降であり、それ以前には適用されない
  • 初期統合範囲はRustコンパイラ、標準ライブラリ、Sequoiaエコシステムに限定される

コード品質と安全性向上の目的

  • .deb、.ar、.tarファイルのパースコードとHTTP署名検証コードがRust導入の主な対象
    • この領域はメモリ安全な言語と強化された単体テスト体制の利点を大きく受けると明記されている

ポート保守担当者への要件

  • Rustツールチェーンのないポートは、6か月以内にRust環境を構築しなければならない
    • そうでなければ当該ポートは中止(sunset) される可能性がある

プロジェクトの方向性

  • Debianプロジェクトが現代的なツールと技術を活用して発展すべきことを強調
    • 旧式ハードウェアやレトロコンピューティング機器に合わせようとする試みによって、発展が遅れてはならないと明記されている

その他の情報

  • 発信者はDebianおよびUbuntuのコア開発者Julian Andres Klode
  • メールはDebian開発者メーリングリストdebian-develに投稿された
  • 添付ファイルとしてPGP署名(signature.asc) を含む
  • 追加の技術的詳細や日程変更についての言及はない

関連記事

1件のコメント

 
GN⁺ 2025-11-02
Hacker Newsの意見

  • 今こそその時期が来たように思う。信頼できないデータをパースするコードをいまだにCで維持し続けるのは、時間がたつほど膨らむ技術的負債だ
    RustはCよりはるかに書きにくいわけでもなく、言語設計とコード安全性に関する現在の知見を反映してCを作り直したらこうなりそう、という言語だ
    実用上の理由で32ビットx86サポートを捨てられるなら、こうしたアーキテクチャも同様だ。本当に維持したいならRustツールチェーンのバックエンドを自分で作るべきだ

    • 現在、ベースシステムで中核アプリケーションに許されている言語は、C、C++、Shell(bash)、Perl、Pythonくらいだ。Pythonが追加されたのは約20年前で、RustはCの役割を置き換えるのに十分近い、最初の言語だ
      Goもそれなりに近かったが、systemdのような中核システムに使えるほど真剣に議論されたことはない。過去にC++、Python、Perlが追加された時も、こういう論争があったのか気になる
    • 「.deb、.ar、.tarパーサやHTTP署名検証コードはメモリ安全な言語の恩恵を受ける」とはいうが、この30年間で安定したコードをわざわざ新しい言語で書き直して、どんな実利があるのか疑問だ
      すでに実戦で鍛えられたコードを捨てて、新しい互換性問題やバグを生むことに本当に価値があるのだろうか
    • 古いCコードのセキュリティ問題を解決する、より実用的なアプローチとして Fil-Cプロジェクト がある。Cを事実上管理された言語のようにして、再実装の必要性を減らす方式だ
    • これは単なるメモリ安全性の問題ではない。Cコミュニティの高齢化で保守要員を見つけにくくなっている。うちのチームもC/C++コードをすべて別の言語へ移している。大半のC/C++開発者は40代くらいで、転職意欲が低い
    • RustがCを現代的に再発明した言語だという主張には同意しにくい。たとえば COSMICデスクトップの時計ウィジェットのコード は、同程度の複雑さのCコード（GNU coreutilsなど）よりずっと読みにくい

  • Rustでコアシステムを書き直す流れは強いが、古いツールを書き換えることでセキュリティが本当に向上するのかは疑問だ
    新しいシステムの導入が難しいのは理解できるが、依然として電信時代の設計判断の上に何層も積み上げた構造を維持している感じがする

    • こうした再実装の理由として、二つ挙げられる。
      第一に、古いC/C++コードベースを扱いたがる新規コントリビューターがほとんどいない。Rustへ移せば新しい開発者の流入がしやすくなる
      第二に、信頼性は利用頻度で検証されるが、安全性は攻撃によってしか検証されない。古いコードがあらゆる攻撃ベクトルを通過したとは限らない。だから先回りしたセキュリティ強化には十分な大義がある
    • uutils/coreutilsはMITライセンス、GNU coreutilsはGPLなので、ライセンスの違いがある。企業にとってはこれが重要なポイントかもしれない
    • 誰かが学ばなければならないのだから、単純でテストしやすいプロジェクトを練習用に再実装するのは悪くないと思う。ただ、その成果物が原作を置き換えるかは別の議論だ

  • Debianのメールスレッドによれば、Rustはすでに大半のDebianリリースアーキテクチャで必須だ
    関連メール では、alpha、hppa、m68k、sh4だけが例外として挙げられている。これらのアーキテクチャの今後の運命が気になる

    • こうした古いマシンをまだ使っている人がいるのか、本気で気になる。ほとんどが20年以上前のハードウェアだ。
      Rustはm68k向けに Tier 3ターゲット を提供しているが、他のアーキテクチャにはない。実際のユースケースが知りたい
    • Debian Supported Architectures によれば、これらのプラットフォームは非公式状態だ。
      32ビットx86やMIPSが外れた一方で、これらが残っているのは意外だ。個人的には郷愁もあるが、実際の用途はよく分からない
    • m68kにはすでにLLVMポートがあるので、Rust実装は可能だ。alpha、hppa、sh4向けLLVMバックエンドも教育用資料として価値がある
      以前のLLVMにはDEC Alphaバックエンドがあったが、かなり昔の話だ
    • Ubuntuの立場では、こうしたアーキテクチャには商業的価値がない
    • 完全に旧式なのだから、単に最後の対応バージョンで止めるか、独自ディストリビューションを作ればいい。Rust対応を追加するのは非現実的だ

  • Rustコミュニティには既存プロジェクトに入り込むのではなく、新しく現代的な技術を自分たちで作って証明してほしい
    Redoxのような独立プロジェクトがその例だが、なぜこうした試みをもっと後押ししないのか残念だ

    • これはDebianがRust依存関係を追加した正式な決定だ。外部のRustファンが押し付けたものではない
      もちろん「Rustで書き直せ」と騒ぐ過激なファンもいるが、今回の件はそれとは違う
    • ripgrepがまさにそういう例だ。新しく作られ、人々にも実際に好まれている

  • Rust標準ライブラリを使うのは構わないが、単純なdebパーサをビルドするためにcargoパッケージ500個を引っ張ってくるのは望ましくない

  • Rust-for-GCCポートが安定するまで待つのが合理的かもしれない
    カーネルもGCC対応ができるまではRustを必須にはしない予定だ。
    複数の実装が出てくれば、言語も今ほど不安定ではなくなるだろう
    ただ、今アーキテクチャ対応を打ち切ると、後になってRustツールチェーンができた時に復帰手順が複雑になる可能性がある

    • 実のところ、こうしたアーキテクチャはすでに10年以上Debian本体から外れている。今回の変更で新たに外れるわけではない
    • 公式サポートはなく、個人が余暇で保守している程度だ。企業が長期保守を引き受けない限り、復帰は難しい
    • GCCRSはまだlibcoreすらビルドできず、Rust 1.50相当だ。汎用コンパイラになるには数年はかかりそうだ
      むしろrustc_codegen_gccのほうが先に安定化する可能性が高い
    • これらのポートはDebian正式リリースには含まれず、unstableチャネルでのみ配布されている

  • Debian Rust議論メールの投稿者が keepassxcパッケージメンテナー だという点を思い出した
    過去にもupstream開発者やユーザーに対して荒っぽい言動をしたというスレッドがある

    • 私もそのメールを見てすぐ確認したが、以前のスレッドを思い出して笑ってしまった
    • 正直、彼の言い回しは荒いが、率直なだけで侮辱的ではない。無用なドラマに見える
    • HNの投稿自体は攻撃的ではないのに、一部が過剰に受け取っているようだ
    • こうした文化はフリーソフトウェア界隈に蔓延している。実際のユーザーより理想のユーザー像を追う傾向は、GNOME 3やMozillaの時代から続いてきたと思う

  • ある人の意見が変わっていく過程を見るのは興味深い。以前の発言へのリンク

    • 時間とともに考えを変える姿勢は好ましい
    • APTへのRust導入も、coreutils移行のように管理上の判断である可能性が高い

  • Rustは単なる流行(hype) だと思う。組み込みの世界では今でもCが王だ。
    実際にRustを使っている、あるいは検討している人を周囲で見たことがない

    • 「自分の周りにはいない」で結論づけるのは無理がある。Rustを使う組み込み開発者は多い
    • AWS内部では、EC2、IAM、DynamoDB、S3などの中核サービスがRustで書かれている。
      性能とメモリ効率を維持しながら開発速度が高い。
      唯一の欠点はバイナリサイズだ。Rustの将来はすでに確かなものだと思う
    • Rustは組み込みでも強力だが、ベンダー支援が不足していてハードウェアごとの初期作業量が多い。
      それでも魅力はメモリ安全性だけではなく、言語とツールチェーン全体の品質にある
    • avr-rust、esp-rs、cortex-m などにより、組み込みエコシステムも少しずつ変わりつつある
    • Microsoft、GoogleなどでもRustが議論され、実製品に適用されている

  • 多言語(polyglot) 環境は問題をさらに増やすと思う。
    Python、Node、Go、Rustなど、それぞれ異なるツールチェーンとパッケージマネージャが必要で複雑だ
    Nodeでバッファオーバーフローをなくしたら、今度はサプライチェーン攻撃が増えた。
    いっそ最初からやり直したほうがよく、Rustを全面的に使いたいならRedox OSに貢献するのが筋だ

    • 現実には各言語に固有の長所と短所があり、Debianは実用的なOSとして多様な言語を支える必要がある
      すべてを一つの言語で書き直すのは非現実的で、Redoxを推すのもかえって非効率かもしれない
      Rustはすでに十分実証された言語であり、Cより修正時に自爆しにくいコンパイル言語として価値がある
      古いアーキテクチャを捨てるのも無理はない
    • Debianのような大規模プロジェクトは、選択肢を広げるほうが合理的だ。Rustを追加するのは十分に理解できる決定だ
      どの言語を外し、どれを入れるかはDebianメンテナーが判断すべきことだ
    • Linuxはすでに数十年前に複雑さとの戦いを諦めた