开发工具链
This content is not available in your language yet.
「编译环境怎么配」在 EL 系上有个固定答案的框架：系统语言栈走 AppStream，构建依赖走 CRB，版本冲突用容器解决。本页按这个框架组织。
系统语言栈与运行时
Section titled “系统语言栈与运行时”AppStream 提供带完整支持承诺的语言运行时（gcc、Python、Node.js 等）——它们随小版本更新，是生产环境的首选。多版本共存在 EL10 上的答案很朴素：优先用容器隔离各项目环境，而不是在同一系统里堆多套编译器；这是与 EL8 时代组件流（modularity）最大的思路差异，背景见枢纽站的EL10 工具链变化。
devel 目录与 CRB 的位置
Section titled “devel 目录与 CRB 的位置”镜像树的 9/ 与 10/ 下都有 devel/ 目录，对应面向开发者的包集合；运行时则由 CRB（CodeReady Builder）仓库提供编译所需的 -devel 头文件与构建依赖——自建 RPM 时先启用 CRB，dnf builddep 才能装齐依赖。两者关系与启用方式见仓库与 SIG 变体。
构建环境的标准做法
Section titled “构建环境的标准做法”自建包的流水线建议固定三件事：构建在独立于生产的主机或容器里做（别在生产机上装全量构建依赖）；rpmbuild 环境用配置管理固化（见自动化运维）；产物签名与仓库发布走独立通道。需要容器化构建的完整教程见枢纽站的Docker 入门。
大版本升级（见ELevate 升级）对工具链的影响集中在：编译产物在新 glibc/gcc 下需要重编验证；第三方构建依赖若在 EL10 缺位，升级会留下旧包（ELevate 文档明确提示此类包会留在系统上）。升级前先用应用清单对一遍构建依赖。
- 仓库与 SIG 变体 — CRB/plus 的启用
- 容器与镜像 — 容器化工具链
- ELevate 跨大版本原地升级 — 升级前的依赖清点
- 枢纽：EL10 工具链变化、DNF 基础