Relation between git.centos.org and gitlab.com/redhat/centos-stream/rpms

Our Neighbors CentOS
1

Ok. Forgive my dumb question, but I’m not very well versed in development, composes, building and so on, but I have a curiosity.
git.centos.org is the CentOS Stream repository for source code releases, correct? So, what about gitlab.com/redhat/centos-stream/rpms?
I mean, let’s take the keepalived package for CentOS Stream 9. On git.centos.org it is at version 2.2.4, while on the gitlab repository is at 2.2.8
How does it work? Sometimes in the future, the spec file will be pushed from gitlab to pagure? If someone (probably not me :sweat_smile:) want to submit a fix or a patch, where should they address the merge request?

2

I have described the details in my mail on devel mailing list

In short git.centos.org is not relevant to CentOS Stream at all.

Let’s consider this specific example:

  • Version 2.2.4-6 has been built 6 months ago (keepalived-2.2.4-6.el9 | Build Info | CentOS Stream BuildSys)

    from

    Source: git+https://gitlab.com/redhat/centos-stream/rpms/keepalived#fc07f81c047dca49df2fc9d20513a7f52005a54d

  • It was built into CentOS package and RHEL package.

  • CentOS package was published within a couple of weeks. RHEL package was shipped to customers 4 months later.

  • After RHEL package was shipped, we took the SRPM of that RHEL package, unpacked it and uploaded to git.centos.org

Which means that

  1. The real source of the keepalived-2.2.4-6 rpm for both CentOS and RHEL is this specific commit on gitlab.com.
  2. on git.centos.org it is not a real source but an unpacked SRPM, created much later than the binary package.

What about keepalived-2.2.8-2.el9?

It was built 4 days ago (keepalived-2.2.8-2.el9 | Build Info | CentOS Stream BuildSys) from the commit on gitlab (Fix keepalived.conf installation (!16) · Merge requests · Red Hat / centos-stream / rpms / keepalived · GitLab)

The package currently sits in the gate (c9s-gate tag in Koji) and waits until its RHEL version passes the QE verification.

After QE are done with their tests, the CentOS package will be shipped to CentOS Stream.

RHEL package built from the same commit will wait until the next minor release of RHEL.

Where to contribute

Via Merge Requests on Gitlab.

7 Likes
3

Thanks for the very clear write-up. I wish it had been part of the press announcement …

Two minor questions:

  1. CentOS and RHEL packages build literally from the same commit (i.e. SPEC+SOURCES) so any differences come from the buildroot and different macro expansions. Is there an easy way to see the “effective diff” (buildflags etc)?

  2. There are (rare) exceptions to the described workflow when there are embargoed security fixes. When/how do they land in CentOS?

4

CentOS and RHEL packages build literally from the same commit (i.e. SPEC+SOURCES) so any differences come from the buildroot and different macro expansions. Is there an easy way to see the “effective diff” (buildflags etc)?

Afaik, there is no difference. Well, maybe some cosmetics, like replacing word Centos with the word RHEL in some metadata, but I think it all comes from packages like centos-release nowadays.

There are (rare) exceptions to the described workflow when there are embargoed security fixes. When/how do they land in CentOS?

They indeed land into minor branch of the currently released RHEL first. But as soon as they are shipped in the currently available minor release, they need to be brought into CentOS Stream so that there is no regression in the next RHEL minor release which is prepared from it.

If a package in CentOS Stream is already updated from the current version shipped in RHEL minor release, like with that keepalived package, than the CVE fix will have to be rebased on top of the version available in the c9s branch in CentOS Stream.

Therefore you may not get exactly the same patch RHEL used in its minor release, but rather the adjusted version of it.

3 Likes