发布软件包

发布¶

rocky-release 软件包¶

预计提供软件包的特别兴趣小组将拥有相关的发布软件包，这些软件包提供

dnf 的存储库文件
与软件包签名相关的 GPG 密钥

密钥/软件包限制

特别兴趣小组不能提交密钥，也不能访问私钥。SIG 不能提交自己的发布软件包。

在初始请求过程中，构建系统会为您分配一个 GPG 密钥，用于对您的软件包进行签名。必须请求构建发布软件包并将其提交到 extras 存储库。如果在初始请求期间未请求或未满足发布软件包，则可以在 SIG/Core Issues 中打开新的请求。

提交请求时，点击“新建 Issue”按钮，然后点击“开始”以获取“SIG 发布软件包请求”，并填写显示的模板，其中包括

自我介绍和发布软件包请求
存储库数量和名称
注意是否有软件多版本计划
注意是否有模块化存储库
您要定位的主要版本（Rocky Linux 8、9 等）
如有需要，请提供其他详细信息

为您的 SIG 发布软件包¶

待定。目前，发布需要向发布工程 (SIG/Core) 反馈才能推送到镜像。

存储库的目录格式（信息性）¶

这更多的是信息性的，但 SIG 了解其导出的存储库将存储在何处非常重要。

存储库将按如下格式进行格式化

/pub/sig/MAJOR/NAME/ARCH/PKG_OR_REPO

这基本上意味着 sig 目录将与主发行版目录并排存在，可能位于镜像的根目录。在 /pub/rocky 中，您将看到每个受支持的主要版本。在 /pub/sig 中，您也将看到主要版本，但结构不同。让我们分解一下。

NAME 可以是 SIG 的名称或缩写代码（例如，cloud、kernel、mcs）
MAJOR 是要定位的主要版本（8、9 等）
ARCH 用于体系结构
PKG_OR_REPO 可以用于特定软件包集或任何存储库。（例如，您可以在其他目录旁边有一个“common”目录）

假设我们需要一些用于 mcs 的存储库，并且我们为 x86_64 和 aarch64 构建。它可能如下所示。这假设消息传递和通信 SIG 不仅拥有 ejabberd 存储库，而且还拥有一个“common”存储库，该存储库可能与 ejabberd 共享，并且将来可能还会与另一组软件包共享。

.
├── rocky
│   ├── 8
│   └── 9
└── sig
    ├── 8
    │   └── mcs
    │       ├── aarch64
    │       │   ├── ejabberd
    │       │   │   ├── Packages
    │       │   │   └── repodata
    │       │   └── mcs-common
    │       │       ├── Packages
    │       │       └── repodata
    │       └── x86_64
    │           ├── ejabberd
    │           │   ├── Packages
    │           │   └── repodata
    │           └── mcs-common
    │               ├── Packages
    │               └── repodata
    └── 9
        └── mcs
            ├── aarch64
            │   ├── ejabberd
            │   │   ├── Packages
            │   │   └── repodata
            │   └── mcs-common
            │       ├── Packages
            │       └── repodata
            └── x86_64
                ├── ejabberd
                │   ├── Packages
                │   └── repodata
                └── mcs-common
                    ├── Packages
                    └── repodata