## TL;DR
The CRB repo is not enabled by default in RHEL, and in keeping with it, the equivalent Powertools repo is also disabled by default in CentOS 8 and CentOS Stream 8.

We can keep the 'disabled by default' nature but make it easier for downstream repos that have dependencies on CRB/Powertools by carving this out from the centos-stream-repos RPM and instead ship CRB/Powertools separately (e.g. maybe centos-stream-repos-crb or centos-stream-crb-repo)

To make this portable between different RHEL rebuilds (e.g. Alma, Rocky, OEL), and since CentOS Stream 9 as the upstream for RHEL 9 is the de facto reference distribution, perhaps we should also pick a branding-neutral name that this repo can provide, e.g. it can `Provide: repo(CRB)`?

## The problem
Downstream repos such as EPEL (and through EPEL, Hyperscale and RPM Fusion) have documented dependencies on CRB/Powertools, but they do not have an automated mechanism for ensuring CRB/Powertools is enabled.

Instead they have to rely on documenting the manual steps needed
e.g.
- EPEL: https://fedoraproject.org/wiki/EPEL#How_can_I_use_these_extra_packages.3F
- RPM Fusion: https://rpmfusion.org/Configuration

This is both inconvenient and error-prone, leading to a bad user experience and a maintenance burden for package maintainers (in EPEL and other repos) as users report bugs that are due to Powertools not being enabled (some of these bugs will be linked as dependents to this issue).

Further, using dnf config-manager modifies the repo definition in place - there are discussions with upstream DNF about the possibility of having overlay configurations in the future, so we can override a repo definition without modifying the original file; this is still a long way off though and so not in scope for CS9.

The problem is:
- the repo file is marked config(noreplace) meaning any future update will not be reflected on systems where Powertools has been overridden to be enabled, until the admin user merges these changes
- if we update the repo definition to be config(replace), that means any update to the repo will re-disable CRB/Powertools until the admin user overrides it again, and thus break future package installs

Mike Rochefort compiled some data about the scope of this issue (of CRB packages being depended on by EPEL):

  https://gitlab.com/omenos/crb-depends

( discussion in https://lists.centos.org/pipermail/centos-devel/2021-July/077149.html )

During the recent office hour, it's been pointed out that CRB is initially meant for build-time dependencies only, not runtime dependencies, but unfortunately this turns out not to be the case. The long-term solution would likely be for any subpackages that EPEL depends on to be promoted to RHEL proper, or the entire package retired from RHEL/Stream and can be maintained in EPEL.

Neal Gompa highlighted some major software that are dependent on CRB at runtime:
- pagure depends on python-markdown
- KDE also has runtime dependencies on CRB

Given that this is a long way off, having a subpackage likely preserves the equivalence of not enabling CRB by default, but make it easier for end users and package maintainers. We can then consider building automation to automatically file issues when such a runtime use is detected (perhaps building on Mike's work to scope out the problem).

This will not affect the experience of RHEL users, where nothing will provide repo(CRB), as we can simply make epel-release have a weak dependency (Recommends) on it rather than a hard dependency