内容管理

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

导入到RESF Git服务

所有特别兴趣小组在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源（规范文件、元数据文件等），并很快将支持dist-git/src-git。虽然此区域是可选的，但您很可能将其用于管理rpm源并将tarball源上传到lookaside。

对于rpm源的情况，这是最标准的用法，导入从这里开始。当发生导入时，只要peridot目录配置已知，这些就会出现在rpms中。注意，下面rpms部分的所有规则都适用。

rpm规则

重复一遍：下面rpms部分的所有规则都适用。请确保您仔细阅读。

RPM格式规则

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

预期的格式是

• SOURCES/... -- 轻量级文本文件、脚本、补丁等可以放在这里（例如，不在tarball中的文件）
• SPECS/name.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源（规范文件、补丁、轻量级文本文件等）。这是“导入”发生的地方，无需手动干预或手动提交。任何手动更改都不会被构建系统拾取。

modules

此区域专门用于模块化。如果您计划维护软件包的多个版本并希望使用模块化，则可以在此处执行此操作。分支名称应始终与rpms匹配。例如，假设您的模块是idm并且您有一个名为DL1的流。分支可以是rX-stream-DL1。

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

预期的格式

• SOURCES/modulemd.src.txt -- 这是将转换为name.yaml的初始模块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"
. . .
  }
}

发行版标签

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

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

一些单字 SIG 也可以缩写。例如，hyperscale 可以缩写为 hs。某些情况下可能无法缩写，可以申请例外。cloud 就是一个例子。

注意：在大多数情况下，这将由 SIG 配置，出于一致性目的，用户无法修改。

下面是一些 dist 标签的示例

SIG	Dist 标签
altarch	elX.altarch
cloud	elX.cloud
core	elX.core
hyperscale	elX.hs

导入到 S3

待定。目前，请与发布工程（SIG/核心）成员合作以获取帮助。在未来的 Peridot 版本中，应该会有更多功能供用户使用。

资源

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

URL: https://accounts.rockylinux.org

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

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

联系方式：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。