[CentOS-devel] Enabling PowerTools by default? (and proof-of-concept alternative)

Sat May 22 08:38:04 UTC 2021
Phil Perry <pperry at elrepo.org>

On 21/05/2021 19:36, Josh Boyer wrote:
> On Wed, May 19, 2021 at 10:18 PM Nico Kadel-Garcia <nkadel at gmail.com> wrote:
>> On Wed, May 19, 2021 at 9:32 PM Michel Alexandre Salim
>> <michel at michel-slm.name> wrote:
>>> At the Hyperscale SIG, one of the repos we ship (centos-release-
>>> hyperscale-hotfixes, which we use to override modular content we need
>>> to fix as MBS is not available to SIGs) depends on EPEL (because the
>>> packages there, for example libvirt, needs dependencies in EPEL).
>>> EPEL's Quickstart recommends enabling codeready-builder on RHEL8, and
>>> the corresponding powertools repo on CentOS 8:
>>> https://fedoraproject.org/wiki/EPEL#Quickstart
>>> Could we possibly just enable powertools by default? CRB is on by
>>> default in RHEL8 UBI containers (but weirdly not in the related CentOS
>>> Stream containers!).
>> Good luck with that. Disabling Powertools by default is a RHEL
>> upstream behavior. The segregation of these tools and the disabling of
>> them by default is one of the aspects of RHEL 8 and CentOs 8 that
>> profoundly irritate me, they've so far served no useful purpose and
>> only caused confusion. They do reduce the metadata download
>> requirements somewhat for ordinary yum updates, but that's a distinct
>> issue.
> For whatever it's worth, CodeReady Builder is disabled by default in
> RHEL 8 because it is a repository that contains content that is not
> supported at runtime in production.  Enabling it by default would
> immediately lead to customers depending on unsupported content without
> any awareness of that dynamic.  We want to make sure they're set up to
> use supported content from the start.

Isn't that the same reason Red Hat cites for not including the missing 
-devel packages in RHEL? If so, I see no reason not to ship them in 
CodeReady Builder as unsupported, and not enabled by default.

> CentOS Stream doesn't have support in the same sense, so PowerTools
> being disabled is indeed more friction than may be necessary but some
> of the same principles still apply.
> josh