内容管理

本节介绍如何在 git 和社区构建系统中管理内容。

导入到 RESF Git 服务

所有特别兴趣小组 (SIG) 在 RESF Git 服务中都会创建一个组织。每个组织都会有一个 meta 仓库，用于跟踪整个 SIG 的问题或请求。这不是强制要求，每个 SIG 可以自行决定如何处理问题或请求。

所有特别兴趣小组还会获得一个 wiki 仓库，用于管理其 sig-X.rocky.page 网站的文档和内容。

对于应该存在哪些仓库和不应该存在哪些仓库，没有严格的要求。这取决于 SIG 的决定。

导入到 Rocky Linux GitLab

构建和发布软件包的特别兴趣小组将在 SIG 下拥有一个子组。该子组将包含额外的子组：src、rpms、modules。

其他子组

虽然这是默认布局，但可以在 SIG 组的根目录下创建其他子组。预计有些 SIG 可能没有计划构建软件包，因为它们可能具有完全不同的重点。

示例和灵感

如果您对设计导入和软件包感到困惑，可以查看其他 SIG 甚至 staging 组中的 Rocky Linux 本身。

src

此区域通常用于 rpm 源代码（spec 文件、元数据文件等），即将支持 dist-git/src-git。虽然此区域是可选的，但您很可能使用它来管理 rpm 源代码，并将 tarball 源代码上传到 lookaside。

对于 rpm 源代码（这是最标准的用法），导入将从这里开始。发生导入时，这些内容将出现在 rpms 中，前提是 peridot 目录配置已更新。注意：下面 rpms 部分的所有规则都适用。

rpm 规则

重申：下面 rpms 部分的所有规则都适用。请务必仔细阅读。

RPM 格式规则

预计在大多数情况下，您将设计要导入到这里的仓库。由于这很常见，因此这是预期的格式

预期的格式是

• SOURCES/... -- 可以在此处放置轻量级文本文件、脚本、补丁等（例如，不在 tar 包中的文件）
• SPECS/name.spec -- 您的 spec 文件在此处，请注意应该只有一个 spec 文件
• .name.metadata -- 必需，列出您在 lookaside 中的源代码档案或其他内容。如果没有要从 lookaside 拉取的源代码，则为空。

元数据文件的格式预计为

SHA256SUM_STRING SOURCES/some_name

左侧列通常是归档的哈希和。这是 lookaside 中文件的名称。右侧是归档将复制到什么位置和名称。例如，ipa 包的源代码名称是 lookaside 中的一个哈希值，在处理过程中，它将被重命名并复制到 SOURCES/freeipa-4.9.6.tar.gz。

b7b91082908db35e4acbcd0221b8df4044913dc1 SOURCES/freeipa-4.9.6.tar.gz

请确保您也使用了正确的​​分支名称。有关更多详细信息，请参阅本指南后面的“分支名称”部分。

rpms

此区域专门用于 rpm 源代码（spec 文件、补丁、轻量级文本文件等）。这是发生“导入”的地方，无需手动干预或手动提交。任何手动更改都不会被构建系统识别。

modules

此区域专门用于模块化。如果您打算维护一个软件包的多个版本并希望使用模块化，那么这里就是为此设计的。分支名称**应始终与** rpms 匹配。例如，假设您的模块是 idm，并且您有一个名为 DL1 的流。分支可以是 rX-stream-DL1。

模块名称不必与实际的软件包或软件包名称匹配。例如，idm 模块。没有名为 idm 的软件包，但模块中的每个软件包都具有源代码 yaml 中引用的正确分支名称。

预期格式

• SOURCES/modulemd.src.txt -- 这是将转换为 name.yaml 的初始 module yaml 数据。请参阅此处的示例。
• .name.metadata -- 与 rpms 类似，需要一个元数据文件，即使它是空的。

截至本文撰写之时，在根目录生成的 name.yaml 文件可能由 Rocky 自动化帐户完成。

分支名称

分支命名**很重要**。**在任何情况下，main 都不是可接受的分支名称。**

您**必须**使用 rX 作为前缀，其中 X 是主版本号。属于 SIG 并且将在同一个 peridot 项目中的所有软件包必须具有匹配的分支名称。

要支持多版本，需要有多个项目，并且需要适当地命名分支。一个软件包的多个版本不能在单个 peridot 项目中共存。

多版本 + 多项目

可能存在以下情况：

• 软件包的多个版本将以某种形式存在，以及/或
• 尽管这种情况可能很少见，但软件包集可能无法与其他软件包共存，而应存在于完全独立的项目中。

如果这适用于您的 SIG，您可以使用分支名称和 peridot 中的正确配置来使这种分离成为可能。分支名称用于在需要时区分软件包。请参阅理想模板

rX-sig-SIGNAME-VERSION

• rX-sig 被认为是 SIG 前缀
• SIGNAME 将是 SIG 的名称（例如，kernel）
• VERSION 是必需的。可以是数字的，也可以只是另一个名称/缩写。

示例

* Kernel SIG for kernel 5.15 (Rocky Linux 8): r8-sig-kernel-5.15
* Kernel SIG for kernel 5.15 (Rocky Linux 9): r9-sig-kernel-5.15
* Kernel SIG for kernel 6.1 on (Rocky Linux 8): r8-sig-kernel-6.1
* Kernel SIG for kernel 6.1 on (Rocky Linux 9): r9-sig-kernel-6.1

