diff --git a/articles/304-package-introduction-and-management-principles.md b/articles/304-package-introduction-and-management-principles.md
index 9d9ba3cfa11877f126bbb5af5d03cfd19f0a5961..22d841eb7bc1bdabf9935ad87f34ff5533d87b38 100644
--- a/articles/304-package-introduction-and-management-principles.md
+++ b/articles/304-package-introduction-and-management-principles.md
@@ -91,7 +91,7 @@ must | 软件包 owner 需要评估软件的运行平台，缺省默认全部支
| --- | --- | --- | --- |
| layer-0 | 内核层 | 操作系统服务（内核） |
1. 跟随上游内核社区，选取社区成熟期 LTS 版本；
2. 选型需兼顾龙蜥社区 IHV 生态支持最完整的内核版本，降低硬件补丁回合成本；
3. 选型需兼顾龙蜥理事成员单位向上游贡献重大特性较多的内核版本，降低特性回合成本；
4. 在一个 OS 版本内不发生大版本变更，仅采取 release 更新形式，以补丁形式合入。
|
| layer-1 | 核心层 | 核心工具、核心库、核心服务 |
1. 跟随上游社区，选取社区稳定版本或 LTS 版本；
2. 和硬件相关的组件选型时需兼顾龙蜥社区 IHV 生态支持最完整的版本，降低硬件补丁回合成本；
3. 在一个 OS 版本内主要版本不发生大版本变更，仅采取 release 更新形式，以补丁形式合入；
4. 原则上不允许同时引入多个版本（例如 libssh, libssh2 需要选择一个版本）。
|
-| layer-2 | 系统层 | 系统工具、系统库、系统服务 | |
+| layer-2 | 系统层 | 系统工具、系统库、系统服务 |
1. 跟随上游社区，选取社区稳定版本或 LTS 版本；
2. 和硬件相关的组件选型时需兼顾龙蜥社区 IHV 生态支持最完整的版本，降低硬件补丁回合成本；
3. 在一个 OS 版本内主要版本不发生大版本变更，仅采取 release 更新形式，以补丁形式合入；
4. 原则上不允许同时引入多个版本（例如 libssh, libssh2 需要选择一个版本）。
|
| layer-3 | 应用层 | 应用工具、应用库、应用服务 |
1. 尽量选取正式发布的最新版本；
2. 允许在一个 OS 版本内发生 version 变更，但要对影响范围整体评估清楚，必须通过**兼容性验证**；
3. 原则上不允许同时引入多个版本。
4. 自研 module 包可以采用 module 模式进行管理，保障单一大版本演进过程的应用软件兼容性 |
| layer-4 | 应用场景 | 数据库、云原生、大数据、桌面等应用场景 |
1. 优先选择最新的，其次如果最新的版本带来不兼容（对其他软件产生影响）的问题，则可以选取次新版本；
2. 允许支持某款软件存在多个版本，但需要由需求驱动，比如：tomcat 7、tomcat 8、tomcat 9等。
3. 具体业务涉及的软件版本可以由对应负责人决策，不做过多要求。
|
diff --git a/articles/305-module-and-checklist-of-spec.md b/articles/305-module-and-checklist-of-spec.md
index f7edd51fee741596b7a9b391ddb4d3cb9381e386..eadfe9fc71ac7b347fa2b008ea0d417966fd5cf6 100644
--- a/articles/305-module-and-checklist-of-spec.md
+++ b/articles/305-module-and-checklist-of-spec.md
@@ -89,7 +89,6 @@ The %{name}-doc package contains documentation files for %{name}.
mkdir -p %{buildroot}/%{prefix}/%{name}
install -m 0644 -p %{SOURCE1} %{buildroot}/%{prefix}/%{name}
-
%check
%make test
@@ -189,6 +188,58 @@ rm -rf %{pypi_name}.egg-info
* Mon Jul 25 2022 happy_orange - 0.1.0-1
- Init pacakge from upstream
```
+
+### 2.3 rpm 增加 abi 和 api 信息
+
+在 anolis 23 版本中额外支持在 rpm 中分别对 so 文件和 bin 文件增加 abi 和 api 信息，下面描述如何进行使用。
+
+- 使用规则：
+ - 在 %install 阶段使用 `%generate_compatibility_deps` 生成 abi/api 文件
+ - abi/api 文件默认都存在放在 `%{abidir}` 中
+ - abi 文件需要和 so 文件一起打包
+ - api 文件需要和 bin 文件一起打包
+ - 需要通过`%dir %{abidir}`的方式增加路径定义，否则会造成卸载残留
+ - 需要根据文件列表和依赖关系共同决定`%dir %{abidir}` 的定义位置，放置在依赖树中最底层的包内，常见情况如下：
+ - 如果只有单个 rpm ，则将路径定义增加到此 rpm 中；
+ - 如果有多个 rpm，但是 abi/api 文件仅存在一个 rpm 内，则将路径定义增加到此 rpm 内；
+ - 如果多个子包中都包含 abi/api 文件，并且这些子包之间是独立的，没有依赖关系，如果有主包，且都依赖主包，则将路径定义增加到主包内；
+ - 如果多个子包中都包含 abi/api 文件，并且这些子包之间是独立的，没有依赖关系，如果没有主包，则新定一个主包，并将路径定义增加到主包内；
+ - 如果多个子包中都包含 abi/api 文件，并且这些子包不是独立的，则需要找出这条依赖线中最底层的 rpm，比如 common 或者 libs，然后将路径定义增加到这个底层 rpm 中；
+- 使用样例
+ - 在 `%install` 阶段生成 abi/api 文件，注意需要将脚本调用放在最后
+ ```
+ %install
+ %make_install docdir=%{_pkgdocdir}
+ # remove unpackaged files from the buildroot
+ rm -f $RPM_BUILD_ROOT%{_libdir}/*.la
+ %generate_compatibility_deps
+ ```
+ - 打包 abi/api 文件
+ ```
+ %files
+ %dir %{abidir}
+ %{_libdir}/libasound.so.*
+ %{abidir}/libasound.so.dump
+ %{_bindir}/aserver
+ %{abidir}/aserver-option.list
+ ```
+ - 验证 abi/api 的有效性
+ ```
+ # rpm -qpl alsa-lib-1.2.7.2-2.an23.x86_64.rpm | grep dump
+ /usr/lib/compatibility/alsa-lib/libasound.so.dump
+ /usr/lib/compatibility/alsa-lib/aserver-option.list
+ ```
+ - 验证 abi/api 的 provides
+ ```
+ # rpm -qp alsa-lib-1.2.7.2-2.an23.x86_64.rpm --provides | grep abi
+ abi(alsa-lib) = 1.2.7.2
+
+ # rpm -qp alsa-lib-1.2.7.2-2.an23.x86_64.rpm --provides | grep api
+ api(alsa-lib) = 1.2.7.2
+ ```
+
+
+
## 3 字段介绍和标准
| **spec header** | 增加 anolis_release 的定义，从 1 开始递增 | |
@@ -205,6 +256,7 @@ rm -rf %{pypi_name}.egg-info
| Patch0 | 对源码进行的修改以补丁的形式。
1. 可以添加更多 PatchX 指令，每次递增编号，例如：Patch1、Patch2、Patch3 等。
2. 自研补丁序号从100、1000、10000等编号开始。 |可选|
| BuildArch | 声明该软件的构建体系结构。
1. koji 构建时默认为：x86_64 和 aarch64
2. 本地构建时会自动继承构建它的机器的体系结构
3. 如果不依赖体系结构，可以声明：BuildArch: noarch
4. 如果仅涉及一个架构，则需要将对应的架构声明：BuildArch：x86_64 或 BuildArch：aarch64 |可选|
| ExcludeArch | 声明该软件不需要的架构体系。
1. 默认不需要
2. 指定不进行编译的架构，举例：ExcludeArch: x86_64 | 可选 |
+| ExclusiveArch | 声明该软件需要的架构体系。
1. 默认不需要
2. 指定进行编译的架构，举例：ExclusiveArch: x86_64 | 可选 |
| BuildRequires | 声明该软件构建所需要的全部软件包列表。
1. 有多个条目 BuildRequires每个条目在 SPEC 文件中各占一行
2. 每个条目内不同软件使用空格隔开
3. 直接声明依赖软件的 package name，不要包含： %{_isa}、/usr/bin/xx、pkg-config(xx)、/usr/lib64/xx.so 等 |必选|
| **spec body** | |
| **字段** | **定义** | **是否可选** |