Managing Content

This section goes over how to manage content in git and the community build system.

Importing to the RESF Git Service¶

All Special Interest Groups get an organization created in the RESF Git Service. Each organization will have a meta repository that can track issues or requests for the SIG as a whole. This is not a requirement and each SIG can dictate how issues or requests are handled.

There is no strict requirement on what repositories should and should not exist. It is up to the discretion of the SIG.

Importing to the Rocky Linux GitLab¶

Special Interest Groups that build and release packages will have a subgroup under SIG. This subgroup will have additional subgroups, src, rpms, modules.

Additional Subgroups

While this is the default layout, additional subgroups can be made at the root of the SIG group. It is expected that some SIG's may not have plans to build packages as they could have an entirely separate focus.

rpms¶

This area is specifically used for rpm sources (spec file, patches, light text files). The expected format is:

SOURCES/... -- light text files, scripts, patches, etc can come here (e.g., ones not in a tar ball)
SPECS/name.spec -- Your spec file comes here - note it should only be one spec file
.name.metadata -- Required, lists your source archives or otherwise that will be in lookaside. Empty if there are no sources to pull from lookaside.

The metadata file format is expected to be:

SHA256SUM_STRING SOURCES/some_name

The left column is generally a hashed sum of the archive. This is the name of the file in lookaside. The right side is where the archive will be the location and name of where it will be copied to. For example, the ipa package source name is a sum in lookaside, and during processing, it will be renamed and copied to SOURCES/freeipa-4.9.6.tar.gz:

b7b91082908db35e4acbcd0221b8df4044913dc1 SOURCES/freeipa-4.9.6.tar.gz

modules¶

This area is specifically used for modularity. If you plan on maintaining multiple versions of a package and want to use modularity, this is the place to do it. The branch names should always match with rpms, especially when there are multiple versions. See the branch section in this document for more information.

The name of the module does not necessarily have to match the actual package or package names. For example, the idm module. There is no package named idm, but each package as part of the module has the correct branch names as referenced in the source yaml for the module.

The format expected:

SOURCES/modulemd.src.txt -- This is the initial module yaml data that will be transformed name.yaml. See this for an example.
.name.metadata - Just like rpms, a metadata file is required, even though it will be empty.

As of this writing, the name.yaml file generated in the root may be done by the Rocky Automation account.

src¶

This area is specifically used for having the source of the rpm. This means that instead of uploading directly to S3, sources can be managed within a repository that matches the name of an rpm in the rpms group, by using dist-git/src-git. This is an optional group and does not have to be used. These are subject to the correct branch names.

Branch Names¶

Branch naming is important. main is NOT an acceptable branch name under any cirumstances.

You must use rX as the prefix, X being the major version number. All packages that are part of a SIG and will be in a peridot project together must have matching branch names.

To support multiple versions, there will need to be multiple projects and branches need to be named appropriately. Multiple versions of a package cannot coexist in a single peridot project.

Multiple Versions + Multiple Projects¶

There may be cases where:

Multiple version of a package will exist in some form and/or
Although the cases may be rare, sets of packages may not coexist with others and live in completely separate projects.

If this applies to your SIG, you can use branch names and the proper configuration in peridot to make this separation possible. The names of the branches are used to separate packages if need be. See the ideal template:

rX-sig-SIGNAME[-PKGNAME]-VERSION

rX-sig is considered the SIG prefix
SIGNAME would be the name of the SIG (for example, kernel)
PKGNAME is optional
VERSION is required

Examples:

* 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

Tagging¶

In the case of an rpm or a module, there should be tags associated, otherwise the build system will not pick up your builds. The general format for tags are as follows:

RPM: imports/rX/NEVR (for example, imports/r8/bash-4.4.20-2.el8 is acceptable)
Note: You cannot choose a tag/branch destined for one rocky release and build on another. Ensure your tags and branches are in alignment.
Module: imports/rX-stream-STREAM_NAME_OR_VERSION/MODULE_NAME-STREAM_NAME_OR_VERSION-X0Y00YYYYMMDDHHMMSS.ZZZZZZZZ
Note: X is the major version, Y is the minor version. MODULE_NAME and STREAM_NAME_OR_VERSION are required. Ensure you fill out the timestamp as appropriate. You may fill in the final Z's with a portion of the commit hash that you are using for the tag.
Example: imports/r8-stream-1.4/389-ds-1.4-8060020220204145416.ce3e8c9c

Peridot Configuration¶

Each Special Interest Group will need a repository called peridot-config which will contain the content of the special interest group. This helps identify what repositories will exist and what exists in each repository. The default file is catalog.cfg. Below is just a simple example using 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"
  }
}

Below was a SIG/Cloud example.

# 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"
. . .
  }
}

Importing to S3¶

TBD

Resources

Account ServicesGit (RESF Git Service)Git (Rocky Linux GitLab)MirrorsMail Lists

URL: https://accounts.rockylinux.org

Purpose: Account Services maintains the accounts for almost all components of the Rocky ecosystem

Technology: Noggin used by Fedora Infrastructure

Contact: ~Infrastructure in Mattermost and #rockylinux-infra in Libera IRC

URL: https://git.resf.org

Purpose: General projects, code, and so on for the Rocky Enterprise Software Foundation.

Technology: Gitea

Contact: ~Infrastructure, ~Development in Mattermost and #rockylinux-infra, #rockylinux-devel in Libera IRC

URL: https://git.rockylinux.org

Purpose: Packages and light code for the Rocky Linux distribution

Technology: GitLab

Contact: ~Infrastructure, ~Development in Mattermost and #rockylinux-infra, #rockylinux-devel in Libera IRC

URL: https://mirrors.rockylinux.org

Purpose: Users can apply to be a mirror to host Rocky content (SIG or the base operating system)

Technology: MirrorManager 2

Contact: ~Infrastructure in Mattermost and #rockylinux-infra in Libera IRC

URL: https://lists.resf.org

Purpose: Users can subscribe and interact with various mail lists for the Rocky ecosystem

Technology: Mailman 3 + Hyper Kitty

Contact: ~Infrastructure in Mattermost and #rockylinux-infra in Libera IRC

Last update: 2023-03-23