标签

对于 rpm 或模块，应该有相关的标签，否则构建系统**可能不会**识别您的构建。标签的一般格式如下：

• RPM：imports/rX[-SIGNAME-VERSION]/NEVR（例如，imports/r8/bash-4.4.20-2.el8 是可以接受的）

• 注意：您不能选择一个用于一个 rocky 发行版的标签/分支，而在另一个上进行构建。确保您的标签和分支一致通常会使您和其他维护者更容易。

• 模块：imports/rX-stream-STREAM_NAME_OR_VERSION/MODULE_NAME-STREAM_NAME_OR_VERSION-X0Y00YYYYMMDDHHMMSS.ZZZZZZZZ

• 注意：X 是主版本号，Y 是次版本号。MODULE_NAME 和 STREAM_NAME_OR_VERSION 是必需的。确保正确填写时间戳。您可以用正在使用的提交哈希的一部分来填写最终的 Z。
• 示例：imports/r8-stream-1.4/389-ds-1.4-8060020220204145416.ce3e8c9c

Peridot 项目配置

peridot-config 仓库

每个特别兴趣小组都需要一个名为 peridot-config 的仓库，其中包含特别兴趣小组的内容。这有助于识别将存在哪些仓库以及每个仓库中存在什么。默认文件是 catalog.cfg。下面是一个使用 SIG/Core 的简单示例。

# kind: resf.peridot.v1.CatalogSync
package {
  name: "some-core-tool"
  type: PACKAGE_TYPE_NORMAL_SRC
  repository {
    name: "core-common"
    include_filter: "core-tool-mgt.noarch"
    include_filter: "core-tool-keys.noarch"
  }
}

package {
  name: "some-infra-tool"
  type: PACKAGE_TYPE_NORMAL_SRC
  repository {
    name: "core-infra"
    include_filter: "infra-tool-mgt.x86_64"
    include_filter: "infra-tool-mgt.aarc64"
    include_filter: "infra-tool-mgt.s390x"
    include_filter: "infra-tool-mgt.ppc64le"
    include_filter: "infra-tool-keys.noarch"
  }
}

下面是 SIG/Cloud 的示例。

# kind: resf.peridot.v1.CatalogSync
exclude_filter {
  repo_match: "^cloud-common$"
  arch {
    key: "*"
    glob_match: "kernel-debug-devel-matched"
  }
}
package {
  name: "kernel"
  type: 2
  repository {
    name: "cloud-common"
    # use an include filter, then exclude same NA to force an empty repo
    include_filter: "kernel-debug-devel-matched.aarch64"
  }
  repository {
    name: "cloud-kernel"
    include_filter: "kernel-debug-devel-matched.aarch64"
    include_filter: "kernel-debug-devel.aarch64"
. . .
  }
}

Dist Tags

预计您的 SIG 会有一个分配给您的“简写”名称（由核心团队或您在提案期间自己指定）。此名称将是 Peridot 中应用于您的构建的 dist 宏的一部分，用作软件包构建位置和构建对象的标识符。因此，要求组项目中的所有软件包在其整个范围内都设置此项。例如，如果 SIG 的名称是“Messaging and Communication”，则简写为“mc”，示例软件包名称将是

erlang-22.0.7-1.el9.mc.x86_64.rpm

一些单字 SIG 也可以缩写。例如 hyperscale 可以变成 hs。可能存在无法缩写的情况，并且可以授予例外。cloud 就是一个例子。

注意：在大多数情况下，这将在 SIG 级别配置，为了保持一致性，用户无法修改。

下面是 dist tags 的更多示例

SIG	Dist Tag
altarch	elX.altarch
cloud	elX.cloud
core	elX.core
hyperscale	elX.hs

导入到 S3

待定。目前请与发布工程（SIG/Core）成员合作寻求帮助。在未来的 peridot 版本中，应该会有更多功能来进一步支持用户。

资源

账户服务Git (RESF Git Service)Git (Rocky Linux GitLab)镜像邮件列表

URL: https://accounts.rockylinux.org

目的：账户服务维护 Rocky 生态系统几乎所有组件的账户。

技术：Noggin，由 Fedora 基础设施使用。

联系方式：Mattermost 中的 ~Infrastructure 和 Libera IRC 中的 #rockylinux-infra。

URL: https://git.resf.org

目的：Rocky Enterprise Software Foundation 的通用项目、代码等。

技术：Gitea。

联系方式：Mattermost 中的 ~Infrastructure、~Development，以及 Libera IRC 中的 #rockylinux-infra、#rockylinux-devel。

URL: https://git.rockylinux.org

目的：Rocky Linux 发行版的软件包和轻量级代码。

技术：GitLab。

联系方式：Mattermost 中的 ~Infrastructure、~Development，以及 Libera IRC 中的 #rockylinux-infra、#rockylinux-devel。

URL: https://mirrors.rockylinux.org

目的：用户可以申请成为镜像，以托管 Rocky 内容（SIG 或基础操作系统）。

技术：MirrorManager 2。

联系方式：Mattermost 中的 ~Infrastructure 和 Libera IRC 中的 #rockylinux-infra。

URL: https://lists.resf.org

目的：用户可以订阅并与 Rocky 生态系统的各种邮件列表进行互动。

技术：Mailman 3 + Hyper Kitty。

联系方式：Mattermost 中的 ~Infrastructure 和 Libera IRC 中的 #rockylinux-infra。