发布软件包

发布¶

rocky-release 软件包¶

预计特别兴趣小组 (SIG) 在交付软件包时，会有相关的发布软件包，这些软件包提供：

用于 dnf 的仓库文件
与您的软件包签名相关的 GPG 密钥

密钥/软件包限制

SIG 无法提交密钥，也无法访问私钥。SIG 不能提交自己的发布软件包。

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

提交请求时，请点击“新建问题”按钮，然后点击“开始”以获取“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