企业级易用标杆实锤！openEuler DNF 包管理 + Oepkgs 仓库 部署效率全流程实测

鸽芷咕
65 阅读12分钟

前言

在企业级服务器部署时，运维团队常遇到 “找软件包费劲、软件之间互相冲突难解决、操作步骤还麻烦” 的问题。openEuler 专门针对这些痛点，选了 DNF（Dandified YUM）作为默认的软件管理工具，再加上 Oepkgs 社区仓库，组成 “工具 + 资源” 的一站式解决方案。它靠智能依赖处理技术（libsolv 引擎）自动解决冲突、Oepkgs 仓库里 2 万多个适配 的软件包补全资源，，真正做到 “拿来就能用”，大幅降低企业部署难度，还能保证批量部署和日常维护时的稳定与好用。下面我们就一起来体验一下openEuler DNF 包管理 + Oepkgs 仓库 。

@TOC

一、openEuler的介绍

openEuler 是面向数字基础设施的开源操作系统，由开放原子开源基金会孵化及运营，旨在通过开源开放的形式汇聚全球技术力量，构建稳定、安全、高性能的基础软件生态。该系统不仅 100% 覆盖 ARM、x86、RISC-V、SW-64、LoongArch 等主流计算架构，还兼容 NPU、GPU、DPU 等异构算力设备，适配 100+ 整机与 300+ 板卡，广泛应用于金融、运营商、能源、云计算等关键行业。目前已拥有 552 万 + 社区用户、25 家商用 OSV 合作伙伴，形成了从技术研发到商业落地的完整生态闭环。

二、DNF 包管理工具——企业级易用的 “核心引擎”

2.1 DNF包管理工具的背景

在众多操作系统发行版中，包管理工具种类繁多，各有千秋。Debian系有APT，RedHat系有YUM，而openEuler基于RPM包管理，但它在此基础上进行了深入优化，并创新性地加入了<font style="color:rgb(222,120,2);">DNF</font>（Dandified Yum）作为新一代工具。DNF致力于改善 YUM 的瓶颈，即性能、内存占用、依赖解决、速度和许多其他方面。DNF使用RPM、libsolv和hawkey库进行包管理。

2. 3 DNF 入选 openEuler 的核心优势

  • 依赖处理更高效：基于 libsolv 解决器，冲突检测速度提升 30%，自动规避依赖循环问题。
  • 资源占用优化：对比 YUM，内存消耗降低 40%，批量操作时卡顿现象显著减少。
  • 扩展能力灵活：支持插件机制，可通过自定义插件适配企业内网部署、权限管控等场景。

2.4 DNF 与 YUM 的比较

DNF 和 YUM 两种 Linux 包管理工具的核心差异主要在于，DNF 作为 YUM 的改进版，采用高性能 libsolv 库解决依赖，内存消耗更低，接口文档完备且支持多种扩展，开发新功能更便捷，适用于 Fedora、RHEL 8 及以上等较新系统，在软件包更新依赖检查、软件库无响应处理、命令功能一致性、内核删除权限及 AppStream module 支持等方面更具优势；而 YUM 基于公共 API，内存消耗大，仅支持 Python 扩展，开发难度较高，主要应用于 RHEL 6/7 等旧版本系统，在依赖检查、功能灵活性等方面相对不足。

DNF (Dandified YUM)YUM (Yellowdog Updater, Modified)
DNF依赖解决方案采用由 SUSE 开发的高性能 libsolv 库YUM依赖解决方案为公共 API
API 接口文档完备API 接口文档较完备
由 C/C++ 和 Python 编写由 Python 编写
DNF 目前应用在 Fedora、RHEL 8、CentOS 8、OEL 8和 Mageia 6/7YUM 目前应用在 RHEL 6/7、CentOS 6/7 和 OEL 6/7
DNF 支持各类扩展YUM 支持 Python 扩展
接口文档完备，开发新功能容易接口文档不完备，开发新功能困难
同步软件库元数据时内存消耗低同步软件库元数据消耗大量内存
如果软件包更新过程中存在不相关的依赖包，则软件包不更新软件包更新时不进行依赖包相关性检查
如果允许的软件库没响应，则 DNF 会忽略并继续使用可用软件库如果允许软件库没响应，则 YUM 程序会立即中止
DNF 中 update 和 upgrade 相同YUM 中 update 和 upgrade 不同
程序包的依赖包是不会更新的YUM 提供选项来设置这种行为
DNF 允许删除所有内核文件，包括正在使用的内核YUM 禁止删除正在使用的内核
如果软件包更新过程中存在不相关的依赖包，则软件包不更新软件包更新时不进行依赖包相关性检查
支持 AppStream module不支持 AppStream module

三、DNF 的基础使用

DNF 绝非仅能完成软件包安装的基础工具，更是 openEuler 生态中功能全面、灵活高效且兼具深度与实用性的 “瑞士军刀”。它深度适配 openEuler 系统架构，在继承 RPM 包管理核心优势的同时，通过 libsolv 等高性能库的加持，攻克了传统包管理工具在依赖解析、内存占用、运行速度上的诸多瓶颈。无论是日常的软件安装、更新与卸载，还是系统依赖修复、软件源配置、包组管理，亦或是离线包处理、版本回滚等复杂场景，DNF 都能提供简洁直观且稳定可靠的解决方案。下面我们就来实操一下

