Sources

All artifacts (RPMs, container images, ISO images) build using source code stored in a Git version control system. Repositories have different branches reflecting the build environment those sources will be used in.

All CentOS Stream RPM Sources live on GitLab.

Projects are publicly accessible and a GitLab account can be used to contribute.

DistGit¶

Though Git is a critical part of the Project's build system, it is not the best solution for dealing with non-text objects such as upstream code tarballs and binary files. DistGit is an integration with Git that provides tooling to be able to accommodate the tracking of these assets alongside the RPM repositories. It creates a lookaside cache that stores the objects and modifies a designated file in the RPM repository that references them with a SHA hash. That's in the sources file. During the build process objects referenced in the DistGit file will be pulled from the lookaside cache into the appropriate directories.

For example:

GitLab: sources

[source,text]
SHA512 (git-2.31.1.tar.xz) = 9aa334a3e8519700ff5d112153ec42677722980094caa9d22aa91afdb65166bd9a98fa445c0d327c428ebfa73bf4832e9b3836109a1d9319feafe3191cfd170e
SHA512 (git-2.31.1.tar.sign) = 0a721876f9869d1dc9a43e7f83f8e63a3d8fa932ff2d2e69bb98f3e314e2e9a896c2171cb6a020d6c6e929fdf1af736dbeb3f25f93fb4d359a9aaa5b859069c3

Source Git¶

If you’re familiar with how packaging is done in CentOS and Fedora, you may know dist-git repositories: each repository represents a source RPM package and contains all the RPM source files (RPM spec file, upstream tarball checksum and optionally patch files and other files). But the repository itself doesn't contain any source code - you need to execute %prep phase to see the source tree before it's being compiled.

CentOS Stream 9 and CentOS Stream 10 have orthogonal relationship with Red Hat Enterprise Linux and because of this fact, source-git repositories work differently for both c9s and c10s.

Red Hat maintainers that want to use a source-based workflow will be working here and MRs will be merged to the c9s or c10s branches and synchronized to dist-git. CentOS Stream source-git repos contain git history of the upstream project so you'll feel more like contributing to the project rather than a bunch of downstream packaging files. The CentOS Stream changes and packaging content are layered on top of the upstream git history.

Submitting a change in a source-git repo¶

Changes to packaging files, such as the spec file, are done without any special care on your side: just edit the file, save it and commit it. All the packaging files live in a .distro subdirectory.

Changing source code by defining the patch in a spec file¶

Creating source code changes needs a bit more work. Packages are modified in CentOS Stream 9 traditional dist-git workflow by creating patch files and defining those patches in a spec file. The patches are then applied during a build process in a %prep section.

If you are changing source code and you know that a patch in the spec is needed, add the patch to the spec file with a name of your choice:

Patch123: my-special-change.patch

Now you need to annotate the git commit which matches the patch with the respective change

We need this change in CentOS Stream

Signed-off-by: Tomas Tomecek <ttomecek@redhat.com>
patch_name: my-special-change.patch

---
 src/code.c | 17 +++++++++--------
 1 file changed, 9 insertions(+), 8 deletions(-)

The automation, packit, then reads the commit message, knows that the patch is already defined in the spec file and creates a patch file with the name set in patch_name from the respective commit when creating a SRPM.

This is the preferred way of changing source code since you define the name of the patch files.

For more details on how to work in a source-git repository, please see packit's documentation.

After a merge request is created¶

You should receive a review from a Red Hat maintainer. And that's the time as with any other open source project to work with the maintainer to get the contribution in a state that it can be merged.

Once your MR is approved, it's gonna be merged first in a respective dist-git repo to make sure it can built and passes all the checks. Once all is good, it can be merged in the source-git repo as well.

When you open a source-git MR, you'll be able to see CI checks which are coming from a mirrored MR which was automatically created in dist-git.