背景
为了开发支持 openGauss 企业级部署的 dbops1.3 版，我下载了所有相关软件包。下载后，我发现了四个包，包名是一样的，这让我疑惑是否重复下载了。显然不是，因为这些包的大小各不相同。
实际上，这些包是支持不同操作系统和 CPU 架构的软件包。上图中的包对应下表：
针对 openGauss 6.0.0 版本，完整的软件包列表如下:
openGauss 软件包的命名存在明显问题。官方目前的方法是将相同包名的软件包存放在下载服务器的不同目录中，以避免冲突。但这并非最佳实践。正确的做法应该是为每个软件包采用独特的命名。我发现 openGauss 软件包在以下三个方面存在命名问题：
- 软件包类型区分不清
- 软件包架构区分不明
- 操作系统区分不明确
一、软件包类型的区分不清
企业版 含 -all
关键字
轻量版 含 -Lite
关键字
极简版 既不含 -all
关键字也不含 -Lite
关键字 (另外极简版是 tar.bz2 的压缩格式)
以上规律是可以区分出软件包类型，但不够清晰。例如 all 为什么放在最后，不可以和 Lite 一样统一放在前面么。
鉴于极简版其实就是不提供 CM 和 OM 组件，但 openGauss Server 数据库是提供的，我建议的命名方法是:
- 企业版：openGauss-All-6.0.0-RC1-openEuler-64bit.tar.gz
- 极简版：openGauss-Core-6.0.0-RC1-openEuler-64bit.tar.gz
- 轻量版：openGauss-Lite-6.0.0-RC1-openEuler-64bit.tar.gz
二、软件包架构区分不明
目前，官方的轻量版可以区分软件架构，适用于 aarch64 还是 x86_64。
而企业版和极简版软件架构部分命名都采用 -64bit
，导致无法区分。
所以我对于企业版命名方法建议是:
- 企业版 AArch64 架构：openGauss-All-6.0.0-RC1-openEuler-aarch64.tar.gz
- 企业版 x86_64 架构：openGauss-All-6.0.0-RC1-openEuler-x86_64.tar.gz
三、操作系统区分不明确
所有软件包类型的软件包，均无法区分 openEuler 系列，到底是 openEuler20.03 还是 openEuler22.03
所以，综上，我对于企业版命名方法建议是:
- 企业版 AArch64 架构 openEuler22.03 系统:
openGauss-All-6.0.0-RC1-openEuler22.03-aarch64.tar.gz
- 企业版 x86_64 架构 openEuler20.03 系统:
openGauss-All-6.0.0-RC1-openEuler20.03-x86_64.tar.gz
软件包名对我的影响
我的 dbops1.0 版本开始支持离线部署 openGauss 5.0.0 的企业版单机架构。如果服务器可以连接互联网，由 dbops 支持在线部署，自动下载安装包和部署，一般无问题。但 dbops 也支持离线部署，用户如果自行下载和上传 openGauss 安装包，那就可能出错了。所以我在一年前就给官方提过 issue，希望优化，如下图。
官方回复承认这个是一个问题，但并没有按照我的建议在 6.0.0 版本优化。
openGauss 的发行版有没有这种问题?
我们知道，openGauss 的主旨是共建国产数据库根社区，打造开源数据库的核心竞争力。任何厂商都可以在遵循木兰协议的情况下发行自己的闭源商业产品。中国移动的磐维数据库（PanWeiDB）也是基于 openGauss 的一个发行版。那么，磐维数据库的软件包是否存在命名问题呢？
答案是没有问题。
由于 PanWeiDB 只支持企业版部署，所以只需考虑软件包是否能区分系统架构和操作系统版本。很明显，它可以做到这一点。
PanWeiDB_V2.0-S2.0.2_B01-install-openeuler_22.03-x86_64-no_mot.tar.gzPanWeiDB_V2.0-S2.0.2_B01-install-openeuler_20.03-aarch64_ft-no_mot.tar.gz
这两个示例清晰地表明了系统架构和操作系统版本，从而避免了命名混乱的问题。
MySQL 有没有这种问题？
MySQL 的软件包命名不存在上述问题，必须的。以下是 MySQL RPM 包的一个命名组织形式：
mysql----...rpm
一个实际例子是：
mysql-community-server-8.4.0-1.el9.x86_64.rpm
包名的每个组成部分都有多个可选项，例如（只列出部分选项）：
-
edition
- Community
- Enterprise
-
component
- server
- client
- libs
-
version
- 8.0.37
- 8.4.0
-
release
- 1
- 2
-
distribution
- el7
- el8
- el9
-
architecture
- x86_64
- aarch64
这种命名方式结构清晰，能够准确区分不同版本、组件、操作系统发行版和架构，避免了命名混乱的问题。
而 MySQL 的通用二进制包（Generic Binary Tarball）更方便，它只区分 glibc 版本，不区分操作系统版本。使用最低 glibc 版本的二进制包，就可以适配所有操作系统的部署。这也解释了为什么 dbops 部署 MySQL 时仅支持通用二进制包。
dbops1.3 的优化
如果采用离线部署(fcs_auto_download_opengauss: 0
)，dbops1.3 将会通过 pre_task 步骤检查你下载的软件包，是否和你的操作系统和架构匹配，保证你使用正确的安装包来部署 openGauss。采用的方法是，通过内置维护一份官方软件包 checksum 列表来实现。
效果如下：
简单地说，从 dbops1.3 起，如果你离线安装 openGauss，并且下载了错误的包，问题会在安装开始时被发现，而不是在安装到一半时才发现。对于安装包损坏的情况也是如此，一开始就能检测到。