3.1 DNF 版本信息查询

DNF --version

3.2 查看DNF命令的帮助信息

查看DNF在openEuler中的help帮助信息

DNF --help

3.3 DNF 核心命令选项的技术解析

  1. **install <软件包名>**：安装一个或多个指定软件包，自动解析并安装依赖项（例：DNF install nginx）。
  2. **remove <软件包名>**：卸载一个或多个指定软件包，可选择保留配置文件（例：DNF remove nginx）。
  3. **update <软件包名>**：更新指定的已安装软件包，若不指定包名则更新所有可更新软件包（与 upgrade 在 DNF 中功能趋同，兼容 YUM 习惯）。
  4. **upgrade**：更新系统中所有已安装软件包及关联依赖项，优先保持系统版本一致性（DNF 中推荐用于全系统更新）。
  5. **info <软件包名>**：查询软件包的详细信息，包括版本、发布日期、大小、依赖关系、功能描述等（例：DNF info firefox）。
  6. **search <关键词>**：根据关键词搜索软件包名称或描述，支持模糊匹配（例：DNF search web server）。
  7. **list**：列出系统中所有已安装的软件包；搭配参数可扩展功能（如 DNF list available 列出可安装包、DNF list updates 列出可更新包）。
  8. **clean <缓存类型>**：清除系统中的软件包缓存，可选参数包括 all（全部缓存）、packages（包文件）、metadata（元数据）等（例：DNF clean all）。
  9. **check-update**：检查系统中所有已安装软件包的可用更新，仅返回结果不执行实际更新操作。
  10. **repository <操作>**：管理 YUM/DNF 软件仓库，支持 enable（启用）、disable（禁用）、list（列出）等操作（例：DNF repository enable epel）。
  11. **module <操作>**：管理 AppStream 模块（如版本切换、启用/禁用、安装），适用于支持模块的发行版（例：DNF module install nodejs:18）。
  12. **group <操作>**：管理预定义的软件包组（如“开发工具”“图形桌面”），支持 install（安装）、list（列出）、remove（卸载）等（例：DNF group install "Development Tools"）。
  13. **config-manager <操作>**：管理 DNF 配置文件和软件库，可添加第三方仓库、修改配置参数（例：DNF config-manager --add-repo ``https://example.com/repo.repo）。
  14. **version**：查看 DNF 工具的当前版本信息，包括依赖库版本（例：DNF version）。

四、DNF命令的使用实操

4.1 查询系统的rpm包

查询已经安装的rpm包

DNF list installed

4.2 更换软件源配置

这里我们以openEuler 24.03-LTS 为例来给大家演示一下如何切换官方源配置

  • 1.先对原有源配置进行备份
