Skip to content

Packaging

Everyone can contribue to packages maintained by the Hyperscale SIG via pull requests. This document explains the recommended contribution workflows; SIG members will also want to see our documentation on building packages.

Prerequisites

We recommend using a Fedora Linux or CentOS Stream (with EPEL enabled) system for development. The necessary tools can be installed with:

$ sudo dnf install mock mock-centos-sig-configs centpkg-sig

You will also want to clone the centos-git-common repository for get_sources.sh.

SIG-maintained packages are hosted git.centos.org under the cXs-sig-hyperscale branches, where cXs refers to the CentOS Stream version (e.g. c8s for CentOS Stream 8).

To open PRs on git.centos.org you will need a CentOS account with a valid SSH key added to it. If you're creating a new account, you will also need to login at least once on git.centos.org with it to initialize your permissions.

Branching new packages for Hyperscale

If a package is not currently branched, please file a ticket on our issue tracker explaining why you'd like it to be included.

Cloning and building a package

To clone an existing package:

$ git clone ssh://git@git.centos.org/rpms/$package.git

And checkout the relevant branch:

$ git checkout cXs-sig-hyperscale

To fetch the sources from lookaside, run get_sources.sh from inside the checkout.

You can use mock to do a local test build, for example:

$ mock -r centos-stream-hyperscale-9-x86_64 --sources . --spec systemd.spec --postinstall

Use centos-stream-hyperscale-$releasever-$arch for packages targeting the Hyperscale main repo, and centos-stream-hyperscale-experimental-$releasever-$arch for packages targeting the experimental repo.

Making changes

Make a branch for your work:

$ git checkout -b work

and do your changes. Remember to add a changelog entry and to bump the Release field.

Merging upstream changes

Sometimes it is necessary to catch up a Hyperscale-branched packaged with the latest changes that had happened upstream. Note that "upstream" for a Hyperscale package could be either the corresponding CentOS Stream branch (for modifications of exisiting CentOS packages), or a Fedora branch (for backports), and these are hosted in different places:

  • CentOS Stream sources are in the cXs branches on GitLab, where cXs refers to the CentOS Stream version (e.g. c9s for CentOS Stream 9).
  • Fedora sources are in the corresponding branch on Fedora dist-git

If you're not sure, please ask before embarking on this work.

To beging with, add the relevant remote to your local checkout. For a package originating from CentOS Stream 9 that would be:

$ git remote add gitlab https://gitlab.com/redhat/centos-stream/rpms/$package.git

Once you have the remote, fetch all changes, checkout the Hyperscale branch and merge the upstream branch into it:

$ git fetch --all
$ git checkout c9s-sig-hyperscale
$ git merge gitlab/c9s
Resolving conflicts

If the Hyperscale package was a straight unmodified backport (e.g. from Fedora), this should just work. In almost all other cases, this will result in a conflict that you will have to resolve. Usually the conflict is around the Release and changelog sections, but other parts of the specfile could be affected too. For Release, you'll want to follow our versioning policy. For the changelog, interleave the new upstream entries with the previous Hyperscale entries and ensure they're in chronological order, then add a new changelog entry detailing your changes.

Submitting changes

You will need to fork the repository on git.centos.org if you haven't already (by clicking the "Fork" button on the repository page (example). Once you have a fork, add the corresponding remote to your local checkout:

$ git remote add fork ssh://git@git.centos.org/forks/$account/rpms/$package.git

Once you're ready to submit your changes, push them to your fork:

$ git push fork work

and create a PR against the corresponding SIG branch. Note that if the PR contains a merge commit, the commit list in the git.centos.org may be incorrect due to a Pagure bug. This is purely a cosmetic issue and does not impact the actual PR content or the ability to merge it.