加载失败
这场讨论源于 Debian 邮件列表上一封提出“从五月起对所有 Debian 发行端口强制 Rust 硬依赖”的通知（邮件作者来自商业厂商并参与 APT 维护），并说明部分老旧架构（如 alpha、hppa、m68k、sh4）例外。争论围绕把 APT 等处理不受信任输入的子系统用 Rust 重写能否提升安全性、以及这样做在架构支持、工具链（rustc/LLVM、gcc 后端）、打包与供应链审计上的成本。评论同时提出替代方案（例如 Fil‑C、rustc_codegen_gcc/gccrs、仅重写解析器或写新项目示范收益），并把技术分歧放大为社区文化与维护责任的权力争论。相关背景还包括 Sequoia‑PGP（Rust 的 OpenPGP 实现）在 Debian 中的采用、以及 Debian 对静态链接/重建的运维挑战。
支持者认为把处理来自不受信任输入的关键模块（如 .deb/.ar/.tar 解析、HTTP 签名验证）用 Rust 重写，能显著减少由空间/时间内存错误引起的可利用漏洞，并举出历史 CVE 作为论据。反对者反驳说并非所有安全问题来源于内存不安全，密码学核心更适合形式化验证，且逻辑缺陷、设计问题和供给链攻击不会被语言本身解决。讨论还指出重写风险：新实现可能带来兼容性或新缺陷（例如 panic 导致 DoS），重写应尽量做到与旧实现一一对应并补足单元测试。许多评论把焦点放在“替换是否能降低总体风险”与“应否采用增量重写（只重写解析器）或保留成熟 C 代码并加强检测”之间的权衡上。
邮件与后续讨论暴露出目标架构的不一致性：Rust 工具链对部分老旧架构支持薄弱（文中点名 alpha、hppa、m68k、sh4 被例外），Rust 官方也以 Target Tier（Tier 1/3）来标注平台成熟度。移植工作常常不仅是编译器后端的问题，还需处理 libcore 原子操作、libstd 的 thread/fs/net/sync 支持，以及 ABI/对齐差异（例如 m68k 的 LLVM 对齐问题会导致 ABI 不兼容）。可行路径包括推动 LLVM 后端、加速 rustc_codegen_gcc 或 gccrs 的成熟，但这些都需要大量持续维护；因此若要保留小众端口，要么由爱好者/厂商承担移植成本，要么这些端口继续停留在旧版本。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6]
评论反复提到 Cargo 生态的传递依赖爆炸与供应链风险：一个看似小的 Rust 程序可能拉入数百个 crates，给审核与长期维护带来负担。Debian 的打包/重建流程也受此影响——静态链接、庞大依赖树和跨发行版的重建成本会限制安全更新速度（有人引用发行说明指出对静态链接语言的安全支持有限）。此外，语言或编译器的快速演进、工具链差异（rustc/LLVM 与未来的 gcc 后端）会给非滚动发行版带来额外维护复杂度。对策建议包括在发行级别管理依赖、限制上游直接用 Cargo 发布到系统包中，或等待/推动 GCC 后端成熟以减少对单一工具链的依赖。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6]
讨论中对邮件语气与发起者身份反应强烈：很多人觉得措辞过于咄咄逼人，且因为发件人来自商业厂商（被指出与 Ubuntu/Canonical 有关联）因此怀疑决策动机与做法。部分回复把问题扩大为“Rust 社区风格”与“布道式宣传”之争——有人批评极端布道者的态度，有人反指反对者为顽固或杞人忧天。另一条现实线索是开源的“do-ocracy”——实际维护工作量往往决定方向，因此少数活跃维护者的决定会被视为“事实上的推动力”，这也加剧了情绪化回响。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6]
评论提出若干替代或折衷路线：Fil-C（把 C 变成受管理运行时以捕获错误）被看作减低重写成本的选项，但目前仅支持 x86_64、性能/体积开销较大且尚不够成熟。另有技术路径包括完善 rustc 的 GCC 后端（rustc_codegen_gcc）、推动 gccrs 或使用 Cranelift/其他后端来扩大平台覆盖。还有人主张不强行改写全部老工具，而是写新的现代工具以示范优势（例如 ripgrep 的成功），或只重写有明确攻击面且易于测试的子模块以降低风险与运维负担。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6]
多条评论从 Debian 维护与发行运维角度提出实际担忧：APT 等核心组件的维护者人数有限，把新语言作为硬依赖会把额外的打包/安全更新/构建负担推给发行者。历史上也有因新实现导致的意外问题（例如某些 Rust coreutils 的 bug 影响了自动更新），发行版政策（冻结的工具链版本、重建策略）会放大这种影响。讨论建议应明确迁移计划、文档、测试与兼容分支（如 minimal vs full package），并指出若没有厂商或社区承担长期维护，某些小众端口实质上只能维持在老版本上。
Cargo: Rust 的包与构建管理工具，会从 crates.io 拉取第三方库（crates）並处理依赖与构建脚本；传递依赖量大时会带来供应链与审计负担。
rustc: Rust 的官方编译器，通常借助 LLVM 做后端生成本机代码；编译器与其后端的可用性直接影响 Rust 在不同 CPU 架构上的可移植性。
LLVM: 一个开源的编译器基础设施项目（代码生成后端），许多语言（包含 rustc 的主流配置）依赖 LLVM 才能支持多平台与优化。
rustc_codegen_gcc / gccrs: 两个旨在让 Rust 利用 GCC 生态或 GCC 后端生成代码的项目：rustc_codegen_gcc 是为 rustc 提供 GCC 代码生成的后端，gccrs 是 GCC 的 Rust 前端/实现；成熟后可减少对 LLVM 的单一依赖。
Fil‑C: 一个把传统 C 运行时变为“托管/检查型”运行时的实验性项目，通过运行时检查减轻直接重写的压力，但目前只对 x86_64 等有限平台提供支持且有性能/体积代价。
Sequoia‑PGP: 用 Rust 实现的 OpenPGP 库/生态，目标替换或补充传统的 GnuPG（GnuPG 为用 C 编写的广泛使用的 OpenPGP 实现）。
Rust 平台支持 Tier（Target Tier）: Rust 官方用 Tier 分级标注目标三元组的成熟度：Tier 1 表示完全支持并在 CI/平台上稳定，Tier 3 表示实验性或缺乏完整支持；影响某架构能否被官方工具链可靠编译。