mkdir -p /etc/yum.repos.d/backup
mv /etc/yum.repos.d/*.repo /etc/yum.repos.d/backup/

  1. 查看当前系统架构，避免多架构环境可能出现的包安装错误，为后续操作可安全执行
arch
  1. 之后我们即可着手修改并配置适配 openEuler-24.09（x86_64 架构）的 repo 配置文件
cat > /etc/yum.repos.d/openEuler-24.09.repo << 'EOF'
[openEuler-24.09-OS]
name=openEuler-24.09 Official OS Repository
baseurl=https://dl-cdn.openeuler.openatom.cn/openEuler-24.09/OS/$basearch/
enabled=1
gpgcheck=1
gpgkey=https://dl-cdn.openeuler.openatom.cn/openEuler-24.09/OS/$basearch/RPM-GPG-KEY-openEuler
repo_gpgcheck=0
metadata_expire=86400
enabled_metadata=1
EOF

在这里我们可以看到，提示信息 “0 files removed” 表明此前的无效缓存已被彻底清理；而 “Metadata cache created” 则说明软件源连接正常，且元数据缓存已成功生成。同时，openEuler-24.09 Official OS Repository 也正常拉取了元数据（速度达 11 MB/s，下载量为 2.9 MB）。

4.3 openEuler中的创新扩展

首先，针对软件源管理，openEuler 社区整合了多样化的官方及第三方镜像资源，发者可通过 DNF 轻松切换至最优镜像源。其次，面对多架构兼容的需求，DNF 在 openEuler 中天然支持 x86、ARM、RISC-V 等主流架构，开发者无需切换工具链，简化了跨平台开发与部署流程。此外，openEuler 还为 DNF 拓展了丰富的插件生态，通过插件机制可灵活扩展功能边界，覆盖从特定场景的依赖管理到系统优化等多样化需求，让这一工具既能满足基础操作，又能适配复杂的定制化场景，充分体现了 openEuler 在包管理领域的创新实践。

  1. 软件源优化
sudo DNF config-manager --add-repo=https://repo.openeuler.org/20.03-LTS-SP3/everything/x86_64/
sudo DNF makecache

  1. DNF 组包管理：高效搭建开发环境

DNF 的组包管理功能可将场景所需的工具链打包为整体，实现 “一键部署”。例如，通过 “Development Tools” 组快速搭建编译环境：

  • 查看开发工具组包含的核心软件（如编译器、调试器等）
DNF group info "Development Tools"

  • 安装整个开发工具组（约包含20+常用工具）
sudo DNF group install "Development Tools" -y

  • 安装完成后，可直接使用gcc、make等工具
gcc --version
make --version

五、Oepkgs 仓库 —— 企业级部署的 “资源宝库”

如果说 DNF 是“智能管家”，Oepkgs 仓库就是“管家背后的超大仓库”——专门存放适配 openEuler x86_64 架构的补充软件包，解决“官方源没有、自己找又麻烦”的痛点。目前oepkgs 镜像源中已有2w+款软件包，用户可以在 search.oepkgs.net/search/ 上进行查询并下载使用。

5.1 Oepkgs 仓库核心优势

优势维度具体说明
资源规模收录 2w+ 架构软件包，涵盖开发工具、中间件、小众工具等
补充价值填补官方源空白，提供长尾软件、定制化组件，满足企业特殊需求
兼容性保障所有 包均经社区测试，确保适配 openEuler 系统，无“装得上用不了”问题
查询便捷性官网支持“x86_64 架构+系统版本”多维度筛选，快速定位目标包

5.2 Oepkgs 仓库结构与管理逻辑

  • 双仓库协同：
    • src-oepkgs：存放 x86_64 软件包源码（“原材料仓库”）；
    • oepkgs-management：负责仓库配置与管理（“管理后台”）；
    • 流程：开发者提交 x86_64 源码 → 系统自动构建 → 发布到 Oepkgs 仓库供下载。
  • 与官方源分工：
    • 官方源（src-openEuler）：核心系统组件（如内核、基础工具）；
    • Oepkgs 源：补充包+社区贡献包，两者互补，覆盖全场景需求。
  • 分组维护：按 sig 组（专业小组）分类，如 sig-cloud 维护云相关 x86_64 包，更新及时、问题修复快。

5.3 Oepkgs 仓库快速上手

  1. 添加 Oepkgs 仓库源
DNF config-manager --add-repo https://repo.oepkgs.net/openEuler/rpm/

  1. 刷新缓存并安装软件
DNF clean all && DNF makecache

  1. 查看所有仓库名称，看看 Oepkgs 对应的仓库是否添加成功
DNF repolist all

六、DNF+Oepkgs 生态价值

6.1 生态协同核心价值

DNF 与 Oepkgs 仓库的协同，不仅是“工具+资源”的简单组合，更是 openEuler 面向企业场景的生态闭环：

  • 降低部署门槛：无需手动编译源码、解决依赖冲突，一键完成软件安装，新手运维也能快速上手；
  • 提升运维效率：批量操作不卡顿、缓存优化提速、自动更新插件适配，减少重复劳动；
  • 保障资源覆盖：官方源+Oepkgs 源互补，核心包、补充包、小众包全满足，无需跨平台找资源；
  • 强化稳定性：所有 x86_64 包均经过兼容性测试，与 openEuler 系统深度适配，降低生产环境故障风险。

6.2 企业场景应用建议

生产环境
  • 配置策略：“官方源为主，Oepkgs 源为辅”；
  • 核心逻辑：系统内核、数据库、核心中间件等关键组件使用官方包（保障稳定性）；小众工具、定制化组件使用 Oepkgs 包（满足特殊需求）；
  • 额外优化：启用 DNF-automatic 插件，仅更新安全补丁，避免功能更新引发故障。
测试环境
  • 配置策略：优先启用 Oepkgs 源；
  • 核心逻辑：提前体验最新版本的软件包，测试兼容性与新功能，为生产环境升级做铺垫；
  • 额外优化：开启缓存保留（keepcache=1），重复测试时无需重复下载，提升效率。

七、总结

DNF与Oepkgs的组合，为openEuler生态打造了“易用、高效、全量、稳定”的企业级部署解决方案。从基础包安装、源配置到复杂的离线部署、批量运维，二者协同突破传统Linux系统部署痛点，让企业用户无需在“找包、解依赖、调配置”上耗费精力，可专注核心业务创新。无论新手运维快速上手，还是资深团队提升效率，这套方案都能适配企业不同阶段需求，成为openEuler生态中企业级部署的“标杆组合”。随着生态持续完善，其不仅在x86_64架构场景竞争力强化，更在ARM、RISC-V等多架构中稳步拓展，全方位凸显openEuler生态“多元架构融合、全场景适配”的多样性优势，为企业数字化转型提供坚实且多元的支撑。

如果您正在寻找面向未来的开源操作系统，不妨看看DistroWatch 榜单中快速上升的 openEuler:distrowatch.com/table-mobil…，一个由开放原子开源基金会孵化、支持“超节点”场景的Linux 发行版。

openEuler官网：www.openeuler.openatom.cn/zh/

avatar
文章
阅读
粉丝