开源之夏，是由中国科学院软件研究所发起的"开源软件供应链点亮计划"下的一项重要活动，这是一场专为高校学生精心打造的技术盛宴。openGauss 社区在本次开源之夏发布的项目共吸引 22 位同学提交申请书申报，在经历了 4 个月的项目开发期，最终 14 位同学成功完成项目并顺利结项！
邀请了来自中国科学院信息工程研究所的博士生李京召，凭借其对系统集成与开源生态建设的深入理解，选择了《SUSE 操作系统集成 openGauss 6.0.0 LTS》项目，并成功完成了从编译适配、多架构支持到社区集成的全链路工作。本文将系统分享他的实现路径、关键技术挑战与开源实践心得。
一、SUSE 操作系统集成 openGauss 6.0.0 LTS 项目介绍
项目简介：本项目致力于将 openGauss 6.0.0 LTS 深度融入 SUSE 系操作系统生态，系统解决其在 openSUSE Leap 15.6、Tumbleweed 以及 SUSE Linux Enterprise Server 15 SP7 等多个发行版上的编译打包、多架构支持与系统兼容性等核心问题。最终实现用户通过 zypper install opengauss 命令一键安装，并全面覆盖 x86_64、aarch64、ppc64le、s390x 四种硬件架构，显著降低 SUSE 用户的部署门槛，提升 openGauss 在企业级 Linux 环境中的可用性。
项目源码/文档链接：
openGauss 社区托管地址：https://gitcode.com/opengauss/examples/tree/master/openSUSE_RPM_package
openSUSE Build Service 托管地址：https://build.opensuse.org/package/show/server:database/opengauss
openSUSE 官方下载页面：https://software.opensuse.org/download.html?project=server%3Adatabase&package=opengauss
server:database 申请请求链接：https://build.opensuse.org/requests/1305598
二、实现路径：从打包到上线的技术全景
1. 技术选型与架构设计：
a. 选择的技术/工具/框架：
Shell 脚本、RPM 打包技术（SPEC 文件编写）、CMake 构建工具、rpmlint 规范检查工具、GCC 编译器、patch 补丁工具、openSUSE Build Service（OBS）平台；核心依赖库编译涉及 krb5、zlib、xgboost、Huawei Secure C、DCF、aws-sdk-cpp 等。
b. 项目的整体架构：
项目分为三个核心阶段，整体流程如下：
RPM 打包脚本编写：基于 openEuler 原版 openGauss 打包脚本，适配 openSUSE 的 rpmlint 规范和编译环境；
多环境验证：搭建多版本 SUSE 虚拟机，完成在线/离线安装测试、功能验证及 benchmarksql 压力测试；
社区提交与适配：将构建仓库提交至 OBS 平台，根据审核意见修复问题，最终接入 openSUSE 官方 server:database 组件库。
c. 选型原因：
RPM 是 SUSE 系系统标准打包格式，适配 zypper 包管理器的安装逻辑，能实现用户一键安装；
CMake 是 openGauss 原生构建工具，复用其编译体系可降低改造成本；
OBS 是 openSUSE 官方构建平台，可自动化验证多发行版、多架构兼容性，确保包的规范性和可复现性；
相比手动编译部署，RPM 打包+OBS 托管的方案更符合开源社区维护规范，能覆盖更多开发场景。
2. 核心实现步骤详解：
a. 关键模块/步骤拆解：
模块 1：RPM SPEC 文件规范适配。参考 openEuler 脚本，按 openSUSE 规范修改 SPEC 文件（如 BuildRequires/Requires 单行排列、削减不必要依赖、使用内置 cmake 宏），编写 rpmlint 过滤规则解决非标准 UID/GID、动态库调用等告警；
模块 2：外部依赖库编译适配。针对 SUSE 源缺失的依赖库（如定制版 Kerberos 5、DCF、华为 SecureC 库），编写适配脚本对依赖库进行编译；
模块 3：openGauss 源码编译修复。修复 CMake 头文件冲突、调整 dolphin 组件编译流程、适配 ppc64le/s390x 架构可能存在的指令集和字节序问题；
模块 4：安装钩子脚本编写。实现%pre（用户创建、端口检查）、%post（数据库初始化、服务注册）、%preun/%postun（服务停止、文件清理）等全流程钩子逻辑；
模块 5：测试与社区提交。完成多架构编译运行与压力测试后，将仓库提交至 OBS，根据审核意见迭代优化，最终通过 server:database 组审核。
b. 关键技术代码示例：
示例 1：Kerberos 5 编译适配（解决高版本 GCC 编译报错）
pushd %{krb5_name}-%{krb5_name}-%{krb5_version}
krb5_dir=${dependency_loc}/kerberos/comm
autoheader; chmod +x configure
cd src
rm -rf configure; cp %{SOURCE20} ./configure
# 添加-std=gnu11适配高版本GCC，指定安装路径并关闭不必要功能
./configure CFLAGS='-std=gnu11' --prefix=${krb5_dir} --disable-rpath --disable-pkinit --with-system-verto=no
make %{?_smp_mflags}
make install %{?_smp_mflags}
# 清理无用文件，减少包体积
rm -rf lib/pkgconfig share var
cd ${krb5_dir}
popd
解析：通过添加-std=gnu11 编译选项适配高版本 GCC 语法规范，指定 prefix 确保依赖库安装路径符合 openGauss 编译要求，同时清理无用文件降低包体积。
示例 2：s390x 大端序适配（解决 LWLock 锁卡死问题）
// src/gausskernel/storage/lmgr/lwlock.cpp
static bool LWLockAttemptLock(LWLock *lock, LWLockMode mode)
……
} while (!pg_atomic_compare_exchange_u8(
#ifndef WORDS_BIGENDIAN
(((volatile uint8*)&lock->state) + maskId), ((uint8*)&old_state) + maskId,
#else
(((volatile uint8*)&lock->state) + sizeof(lock->state) - maskId - 1), ((uint8*)&old_state) + sizeof(lock->state) - maskId - 1,
#endif
(desired_state >> (8 * maskId))));
// src/gausskernel/storage/buffer/bufmgr.cpp
Buffer ReadBuffer_common(SMgrRelation smgr, ……)
……
pg_atomic_write_u32(
#ifndef WORDS_BIGENDIAN
((volatile uint32 *)&bufHdr->state) + 1,
#else
((volatile uint32 *)&bufHdr->state),
#endif
buf_state >> 32);
解析：s390x 为大端序架构，原有代码按小端序计算内存地址导致锁操作读写错误；通过条件编译区分大小端序，调整大端内存序下内存地址计算逻辑，解决程序运行卡死问题。
三、攻坚时刻：当技术遇上规范与架构差异
1、主要技术挑战
多机构兼容性问题：openGauss 在 s390x/ppc64le 架构的兼容性问题：s390x 大端序导致锁操作卡死，ppc64le 存在 SSE4.2 指令集依赖编译报错；
openSUSE 打包规范严格：rpmlint 检查抛出大量告警，且与 openEuler 打包规范差异大，原版脚本无法复用；
SUSE 源缺失核心依赖库：华为 SecureC、DCF 等依赖库在 SUSE 源中无适配版本，且高版本 GCC 与依赖编译选项不兼容。
2、问题定位与解决路径
挑战 1（多架构兼容性）：
排查过程：在 s390x 虚拟机中通过 gdb 调试与人工代码分析定位到 LWLock 锁内存读写错误，分析确认是大小端内存序导致；ppc64le 编译报错时，通过编译日志定位 SSE4.2 指令集依赖问题；
解决方案：为 s390x 添加-DWORDS_BIGENDIAN=ON 编译选项，在代码中使用条件编译调整内存地址计算逻辑；为 ppc64le 移除 SSE4.2 相关源码文件。该方案仅做最小化修改，不影响内核核心功能。
挑战 2（打包规范适配）：
排查过程：运行 rpmlint 梳理所有告警类型，区分"必须修复"和"可过滤"项，参考 openSUSE 官方打包文档和审核意见；
解决方案：按规范修改 SPEC 文件，编写 rpmlint 过滤规则集过滤合理告警，优化文件权限、删除无用静态库，既满足社区规范又保留 openGauss 运行特性。
挑战 3（缺失依赖编译）：
排查过程：逐个分析依赖库编译报错原因，对比 openEuler 编译脚本与 SUSE 环境差异；
解决方案：为每个缺失依赖编写适配脚本，针对性添加编译选项（如 Kerberos 5 加-std=gnu11、Huawei Secure C 加-Wl,-soname），为 DCF 打补丁解决编译错误，保证依赖功能与 openGauss 原生要求一致。
四、开发者说：李京召的开源心路
是什么机缘让你在开源之夏的诸多项目中选择了 openGauss？在选择项目任务和撰写申请书的时候有哪些考虑和准备？
李京召：openGauss 是企业级开源数据库，SUSE 又是主流的企业 Linux 发行版，两者的集成有很强的实用价值。我在申请前深入研究了 openGauss 的编译体系和 openEuler 的打包脚本，也提前调研了 SUSE 的 RPM 规范与 OBS 平台，在方案中明确了可能遇到的技术难点与解决路径。
此次开发工作与你以前的项目开发经历有何异同？
李京召：以前的项目大多围绕单一环境或架构，这次要同时适配多个发行版和四种硬件架构，还要兼顾社区规范，对跨环境调试和协作能力的要求更高。不过解决问题的思路是相通的：拆解问题、逐步验证、持续迭代。
通过这个项目任务，你对开源有了什么更深刻的理解吗?
李京召：开源不仅是代码公开，更是一个需要遵循规范、融入生态的协作过程。这次项目不仅要技术上行得通，还要符合 openSUSE 的打包规范、通过社区审核，才能真正被用户使用。社区的反馈也让方案变得更扎实。
对于学生参与开源项目，你有什么建议？
李京召：不要怕跨生态、跨架构的挑战，这些正是快速成长的机会。一定要重视文档和规范，多和社区沟通，细节决定代码能否被接纳。保持耐心，调试和迭代是开源项目落地的常态。
从代码适配到社区融合，从单一架构到多端支持，李京召同学的项目不仅攻克了诸多技术难点，更完成了一次深入的开源协作实践。通过将 openGauss 成功植入 SUSE 生态，他为更多用户提供了开箱即用的数据库选择，也体现了开源世界中"共建共享"的核心精神。每一次规范的遵循、每一个补丁的提交、每一轮社区的反馈，都在推动着开源生态向前一步。期待更多开发者像他一样，勇于踏入跨生态适配的"深水区"，在解决真实问题的过程中，与开源共同成长。
