Since this is a change in behavior would it be ok to target 9.1 for the fix?

Well I would be very careful with the change. It is true that DNF downloads only one of them (preferentially the compress one) and uncompressed is created later on, but it doesn't mean that it is a non braking change. We can provide a new option that will ensure the compatibility and keep the current default behavior. Or we can change the default behavior and deploy the change to Fedora first and then to RHEL to ensure that we discovered all side affects. But it means to postpon the release of the change to 9.3 We have to consider legacy user cases where the new createrepo will create content for old RHELs therefore we have to investigate acompatibility of the change with yum 3 (RHEL 7) first.

I will add another voice in support of not making this change mid-RHEL. This would be very prone to unnecessary breakage in various tooling that relies on one or the other. If this is something that we would pursue at all, I would say that it _must_ go into Fedora first, and then have a lengthy validation period. Likely well beyond the RHEL 9 timeframe.

Satellite currently expects the uncompressed variant to be there, which is an easy fix, but worth considering.  I concur with Jaroslav and Kyle that it shouldn't happen in 9.1.  9.3 might be reasonable, I can follow up on that in the future.

Will the metadata tagged as "group" in repomd.xml disappear completely, with consumers expected to look for "group_gz" or "group_xz", or will "group_gz" and "group_xz" disappear, with "group" being compressed under any supported compression type?

Keep in mind, nothing will actually change for RHEL repos since RHEL doesn't use createrepo_c to generate their repos.  Only the uncompressed groups metadata variant exists currently and that won't change.

It looks like that the request could be blocked by https://bugzilla.redhat.com/show_bug.cgi?id=1904360. If we will remove `group` type and distribution will exchange `group_gz` by `group_xz` then we have a disaster.

As per my comment here (https://bugzilla.redhat.com/show_bug.cgi?id=1904360#c7) I suggest that Fedora and RHEL should use compressed metadata with the "group" metadata name, which ought to work fine (I haven't tried it, but the logic of the code should handle it).

Whether createrepo_c can adopt that change is questionable. I believe as mentioned legacy yum (ie. EL6, EL7) may not work with such repos. However, we could either restore the old behavior under the --compatibility flag, or if that is too aggressive we could make it more opt-in.

>However, we could either restore the old behavior under the --compatibility flag, or if that is too aggressive we could make it more opt-in.

I meant make the new behavior opt-in, as we can't assume that anyone who wants to generate EL6/EL7 repos is already using the --compatibility flag, even though it would be really convenient to just shove all legacy compatibility behaviors under that flag and in a vacuum that would absolutely be my preference.

The issue was created by https://github.com/rpm-software-management/createrepo_c/commit/a3c8f027af1f15c9e93c34a5ba3b82e8a3e630f9 version 0.13.0, therefore it created a regression in RHEL8.

I recommend to develop two solution.

For upstream and RHEL10:
Create only `group` type metadata (compressed (various compressions), or uncompressed). It means no `group_gz` or `group_xz`

This solution will unify behavior with standard metadata types (primary, filelists, ...).
The solution is not compatible with RHEL7 and YUM version 3 because it is unable to open compressed `group.xml`. Therefore uncompressed `group` file is required to create RHEL7 compatible repository (it might require an additional option).

AC: By default createrepo_c must not create `group_gz` or `group_xz` and even with `--xz` option used to modified compression algorith.
The new metadata must work correctly with DNF version from RHEL 8.0 GA.
Documentation must describe how to create RHEL7 compatible metadata


For RHEL8/9 there are 3 alternative solution:

A) (not compatible with RHEL7)
We should deliver a solution to not generate `group_xz` metadata when the `--xz` option is used. CentOS Stream distribution is affected with this issue.

I suggest to generate `group` type with compressed `group.xml` when `--xz` is used. No change in default behavior (`group_gz` and `group` will be kept).

AC: By default createrepo_c must create `group_gz` and `group`
 - With `--xz` option generate compressed `group` type of metadata.
 - The new metadata must work correctly with DNF version from RHEL 8.0 GA.
 - Documentation must mention that metadata generated with `--xz` are not compatible with RHEL7 (I believe that they were not compatible with RHEL7 anyway before the change for other metadata types)

B) (compatible with RHEL7)
We should deliver a solution to not generate `group_xz` metadata when the `--xz` option is used. CentOS Stream distribution is affected with this issue.

I suggest to generate `group_gz` type with compressed `group.xml` (by xz compression) and uncompressed `group` type when `--xz` is used. No change in default behavior (`group_gz` and `group` will be kept).

AC: By default createrepo_c must create `group_gz` and `group`
 - With `--xz` option generate compressed `group_gz` and uncompressed `group` type of metadata .
 - The new metadata must work correctly with DNF and YUM from RHEL7 and RHEL8.


C) (only documentation update)
Document that option `--xz` will generate compressed group metadata (`group_xz` type) unusable by anyone.

>I suggest to generate `group_gz` type with compressed `group.xml` (by xz compression) and uncompressed `group` type when `--xz` is used. No change in default behavior (`group_gz` and `group` will be kept).

I'm not sure I understand what you're saying here, is it that "group_gz" would be compressed with xz compression?  If so I'm not sure I like that - "group_gz" should be "gz"-compresessed if it's kept around at all. What might make sense (and maybe this is what you meant?) is, produce all xz-compressed metadata including the "group" metadata, but additionally produce "group_gz" which is gzip-compressed.  Yum will prefer the latter so if it is present the former will be ignored (so it shouldn't break). DNF should be changed to not look for "group_gz" and instead pick up the "group" metadata which is compressed the same way everything else is.

Does that make sense?

Update for Comment 12:

RHEL8/9 (decision) - We will document the issue as KNOWN ISSUE without updating createrepo_c package.

The bug cannot be fixed during lifecycle of RHEL therefore I am closing it. We will document the issue as a known issue.