Hi,

When you have access to RHEL repo you can use repoquery to download comps (and other metadata in EL8 version). Then you have to debrand them.

There are at least two things that you have to debrand.

1) Descriptions. There is a lot of Red Hat Enterprise Linux and other. Note that some descriptions (Chineese if I recall corectelly), have Red Hat written in respective language, so it's not as trivial as `sed s/Red Hat/My Distro/g`. 2) You have to change/replace some packages like redhat-logos. You also have to remove some packages (mostly connected with RHEL registration).

Bests, Alex

On 1/21/21 2:34 AM, Brian Stinson wrote:

On Wed, Jan 20, 2021, at 17:13, Ken Dreyer wrote:

...

Hi folks,

When I look at a commit like this: https://git.centos.org/centos/comps/c/5251f94b374cd9cf527f85a0a82245c0a83810...

it's adding over 10,000 lines of configuration. I'm wondering how that relates to RHEL's comps. Do the CentOS developers have a tool that generated that XML from a data source elsewhere? Did someone write that XML by hand?

• Ken

---

CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel

These commits are generated from debranding and then processing (for language translations and such) the RHEL comps.

--Brian _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel

On Thu, Jan 21, 2021 at 12:40 PM Ken Dreyer kdreyer@redhat.com wrote:

On Thu, Jan 21, 2021 at 1:46 AM aleksander.baranowski via CentOS-devel centos-devel@centos.org wrote:

...

When you have access to RHEL repo you can use repoquery to download comps (and other metadata in EL8 version). Then you have to debrand them.

I checked the comps XML files from BaseOS and AppStream today, and those XML files are different than this file in Git.

For example, the BaseOS Yum repo's comps.xml has one "file-sever" group, and AppStream's comps.xml has another "file-system" group, and they are combined in the comps file that CentOS uses for Pungi.

I can explain this.

Internally, we have a single comps file that looks almost identical to the CentOS one referenced except for the branding changes already mentioned. It delineates packages between repos using "variant="BaseOS" or variant="AppStream", etc. For groups that have packages split across repos, you'll see both variant statements within the group definition. When pungi runs, it will take the single comps file and deconstruct it based on variant statements to produce per-repository comps definitions. That way the comps groups don't include packages that are not actually in that repository.

On a system attached to these repositories, yum will actually pull the comps data from both groups and recombine them to the full group definition. There's an example below that illustrates this.

josh

[jwboyer@vader ~]$ podman run -it --rm ubi8 Trying to pull registry.access.redhat.com/ubi8... Getting image source signatures Copying blob cca21acb641a [--------------------------------------] 0.0b / 0.0b Copying blob d9e72d058dc5 [--------------------------------------] 0.0b / 0.0b Copying config 3269c37eae done Writing manifest to image destination Storing signatures [root@2db2390ba9d6 /]# yum --disablerepo=* --enablerepo=rhel-8-for-x86_64-baseos-rpms groupinfo file-server Updating Subscription Management repositories. Unable to read consumer identity Subscription Manager is operating in container mode. Red Hat Enterprise Linux 8 for x86_64 - BaseOS 17 MB/s | 27 MB 00:01 Last metadata expiration check: 0:00:03 ago on Thu Jan 21 21:07:20 2021.

Group: File and Storage Server Description: CIFS, SMB, NFS, iSCSI, iSER, and iSNS network storage server. Mandatory Packages: cifs-utils gssproxy nfs-utils nfs4-acl-tools samba Optional Packages: isns-utils [root@2db2390ba9d6 /]# yum --disablerepo=* --enablerepo=rhel-8-for-x86_64-baseos-rpms --enablerepo=rhel-8-for-x86_64-appstream-rpms groupinfo file-server Updating Subscription Management repositories. Unable to read consumer identity Subscription Manager is operating in container mode. Red Hat Enterprise Linux 8 for x86_64 - AppStre 14 MB/s | 25 MB 00:01 Last metadata expiration check: 0:00:04 ago on Thu Jan 21 21:07:51 2021.

Group: File and Storage Server Description: CIFS, SMB, NFS, iSCSI, iSER, and iSNS network storage server. Mandatory Packages: cifs-utils gssproxy nfs-utils nfs4-acl-tools samba targetcli <---this showed up from AppStream now Optional Packages: isns-utils [root@2db2390ba9d6 /]#

On Thu, Jan 21, 2021, 5:50 PM Ken Dreyer kdreyer@redhat.com wrote:

On Thu, Jan 21, 2021 at 2:12 PM Josh Boyer jwboyer@redhat.com wrote:

...

I can explain this.

Internally, we have a single comps file that looks almost identical to the CentOS one referenced except for the branding changes already mentioned. It delineates packages between repos using "variant="BaseOS" or variant="AppStream", etc. For groups that have packages split across repos, you'll see both variant statements within the group definition. When pungi runs, it will take the single comps file and deconstruct it based on variant statements to produce per-repository comps definitions. That way the comps groups don't include packages that are not actually in that repository.

Thanks Josh, this clears up a lot. I also found https://docs.pagure.org/pungi/comps.html and that helps me understand further how this process works.

It sounds like CentOS engineers copy and transform an internal RHEL comps XML for CentOS 8 and push it to Pagure. And then when we get to CentOS 9 Stream, release engineers will make comps changes happen in CentOS' git first?

Engineering in general, but yes. For those interested before Stream 9 is available, the eln comps file in the fedora-comps repo is tracking things as they are developing.

josh